- From: Myles, Stuart <SMyles@ap.org>
- Date: Mon, 17 Oct 2016 13:26:23 +0000
- To: "Johnston, Patrick - Hoboken" <pjohnston@wiley.com>, Renato Iannella <renato.iannella@monegraph.com>, W3C POE WG <public-poe-wg@w3.org>
- Message-ID: <2B3AA5056E3CB8428BDE670B2CEEC54FC6C56C42@CTCXMBX10.ap.org>
I propose that we close ACTION 30 with an answer along the lines of “Yes, we can only have a JSON-LD serialization”. But that we open a new topic of “should we remove scope from the ODRL model?” Ø The issue is that your JSON is already half trying to incorporate semantic content (using e.g. “assignee_scope”). Yes, I agree that this is a problem. In fact, I think a more basic issue – for both XML serialization and for JSON serialization – is whether the “scope” concept belongs within the model and hence the serializations. Full disclosure: I was always against the inclusion of the “scope” property. Let me see if I can explain why. A recipient of an ODRL message needs to determine whether the assignee of a policy is the same as the party who would like to make use of the asset governed by the policy. In the case of the example, the assignee is http://example.com/billie:888. In some situations, the ODRL processing system will have a URL for the would-be user which is identical to the one used in the policy. But the more general case is that the ODRL processing system needs to determine whether a given party is “the same” as the assignee of a policy by following a set of rules. The rules might include evaluating “sameas” or “equivalentclass” relationships. Or it might involve various kinds of group membership relationships. Does the inclusion of a “scope=group” help with that evaluation? In my view, no. I can’t see how in practical terms the set of rules to be evaluated would be influenced by the presence of absence of the scope property. I think that Patrick expresses this more elegantly than I do when he says “your JSON is already half trying to incorporate semantic content” – really the “semantic content” of properties like “scope” do not belong in the ODRL model or the serialization of it. Regards, Stuart From: Johnston, Patrick - Hoboken [mailto:pjohnston@wiley.com] Sent: Friday, October 14, 2016 1:23 PM To: Myles, Stuart; Renato Iannella; W3C POE WG Subject: Re: poe-ACTION-30: Can we only have a json-ld serialisation? will it impact righstml? There are many different ways to cut it. It’s unclear from the JSON example if you intend to return both policies as part of a single JSON response (as is shown in the Turtle rendering). Ideally, all you would need to do is insert an @context and your JSON would turn into JSON-LD. The issue is that your JSON is already half trying to incorporate semantic content (using e.g. “assignee_scope”). I have tried to match your original JSON as much as possible. The JSON-LD context adds some convenience aliases to do that. Eventually, you would want a full-blown standard JSON-LD context that aliases everything explicitly, and that you just reference here, but this will work for the purposes of the example. Incidentally, you can play around with this stuff at http://json-ld.org/playground/. If you want all the policies in one response, you’d normally wrap them in one container: { "@context": { "@vocab": "http://www.w3.org/ns/odrl/2/", "policytype": "@type", "policyid": "@id", "permissions": "odrl:permission", "policies": "@graph" }, "policies": [ { "policyid": "http://example.com/policy:5531", "policytype": "odrl:Agreement", "permissions": [{ "@type": "Permission", "action": { "@type": "Permission", "action": "print", "target": "http://example.com/report:2321", "assigner": { "@id": "http://example.com/pub:88", "@type": "Party" }, "assignee": { "@id": "http://example.com/billie:888", "@type": "Party" } } }] }, { "policyid": "http://example.com/policy:9999", "policytype": "Agreement", "inheritFrom": "http://example.com/policy:5531", "permissions": [{ "@type": "Permission", "action": "display", "target": "http://example.com/report:2333", "assigner": { "@id": "http://example.com/pub:88", "@type": "Party" }, "assignee": { "@id": "http://example.com/class:IT01", "@type": "Group" } }] } ] } Notes: • I aliased “policyid” and “policytype” because they were in the original JSON, but you can see that “@id” and “@type” appear further down when they aren’t policies. These could also be aliased if needed. The only thing is that this would only go one way – you couldn’t get back to the original JSON once you have extracted the JSON-LD. I generally don’t like this approach, and like to keep things reversible – means you can serialize to JSON API from RDF without custom logic. • If you want to keep “inheritallowed”, the @context will have to explicitly declare all the JSON-LD aliases except “inheritallowed”, so that it is effectively ignored from the semantic markup. It seems an odd property to have, though. • You explicitly used “permissions” to always have an array, at least in example 9. JSON-LD (and JSON) doesn’t need that the array [] wrapper if there is only one member of the array, but I have put it in for consistency. • “assignee_scope” gets bundled into the JSON object under assignee. Here I would recommend redesigning the original JSON for compatibility. You could also choose to bundle one policy inside the other, so that inheritsFrom captures all of policy 5531. In RDF terms, the following is semantically identical to the example above: { "@context": { "@vocab": "http://www.w3.org/ns/odrl/2/", "policytype": "@type", "policyid": "@id", "permissions": "odrl:permission", "policies": "@graph" }, "policyid": "http://example.com/policy:9999", "policytype": "Agreement", "inheritFrom": { "policyid": "http://example.com/policy:5531", "policytype": "odrl:Agreement", "permissions": { "@type": "Permission", "action": { "@type": "Permission", "action": "print", "target": "http://example.com/report:2321", "assigner": { "@id": "http://example.com/pub:88", "@type": "Party" }, "assignee": { "@id": "http://example.com/billie:888", "@type": "Party" } } } }, "permissions": { "@type": "Permission", "action": "display", "target": "http://example.com/report:2333", "assigner": { "@id": "http://example.com/pub:88", "@type": "Party" }, "assignee": { "@id": "http://example.com/class:IT01", "@type": "Group" } } } What I would really recommend is refactoring the current JSON so that it is more compatible with JSON-LD, and merging the two – then JSON consumers can just ignore anything with an “@...”, where JSON-LD consumers factor it in. One question on inheritance: it might be worth looking at owl:imports as a means to inherit at an RDF level. I do see that there are some conditions on inheritance that might not make this suitable: https://www.w3.org/community/odrl/model/2-1/#section-211, but it’s just a thought. Chz Patrick From: "Myles, Stuart" <SMyles@ap.org<mailto:SMyles@ap.org>> Date: Friday, October 14, 2016 at 11:03 AM To: Renato Iannella <renato.iannella@monegraph.com<mailto:renato.iannella@monegraph.com>>, W3C POE WG <public-poe-wg@w3.org<mailto:public-poe-wg@w3.org>> Subject: RE: poe-ACTION-30: Can we only have a json-ld serialisation? will it impact righstml? Resent-From: W3C POE WG <public-poe-wg@w3.org<mailto:public-poe-wg@w3.org>> Resent-Date: Friday, October 14, 2016 at 11:04 AM Yes, great request, Renato! Here is example 9 in ODRL JSON: { "policytype": "http://www.w3.org/ns/odrl/2/Agreement", "policyid": "http://example.com/policy:5531", "inheritallowed": true, "permissions": [{ "target": "http://example.com/report:2321", "action": "http://www.w3.org/ns/odrl/2/print", "assigner": "http://example.com/pub:88", "assignee": "http://example.com/billie:888" }] } { "policytype": "http://www.w3.org/ns/odrl/2/Agreement", "policyid": "http://example.com/policy:9999", "inheritfrom": "http://example.com/policy:5531", "permissions": [{ "target": "http://example.com/report:2333", "action": "http://www.w3.org/ns/odrl/2/display", "assigner": "http://example.com/pub:88", "assignee": "http://example.com/class:IT01", "assignee_scope": "http://www.w3.org/ns/odrl/2/group" }] } Here it is in XML https://www.w3.org/community/odrl/xml/2.1/#section-5 <o:Policy xmlns:o="http://www.w3.org/ns/odrl/2/" type="http://www.w3.org/ns/odrl/2/Agreement" uid="http://example.com/policy:5531" inheritAllowed="true"> <o:permission> <o:asset uid="http://example.com/report:2321" relation="http://www.w3.org/ns/odrl/2/target"/> <o:action name="http://www.w3.org/ns/odrl/2/print"/> <o:party uid="http://example.com/pub:88" function="http://www.w3.org/ns/odrl/2/assigner"/> <o:party uid="http://example.com/billie:888" function="http://www.w3.org/ns/odrl/2/assignee"/> </o:permission> </o:Policy> <o:Policy xmlns:o="http://www.w3.org/ns/odrl/2/" type="http://www.w3.org/ns/odrl/2/Agreement" uid="http://example.com/policy:9999" inheritFrom="http://example.com/policy:5531"> <o:permission> <o:asset uid="http://example.com/report:2333" relation="http://www.w3.org/ns/odrl/2/target"/> <o:action name="http://www.w3.org/ns/odrl/2/display"/> <o:party uid="http://example.com/pub:88" function="http://www.w3.org/ns/odrl/2/assigner"/> <o:party uid="http://example.com/class:IT01" function="http://www.w3.org/ns/odrl/2/assignee" scope="http://www.w3.org/ns/odrl/2/Group"/> </o:permission> </o:Policy> And here it is in RDF http://www.w3.org/ns/odrl/2/ODRL21#sec-example-9 @prefix odrl: <http://www.w3.org/ns/odrl/2/> . <http://example.com/policy:5531> a odrl:Agreement ; odrl:permission [ a odrl:Permission ; odrl:action odrl:print ; odrl:target <http://example.com/report:2321> ; odrl:assigner <http://example.com/pub:88> ; odrl:assignee <http://example.com/billie:888> ; ] . <http://example.com/policy:9999> a odrl:Agreement ; odrl:inheritFrom <http://example.com/policy:5531> ; odrl:permission [ a odrl:Permission ; odrl:action odrl:display ; odrl:target <http://example.com/report:2333> ; odrl:assigner <http://example.com/pub:88> ; odrl:assignee <http://example.com/class:IT01> ] . <http://example.com/pub:88> a odrl:Party . <http://example.com/billie:888> a odrl:Party . <http://example.com/class:IT01> a odrl:Group . In particular, I’m interested in how to represent the RDF expression “<http://example.com/class:IT01> a odrl:Group .” in JSON-LD? Regards, Stuart From: Renato Iannella [mailto:renato.iannella@monegraph.com] Sent: Friday, October 14, 2016 1:52 AM To: W3C POE WG Subject: Re: poe-ACTION-30: Can we only have a json-ld serialisation? will it impact righstml? On 14 Oct. 2016, at 02:28, Myles, Stuart <SMyles@ap.org<mailto:SMyles@ap.org>> wrote: In fact, for the Ontology, the possible values of “scope” in XML and JSON are instead subclasses of Party. This may well be a better way to model it, but that’s how JSON and XML have the scope property and the Ontology does not. There is no concept of inheritance in JSON. (Or namespaces or …). Instead, applications which handle JSON are meant to just “know” what the properties mean. Can a JSON-LD expert, convert our current JSON example into (pure) JSON-LD (based on our ontology)? Use “ Example 9 Inheritance” from here: https://www.w3.org/community/odrl/json/2.1/#section-Examples (Note: the JSON examples are yet to appear in the w3c editors draft) Renato Iannella, Monegraph Co-Chair, W3C Permissions & Obligations Expression (POE) Working Group
Received on Monday, 17 October 2016 13:27:23 UTC