RE: About a more strict definition of Constraint

Hi Victor,


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

One day, I hope to update that code… ☺


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

My memory is a bit hazy, but I think I got the “context” idea from looking at other rules engines like Drools? So I certainly don’t claim it as original to me. And the fact that the concept appears in other similar systems is an indication that it might be a good idea.

I certainly agree with your suggestion that we decide upon and document the processing model for ODRL. I attempted to do so for RightsML http://dev.iptc.org/RIghtsML-Processing-Model with an eye to how news is typically licensed.

Regards,

Stuart


From: Víctor Rodríguez Doncel [mailto:vrodriguez@fi.upm.es]
Sent: Saturday, November 12, 2016 7:53 AM
To: public-poe-wg@w3.org
Subject: Re: About a more strict definition of Constraint

Stuart,

1) I have just learnt about your code at https://github.com/iptc/rightsml-dev/<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<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>



--

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