- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Wed, 09 Mar 2011 09:45:08 +0000
- To: Manu Sporny <msporny@digitalbazaar.com>
- CC: RDF Working Group <public-rdf-wg@w3.org>
On 09/03/11 05:01, Manu Sporny wrote: > 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. I hope any mapping is the serialization. It's important that if the format is a graph, or triples, then the representation is self-contained. If it points to an external context then the meaning can be changed by some external change. Andy
Received on Wednesday, 9 March 2011 09:45:46 UTC