JSON LD

JSON-LD is a relatively new W3C recommendation for expressing Linked Data in JSON. Even though it is a new standard, it has been in development for a few years, and has been used fairly heavily already, notably by the DPLA.

If you get bored of reading specifications, Markus Lanthaler's talk Building Next-Gen Web APIs with JSON-LD and Hydra. It has a nice discussion of how JSON-LD fits in with more traditional Web APIs, like the approach taken thus far in Launchpad (REST + JSON). You can probably tune out about halfway through where he talks about Hydra (not that Hydra)...or not, it's actually pretty interesting too from a read/write perspective.

The basic idea is that in JSON-LD you add a context key to your JSON so that people know what you mean when you say something has a given title. For example instead of simply saying:

{
  "title": "Huckleberry Finn"
}

you say:

{ 
  "context": {
    "title": "http://purl.org/dcterms/title"
   },
   "title": "Huckleberry Finn"
}

This allows you document exactly what you mean by particular property names, and (in theory) allows others to interoperate easier with you. The library tradition of using a shared understanding of MARC to perform cooperative cataloging make the concept of JSON-LD kind of familiar, and perhaps, compelling? Also, there is possibly some PR value to say GWU is aligning with DPLA? There might also be an opportunity to nudge DPLA towards using schema.org as a vocabulary as Launchpad has in its HTML? Or we could instead decide to align with Europeana and DPLA's use of Dublin Core.

Item Example

To that end here's a brief example of a Launchpad item as JSON-LD using Schema.org:

{
  "context" {
    "@vocab": "http://schema.org"
  },
  "@type": "Book",
  "name": "Planet water : investing in the world's most valuable resource",
  "author": {
    "name": "Hoffmann, Stephen J.",
    "birthDate": "1955"
  },
  "about": [
    "Water quality management",
    "Water resources development -- Economic aspects",
    "Water-supply -- Economic aspects"
  ],
  "datePublished": "2009",
  "publisher": {
    "name": "Wiley",
    "address": {
      "addressLocality": "Hoboken",
      "addressRegion": "NJ"
    }
  },
  "numberOfPages": 352,
  "inLanguage": "eng",
  "isbn": "0470277408",
  "sameAs": [
    "http://www.worldcat.org/oclc/243547687",
    "http://lccn.loc.gov/2008047039"
  ],
  "offers": [
    {
      "seller": "George Washington University",
      "availableAtOrFrom": "Gelman stacks",
      "sku": "D1691.H64 2009",
      "status": "http://purl.org/goodrelations/v1#LeaseOut", 
      "serialNumber": "8988479"
    },
    {
      "seller": "Catholic University",
      "availableAtOrFrom": "Mullen Library stacks",
      "sku": "D1691.H64 2009",
      "status": "http://purl.org/goodrelations/v1#LeaseOut", 
      "serialNumber": "9068409"
    },
    {
      "seller": "American University",
      "availabilityAtOrFrom": "LIB stacks",
      "sku": "D1691.H64 2009",
      "status": "http://schema.org/OutOfStock", 
      "serialNumber": "8789370"
    }
  ]
}

You can see the holdings are expressed using Schema.org following some work done in the SchemaBibExtend community. It feels a bit strange to be marking up holdings like they are products. We could use the @context to alias seller to property etc, or we could decide to just create our own vocabulary. It might be worthwhile to do a bit more research to see if other people have represented holdings in RDF that we could reuse.