- From: Michael Steidl \(IPTC\) <mdirector@iptc.org>
- Date: Mon, 18 Sep 2017 09:07:47 +0200
- To: <vrodriguez@fi.upm.es>, "'simon.steyskal'" <simon.steyskal@wu.ac.at>
- Cc: <nmihindu@fi.upm.es>, "'W3C POE WG'" <public-poe-wg@w3.org>
- Message-ID: <007f01d3304c$d56cc740$804655c0$@iptc.org>
Hi Victor and Simon, thanks for being behind this issue. This morning I’ve thrown the JSON-LD of Example 16 into the sandbox – and the spinner is spinning, and spinning … Maybe a tiny particle is missing. Best, Michael From: vrodriguez@fi.upm.es [mailto:vrodriguez@fi.upm.es] Sent: Friday, September 15, 2017 8:09 PM To: simon.steyskal <simon.steyskal@wu.ac.at> Cc: Michael Steidl (IPTC) <mdirector@iptc.org>; nmihindu@fi.upm.es; 'W3C POE WG' <public-poe-wg@w3.org> Subject: Re: ODRL Validator document - communication considerations Simon: Thanks a lot! Perfect! Now everything works smoothly. Michael: You can now try the normalizer/validator http://odrlapi.appspot.com/ even with JSON-LD At least I just tried this as input: { "@context": "http://www.w3.org/ns/odrl.jsonld", "@type": "odrl:Set", "@id": "http://example.com/policy:1010", "target": " <http://example.com/asset:9898> http://example.com/asset:9898", "permission": [{ "action": "odrl:reproduce", "assigner": "http://example.com/assigner:88", "duty": [{ "action": "odrl:attribute", "attributedParty": "http://example.com/owner:9898" }] }], "prohibition": [{ "action": "odrl:translate" }] } And I got the correct output: <http://example.com/policy:1010> a odrl:Set ; odrl:permission [ a odrl:Permission ; odrl:action odrl:reproduce ; odrl:assigner <http://example.com/assigner:88> ; odrl:duty [ a odrl:Duty ; odrl:action odrl:attribute ; odrl:attributedParty <http://example.com/owner:9898> ] ; odrl:target < <http://example.com/asset:9898> http://example.com/asset:9898> ] ; odrl:prohibition [ a odrl:Prohibition ; odrl:action odrl:translate ; odrl:target < <http://example.com/asset:9898> http://example.com/asset:9898> ] . Although perhaps it should return JSON-LD if the input is JSON-LD. Víctor "simon.steyskal" <simon.steyskal@wu.ac.at <mailto:simon.steyskal@wu.ac.at> > escribió: > try "@context": "http://www.w3.org/ns/odrl.jsonld", > as context > Sent from Samsung tablet. > -------- Original message --------From: vrodriguez@fi.upm.es <mailto:vrodriguez@fi.upm.es> Date: > 9/15/17 19:06 (GMT+01:00) To: Simon Steyskal > <simon.steyskal@wu.ac.at <mailto:simon.steyskal@wu.ac.at> > Cc: "Michael Steidl (IPTC)" > <mdirector@iptc.org <mailto:mdirector@iptc.org> >, nmihindu@fi.upm.es <mailto:nmihindu@fi.upm.es> , 'W3C POE WG' > <public-poe-wg@w3.org <mailto:public-poe-wg@w3.org> > Subject: Re: ODRL Validator document - > communication considerations > can you copy the example? > I selected as input data "JSON-LD" and copied directly the example 1 > with little success: > > { > "@context": { > "odrl": "http://www.w3.org/ns/odrl/2/" > }, > "@type": "odrl:Set", > "@id": "http://example.com/policy:1010", > "permission": [{ > "target": "http://example.com/asset:9898", > "action": "odrl:read" > }], > "prohibition": [{ > "target": "http://example.com/asset:9898", > "action": "odrl:reproduce" > }] > } > > > > Simon Steyskal <simon.steyskal@wu.ac.at <mailto:simon.steyskal@wu.ac.at> > escribió: > >> easy rdf worked for me.. >> this happens usually when certain properties aren't properly defined >> in the context file >> simon >> -------- Original message --------From: vrodriguez@fi.upm.es <mailto:vrodriguez@fi.upm.es> Date: >> 9/15/17 18:45 (GMT+01:00) To: "Michael Steidl (IPTC)" >> <mdirector@iptc.org <mailto:mdirector@iptc.org> >, nmihindu@fi.upm.es <mailto:nmihindu@fi.upm.es> Cc: 'W3C POE WG' >> <public-poe-wg@w3.org <mailto:public-poe-wg@w3.org> > Subject: Re: ODRL Validator document - >> communication considerations >> Nandana, Michael, >> >> I need your help here, >> >> When I introduce the JSON-LD examples of the IM spec in the >> http://www.easyrdf.org/converter or in >> http://rdf-translator.appspot.com/ I get no result (almost empty). Can >> you please remind me what else had to be done to do the conversion? >> Libraries (ODRLAPI, Jena) also fail... >> >> I have modified the http://odrlapi.appspot.com to understand also >> RDF/XML and JSON-LD but first I need good working examples... >> >> Víctor >> >> { >> "@context": { >> "odrl": "http://www.w3.org/ns/odrl/2/" >> }, >> "@type": "odrl:Set", >> "@id": "http://example.com/policy:1010", >> "permission": [{ >> "target": "http://example.com/asset:9898", >> "action": "odrl:reproduce", >> "assigner": "http://example.com/assigner:88", >> "duty": [{ >> "action": "odrl:attribute", >> "attributedParty": "http://example.com/owner:9898" >> }] >> }], >> "prohibition": [{ >> "target": "http://example.com/asset:9898", >> "action": "odrl:translate" >> }] >> } >> >> "Michael Steidl (IPTC)" <mdirector@iptc.org <mailto:mdirector@iptc.org> > escribió: >> >>> Hi Victor, >>> >>> thanks for your work on an ODRL Validator (and Evaluator) and creating the >>> document at https://www.w3.org/2016/poe/wiki/Validation >>> >>> >>> >>> Looking into that document raised for me some issues regarding how to >>> communicate ODRL related to the IM of the CR: >>> >>> * A key issue from my point of view is that the IM shows all examples >>> only in JSON-LD, while the Validator doc shows only Turtle syntax. A person >>> who reads the IM will get familiar with the JSON-LD syntax - and its >>> specialities - and it may be hard to transform this quickly into Turtle in >>> the reader's head. >>> * Question: could we recommend a web service for translating JSON-LD >>> into Turtle to support such readers? >>> * Terminology: (goal: using the same terms in the IM and the Validator >>> document) >>> >>> * Normalization 3: Applying inheritance rules >>> The IM does not use the term "inheritance rules" but "inheritance >>> mechanism" >>> - is it ok, to adopt that? >>> * Normalization 4. Interiorizing policy-level properties >>> This section is about IM section 2.7.1. headlined "Compact Policy" and this >>> is included "It is RECOMMENDED that compact ODRL Policies be expanded to >>> atomic Policies when being processed for conformance." >>> I suggest to name this section 4: "Expanding Compact Policies" >>> * Normalization 5. Expanding from compound to irreducible Rules >>> Section 2.7 in the IM names the target of expanding compounded properties >>> the "atomic equivalent". >>> - the target "Rules" in the current heading is wrong, this IM section only >>> talks about properties. >>> - I suggest to name this section 5: "Expanding compound Rule properties to >>> atomic equivalents" >>> >>> >>> >>> That's all, thanks for considering. >>> >>> >>> >>> Best, >>> >>> Michael
Received on Monday, 18 September 2017 07:08:14 UTC