Re: experiences promoting a JSON format for RDF

+1

This resonates with my experience when negotiating with JSON developers. I would quite like to have a well-defined format like this.

I find the link/profile/rel/anchor thing a bit complicated (why not just profile:"http://..." on the root object?) and would like to see how to deal with multi-valued properties.

Best,
Richard


On 30 May 2011, at 23:10, Brian Peterson wrote:

> 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 23:44:50 UTC