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