[GeoJSON] Integrating GeoJSON with other kinds of data (via Chris Goad)

[Christopher Schmidt]

Chris was having problems sending this to the list, and I offered to
send it for him, since I know we're rapidly moving towards a 'final'
RFC, so I wanted this out there so people were aware of it before we
'released'. 

From: chris goad <chris at platial.com>
Date: Thu, 31 May 2007 16:30:34 -0700
Subject: Integrating GeoJSON with other kinds of data

I've been working with JSON for geo for a year or so at Platial. I love the elegance and conciseness of JSON, but there were things that I missed from earlier work with RDF - not the whole  stack, but basic capabilities for data integration. JDIL  ( http://jdil.org ) , which I formulated earlier this year, was my stab at retrieving what was missing; JDIL has nothing specific to do with geo, but implementing geo inside JDIL makes it play well with other data. I have been using GeoRSS for the geo aspect, but would like to switch  to GeoJSON.

Here's a bit about JDIL:

JDIL specfies two simple ways to enhance JSON's  capability for  integrating data from diverse vocabularies and sources. The first is namespaces - namespace definitions appear as the value of the @namespaces property, and are utilized via qualified names for properties. The second is use of URIs as object labels (these labels appear as the value of the @id property).  The latter allows encoding of object graphs, rather than only trees, and supports merging of property-value assertions from different sources about the same object.  With very little effort, the major benefits of the RDF data model are captured within the JSON framework (RDF need not be mentioned in explanations of JDIL!)

Minor changes in GeoJSON would make it compliant with these conventions, and as a consequence would allow  GeoJSON to be smoothly mixed with other kinds of data. This is an important benefit, since geo applications that involve data of other varieties are the norm rather than the exception.  The changes : 1)  support the namespace construct, and allocate a URI for the GeoJSON namespace, 2) utilize the generic JDIL "@type" name for the type-of concept.   

In pure geo applications (eg sending feature geometry off to a client for rendering), the overhead is miniscule. A pure GeoJSON file would need only  include  this property in the root object:

"@namespaces":  {"":"http://whateverthegeojsonuriturnsouttobe"} 

This specifies a blank prefix for the GeoJSON namespace, removing the need to prefix GeoJSON properties in the body.  

Regards,
-- 
Christopher Schmidt
MetaCarta