Re: experiences promoting a JSON format for RDF

On May 30, 2011, at 10:37 PM, Brian Peterson wrote:

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.

This is where the @coerce in JSON-LD can come in handy. When serializing an RDF graph with typed literals I can create @coerce mappings so that the actual values are just plain strings. If you were to come up with a standardized profile (like a remote @context), you could add information such as this so that the semantic representations could be inferred.

For the common case where plain literals in a JSON serialization might have a common language, @coerce might be extended to coerce particular properties to have a language, e.g.:

{
  "@context": {"@coerce": "en-us" : ["dcterms:title", "dcterms:description"]}}
  ..
}

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 : {...}
     ...
  }

With a hypothetical change to JSON-LD, should could be something like the following:

{
  "@context": "http://link-to-remote-profile"
  ...
}

which could have the same semantics as a locally defined profile, but it allows for a remote (and exhaustive) definition of term and @coerce mappings.

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>
[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<mailto: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