[Geojson] Was: Requests for comments on GeoJSON Events draft

HI Matthias, Joan, Carl, etc,

Belated Happy New Year (Gregorian).

I think it would be useful if the GeoJSON Event people were aware of the revamped W3C Time Ontology that is in the pipeline. The latest Editor's Draft is at http://w3c.github.io/sdw/time/ . Of course they may be very aware of it anyway.

There may be a vote to release it for public comment as an official W3C First Public Working Draft later today.

The ontology should give a stable persistent framework for attaching a variety of temporal attributes to other entities, while allowing a variety of calendars and temporal reference system to be used unambiguously. 

Chris 

-----Original Message-----
From: JSONsubgroup [mailto:jsonsubgroup-bounces@lists.opengeospatial.org] On Behalf Of Matthias Müller via JSONsubgroup
Sent: Sunday, January 08, 2017 3:58 PM
To: Joan Masó; 'Carl Reed'; temporal@lists.opengeospatial.org; JSONsubgroup@lists.opengeospatial.org
Subject: Re: [JSONsubgroup] [OAB] Fwd: [Geojson] Requests for comments on GeoJSON Events draft

Joan, all,

the GeoJSON Events draft does *not* prevent the use of multiple time attributes.
The spec is about events (mind the title) and I would assume, that any event has some kind of "primary" time attribute, that is when the event actually happens (most often: real word time, sometime database time - just pick one that suits the application / domain context). If you can accept this, "when" naturally goes with that primary time attribute.

Additional time properties can still appear in GeoJSON's properties{} object next to other feature attributes.

Matthias

On 08.01.2017 15:11, Joan Masó via JSONsubgroup wrote:
> Hi,
>
>
>
> Interesting. I was not aware of this initiative. In my first initial
> look, I see that they suggest the use of “when”. It has the same
> problems than “geometry”. There is not semantic associated with it and
> you can only have one.
>
> From the meteo people we have learnt that “time” has different meanings.
> There is the time of creation of capture, the update, the forecast, the
> forecast validity… “When” needs semantics and there an be plenty of them
> in a single object.
>
>
>
> FYI chapter 6 in the 16-122r1 Testbed-12 JSON and GeoJSON User Guide
> discusses about time:
> https://portal.opengeospatial.org/files/?artifact_id=72307&version=1
>
>
>
> Joan Masó
>
> UAB-CREAF
>
>
>
> *De:*OAB [mailto:oab-bounces+joan.maso=uab.cat@lists.opengeospatial.org]
> *En nombre de *Carl Reed via OAB
> *Enviado el:* sábado, 07 de enero de 2017 19:20
> *Para:* temporal@lists.opengeospatial.org;
> aviation.dwg@lists.opengeospatial.org; OGC Architecture Board
> *Asunto:* [OAB] Fwd: [Geojson] Requests for comments on GeoJSON Events draft
>
>
>
> All
>
> For those of you interested in time, events, and related geospatial
> topics, the GeoJSON folks have defined a draft extension to GeoJSON for
> events. A major component of the extension is defining time. I suggested
> they look at the work of the OGC - but no response.
>
> So, perhaps those of you with more knowledge about these topics can
> provide input. Anyone can join the IETF GeoJSON email list - free.
>
> Thanks
>
> Carl
>
> ---------- Forwarded message ----------
> From: *Sean Gillies* <sean.gillies@gmail.com
> <mailto:sean.gillies@gmail.com>>
> Date: Sat, Jan 7, 2017 at 5:52 AM
> Subject: Re: [Geojson] Requests for comments on GeoJSON Events draft
> To: "geojson@ietf.org <mailto:geojson@ietf.org>" <geojson@ietf.org
> <mailto:geojson@ietf.org>>
>
> Dear all,
>
> Thanks for the feedback. I've made sure that the draft uses start/end
> (following the Activity Streams 2.0 spec and suggestions here) and
> explains that the values are on the boundary of intervals. Version -01
> of the draft is now at
> https://sgillies.github.io/geojson-events/draft-gillies-geojson-events.html.
>
>
>
> On Thu, Jan 5, 2017 at 1:37 PM, Martin Daly <Martin.Daly@cadcorp.com
> <mailto:Martin.Daly@cadcorp.com>> wrote:
>
> You know me: I think that the “when” object belongs **inside** the
> “properties” object.
>
>
>
> If everyone did it like that then the implementations would (eventually,
> if they don’t already) support structure within the “properties” object,
> which, I think, is more interoperable than N new objects alongside
> “properties”.
>
>
>
> And, purely subjectively, I’d stick with start/end.
>
>
>
> Martin
>
>
>
>
>
> *From:*GeoJSON [mailto:geojson-bounces@ietf.org
> <mailto:geojson-bounces@ietf.org>] *On Behalf Of *Sean Gillies
> *Sent:* 04 January 2017 09:33
> *To:* geojson@ietf.org <mailto:geojson@ietf.org>
> *Subject:* [Geojson] Requests for comments on GeoJSON Events draft
>
>
>
> Hi and Bonne Année all,
>
> With help from many of you, I've been working on a GeoJSON extension for
> event-like features
>
>     https://github.com/sgillies/geojson-events
>
> and have drafted a spec:
>
>
>
> https://sgillies.github.io/geojson-events/draft-gillies-geojson-events.html
>     https://sgillies.github.io/geojson-events/
>
> It's pared down dramatically from what we discussed in the past. Fuzzy
> time periods are out and so are temporal bounding boxes because the use
> cases for these are rare. GeoJSON has been doing well so far without any
> representation of fuzzy geometry and I think the situation is about the
> same for time.
>
> I received an suggestion to consider ISO 8601 style time intervals. This
> would allow a single string value to represent an instant or interval,
>
>     "when": "2017-01-04/2017-01-05"
>
>
>
> instead of
>
>     "when": {"start": "2017-01-04", "stop": "2017-01-05"}
>
> but this seems harder to use because support for it in parsers is rare.
>
> I was asked about recurring intervals like "every other Friday," but I
> think this isn't necessary. GeoJSON doesn't have a concept of
> non-literal geometries either.
>
> Some time ago we arrived at rough consensus that "moving objects" and
> "event-like features" are either different things or very different
> models of the same things. Moving objects are not specified in my draft.
>
>
>
> I have two objectives for this draft:
>
> * To establish a common representation for time in GeoJSON that mappers
> of events, whether they are scientists or journalists or historians, can
> share.
>
> * To set an example for other extension projects.
>
> I'd love comments on how it can be improved to better meet those
> objectives. Thanks!
>
> --
>
> Sean Gillies
>
>
>
> --
>
> Sean Gillies
>
>
> _______________________________________________
> GeoJSON mailing list
> GeoJSON@ietf.org <mailto:GeoJSON@ietf.org>
> https://www.ietf.org/mailman/listinfo/geojson
>
>
>
>
> --
>
> Carl Reed, PhD
>
> Carl Reed and Associates
>
>
>
> Mobile: 970-402-0284 <tel:(970)%20402-0284>
>
> "When the power of love overcomes the love of power the world will
> know *peace*." Jimi Hendrix
>