Re: [Geojson] Temporal Digest, Vol 33, Issue 3

[Karl Grossner <[e-mail]>]

Simon,

With apologies for the delay; I've been traveling with spotty internet.
Many thanks for the comments, some responses below

Karl

----------------------------------------------------------------------

> Date: Mon, 9 Jan 2017 00:27:36 +0000
> From: <[e-mail]>
> To: <[e-mail]>, <[e-mail]>, <
> [e-mail]>
> Subject: Re: [Temporal] [Geojson] Requests for comments on GeoJSON Events
> draft
>
> A few observations:
> ​ ​
>
> 1.     Yes ? this treats temporal properties the same way as geometrical
>

​I think there will be many interesting computations that can be done with
4-part timespans as "temporal geometry,"​

​and began exploring that a few years ago (
http://dh.stanford.edu/topotime/docs/TemporalGeometry.pdf/) I'll revisit
this with the new, simpler GeoJSON-T.


> 2.     The proposed four timespan properties make sense, but do not appear
> to align specifically with any existing theory. In particular:
>
> a.     Latest start and earliest end appear to combine considerations of
> topology and uncertainty. I haven?t seen these elsewhere.
>
> ​One theoretical basis is Allen's interval algebra; the 4-part timespan
simply says that intervals are not necessarily bounded by instants, but can
be by intervals. I have in the past cited a fine 2010 paper that delves
into that more deeply than I have yet. Unfortunately a blog post describing
its relevance to my work is lost to time because of a wordpress hosting
switch I made. The paper is:

Kauppinen, T., Mantegari, G., Paakkarinen, P., Kuittinen, H., Hyvönen, E.,
& Bandini, S. (2010). Determining relevance of imprecise temporal intervals
for cultural heritage information retrieval. *International journal of
human-computer studies*, *68*(9), 549-560.

It can be retrieved here:
http://kauppinen.net/tomi/temporal-relevance-ijhcs2010.pdf

But you are correct, there needs to be a theoretical paper/post behind my
own work; I've fallen out of the habit of writing as I press forward with
engineering.

In talks I often point to the 18c timeline illustrations of Joseph
Priestley which indicate "fuzzy" timespans so: - - - -------- - - -
http://math.yorku.ca/SCS/Gallery/images/priestley.gif
I argue the conceptual model is intuitive, and does correspond to the
concepts of 'terminus post quem and terminus ante quem. My 'start' and
'end' are by inference 'earliest start' and 'latest end'


b.     I don?t really understand the rationale for making start m
> ​​
> andatory compared with end. Rather, I?d suggest either all optional, or
> possibly one of start and end mandatory.
>

​I'm not clear how the "when" of a feature could have no temporal assertion
whatsoever; the entire "when" element (member) is optional.


> 3.     Intervals all the way down matches Allen?s temporal calculus. Note
> that this is implemented in OWL-Time, currently under revision by the joint
> OGC/W3C Spatial Data on the Web working group. Since GeoJSON-T has no
> backward compatibility issues, and in the spirit of reducing unnecessary
> divergence, it might be worth aligning with that. See
> http://w3c.github.io/sdw/time/ and https://www.w3.org/TR/owl-time/

​
There is a lot to like about the Time Ontology in OWL, but my assessment is
that GeoJSON will never (and shouldn't) support an elaborate formal
ontology in its entirety and I'm not sure what the implications of
declaring a partial alignment are. Making a (relatively) simple temporal
extension to GeoJSON is a very practical thing I can contribute to.
GeoJSON-T has a key goal of usability by the average historical scholar.
All that said, the conceptual model beneath GeoJSON-T is an "ontology
design pattern," and as such it needs to be written up in OWL(!); at that
stage alignment with larger ontologies can be considered.

It is my fervent hope to be able to organize an international meeting soon
bringing together many of us who have been "wrangling" time in recent
years. There was a lot of support for that idea at the recent Linked Pasts
meeting in Madrid.

kg
​


> From: GeoJSON [mailto:[e-mail]] On Behalf Of Karl Grossner
> Sent: Monday, 9 January, 2017 06:43
> To: [e-mail]; [e-mail]
> Subject: Re: [Geojson] Requests for comments on GeoJSON Events draft
>
>
> Hello,
>
> [copying temporal OGC list b/c topic was cross-referenced recently]
>
> I've recently posted "A Case for GeoJSON-T" on my blog (
> http://kgeographer.com/a-case-for-geojson-t/) with some additional
> details on the Topotime repo wiki (https://github.com/kgeographe
> r/topotime/wiki). Both refer to my recent efforts adding "when" to
> GeoJSON datasets, and beginning to make some software that interprets them.
>
> Surely I'm in favor of adding "when," but depart from Sean's draft in a
> few ways, briefly:
>
> 1. I allow a "when" to be a sibling of a "geometry" wherever it may be
> (i.e. Feature, GeometryCollection). Then I rely on that to build (in the
> case of journeys/itineraries) FeatureCollections with some number of Place
> Features and a single Path Feature with multiple segments within a
> GeometryCollection.
>
> 2. I account for timespans with up to 4 parts: start, latest start,
> earliest end, end. Only start is required. While I recognize many (even
> most) datasets will not use all 4, and that GeoJSON does not handle spatial
> fuzziness even to this limited extent, I see no harm in allowing for it.
> That is, recommending a syntax so there can be commonality in future data
> stores that DO use it. It adds no burden I can tell on those who ignore it.
> The pattern is intuitive and has been well-received when I describe it in
> talks.
>
> 3. I don't think all temporal expressions reduce neatly to instants and
> intervals, rather it's intervals all the way down so to speak. Also, I
> think there is a basic distinction between events that occur _throughout_ a
> given interval and those that occur _at some time during_ an interval. That
> distinction will be important for many visualizations and computations. For
> example, a birth for which only the year is known. The draft suggests a
> start:YYYY and type:instant would be parsed as _at some time during_, is
> that right? My GeoJSON-T proposes a "duration" element within "when" that
> would handle this differently.
>
> I do recognize that GeoJSON-T pushes the envelope more than some would
> care to; my rationale is simple -- I'm trying to meet very specific use
> cases (described in the various posts and wiki), and plowing forward with
> what works. All of it is subject to revision. Ideally, I'd like to see
> GeoJSON add time, obviating the need for a "-T' extension.
>
> Comments of course welcome here and at any of the referenced locations,
> twitter, etc
>
> Karl
>
> --------
>
> Karl Grossner, @kgeographer
>
>