Re: About a more strict definition of Constraint

Stuart,

1) I have just learnt about your code at 
https://github.com/iptc/rightsml-dev/. Good!

2) I share your vision. When you speak about context reminds me about 
the authorisation model in MPEG-21 REL, which had as input not only the 
request and the specified licenses but also the "authorization context". 
In the MPEG-21 REL this was insufficiently formalized, and the 
authorization algorithm was a very poorly described procedure. I wished 
this could be improved this tiem.

Víctor

El 09/11/2016 a las 23:49, Myles, Stuart escribió:
>
> 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>
> a odrl:Set;
> odrl:permission [
> a odrl:Permission ;
> odrl:action odrl:play ;
> odrl:target <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 [1]> ;
> >
> > odrl:assigner <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 [1]> ;
> >
> > odrl:constraint [
> >
> > a odrl:Constraint ;
> >
> > spotify:artist <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> ;
> >
> > 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 ;
> >
> > 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>
>

-- 
Víctor Rodríguez-Doncel
D3205 - Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial
ETS de Ingenieros Informáticos
Universidad Politécnica de Madrid

Campus de Montegancedo s/n
Boadilla del Monte-28660 Madrid, Spain
Tel. (+34) 91336 3753
Skype: vroddon3