Earliest and latest: in or out?

[sgillies]

Can we leave "earliest" and "latest" out of the GeoJSON-LD Time context? Let's reconsider this since we only have one first chance to get things right.

My concerns are complexity and necessity. There's a price to be paid in documenting why and how to use these features properly. We should be sure that it's worth the time.

GeoJSON has gone pretty far without anything to say about imprecise locations. Can a feature succession and event JSON-LD vocabulary get by just as well? Say you want to model the spatio-temporal extent of the Fremont Culture: how exactly would an application suffer from having to use the widest possible interval to represent its duration instead of the combination of "core" and "peripheral" durations?

@sfsheath thoughts?

[sfsheath]

Whoops. I thought we were agreed on including these? Fremont Culture is outside my wheelhouse.

Using ranges to indicate the starts and ends of past timespans is common. Lots of examples from science (radio carbon dating) and humanities (the start of writing as dependent on how you define writing), but I hope that statement isn't controversial.

Given the common usage, is the added difficulty of implementing the display and other use of at most two possible points for each end of a 1-dimensional line (if that's how a timespan can be described) such that we should reject that possibility?

[sgillies]

@sfsheath yeah, I was all for this 3 weeks ago, but am having second thoughts when faced with typing up instructions on how to put this into practice. I just want to review this again without all the other distractions of #9 and give @p3dr0 a chance to express his reservations clearly.

I recognize that earliest and latest attributes of an interval would be useful (I can see how I would have used them for Pleiades), but I'd consider it a failure if they got used commonly, because it complicates temporal logic, e.g., does start: 1000, earliest: 998 come before start: 999? We could leave that temporal logic entirely up to applications, but with no fuzzy geometry precedent in GeoJSON, I'm not sure how that choice would play out.

[kgeographer]

My view (and vote) is that earliest/latest are worthwhile and not a terrible burden. I think the way the scenario @sgillies presents would play out is that if an app had no means for reasoning about 'earliest' it would ignore it and work only with 'start' and 'end'; completely agree most users will not make use of it, but isn't that in part because apps that can reason about such things don't exist, because there isn't much data modeled that way? Getting the universe of GeoJSON users thinking about time will change that IMHO.

Simile Timeline has paved the way ( http://www.simile-widgets.org/timeline/examples/monet/monet.html ) and illustrates that unnecessary keys can be ignored and still get good results. I think the pattern is simple and well-worn enough to proceed with it, and that it could stimulate apps that do a better job of temporal reasoning and visualization. For instructions to developers on putting into practice, there are two sets of issues, reasoning and display. For the latter, simply referring to Simile Timelines would go a long way ( http://simile-widgets.org/wiki/Timeline_Event_Display ). For reasoning, it's left to the imagination of developers how to take this past what Simile Timeline offers.

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

@sfsheath yeah, I was all for this 3 weeks ago, but am having second thoughts when faced with typing up instructions on how to put this into practice. I just want to review this again without all the other distractions of #9 and give @p3dr0 a chance to express his reservations clearly.

I recognize that earliest and latest attributes of an interval would be useful (I can see how I would have used them for Pleiades), but I'd consider it a failure if they got used commonly, because it complicates temporal logic, e.g., does start: 1000, earliest: 998 come before start: 999 ? We could leave that temporal logic entirely up to applications, but with no fuzzy geometry precedent in GeoJSON, I'm not sure how that choice would play out.

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

[sgillies]

@kgeographer I'm more concerned that people will use earliest/latest, and improperly or superfluously. People struggled with implementing coordinate order in their GeoJSON despite it being clearly written in the spec. I fear that we could see data that has only earliest/latest and no start/stop.

How about this: will @kgeographer or @sfsheath send a pull request with solid documentation of these items in https://github.com/geojson/geojson.github.io/blob/master/vocab.md? Let's include these items contingent on being able to explain them unambiguously.

[kgeographer]

Points taken. The inherently conservative approach required for standards is not something I've delved in to date; only dreaming them up in arm-wavy academic style or building one-off things that will never be standardized. Glad to take a stab at this, within the next few days. @sfsheath if you do also we can compare notes, and/or @sgillies can accept both and a collective comment/edit ensue.

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

@kgeographer I'm more concerned that people will use earliest/latest, and improperly or superfluously. People struggled with implementing coordinate order in their GeoJSON despite it being clearly written in the spec. I fear that we could see data that has only earliest/latest and no start/stop.

How about this: will @kgeographer or @sfsheath send a pull request with solid documentation of these items in https://github.com/geojson/geojson.github.io/blob/master/vocab.md ? Let's include these items contingent on being able to explain them unambiguously.

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

[kgeographer]

The task of describing a when object turns out to be hard, and lead to further questions of scope. [edit: this concerns the reframing topic raised in https://github.com/geojson/geojson-ld/issues/17]

A few points:

• Why not mimic geometry/GeometryCollection with when/WhenCollection?
• GeoJSON appropriately offers no advice on how to render or compute over a geometry. This is less straightforward with "when." Points, Polylines and Polygons are unambiguously described in terms of coordinates in a universally recognized reference system. An Instant does not correspond to a Point unless you declare an "atom." Is it a second, a minute? The idea of an hour, day, month or year Instant is counterintuitive. As @sgillies has noted, there would have to be a default meaning, such as 'first moment.' Easy to see an argument for centroid.
• I keep returning to Simile Timeline because a) these questions have been thought out there, and b) it has had considerable uptake. So once again citing them:
  • An Instant can be described by a single start value or by a start-end pair w/ optional latestStart and earliestEnd.
  • In the first case, the meaning is 'first minute of'
  • In the second case, it's meaning is 'some time during' the interval between firstminute(start) and lastminute(end)
  • An Interval can be described by a start-end pair w/ optional latestStart and earliestEnd
• But standards like GeoJSON-LD are not in the business of deciding meaning; all this does is allow flexibility.

If this makes sense I will submit relevant draft entries for vocab.md

---

{ "type": "FeatureCollection",
  "features": [
    { "type": "Feature",
        "id": "e01",
      "geometry": {"type": "Point", "coordinates": [102.0, 0.5]},
      "when": {"type":"Instant", start": "1832-08-01T16:00+00:00"}
      "properties": {
        "prop0": "value0",
        "label":"4pm UTC on 01 Aug 1832"
      }
    },
    { "type": "Feature",
        "id": "e02",
      "geometry": {
         "type": "Polygon",
         "coordinates": [
           [ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0],
             [100.0, 1.0], [100.0, 0.0] ]
           ]
       },
       "when": {"type": "Instant", "start":"1833-01-01", "end":"1833-01-31"}
       "properties": {
         "label": "at some point in time during Jan 1833",
         "prop1": {"this": "that"}
         }
       }
   }, { "type": "Feature",
        "id": "e03",
      "geometry": {
        "type": "LineString",
        "coordinates": [
          [102.0, 0.0], [103.0, 1.0], [104.0, 0.0], [105.0, 1.0]
          ]
        },
      "when": {
        "type": "Interval",
        "start": "1832-08-02", "latestStart": "1832-08-04", "end": "1833"
      },
      "properties": {
        "label": "began some time betw. 02 and 04 Aug 1832 and ended in 1833",
        "prop1": 0.0
        }
    }
   ]
}

[sgillies]

@kgeographer I've made a fairly big update to https://github.com/geojson/geojson.github.io/blob/master/vocab.md and it's ready for changes to "earliest" and "latest".

The live entry point to temporal stuff is http://geojson.org/vocab#when.

[sgillies]

Earliest and latest aren't going to be needed now that we've introduced "circa". circa["start'"] and circa["stop"] are now the earliest and latest date/time for a feature or feature collection.