Due to limitations of the display of large plain-text code snippets on the site, we have placed the actual content in this text file which you should refer to as we go along.

We used a BibJSON document, which comes from the examples on the
BibJSON homepage.

When converting this into the two RDF serialisations we invent a namespace

http://www.bibkn.org/bibjson/terms/

This namespace provisionally holds all predicates/keys that are used by BibJSON
and are not immediately clearly available in another ontology. These terms should
not under any circumstances be considered definitive or final, only indicative.

Now consider the RDF-JSON serialisation

Some key things to note about this serialisation:

• There is no explicit shortening of URIs for predicates into CURIEs,
  all URIs are instead presented in full.
• The subject of each predicate is a JSON object with up to 4 keys (value,
  type, datatype, lang). This means that it is not easy for the human
  eye to pick out the value of a particular predicate.
• Of the two RDF serialisations, this is by far the most verbose
• It is relatively difficult for a human to read and write

Compare this with the equivalent JSON-LD serialisation:

Some things to note about this serialisation:

• It has a clear treatment of namespaces
• It may be slightly inaccurate, as there are some parts of its specification
  which are ambiguous – feedback welcome
• The object values cannot be taken as the value of the predicate,
  as they may contain datatype and/or language information in them, or may
  be surrounded by angled brackets.
• It is relatively easy for a human to read and write

Both serialisations are capable of representing the same data, although JSON-LD
is far more terse and therefore easier to read and write. It is not, however,
possible to reliably treat JSON-LD as a pure list of key-value pairs in non-RDF
aware environments, as it includes RDF type and language semantics in the literal
values of objects. RDF-JSON does not suffer from this same issue within the object
literals, but in return its notation is more complex.

A serious lacking in RDF-JSON is explicit handling of CURIEs and namespaces,
and it could benefit from adopting the conventions laid out in JSON-LD – this
may bring the choice of which serialisation to use down to preference rather
than relying on any significant technical differences.

Each of the formats also comfortably represents BibJSON, and with the extensive lists of predicates provided in that specification it would be straightforward enough to do a full and proper treatment of BibJSON through one of these routes.

You can find the WIP writeup here: http://knowledgeforge.net/pdw/trac/wiki/datatriage

This will include links to the source datasets and any subsequent curated data as I am able to put them up online.

The data will be from two distinct sources: traditional library catalogues (Cambridge University Library and the British Library) and ToCs from a scientific publisher, the IUCr. None of the material is currently available as LOD, furthermore the outputs can be guaranteed to be open (unlike many existing data efforts, linked or otherwise).

Key strategies are

• transformation of current publishers’ model to create Open Bibliography as part of their future business, and
• the immediate and continuing engagement of the scholarly community.

Deliverables include a maintained and growing bibliography on the IUCr site and engagements with other like-minded publishers such as PLoS as well as the code for the  software used to create the Linked Data versions of the aforementioned sources.