Dear Martin and All, In CRMgeo we specified the relations between CRMgeo classes and GeoSPARQL classes like crmgeo:SP1_Phenomenal_Spacetime_Volume as a subclass of geosparql:Feature . I believe the value of CRMgeo and GeoSPARQL is in making explicit the relations between CRM concepts and OGC concepts. GeoSPARQL is probably the most elaborated formalised conceptual model of the OGC standards and more complex than lots of other other spatial vocabularies/ontologies. It offers quite sophisticated topological relations between its concepts that are based on models of the GIS community.
In regard to encoding geometry expressions it only explicitly offers specific properties for GML (geosparql:asGML) and WKT (geosparql:asWKT), which are both used rather as exchange formats for geometries than directly in GIS systems. For practical reasons it may make sense to store the geometries (if they are points, what is often the case) just in latitude/longitude in WGS 84 like specified in the "Basic Geo (WGS84 lat/long) Vocabulary” (https://www.w3.org/2003/01/geo/) or schema.org (https://schema.org/GeoCoordinates). Also for more complex geometries other encodings than GML and WKT may be more at hand, practical and useful. As the developments of GeoSPARQL are slow to incorporate other serialisations for geometric expressions I believe we need a recommendation/mechanism to specify additional encodings. The recommendation should follow the GeoSPARQL examples/practice, so that we have no problems with the existing GeoSPARQL concepts and are in line with further GeoSPARQL developments. Should we put it as an issue for the next CRM-meeting? Best, Gerald PS: Thank you for your enhanced perspective on the “p7_took_place_at” property. Makes more sense to me now and reflects very much of current encoding practice. From: Martin Doerr <[email protected]<mailto:[email protected]>> Date: Monday 13 August 2018 at 13:21 To: Gerald Hiebel <[email protected]<mailto:[email protected]>>, Robert Sanderson <[email protected]<mailto:[email protected]>>, crm-sig <[email protected]<mailto:[email protected]>> Subject: Re: [Crm-sig] NEW ISSUE: Harmonizing Space Primitive Dear Gerald, Thank you very much for your comment! How would you link GeoSPARQL into CRM RDFS? Would it make sense then to recommend GeoSPARQL as THE form to encode geometry expressions? By the way, the meaning of "p7_took_place_at [ a E53_Place ;" is the actual place of the event OR any wider one. So, "Rangiora, the town" is a good range here, as well as the actual place of birth. If we want to refer to the phenomenal place itself only, we would use the spatial projection "P161 has spatial projection (is spatial projection of)". Best, Martin On 8/6/2018 1:56 PM, Hiebel, Gerald wrote: Dear Martin, Rob and All, Thanks very much for elaborating on the issues related to Space Primitives. I would like to add/emphasis some off the points Rob and Martin made: Properties and Provenance of Declarative Places: I believe Martins approach to relate these relations to the E53 Place (defined by (P168) an E94) and not the E94 is a good choice as the recording of the Properties and Provenance of Declarative Places becomes increasingly important when having multiple geometries (coming from multiple sources and thus multiple methods to create the geometry) that approximate one phenomenal place. For different applications and reasonings I need to know more about the declarative place (Geometry) and its provenance and type. An example: Right now I am working on the integration of several different Gazetteers and I need to record the provenance and type of the geometry in order to make a decision which geometry to use as preferred or for a specific purpose. Formats of serialisation: One goal of CRMgeo was to relate CIDOC CRM to OGC GeoSPARQL and thus make use of the developments and standards of OGC. In OGC GeoSPARQL one goal for further work was to enhance the specific serialisation formats, explicitly stating KML and GeoJson. Unfortunately GeoSPARQL did not evolve quickly, although it is still discussed (https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL) and serialisation is a major issue. Nevertheless GeoSPARQL offers a general property GeoSPARQL:#hasSerialization that allows for encoding in serialisations different to WKT or GML. The type of the encoding would then probably needed to be stated in a P2_has_type of the E53. Another option may be to create specific subproperties of GeoSPARQL:#hasSerialization in a new version of CRMgeo. (please comment) Relationships between geometries: When geometries are treated as declarative Places and in CRMcore as E53 the spatial relationships of CRM are available. Through the linking to GeoSPARQL the topological relations of GeoSPARQL are available as well. In the paper "CRMgeo: A spatiotemporal extension of CIDOC-CRM" (attached, https://link.springer.com/article/10.1007/s00799-016-0192-4) we provided some graphics showing the relations of CRMgeo and GeoSPARQL and in figure 4 and 5 you see that the topological properties of GeoSPARQL are available CRM Places if you need richer topological relations. A comment on the example of Rob: _:rob a E21_Person ; rdfs:label “Rob” ; p98i_was_born [ a E67_Birth ; p7_took_place_at [ a E53_Place ; rdfs:label “Rangiora” ; q11i_approximated_by [ a SP6_Declarative_Place ; p2_has_type <xxx:Geospatial_Bounding_Box> ; rdfs:label “Bounding Box for Rangiora” ; P168_place_is_defined_by “POLYGON((172.565456 -43.285409, 172.622116 -43.285409, 172.622116 -43.323697, 172.565456 -43.323697, 172.565456 -43.285409))” ] ] ] . And further SP6s could be introduced for other approximations, such as centroids, points, exact boundaries, different coordinate systems, etc. I had interpreted the footnote that SP6 would also be collapsed into Place, which I understand not to be the case now. Given that I was only born at one location, the E53 provides the unique reference, and SP6 provides the ability to have different approximations of that location. If only one approximation was needed, then E53 and SP6 could be collapsed, as SP6 is a subclass of E53. (Though that doesn’t seem like a good idea…) E53 provides the unique reference: I would interpret the E53_Place in the example as Rangiora the town and not the spatial projection(P161) of the spacetime volume(E92) of the birth event (E67), which is a much smaller place and unique. The birth place and Rangiora are two distinctive places with the topological relation that one falls within the other. Best, Gerald -- -------------------------------------------------------------- Dr. Martin Doerr | Vox:+30(2810)391625 | Research Director | Fax:+30(2810)391638 | | Email: [email protected]<mailto:[email protected]> | | 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 | --------------------------------------------------------------
