Implementing .2 properties in RDF

The issue closely relates to Issue 588 (the policy for implementing .1 properties in RDF) and is affected by any decisions therein. It is listed as a separate issue, only to better keep track of things. 

The outcome of the present issue (and 588 of course) are expected to have a bearing on the reorganization of property definitions in CRMbase and extensions and should be taken into consideration upon redesigning the templates for CRM extensions (see here), but also the template used for CRMbase.  

Post by Gerald Hiebel (24 April 2023)

Dear all,

we discussed CRMarchaeo and are going to make a proposel for a new version in the next CRM-SIG.

In the discussion we encountered the issue of not having yet a policy/strategy for implementing .2 properties, which means properties related to properties.

We have one of them in CRMarchaeo:

AP13.2 justified by (is justification of)

Domain:                AP13 has stratigraphic relation to

Range:                   AP11 has physical relation to

Scope note:           This property identifies the type of physical relation that was used to justify the type  of stratigraphic relation assigned to the relation between two A5 Stratigraphic Modification events. Physical

relations of “above” or “fills” may justify the stratigraphic relation type “after”. Figure 7 gives a graphical representation and Figure 6 shows an example.

I would ask to either create a new issue for the implementation of .2 properties or include the discussion in the existing issue 588 as the strategy should be the same for .1 and .2 .

Whatever you think appropriate.

Kind regards,

Gerald

Post by Pavlos Fafalios (2 May 2023)

Dear Gerald, all,

I think we can follow the same reification approach as we do for the .1 properties. 
In this case, we just need to provide the property classes of the domain and range properties of AP13.2, i.e.: 
    PC_AP13_has_stratigraphic_relation_to    
and   
    PC_AP11_has_physical_relation_to

Then, here is a (draft) example of RDF triples that make use of these constructs:
 
***********************************************************
<PC_AP13_has_stratigraphic_relation_to>
   a  <PC0_Typed_CRM_Property> .
<PC_AP11_has_physical_relation_to>
   a  <PC0_Typed_CRM_Property> .

<subject1> 
   <AP13_has_stratigraphic_relation_to> <object_1> .
<pc_ap13_instance> 
   a <PC_AP13_has_stratigraphic_relation_to> ;
   <P01_has_domain> <subject1> ;
   <P02_has_range> <object1> . 

<subject2> 
   <AP11_has_physical_relation_to> <object_2> .
<pc_ap11_instance> 
   a <PC_AP11_has_physical_relation_to  > ;
   <P01_has_domain> <subject2> ;
   <P02_has_range> <object2> . 

<pc_ap13_instance>
     <AP13.2 justified by> <pc_ap11_instance>
***********************************************************

But there are also other approaches for implementing this, such as using named graphs, or the standard RDF reification method (i.e. using rdf:subject, rdf:object, etc.), or RDF-start (I think). 

Please correct me if I have misunderstood something! 

Best regards,
Pavlos
 

Post by George Bruseker (2 May 2023)

Dear both,

I am more and more swayed by Francesco's argument that every PC property class hides an actual ontological entity which we are failing to properly model. 

I think in principle what Pavlos proposes is syntactically correct and insofar as we stay on PC here that is probably the way to go.

That said, in this case we are actually building PCs on PCs essentially because we want to avoid saying that there is a state that exists or existed between two things and held for some time. Perhaps in a later version of archaeo if we are able to accept that states do exist we could significantly simplify this model by having real state classes for physical relations etc. This I just forward for thought. The present modelling completely depends on PC properties and there would be no good reason to pause the present development path of CRMArchaeo which is reaching a stable point, by presently changing course. We can maintain the state we presently have.

Best,

George

Post by Pavlos Fafalios (2 May 2023)

Dear George,

About the PC constructs and, in general, if this is the best method to implement CRM's properties of properties in RDF (considering Francesco's email and arguments): I was not involved in the initial discussions, when the SIG first introduced the idea of property classes for implementing the
.1 properties of CRM (I see they were first introduced in Jan 2015 for crm version 6.0).

My suggestion is to first close issue 588 (since we have already voted for most of its sub-issues) and then open a new issue for discussing this aspect.

Thoughts?

Best,
Pavlos

Post by George Bruseker (2 May 2023)

Hi Pavlos,

I definitely agree to keep following the PC modelling pattern at this moment and your RDF description above looks correct to me.

My point was a theoretic one. The spirit should be to come to a conclusion on this issue given current premises. My comments for posterity not the present :)

Or perhaps as Gerald implied the .2 as a method could be a separate issue, while this particular implementation could just go ahead as is.

Cheers,

George

Post by Martin Doerr (2 May 2023)

Dear George,

I agree that often links with properties simplify a more complex entity. There are complex questions of the philosophical distinction between relationships and the entities that exist by their own. E-R model and RDFS differ considerably in this respect. Regarding the question of "state", I think the use of the term itself suggests a simplicity that does not exist. We have discussed extensively concepts of state and situation, without coming to a clear unique definition of what it can mean. In the extreme, we can regard any property instance as a kind of "state".

I see the question more practical, to model all these intermediate things explicitly as distinct, in a proactive way,  would need a lot of effort, without a clear demand. Also, there is the question, where to stop the intermediate of the intermediate of the intermediate entity. With respect to the statigraphic relations below, I do not agree that there are hidden entities. Simply, I regard this "directed correspondence" construct to be of /epistemic /nature, and it is missing as primitive in the KR languages we use.

All the best,

Martin

Post by Gerald Hiebel (4 May 2023)

Dear Pavlos and all,

Pavlos thank you very much for the proposal of the formal approach for the .2 PC classes for CRMarchaeo.

As I never worked with the PC classes this helps a lot for the issue raised in the CRMarchaeo group, that we never formalised .2 properties.

As for the discussion that followed I find it very interesting and it will need further thinking.

Regarding implementation I hope to test an approach (combining) RDF star and named graphs.

RDF star can implement .2 properties, I testet that, but I did not test SPARQL star yet to see how the query options look like.

Anybody interested in exchanging experiences, thoughts, I am very grateful.

Best,

Gerald