RE: Encoding of ODRL in JSON

I agree that borrowing the JSON-LD @context approach is worth considering:

1. It is a draft standard (so has been thought/argued about, documented, is easy to lookup, may have been seen before ...)
2. It provides a solution to distributed evolution and extension, for anyone who cares about that (mainly XML people)
3. It doesn't require "unnatural" alterations or syntax conventions to the JSON (and so can be safely ignored by people who typically don't want to deal with namespaces - HTML/JSON type people)

Of course, I'm grossly stereotyping for effect when I say that "XML people" care about distributed extensions and "HTML/JSON people" don't want to deal with namespaces. (If I had to, I would call myself an XML type person, by the way, but I've been working to open myself up to the more relaxed approach to things from the JSON point of view).

To illustrate what Mo says about you don't need a full JSON-LD implementation to make this approach work: consider that a JSON-ODRL processor could simply compare an incoming @context object to its own internal @context to quickly determine whether there are any clashes. A step up would be for a JSON-ODRL processor to be able to select between incoming @context values. In practice, an ODRL processor (no matter the syntax) needs to determine the context within which to evaluate permissions and restrictions, so handling the @context object seems like a reasonable requirement.

I suggest we adopt the JSON-LD @context as our working assumption for accommodating extensibility for the ODRL JSON syntax (until we discover a situation where it doesn't make sense).

Regards,

Stuart


-----Original Message-----
From: Mo McRoberts [mailto:Mo.McRoberts@bbc.co.uk] 
Sent: Tuesday, April 09, 2013 4:23 AM
To: Jonas Öberg
Cc: Jim Earley; Myles, Stuart; public-odrl@w3.org
Subject: Re: Encoding of ODRL in JSON


On Tue 2013-Apr-09, at 08:38, Jonas Öberg <jonas@shuttleworthfoundation.org>
 wrote:

> Hi Jim, Mo, Stuart,
>
> thanks very much for your valuable feedback so far. It seems to me that the original comment by Stuart on starting property names with a lower case letter is evident and should definitely be implemented in the draft standard. For the rest of the discussion though, we seem to circulate around the question on how to best express the JSON in a natural way for developers and how to include some concept of namespaces, if required.
>
> Let me first mention namespaces. I'm not particularly keen to define our own way of doing this but would much rather use existing standards that we can relate to. JSON-LD is one of them which could indeed be used, but I worry about backwards compatibility. Let me explain: if we assume JSON-LD, then I understand it would be quite possible to do something like this:
>
> {
>   "@context":
>   {
>     "fiduciary": "http://example.com/vocab#fiduciary",
>     "assignee": "http://w3.org/ns/odrl/vocab#assignee"
>   },
>   "fiduciary": ["http://example.com/bob:10"],
>   "assignee": ["http://example.com/clara:11"] }
>
> However, this requires that the parser is able to read and understand JSON-LD, because we could as well do:
>
> {
>   "@context":
>   {
>     "bob": "http://example.com/vocab#fiduciary",
>     "clara": "http://w3.org/ns/odrl/vocab#assignee"
>   },
>   "bob": ["http://example.com/bob:10"],
>   "clara": ["http://example.com/clara:11"] }

Well, one way you could do that is to profile a subset of JSON-LD as the JSON serialisation of ODRL, possibly including a specific profile document which is mandatory if you want your JSON to be supported by ODRL processors...

{
  "@context":"http://www.w3.org/ns/odrl/context",
  "assignee": [ ... ],
  "..." ...
}

If you didn't want to use the fixed context document, you could still state that the ODRL JSON context document must either be that one, or a superset of it.

In other words, a processor isn't required to support _all_ of the capabilities of JSON-LD, just the basic grammar and extension mechanism, while the core vocabulary is fixed and predictable.

(A fringe benefit is that any ODRL JSON document would also be parseable by a JSON-LD processor, but if I'm honest I'm less concerned about that than reinventing the same mechanisms for extensibility and so on).

M.

--
Mo McRoberts - Analyst - BBC Archive Development, Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
MC3 D4, Media Centre, 201 Wood Lane, London W12 7TQ,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
-----------------------------


The information contained in this communication is intended for the use
of the designated recipients named above. If the reader of this 
communication is not the intended recipient, you are hereby notified
that you have received this communication in error, and that any review,
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please 
notify The Associated Press immediately by telephone at +1-212-621-1898 
and delete this email. Thank you.
[IP_US_DISC]

msk dccc60c6d2c3a6438f0cf467d9a4938

Received on Tuesday, 9 April 2013 14:25:25 UTC