Re: [poe] Support JSON-LD

So, I would say there are two overall requests here to alter the JSON
representation of ODRL:

1. Rename all of the properties - generally, take off the prefixes to 
bring
the JSON property names into alignment with the names in XML or RDF. 
For
exampe, no longer "policytype" but "type".
2. Rather than simple, flat structures (such as { "assignee" : "
http://example.com/org44/" } ) instead have lists of complex, 
anonymous
obects, with multiple properties.

So, I want to briefly explain *why* we decided to take the design 
approach
to JSON that we did for ODRL 2.1 - it wasn't just an accident! I go 
into
more detail in
https://stuartmyles.blogspot.com/2014/08/json-design-principles-and-lessons.html
but, briefly:

1. It is possible to mechanically translate from XML (or RDF) into 
JSON.
However, like most mechanical translations, this is not going to 
result in
"natural" JSON. In my experience, adoption of a standard is often 
driven by
initial impressions - if I don't like the look of your markup 
(particularly
in the JSON world) I may well decide to design something simpler and
easier. (Although this can happen with XML too. Remember that PRISM
"adopted ODRL" but decided they wanted a different syntax for it
http://www.prismstandard.org/specifications/3.1/Draft_Rights_Summary_Guide_3.1.htm#_Toc406232056
because they disliked the XML Serialization).

2. A big reason that developers like JSON is that it is much easier to
 deal
with than XML or RDF. (These days, I even find myself converting from 
XML
to JSON for a lot of tasks). However, a lot of that simplicity 
evaporates
if the JSON has complex structure - particularly anonymous objects. 
That's
because there still aren't a lot of great options for querying complex
JSON. (Although I hold out a lot of hope for the upcoming XQuery 3.1
https://www.w3.org/TR/2017/PR-xquery-31-20170117/). For most JSON
developers, flat lists of properties, with very little hierarchy, is 
the
way to go. (And, of course, you can't repeat property names, which is 
why I
prefixed the ODRL names, hence "policytype" rather than "type"). We 
didn't
quite as bit of experimentation with different JSON libraries and 
tools in
order to formulate these "best practices".

3. Some things are simply stylistic choices, to aid readability. Which
 is
why "permissions" for the list of permissions, rather than 
"permission" -
which doesn't really make sense as the name of a list.

Now, like any design issue, a lot of these decisions are based on 
various
trade-offs. And other people have come up with slightly different 
choices
in their style guides. For example, I favour lower_snake_case (since 
it
doesn't cause problems with generated class names). But others prefer
CamelCase, since it saves more bytes. And it could be that we decide 
that
we do want to revise (or update) the way we design our JSON. We might 
break
backwards compatibility, but that can be worth it for a better design.
However, I would ask that, if we do decide to change things, then we 
do so
with the goal of making the JSON experience with ODRL as good as 
possible,
rather than just seeing the JSON encoding as being a poor relation to 
the
RDF.

Regards,

Stuart









On Thu, Feb 16, 2017 at 7:54 PM, Renato Iannella 
<notifications@github.com>
wrote:

> What about all the Classes?
>
> Should we support:
>
>     "assignee": [{
>             "@type": [ "odrl:Party", "vcard:Organisation"],
>             "@id": "http://example.com/org44/",
>             ...
>     }]
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/poe/issues/46#issuecomment-280515609>, or 
mute
> the thread
> 
<https://github.com/notifications/unsubscribe-auth/ADwBfwAs0bORtbhSGlgTGJFD2JIMwqcuks5rdO_BgaJpZM4KZWR0>
> .
>


-- 
GitHub Notification of comment by stuartmyles
Please view or discuss this issue at 
https://github.com/w3c/poe/issues/46#issuecomment-281431392 using your
 GitHub account

Received on Tuesday, 21 February 2017 18:22:31 UTC