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
Cool. Looking forward to it,
Posted by: steve | May 20, 2006 at 11:39 PM
Waiting patiently. I've got big plans for leveraging the API. When is it gonna be available?
Posted by: Mark | June 02, 2006 at 01:09 PM