Common Policy / Method for Implementing the .1 Properties of Base and Extensions in RDF

In the 53rd CIDOC CRM & 46th FRBRoo SIG meeting, PF walked the Sig through the current state of the issue -2 rdfs files generated per published CRMbase model (one for the ontology, one for the Property Classes); plus the following subtopics raised by PM:

1. List the .1 properties of the CRM in the specification document

This particular point has been addressed (and resolved) by Issue 571: a list of all the .1 properties will be added in a tabular form under current table 4 (properties table). Links from that table to the .1 property definition in the document.

Proposal: add scope notes for .1 properties –not for v7.1.2 because there is no time before it is submitted to ISO but for v7.2.1 and on it is definitely something to consider

It is also relevant for Issue 556

2. Proposal to merge the 2 rdfs files (ontology & pc module); apply this policy in extensions too

Objections to that on the grounds that

• it is trivial to implement the .1 properties in a different file, whereas incorporating them to the ontology file would mean that they need to be used.
• if one wants to extend the PC module for an application, they should not have to extend the core model as well
• there are other ways to implement .1 properties, it doesn’t have to be through reification.

Decision: The relation between the CIDOC CRM and the PC module (rdfs implementation of the .1 properties) should be expressed in a comment in the CRMbase file) to minimize confusion

HW: PF to write the statement in the ontology file.

3. Provide scope notes for all PC constructs (using ‘rdfs:comment’)

Proposal: since PCxxx is the same as Pxxx from the point of view of ontology, the scope note of PCxxx could consist of a statement along the lines of “this is the materialization of Pxxx to implement rdf reification. The property means (repeat the scope note of Pxxx)”

HW: PF to prepare a draft statement to be reviewed by the Sig

4. Provide implementation guidelines (generate rdf triples using PCs; run SPARQL queries)

Two options available:

1. Always use the property (e.g., ‘P14 carried out by’) together with its PC class  (‘PC14_carried_out_by’) E.g.:

DATASET EXAMPLE

:painting_sistine_chapel   a  crm:E7_Activity ; 

            crm:P14_carried_out_by :Buonaroti .

:Buonaroti   a  crm:E39_Actor . 

:instanceOfPC14   a   crm:PC14_carried_out_by ;          

            crm:P01_has_domain :painting_sistine_chapel ;                      

            crm:P02_has_range :Buonaroti  ;

            crm:P14.1_in_the_role_of  :master_craftsman . 

QUERY EXAMPLE: Requesting all activities, together with their actors and the role of each actor 

SELECT ?activity ?actor ?role WHERE {    

   ?activity a crm:E7_Activity ; 

           crm:P14_carried_out_by ?actor .    

   OPTIONAL { 

       ?x  a crm:PC14_carried_out_by ; 

             crm:P01_has_domain ?activity ;          

             crm:P02_has_range  ?actor ;         

             crm:P14.1_in_the_role_of ?role } }

2. Use the PC class without using the property

DATASET EXAMPLE

:painting_sistine_chapel a  crm:E7_Activity . 

            crm:P14_carried_out_by :Buonaroti .

:Buonaroti  a  crm:E39_Actor . 

:instanceOfPC14   a   crm:PC14_carried_out_by ;          

            crm:P01_has_domain :painting_sistine_chapel ;                      

            crm:P02_has_range :Buonaroti  ;

            crm:P14.1_in_the_role_of  :master_craftsman . 

QUERY EXAMPLE: Requesting all activities, together with their actors and the role of each actor 

SELECT ?activity ?actor ?role WHERE {      

       ?x  a crm:PC14_carried_out_by ; 

             crm:P01_has_domain ?activity ;          

             crm:P02_has_range  ?actor .       

       OPTIONAL {  

            ?x  crm:P14.1_in_the_role_of  ?role }  }

// the query makes no use of ‘crm:P14_carried_out_by’

Discussion:

• (b) problematic, in the sense that neither the dataset nor the query make use of P14, so one cannot exploit sub/super property information, make reasoning, etc
• (a) unmanageable, in the sense that it requires users to double the effort. It should fall on the users to query for both P01-PCxxx-P02 and Pxx.
• Union SPARQL query (E39 Actor in the range of P14 displayed along with the E39 Actor in the range of P02 has range) as a 3rd scenario (to be included in the statement)
• Given comments above: resolve this by drafting a recommendation document that lays out the two approaches –namely: if data generation process allows case (a) then go for it, if not, the recommendation is to use case (b) but query for both Pxxx and PCxxx. Also include 3^rd scenario in the statement.

HW: PF detailed descriptions (and draft a query for case 3).

The other issues addressed in PMs response are to be discussed at a later stage.

Another point raised was the directionality of PC properties (forward going vs. inverse form).

May 2022

Post by Thanasis Velios (7 July 2022)

Dear all,

I am reading through the discussion on issue 588 (https://cidoc-crm.org/Issue/ID-588-common-policy-method-for-implementing-the-.1-properties-of-base-and-extensions-in-rdf) and looking forward to Pavlos's HW.

I was thinking that we should connect in the graph the property with its reified class. E.g.:

crm:PC14_carried_out_by → crm:P0x_reifies → crm:P14_carried_out_by

This way the two are connected in the graph and some automatic querying could be possible to programme.

With the usual apologies if I have misunderstood the discussion.

All the best,

Thanasis

Post by Pavlos Fafalios (12 September 2022)

Dear all, 

Please find my homework for issue 588 in the below link (as well as in the issues' folder): 

https://docs.google.com/document/d/1oQRkmMUgyOeDsn3ZbPuQ__VtbigS9DVsHjmOtvx16uo/edit?usp=sharing

Apologies for the delay! Feel free to add your comments or send your feedback! 

Best regards,

Pavlos

Post by Mark Fichtner (12 September 2022)

Dear all,

nice work, thanks! I think for RDF this is a valid representation, although I am not very happy to add properties that are not in the cidoc crm directly and that are not part of the language itself (like in this case crm:P03_reifies). As a user/reader of the rdf it is simply hard to understand what is part of the cidoc crm itself and what comes due to "workarounds". Even in as a new ontology/file/addon it mixes cidoc crm and non-cidoc crm things. 

Also we have a reification concept (E13 Attribute Assignment), I am not sure if we need even more of these.

I'm looking forward to the discussion!

Best,

Mark Fichtner

Germanisches Nationalmuseum

Post by Pavlos Fafalios (1 December 2022)

Dear all,

Please find my revised homework for issue 588 below: 
https://drive.google.com/drive/folders/1b0wW70xo2wjxNlWHYDRl7nr-fzYXTch…;

Feel free to add your comments or send your feedback!

Best regards,
Pavlos 

Post by Francesco Beretta (6 December 2022)

Dear Pavlos, all

reconsidering this question of the properties of properties and the proposed solution of the properties-classes remain some doubts and interrogations to me, in particular in relation with the best practices in the field of serialization of conceptual models in RDF.

Metadata about properties as instances, i.e. statement, can be expressed with the standard RDF reification or the new RDF* standard.

What is the best practice in the RDF community to express this kind of properties of properties (and also dates, etc. added to properties in conceptual models) ?

And furthermore: are the CRM properties of properties just 'metadata' or do they carry some additional ontological substance ?

The technical solution of 'PC' does not remove all ambiguity: are they in the end properties or classes? and when we talk about adding, as now, labels and scope notes to the PCs they do becomes classes, don't they? what is then their substance? just to be reified properties?

One could come to think that in fact there is more substance but not totally and adequately expressed, and that should be more carefully analyzed like in the case of P14.1 in the role of: E55 Type or P107.1 kind of member: E55 Type.

Take the example of  P3.1 has type: E55 Type — "This property allows differentiation of specific notes, e.g., "construction", "decoration" etc." (thank you Pavlos for the work you've done).

If P3 is not just taken as a CRM replacement of rdfs:comment, shouldn't the so called associated 'note' be modelled as an information object of type 'damage description' (chipped at edge of handle) related to the corresponding human-made object by P129 is about. Or 'chipped at edge of handle' would be a E3 Condition or State and the 'note' its description?

But because P3 has E62 String as a range, which "is not further elaborated upon within the model", it becomes —P3 I mean— quite relevant as it captures the characterization of the item itself, its internal structures, appearance etc.

So, again, are there any best practices in other communities of RDF experts that apply to these types of situations that should be analyzed before further specifying a notion of PC that doesn't seem totally justified, or raising ontological analisis issues, instead of using simple RDF reification?

Best

Francesco
 

In the 55th joint meeting of the CIDOC CRM and SO/TC46/SC4/WG9; 48th FRBR/LRMoo SIG meeting, the SIG reviewed HW by PF presented on the .1 properties RDFS implementation. 

For details, check attached document.

Summary of decisions: 

• Re. the relevant section where the scope-note of .1 properties will be placed in the specification document (wrt. their domain property definitions): add a section “Properties” that’s placed right below the scope-note of the property and right above the examples section
• Re. the statement concerning the relation of the PC module to the CIDOC CRM base file: approved, needs to be introduced at the end of the CRMbase file. 
• Re. the introductory text and instantiation example to be included in the PC module: add the XML comments in v7.1.1 and subsequent stable versions. The enriched file (e.g., for version 7.1.1) can be found here. How the content is represented (xml comments vs rdfs:comment) can be dealt with in a separate issue.
• Re. the explicit marking of properties that do not form part of the official definition of the CIDOC CRM (but are part of its implementation):
  HW to PF to revise the statements, also consider including other properties that are part of the implementation and do not fall under typed properties treatment (like P81a/P81b, P82a/P82b etc.)
• Points F through I of the HW have not been reviewed for want of time. Can be discussed through the SIG list and be put to an e-vote.

Belval, December 2022
 

Post by Pavlos Fafalios (2 May 2023) --in response to Francesco Beretta's post on the list (6 December 2023)

Dear Francesco,

You have raised some interesting points which, I think, need discussion (but after closing this issue :) ), including:

• what was the motivation of introducing property classes
• how can we tackle ambiguity of PCs (classes vs properties, etc etc)
• why not directly using the standard RDF reification vocabulary <https://www.w3.org/TR/rdf-schema/#ch_reificationvocab&gt;, where properties can be attached to statements/triples.

I will include your comments in the working document of Issue 588, with a suggestion to open a new issue for discussing and working on them.

Best regards,
Pavlos

In the 56th joint meeting of the CIDOC CRM and ISO/TC46/SC4/WG9 &49th FRBR/LRMoo SIG, PF walked the SIG through the remainder of the HW that had not been reviewed in the 55^th meeting.

Summary of decisions:

1. The SIG approved the revised statement wrt the constructs that are part of the rdfs implementation (see statement in the appendix—point E).
   
   1. Xml comments to be turned into standardized <rdfs:comment> statements
      HW: ETz & PF to implement
2. The SIG approved the proposal to introduce labels & scope notes for PCs in the PC file (see appendix –point F)
   HW: ETz & PF to implement
3. The SIG approved the proposal to add in the PC file a statement per PC property, of the sort:

<crm:P04_represents rdf:resource= “Pxx_label_of_respective_property”/>
(see appendix –point G AND ALSO see point F, the highlighted statements)

HW: ETz & PF to implement

4. (point H).
   HW: MD & PF to revisit the implementation guideline for PC properties.
5. (point I). The SIG approved the proposal by PF to not introduce a PC for the inverse directionality of the corresponding property, on the grounds that it would call for both PCx and PCx-I to instantiate the domain of the corresponding Px.1, which would make querying even more complex.
6. (point J). The SIG approved the proposal by PF to start a new issue (640) where to discuss the ontological status of PC properties and the kinds of statements one can make about them.
7. (Point K). The SIG did not approve the proposal by GB to declare PC0_Typed_Property a subclass of E1. The topic relates to the new issue discussed in (point J), above.

Crete, May 2023