Context for GeoJSON + Time

[sgillies]

How about this (using a JSON-LD ish notation)? Familiar GeoJSON idioms at work:

At an instant

{ "@context": {"Instant": "http://www.w3.org/2006/time#Instant"}, "type": "Feature",
  "geometry": {"type": "Point", ...},
  "time": {"type": "Instant", "value": "2014-04-03"},
  "properties": ... }

During an interval

{ "@context": {"Interval": "http://www.w3.org/2006/time#Interval"}, "type": "Feature",
  "geometry": {"type": "Point", ...},
  "time": {"type": "Interval", "value": ["2014-04-03", "2014-04-04"]},
  "properties": ... }

I can't think of a reason not to use a subset of W3C's time vocabulary: OWL Time.

Analogies

• "Instant" and "Point"
• "Interval" and "LineString"

[kgeographer]

That is very much along the lines I was thinking. Agree with the basic W3C examples, and I might publish a collection with

{ "@context": {"Timespan": "http://catalhoyuk.stanford.edu/schema#Timespan"}, 
  "type": "Feature",
  "geometry": {"type": "Point", ...},
  "time": {"type": "Timespan", "value": ["-7200", "-6400"]},
  "properties": ... }

"time" is ignored by GeoJSOn parsers like GitHub, but handled by apps that expect it
e.g. https://github.com/kgeographer/catalhoyuk/blob/master/figurine_ld.json (zoom out for context)
And values can also take the form of URIs for periods defined wherever.

[sgillies]

My initial example "time": {"type": "Instant", "value": "2014-04-03"} feels a bit off. Better, I think, is something like "SOME_KEY": {"type": "Instant", "times": "2014-04-03"} where the analogy is "times" and "coordinates" and "SOME_KEY" and "geometry".

So, what to use for SOME_KEY? "duration" could work. Other ideas anyone? @kgeographer?

For the value(s) of "times", what is the simplest thing that could possibly work? I suggest that the answer is ISO 8601 (or equivalently, RFC 3339) datetimes in a "common era" calendar using astronomical years (0 indexed). The day before "1-01-01" would be "0-12-31".

[kgeographer]

my 3 or 4 cents:
For SOME_KEY I prefer 'timespans,' or 'temporal_extent' because 'duration' suggests to me the product of end - start. In Topotime so far we call the temporal equivalent of geometry 'tSpans' b/c they can be a set -- multispans so to speak. All of these may be inferior to simply 'time.'

For 'times,' ISO8601 to any level of detail makes sense. All transformations, to and from other calendars for example, are pre- and post-processing steps outside the basic core you/we are aiming for.

There are interesting scale issues that differ from geometry -- or maybe not so much? E.g. whether any single datetime expression can be called an Instant, and an Interval is necessarily a pair of Instants. The type becomes a signal to further processing, including visualization. Is a day the unit for time that corresponds to the whole number degree?

If there were one day a GitHub parser for this, rendering a timeline along with a map, a mixed bag (Collection) of day, year, minute Instants and Intervals could produce an unintelligible display. It's on the data producer to manage temporal scale meaningfully, just as with geometry now.

[jyutzler]

My counterproposal is presented here:
https://github.com/jyutzler/slartime-spec/blob/master/0.0.2/README.md

and discussed here:
http://slarjy.blogspot.com/2014/04/time-for-slartime.html

Main differences between my proposal and the above:

• "SOME_KEY" is an unnecessary paradigm. A feature may have multiple geometries (Geometry Collection). There is no real difference between a numbered index in a collection and a hard-coded "SOME_KEY".
• The most efficient way to encode moving features is with a multipoint geometry and datetime sequence. The above seems to be missing that paradigm.
• A general disinterest in wading into temporal reference systems as this does not appear to be a well-solved problem.
• Minor naming differences: Period vs. Interval, positions vs. value/time (who cares...)

Side rants: Please provide a URL to the "W3C's time vocabulary" as I am not 100% sure what this refers too. Of course I wish ISO wouldn't keep its standards behind a paywall (my proposal is influenced by ISO19108). Even more stupidly, NGA nicely summarized the ISO 191xx documents in its Time-Space Position Information document, marked the document as unlimited public distribution, then tucked the document behind its own firewall so the public can't easily get to it. This stupidity keeps me from linking to the documents influencing my proposal.

[sgillies]

Recap

• The spatial extent of a GeoJSON feature is described by its "geometry" object.
• GeoJSON Time (this proposal) will treat time separately from space but with analogous constructs (Instant-Point, Interval-LineString, datetime-coordinates).
• The extent in time of a GeoJSON feature will be described by an object that's a sibling to "geometry."

When

Why not call that object "when"? Here's an example of a Feature that existed for an instant:

{"type": "Feature", "when": {"type": "Instant", "datetime": "2014-04-03"} ...}

One that existed for a day:

{"type": "Feature", "when": {"type": "Interval", "datetime": ["2014-04-03", "2014-04-04"]} ...}

Open ended intervals

Open ended intervals are going to be useful, yes? Here's a possibility for a feature that existed up to a certain day:

{"type": "Feature", "when": {"type": "Interval", "datetime": [null, "2014-04-04"]} ...}

And one that exists from a certain day onward:

{"type": "Feature", "when": {"type": "Interval", "datetime": ["2014-04-04", null]} ...}

[jyutzler]

I'm fine with "when". Datetime always struck me as a clunky name. For that reason, I still prefer a positions array for the actual values (or position for an instant, something I corrected in 0.0.3).

I am amenable to open-ended intervals but nulls concern me. Is null "+/- infinity" or "unknown" or "none"? I believe it must be unambiguous and if we need to support more than one at a time then things get more complicated. In my draft I currently only allow null to describe an open-ended period.

FWIW, ISO19108 uses "period" to describe something with a beginning and end "when". It doesn't define interval but I assume that it refers to the mathematical concept of the continuity of real numbers:
http://en.wikipedia.org/wiki/Interval_(mathematics)

[tschaub]

How about Instant, Interval, Since, and Until as types of when (instead of optionally null interval endpoint(s))?

[jyutzler]

I'd like to think this can be done without overloading the type property.

[sgillies]

@jyutzler I added a link to W3C OWL Time above. That's where Instant and Interval come from.

@tschaub Much better! I like new types better than significant nulls.

FWIW, OWL Time RDF style would be

  feature hasBeginning DATETIME
  feature hasEnding DATETIME

In JSON that would be like

{"type": "Feature", "when": {"type": "Interval", "since": "2014-04-03", "until": "2014-04-04"} ...}

That would let us go back to two types of when. Omission of one or the other means an open-ended interval. I think open endedness means uncertainty, not infinity.

[jyutzler]

@sgillies I'm not sure how this is better, just more verbose. As we've seen elsewhere, JSON scales best when using arrays. We don't use properties for coordinate values and bbox corners. Why start now?
Note this proposed JSON snippet from an OGC SWG[1].

{ “type”: “FeatureCollection”, "features": [
    {“type”: “Feature”, 
     “geometry”: {“type”: “LinerTrack”, “coordinates”: [[102.0, 0.5], [102.0, 13.5]]},
    “properties”:{ “starttime”:”10”, ”endtime”:”100”, “attr”: [“walking”,”1”] },
    {"type": "Feature",
     “geometry”: { “type”: “LinearTrack”,    “coordinates”: [ [102.0, 0.0], [100.0, 21.0]] },
     “properties”: {“starttime”:”11”, “endtime”:”120”, “attr”: [ “vehicle”, “0”] },
    { “type”: “Feature”,
      “geometry”: { “type”: “LinearTrack”,  “coordinates”: [ [ [100.0, 0.0], [101.0, 18.0] ] },
     “properties”: {“starttime”:”12”,”endtime”:”80”,“attr”: [“walking”, “0”] } } 
] } 

This is so inefficient that the SWG rejected GeoJSON completely from their set of encodings. I complained that they were doing it wrong and promised to show them a better way. The proposal on the table here would not be a significant improvement over the SWG's strawman.

BTW, thanks for the OWL link.
[1] Moving Features SWG �Discussion on Draft, 25, September 2013

[sgillies]

@jyutzler I do prefer datetimes of an interval to be a list. I also like using @tschaub's Since and Until types instead of adding nulls. Would love to get more feedback from the people watching this repo.

[sgillies]

Next can of worms... :)

Intermittent or periodic temporality

Is it too soon to kick multi-instant and multi-interval types out of scope? I don't think it is. Things in our universe don't really come and go, they only go far away and return.

[jyutzler]

@sgillies My proposal has Sequence (like Multipoint) and WhenCollection (like GeometryCollection), though neither is in ISO19108 or the OWL Time Ontology. What is not in my proposal is regular intervals - that something happens weekly or daily or every 17 minutes or whatever. I don't happen to have a use case for that one.

[kgeographer]

@sgillies, all - I am watching this with great interest, but completely immersed in other work with a deadline; will have to wait until evening to actually give it thought

btw, not nec. to cc me, as I get these real-time

----- Original Message -----

@jyutzler I do prefer datetimes of an interval to be a list. I also like
using @tschaub 's Since and Until types instead of adding nulls. Would love
to get more feedback from the people watching this repo.

—
Reply to this email directly or view it on GitHub .