There seem to be several mechanisms around to serialize RDF in JSON, e.g. http://n2.talis.com/wiki/RDF_JSON_Specification and http://www.gbv.de/wikis/cls/RDF_in_JSON
which may actually produce the same JSON
Also, see http://www.w3.org/TR/rdf-sparql-json-res/
--Bob
On Fri, Oct 3, 2008 at 3:41 PM, Renato De Giovanni renato@cria.org.br wrote:
... I think it was Wouter who found some time ago a generic XSLT to convert any XML to JSON. I never used it and I'm not sure if I still have a copy somewhere. A first step towards standardizing JSON representations for our objects could be to play with this kind of generic stylesheet to convert TDWG ontolgy objects represented in RDF/XML to JSON.
Best Regards,
Renato
Yes I think you are right a REST section would be good but.... What is REST? In a way the TAPIR specification (especially in its lighter versions) is 'just' a common REST specification. You pass it parameters over HTTP and you get back data as XML. On the other hand TAPIR seems more complex than just putting a REST service together. Perhaps because doing anything that meets a specification rather than just what comes to hand is going to be harder. Perhaps Renato may have comments on this.
I have actually just done a REST/JSON service for BCI.
I am nervous because it is totally not TDWG standards compliant and just a useful thing for getting data back for mashups and embedding. Effectively exposing the database to client side applications. From an engineering point of view it is dead simple - a single PHP file (within the Zend Framework). To write code to consume this is trivial (there is an example) but it is bespoke. a major thing is that the return type is JSON which I think many people think of a standard data format for REST type services.
So it would be a good to get some clarification on what we mean by REST.
Does REST tend to imply a particular return type?
If we mean REST/JSON does anyone have an idea how we could get some data typing in a JSON object so that a consuming application could tell that it is a representation of a DwC object or something from the TDWG ontology? Service description is also an issue. We end up re- inventing TAPIR if we aren't careful.
I am sure it would be trivial to wrap a TAPIR provider in something that converted the XML output to JSON enabling it to act as a data source for client mashups.
As usual I'd be grateful for opinions on this. Perhaps we should talk in Fremantle.
All the best,
Roger
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag