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/  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
> [2] http://example.com/sony:10
> [3] http://music.net/people:prince

Received on Wednesday, 9 November 2016 07:33:14 UTC