Re: [JSON] Survey for design requirements

On 03/07/2011 05:19 AM, Richard Cyganiak wrote:
> I renamed two of the use cases to hopefully better highlight their
> differences. Also added more text to Andy's.

Thanks, Richard :)

> I wasn't quite able to make sense of this one: 
> http://www.w3.org/2011/rdf-wg/wiki/TF-JSON#RDF_REST_Web_Services
> 
> The web services that Frank is using. Do they already provide RDF, or
> just plain old JSON? 

Plain old JSON.

> If we assume that the operators of the web
> service already adopted some sort of JSON+RDF technology, then that
> would better be a separate use case, written from their POV.

I was trying to specify that the web service operators were moving their
back-end to RDF, but were keeping their front-end as plain old JSON for
the time being. Eventually, they'd move their front-end to JSON+RDF as well.

> If we
> assume that these web services are just plain JSON at the moment,
> then I'd like to understand why Frank doesn't simply stick with doing
> everything in JSON. Why does he want to “add semantics to the data”,
> and what does that mean?

Frank may start out with JSON that looks like this for his
/api/create-account REST call. So, if you post this data:

{
   "name": "Richard Cyganiak",
   "id": "cygri",
   "email": "richard@example.com"
}

but what if Frank wants to allow people that call his service to store
arbitrary data with their account. Things like WebIDs or public keys or
icons? Basically, what happens when they want to store their health
records or other data-locker like data with their account information?
We want to allow this new mechanism to be fairly flexible - RDF is a
good fit here.

If Frank's system assumes the following mappings:

name -> http://xmlns.com/0.1/foaf/name
nick -> http://xmlns.com/0.1/foaf/nick
email -> http://xmlns.com/0.1/foaf/mbox
info -> http://example.com/datalocker/info

Storing arbitrary information with the user account becomes as easy as
doing this (in JSON-LD):

{
   "#":
   {
      "sig": "http://purl.org/signature#"
   },
   "name": "Richard Cyganiak",
   "id": "cygri",
   "email": "richard@example.com"
   "info":
   {
      "sig:publicKey": "http://example.org/keys/5",
      "sig:publicKeyPem": "MIIjwjd832hjsfS...Efoiqwj=="
   }
}

There are two things that happened above:

1. Frank's system provides a default context that changes all of his
   plain old JSON into RDF.
2. The person interfacing with Frank's system provides their own
   set of keywords that expand to full URIs - enabling any triple
   to be stored alongside Frank's regular account information.

So, the transition from plain old JSON to JSON+RDF happens smoothly.
Frank makes this transition because it makes his REST services far more
flexible than just plain old JSON.

Twitter could use the same approach to semantify their API - imagine
being able to automatically annotate your tweets using semantics (like
whether or not what you're talking about is a web page, product for
sale, video, etc.).

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Towards Universal Web Commerce
http://digitalbazaar.com/2011/01/31/web-commerce/

Received on Wednesday, 9 March 2011 05:01:53 UTC