Issue 400: CRMGeo: super classes of SP4
Posted by Robert Sanderson on 6/7/2018
In the version 1.2 PDF  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)?
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
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.