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

Matthias Müller <Matthias_Mueller@tu-dresden.de> Sat, 07 January 2017 16:27 UTC

Return-Path: <Matthias_Mueller@tu-dresden.de>
X-Original-To: geojson@ietfa.amsl.com
Delivered-To: geojson@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1C7129967 for <geojson@ietfa.amsl.com>; Sat, 7 Jan 2017 08:27:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.499
X-Spam-Level:
X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbB4MvHHp689 for <geojson@ietfa.amsl.com>; Sat, 7 Jan 2017 08:27:29 -0800 (PST)
Received: from mailout5.zih.tu-dresden.de (mailout5.zih.tu-dresden.de [141.30.67.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4E8C129599 for <geojson@ietf.org>; Sat, 7 Jan 2017 08:27:28 -0800 (PST)
Received: from mail.zih.tu-dresden.de ([141.76.14.4]) by mailout5.zih.tu-dresden.de with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <Matthias_Mueller@tu-dresden.de>) id 1cPtq2-0006rA-8T for geojson@ietf.org; Sat, 07 Jan 2017 17:27:26 +0100
Received: from port-92-195-13-65.dynamic.qsc.de ([92.195.13.65] helo=[192.168.178.31]) by server-50.mailclusterdns.zih.tu-dresden.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from <Matthias_Mueller@tu-dresden.de>) id 1cPtq1-00056k-Nq for geojson@ietf.org; Sat, 07 Jan 2017 17:27:25 +0100
From: Matthias Müller <Matthias_Mueller@tu-dresden.de>
To: geojson@ietf.org
References: <CAOodmJomw-0VymQYyPHLCR+Ds+dpEmFe=2j+FnZGh19bf1DUbg@mail.gmail.com> <5c9ebf53b24d4fce8c9fe3903b3e6177@SRV016VEX.cadcorp.net> <CAOodmJqAJsw8wR_WrKaWHWWb73ngD=u8Q6-zER_8L6rTWL-FCg@mail.gmail.com>
Message-ID: <022c2c55-b456-fa7f-1999-00508366fb96@tu-dresden.de>
Date: Sat, 07 Jan 2017 17:27:25 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAOodmJqAJsw8wR_WrKaWHWWb73ngD=u8Q6-zER_8L6rTWL-FCg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-TUD-Original-From: matthias_mueller@tu-dresden.de
X-TUD-Virus-Scanned: mailout5.zih.tu-dresden.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/geojson/ro1rqtTbasowllcA-aphnPx3kh4>
Subject: Re: [Geojson] Requests for comments on GeoJSON Events draft
X-BeenThere: geojson@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF GeoJSON WG <geojson.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geojson>, <mailto:geojson-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/geojson/>
List-Post: <mailto:geojson@ietf.org>
List-Help: <mailto:geojson-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geojson>, <mailto:geojson-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Jan 2017 16:27:31 -0000

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-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
>     <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/draft-gillies-geojson-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
> GeoJSON@ietf.org
> https://www.ietf.org/mailman/listinfo/geojson
>