Dear all, > 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/ <https://www.w3.org/2003/01/geo/>) or > schema.org (https://schema.org/GeoCoordinates > <https://schema.org/GeoCoordinates>). Also for more complex geometries other > encodings than GML and WKT may be more at hand, practical and useful.
While WKT is great for many reasons (compact, case insensitive, cross-domain support..) It seems to me that a quite large set of heritage institutions encode the geographical coordinates only using latitudine/longitude, therefore the basic geo would better fit their needs. What seems to me a viable option is to recommend the use of WKT or GML (as in “please use at least one of these in combination with other encoding"), and still be able to accomodate other formats such as GeoJson, KLM, Geohash etc. In our case we use ISA Programme Location Core vocab and Basic Geo to express the latitude and longitude: <https://collection.example.com/resource/P00006626> a crm:E53_Place ; crm:P168_place_is_defined_by "POINT (9.1232696 45.2503146)"^^geo:wktLiteral ; locn:geometry [ geo:lat "51.477811" ; geo:long "-0.001475" ] . but would be great to have the possibility to define both the WKT and lat/long directly with CRM. Best, Nicola > On 17 Aug 2018, at 11:23, Hiebel, Gerald <[email protected]> wrote: > > 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/ <https://www.w3.org/2003/01/geo/>) or > schema.org (https://schema.org/GeoCoordinates > <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 >> <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 >> <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 > <http://www.ics.forth.gr/isl> | > -------------------------------------------------------------- > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig
