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
