Warning:
This wiki has been archived and is now read-only.

Space and Time

From Locations and Addresses Community Group
Jump to: navigation, search

Background

This page summarises discussion on space and time in the following resources:

Cited specifications & resources

TBD

Issues under discussion

Do geospatial data require a specific representation of time?

Quoting from space and time, 23 May 2014 (Frans Knibbe)

When reading and talking about geographical Linked Data I sometimes come across the term 'spatiotemporal data', meaning that data are dependent on both space and time. I wonder if temporal aspects of data should be considered when we are thinking about how to express location data in the Semantic Web.
I understand that for many spatial data the temporal aspects are really important, but I think temporal aspects could be equally important to data about postage stamps or model trains or beer, or whichever other topics one can have data about. In all cases, I don't think it is necessary to think of special ways of expressing the time dimension in the data. It seems to me that general vocabularies and/or data types for expressing time should suffice. In other words, I think that time and space are orthogonal subjects and that vocabularies about space (location) can be kept separate from vocabularies about time (For normal everyday data, that is. Cosmological data are another matter).

Quoting from Re: space and time, 23 May 2014 (Bart van Leeuwen)

This way [i.e., if vocabularies about space and time are kept separate] tools that understand the temporal structure of your data are able to tell if the data is valid for a given period or not without understanding the actual contents ( geo ) of the data. IMHO that is the strength of linked data / semantic web

Quoting from Re: space and time, 24 May 2014 (Andrea Perego)

the representation of "time" was identified during the LGD'14 barcamp session proposed by Jeremy [Tandy] [...] as one of the key issues to be addressed for the representation of geo data through RDF/OWL.

Quoting from Re: space and time, 24 May 2014 (Raphaël Troncy)

I tend to think that space and orthogonal dimensions. However, there are a number of use cases where those dimensions are tied which trigger the question where we should not have a few handy predicates to handle those cases, among others :
- the temporal validity of the spatial extent of a geographic feature: this is indeed a generic use case that can be applied to any resource (a solution is for example Memento)
- the temporal evolution of the spatial extent of a geographic feature: the typical case is to represent the evolution of boundaries of a administrative unit
- etc.

Quoting from Re: space and time, 28 May 2014 (Frans Knibbe)

Yes, some handy predicates are needed. But I tend to think that those need to come from other vocabularies created by other working groups. I think what is needed is a clear separation of concerns (which is actually a design principle in computer science, so the wikipedia tells me). Otherwise the working groups on geography, model trains and beer will eventually each come up with models that can describe the entire world (but from different perspectives).

Quoting from Re: space and time, 24 May 2014 (Krzysztof Janowicz)

I would just like to point out that a temporal (and spatial) scope is different from a statement that some event occurred before, after, during, etc, another event or that a certain territory was established during a particular time.
Such statements can be addressed by defining a vocabulary for them. The scoping would have to be addressed by the formal semantics of the KR language and in fact Pat Hayes proposed this a few times before.
If you are interested in a tight integration of space and time, we are currently working on a so-called 'settings' ontology design pattern that does exactly that. It was developed during the last Geo-VoCamp in Santa Barbara in March 2014.

Quoting from Re: space and time, 25 May 2014 (Karl Grossner)

People's views about the urgency of somehow joining spatial and temporal seem to vary depending on the use cases they deal with the most. I work in historical applications and see the joining as essential.
Regarding the observation that any data _could_ have a temporal dimension so why favor spatial, I would say this: it's not about adding temporality to widget data, it's about the opportunity to include temporal with spatial if you're representing widget locations.
The location of a thing or event/period is in fact spatial and temporal whether or not we care about both aspects in a given situation. A general data model should account for the essential characteristics of what it models!

Quoting from Re: space and time, 28 May 2014 (Frans Knibbe). In reply to RE: space and time, 24 May 2014 (Raphaël Troncy)

- since 1 month, there is a HUGE thread in the geojson community in order to be able to represent time together with space. Concrete proposals have been made, see https://github.com/geojson/geojson-ld/issues/
An interesting observation. I tried to read this discussion <https://github.com/geojson/geojson-ld/issues/9> and - not being that familiar with GeoJSON - wondered why the community apparently has not chosen to hand over the problem of specification of time to TimeJSON. Is it because TimeJSON does not exist?

Quoting from Re: space and time, 29 May 2014 (Karl Grossner)

Frans,
My answer to this is: because space and time are not independent of each other - they are aspects of location, maybe better termed "setting." A very large proportion of data on natural phenomena come to us as {x,y,z,t} and time has been split out previously because it is challenging to keep them together, and a lot of good work can be done with a "snapshot" view. GeoJSON models geographic features; it is increasingly recognized that events (and periods and processes) are dynamic geographic features. So I would say "when" was an important omission from GeoJSON. If there were a TimeJSON (and Topotime is aimed at that), "where" will be similarly important. I think of them as perspectives on the same thing(s).

Quoting from Re: space and time, 2 June 2014 (Frans Knibbe)

My answer to this is: because space and time are not independent of each other - they are aspects of location, maybe better termed "setting."
I think this is the core of the matter: Are space and time truly dependent on each other? Or do they just happen to occur together very often? If the latter is the case, I think it is better to keep the semantics separate. It is one of the things I like about the semantic web: vocabularies are modules that can be mixed and matched at will. And if a vocabulary is designed well it will be as simple as possible and not try to model anything outside its scope.
A very large proportion of data on natural phenomena come to us as {x,y,z,t} and time has been split out previously because it is challenging to keep them together, and a lot of good work can be done with a "snapshot" view.
Isn't this because with methods less advanced than Linked Data it is harder to keep related thing together? In Linked Data, would say it is not necessary to use a single vocabulary if there is a need to group some facts tightly together.
GeoJSON models geographic features; it is increasingly recognized that events (and periods and processes) are dynamic geographic features. So I would say "when" was an important omission from GeoJSON. If there were a TimeJSON (and Topotime is aimed at that), "where" will be similarly important. I think of them as perspectives on the same thing(s).
OK, I can imagine that time was an omission in GeoJSON. But as far as I know GeoJSON is not at liberty to use semantics from other sources. It needs to model the world on its own. But in Linked Data it is possible to keep things modular and let each group of domain experts work on the semantics of their own domain of expertise.
I see some similarities with the set of OGC standards. It started simple enough: a standard data type for geometry was needed. But then more and more things gravitated towards the model and now the OGC feature model encompasses a great many things. A lot of those things are firmly out of scope. Now the problem with that model is that it is very large and complex and therefore very hard to use, especially for people with only a casual interest in geography.

Quoting from Re: space and time, 7 June 2014 (Andrea Perego)

I think this is the core of the matter: Are space and time truly dependent on each other? Or do they just happen to occur together very often? If the latter is the case, I think it is better to keep the semantics separate. It is one of the things I like about the semantic web: vocabularies are modules that can be mixed and matched at will. And if a vocabulary is designed well it will be as simple as possible and not try to model anything outside its scope.
About your main question, I think that whether and how much space and time are dependent on each other depends on the specific use case.
IMHO, what we need is something like a "core" time ontology. Specific extensions can then be defined to address the specific requirements of the different use cases. In this scenario, the key point is: what are the cross-disciplinary requirements to be addressed by a core time ontology?

Quoting from Re: space and time, 7 June 2014 (Simon Cox)

Yes - I agree that a core vocabulary should do the simple things simply. But it should not erect a fence that makes doing the more sophisticated things impossible. In both time and space a key requirement is that it should be possible to use reference systems other than the default.
While 90%+ of use-cases will use the well-known calendar and clock that are implemented in the XSD time types, there are nevertheless applications and communities who need to use other timescales. Let's try to ensure that the core is extensible in a standard way so the variant users don't have to go elsewhere.

Requirements for modelling time

Quoting from the minutes of the LGD'14 barcamp session proposed and chaired by Jeremy Tandy:

  • Time
    • W3C Time Ontology (Not a standard - a working draft
    • Michael Lutz mentions the need for time properties as a vocabulary
    • The Event Ontology EVENT
    • Allen Operators CIDOC CRM
    • How do we deal with literal syntactic representations of time in ISO 8601? (we parked the discussion on representations in favour of more debate on vocabularies)
    • UK time representation URIs
    • Coordinate Reference Systems for time
      • i.e. We need to make sure that the CRS section above is truly “coordinate” and not simply spatial
      • For example, dates in the Gregorian calendar vs. Julian calendar

Quoting from Re: space and time, 24 May 2014 (Raphaël Troncy)

I tend to think that space and orthogonal dimensions. However, there are a number of use cases where those dimensions are tied which trigger the question where we should not have a few handy predicates to handle those cases, among others :
- the temporal validity of the spatial extent of a geographic feature: this is indeed a generic use case that can be applied to any resource (a solution is for example Memento)
- the temporal evolution of the spatial extent of a geographic feature: the typical case is to represent the evolution of boundaries of a administrative unit
- etc.

Quoting from RE: space and time, 26 May 2014 (Simon Cox)

The current version [of the W3C Time Ontology] (derived from DAML) is scoped such that it would be hard to generalize for archeological and geologic time.
While they may be minority interests, they are authentic and have a rich history and theory associated.
In particular, W3C Time appears to be limited to temporal geometry (no temporal-topology classes), and time position is limited to year/month/day/hours/minutes/seconds, which clearly limits it to the present and relatively recent past.

Quoting from RE: space and time, 27 May 2014 (Simon Cox). The message refers to (an excerpt of) a chapter by Karl Grossner, Krzysztof Janowicz & Carsten Keßler - more specifically, to the Setting ontology and the Topotime temporal data model described there. See Re: space and time, 24 May 2014 (Krzysztof Janowicz) and Re: space and time, 25 May 2014 (Karl Grossner).

Karl -
I note that some of your historical application examples use a temporal reference system that is based on ordered sequences of named periods. These may be modelled as a (constrained) temporal topology, which may be related to a temporal coordinate system, but is often used independently. As I implied in my earlier message to this list, that is a situation that also applies in archaeology and geology. While there are certainly differences in practice between these disciplines, the general principle is common. The standard time ontologies (particularly W3 Time) do not support this case.
There is a more comprehensive, but still flawed, treatment of temporal reference systems in ISO 19108, which we critiqued in a paper published in 2005 http://dx.doi.org/10.1130/GES00022.1
More recently we have developed an OWL implementation, described in a paper in press in Earth Science Informatics, and available at http://resource.geosciml.org/ontology/timescale/thors which is aligned with both the ISO 19108 Temporal Topology and Temporal Reference System models (with a geological extension at http://resource.geosciml.org/ontology/timescale/gts )

Issues for the representation of time and space

Quoting from RE: space and time, 27 May 2014 (Simon Cox)

The challenge of dealing with ‘structured values’, particularly for space and time was alive from early on, with the constraint of trying to jam it into text strings.
For time there was always ISO 8601 to fall back on (which underlies the XSD temporal types) and most software libraries can deal with parsing that.
But for space, and space-time, the world is yet to converge on a common solution. [...]
The issue is that even the simplest geometry (a single position or point) requires between 3 and N pieces of information, where N could be as much as 20 in order to fully define a coordinate reference system locally which really does happen sometimes. There are specific relationships between them, but the labels and semantics are not even common for all cases (e.g. latitude-longitude vs easting-northing, depending on the coordinate reference system used, for example – there are around a thousand of these in the standard databases[1], and note that ‘southing-westing’ is used in some places even!). Ubiquitous GPS has pushed us all closer to a single standard for the information than ever before (but not the format), but still there are legal requirements and common conventions to use other systems in many places in the world (e.g. UK National Grid), so it is not clear that just saying ‘it is WGS84 and tough luck to everyone else’ is acceptable. A key point is that the individual items are not independent of each other – it is really one piece of information, but is a vector and thus has internal structure. So the standard RDF approach of putting everything in separate literals would require a very complex structure to track all this, which would probably fail to pass the laugh-test for the common case.
My sense is that the closest we have to a useable standard for geometry is WKT. This ticks enough of the boxes – it is a text-based microformat that allows the CRS to be indicated, and doesn’t require escaping to embed in a text field. Like any microformat it does need a special parser, but there a few of these around[2], and since even hard-core RDF types accept a microformat for time, then why not space?
[...]
[1] http://www.epsg-registry.org/
[2] http://en.wikipedia.org/wiki/Well-known_text#RDBMS_Engines_that_provide_support

Time modelling approaches

W3C Time Ontology

Reference specification

Discussion

Quoting from RE: space and time, 24 May 2014 (Raphaël Troncy)

OWL Time is a draft, unfinished, and criticized for a number of use cases.

Quoting from RE: space and time, 26 May 2014 (Simon Cox)

The current version [of the W3C Time Ontology] (derived from DAML) is scoped such that it would be hard to generalize for archeological and geologic time. While they may be minority interests, they are authentic and have a rich history and theory associated.
In particular, W3C Time appears to be limited to temporal geometry (no temporal-topology classes), and time position is limited to year/month/day/hours/minutes/seconds, which clearly limits it to the present and relatively recent past.

stRDF & stSPARQL

Quoting from RE: space and time, 27 May 2014 (John Goodwin)

This was some work done by the FP7 project TELEIOS looking at geospatial and temporal extensions to RDF/SPARQL (called stRDF and stSPARQL respectively). The spatial elements of this work did end up converging nicely with GeoSPARQL. The temporal aspects also look useful and interesting.

FGDC Time Space Position Information (TSPI)

Quoting from RE: space and time, 27 May 2014 (Carl Anderson)

[The] FGDC standard [...] attempts to deal with describing time and space and uncertainties in inherent in both.

Time in GeoJSON(-LD)

Documentation and resources

Discussion

Quoting from RE: space and time, 24 May 2014 (Raphaël Troncy)

- since 1 month, there is a HUGE thread in the geojson community in order to be able to represent time together with space. Concrete proposals have been made, see https://github.com/geojson/geojson-ld/issues/

Quoting from Re: space and time, 28 May 2014 (Frans Knibbe)

An interesting observation. I tried to read this discussion <https://github.com/geojson/geojson-ld/issues/9> and - not being that familiar with GeoJSON - wondered why the community apparently has not chosen to hand over the problem of specification of time to TimeJSON. Is it because TimeJSON does not exist?

Quoting from Re: space and time, 25 May 2014 (Karl Grossner)

Yes, there is now an effort at a new GeoJSON-LD standard, and I have co-instigated getting time into it (not into core GeoJSON; that idea has been rejected by its keepers).
Regarding the observation that any data _could_ have a temporal dimension so why favor spatial, I would say this: it's not about adding temporality to widget data, it's about the opportunity to include temporal with spatial if you're representing widget locations.
The location of a thing or event/period is in fact spatial and temporal whether or not we care about both aspects in a given situation. A general data model should account for the essential characteristics of what it models! In the case of GeoJSON-LD, a Feature will have an optional "when" object at the same level as the "geometry" object. Existing software that parses GeoJSON will ignore the "when" (as well as the @context), but applications can be written to process it.
I'm not thrilled with how GeoJSON-LD is shaping up but do consider it making time a co-equal aspect with space in answers to "where?" a significant step forward.

Setting ontology and Topotime data model

Documentation and resources

Discussion

Quoting from Re: space and time, 24 May 2014 (Krzysztof Janowicz)

I would just like to point out that a temporal (and spatial) scope is different from a statement that some event occurred before, after, during, etc, another event or that a certain territory was established during a particular time.
Such statements can be addressed by defining a vocabulary for them. The scoping would have to be addressed by the formal semantics of the KR language and in fact Pat Hayes proposed this a few times before.
If you are interested in a tight integration of space and time, we are currently working on a so-called 'settings' ontology design pattern that does exactly that. It was developed during the last Geo-VoCamp in Santa Barbara in March 2014.

Quoting from RE: space and time, 27 May 2014 (Simon Cox). The message refers to (an excerpt of) a chapter by Karl Grossner, Krzysztof Janowicz & Carsten Keßler - more specifically, to the Setting ontology and the Topotime temporal data model described there. See Re: space and time, 25 May 2014 (Karl Grossner).

Karl -
I note that some of your historical application examples use a temporal reference system that is based on ordered sequences of named periods.

Quoting from Re: space and time, 27 May 2014 (Karl Grossner)

Much historical data arrives as 'before' and 'after.' I'm working intently on archaeological data in recent months and certainly topological time and space are conflated in many senses with Harris matrices, etc. [...] Principally, Topotime seeks to add operators for before, after and about to any ISO 8601 expression, permit some very basic estimations and then make parameters manipulable.

Space and time in Dublin Core

Relevant specifications

Discussion

Quoting from Re: space and time, 27 May 2014 (Andrea Perego)

Dublin Core [...] defined a generic property dct:coverage and a generic class dct:LocationPeriodOrJurisdiction, and related specialisations (dct:spatial, dct:Location; dct:temporal, dct:PeriodOfTime; dct:Jurisdiction), as well as encoding schemes for points, bboxes and periods (now "deprecated").
@Makx, @Simon, I wonder whether you can give any insight on the design choices made in Dublin Core when modelling these notions.

Quoting from RE: space and time, 27 May 2014 (Makx Dekkers)

In response to Andrea’s request, I did some digging in my memory and archive on the ideas that led to the definition of the coverage element in Dublin Core.
A very early discussion (1997) is recorded at http://dublincore.org/documents/coverage-element/.
The definition then read:
The Coverage element describes the spatial and temporal characteristics of the object or resource and is the key element for supporting spatial or temporal range searching on document-like objects that are spatially or temporally referenced. Coverage may be modified by spatial or temporal qualifiers.
A resource may have both spatial and temporal coverages, or just one of the two, or none. This element may be used in describing resources from many different fields, e.g., archaeology, art, cartography, geography, geographic information systems, medicine, natural sciences, etc. - any field that deals with georeferenced information, spatial data, or temporal data. Thus for example, resources describing the Grand Canyon of the United States include text, maps, music (e.g., Ferde Grofe's Grand Canyon Suite), statistics (e.g., number of visitors per year), works of art (such as the panoramas that appear in the 1882 publication, "Atlas to accompany the monograph on the Tertiary history of the Grand Canon district"), etc.; and each could use Coverage - Spatial and in some cases Coverage - Temporal.
Spatial information may be given in numeric form (e.g., degrees of latitude) or as text. Temporal information may also be given in numeric form or as text. Numbers are preferred. If scheme is not given, none is assumed. No defaults are assumed.
Please note that that was a time when people were still thinking mostly about putting metadata in the META tag of HTML. RDF was just being drafted but it would be some time before that was considered a better way to express metadata.
So the idea in 1997 was that there could be several aspects of time and place related to a resource. Those aspects were lumped together in a general purpose bucket that could be further specialised using ‘qualifiers’. A couple of years later, when RDF became the expression of choice for Dublin Core metadata, the original 15 elements were retrofitted into a set of properties with supporting classes conforming to the RDF model.
In that process, it was decided that the definition of coverage as a union of temporal and spatial characteristics (jurisdiction was added in the comment in 1999) required the creation of a composite class dcterms:LocationPeriodOrJurisdiction to provide backward compatibility with existing usage. At the same time, the more precise subclasses dcterms:Location, dcterms:Period and dcterms:Jurisdiction were created together with two sub-properties dcterms:spatial and dcterms:temporal to allow for more precise use. In fact, the more precise use was encouraged. In effect, there were calls to deprecate the use of dc:coverage although this was never made explicit in order not to upset the implementations that were based on the mixed usage.
I also need to note that some of the more ‘semantically oriented’ people in the DCMI community around 2003-2004 expressed a strong opinion that the lumping together of two very different dimensions had been a big mistake, because it made automated processing very hard.
The ‘structured values’ DCMI Box, DCMI Point and DCMI Period were intended to provide a method for recording simple structured data in text strings; again, this was intended for use in string-based, META-tag, ‘simple’ Dublin Core. The approach was abandoned in favour of using RDF-based methods; however, I don’t think these DCMI Recommendations were ever formally retired or deprecated.
Simon, as the author of these structured value definitions, may have a more precise recollection of how this came about.

Quoting from RE: space and time, 27 May 2014 (Simon Cox)

Regarding
The ‘structured values’ DCMI Box, DCMI Point and DCMI Period were intended to provide a method for recording simple structured data in text strings; again, this was intended for use in string-based, META-tag, ‘simple’ Dublin Core. The approach was abandoned in favour of using RDF-based methods; however, I don’t think these DCMI Recommendations were ever formally retired or deprecated.
Yes. The challenge of dealing with ‘structured values’, particularly for space and time was alive from early on, with the constraint of trying to jam it into text strings.
For time there was always ISO 8601 to fall back on (which underlies the XSD temporal types) and most software libraries can deal with parsing that.
But for space, and space-time, the world is yet to converge on a common solution. [...]
The issue is that even the simplest geometry (a single position or point) requires between 3 and N pieces of information, where N could be as much as 20 in order to fully define a coordinate reference system locally which really does happen sometimes. There are specific relationships between them, but the labels and semantics are not even common for all cases (e.g. latitude-longitude vs easting-northing, depending on the coordinate reference system used, for example – there are around a thousand of these in the standard databases[1], and note that ‘southing-westing’ is used in some places even!). Ubiquitous GPS has pushed us all closer to a single standard for the information than ever before (but not the format), but still there are legal requirements and common conventions to use other systems in many places in the world (e.g. UK National Grid), so it is not clear that just saying ‘it is WGS84 and tough luck to everyone else’ is acceptable. A key point is that the individual items are not independent of each other – it is really one piece of information, but is a vector and thus has internal structure. So the standard RDF approach of putting everything in separate literals would require a very complex structure to track all this, which would probably fail to pass the laugh-test for the common case.
My sense is that the closest we have to a useable standard for geometry is WKT. This ticks enough of the boxes – it is a text-based microformat that allows the CRS to be indicated, and doesn’t require escaping to embed in a text field. Like any microformat it does need a special parser, but there a few of these around[2], and since even hard-core RDF types accept a microformat for time, then why not space?
[...]
[1] http://www.epsg-registry.org/
[2] http://en.wikipedia.org/wiki/Well-known_text#RDBMS_Engines_that_provide_support
Retrieved from "https://www.w3.org/community/locadd/wiki/index.php?title=Space_and_Time&oldid=178"