Re: Encoding of ODRL in JSON

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"]
}

And I don't like the idea of being able to redefine the names of terms
which are in the Common Vocabulary. JSON is supposed to be simple and easy
to use, which makes me feel that we should ensure that the terms of the
Common Vocabulary are always identical when encoding ODRL as JSON. So;

{
  "@context":
  {
    "fiduciary": "http://example.com/vocab#fiduciary"
  },
  "fiduciary": ["http://example.com/bob:10"],
  "assignee": ["http://example.com/clara:11"]
}

that would enable someone who only wants to support Common Vocabulary to do
so without JSON-LD, since everything that is in the Common Vocabulary would
be in the default namespace. This means that the payload is reduced and
only when introducing terms which are not part of the Common Vocabulary do
you need to purposefully specify the context with JSON-LD.

Happy to hear your thoughts on this.

Sincerely,
Jonas




On Sun, Apr 7, 2013 at 5:17 PM, Jim Earley <xml.jim@gmail.com> wrote:

> Mo, et al.,
>
> To your point about introducing other semantics into a rights document:
>  we've extended the schema for our customers in various ways, including
> adding rights semantics that are defined in different namespaces.  Could I
> propose some additional structures in the JSON encoding that would support
> this?  One way I've seen this handled is to use Java notation for
> namespaced elements, e.g.,
>  "{http://w3.org/ns/odrl/2/}asset":"..."
>
> Obviously, this makes the JSON difficult to read, and bloats the payload.
>  Another way to support this without the extra "noise" for each asset could
> be do add the following to the JSON encoding:
>
> {
>     "namespaces":[
>           {"o":"http://w3.org/ns/odrl/2/"},
>           {"e":"http://www.example.com"}
>      ],
>      "assets": [
>          {"uid":"12345", "relation":"e:relationType"}
>      ]
>
>
> }
>
> Regards,
>
> Jim Earley
>
>
>
> On Fri, Apr 5, 2013 at 1:14 PM, Mo McRoberts <Mo.McRoberts@bbc.co.uk>wrote:
>
>> Hi Jonas,
>>
>> On Fri 2013-Apr-05, at 19:45, Jonas Öberg <
>> jonas@shuttleworthfoundation.org>
>> wrote:
>>
>> > Let's say for instance that we create a Profile that introduces the
>> concept of a fiduciary Role. It doesn't feel appropriate to express this as
>> >
>> > "fiduciary" : " http://example.com/sony:10"
>> >
>> > as this risks collisions with other Profiles.
>> >
>> > It's entirely possible that my thinking here is off, so I'd be keen to
>> hear your thoughts on this and would be happy to incorporate this thinking
>> in the draft once we agree on the appropriate route!
>>
>> It was exactly this issue which made expressing RDF in JSON was so
>> troublesome for a long time; you either ended up being very ambiguous and
>> risking clashes or misinterpretation, or you were too verbose and nobody
>> wanted to work with the data. JSON-LD was created to try to bridge that
>> gap, and (though I wasn't involved in it at all) I think it manages to do
>> that quite neatly.
>>
>> Maybe there's a way, even if one doesn't actually use JSON-LD (which
>> might be worth exploring anyway, of course), that its approach could be
>> borrowed? i.e., specify that the JSON expression of ODRL references a
>> 'context' document (published on w3.org alongside the other vocabs)
>> which contains the necessary information to map the short-and-friendly
>> names to the fully-qualified ones?
>>
>> M.
>>
>> --
>> Mo McRoberts - Technical Lead - The Space
>> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
>> Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA
>> Project Office: MC3 D4/5, Media Centre, 201 Wood Lane, London W12 7TQ,
>>
>>
>> --
>> 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.
>> -----------------------------
>>
>>
>