RE: experiences promoting a JSON format for RDF

I ended up rolling up multiple values into a JSON array. So if I had
multiple phone numbers, then it would be 

   phoneNumber : ["123-555-6789", "111-222-3333"]

Values in arrays can be strings, URIs, or nested objects for other those
resources. Arrays are not be used as values themselves. This limitation has
had no practical impact for us because we aggressively avoid RDF lists.

Other simplifications that we use:
 - Only simple literals, no language tagging and no datatyping.
 - URIs appeared as simple literals.

Our developers were very much against embedding structure within JSON
strings, which ruled out tags, datatypes, and angle-bracketing URIs. These
simplifications will rule out many RDF use cases, but it was quite evident
that the advantages outweighed the drawbacks. I hope to use rdf:domain and
rdf:range assertions on the vocabulary (or perhaps in the profile) to help
mitigate the drawbacks.

On the "link" objects: I originally had just "profile" on the root object,
but talked myself into treating it like another web link, analogous to the
HTML link elements (I think the RDFa profile reference appears in a link
element). So other links for the resource would also end up in that
structure rather than mixing with the RDF properties of the resource:

   link : {
      profile : {...},
      next : {...}
      ...
   }

Each mapping in the link object maps to another object, one modeled along
the lines of the Web Links RFC (http://tools.ietf.org/html/rfc5988).

I like the symmetry with XHTML links, the generality of treating the profile
as another link, and keeping these links separate from the RDF properties on
the resource; however, I do like the simplicity of a simple "profile"
mapping on the root object. I'm also not sure it was worth trying to model
the Web Links in the RFC.

Brian

-----Original Message-----
From: public-linked-json-request@w3.org
[mailto:public-linked-json-request@w3.org] On Behalf Of Richard Cyganiak
Sent: Monday, May 30, 2011 7:44 PM
To: Brian Peterson
Cc: public-linked-json@w3.org
Subject: 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 Tuesday, 31 May 2011 02:38:36 UTC