Re: Encoding of ODRL in JSON

Hi Stuart,

thanks very much for your feedback on this -- this will help us move
forward very quickly with this for which I'm grateful. Let me quickly feed
something into this. In general, I agree with your suggestions, and it's a
matter of weighing the ease with which the JSON encoding can be expressed
in the standard against the suitability of the JSON data types and the
possibilities to simplify the encoding to facilitate use.

One of the reason I decided to ultimately go the XML translation route for
this first draft is that I was concerned about locking us too tight to the
Common Vocabulary if not. Since JSON itself does not have any concept of
name spaces natively, I felt that it would be useful to retain this from
the XML where there's already a clear concept of this.

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!


Sincerely,
Jonas





On Fri, Apr 5, 2013 at 8:29 PM, Myles, Stuart <SMyles@ap.org> wrote:

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