Martin, all, I feel that the implications of your footnote are somewhat problematic. I agree overall with the clarifications but, SP4/SP5 add extra value.
In particular: · Use of literals prevents the association of additional information with the value, other than the custom datatype, especially: o Associating P2_has_type is enormously useful to give guidance on the usage for the particular geometry. Types might distinguish simple bounding boxes for user interfaces from very accurate geo-political boundary data that would be useful for calculations. Or coastlines from other boundaries. Preferred from alternative. o The source / provenance of the data is very important. Is this a bounding box that someone threw together, or data that is provided by an established authority? o There are more formats than just WKT and GML. GeoJSON and KML are very frequently used, and there are many more besides those. Not all formats have the capacity to embed the reference system within the literal. o Relationships between geometries are also useful, such as partitioning. · Literals can only be embedded within the serialized graph, rather than referenced externally. This means that the coastline of New Zealand (a 100+ mb file) would need to be embedded within the description of the E53 Place, rather than being referenced. Conversely a resource can have a URI and optionally a value, providing flexibility within a single model. · Relying on subproperties to manage the data type runs into the extensibility problem above. We would need to continually create new properties when there are new data types. A cognate situation is rdfs:label vs E41 Appellation – label is great if you have very simple data, but E41 provides clear advantages when you want to do more than just display a string to a user. Having a single literal (be it a label or geometry) is great for the simple cases, but rdfs:label does not obviate the need for E41. Nor should P168 obviate the need for a richer spatial system. Rob From: Crm-sig <crm-sig-boun...@ics.forth.gr> on behalf of Martin Doerr <mar...@ics.forth.gr> Date: Thursday, August 2, 2018 at 8:55 AM To: crm-sig <Crm-sig@ics.forth.gr> Subject: [Crm-sig] NEW ISSUE: Harmonizing Space Primitive Dear All, I have just finished a draft of the section "recording space" of the guideline "Expressing the CIDOC CRM in RDF (https://docs.google.com/document/d/1zCGZ4iBzekcEYo4Dy0hI8CrZ7dTkMD2rJaxavtEOET0/edit#<https://docs.google.com/document/d/1zCGZ4iBzekcEYo4Dy0hI8CrZ7dTkMD2rJaxavtEOET0/edit>): The recommended datatypes of RDF1.1 do not contain datatypes for describing geometric entities on the surface of earth. On the other side, they become increasingly important, and the CIDOC CRM version 6.2 on defines E94 Space Primitive, subclass of: E59 Primitive Value, as: “This class comprises instances of E59 Primitive Value for space that should be implemented with appropriate validation, precision and references to spatial coordinate systems to express geometries on or relative to earth, or any other stable constellations of matter, relevant to cultural and scientific documentation. An E94 Space Primitive defines an E53 Place in the sense of a declarative place as elaborated in CRMgeo (Doerr and Hiebel 2013), which means that the identity of the place is derived from its geometric definition. This declarative place allows for the application of all place properties to relate phenomenal places to their approximations expressed with geometries. Definitions of instances of E53 Place using different spatial reference systems always result in definitions of different instances of E53 place approximating each other. It is possible for a place to be defined by phenomena causal to it, such as a settlement or a riverbed, or other forms of identification rather than by an instance of E94 Space Primitive. Any geometric approximation of such a place by an instance of E94 Space Primitive constitutes an instance of E53 Place in its own right, i.e., the approximating one. Instances of E94 Space Primitive provide the ability to link CRM encoded data to the kinds of geometries used in maps or Geoinformation systems. They may be used for visualisation of the instances of E53 Place they define, in their geographic context and for computing topological relations between places based on these geometries. E94 Space Primitive is not further elaborated upon within this model. Compatibility with OGC standards are recommended.” These standards currently do not have a common form comprising all others. Further, geometries defined with respect to particular object shapes, such as rotationally symmetric ones, are possibly open ended. Therefore we define in the CRM RDFS the range of properties that use E94 Space Primitive in the definition of the CRM as rdfs:Literal, and recommend the user to instantiate it with adequate XML datatypes. These are for the surface of Earth “ogc:gmlLiteral” or “geo:wktLiteral”. In the current version of the CIDOC CRM, only the property “P168 place is defined by (defines place)” has range E94 Space Primitive. Since any instance of E94 Space Primitive identifies unambiguously an instance of E53 Place by a symbolic expression, E94 Space Primitive must logically be regarded as a subclass of E41 Appellation, regardless whether this can be expressed in RDFS or OWL. See below for the relationship between datatypes an E41 Appellation. In a footnote I make the argument that: "The concepts E47 Spatial Coordinates,crmgeo: SP5 Geometric Place Expression, crmgeo:Q10 defines place and P168 place is defined by (defines place) need to be revised soon. E94 Space Primitive should replace E47 Spatial Coordinates and SP5 Geometric Place Expression. P168 place is defined by (defines place) should replace crmgeo:Q10 defines place. It may be useful in the CRM RDFS to specify two subproperties of P168, one having as range “geo:wktLiteral” and another “ogc:gmlLiteral”. Best, Martin -- -------------------------------------------------------------- Dr. Martin Doerr | Vox:+30(2810)391625 | Research Director | Fax:+30(2810)391638 | | Email: mar...@ics.forth.gr<mailto:mar...@ics.forth.gr> | | Center for Cultural Informatics | Information Systems Laboratory | Institute of Computer Science | Foundation for Research and Technology - Hellas (FORTH) | | N.Plastira 100, Vassilika Vouton, | GR70013 Heraklion,Crete,Greece | | Web-site: http://www.ics.forth.gr/isl | --------------------------------------------------------------
