Re: [Geojson] Extensibility of GeoJSON

Erik Wilde <erik.wilde@dret.net> Wed, 25 November 2015 09:11 UTC

Return-Path: <erik.wilde@dret.net>
X-Original-To: geojson@ietfa.amsl.com
Delivered-To: geojson@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00531B2B68 for <geojson@ietfa.amsl.com>; Wed, 25 Nov 2015 01:11:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 8Y-m6w2uA15J for <geojson@ietfa.amsl.com>; Wed, 25 Nov 2015 01:11:19 -0800 (PST)
Received: from cm03fe.ist.berkeley.edu (cm03fe.ist.berkeley.edu [169.229.218.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2ED61B2B6A for <geojson@ietf.org>; Wed, 25 Nov 2015 01:11:19 -0800 (PST)
Received: from 46-126-159-4.dynamic.hispeed.ch ([46.126.159.4] helo=dretair11.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <erik.wilde@dret.net>) id 1a1W6f-0000Xg-CY; Wed, 25 Nov 2015 01:11:19 -0800
To: geojson@ietf.org
References: <CACuR0Ku66k9BF_o7vymeKsYGPWun0zGprz0h+O0Lmfzuk8t6VQ@mail.gmail.com> <565180B0.2020005@dret.net> <CAOodmJpDD2b0vqzgb6ECbO-JZ1bCh3+XaOb5fQER6ttAfGAOJw@mail.gmail.com>
From: Erik Wilde <erik.wilde@dret.net>
Message-ID: <56557B32.40007@dret.net>
Date: Wed, 25 Nov 2015 10:11:14 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAOodmJpDD2b0vqzgb6ECbO-JZ1bCh3+XaOb5fQER6ttAfGAOJw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/geojson/d3g_8VJ0PDzMC8vipV2emp_IZtA>
Cc: Sean Gillies <sean.gillies@gmail.com>
Subject: Re: [Geojson] Extensibility of GeoJSON
X-BeenThere: geojson@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Nov 2015 09:11:21 -0000

On 2015-11-24 22:53, Sean Gillies wrote:
> On Sun, Nov 22, 2015 at 1:45 AM, Erik Wilde <erik.wilde@dret.net
> <mailto:erik.wilde@dret.net>> wrote:
>     http://tools.ietf.org/html/rfc6906 could be a foundation, but it's a
>     simple mechanism. it simply means that it is possible to signal that
>     a profile is being used, but it does not support any more fancy
>     "profile model" where for example a profile could be recognized as
>     being a refinement of an existing profile.
>     this could be added by having a top-level "profile" member that
>     would accept an array of URIs, each identifying one profile.
> A standard/information profile mechanism would be best, I agree. I don't
> see in RFC 6906 a mention of embedding profiles in documents. Are you
> suggesting doing for GeoJSON what RFC5988 proposed for HTML
> (http://tools.ietf.org/html/rfc5988#appendix-A)?

my usual recommendation re:profiles is:

- if your model supports generic and typed links, then use the "profile" 
relation type for indicating profiles. (but GeoJSON does not have 
generic typed links).

- if your model has no generic typed links, then define some way how 
profile links can be represented. make sure that you allow more than one 
profile to be indicated (that's what GeoJSON could do).

- since the profile links are resource-scoped, it makes sense to also 
allow them in HTTP link headers. the media type ideally should say that 
it's equivalent to see a profile being indicated embedded in the 
resource, or signaled via an HTTP link header.

- ideally, the media type should allow a profile media type parameter, 
so that profiles become visible on the web level and can be used, for 
example, in content negotiation.

https://github.com/dret/I-D/blob/master/Abandoned/atom-profile/draft-wilde-atom-profile-04.txt 
is where i tried to write a blueprint of how profiles (ideally) should 
be used. i abandoned this one a while ago because of a lack of interest, 
but if could serve as a starting point if there was some momentum to 
support profiles in GeoJSON.

cheers,

dret.

-- 
erik wilde | mailto:erik.wilde@dret.net |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |