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

[Renato De Giovanni]

Good question. It's also not easy for me to draw a line between RESTful
and RESTless services.

Although TAPIR is based on operations, which could be seen as something
closer to an RPC approach, it has just a few quite generic operations. On
the other hand, for sure TAPIR offers simple ways to interact with the
service and to easily expose URLs for any underlying resource (using the
term "resource" here in the general sense). REST junkies can even
configure re-write rules very easily on a web server to allow "cleaner"
URLs for resources that are exposed through a TAPIR service.

I don't think TAPIR is harder just because you need to follow a
specification - this could actually make things easier, obviously
depending on the complexity of the specification. Remember that TAPIR was
created to be used by distributed data providers who want to share the
same kind of data using the same protocol, so there's all that additional
stuff related with data abstraction, conceptual schemas, etc. The BCI
service seems to be built on top of a central database in a single data
provider scenario (or am I wrong?) so it's understandable not to use
TAPIR.

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