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

Received on Tuesday, 9 April 2013 08:23:21 UTC