Skip to content

Compatibility with common patterns for linking assets to policies #184

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
aisaac opened this issue May 18, 2017 · 51 comments
Closed

Compatibility with common patterns for linking assets to policies #184

aisaac opened this issue May 18, 2017 · 51 comments
Assignees
@sereAbi @riannella
Labels
Model Wide Review

Comments

@aisaac
Copy link

aisaac commented May 18, 2017

Split from #158 , in the context of https://lists.w3.org/Archives/Public/public-poe-comments/2017Apr/0005.html :

The POE pattern is centered on rights statements (which for us correspond to the POE "policy" notion). And the property that indicates the policy that applies to an asset (odrl:target) goes from the policy to the asset.
The most common pattern, and we believe the one that fits most application scenarios, is the one where links in the other direction and use properties that are usually used for representing metadata on assets, like “simple” (DC) properties. Our (rightsstatements.org) specific approach to this can be seen in the "Class for Rights Statements" and "Object Metadata Examples" at http://rightsstatements.org/files/170106requirements_for_the_technical_infrastructure_for_standardized_international_rights_statements_v1.2.pdf
It's also in the ccRel W3C submission: https://www.w3.org/Submission/ccREL/ and https://creativecommons.org/ns (using cc:license/xhtml:license)
But I guess you're already quite familiar with the pattern anyway…
Of course I’m not saying that the ODRL pattern is bad. It is fully legit, imho. But considering existing practices, I think the matter of the equivalence between patterns should be given a much more prominent place, and be ironed out to remove any doubts one could have.

As a matter of fact it seems you are aware of the problem: the RDF/OWL document refers to a correspondence between expressing rights statements with dct:license and the “official” pattern (section 5.1.1, https://www.w3.org/TR/2017/WD-odrl-vocab-20170223/#rdfowl )
This goes in the right direction, but:

  • in fact the axiom is not presented very explicitly: it is refered to as ‘this axiom’ but not spelled out
  • we are not sure that dct:license is the right property (level) for such axiom. We consider dct:rights (a super-property of dct:license) to be a more appropriate level for such linking, as some policies (rights statements) are not necessarily licenses.
  • I really don’t see why this is in a section introducing an ‘RDF/OWL encoding’. It is not a matter that seems specific to an OWL ontology. And in fact it doesn't seem to appear in the RDF/Turtle serialization of the ontology: http://w3c.github.io/poe/vocab/ODRL22.ttl . It may be better to devote a specific section of another document, or even a document of its own (maybe one that would tackling the following issue at the same time?)
@aisaac
Copy link
Author

aisaac commented May 18, 2017

From @riannella at #158 (comment)

Proposal:

1 - update the IM to include a new property odrl:policy (hasPolicy)
(declare as sub-property of dc:rights and http://www.w3.org/ns/ma-ont#hasPolicy)

2 - Remove the "target asset" section from the RDF/OWL Encoding section in the Vocab.
(there will be an example in the IM)

@aisaac aisaac mentioned this issue May 18, 2017
Closed
@aisaac
Copy link
Author

aisaac commented May 18, 2017

@riannella this ticket contains the "first" part of #158 can you assign and label it please?

@aisaac
Copy link
Author

aisaac commented May 18, 2017

Reactions to the proposal:

  1. This can be fine, but
  • why not odrl:hasPolicy instead of odrl:policy?
  • regarding your mapping to MO: wouldn't the property be equivalent (sameAs) mo:hasPolicy? (there might be hidden semantic traps in a strict equivalence, but I must suggest it still :-) )
  • regarding your mapping to DC: wouldn't the property be a super-property of dc:rights?
  • you shouldn't forget an inverse axiom between odrl:target and the new property
  1. OK!

@riannella riannella mentioned this issue May 19, 2017
Closed
riannella added a commit that referenced this issue May 29, 2017
@riannella
Added HasPolicy #184
cc18380
@riannella
Copy link
Contributor

Added hasPolicy to IM (section 2.1.4) and to Vocab.

Commit cc18380

@aisaac
Copy link
Author

aisaac commented May 29, 2017 via email

@vroddon
Copy link
Contributor

vroddon commented May 29, 2017

I had documented the use of dct:license as a best practice:
https://www.w3.org/2016/poe/wiki/Best_Practices#3._How_to_grant_Alice_the_permission_to_use_an_asset_.28III.29

Should we replace dct:license by odrl:hasPolicy? Should we keep both?

@aisaac
Copy link
Author

aisaac commented May 29, 2017 via email

@simonstey
Copy link
Contributor

while every license is also a policy, every policy isn't necessarily a license

@vroddon
Copy link
Contributor

vroddon commented May 29, 2017

I would advice to have a odrl:policy and recommend it as best practice, but tolerate dct:license.
dct:license is defined as:

A legal document giving official permission to do something with the resource.

This may not be always the case.

As a comparison cc:license (see https://creativecommons.org/schema.rdf) is a property defined to be the same (owl:sameAs) http://www.w3.org/1999/xhtml/vocab#license but subproperty of http://purl.org/dc/terms/license"

@aisaac
Copy link
Author

aisaac commented May 29, 2017 via email

@aisaac
Copy link
Author

aisaac commented May 29, 2017

I forgot to point out that even the single axiom
dct:license subPropertyOf odrl:hasPolicy
would still enable to present best practices like @vroddon 's https://www.w3.org/2016/poe/wiki/Best_Practices#3._How_to_grant_Alice_the_permission_to_use_an_asset_.28III.29 without changing them. I.e. they'd be not only 'tolerated': they would use a property that is well used in the field, while being compatible with ODRL's general picture (thanks to the subproperty axiom).

@riannella
Copy link
Contributor

Updated the narrative to say: "...MUST be inferred to be the target Asset..."

Added: owl:inverseOf :target ;

Added axiom: dct:license rdfs:subPropertyOf odrl:hasPolicy .

commit: b6987fa

@vroddon suggest the examples use odrl:hasPolicy

@simonstey
Copy link
Contributor

Added: owl:inverseOf :target ;
Added axiom: dct:license rdfs:subPropertyOf odrl:hasPolicy .

what does this mean for XML?

@riannella
Copy link
Contributor

This is beyond XML capabilities - unless implementors directly code this support.

@aisaac
Copy link
Author

aisaac commented Jun 6, 2017 via email

@riannella
Copy link
Contributor

thanks for your feedback and followup

@simonstey
Copy link
Contributor

3.4.3 Has Target Policy:

Note: The Asset being identified MUST be inferred to be the target Asset of all of the Rules of the Policy.

+

Added: owl:inverseOf :target ;

+

Valid Policy:


    a odrl:Policy;
    odrl:permission [
        a odrl:Permission ;
        odrl:target ex:PartA ;
        odrl:action odrl:present ;        
        odrl:assignee ex:Bob
    ] ;
    odrl:prohibition [
        a odrl:Prohibition ;
        odrl:target ex:PartB ;
        odrl:action odrl:present ;
        odrl:assignee ex:Alice 
    ] .

=

Invalid Policy:

# inferred
ex:PartA odrl:hasPolicy  .
ex:PartB odrl:hasPolicy  .

# becomes invalid because not >all< rules of the policy have 
# both ex:PartA and ex:PartB as their target

    a odrl:Policy;
    odrl:permission [
        a odrl:Permission ;
        odrl:target ex:PartA ;
        odrl:action odrl:present ;        
        odrl:assignee ex:Bob
    ] ;
    odrl:prohibition [
        a odrl:Prohibition ;
        odrl:target ex:PartB ;
        odrl:action odrl:present ;
        odrl:assignee ex:Alice 
    ] .

@simonstey simonstey reopened this Jun 16, 2017
@simonstey simonstey mentioned this issue Jun 16, 2017
Closed
@vroddon
Copy link
Contributor

vroddon commented Jun 16, 2017 via email

@simonstey
Copy link
Contributor

not according to 3.4.3 Has Target Policy:

Note: The Asset being identified MUST be inferred to be the target Asset of all of the Rules of the Policy.

either you ignore the MUST -> policy becomes invalid

or you add the inferred target triples to the rules and end up with a new policy with different semantics

@vroddon
Copy link
Contributor

vroddon commented Jun 16, 2017

In which sense is the word "inferred" used?
If informally, I would say my expression is totally correct.
If formally, it would not, unless we add this SWRL expression (what we do not want...):

assigner(?policy, ?X) ∧ permission(?policy,?P) ⇒ assigner(?P,?X)

@simonstey
Copy link
Contributor

As for the turtle shortcut:
odrl:permission odrl:present ;

We need to add this example to the "Policy Rule Composition" section.

I don't think we should allow this..
The benefits of being able to do something like this:

 
    a odrl:Policy ;   
    odrl:permission odrl:present, odrl:archive, odrl:share .

instead of:

 
    a odrl:Policy ;   
    odrl:permission [
        a odrl:Permission ; # we could even allow to omit this
        odrl:action odrl:present, odrl:archive, odrl:share ;
    ] .

don't outweigh all the issues/complications this would come with..

(btw., that wouldn't be a turtle shortcut only.. all of that applies to any serialization of ODRL)

@riannella
Copy link
Contributor

I am all for minimising "issues and complications" ;-)
@vroddon ok?

@vroddon vroddon mentioned this issue Jun 21, 2017
Closed
@vroddon
Copy link
Contributor

vroddon commented Jun 21, 2017

About allowing: odrl:permission odrl:present
Pros:

  • A policy can be described as a resource (policy01) with a set of 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.

Cons:

  • An extra burden for rigorous implementors, who will need to implement another branch to evaluate policies (big "if").
  • The lack of elegance of specifying two manners to do the same
  • An additional source of contradictions (but already possible)

@simonstey Am I missing anything else?
I would like this to hear more opinions, but indeed I am ok for "minimising issues and complications"

@nitmws
Copy link
Contributor

nitmws commented Jun 21, 2017 •
edited
Loading

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? To have less characters in a policy document? This drove an IPTC team to create a standard in 2008 with "property names not longer than 12 characters" - today we say "that's history" and add properties with 20 characters.

vroddon pushed a commit that referenced this issue Jun 21, 2017
Changed the range of three properties, as per issue #184
ef769e8
@vroddon
Copy link
Contributor

vroddon commented Jun 21, 2017

In such a case, I believe we can close this issue.
I have effected the changes in commit ef769e8

The range of :permission, :prohibition and :duty have been updated and consequently limited.

@vroddon vroddon closed this as completed Jun 21, 2017
@riannella
Copy link
Contributor

Reopening this - just from a process point-of-view - as this is an original "wide review" comment.

@aisaac are you ok with the resolution?

@riannella riannella reopened this Jun 22, 2017
@simonstey
Copy link
Contributor

simonstey commented Jun 22, 2017 •
edited
Loading

@vroddon

About allowing: odrl:permission odrl:present
Pros:

  • 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.

@nitmws

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? (btw. I agree with you on this)

@aisaac
Copy link
Author

aisaac commented Jun 22, 2017 via email

@simonstey
Copy link
Contributor

(short answer for now)

Of course this would require that this axiom is true, which is not clear. The "The processing model for Policies with multiple Assets, Parties, and Actions declared at the Policy-level" only propagates the target from a Policy to its attached Permissions or Prohibitions.

it propagates it to all attached Perm/Proh.

which would together with ->

(this says that whenever there's a path policy-permission-target or policy-prohibition-target then one can infer a statement policy odrl:target target)

prevent policies from having rules with different targets.

@aisaac
Copy link
Author

aisaac commented Jun 22, 2017 via email

@nitmws
Copy link
Contributor

nitmws commented Jun 22, 2017

@simonstey my view on 2.7 Policy Rule Composition

First para (A Policy may contain ...) states "... each Rule may contain multiple Assets, Parties, Actions, Constraints, and Duties ..." but the Rule definition talks only about "an Action/Asset" vs "one or more Parties/Constraints". This lets me conclude: only a single Action or Asset is allowed, but multiple Parties and Constraints.

But the ODRL specification appears to be different: the section about "create the atomic Rules" (further down in this 2.7 section and hidden between examples) is based on the view "each Rule may contain multiple Assets, Parties, Actions, Constraints, and Duties".
And it covers what @simonstey shows in the Policy Inference document.

This lower region of 2.7 also introduces Assets, Parties and Actions at the Policy level. These are shortcuts opening the expression of Asset(s), Party/ies and Actions of a Rule to two different ways.
And the wording there is wrong: "This implies that these (Asset, Party, Action) classes are all common to all the Rules in the Policy,". No, they don't apply to any Duty Rule.
As said above, shortcuts may save come characters but makes processing a Policy harder - and I hope all Policy Architects will be aware that an Action at the Policy level applies to both permissions and prohibitions, a potential source of conflict.

These shortcuts may raise confusion as also Constraints may occur at the Policy level - but they do NOT apply to all Permission/Prohibitions of a Policy. In fact these Constraints are no shortcuts - what makes a distinction?

The second para of 2.7 reminds of issue of #173: what is the "core" of ODRL? The IM Introduction says "The information model covers the core concepts, entities and relationships that provide the foundational model for content usage statements." My conclusion: each word in the Information Model is about the core ODRL except words in non-normative sections - oops, the Introduction is non-normative.
Finally the second para tells: "This example shows the atomic level of a Policy where it is an irreducible Rule (that is, not able to be reduced or further simplified)". Based on what definitions or rules has Example 21 been formulated? Or is Example 21 the rule?

@riannella
Copy link
Contributor

@aisaac

In the context of the the Processing Model that propagates a policy's target to all it's permissions and prohibitions, this seems quite compatible with
odrl:hasPolicy owl:inverseOf odrl:target

But it does not work the other way...if you have a Policy with two Permissions each with a different target Asset. The inverse will mean that each target Asset is a target to the entire Policy.

@riannella
Copy link
Contributor

With Duties now becoming part of the Policy-level Rules #162 we need to revisit the "Policy Rule Composition" narrative...

@simonstey
Copy link
Contributor

But it does not work the other way...if you have a Policy with two Permissions each with a different target Asset. The inverse will mean that each target Asset is a target to the entire Policy.

with odrl:hasPolicy owl:inverseOf odrl:target and given following policy:

 
    a odrl:Policy ;   
    odrl:permission [
        a odrl:Permission ; 
        odrl:action odrl:present ;
        odrl:target ex:Asset1 ;
    ] ;
    odrl:prohibition [
        a odrl:Prohibition ; 
        odrl:action odrl:share ;
        odrl:target ex:Asset2 ;
    ] ;

a reasoner would infer:

ex:Asset1 odrl:hasPolicy _:bPerm .
ex:Asset2 odrl:hasPolicy _:bProhib .

@riannella
Copy link
Contributor

wouldn't it infer:

ex:Asset1 odrl:hasPolicy  .
ex:Asset2 odrl:hasPolicy  .

@simonstey
Copy link
Contributor

wouldn't it infer:

ex:Asset1 odrl:hasPolicy  .
ex:Asset2 odrl:hasPolicy  .

no, because in:

 
    a odrl:Policy ;   
    odrl:permission [
        a odrl:Permission ; 
        odrl:action odrl:present ;
        odrl:target ex:Asset1 ;
    ] ;
    odrl:prohibition [
        a odrl:Prohibition ; 
        odrl:action odrl:share ;
        odrl:target ex:Asset2 ;
    ] ;

the subjects of the two odrl:target triples are the two Rule blank nodes:

 a odrl:Policy .

 odrl:permission _:bPerm .
_:bPerm a odrl:Permission .
_:bPerm odrl:action odrl:present .
_:bPerm odrl:target ex:Asset1 .
ex:Asset1 odrl:hasPolicy _:bPerm . # inferred

 odrl:prohibition _:bProh .
_:bProh a odrl:Prohibition .
_:bProh odrl:action odrl:share .
_:bProh odrl:target ex:Asset2 .
ex:Asset2 odrl:hasPolicy _:bProh . # inferred

@riannella
Copy link
Contributor

Ok, so I removed the inverseOf axiom as I thought from here:
#184 (comment)
That it was not correct?

@simonstey
Copy link
Contributor

Ok, so I removed the inverseOf axiom as I thought from here:
#184 (comment)
That it was not correct?

aah.. yes my bad..
it's still not correct though, because it would then point to a Rule instead of a Policy.

@riannella
Copy link
Contributor

Ok, just to be clear, we don't add the inverseOf axioms.

@simonstey
Copy link
Contributor

Ok, just to be clear, we don't add the inverseOf axioms.

👍

@aisaac
Copy link
Author

aisaac commented Jul 31, 2017 via email

@aisaac
Copy link
Author

aisaac commented Jul 31, 2017 via email

@riannella
Copy link
Contributor

Thanks @aisaac - closing this issue
(Best Practices NOTE is still be worked on ;-)

@nitmws nitmws mentioned this issue Dec 20, 2017
Closed
@aisaac aisaac mentioned this issue Feb 14, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sereAbi sereAbi

@riannella riannella

Labels
Model Wide Review
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@aisaac @sereAbi @nitmws @vroddon @simonstey @riannella