Re: [JSON] Survey for design requirements

Hi Manu,

Now I'm completely confused regarding the “RDF REST Web Services” use case. The use case as written makes it sound like Frank is a client developer who *uses* some web service. Your story below makes it sound like he is *operating* a web service. Which is it?

More inline.

On 9 Mar 2011, at 05:01, Manu Sporny wrote:
>> 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.

Well that would be a back-end use case then.

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

So I guess the use case is:


Extend existing JSON API with ability to store arbitrary RDF data

ACME Corp is operating a website with a JSON API. They want to give users the ability to store arbitrary additional data alongside certain objects managed via the API. For example, when a user account is created via the API, the client app should be able to also submit a digital signature or “My upcoming trips” data. The client app would be able to use that data on subsequent requests. To avoid accidental clashes between fields used by different client apps, ACME Corp wants to use RDF as the data model. Nevertheless, they want to keep the impact on the existing JSON API and existing clients to a minimum.


Does this capture the intent? Any major aspects to the server-side story that this is missing?

Best,
Richard




> 
> -- 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 07:25:19 UTC