[Crm-sig] Preferred Identifier vs Appellation vs Image

[Vladimir Alexiev]

Here's my take, using more direct answers, complementing Martin's answer.

> Q1: Can P1_is_identified_by be used instead of rdfs:label (like
> Vladimir wrote above)?

No.
- P1 leads to a node (E41_Appellation), which itself can carry a literal
- P1 is used for both identifiers and titles while rdfs:label is used only for titles.

> Q2: Is it correct to use P1_is_identified_by for any (internal or
> abstract) identifier, like an inventory number or so?

Yes.

> (If yes, this identifier is a literal an not a new object …)

No. P1 leads to a node, which itself carries the label.

> Q3: Is P48_has_preferred_identifier usable as the 'real' title/name of
> an artefact?

No. It leads to E42 Identifier, which is an identifier not a title.

> Q4: What is P102_has_title for? – I can use P1 and P48 … :-/

You need it to record the title (through a node E35_Title).
P1 is too general, and P48 is not applicable.

And my gripe is that in CRM, you cannot distinguish a Preferred title in a standard way.
You can use E35_Title.P2_has_type to record the title type, but P2 values are not standardized.

Here's an example of a painting that uses all the above constructs (search by prop number):
http://personal.sirma.bg/vladimir/crm/art/susana.ttl.html
- It doesn't bother to specify node types since they are inferred from rdfs:range by RDFS reasonning
- it doesn’t use rdfs:label at all. If you like rdfs:label, you can complement the existing statements about the *primary* title:

<obj/2926> crm:P102_has_title <obj/2926/title/primary>.
<obj/2926/title/primary>
  crm:P2_has_type rst-note:title-primary; crm:P3_has_note "De badende Suzanna"@nl, "Susanna"@en.

with these:
  <obj/2926> rdfs:label "De badende Suzanna"@nl, "Susanna"@en.

> Do I have to express the inverse relation (P1i_identifies) in the
> object (<obj/id/1>) explicit or is the inverse relation
> always/automatically (inplizit) there?

That depends on which implementation and reasoner you use.
- Erlangen CRM (OWL implementation) defines the inverses and OWLIM infers them, so with British Museum data we state only one direction (always from the object towards leaf nodes)
- The CRM (RDFS) implementation declares the inverse properteis but does not define owl:inverseOf
- I've posted here half a year ago a XQuery script that can extract a "profile" from ECRM and leave only the constructs you need

Inverses are convenient since they simplify querying (and to some extent necessary in ResearchSpace if you want to annotate a particular property instance).
But they have their price: they add more statements. See our paper here for some numbers; in our case they add 18.5% more statements:
http://www.ontotext.com/publications/2013

Cheers! V