[openbiblio-dev] JISC openbib update

Wed May 4 14:23:26 UTC 2011

On 3 May 2011 11:55, Mark MacGillivray <mark at odaesa.com> wrote:
> (copied in to openbiblio-dev list now)
>
> JSON-LD, RDF/JSON, RDFlib
>
> Yesterday we looked at writing a parser and serialiser for RDFlib to
> handle JSON-LD, as JSON-LD was expected to be the best of various JSON
> linked data formats. Here are some updates:

Why do we need to write a general purpose JSON-LD parser? (Not trying
to be difficult but to understand!). I had imagined JSON-LD being used
in the context of an API where there would be a limited amount of
material to serialize and deserialize (i.e. we are not trying to do
huge RDF documents ...). Does this restriction help?

> * We can write a parser for RDFlib, it is not that hard
> * but we need good info on the algorithm to implement to create a
> successful parse
> * unfortunately, JSON-LD is insufficiently specified to enable this

Details?

> * JSON-LD does not clearly explain how to encode an entire document -
> rather it describes how to encode snippets

What is an entire document versus snippets?

> * There are advantages of JSON-LD over RDF/JSON, although they are not
> critical requirements

Yes, they are from my perspective: it produces JSON that is
understandable and normal enough for non-semantic-web people to
consider using :-)

> * in particular, whilst JSON-LD provides a format that is easier to
> manage at the front end (e.g. via javascript) it is not worth trying
> to implement an underdefined spec just for that advantage

It is worth it for our API IMO ... (we don't need a general purpose
parser do we?)

> * JSON-LD does give namespace handling which we do not get in
> RDF/JSON. This would be great, but requires more specification

> * Hence, we believe our time may be better spent doing an RDF/JSON
> parser, and building on that simple spec where necessary to
> incorporate the functionality that JSON-LD would offer (more explicit
> namespace handling)

But standard RDF/JSON completely defeats the point of having a JSON
(REST) API -- low entry cost for average web coder (after we could
just use sparql for a lot of this)

> * This could be done within a week, (bringing up the RDF/JSON parser
> written for an old version written by Rob Sanderson of RDFlib to meet
> 3.1 requirements) as opposed to a JSON-LD implementation, which would
> require a few weeks of additional speccing before any coding began

OK but it seems we are now doing something different from the
originally anticipated usage of JSON-LD (which use in an API with
transmission of "smallish" objects such as Entry, Collection, Entity
etc).

> So, we would now like some feedback; should we proceed with RDF/JSON?
> Have we missed details about JSON-LD that would help us successfully
> parse and serialise entire documents? Here are some more details about
> where the JSON-LD spec is lacking:
>
> * sections 7 and 8 are incomplete and have warnings
> * we cannot clearly define how to parse / serialise an entire
> document, because the way JSON-LD specifies serialising records does
> not build actual JSON - therefore it is unclear how we build these
> fragments together into a reliably parseable JSON document

Can you give a simple example of what you mean?

Also: do we need to do whole records for what is needed in
bibliographica. The original discussion of JSON-LD was in improving on
our current 'ad-hoc' dictization / json serialization. In that context
is JSON-LD not better?

Rufus