Why P3_has_note not an object property in current version

[idoia Murua]

Hi,

We are using Erlangen CRM OWL version, and Erlangen FRBRoo OWL version for mapping museum (LIDO) and bibliographic (MARCXML) records into OWL format.

For the MARCXML mapping we are followig the FRBRer to FRBRoo mapping table specified in section 3.3 of http://www.cidoc-crm.org/docs/frbr_oo//frbr_docs/FRBRoo_V2.1_2015February.pdf .

Our problem is that, in this mapping table, it appears the P3_has_note property as an object property, with the E62_String associated to it, and the P3.1_has_type to associate a type to the note.

E.g.:

F3 Manifestation Product Type P3 has note {P3.1 has type E55 Type = “Presentation format”} E62 String

and there a lot more examples like this. 

My question is: Why was it decided to convert the P3_has_note from an object property to a data property and why was the E62_String supressed?

They are very useful when data has to be mapped into OWL and there are´t appropriate properties for doing such mapping.

I have seen that the British Museum (http://collection.britishmuseum.org/resource/rdfs/comment?role=predicate&limit=200) solves this problem by adding new subproperties of the ecrm:P3_has_note property. E.g.:

- bmo:PX_exhibition_history This is a sub-property of crm:P3_has_note, used to represent the exhibition history of an object

- bmo:PX_has_copyright This is a sub-property of crm:P3_has_note, used to represent copyright information

.....

Is this the only solution?

Best,

Idoia

[Martin Scholz]

Hi Idoia,

this design choice was made upon two things:

1) the CIDOC CRM SIG recommends to implement E62 String and other Primitive Values as datatypes according to the underlying system. That's why in OWL / RDF properties pointing to Primitive Values are datatype properties.

2) P3.1 is a property of a property. OWL DL does not allow that. The preferred/generic solution at the moment is introducing subproperties. An alternative would be to introduce an intermediate instance (and a class for it in the ontology) resembling the relation.

Can you elaborate on why object properties should be better usable for mapping than datatype props in your application? The CIDOC CRM does not define any properties that describe Primitive Values (in contrast to the other classes), ie. they are not "subjects" of documentation. This maps quite well to rdf literals that can only appear in object position.

Regards

Martin Scholz

--
You received this message because you are subscribed to the Google Groups "Erlangen CRM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to erlangen-crm...@googlegroups.com.
To post to this group, send email to erlang...@googlegroups.com.
Visit this group at http://groups.google.com/group/erlangen-crm.
For more options, visit https://groups.google.com/d/optout.

[idoia Murua]

Hi Martin,

Sorry for not replying before to your e-mail. I have just checked the group and seen your answer. I was busy with other issues.

Regarding your question, I referred to P3_has_note property: If we want to express the "playing speed" , "reproduction characteristics", etc. of a F3_Manifestation_Product_Type, now we only could do it the following way:

<#F1> rdf:type efrbroo:F3_Manifestation_Product_Type .

<#F1> ecrm:P3_has_note "playing speed is written here" .

<#F1> ecrm:P3_has_note "reproduction characteristics are written here" .

....

so there is no way to differentiate the propertt types. On the contrary, if the P3_has_note were an object property, like it was before, we could express it the following way:

<#F1> rdf:type efrbroo:F3_Manifestation_Product_Type .

<#F1> ecrm:P3_has_note <#S1> .

<#F1> ecrm:P3_has_note <#S2> .

<#S1> rdf:type ecrm:E62_String .

<#S1> ecrm:has_PrimitiveString "playing speed is written here" .

<#S1> ecrm:P2_has_type <#T_playing_speed> .

<#S2> rdf:type ecrm:E62_String .

<#S2> ecrm:has_PrimitiveString "reproduction characteristics are written here" .

<#S2> ecrm:P2_has_type <#T_reproduction_characteristics> .

<#T_playing_speed> rdf:type ecrm:E55_Type .

<#T_reproduction_characteristics> rdf:type ecrm:E55_Type .

Best,

Idoia

[Vladimir Alexiev]

• P3_has_note has always been a data property, both in ECRM (OWL) and in the official CRM releases (RDF). Eg cidoc_crm_v6.2-draft-2015August.rdf defines it as rdf:Property, but the range is http://www.w3.org/2000/01/rdf-schema#Literal, which makes it in essence a data property.
  
• P3.1 is not the same as P2 inside an E62_String. Conceivably, the same string could play different roles in relation to two different objects, so the semantics is different.
  
• If you want to express different musical properties, use subprops of P3. But you should also consider mapping them to more structured props, eg a Speed sounds like a Measurement or Dimension

[idoia Murua]

Hi Vladimir,

Yes, finally we have created several subprops of P3, as you mention. 

In a  a comment header of the following specification: http://www.cidoc-crm.org/rdfs/cidoc_crm_v5.1-draft-2014March.rdfs , we found a suggestion to create specific sub properties of P3.has_note.

Thank you!

Idoia