[Crm-sig] Preferred Identifier vs Appellation vs Image
vladimir.alexiev at ontotext.com
Mon Oct 7 12:29:47 EEST 2013
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)?
- 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?
> (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):
- 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>.
crm:P2_has_type rst-note:title-primary; crm:P3_has_note "De badende Suzanna"@nl, "Susanna"@en.
<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:
More information about the Crm-sig