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> 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 Friday, 15 September 2017 16:46:24 UTC