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

[Carl Reed <[e-mail]>]

Sean -

While I am no expert on modeling time, I do have some questions and
observations.

Perhaps it is a mistake to not be consistent with or even reference RFC
3339 (which is a profile of ISO 8601). I believe that you can specify a
DATE only that is 8601 compliant. I would also suggest that you consider
the use of case of an event that crosses time zones. How will that use case
be handled? And what about time zone offsets. 8601 states that if a time
zone (UTC offset) is not specified, then local time is assumed. However, in
my mind assuming local time introduces potential ambiguities that could
impact interoperability. Finally, I would suggest that any temporal
extensions to GeoJSON use a vocabulary that is consistent with a raft of
international standards that deal with time/temporal/timeseries.

For example, your use of "instant" is consistent with international best
practice and as documented in ISO 19108 (see below). The actual ISO
definition is "instant: point representing position in time". However, your
use of "interval" may not be entirely consistent as "interval" is often
used in the context of the time scale. An interval scale offers a basis for
measuring duration.

Below are some publicly accessible ISO documents (no fees) that deal with
time.

ISO 19103:2015 Geographic information -- Conceptual schema language
infostore.saiglobal.com/store/PreviewDoc.aspx?saleItemID=2636892

ISO 19108:2002 Geographic information — Temporal schema (recomfirmed in
2015)
http://people.ischool.berkeley.edu/~ryanshaw/pdf/ISO_19108.pdf

Examples of using and referencing these standards can be found in most any
OGC standard that has a temporal component. For example, from the recently
published OGC PubSub standrd: "The UML shown in this standard is considered
conceptual and abstract, and should not be interpreted as an implementation
strategy for bindings that extend and implement this standard. For example,
TM_Instant from ISO 19108 is used to represent time instants for conceptual
clarity, but bindings and implementations of this standard may realize
TM_Instant as a GML TimeInstant, an ISO 8601 date string, or any other
representation that is consistent with TM_Instant."

I know that you want to keep this extension simple but my concern is
clarity of the wording and consistency with international best practice,
both of which lead to enhanced interoperability.

Thanks for listening.

Regards

Carl

On Tue, Jan 10, 2017 at 1:05 AM, Sean Gillies <[e-mail]>
wrote:

> Indeed, Matthias, thanks for pointing out this issue with RFC 3339. Being
> able to use a date (no time) is important for some applications. I'll
> remove the normative reference to RFC 3339.
>
> On Sat, Jan 7, 2017 at 5:27 PM, Matthias Müller <
> [e-mail]> wrote:
>
>> Hi Sean,
>>
>> the interval definition looks perfect to me.
>>
>> To verify the time string question, I took a re-read of RFC 3339 and
>> stumbled over this passage in section 5:
>>
>> "The following section defines a profile of ISO 8601 for use on the
>>    Internet.  It is a conformant subset of the ISO 8601 extended format.
>>    Simplicity is achieved by making most fields and punctuation
>>    mandatory."
>>
>> The BNF is this:
>>
>> full-date       = date-fullyear "-" date-month "-" date-mday
>> partial-time    = time-hour ":" time-minute ":" time-second
>>                      [time-secfrac]
>> full-time       = partial-time time-offset
>> date-time       = full-date "T" full-time
>>
>>
>> My reading of this is that RFC 3339 demands the date-time representation
>> for all timestamps (all the examples in the RFC seem to support this view).
>> This requires at least 1-second precision and make the use of time second
>> fractions optional.
>> This is reasonable for the purpose of RFC 3339 but may conflict with your
>> intentions for GeoJSON Events.
>>
>>
>> Matthias
>>
>>
>> On 07.01.2017 13:52, Sean Gillies wrote:
>>
>>> 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-geoj
>>> son-events.html.
>>>
>>> On Thu, Jan 5, 2017 at 1:37 PM, Martin Daly <[e-mail]
>>> <mailto:[e-mail]>> 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:[e-mail]
>>>     <mailto:[e-mail]>] *On Behalf Of *Sean Gillies
>>>     *Sent:* 04 January 2017 09:33
>>>     *To:* [e-mail] <mailto:[e-mail]>
>>>     *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
>>>     <https://github.com/sgillies/geojson-events>____
>>>
>>>     and have drafted a spec:____
>>>
>>>
>>>
>>>     https://sgillies.github.io/geojson-events/draft-gillies-geoj
>>> son-events.html
>>>     <https://sgillies.github.io/geojson-events/draft-gillies-geo
>>> json-events.html>
>>>         https://sgillies.github.io/geojson-events/
>>>     <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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/geojson
>>>
>>>
>> _______________________________________________
>> GeoJSON mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/geojson
>>
>
>
>
> --
> Sean Gillies
>
> _______________________________________________
> GeoJSON mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geojson
>
>


-- 
Carl Reed, PhD
Carl Reed and Associates

Mobile: [phone]

"When the power of love overcomes the love of power the world will know
peace." Jimi Hendrix