Wednesday, June 17, 2009

Looking for JSON, ReST, (and in-memory RDF) frameworks

Currently writing a number of small web-services to do various informatics tasks (more detailed post to come). Fortunately I'm not the one having to deal with 3rd-party SOAP apis! Still I do need to do various XML and JSON parsing, and not having addressed the latter before I've gone looking for libraries.

Currently I am about to start using Jackson, but was wondering if anyone had any warnings, advice, or recommended alternatives? In the course of looking at what was out there I have also come across Restlet, a ReST framework that seems like it is well worth the time to figure out and deploy, so I will probably be doing that soon as well, any warnings or advice on this will be welcome.

One of the nice things about Restlet is its support for RDF. Granted it doesn't support querying, and the terminology in the interface is a bit confused, but it does use its native Resource interface for URIRefs, so it should integrate well. OTOH, if it does prove useful as a ReST framework, I can see myself writing a quick Sesame or Mulgara extension, as there is only so much you can do with RDF before you need a query and/or data-binding interface.


Jerome Louvel said...

Hi Andrae,

In Restlet, we currently provide support for the standard library which is simple but has several limitations. We also provide an XStream extension which can serialize beans to/from XML and JSON (using Jettison).

Finally, Jackson is also on our radar. As a pure streaming JSON library, it looks like an excellent candidate.

Regarding RDF, I'm glad you had a look at our support. We tried to adapt the terminology of RDF from a REST point of view (a graph of linked resources). It is not as common as RDF centric API using statements, etc. indeed. Are you refering to other aspects?

Our RDF support is clearly limited to building RDF representation from various XML/RDBMS/POJO sources, but not to support SPARQL querying of RDF data stores.

In this area, leveraging existing RDF libraries/products makes sense!


Andrae Muys said...

I saw the support, but as you alude to, isn't very impressive. Swapping a DOM class hierarchy for a JSON class hierarchy isn't a win, and the tool support for XML is much broader, so why waste my time.

However the point is mostly moot. I've been meaning to write a new post, JSON really is a bit of a dead-end; especially from a ReST perspective. The only advantage of JSON over XML is that you can parse it in javascript via eval(); however

1. You can only do that on the client - because you're a fool if you are going to execute arbitrary code you pulled from a socket on your server; so you still need a parser there.

2. Javascript has no concept of a URI Reference, so there is no general way to make JSON data navigable. Compare this to xlink, and of course rdf is eminently navigable (most of an rdf file is generally identified links).

So while I may use JSON as a representation for any RPC-based services, I will stick to representations that provide more than an operational semantics when developing resources.

Regarding your RDF support I was looking at the javadocs at specifically classes such as Link and LinkReference. I'm still not sure what a typeRef is supposed to be, but from its usage I'm pretty certain it's not referring to rdf:type. It is also strange that LinkReference.createBlank() takes a String 'identifier', but does not take a graph-serialization-context as blank-nodes do not have identifiers. This suggests a fundamental (and extremely common) misunderstanding by the API author of the nature of RDF Blank-Nodes.

I also have _no_ idea how Graph::add(Graph, Reference, Reference) relates to an RDF statement; and the whole RdfRepresentation class is a little bizarre.

Regardless it is great to see you include an RDF extension, and there is definitely no point in ignoring the existing RDF products out there.

Jerome Louvel said...

Hi Andrae,

Thanks for the reply. Another advantage of JSON is its compactness. Even though it doesn't have explicit support for hyperlinks, nothing prevents you from embedding some as values, like "href" attributes in XML.

Regarding RDF, our Link#typeRef indicates the type of the RDF property, or its predicate if you prefer. I've just updated the Javadocs in the code base (might take a bit to appear online) to clarify the mappings between our RDF API and the RDF terminology.

LinkReference has been removed and its static methods moved to Link. The idea is to use local reference to identify blank nodes, similarly to the way they are serialized: "_:123".

RdfRepresentation is capable of parsing (and writing) a wrapped RDF document by detecting its media type (MIME type). It hides our internal parsers and formatters in a more convenient and practical class. It supports both DOM-like and SAX-like processing via the associate GraphHandler class.

The ability of adding a Graph as a source node (or subject) relates to n3 reification feature.


Quoll said...

As per your comments on extending Mulgara and Sesame:
For Sesame see:
Chapter 8. HTTP communication protocol for Sesame 2.0
For Mulgara see:
Mulgara REST Interface

Andrae Muys said...

Quoll: Yep, those were the interfaces I was thinking of linking to :).

jhoney said...

There is no definition of beauty, but when you can see someone's spirit coming through, something unexplainable, that's beautiful to me.
Roller Shutters

GOD is BIG Power said...

Valium Online
what is more, staff have the correct to make and be part of unions in addition because the right to strike. As a result labor unionisation is incredibly high, forty p.c of Italy’s working class was unionized.