Add 'T' and 'L' as new optional coordinates in WKT literals

[mjovanovik]

We propose an enhancement of the modifiers available in WKT literals with two additional optional coordinates, named T and L, that could be used in the following manner:

• T should be used for the temporal aspect of the geometry, i.e. a timestamp of a geometry denoting an additional dimension.
• L should be used for specifying the level of detail (zoom level, granularity or scale), as an additional dimension.

The rationale behind T is to have the ability to add a time dimension to a geometry, which can be used in various scenarios, such as defining the time the geometry came into existence. This is especially important when dealing with traffic data on a map, for instance, where a vehicle position has a time dimension as well.

The rationale behind L is to have the ability to determine the importance of a geometry when displaying it on a map, or returning it as part of a SELECT query. One way to do this is to denote the "level of detail" for a geometry, as an integer, which will be used in the calculations which determine whether the geometry should be selected for the current scale, or not.

These two optional modifiers should be treated in the same way as Z and M, thus any geometry could have them specified. For example, a point could be represented from 2D to 6D, all depending on which modifiers are present:

• 2D: POINT(X Y)
• 3D: POINTZ(X Y Z), POINTM(X Y M), POINTT(X Y T), POINTL(X Y L)
• 4D: POINTZM(X Y Z M), POINTZT(X Y Z T), POINTZL(X Y Z L), POINTMT(X Y M T), POINTML(X Y M L), POINTTL(X Y T L)
• 5D: POINTZMT(X Y Z M T), POINTZML(X Y Z M L), POINTZTL(X Y Z T L), POINTMTL(X Y M T L)
• 6D: POINTZMTL(X Y Z M T L)

This also applies to other geometries (LINESTRING, POLYGON, etc...) in a similar way.

Examples

Example 1. If the T modifier is introduced, we can use a POINTT type to add a timestamp for a geometry directly in the WKT literal:

<#p0> geo:hasGeometry <#p0_g>.
<#p0_g> geo:asWKT "POINTT(12.27 51.32 2017-09-03T12:48:11Z)"^^geo:wktLiteral.

instead of using a POINT type with an additional property (hasTimestamp) for time.

<#p0> geo:hasGeometry <#p0_g>.
<#p0_g> geo:asWKT "POINT(12.27 51.32)"^^geo:wktLiteral.
<#p0> :hasTimestamp "2017-09-03T12:48:11Z"^^xsd:dateTime.

Example 2. We can have a similar situation with a 3D geometry which needs to have a time dimension as well, with the POINTZT type:

<#p0> geo:hasGeometry <#p0_g>.
<#p0_g> geo:asWKT "POINTZT(12.27 51.32 120 
2017-09-03T12:48:11Z)"^^geo:wktLiteral.

instead of using a POINTZ type with an additional property (hasTimestamp) for time.

<#p0> geo:hasGeometry <#p0_g>.
<#p0_g> geo:asWKT "POINTZ(12.27 51.32 120)"^^geo:wktLiteral.
<#p0> :hasTimestamp "2017-09-03T12:48:11Z"^^xsd:dateTime.

Example 3. We can combine the time and level of detail information within a WKT literal using the POINTZTL type:

<#p0> geo:hasGeometry <#p0_g>.
<#p0_g> geo:asWKT "POINTZTL(12.27 51.32 120 
2017-09-03T12:48:11Z 6)"^^geo:wktLiteral.

instead of using a POINTZ type with additional properties (hasTimestamp, scale) for time and level of detail, respectively.

<#p0> geo:hasGeometry <#p0_g>.
<#p0_g> geo:asWKT "POINTZ(12.27 51.32 120)"^^geo:wktLiteral.
<#p0> :hasTimestamp "2017-09-03T12:48:11Z"^^xsd:dateTime.
<#p0> :scale "6"^^xsd:integer.

Background

Our team at OpenLink Software has been working on 5D geospatial support in its Virtuoso product, as part of the SAGE: Semantic Geospatial Analytics project.

As part of our work, we introduced and successfully used these WKT and GeoSPARQL enhancements, as we outlined in our Deliverable 4.2 "Prototype verifying 5D Geospatial support in Virtuoso".

[mathib]

Hi, this is an interesting proposal to add more metadata concerning geometry. I think the time aspect has some overlap with extension proposal 13 in white paper clause 4?

However, I have some questions/concerns:

• as far as I understand, the proposal would mean that the Simple Features Access (SFA) standard defining WKT has to be updated? If that succeeds, a set of terminology should be prepared to allow spatiotemporal queries in combination with level of detail, i.e. an extension of GeoSPARQL (possibly inspired by the spatiotemporal querying possibilities of stSPARQL)?
• several geosparql extension proposals ask to widden the scope of GeoSPARQL to other geometry schemas than WKT and GML (white paper clause 4 extension proposals 8, 9, 11, 18). Instead of adjusting each individual geometry schema to support temporal and/or LOD values, it might be more straightforward to define a GeoSPARQL metadata vocabulary that can be interpreted by the SPARQL processors? This would be closer to the "original" way of modeling things as you mention in your examples by using :hasTimeStamp and :scale, but has the advantage that it can be applied to geometry of any geometry schema.
• small side note: the metadata expressed using dedicated RDF/OWL properties (e.g. :hasTimeStamp and :scale) should probably be connected to the geometry node, i.e. <#p0_g> instead of <#p0>as it concerns the geometry and not the thing that's described by the geometry?

Would be happy to discuss this further! You might have good reasons (e.g. readability, efficiency, etc.) to define time and LOD inside the RDF literal as part of the WKT geometry description that should be discussed here :-)

[mirkospasic]

Hi, me and Milos worked together on this deliverable, so I can answer on some questions, but basically all the answers are 'yes'. :-)

Yes, you are totally right, our proposal regarding time aspect is exactly the same as specified in white paper 4, proposal 13. SFA standard should be updated, but I'm not the right person to propose a set of terminology. IMHO, it seems that defining a GeoSPARQL metadata vocabulary could work, but not totally sure. You are right as well about the properties :hasTimeStamp and :scale, they should be predicates of <#p0_g>.

[jabhay]

Created MoSCoW poll

[FransKnibbe]

I have just voted W, which I'd like to explain:

• In general, I think WKT literals in the current GeoSPARQL spec are overloaded as they are. I would rather see them slimmed down (i.e. remove the CRS bit) than expanded further.
• I think that for most knowledge domains (excluding cosmology and quantum physics), space and time can be considered as being independent. So I think it best to keep ontologies for space and time nicely separated.
• Of course it should be possible to use time stamps with geometry, but I think it would be better to use separate properties for that purpose, which would also make clear what exactly is timed. For instance, a set of coordinated could be measured in the field and be transformed to another CRS at different times.
• A way to specify spatial resolution is absolutely required, but I think it would be much better to model that as a separate property of geometry.

To summarize: yes to improving expressing time and LoD, no to adding them to the WKT literal.

[paulc-dstl]

I agree with @FransKnibbe - "So I think it best to keep ontologies for space and time nicely separated." The Owl-Time ontology, for example, can be seen as largely analogous to GeoSPARQL in the way it works. And if we are talking about temporal dimensions of spatial things, I would suggest we are actually talking about things which have both spatial and temporal dimensions (eg a forest fire, an observation of a car in traffic, the Bronze Age, the Great Fire of London, etc), ie there is some class of things which exhibit both spatial and temporal characteristics, the former can be modelled using a geospatial ontology and the latter by a temporal ontology, both of which can be nested within an appropriate domain ontology for the thing. A simple timestamp attached to a geo thing would be far too crude for many purposes and would get in the way of richer, more descriptive approaches to temporal things (instants, intervals, etc) and relationships between them (ie Allen's temporal algebra). Let's keep GeoSPARQL simple and focussed.