- From: Simon Steyskal <simon.steyskal@wu.ac.at>
- Date: Fri, 09 Dec 2016 06:44:12 +0100
- To: vrodriguez@fi.upm.es
- Cc: W3C POE WG <public-poe-wg@w3.org>
Hi!
>> In many cases, the Asset (target) and Parties (assigner, assignee)
>> are the same for multiple Permissions and Prohibitions in an ODRL
>> Policy.
>>
>> It maybe a useful change to support the Asset/Party at the Policy
>> level, which means that these values all apply to the enclosed
>> Perms/Prohibs (and conversely means that the Perms/Prohibs do not
>> define these values).
few questions:
1) If assets/parties are referred to at policy level, would it make
sense to introduce some sort of policy set concept for grouping multiple
policies?
2) what about duties?
3) could we then finally get rid of that weird "policy is subclassOf
asset" relationship [1]?
@victor
> This creates, again, alternative manners to express the same thing.
could you elaborate on that? because ->
>> (and conversely means that the Perms/Prohibs do not define these
>> values).
[1] https://lists.w3.org/Archives/Public/public-odrl/2015Jan/0016.html
---
DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna
www: http://www.steyskal.info/ twitter: @simonsteys
Am 2016-12-08 13:33, schrieb vrodriguez@fi.upm.es:
> I fully support this.
>
> This creates, again, alternative manners to express the same thing.
> But again, I believe that if necessary, a simple script can transform
> these expressions into a "canonical form".
>
> I guess that we can define a "canonical" representation of one policy.
> And then, different syntaxes that can be algorithmically mapped to the
> canonical representation.
> By having a canonical representation we can grant that (to some
> extent) policies with the same meaning can be compared and matched.
> This would be work, though, for the formalization task force, I guess.
>
> Víctor
>
> Renato Iannella <renato.iannella@monegraph.com> escribió:
>
>> In many cases, the Asset (target) and Parties (assigner, assignee)
>> are the same for multiple Permissions and Prohibitions in an ODRL
>> Policy.
>>
>> It maybe a useful change to support the Asset/Party at the Policy
>> level, which means that these values all apply to the enclosed
>> Perms/Prohibs (and conversely means that the Perms/Prohibs do not
>> define these values).
>>
>> If you look at this example:
>> http://w3c.github.io/poe/vocab/#sc-example8
>> <http://w3c.github.io/poe/vocab/#sc-example8>
>>
>> It would then look like:
>> {
>> "policytype": "http://www.w3.org/ns/odrl/2/Agreement",
>> "policyid": "http://example.com/policy:3433",
>> "conflict": "perm",
>> "target": "http://example.com/music:1234908",
>> "assigner": "http://example.com/sony:10",
>> "assignee": "http://example.com/billie:888"
>> "permissions": [{
>> "action": "http://www.w3.org/ns/odrl/2/play",
>> }],
>> "prohibitions": [{
>> "action": "http://oma.org/drm:ringtone",
>> }]
>> }
>>
>>
>> Renato Iannella, Monegraph
>> Co-Chair, W3C Permissions & Obligations Expression (POE) Working Group
Received on Friday, 9 December 2016 05:44:47 UTC