RE: Encoding of ODRL in JSON

Hi Jonas,

Thanks for pulling together this initial draft.

One of the things that I think we need to decide upfront is whether we're trying to translate from the XML encoding into a JSON encoding. Or whether we're trying to translate from the ODRL data model into a JSON encoding. They are *almost* the same thing, but I think that it is worth considering the JSON we're specifying from the point of view of, say, a Javascript (or Ruby or Python or ...) programmer who is not familiar with the XML encoding of ODRL. How "natural" and understandable is the JSON? Of course, we also need to balance this with the need to make sure that the JSON is sufficiently expressive of the ODRL model for permissions and restrictions.

To try to illustrate what I'm getting at, let's look at one part of what you've proposed so far - the representation of the "Party" object from ODRL. You have an example (from which I quote a fragment):

"Party":[{"id":"p1","uid":"http://example.com/sony:10","function":"http://w3.org/ns/odrl/vocab#assigner"},
             {"id":"p2","uid":"http://example.com/billie:888","function":"http://w3.org/ns/odrl/vocab#assignee"}]

This is an array of "Party" objects. The objects themselves are anonymous but you can determine the part they play within the (in this case) "Permission" by examining the "function" property. But how about this structure instead?

"assigner": {"id":"p1","uid":"http://example.com/sony:10"},
"assignee" : {"id":"p2","uid":"http://example.com/billie:888"}

I bet that looks a lot simpler to a JSON eye. Also, I wonder if it is better to create an array of "parties" and turn all other references (within the permissions and restrictions or elsewhere) into (implicit) idrefs, i.e.

"parties":[{"id":"p1","uid":"http://example.com/sony:10"},
             {"id":"p2","uid":"http://example.com/billie:888"}]
...
"assigner" : "p1",
"assignee" : "p2"

And, actually, why do we need both id and uid? Why not just?

"parties":[{"uid":"http://example.com/sony:10"},
             {"uid":"http://example.com/billie:888"}]
...
"assigner" : " http://example.com/sony:10",
"assignee" : " http://example.com/billie:888"

(I'm going to assume that additional information about the parties are  in the JSON objects, otherwise you don't appear to need the parties list at all...).

Finally, a small point that we've discovered in the IPTC's experimentation with JSON: it is typically better to start your property names with a lower case letter, since there are a lot of tools (e.g. http://jackson.codehaus.org/) that generate code from the JSON and get confused if you use an uppercase letter. (This point underlines what we've found: it is really important to perform experiments on your encodings with a variety of JSON tools, to find out these odd gotchas).

Regards,

Stuart



-----Original Message-----
From: jonas@ffkp.se [mailto:jonas@ffkp.se] On Behalf Of Jonas Öberg
Sent: Thursday, April 04, 2013 7:46 AM
To: public-odrl@w3.org
Subject: Encoding of ODRL in JSON

Dear all,

after having consulted with Renato and Stuart, I've started working on a specification for encoding ODRL in JSON. As you know, JSON is a very simple structure that has more in common with XML than RDF, and thus, I've based my draft specification on our existing specification for XML Encoding to avoid introducing additional complexities.

You will find the first version of the draft specification posted on the ODRL community site here:

  http://www.w3.org/community/odrl/work/json/

I invite your feedback on the specification.

You will note that I draw heavily on the XML Encoding specification and indeed refer to it from section 3 where, instead of again defining the cardinality of each attribute or object, I describe a set of rules with which one can infer the corresponding JSON structure based on the XML Encoding specification.

I did not want to blindly recreate the same section based on the XML Encoding document, since it would be virtually identical, but we could do so if there are compelling reasons for it.


Sincerely,
Jonas




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 Friday, 5 April 2013 18:30:09 UTC