XTech Part II: API (Platial News and Neogeography)

Chris Goad, Platial Chief Architect finally had some time to focus on the Platial api (He's been trying to find the time for months) and he gave a brief demo at XTech while he spoke about the People's Atlas and the technology required to support it. Part III next week will cover the rest of the technology infrastrcture components and talk about how excited we are to find ways to collaborate with Open Street Maps.

Technical Architecture for the People's Atlas

Platial aims to contribute to an ecology of shared geodata, not to build an isolated platform. This aim has guided the design of our georepository and API. The elements of our technology are: 1) A repository architecture that supports user contribution of data types, not just data; 2) an API that enables federation of repositories ; 3) our own running repository (of course); 4) GeoRSS feeds, and 5) A carefully engineered user interface for the web public.

Here are some details related to the api.

The new Platial API gives developers full access to our repository. The Design goal (for Platial in general and the API in particular):

Support for user contributed vocabularies, not just user contributed content.
Will allow birders, architectural historians, surfers to invent their own vocabularies for describing their Platial places and events.
The API will support insertion and retrieval of located items expressed in user-contributed vocabularies

Approaches to User Contributed Vocabularies

Low end: Tagging : Simple, but limited expressiveness
High end: GML Application Schemas / WFS : way too hard for most target developers
In between: Free-form property sheets (EVDB API, Google Base)

But for Geo Apps, property sheets fall a bit short

Many vocabularies will be used together to describe common objects (eg La Scala as historic building and La Scala as event venue) - can't have them bumping into each other

Platial Approach

Classes are relevant - geo is a comparatively structured domain
Namespaces for vocabularies; properties have qualified names
Classes are defined by lists of required/optional properties + types for the properties

This is RDF

However the API is formulated in a way that requires no background in RDF from developers
We introduce the RDF data model as

JSON + URI names for things + namespaces - following the lead of Masahide Kanzaki; Details at http://platial.com/services/jsonrdf

Example API call - POST the following to http://platial.com/json
{
"api:method":"get",
   "arg:subject":"<http://platial/rdf/item/1234>",
   "arg:properties":
      ["dc:title","dc:author","cgeo:address","georss:point"]
}
or in REST

http://platial.com/rest?method=get& subject=http://platial/rdf/item/1234& properties=dc:title,dc:author,cgeo:address,georss:point

Result
{
"rdf:type":"cgeo:Place",
"@about":"<http://platial.com/rdf/item/52643>",
"dc:title":"Cha Cha Cha",
"dc:author":"platialUser:jason",
"cgeo:address":{
"rdf:type":"vCard:ADRTYPES",
:vCard:Street":"1208 NW Glisan Street",
"vCard:Locality":"Portland",
"vCard:Region":"Oregon",
"vCard:Country":"US”

},
"georss:point":"45.525683 -122.683661”
}

API is fully specified and documented. See http://platial.com/services/api
If you want to be involved in trying/testing the api before release at the end of the month, feel free email diann-at-platialdotcom