Consider adding geospatial relations echoing the predicates from DE-9IM

[danbri]

• https://en.wikipedia.org/wiki/DE-9IM has a list of topological relationship types between 2d-geometrically described places
  • "The Dimensionally Extended nine-Intersection Model (DE-9IM) is a topological model and a standard used to describe the spatial relations of two regions (two geometries in two-dimensions, R2), in Geometry, Point-set topology, Geospatial topology, and fields related to computer spatial analysis. "
• http://schema.org/GeoShape is the closest schema.org currently gets to having a type for geo-spatial geometry.

It would be useful (as discussed 2016-09-19) at W3C/OGC Spatial Data on the Web WG meeting in Lisbon if these could be used within schema.org.

[danbri]

Suggest:

* geospatiallyEquals
* geospatiallyDisjoint
* geospatiallyTouches
* geospatiallyContains
* geospatiallyCovers
* geospatiallyIntersects
* geospatiallyWithin
* geospatiallyCoveredBy 
* geospatiallyCrosses 
* geospatiallyOverlaps

with text based on Wikipedia's summaries, and allowing each to link either geometries or places.

[danbri]

Ok I have made a FIRST CUT with DELIBERATE MISTAKES for discussion in Schema.org and W3C circles.

Further things to consider:

• I included a GeospatialGeometry definition to avoid editing the existing deployed GeoShape (which could become a subtype)
• It tries to make these relations applicable both at the geometry and at the place level. Of all the relations, "equals" is the hardest to consider without concrete geometry.
• Text is based heavily on Wikipedia, no proper citation to underlying standards yet.
• We haven't got inverseOf relations or subPropertyOf relations yet (although schema.org understands these). Also we don't have "symmetric property" in schema.org's meta model yet, although that could be useful here.
• It was suggested that similar temporal relations could be added (see Working Draft)

[danbri]

http://pending.webschemas.org/GeospatialGeometry /cc @philarcher1 @6a6d74

[rvguha]

Who is this vocab targeted at? Who will mark things up and who will use it?

guha

[danbri]

It's part of an effort to get existing professional geospatial systems to expose modern Web-based views rather than just GIS-specific standards. Those tools support such relations out of the box. (stopgap reply for now, typing on a phone)

[thadguidry]

Not sure if this is in another issue somewhere but.... We'll also need to support a Geo Feature class (a code or text string) to hold things not just name-like 'pond', 'mountain', 'orchard', but also code-like 'PND', 'MT', 'ORC'. (this is not Geonames - USA specific, but a global Geo Feature class) NOTED: additionalType could actually be utilized for handling this on GeoCoordinates and GeoShape, but I think all the GIS folks might runaway from Schema.org rather than embrace us. References: https://www.wikidata.org/wiki/Property_talk:P2452 http://www.geonames.org/export/codes.html https://data.gov.uk/dataset/register-of-geographic-codes-apr-2016-uk http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Associating_Geonames_with_other_features

[rvguha]

Ok, sounds like a good idea.

guha

[danbri]

I have heard rumour of an application that may use this. In the meantime the names are needlessly verbose, let's just write them as 'geoXyz' instead of 'geospatiallyXyz'. I'll make that fix directly, and do not plan to preserve a history for the old property names unless someone speaks up here and says they're important.

[RichardWallis]

Implemented in release 3.5

[nicholascar]

@danbri @rvguha please note that GeoSPARQL 1.1 is in drafting right now and that you might like to either influence that work with lessons from shcema.org or adopt patterning: https://github.com/opengeospatial/ogc-geosparql

[danbri]

I still don’t really understand why there needs to be a version of sparql for geo. I understand that engines might optimise, ...

…

On Sun, 7 Mar 2021 at 11:25, Nicholas Car ***@***.***> wrote: @danbri <https://github.com/danbri> @rvguha <https://github.com/rvguha> please note that GeoSPARQL 1.1 is in drafting right now and that you might like to either influence that work with lessons from shcema.org or adopt patterning: https://github.com/opengeospatial/ogc-geosparql — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABJSGMOINUVWNIWBS5LKITTCNPEDANCNFSM4CQCRXWA> .

[nicholascar]

I still don’t really understand why there needs to be a version of sparql for geo.

Two main reasons:

1. to support processing of complex geometry objects in RDF given as literals, such multi-polygons.

To get reasonable results when using complex geometries, or even geometries using different reference systems, you need to hand off operations to spatial code libraries, so GeoSPARQL extends SPARQL functions with common spatial operations like sfWithin to calculate whether one geometry is inside another. Implementers then implement sfWithin using common tools.

2. to provide a powerful Feature/Geometry representation ontology

schema.org does some spatial modelling but doesn't cater for:

• well-known spatial literal formats (KML, GeoJSON, WKT)
• complex geometries (multi-polygons, mixed geometries)
• multiple coordinate reference systems

Pretty much all common spatial libraries do handle these things so GeoSPARQL allows for their representation.

[nicholascar]

Just a follow-up note here: GeoSPARQL's functions are now widely implemented in mainline RDF databases (Jena, GraphDB, MArcLogic, RDF4J, Triply, etc.) and appears to be the only widely-used sophisticated handing of spatial operations and representations of relationships in the Semantic Web, so I again recommend alignment/adoption of it by schema.org.

Note also that the RDFLib are now implementing RDF<->GeoJSON conversions by way of GeoSPARQL mappings, so we should be able to have RDF data with lots of properties, the spatial elements of which can easily by put out into GeoJSON for current generation web aps, by (one of the) low-level RDF toolkits.