Proposal for flatter GeoJSON-LD Time

[sgillies]

The time representation from #9 (see examples in time.md) can be flattened significantly with little loss of information. See time-flat.md for examples.

Good? Bad?

[kgeographer]

I take it a "Open-ended interval with a fuzzy start and end" would have earliest, start, end and latest terms?

I'm all for simplicity, and it seems simplest that "when" be handled similarly to "where." And that a "when" object corresponding to "geometry" mimic its structure insofar as possible. For that reason, I don't favor its removal in a flattening.

The concept of a 'standard GeoJSON-LD "when object"' and potentially other, more elaborate alternatives seems intuitive: easy to imagine 'are your GeoJSON-LD "when"s vanilla, PeriodO, or Topotime?'

Not thrilled with a day referred to as an Instant, since it doesn't correspond well to the most common understandings of that word. But it works as an instruction to a rendering engine, much as "type': "Point" does. A city isn't a point but GeoJSON allows us to direct its rendering as one. A day (or month or year) isn't an Instant, but we're saying render it as one.

Following that line of reasoning, I favor including the types MultiInstants and MultiIntervals. We're starting to conflate geo features and events here (which is both great and potentially confusing), as what geo features exist for an instant except events? I want to represent the intermittent existence of the geo-feature "State of Georgia." I grant that geo-reincarnation is not that common outside of admininistrative boundaries, but it is a case and suggests a more complete correspondence with geometry:

"when": { 
   "times": [ "start":" ", "end":" ", "earliest":" " ],
                [ "start":" ", "end":" ", "earliest":" " ] 
   "type": "MultiInterval"
   }

After all this, feeling more than ever collections of temporal things (like the PeriodCollection in Topotime) will be a useful alternative perspective on things that have both spatial and temporal extension. Perhaps such a standard can be merged with that for FeatureCollection (GeoJSON) down the road, but more likely to remain a distinctive perspective on spatial-temporal phenomena.

[sgillies]

Instant: 2014-04-24 (shorthand notation) isn't a day long interval, it's the first stroke of April 24 expressed with granularity of a day. Different levels of granularity are explained in http://www.w3.org/TR/NOTE-datetime and definitely need to be nailed down a bit for GeoJSON-LD Time.

I really can't get behind Multi- temporal types. From years of designing and critiquing formats for the web, it's clear that usability goes down as the amount of modeling goes up. Modeling a domain exquisitely and modeling it sufficiently are always at odds. GeoJSON has always chosen to be just sufficient, and that's been the key to its success. I suspect that anything more complicated than simple instants and intervals isn't going to take off and that as long as we can show the evolution of Georgia in timelines and maps using just simple instants and intervals, we should. I'm certain we can.

[p3dr0]

+1 Even if at first I was more inclined for the "when" object because of the similarity to the geometry, I was having a problem with the temporal types. Could the flat model be further simplified and just assume an optional start and stop? Do we really need to explicitly define the fuzziness of the data? What is precise for one application might be considered fuzzy in another

[sgillies]

@p3dr0 Can you explain what you mean by having a problem with the types?

The fuzziness could be moved to another profile certainly. By profile, I mean a different context for Feature Collections. But too many layers of profiles becomes a burden for adoption and usability.

[p3dr0]

by types I mean the "type" element of "when" as defined in time.md

 "when" : {
    "datetime": "2014-04-24", 
    "type": "Instant"
  }

I think that we are adding an unnecessary complexity layer with this model

I prefer the flat model defined in time-flat.md but only defining a "instant", "start" or "stop" element that is a date-time format (YYYY-MM-DDThh:mm:ss.SSS[+-]hh:mm ) following these rules :

• "Instantaneous event-like feature" uses the "instant" element
• To define an interval use the "start" and "stop" element
• To define a "Open-ended event-like feature" you just add the "start" element
• To define a "Close-ended event-like feature" you just add the "stop" element

I don't think we have to the "fuzziness" to a another profile as you are able to define it with the existing parameters.

[sgillies]

I see. Start, stop, and instant could describe a fuzzy instant, I agree, but I don't see how they could describe a fuzzy interval.

I think that the flat version works really well with JSON-LD because we can write JSON like this:

{
  "@context": {
    "Feature": "http://example.com/vocab#Feature", 
    "Instant": "http://www.w3.org/2006/time#Instant", 
    "Interval": "http://www.w3.org/2006/time#Interval", 
    "Point": "http://example.com/vocab#Point", 
    "coordinates": "http://example.com/vocab#coordinates", 
    "datetime": "http://www.w3.org/2006/time#inXSDDateTime", 
    "earliest": "http://example.com/vocab#earliest", 
    "geometry": "http://example.com/vocab#geometry", 
    "id": "http://example.com/vocab#id", 
    "latest": "http://example.com/vocab#latest", 
    "properties": "http://example.com/vocab#properties", 
    "start": "http://www.w3.org/2006/time#hasBeginning", 
    "stop": "http://www.w3.org/2006/time#hasEnding", 
    "type": "http://example.com/vocab#type", 
  },
  "geometry": {
    "type": "Point", 
    "coordinates": [
      0.0, 
      0.0
    ]
  }, 
  "datetime": "2014-04-24",
  "type": "Feature",
  "@type": ["Feature", "Instant"],
  "properties": {}
}

And the "@type": ["Feature", "Instant"] makes it explicit that the thing is an instantaneous Feature.

[p3dr0]

I'd prefer to use the nouns for all time objects (instant, start, stop) instead of mixing it with formats/types (e.g. datetime), is this ok for you?

Regarding time fuzziness, is this an explicit requirement ? We don't have fuzzy geometry and I see it as an application dependent issue. The same document start and stop might be considered fuzzy or precise depending of the use cases

Going that road will lead us to the data quality and validity issues that, while very interesting, should not be considered at this stage.

[sgillies]

@p3dr0 You've persuaded me that "instant" is a better word than "datetime". I'm also willing to split fuzzy time out for now. It's very useful for historical web mappers who have to deal with uncertainty, but I'd be uncomfortable with developers using the fuzzy parameters to indicate precision.

So, I'll update time-flat.md and work on making the case to @adoyle :) The flat approach really requires JSON-LD, I think, whereas the other one does not. I'm happy with a JSON-LD requirement and I've guaranteed several times that there will never be a GeoJSON 2.0 ;)

[jyutzler]

Once things are flattened, what role to the following context entries have?

    "Instant": "http://www.w3.org/2006/time#Instant", 
    "Interval": "http://www.w3.org/2006/time#Interval", 

If I understand this correctly, these things will never appear in a GeoJSON-LD object so they don't need to be mentioned in the @context section.

[p3dr0]

@jyutzler what @sgillies is proposing is that we use the tokens "Interval" and "Instant" on the json-ld @type array this is in accordance with http://www.w3.org/TR/json-ld/#specifying-the-type (check example 14)

[sgillies]

Show of hands

Can you please indicate support for the flatter form by giving flatter gist a star? If you prefer the deeper form, please give deeper gist a star instead.

[jyutzler]

@p3dr0 got it thanks.

Now to figure out if I can align a moving features effort with this proposal...

[jyutzler]

So since our start, stop, earliest, and latest are all ISO8601 strings, shouldn't that be identified explicitly in the context? Something like:

{
  "@context": {
    "Feature": "http://example.com/vocab#Feature", 
    "Instant": "http://www.w3.org/2006/time#Instant", 
    "Interval": "http://www.w3.org/2006/time#Interval", 
    "Point": "http://example.com/vocab#Point", 
    "coordinates": "http://example.com/vocab#coordinates", 
    "instant": "http://www.w3.org/2006/time#inXSDDateTime", 
    "earliest": "http://example.com/vocab#earliest", 
    "geometry": "http://example.com/vocab#geometry", 
    "id": "http://example.com/vocab#id", 
    "latest": "http://example.com/vocab#latest", 
    "properties": "http://example.com/vocab#properties", 
    "start": {
        "@id":"http://www.w3.org/2006/time#hasBeginning", 
        "@type":"instant"
    },
    "stop": {
        "@id":"http://www.w3.org/2006/time#hasEnd", 
        "@type":"instant"
    },
    "type": "http://example.com/vocab#type" 
  },
  "geometry": {
    "type": "Point", 
    "coordinates": [
      0.0, 
      0.0
    ]
  }, 
  "start": "2014-04-24",
  "stop": "2014-04-25",
  "type": "Feature",
  "@type": ["Feature", "Interval"],
  "properties": {}
}

The above happily passes the JSON-LD Playground's parser.

[sgillies]

@jyutzler More like in 926a4bb, I think.

Also, I'm reversing myself on the "datetime" to "instant" switch. Although it's really the URI (http://www.w3.org/2006/time#inXSDDateTime) that's the important thing, having an "instant" and an "Instant" is going to confuse people.

[jyutzler]

I don't think we're there yet. How about this:

{
   "@context": {
    "Feature": "http://example.com/vocab#Feature",
    "Instant": {
      "@id": "http://www.w3.org/2006/time#Instant",
      "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
    },
    "Interval": "http://www.w3.org/2006/time#Interval",
    "Point": "http://example.com/vocab#Point",
    "coordinates": "http://example.com/vocab#coordinates",
    "geometry": "http://example.com/vocab#geometry",
    "id": "http://example.com/vocab#id",
    "properties": "http://example.com/vocab#properties",
    "type": "http://example.com/vocab#type"
  },
  "@type": ["Feature", "Instant"],
  "geometry": {
    "type": "Point",
    "coordinates": [
      0.0,
      0.0
    ]
  },
  "Instant": "2014-04-24",
  "type": "Feature",
  "properties": {}
}

[jyutzler]

@kgeographer please take a look at https://github.com/geojson/geojson-ld/issues/15 and see if this works for you.

[kgeographer]

@jyutzler I'm overseas, very intermittent contact and bandwidth for a couple of days, followed by jet lag and catching up with 'real' work stuff no doubt. I'll do my best to ponder and respond soon.

Off the top, appears 'official' GeoJSON-LD spec is moving on w/o accommodating my admittedly troublesome use cases for fuzzy history. I will principally focus on the collections of periods (temporal things) that is Topotime and be grateful time is making any appearance in GeoJSON-LD collections of features. Topotime development has definitely benefited from this discussion.

[sgillies]

@sfsheath pointed out something important at https://github.com/geojson/geojson-ld/issues/9#issuecomment-41752563: with no "when" object, there's no good way to annotate the temporal information. Where would you put provenance and precision? We'd lose the ability to express more precisely what "when" means in our data. Something like

@context:
  "when": {
    "@type": ["http://geojson.org/vocab#when", "http://example.com/vocab#lifetime"]
   }

where you say that "when" in your data means the "lifetime" of a feature (I'm pulling this property out of thin air) wouldn't be possible except by annotation of the Feature object.

@adoyle Is this related to your misgivings about flatter JSON?

[jyutzler]

@sgillies I think this argument is completely moot. In JSON-LD land, it isn't for us to even decide how these are organized. The only thing that matters is that when a property is encountered and that property is part of the context, that the property has a real meaning. The organization can be flat or wrapped in when or Djbouti. You can do whatever you want outside the vocabulary - it is just ignored.

You can test this for yourself in the playground. The following interprets properly.

{
   "@context": {
    "Feature": "http://example.com/vocab#Feature",
    "Instant": {
      "@id": "http://www.w3.org/2006/time#Instant",
      "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
    },
    "datetime": {
      "@id": "http://www.w3.org/2006/time#Instant",
      "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
    },
    "Interval": "http://www.w3.org/2006/time#Interval",
    "Point": "http://example.com/vocab#Point",
    "when": "http://example.com/vocab#when",
    "coordinates": "http://example.com/vocab#coordinates",
    "geometry": "http://example.com/vocab#geometry",
    "id": "http://example.com/vocab#id",
    "provenance": "http://example.com/vocab#provenance",
    "precision": "http://example.com/vocab#precision",
    "properties": "http://example.com/vocab#properties",
    "type": "http://example.com/vocab#type"
  },
  "@type": ["Feature", "Instant", "when"],
  "geometry": {
    "type": "Point",
    "coordinates": [
      0.0,
      0.0
    ]
  },
  "when": {"Instant": "2014-04-24",
              "provenance":"foo",
              "precision":"bar"},
  "type": "Feature",
  "properties": {}
}

If you delete the when from the context, the later block is ignored by the JSON-LD parser. So I say if your Instant is just an Instant, go flat. If it is something more (like a CAP alert onset), wrap it in an onset and define it in the context.

The thing that I need to confirm is that a JSON-LD parser can determine, let's say, the Instant of the feature by either its Instant property OR the Instant property of one of its child properties. However, if you can't I'm not sure how one can ever get this to work. Let's say we put everything under when. Well when has a specific meaning as defined in the context - we can't come back later and say that in this document a when is both a when and an onset, right? I think you would have to duplicate the property.

[kgeographer]

I had the impression no "when" was a done deal. I've expressed support for it multiple times and continue to!

------------------Karl Grossner, Digital Humanities Research DeveloperStanford University LibrariesStanford,CA USwww.kgeographer.org

----- Sean Gillies notifications@github.com wrote:

@sfsheath pointed out something important at https://github.com/geojson/geojson-ld/issues/9#issuecomment-41752563: with no "when" object, there's no good way to annotate the temporal information. Where would you put provenance and precision? We'd lose the ability to express more precisely what "when" means in our data. Something like

@context:
  "when": {
    "@type": ["http://geojson.org/vocab#when", "http://example.com/vocab#lifetime"]
   }

where you say that "when" in your data means the "lifetime" of a feature (I'm pulling this property out of thin air) wouldn't be possible except by annotation of the Feature object.

---

Reply to this email directly or view it on GitHub: https://github.com/geojson/geojson-ld/issues/13#issuecomment-41808559

[sgillies]

Closing after the show of hands (see #9).