Issue 400: CRMGeo: super classes of SP5

Starting Date: 
2018-07-06
Working Group: 
3
Status: 
Open
Background: 

Posted by Robert Sanderson on 6/7/2018

In the version 1.2 PDF [1] on page 10, it says that SP5 Geometric Place Expression is a subclass of E94 Space Primitive. This allows it to be referenced using P168 place is defined by.

However in the RDF encoding for CRM core, E94 is mapped to rdfs:Literal which cannot also be used as a subclass with E73 and E47. This is reflected in the RDF for CRMGeo by simply not including E94 as a subclass.

So … the abstract documentation and the RDF mapping are significantly inconsistent. Can an SP5 be used as the object of a P168 relationship (and hence the mapping should be updated to include it) or not (and hence the documentation should be updated to remove it)?

Current Proposal: 

Posted by Gerald Hiebel on 12/7/2018

Dear Rob, thanks very much  for pointing out the issue, we will look into it. 

Posted by Robert Sanderson on 12/7/2018

Many thanks, Gerald!

In the mean time we’re using P1 is identified by to relate the Place to the SP5 (apologies for the typo in the subject line!), based on it being an E47 Spatial Coordinates, a subclass of E41 Appellation.  This seems defensible … but a more precise definition of the semantics would be greatly appreciated to know if it’s definition (P168) or identification (P1).

 

Posted by Martin on 12/7/2018

Dear Rob,

I am in a process to elaborate with Richard in more details the relationships between rdfs:Literal , E59 Primitive Value and E41 Appellation.
We hope to have a viable text by the next CRM-SIG meeting.

The issue is that RDF 1.1 itself breaks the uniformity of a class system overloading rdfs:Literal with xsd datatypes. The latter in turn cannot be described by adequate superclasses in RDF, which is a logical shortcoming of RDF and not a question of the CRM.

We have a need
A) to represent simple appellations by a Literal or alternatively by a URI  as formal instances of E41 Appellation when more has to be said about it.
B) To represent all subclasses of E59 Primitive Value by various xsd datatypes or even other custom datatypes.

Theoretically, time primitives, space primitives and spacetime primitives denominate "loci" in the natural spacetime. As such, they are indeed Appellations for such loci and simultaneously "compactified" instructions how to verify the locus by distances relative to absolute reference points. The latter makes them "primitive values".

We can identify rdfs:Literal with E59 Primitive Value, quite in the same sense in which RDF1.1 does not make a distinction between literals that identify a thing or spacetime locus and literals that do other things.

However, the mapping between xsd datatypes and Primitive Values is not one-to-one. The xsd datatypes systematically represent smaller mathematical spaces. For SP5, we have used instances such as gmlLiteral or wktLiteral in projects.

Following these considerations, we should regard E94 Space Primitive a subclass of E44 Place Appellation, and declare E47 as obsolete.

Since RDF is "tolerant" to typing violations and does itself not provide a binding between specific xsd datatypes and respective property semantics, if (!!) I am right,  the question is, how best to connect overloadings of rdfs:Literal with a CRM compatible class system.

The semantic gap has to be controlled at data entry time and be interpreted correctly at query time, basically a task which we should not invent, but which people that have implemented GIS-enabled triple stores should have done before.
We'll revise this things in the near future.

In other words, P168 should have range rdfs:Literal, and only be used with the respective data types that qualify as SP5 by their nature.

The fact, that the Literal instantiated as a range of P168 is an E94, can be inferred automatically from the fact that P168 has been used, assuming not been abused.

Opinions?

In the 42nd joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 35th FRBR - CIDOC CRM Harmonization meeting, discussing about super properties of SP5, we decided that space primitive is a geometric place expression. Thus, we changed the subclass definition of SP5 

From

SP5 Geometric Place Expression

Subclass of:  E73 Information Object, E47 Spatial Coordinates,

To

SP5 Geometric Place Expression, 

Subclass of:  Geometry, E94 Space Primitive

Also we concluded that we need the shortcuts in CRMgeo for the supeproperties of CRMgeo properties: These are:
(a) approximate by geometry, (b) falls within geometry, (c) includes geometry
We also decided that:
• Q10 is  obsolete
• CRMbase properties declared in the extension must be included in CRMgeo
• in an implementation gulideline should be included that E94 should take care of SP5
• taking the occasion of Francesco  commentary about the notation of quantification in the introduction that it should be compatible with the UML, the sig assigned to Steve to review to the introduction of CRM the guidelines that users of the crm should follow and to add some comments about the provenance of this notation.
It was suggested that the implementation guidelines for E94 (Doerr & Light, Implementing the CIDOC Conceptual Reference Model in RDF) should transfer to SP5 as well. This has been assigned to GH.
SS was assigned to find a suitable place in the introduction of the crm in order to point to the Implementation guidelines, so that the users of the crm will benefit from them.

Berlin, November 2018
 

Posted by Gerald Hiebel on 12/3/2019

Dear all,
I attached a word document with a proposal for further steps after reading through the various issues regarding
E94 and the actual google doc "Implementing the CIDOC Conceptual Reference Model in RDF”
(https://docs.google.com/document/d/1NdrWpzo7EFChryh4Qg-Ue8WLvnwejHx20eiwdJuZEck/edit#heading=h.inws0ne22in3).

I included Günther in the conversation, as we discussed issues how a new CRMgeo version could look like.
If we get an agreement in one of the next CRMSIG meetings I would write it up in a new CRMgeo version.

Meetings discussed: