Perhaps I missed this, but what is the requirement driving serialization of RDF or XML in JSON? Adoption of REST strategies does not require or even imply JSON encoding, so is the goal to provide rich content to browsers that is easily parsed by javascript applications?
In any case with the variety of formats and tools available for serializing RDF it is trivial (assuming that the XML, RDF/XML, or whatever is being produced on the fly) to support agent-driven content negotiation and have the web server respond with appropriately serialized content based on the mime type indicated in the HTTP Accept header forwarded by the client (json = application/json, rdfxml = application/rdf+xml). I guess one could also request text/csv if semantics weren't of interest.
Dave V.
On Oct 3, 2008, at 14:39 , Bob Morris wrote:
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
-- Robert A. Morris Professor of Computer Science UMASS-Boston ram@cs.umb.edu http://bdei.cs.umb.edu/ http://www.cs.umb.edu/~ram http://www.cs.umb.edu/~ram/calendar.html phone (+1)617 287 6466 _______________________________________________ tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag