[GeoJSON] Integrating GeoJSON with other kinds of data via JDIL

[Sean Gillies]

Chris,

Plain old dumb JSON is satisfying a web programmer's need to send dicts 
over the wire. It's a sweet solution to a clearly demonstrated need. 
Let's keep the distinction between GeoJSON (dumb data) and JDIL 
(semanticly rich data) instead of putting unwarranted RDF and XML-isms 
into GeoJSON.

I'm opposed to the @type and @values constructs, and also opposed to 
magical-looking member names such as "@type". Frankly, I am holding my 
nose about the "types" member of GeoJSON collections and features, and 
I'd rather we made the types/@types confusion go away by dropping the 
GeoJSON type members except in the case of geometries, where it is 
needed to distinguish between otherwise identical line and polygon 
representations.

I might very well use JDIL in some applications, but I'd rather we 
didn't encumber the simplest thing that could possibly work: plain JSON.

Cheers,
Sean

chris goad wrote:
> Re geojson:type and JDIL @type:
> 
> Yes, I agree, a  best practices doc rather than a GeoJSON spec modification 
> (realized already in the GeoJDIL wiki page by Christopher Schmidt!)  goes 
> almost all of the way towards  achieving the practical goals of GeoJSON/JDIL 
> integration.   However, there is one more possible improvement.
> 
> JDIL has a construct for representing multi-valued properties:, which looks 
> like this:
> 
> "propname":{"@values":["value0","value1"]}
> 
> 
> If  GeoJSON "type" and JDIL "@type" were collapsed into one property, then 
> the two lines:
> 
>  "@type": "atom:item",
>   "type": "Feature",from the example on the GeoJDIL wiki page could be 
> written:
> 
> "@type":{"@values":["atom:item","Feature"]}
> 
> or
> 
> "type":{"@values":["atom:item","Feature"]}
> 
> depending on which direction of collapse is chosen.  This way of doing 
> things is easier to understand.  Unless I am mistaken, GeoJSON is using 
> "type" to mean type membership in the usual sense, and does not denote some 
> specialized typing that applies only  to  geometry.  If so, it  is confusing 
> to have two names for the same thing, and to  mandate the use one or the 
> other depending on circumstances.
> 
> There are three ways to achieve the type/@type collapse:
> 
> 1) The GeoJSON spec is left unchanged, but a transformation which replaces 
> "type" by "@type" is mandated when embedding GeoJSON in JDIL.
> 
> 2) The JDIL spec is modified to endorse vocabulary-specific synonyms of 
> "@type"  - either "every vocabulary's  'type' property, if present, shall be 
> construed as a synonym of  '@type'", or "GeoJSON's 'type' property is a 
> synonym of  '@type'"
> 
> 
> 3) The GeoJSON spec is modified to change the property name "type" to 
> "@type".
> 
> 
> Option 3 involves zero  addition of complexity to GeoJSON parsers - there is 
> no implication that the injection of one "@" symbol implies support for any 
> other JDIL primities. It is only a name change.
> 
> In contrast, options 1)  and 2) add complexity and real work for developers.
> 
> Note that JDIL doesn't have the option of a simple name subsitution in the 
> opposite direction of option 1) - using "type" without the @.  This is 
> because "type" might be defined in the base namespace (eg GeoJSON if 
> unaltered!), leading to conflict with JDIL's own "type".
> 
> Are there other options?
> 
> -- Chris
> 
> 
> ----- Original Message ----- 
> From: "Christopher Schmidt" <crschmidt at metacarta.com>
> To: "Panagiotis (Peter) A. Vretanos" <pvretano at cubewerx.com>
> Cc: <geojson at lists.geojson.org>
> Sent: Friday, June 01, 2007 10:17 AM
> Subject: Re: [GeoJSON] Integrating GeoJSON with other kinds of data via JDIL
> 
> 
>> On Fri, Jun 01, 2007 at 12:23:56PM -0400, Christopher Schmidt wrote:
>>> On Fri, Jun 01, 2007 at 12:13:39PM -0400, Panagiotis (Peter) A. Vretanos 
>>> wrote:
>>>> 3) Add a and @type parameter (e.g. "@type": "myns:BUILTUPA_1M").
>>> Hm. that's a point. Most people who think about 'types' in this way are
>>> actually talking about feature types. I hadn't thaough about that. How
>>> is 'myns:BUILTUPA_1M' described in the JSON now?
>> Okay, after discussing with other people on #geojson, we've established:
>>
>> * KML has not seriously suffered due to lack of feature types.
>> * Feature types in existing implementations (for example, my
>>   WFS translation of FeatureServer input from JSON) are just faked up
>>   based on using the layer name, and have little to no actual meaning.
>>
>> As a result:
>> * '@type' is something which can be delivered in GeoJDIL. If it is
>>   available, it is expected to be a feature type. Users who ask how to
>>   use featuretypes should be using geojdil and geojdil friendly parser.
>>
>> I'm going to write this example into the specification.
>>
>> Regards,
>> -- 
>> Christopher Schmidt
>> MetaCarta
>> _______________________________________________
>> geojson mailing list
>> geojson at lists.geojson.org
>> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org 
>