Re: [JSON] Survey for design requirements

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