experiences promoting a JSON format for RDF

I work in a group within a much larger organization. Part of my job in this
group is to promote the adoption of Linked Data as an enterprise-wide
architecture, including supporting RDF. Manu asked (in a previous posting)
for some feedback and suggestions for a JSON format. I thought I'd
contribute an overview of the JSON format that we came up with to help
promote Linked Data throughout our enterprise.

It is easy enough to convince other development groups to adopt REST and to
use URIs to identify their web resources. It was impossible to convince
Javascript developers to adopt RDF. An initial JSON format for RDF that
included URIs or CURIEs for properties went nowhere. Javascript developers
would never chose to work in that format, and service developers consuming
JSON would never choose to use it; consequently, services would never
include support for it. They would always end up with custom JSON that had
little relation to RDF.

We still wanted to eventually get to where RDF was supported throughout the
enterprise. So the challenge was to design a JSON format that encoded RDF
without looking like RDF, without requiring developers to lean and
understand RDF. 

I know most people look at RDF from the perspective of graphs. I started
looking at RDF and promoting it as a formalization of hypermedia links, and
as a pattern for designing resources - a resource has properties, and these
properties have values (SPO - a triple). Looking at RDF more as a resource
description framework (not intended to be flippant) and less as a vehicle
for logical semantics and graph models made it much easier for system
engineers, architects and developers to understand and utilize. This helped
focus the role of RDF in the day-in-a-life of a developer to something they
could work with. Suddenly RDF was so scary and confusing.

I then took a lesson from the RDFa specification for vocabulary profiles. I
haven't looked at the RDFa 1.1 specification recently, but at one time the
idea was to use profiles to make keywords to URIs. This was exactly what I
needed to make an RDF+JSON accessible to regular Javascript and service
developers. Our RDF+JSON started looking like this:

  {
    uri : "http://ex.org/hr/people/123",
    name : "Brian Peterson",
    phoneNumber : "123-555-6789",
    address : {
        street : "123 Sesame St",
        city : "New York",
        state: "NY"
    },
    link : {
      profile : {
        rel : "profile",
        anchor : "http://ex.org/vocabs/hr/profile"
      }
    }
  }

The "uri" is the URI for the resource. The "link" mapping was intended to be
analogous to the link element in XHTML, mapping from the link type to an
object representing the link. The "profile" link is to the vocabulary
profile for the resource. That profile would map the tokens "name",
"phoneNumber", "address", "street", "city", and "state" (and possibly
others) to their vocabulary URIs (I this case, probably a mix of FOAF and
maybe others).

So except for the "uri" and the "link" elements, this would look almost
exactly like what a developer would have designed themselves without
thinking about RDF. However, the use of those profiles and the standard
usage of uri and link.profile keywords, we can generate RDF from this JSON
when we need it.

I understand that this style of RDF+JSON would not fit all use cases for RDF
in JSON, but it makes it a lot easier to get other non-semantic-web groups
to start using RDF in their linked data architecture. So we also have
another format that looks much more like RDF (looks kind of like the
JSON-LD) that is available for use cases that need it.

So perhaps having several formats would be useful. The simple format for the
simple cases and to help adoption, then another more traditional RDF for the
hard core cases.

Brian

Received on Monday, 30 May 2011 22:11:10 UTC