- From: Jonas Öberg <jonas@shuttleworthfoundation.org>
- Date: Mon, 1 Jul 2013 08:34:11 +0200
- To: "Myles, Stuart" <SMyles@ap.org>
- Cc: Mo McRoberts <Mo.McRoberts@bbc.co.uk>, Jim Earley <xml.jim@gmail.com>, "public-odrl@w3.org" <public-odrl@w3.org>
- Message-ID: <CAECQ_dou8_7uLiCLOTzOv_QypVmr17A+i=Fn_NVuo_5Zwzq84A@mail.gmail.com>
Dear all,
Last week, I spoke briefly to Stuart about moving this forward, and would
like to present you with the current state of this work and invite your
comments. As you know, we discussed JSON vs JSON-LD and came to the rough
agreement that we should aim for JSON-LD in principle, while giving enough
rigor in the definitions to enable most encodings to be read even by
implementations not supporting the full JSON-LD specification.
The following three examples of ODRL in JSON are based on the following
rules, to be lifted into a specification document:
- The default vocabulary MUST be http://w3.org/ns/odrl/vocab#
- An implementation SHOULD specify the default vocabulary
- Vocabulary terms from the default vocabulary MAY be overridden or added
to by specifying a specific context for each changed or added term, ie.
("distribute": "http://iptc.org/std/RightsML/2011-10-07/distribute")
- Implementations MAY use the definition from the Common Vocabulary for
terms which are overridden, if they only claim compliance with the Common
Vocabulary.
- The vocabulary terms asset, relation, party, permission, prohibition,
action and duty are explicitly defined and MUST NOT be changed. An
implementation MAY define these terms in the
http://w3.org/ns/odrl/2/json#namespace.
- Implementations SHOULD pay attention to the context but MAY assume all
term used are in accordance with the Common Vocabulary if they only claim
compliance with the Common Vocabulary.
Example 1: a set (cf core model section 3.1), without mention of contexts.
This should be readable by any JSON-capable implementation. Permission,
prohibition, asset and action are defined in the JSON encoding standard,
whereas all other terms (target, modify, reproduce) are interpreted
according to the Common Vocabulary.
{
"@type": ["set"],
"@id": "http://example.com/policy:0099",
"permission":
[{
"asset":
[{
"@id": "http://example.com/asset:9898",
"@type": "target"
}],
"action": "reproduce"
]},
"prohobition":
[{
"asset":
[{
"@id": "http://example.com/asset:9898",
"@type": "target"
}],
"action": "modify"
}]
}
Example 2: A modified RightsML request (cf core model section 3.4), noting
the default context and explicitly defining the RightsML definition of
distribute. Implementations supporting JSON-LD would understand the
following request to mean the request to display (according to the Common
Vocabulary) and distribute (according to RightsML), if they support
RightsML. Implementations that only support the Common Vocabulary OR for
implementations that do NOT support JSON-LD will interpret this as being a
request to display and distribute, both according to the Common Vocabulary.
{
"@context":
{
"@vocab": "http://w3.org/ns/odrl/vocab#",
"distribute": "http://iptc.org/std/RightsML/2011-10-07/distribute"
},
"@type": ["request"],
"@id": "http://example.com/policy:04311",
"permission":
[{
"asset":
[{
"@id": "http://example.com/news:0099",
"@type": "target"
}],
"action": ["distribute", "display"],
"party":
[{
"@id": "http://example.com/guest:0589",
"@type": "asignee"
}]
}]
}
Example 3: A set (cf core model section 3.1), this one explicitly defining
all contexts. This would be the "best practice" output from any
implementation supporting the standard.
{
"@context":
{
"@vocab": "http://w3.org/ns/odrl/vocab#",
"permission": "http://w3.org/ns/odrl/2/json#permission",
"asset": "http://w3.org/ns/odrl/2/json#asset",
"action": "http://w3.org/ns/odrl/2/json#action",
"prohibition": "http://w3.org/ns/odrl/2/json#prohibition",
},
"@type": ["set"],
"@id": "http://example.com/policy:0099",
"permission":
[{
"asset":
[{
"@id": "http://example.com/asset:9898",
"@type": "target"
}],
"action": "reproduce"
]},
"prohibition":
[{
"asset":
[{
"@id": "http://example.com/asset:9898",
"@type": "target"
}],
"action": "modify"
}]
}
Sincerely,
Jonas
On Thu, Apr 11, 2013 at 11:10 AM, Jonas Öberg <
jonas@shuttleworthfoundation.org> wrote:
> Hi all,
>
> thanks for the feedback so far, it seems we have a broad agreement on
> JSON-LD, so let me include an example here to see if I've understood
> this correctly. You'll notice that I've references the ODRL Common
> Vocabulary through the JSON-LD default vocabulary (@vocab), as well as
> introduced a namespace definition for the core entities. I'm far from
> sure that this is correct though -- or that there's not an easier way
> to do it.
>
> Here's the example, and below it the N-quads representation
>
> {
> "@context":
> {
> "@vocab": "http://w3.org/ns/odrl/vocab#",
> "policy": "http://w3.org/ns/odrl/2/policy",
> "permission": "http://w3.org/ns/odrl/2/permission",
> "asset": "http://w3.org/ns/odrl/2/asset",
> "action": "http://w3.org/ns/odrl/2/action",
> "party": "http://w3.org/ns/odrl/2/party"
> },
> "@type": ["request", "policy"],
> "@id": "http://example.com/policy:0099",
> "permission":
> [{
> "asset":
> [{
> "@id": "http://example.com/news:0099",
> "@type": "target"
> }],
> "action": "display",
> "party":
> [{
> "@id": "http://example.com/guest:0589",
> "@type": "asignee"
> }]
> }]
> }
>
> And N-quads:
>
> <http://example.com/guest:0589>
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> <http://w3.org/ns/odrl/vocab#asignee> .
> <http://example.com/news:0099>
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> <http://w3.org/ns/odrl/vocab#target> .
> <http://example.com/policy:0099>
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> <http://w3.org/ns/odrl/2/policy> .
> <http://example.com/policy:0099>
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> <http://w3.org/ns/odrl/vocab#request> .
> <http://example.com/policy:0099> <http://w3.org/ns/odrl/2/permission>
> _:b0 .
> _:b0 <http://w3.org/ns/odrl/2/action> "display" .
> _:b0 <http://w3.org/ns/odrl/2/asset> <http://example.com/news:0099> .
> _:b0 <http://w3.org/ns/odrl/2/party> <http://example.com/guest:0589> .
>
>
> Sincerely,
> Jonas
>
> On Tue, Apr 9, 2013 at 4:24 PM, Myles, Stuart <SMyles@ap.org> wrote:
> > I agree that borrowing the JSON-LD @context approach is worth
> considering:
> >
> > 1. It is a draft standard (so has been thought/argued about, documented,
> is easy to lookup, may have been seen before ...)
> > 2. It provides a solution to distributed evolution and extension, for
> anyone who cares about that (mainly XML people)
> > 3. It doesn't require "unnatural" alterations or syntax conventions to
> the JSON (and so can be safely ignored by people who typically don't want
> to deal with namespaces - HTML/JSON type people)
> >
> > Of course, I'm grossly stereotyping for effect when I say that "XML
> people" care about distributed extensions and "HTML/JSON people" don't want
> to deal with namespaces. (If I had to, I would call myself an XML type
> person, by the way, but I've been working to open myself up to the more
> relaxed approach to things from the JSON point of view).
> >
> > To illustrate what Mo says about you don't need a full JSON-LD
> implementation to make this approach work: consider that a JSON-ODRL
> processor could simply compare an incoming @context object to its own
> internal @context to quickly determine whether there are any clashes. A
> step up would be for a JSON-ODRL processor to be able to select between
> incoming @context values. In practice, an ODRL processor (no matter the
> syntax) needs to determine the context within which to evaluate permissions
> and restrictions, so handling the @context object seems like a reasonable
> requirement.
> >
> > I suggest we adopt the JSON-LD @context as our working assumption for
> accommodating extensibility for the ODRL JSON syntax (until we discover a
> situation where it doesn't make sense).
> >
> > Regards,
> >
> > Stuart
> >
> >
> > -----Original Message-----
> > From: Mo McRoberts [mailto:Mo.McRoberts@bbc.co.uk]
> > Sent: Tuesday, April 09, 2013 4:23 AM
> > To: Jonas Öberg
> > Cc: Jim Earley; Myles, Stuart; public-odrl@w3.org
> > Subject: 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.
> > -----------------------------
> >
> >
> > 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 Monday, 1 July 2013 06:34:40 UTC