Issue 400: CRMGeo: super classes of SP5
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)?
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.
In the 45th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 38th FRBR – CIDOC CRM Harmonization meeting, the sig reviewed the HW by GH and agreed
- to deprecate SP5 Geometric Place Expression and E47 Spatial Coordinates in favor of E94 Space Primitive.
- To not declare Q9 expressed in terms of [D: (set to) E94 Space Primitive, R: SP4 Spatial Coordination Reference System] a subproperty of a CRMbase class
- To keep Q10 defines place in CRMgeo, but declare it a subproperty of P168i defines place (place is defined by)
- To start a new issue regarding the possible ramifications of declaring E94 Space Primitive a subclass of E41 Appellation and discuss if its place is in CRMbase or CRMgeo (HW: MD)
- To start a new issue on how to phrase that for every property of every extension of the CRM, there either exists a CRMbase property, which they are subproperties of or there doesn’t.
Heraklion, October 2019
In the 50th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 43nd FRBR – CIDOC CRM Harmonization meeting, the SIG resolved to close issue 400 (on the grounds of there being nothing left to do).
Note: issue 469 (that spawned from issue 400) was decided to be merged with 365 in the 45th SIG meeting. The 48th SIG meeting assigned HW to ES, MF, CEO, OE to work on 365, but it has been idle since. FB could be invited to participate.
Issue closed
June 2021