Not clear if "start" and "stop" values are data or objects

rybesh commented 10 years ago

The JSON-LD context used in the latest version of the temporal items example maps start to http://www.w3.org/2006/time#hasBeginning and indicates that the type of start values is http://www.w3.org/2001/XMLSchema#dateTime. This implies that time:hasBeginning is a data property. But, according to the OWL-Time spec, the range of time:hasBeginning is time:Instant (a time:TemporalEntity); in other words, time:hasBeginning is an object property. (stop has the same issue w.r.t. time:hasEnding.)

It seems to me that this is a misuse of OWL-Time as it elides the distinction between temporal entities (instants and intervals) and their descriptions (which include XML datetimes but also other forms of description).

But, maybe you intended to treat time:hasBeginning as property that ranges over both objects and data; so that each value of start is both a time:Instant and an xsd:datetime. If that's the case, then RDF produced from GeoJSON-LD is not going to be compatible with OWL-DL, which strictly separates the object domain from the data domain. This will make reasoning over GeoJSON-LD potentially intractable.

I see two possible solutions.

Decide that you don't care about OWL, and are just sticking with RDF semantics. Fine, but in that case, why use OWL-Time? Why not drop time:hasBeginning and time:hasEnding in favor of some predicates that allow you to directly relate intervals to XML datetimes using Allen relations?
Introduce blank nodes, e.g.:

"when": {
  "start": { "datetime": "2014-04-24" },
  "stop": { "datetime": "2014-04-25" },
  "@type": "Interval"
}

The extra level of nesting kinda sucks, but on the other hand by making the instant endpoints accessible it opens the possibility of relating features more directly; for example one could make it clear that two non-instantaneous features are temporally adjacent by giving a time:Instant an identifier, and asserting that the when.stop of the first feature has the same value as the when.start of the second feature.

sgillies commented 10 years ago

@rybesh I'm inclined toward the first solution.

I don't want to prevent anyone from reasoning with OWL by misusing OWL-Time.

I don't find the blank nodes in that block under number 2 too bad. I'm more concerned about the proliferation of instant references. Data such as

"when": {
  "start": { "@id": "_:instant1"},
  "stop": { "@id": "_:instant2" }
  "@type": "Interval" }

can't be processed without RDF, and I think this means that it will be unusable to many if not most applications. TopoJSON uses references, yes, but ones very specific to its implementation. It doesn't require RDF but still has fewer uses due to the indirection.

Would this work still be useful to PeriodO if we went with the first solution?

rybesh commented 10 years ago

I agree that the first solution is best, and it works for us. For PeriodO we're trying to be RDF-friendly where possible, but not at the expense of providing simple, idiomatic plain-old-JSON.

I wish I could recommend a vocabulary to replace OWL-Time (which nobody seems to like anyway) but I don't know of any offhand...

akuckartz commented 10 years ago

A similar issue was raised regarding schema.org: https://github.com/rvguha/schemaorg/issues/51

geojson / geojson-ld

Not clear if "start" and "stop" values are data or objects #23