Allignments - Annex E

1.1/spec/00-GeoSPARQL.adoc

@@ -136,6 +136,10 @@ include::17-Annex-B.adoc[]
 
 include::18-Annex-C.adoc[]
 
-include::19-Bibliography.adoc[]
+include::19-Annex-D.adoc[]
+
+include::20-Annex-D.adoc[]
+
+include::21-Bibliography.adoc[]
 
 <<<

1.1/spec/20-Annex-E.adoc

@@ -0,0 +1,276 @@
+= Annex E - Alignments (informative)
+
+== E.0 Overview
+
+This Annex provides alignments of GeoSPARQL to other well known ontologies that are either commonly used with GeoSPARQL or could be.
+
+The prefixes used for the ontologies mapped to in all following sections are given in the following table.
+
+[frame=none, grid=none, cols="1, 6"]
+|===
+| dcterms: | http://purl.org/dc/terms/
+| geo: | http://www.opengis.net/ont/geosparql#
+| geom: | http://geovocab.org/geometry#
+| gn: | https://www.geonames.org/ontology#
+| juso: | http://rdfs.co/juso/
+| locn: | https://www.w3.org/ns/locn
+| pos: | http://www.w3.org/2003/01/geo/wgs84_pos#
+| prov: | http://www.w3.org/ns/prov#
+| rdf: | http://www.w3.org/1999/02/22-rdf-syntax-ns# 
+| rdfs: | http://www.w3.org/2000/01/rdf-schema#
+| sdo: | https://schema.org
+| sosa: | http://www.w3.org/ns/sosa/
+| spatial: | http://geovocab.org/spatial#
+| ssn: | http://www.w3.org/ns/ssn/
+| time: | http://www.w3.org/2006/time#
+|===
+
+== E.1 ISA Programme Location Core Vocabulary (LOCN)
+
+LOCN Source: https://www.w3.org/ns/locn
+
+The LOCN specification provides notes on the use of GeoSPARQL literals (see https://www.w3.org/ns/locn#changes).
+
+|===
+| From Element | Mapping relation | To Element | Notes
+
+| `geo:Feature` | `rdfs:subClassOf` | `dcterms:Location` | LOCN states that `dcterms:Location` "represents any location, irrespective of size or other restriction", thus it is a superclass of `geo:Feature` 
+| `locn:Address` | `rdfs:subClassOf` | `geo:Feature` | Although LOCN indicates no spatial or geometry properties for `locn:Address`, `locn:Address` is clearly some specialized form of a Feature
+| `geo:Geometry` | `owl:equivalentClass` | `locn:Geometry` | The LOCN class "defines the notion of "geometry" at the conceptual level, and it shall be encoded by using different formats", so GeoSPARQL's class is equivalent.
+| `geo:hasGeometry` | `owl:subPropertyOf` | `locn:geometry` | The LOCN property notes say "Depending on how a geometry is encoded, the range of this property may be one of...". GeoSPARQL's property is indicates only a `geo:Geometry` class instances, not a Literal for instnace, so GeoSPARQL's property is clearly more narrowly defined.
+|===
+
+== E.2 WGS84 Geo Positioning: an RDF vocabulary (POS)
+
+POS Source: http://www.w3.org/2003/01/geo/
+
+|===
+| From Element | Mapping relation | To Element | Notes
+
+| `geo:SpatialObject` | `owl:equivalentClass` | `pos:SpatialThing` | Both classes are unrestricted, essentially abstract classes
+| `pos:Point` | `rdfs:subClassOf` | `geo:Geometry` | Via `pos:Point rdfs:subClassOf pos:SpatialThing` but since `pos:Point` usage notes indicate sirect postitioning, it is a form of geometry
+| `pos:Point` | `owl:equivalentClass` | `sf:Point` | 
+| `pos:lat_long` | `rdfs:subPropertyOf` | `geo:hasSerialization` | A special datatype is not indicated for use with this proeprty by POS, unlike GeoSPARQL's `geo:hasSerialization` object literals
+| `pos:location` | `rdfs:subPropertyOf` | `rdfs:hasGeometry` |
+|===
+
+== E.3 Geonames Ontology (GN)
+
+Geonames source: http://www.geonames.org/ontology/documentation.html
+
+|===
+| From Element | Mapping relation | To Element | Notes
+
+| `gn:Feature` | `owl:equivalentClass` | `geo:Feature` |
+| `gn:GeonamesFeature` | `rdfs:subClassOf` | `geo:Feature` | The GN class is defined as "A feature described in geonames database..."
+| `geo:Feature` | `rdfs:subClassOf` | `gn:Class` | The GN class' definition reads "A class of features"
+| `gn:locatedIn` | `owl:equivalentProperty` | `geo:sfWithin` | 
+| `gn:nearby` | `rdfs:subPropertyOf` | `geo:sfDisjoint` | A `gn:nearby` B means A is not within or touching B. The only close SF property is disjoint
+| `gn:neighbour` | `owl:equivalentProperty` | `geo:sfTouches` | 
+|===
+
+== E.4 NeoGeo Vocabulary
+
+NeoGeo Source: http://geovocab.org/ / http://geovocab.org/doc/neogeo/
+
+|===
+| From Element | Mapping relation | To Element | Notes
+
+| `spatial:Feature` | `owl:equivalentClass` | `geo:Feature` |
+| `spatial:C` | `rdfs:subPropertyOf` | `geo:rcc8ec` | Sub proerty not equivalent property since the NeoGeo property has more restrictive domain & range
+| `spatial:DR` | `rdfs:subPropertyOf` | `geo:rcc8dc` |
+| `spatial:EC` | `rdfs:subPropertyOf` | `geo:rcc8ec` |
+| `spatial:EQ` | `rdfs:subPropertyOf` | `geo:rcc8eq` |
+| `spatial:NTPP` | `rdfs:subPropertyOf` | `geo:rcc8ntpp` |
+| `spatial:NTPPi` | `rdfs:subPropertyOf` | `geo:rcc8ntppi` |
+| `spatial:O` | `rdfs:subPropertyOf` | `geo:sfOverlaps` |
+| `spatial:P` | `rdfs:subPropertyOf` | `geo:sfWithin` |
+| `spatial:PO` | `rdfs:subPropertyOf` | `geo:rcc8po` |
+| `spatial:PP` | `rdfs:subPropertyOf` | `geo:sfWithin` |
+| `spatial:PPi` | `rdfs:subPropertyOf` | `geo:sfContains` |
+| `spatial:Pi` | `rdfs:subPropertyOf` | `geo:sfContains` |
+| `spatial:TPP` | `rdfs:subPropertyOf` | `geo:rcc8tpp` |
+| `spatial:TPPi` | `rdfs:subPropertyOf` | `geo::rcc8tppi` |
+| `geom:Geometry` | `owl:equivalentClass` | `geo:Geometry` |
+| `geom:BoundingBox` | `rdfs:subClassOf` | `geo:Geometry` | GeoSPARQL doens't have a BoundingBox class but has a generic Geometry class that is the range of the `geo:hasBoundigBox` property
+| `geom:GeometryCollection` | `owl:equivalentClass` | `geo:GeometryCollection` |
+| `geom:LineString` | `owl:equivalentClass` | `sf:LineString` |
+| `geom:LinearRing` | `owl:equivalentClass` | `sf:LinearRing` |
+| `geom:MultiLineString` | `owl:equivalentClass` | `sf:MultiLineString` |
+| `geom:MultiPoint` | `owl:equivalentClass` | `sf:MultiPoint` |
+| `geom:MultiPolygon` | `owl:equivalentClass` | `sf:MultiPolygon` |
+| `geom:Polygon` | `owl:equivalentClass` | `sf:Polygon` |
+| `geom:Point` | `owl:equivalentClass` | `sf:Point` |
+| `geom:bbox` | - | - | This property relates a Geometry to another Geometry and is thus not equivalent to GeoSPARQL's Feature to Geometry `geo:hasBoundingBox`
+| `geo:hasGeometry` | `rdfs:subPropertyOf` | `geom:geometry` | `geo:hasGeometry` has more restrictve domain
+|===
+
+== E.5 Juso Ontology
+
+Juso Source: http://rdfs.co/juso/
+
+Juso contains mappings to GeoSPARQL but uses `owl:sameAs` which it should instead use `owl:equivalentClass`.
+
+|===
+| From Element | Mapping relation | To Element | Notes
+
+| `juso:SpatialThing` | `owl:equivalentClass` | `geo:SpatialObject` |
+| `juso:Feature` | `owl:equivalentClass` | `geo:Feature` |
+| `juso:Geometry` | `owl:equivalentClass` | `geo:Geometry` |
+| `juso:Point` | `owl:equivalentClass` | `sf:Point` |
+| `juso:geometry` | `owl:equivalentProperty` | `geo:hasGeometry` |
+| `juso:parent` | `rdfs:subPropertyOf` | `geo:sfWithin` |
+| `juso:political_division` | `rdfs:subPropertyOf` | `geo:sfContains` |
+| `juso:within` | `owl:equivalentProperty` | `geo:sfWithin` |
+|===
+
+== E.6 Time Ontology in OWL (TIME)
+
+TIME Source: https://www.w3.org/TR/owl-time/
+
+There are no direct class or property correspondences between GeoSPARQL and TIME however class patterning is similar:
+
+* TIME uses `time:hasTime` to indicate that something has a temporal projection
+* GeoPSARQL uses `geo:hasGeometry` to indicate that a `geo:Feature` has a spatial projection
+
+and
+
+* TIME uses properties such as `time:inXSDDate` to indicate the position of temporal entities on a temporal reference system
+* GeoSPARQL uses properties such as `geo:asWKT` to indicate the position of spatial entities (Geometries) on spatial reference systems
+
+OWL TIME sets no domain for `time:hasTime` thus this property may be used with anything, including a GeoSPARQL `geo:Feature` so that a spati-temporal Feature may be indicated like this:
+
+```turtle
+:flooded-area-x
+    a geo:Feature ;
+    geo:hasGeometry [
+        a geo:Geometry ;
+        geo:asWKT "POLYGON (((...)))"^^geo:wktLiteral ;
+    ] ;
+    time:hasTime [
+        a time:ProperInterval ;
+        time:hasBeginning [
+            time:inXSDDate "..."^^xsd:date ;
+        ] ;
+        time:hasEnd [
+            time:inXSDDate "..."^^xsd:date ;
+        ] ;        
+    ] ;
+.    
+```
+
+In the above example, `:flooded-area-x` is a spatio-temporal Feature that has both a GeoSPARQL spatial projection - a `geo:Geometry` - and a temporal projection - a `time:ProperInterval` which is a specailised form of `time:TemporalEntity`.
+
+Another possible use of TIME with GeoSPARQL is to assign temporality to individual `geo:Geometry` instances. This is allowed given `time:hasTime`'s open domain:
+
+
+```turtle
+:flooded-area-x
+    a geo:Feature ;
+    geo:hasGeometry [
+        a geo:Geometry ;
+        geo:asWKT "POLYGON (((...)))"^^geo:wktLiteral ;
+        time:hasTime [ ... ] ;      
+    ] ;
+.
+```
+
+In contrast to the first example, `:flooded-area-x` is inferred to be a spatio-temporal Feature but since it is the Geometry of `:flooded-area-x` that has a temporality, it is possible to describe other Geometries of `:flooded-area-x` with other temporalities.
+
+
+== E.7 schema.org
+
+schema.org Source: https://schema.org
+
+|===
+| From Element | Mapping relation | To Element | Notes
+
+| `geo:Geometry` | `rdfs:subClassOf` | `sdo:GeoShape` | A GeoShape can various literal geometry representation
+| `sdo:GeospatialGeometry` | `owl:equivalentClass` | `geo:SpatialObject` | Since GeospatialGeometry is the domain of SimpleFeature-like properties and a superclass of GeoShape
+| `sdo:GeoCoordinates` | `rdfs:subClassOf` | `geo:Geometry` | GoCoordinates uses direct lat, long, elevation etc properties to indicate position, not a while geometry serialization but it is nevertheless a form of a Geometry
+| `sdo:geo` | `rdfs:subPropertyOf` | `geo:hasGeometry` |
+| `sdo:geoCoveredBy` | `owl:equivalentProperty` | `geo:ehCoveredBy` | 
+| `sdo:geoCovers` | `owl:equivalentProperty` | `geo:ehCovers` | 
+| `sdo:geoCrosses` | `owl:equivalentProperty` | `geo:sfCrosses` | 
+| `sdo:geoDisjoint` | `owl:equivalentProperty` | `geo:sfDisjoint` | 
+| `sdo:geoEquals` | `owl:equivalentProperty` | `geo:sfEquals` | 
+| `sdo:geoIntersects` | `owl:equivalentProperty` | `geo:sfIntersects` | 
+| `sdo:geoOverlaps` | `owl:equivalentProperty` | `geo:sfOverlaps` | 
+| `sdo:geoTouches` | `owl:equivalentProperty` | `geo:sfTouches` | 
+| `sdo:geoWithin` | `owl:equivalentProperty` | `geo:sfWithin` | 
+| `sdo:Landform` | `rdfs:subClassOf` | `geo:Feature` |
+|===
+
+
+== E.8 Semantic Sensor Network Ontology (SSN)
+
+SSN Source: https://www.w3.org/TR/vocab-ssn/
+
+SSN and GeoSPARQL do not cover overlapping concerns directly and therefore there are no direct class or property correspondences between them, however SSN provides advice on the use of GeoSPARQL for location, 
+see Section 7.1 (https://www.w3.org/TR/vocab-ssn/#x7-1-location):
+
+> GeoSPARQL ... provides a flexible and relatively complete platform for geospatial objects, that fosters interoperability between geo-datasets. To do so, these entities can be 
+declared as instances of geo:Feature and geometries can be assigned to them via the geo:hasGeometry property. In case of classes, e.g., specific features of interests such as 
+rivers, these can be defined as subclasses of geo:Feature.
+
+
+== E.9 DCMI Metadata Terms (DCTERMS)
+
+DCTERMS Source: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
+
+|===
+| From Element | Mapping relation | To Element | Notes
+
+| `geo:Feature` | `rdfs:SubClassOf` | `dcterms:Location` | A Location is a "A spatial region or named place."
+| `dcterms:coverage` | - | - | See note below table
+| `dcterms:spatial` - | - | Since coverage is a sub property of `dcterms:coverage`
+|===
+
+`dcterms:coverage` is extremely generic - "The spatial or temporal topic of the resource, spatial applicability of the resource, or jurisdiction under which the resource is relevant." - but DCTERMS indicates its range includes a `dcterms:Location`, so it is a property for indicating a `geo:Feature`, not a `geo:Geometry` and for which GeoSPARQL has no equivalent. Often, `dcterms:coverage` is used to indicate a spatial extent such as a bounding box. GeoSPARQL now provides a `geo:hasBoundingBox` property, so such a property could be used if a Bounding Box is wanted to be indicated.
+
+DCTERMS-related geometry literals, such as the _DCMI Box Encoding Scheme_footnote:[https://www.dublincore.org/specifications/dublin-core/dcmi-box/] and the _DCMI Point Encoding Scheme_footnote:[https://www.dublincore.org/specifications/dublin-core/dcmi-point/] 
+could be indicated as GeoSPARQL geometry literals if a literal datatype were created for each. For example, the _DCMI Point Encoding Scheme_ example of "The highest point in Australia" with the literal value 
+`east=148.26218; north=-36.45746; elevation=2228; name=Mt. Kosciusko` might be encoded in GeoSPARQL like this:
+
+```turtle
+:mt-kosciusko
+    a geo:Feature ;
+    geo:hasGeometry [
+        a geo:Geometry ;
+        geo:hasSerialization "east=148.26218; north=-36.45746; elevation=2228; name=Mt. Kosciusko"^^ex:dcmiPoint ;        
+    ] ;
+.
+```
+
+
+== E.10 The Provenance Ontology (PROV)
+
+PROV Source: https://www.w3.org/TR/prov-o/
+
+From GeoSPARQL's point of view, PROV is an "upper" ontology - one dealing with more abstract concepts - and only one of PROV's three main classes of object, `Entity`, `Activity` & `Agent` has direct relations to GeoSPARQL classes: `Entity`.
+
+|===
+| From Element | Mapping relation | To Element | Notes
+
+| `geo:SpatialObject` | `rdfs:subClassOf` | `prov:Entity` | All SpatialObjects fit within PROV's Entity's definition: "An entity is a physical, digital, conceptual, or other kind of thing with some fixed aspects; entities may be real or imaginary." 
+| `geo:Feature` | `rdfs:subClassOf` | `prov:Location` | A Location "...can be an identifiable geographic place (ISO 19112), but it can also be a non-geographic place such as a directory, row, or column" so seem to be wider in scope than GeoSPARQL's Feature although a Feature could indeed be something such as a "directory, row, or column"
+| `prov:atLocation` | - | - | The PROV property indicates a `prov:Location`, so perhaps a `geo:Feature`, but GeoSPARQL has no property to indicate a `geo:Feature`
+|===
+
+Derivative relations between GeoSPARQL objects could be modelled using PROV, for instance a BoundingBox may be indicated as haveing been derived from a Polygon like this:
+
+```turtle
+:bounding-box-y prov:wasDerivedFrom :polygon-x .
+```
+
+== E.11 WikiData
+
+== E.12 OpenStreetMap
+
+== E.13 German Building Types (Timo)
+
+INSIPRE building types...
+
+== E.14 GRM Geo
+
+https://cidoc-crm.org/crmgeo/