- From: Myles, Stuart <SMyles@ap.org>
- Date: Wed, 9 Nov 2016 22:49:15 +0000
- To: Simon Steyskal <simon.steyskal@wu.ac.at>
- CC: W3C POE WG <public-poe-wg@w3.org>
- Message-ID: <2B3AA5056E3CB8428BDE670B2CEEC54FC6C7BDE3@CTCXMBX10.ap.org>
Hi Simon, Ø How would your engine evaluate/determine whether constrained permission is valid? I.e., x <= "2010-12-31"^^xsd:date -> where does "x" come from? What I wound up doing was creating a “context” for each requested action. The context consists of a series of assertions that correspond to things that could be constraints, such as location, purpose, time of execution and so on. In fact, I (re)used the “constraint” part of ODRL to express the context assertions. Since the engine can “understand” a set of possible types of constraints, I realized that possible set implies the range of constraint slots which need to be filled. So, in your example, I would have a slot for time for execution, which corresponds to “x”. The ODRL representation library I built is https://github.com/iptc/rightsml-dev/tree/master/licensed although the engine where I actually evaluate whether a particular action is permitted is an API that layers on top of licensed. Maybe one day I will get around to sprucing it up a bit and releasing that as open source, too? Regards, Stuart From: Simon Steyskal [mailto:simon.steyskal@wu.ac.at] Sent: Wednesday, November 09, 2016 2:33 AM To: Myles, Stuart Cc: W3C POE WG Subject: Re: About a more strict definition of Constraint Hi! > (What follows is all based on my experience with implementing an > engine to evaluate ODRL automatically. [...] Just out of curiosity (sry for hijacking your email discussion).. Given following ODRL policy: <http://example.com/policy:0811<http://example.com/policy:0811>> a odrl:Set; odrl:permission [ a odrl:Permission ; odrl:action odrl:play ; odrl:target <http://example.com/game:4589<http://example.com/game:4589>> ; odrl:constraint [ a odrl:Constraint ; odrl:operator odrl:lteq ; odrl:dateTime "2010-12-31"^^xsd:date ] ] . How would your engine evaluate/determine whether constrained permission is valid? I.e., x <= "2010-12-31"^^xsd:date -> where does "x" come from? br, simon --- DDipl.-Ing. Simon Steyskal Institute for Information Business, WU Vienna www: http://www.steyskal.info/<http://www.steyskal.info/> twitter: @simonsteys Am 2016-11-08 16:13, schrieb Myles, Stuart: > I don’t see how it is meaningful to constrain either parties or > targets. In fact, I think it just introduces problems for evaluating > policies. > > (What follows is all based on my experience with implementing an > engine to evaluate ODRL automatically. And it is the same argument for > why I think it is a mistake to indicate any properties of parties > other than their URI - such as whether or not they are a “group”). > > > When you’re evaluating an ODRL policy, you’re trying to determine > “Am I permitted to perform this action on this asset?”. More > generally, it could be stated as “Is Party P permitted to perform > Action A on Asset X?”. That means you need to determine whether > various entities in the Policy are “the same as” the entities > you’re interested in. Is the Policy Asset “the same as” Asset X > and is the Policy Assignee “the same as” Party P? (In fact, it is > much more complicated than this, as you also need to determine whether > the Policy Action is “the same as” Action A – ODRL actions are > hierarchical, so it is quite likely the action you wish to perform is > very granular, but the Policy Action could be much more general – an > ancestor of Action A in the ODRL tree. And the same thing applies to > values for constraints such as location – the Policy may constrain > actions in Europe. And you might want to perform the Action in > Istanbul or Geneva or London). > > So, a lot of the work that an ODRL evaluation engine must perform is > to evaluate rules to determine whether various values are “the same > as” other values. So, what would it mean to introduce constraints on > those values in the Policy itself? How can a Party have both a URI > *AND* a constraint? What is that meant to mean? I can understand a > Party URI which means “people known to be 18 years and older”. But > I don’t understand how an engine is meant to evaluate a URI and a > constraint – unless we want to introduce rules for how to deal with > contradictions between what is stated in the Policy constraints and > what is “known” by the evaluating engine. > > Regards, > > Stuart > > FROM: Renato Iannella [mailto:renato.iannella@monegraph.com] > SENT: Tuesday, November 08, 2016 8:40 AM > TO: W3C POE WG > SUBJECT: Re: About a more strict definition of Constraint > > I think the general issue is that we have associated the Constraint to > the Perm/Prohib/Duty, when we should have associated it directly to > the Action/Name. > > Michael’s example show that with the “odrl:constraintsubject” > having to explicitly refer to the odrl:action. > > And this gets worse when we introduce support for Constraints on > Asset’s and Parties. > > *IF* we move the constraint directly as a property of the Action/Name, > then we could express: > > odrl:permission [ > > a odrl:Permission ; > > odrl:target <http://example.com/music:4545<http://example.com/music:4545> [1]> ; > > odrl:assigner <http://example.com/sony:10<http://example.com/sony:10> [2]> ; > > odrl:action [ > > a odrl:Action ; > > rdf:value odrl:copy ; > > odrl:constraint [ > > a odrl:Constraint ; > > odrl:count 1 ; > > odrl:operator odrl:lteq > > ] > > ] > > ] . > > This makes the constraint clearly associated with the odrl:copy action > (and all constraints in that Action will apply to the same). > > Then, when we add a Constraint to the Target, the subject is clear: > > odrl:target [ > > a odrl:Asset ; > > rdf:value <http://example.com/music:4545<http://example.com/music:4545> [1]> ; > > odrl:constraint [ > > a odrl:Constraint ; > > spotify:artist <http://music.net/people:prince<http://music.net/people:prince> [3]> ; > > odrl:operator odrl:eq > > ] > > ] > > And the same for Party: > > odrl:assignee [ > > a odrl:Party ; > > rdf:value <http://example.com/billie<http://example.com/billie>> ; > > odrl:constraint [ > > a odrl:Constraint ; > > spotify:age 18 ; > > odrl:operator odrl:gteq > > ] > > ] > > Then we have our favourite example…the constraint on a constraint. > > The constraint “end of the football match” is further constrained > by a “30 min time period”: > > odrl:action [ > > a odrl:Action ; > > rdf:value odrl:distribute ; > > odrl:constraint [ > > a odrl:Constraint ; > > odrl:event <http://premier-league.com/end-of-match<http://premier-league.com/end-of-match> ; > > odrl:operator odrl:eq ; > > odrl:constraint [ > > a odrl:Constraint ; > > odrl:dateTime "P30M" ; > > odrl:operator odrl:gteq ; > > ] > > ] > > ] . > > Renato > > ps: i’ve used rdf:value here but we could define our own predicate > > Links: > ------ > [1] http://example.com/music:4545<http://example.com/music:4545> > [2] http://example.com/sony:10<http://example.com/sony:10> > [3] http://music.net/people:prince<http://music.net/people:prince>
Received on Wednesday, 9 November 2016 22:50:24 UTC