Re: [poe] Compatibility with common patterns for linking assets to policies

> About allowing: `<> odrl:permission odrl:present`
>    + A policy can be described as a resource (policy01) with a set of properties and values. 

well technically, the same holds true for: 
    a odrl:Policy ;   
    odrl:permission [
        a odrl:Permission ; 
        odrl:action odrl:present ;
        odrl:assignee ex:Bob ;
        odrl:target ex:Asset1 ;
    ] .
where `<>` is also a resource with properties and values ;)
> ... Ideal for lazy implementors, **easy storage/processing** (a policy as a POJO, stored in a single table in a relational database, or in a couple of columns in a CSV file).
>    + **Easy understandability**, "less lines in a powerpoint": nobody will be able to say "I dont understand simple ODRL policies". Developers of the world happy.

There's an important difference between making policies _"easy to understand"_ or _"easy to store/process"_. 

As outlined [here]( and here [2.7 Policy Rule Composition](, a user can write compact (thus easy to comprehend) policies, but in order to achieve interoperability an ODRL processor has to derive the policy's expanded/atomic form. If the same processor has to process a "normal" ODRL policy, it simply skips the expansion part, but is otherwise able to proceed as usual.

However, if you skip the expansion/transformation step and work with the compact representation only, you will indeed have "less lines in a ppt", but loose expressiveness and interoperability with "normal" policies.


> We at IPTC have a rule for the syntax design: **don't support expressing the same semantic assertion by syntax variants differently.** The reason is quite simple: a parser has to check all syntax variants before statements can be retrieved from a document - and this makes parsers more complex and expensive.
With that background I don't support such shortcuts - what is the real benefit?

What's your take on [2.7 Policy Rule Composition]( then?

GitHub Notification of comment by simonstey
Please view or discuss this issue at using your GitHub account

Received on Thursday, 22 June 2017 05:19:05 UTC