[tdwg-tag] TAG Roadmap for 2008 - Job vacancy!

[Dave Vieglais]

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 at 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.
>>>
>>> http://biocol.org/json
>>>
>>> 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 at lists.tdwg.org
>> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>>
>
>
>
> -- 
> Robert A. Morris
> Professor of Computer Science
> UMASS-Boston
> ram at 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 at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tag

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20081003/a7d49d92/attachment.html