Mappings to DCMIMT in GeoSPARQL 1.1 candidate specification

[tombaker]

Nicholas Car, on behalf of the editors of a new candidate
version of GeoSPARQL, has asked DCMI to have a look at the
(non-normative) mappings in the specification to DCMI
Metadata Terms.

The mappings touch on one class, dcterms:Location, and
one property, dcterms:coverage, and refer to the DCMI Box
and DCMI Point encoding schemes.

If any of you have comments about these mappings, please
reply to Nick and to the GeoSPARQL editors
[email protected], preferably by
5 May 2022.

[1] https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#_e_9_dcmi_metadata_terms_dcterms

[tombaker]

Dear DCMI,

You're the publisher of the DCMI Metadata Terms (DCTERMS) [1] to which a
mapping from the new version of GeoSPARQL, 1.1 [2] has been made [3].

There are a couple fo direct ontological term mappings and also a
suggestion for use with various DCMI encoding schemes.

Mappings such as this in GeoSPARQL are only informative and don't affect
the normative content of GeoSPARQL but are thought to be of great interest
to GeoSPARQL users and thus the GeoSPARQL 1.1 editors are interested to
know what you make of the mappings.

GeoSPARQL 1.1 is about to move to the final stages of Open Geospatial
Consortium standards release in about a month (May/June 2022), so there is
still an opportunity for content changes to be made to the standard
version.

If you, or others, are interested in providing feedback on this mapping,
could you please do so by Thursday, 5th of May, 2022? Feedback can be
supplied directly to this email but, preferably, feedback can be supplied
to the GeoSPARQL version control repository online in Issues or as Pull
Requests [4]. Please do feel free to pass this request for feedback on to
anyone else too.

We look forward to any feedback!

Thanks,

Nicholas
on behalf of all the GeoSPARQL 1.1 editors

[1] https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
[2] https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html
[3] https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#_e_9_dcmi_metadata_terms_dcterms
[4] https://github.com/opengeospatial/ogc-geosparql

[tombaker]

Nicholas Car [email protected] - if you want to contact him directly

[nicholascar]

Thanks @tombaker and dear DCMI: any feedback is appreciated!

Please note that GeoSPARQL development continues after this version with version 1.2 is anticipated later this year or early next and all GeoSPARQL Standards Working Group work is public at https://github.com/opengeospatial/ogc-geosparql, so there are opportunities for those interested in semantic spatial data to not just contribute to this mapping but to be involved more deeply in this work if they wish.

[kcoyle]

Hi @nicholascar - for those of us without ISO access, can you give a definition and/or examples of what geo:Feature means? Your document says that it is the "top level feature type" but I'd like to confirm what is meant by "feature". I could guess that "mountain" is a feature - am I on the right track? Is there a standard or preferred list of features?

Thanks.

[nicholascar]

ISO 19101 that "feature" is ultimately inherited from reads:

feature
abstraction of real world phenomena

Note 1 to entry: A feature can occur as a type or an instance. Feature type or feature instance will be used when only one is meant.

So it's "anything". GeoSPARQL doesn't ever mention "feature type" so GeoSPARQL features are all instances.

When looking at the total set of GeoSPARQL ontology relations - topological relations between features, the hasGeometry relation, and its specializations, between features & geometries, and the geometry definition itself, we can understand that "feature" is anything that may have a spatial extent defined (a geometry) or topological relations defined.

So, a mountain could be defined as a feature but so too could be Table Cell X on a page since it could have relations to other table cells ("touches"), rows ("within") or a geometry Row I, Column J etc.

GeoSPARQL is often/mostly (a guess) used for geo spatial data but it has generic classes and properties and may, and is (I know of some instances), used for other kinds of spatial data. Non-geo spatial reference systems are not given in GeoSPARQL other than WKT literals with non-geo CRSes which would have to be and are sometimes defined. The datatype of the geometry serialization you want to use is where you set your geometry system so, for a non-geo table cell spatial reference system, you could have:

ex:TableCellX
  a geo:Feature ;
  geo:sfWithin ex:TableRow3 , ex:Page25 ;
  geo:hasGeometry [
    ex:asTablePos "3:5"^^ex:tablePositionLiteral ;  # {ROW}:{COLUMN}
  ] ;
.