sgillies commented 10 years ago

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"

sfsheath commented 10 years ago

@sgillies thanks for the clarity. And just for further understanding of scope of your proposal (with my roman amphitheater data as reference):

1) I can use the "when" object to provide some sense of when these were built. The exact semantics will need to be specified in NL or by some other means, but either way, outside the scope of this proposal. Though I will be able to offer some buffering of the "time of construction" duration I specify.

2) The following is out of scope: For the amphitheater at Pompeii, I have decent information on when gladiatorial combats/animal hunts took place. Obviously I am not going to repeat the geometry for the Pompeii Amphitheater for however many events I have. That would break the semantics of that FeatureCollection being a list of amphitheaters, not a list of events in Amphitheaters.

So I need to engage with @kgeographer on topotime more closely to see how it can help me/I can help it. Doing so has been on my list.

And I remain grateful that geojson parsers don't complain about json objects that fall outside the spec's purview.

adoyle commented 10 years ago

I'm going to claim total ignorance on json-ld, but isn't there some way to define an agreed-upon base set of temporal structures and then leave the rest to individual implementations, just like we did with GeoJSON? Having a spec that defines the basics without limiting extensions is generally a winning strategy and is a pretty time-honored tradition in internet (and other) specs.

kgeographer commented 10 years ago

@sfsheath Welcome that @adoyle Appears we're getting there...something like this, @sgillies ?

"when": {"type": "Interval" | "Instant", "time": [{"start":" ", "end":" ", "latest_start":" ", "earliest_end":" "}, { }, ... ]}

sfsheath commented 10 years ago

This is possibly minor.

The pairing of "geometry" with "when" seems odd. Is "geometry" and "chronology" better?

Years from now will someone ask, 'If they used "when" for time, why not "where" for space?'

Like I said, perhaps too minor to worry about.

jyutzler commented 10 years ago

IMHO chronology > when > datetime

kgjenkins commented 10 years ago

"start" and "end" make sense as member names for an interval, but what would be used for an instant? ("value"?) Saying "start": "2014" for an instant seems odd, but having a completely different name for an instant doesn't seem quite right either (and would also make it more convoluted to do something like sorting features that may contain either instances or intervals).

As for word choices, "start" and "end" have a couple advantages: both are short words, and can be used as either adjectives ("start date") or nouns ("the start").

sgillies commented 10 years ago

Dear all, I've written examples for the proposal above and updated the context document.

@sfsheath I found that an earliest (start) and latest (stop) is the only thing that works for both instants and intervals and made that change in the examples.

@kgjenkins I hope the examples answer your question about instants.

kgjenkins commented 10 years ago

@sgillies Thanks for the examples.

Just to be explicit, we have five possible datetimes, with:

earliest <= start <= datetime <= stop <= latest

In the fuzzy instant example, three dates are given: "earliest", "datetime", and "latest". Perhaps it could just as well have just "earliest" and "latest"? Or is it implied in that case that 'datetime' is the most probable date?

Similarly, could the "open-ended interval with a fuzzy start" example just have "earliest"? Or in that case is "start" implied to be the probable start date?

sgillies commented 10 years ago

@kgjenkins right, "datetime" and "start" are the probable times in the fuzzy case. This lets fuzzy time degrade fairly gracefully to precise time for processors that don't understand or fully support fuzzy time.

adoyle commented 10 years ago

Very nice. I think I prefer the time.md to the time-flat.md examples. There's something about the flat ones that bug me, but I'm not sure what.

I took the liberty of correcting what I think was a cut/paste error in https://github.com/geojson/geojson-ld/blob/master/geojson-time.jsonld where Interval used to be ...#Instant.

I may have missed this, but what would be wrong with using http://geojson.org instead of http://example.com in the context documents? Even if geojson.org were to ever go away (heavn forbid!), these are URI, not URLs, I think, so the don't actually have to resolve.

On Apr 24, 2014, at 12:12 PM, Sean Gillies notifications@github.com wrote:

Dear all, I've written examples for the proposal above and updated the context document.

@sfsheath I found that an earliest (start) and latest (stop) is the only thing that works for both instants and intervals and made that change in the examples.

@kgjenkins I hope the examples answer your question about instants.

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

sgillies commented 10 years ago

@adoyle Thanks for the fix and the feedback. I want geojson.org URIs in the end, what you see now is my attempt to keep contexts from being adopted before they are finalized. I'm sorry I haven't made that more clear.

My motivation for offering a flatter alternative was a look at https://schema.org/Event. But yes, maybe we don't want to go that flat.

adoyle commented 10 years ago

Makes sense. Good strategy.

On Apr 24, 2014, at 22:13, Sean Gillies notifications@github.com wrote:

@adoyle I want geojson.org URIs in the end, what you see now is my attempt to keep contexts from being adopted before they are finalized. I'm sorry I haven't made that more clear.

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

sgillies commented 10 years ago

Conclusion

We've agreed that despite the overlap at some scales moving features and feature succession/events should be different efforts.
Simple instants and intervals based on W3C Time are good enough for feature succession/events.
Some feel the simple temporal objects are too restrictive.

Direction

Let's consider a flatter approach as in time-flat.md too. GeoJSON's "type" property is, IMO, a historical artifact and not something we need to do anymore. JSON-LD's way of specifying type is far better. Since JSON-LD's @type can be a list, we can say that a JSON object is both a Feature (having a "geometry" property) and an Instant (having an "instant" property). A "when" object would no longer be needed in this flatter approach.

I'd also like to keep this a strictly JSON-LD effort. One of the nice things about GeoJSON is that it's stable. Once we start adding things like "when" to GeoJSON, that's no longer true.

sfsheath commented 10 years ago

Quickly... I prefer deeper so that I can annotate the "when" object with additional json that doesn't seem like it's littered in the main block of the feature.

kgeographer commented 10 years ago

agreed, @sfsheath - A distinct "when" object seemed very modular to me, and a good thing. I could envision various flavors of 'when' of varying complexity. Now I'm not sure, will have to ponder after current travels.

kgjenkins commented 10 years ago

I can see the benefits of both a simple flat approach, as well as a more modular object approach for more complex/uncertain times.

Why not both?

Earlier, there was a brief discussion of using array values like "datetime": ["2014-04-03", "2014-04-04"] to represent intervals, but that was dropped once uncertainty entered the discussion. GeoJSON currently offers an optional bbox member (not sure how much it gets used) to give a simplified extent of a geometry. What if we had a bbox for time ("tbox"?) that would similarly give simple bounds for a possibly more complex time value ("chronology"?) So tbox/chronology would be the time equivalent of bbox/geometry. But whereas geometry is required and bbox optional, the tbox would be required (well, only where applicable) and chronology would be optional.

So for an instantaneous feature with a certain date, we'd have something like:

"tbox": "2014-05-01"

But if the date is fuzzy, we could have:

"tbox": "2014-05-01",
"chronology": {
  "type": "Instant",
  "earliest": "2014-04-29",
  "probable": "2014-05-01",
  "latest": "2014-05-02"
}

For a certain interval:

"tbox": ["2014-04-12", "2014-04-15"]

For an uncertain interval:

"tbox": ["2014-04-12", "2014-04-15"],
"chronology": {
  "type": "Interval",
  "earliest": "2014-04-01",
  "start": "2014-04-12",
  "stop": "2014-04-15",
  "latest": "2014-04-30"
}

The general idea here is that the "tbox" (or just call it "datetime") would be a simple representation of a time that would cover the majority of use cases and basic visualizations, but the optional "chronology" could be available for a more nuanced treatment of time.

jyutzler commented 10 years ago

I think the group needs to come to a decision on whether the temporal implementation is based primarily on JSON (object-based) or JSON-LD (linked data). This decision has ramifications that should resolve some of the ongoing (i.e., circular) discussions.

sfsheath commented 10 years ago

My quick reaction and assuming I understand @jyutler's concern is that we are looking to merge the two elegantly. We can stick "key":"value" pairs or arrays just about anywhere and "pull out" the triples via a JSON-LD @context. There will be some anti-patterns but lots of JSON-LD will produce the same set of triples. So I suggest we do think about what looks like good JSON. And I think "when":{} is nice and parallels existing geojson patterns.

jyutzler commented 10 years ago

Some examples of ramifications:

There is no clear way to identify the semantics of the Nth element of a JSON array (as in tbox above) in JSON-LD.
You can declare the semantics of properties like earliest, start, etc. and you can declare the semantics of a containing object like chronology, but things break down if you want your container object (or the elements therein) to also take on another semantic meaning (e.g., CAP alert). In other words you need to pick one or the other. .

sgillies commented 10 years ago

@sfsheath I've updated https://gist.github.com/sgillies/11404768 and switched my favorite star over to it. The more I think about it, the more I like "when" (the object if not necessarily the name).

@kgjenkins temporal bounding box is an interesting idea... but earliest and latest (which would be entirely optional) are easier to describe using JSON-LD as @jyutzler points out.

sgillies commented 10 years ago

Show of hands

Please indicate support for the flatter form (without "when") of GeoJSON-LD Time by giving flatter gist a star. If you prefer the deeper form (with "when"), please give deeper gist a star instead.

p3dr0 commented 10 years ago

After evaluation and reading all the comments, my vote is tending for the "when" element. However I would like to know if after decision we can still discussed the following items:

The naming of the elements (e.g. datetime)
The need to add fuzziness as a information model property
How to deal with multiple values of time

I'd like to restrict the vote to flat or deeper, still leaving open the other discussions Is this ok ?

sgillies commented 10 years ago

@p3dr0 i want to give the show of hands another day before I close this issue and we move on. I agree that fuzziness is a different issue.

sgillies commented 10 years ago

Conclusion

The deeper form has more support than the flatter. Let's go ahead with that.

geojson / geojson-ld

Context for GeoJSON + Time #9

At an instant

During an interval

Analogies

Conclusion

Direction

Show of hands

Conclusion