Re: experiences promoting a JSON format for RDF

On 05/30/2011 06:10 PM, Brian Peterson wrote:
> 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.

With the exception about the comment regarding CURIEs for properties, I
whole-heartedly agree with you. It is nearly impossible to get
JavaScript folks to adopt 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. 

+1

>   {
>     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 above, coupled with Gregg's suggestion, would look like this in JSON-LD:

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

Very similar, no?

Also note that JSON-LD already supports importing external profiles:

http://json-ld.org/spec/ED/20110507/#vocabulary-profiles

> 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).

@context would have the same effect above, without requiring the import
of any of the XHTML rel-values. Do we really need to mirror XHTML
rel-values in this format?

> 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.

The one down-side of this approach is that the markup, if cut-pasted
into another application may not match the profile that is in use. That
is why there exists a Default Context in JSON-LD and why developers are
asked to not deviate from it in any significant way. We want the JSON
objects that people create to be interchangeable if they are published
to the Web without the need for RDF processing to occur.

I don't know if that affected the approach that you provided? That is
not to say that one couldn't override the default context... just that
the behavior should be frowned upon because it leads to
non-interoperable systems if a Linked-JSON processor isn't used.

> 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.

I would argue that what you are suggesting is essentially JSON-LD for
all practical intents and purposes, right? That is, if we rename "uri"
to "@subject" or even "@iri" and collapse the link/profile relationship
to just "@context" - we end up with essentially the same structure from
a developer's perspective.

> 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.

Do you think JSON-LD supports both the simple use case you describe as
well as the more traditional use cases?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
http://digitalbazaar.com/2011/05/05/payswarm-sandbox/

Received on Thursday, 2 June 2011 01:05:07 UTC