[Odrl-version2] Model change?

[Guth, Susanne, VF-Group]

Hi Francis,
 
thanks for your new example and for pointing out the inconsistency of the XML schema.
Lets discuss if, the XML schema should be changed in our call.
 
Kind regards and have a nice weekend.
Susanne

________________________________

From: odrl-version2-bounces at odrl.net [mailto:odrl-version2-bounces at odrl.net] On Behalf Of Francis Cave
Sent: Donnerstag, 18. November 2010 16:28
To: 'ODRL-Version2'
Subject: Re: [Odrl-version2] Model change?



Hi Susanne

 

Sorry, my sample XML is not valid, I realise. I just didn't add an <o:asset> element (which is mandatory in the schema) because it is not central to my concern.

 

<o:policy

  xmlns:o="http://odrl.net/2.0"

  xmlns:a="http://assigner.com/identifiers"

  type="o:set"

  inheritAllowed="true"

  conflict="prohibit">

    <o:permission>

        <o:asset uid="myAssetURI"/>

        <o:role uid="a:anyParty" function="o:assignee"/>

        <o:action name="o:distribute"/>

    </o:permission>

    <o:permission>

        <o:asset uid="myAssetURI"/>

        <o:role uid="a:party_A" function="o:assignee"/>

        <o:action name="o:distribute"/>

        <o:constraint

          name="o:media"

          operator="o:neq"

          rightOperand="a:online"/>

    </o:permission>

</o:policy>

 

I also wonder whether the <o:role> element in the first permission is needed. In the Core Model a Permission must have at least one Party, but in the XML schema <o:role> is non-mandatory.

 

Regards,

 

Francis

 

 

 

From: odrl-version2-bounces at odrl.net [mailto:odrl-version2-bounces at odrl.net] On Behalf Of Guth, Susanne, VF-Group
Sent: 18 November 2010 15:09
To: ODRL-Version2
Subject: [Odrl-version2] Model change?

 

Dear all,

 

I apologize that I can not follow all discussions. However, I just saw that obviously a fundamental change was done in the ODRL model.

Assets need to be mandatory in each permission. Otherwise a permission can not be referred to a concrete asset. In the model the cardinality must be changed back to 1. And only 1.

Basis for this is the role based access model (rbac), where permissions describe the permissions that are allowed to certain assets. 

 

Renato, can you please also but this on the agenda of our Skype call.

Thanks

Susanne

--------------------------------------------------------------------
Dr. Susanne Guth-Orlowski
Principal Development Manager B2B Enablers

Vodafone Group Services GmbH, VIS, Content Services
Mannesmannufer 2, D-40213 Düsseldorf
phone: +49 211 820-2098, mobile: +49 162 2678760

 

 

 

________________________________

From: odrl-version2-bounces at odrl.net [mailto:odrl-version2-bounces at odrl.net] On Behalf Of Francis Cave
Sent: Donnerstag, 18. November 2010 15:37
To: 'ODRL-Version2'
Subject: Re: [Odrl-version2] Party constraints

If you have the exact same Action in both Permission and Prohibition, then the Perm will win out.

But in your case, the Action in the Prohibition is further constrained (hence, not the same) so there is actually no conflict to trigger.

 

This is an important point that is not explained anywhere in the Core Model. In what circumstances can a conflict be triggered? Here is the example I was thinking of:

 

<o:policy

  xmlns:o="http://odrl.net/2.0"

  xmlns:a="http://assigner.com/identifiers"

  type="o:set"

  inheritAllowed="true"

  conflict="prohibit">

    <o:permission>

        <o:role uid="a:anyParty" function="o:assignee"/>

        <o:action name="o:distribute"/>

    </o:permission>

    <o:permission>

        <o:role uid="a:party_A" function="o:assignee"/>

        <o:action name="o:distribute"/>

        <o:constraint

          name="o:media"

          operator="o:neq"

          rightOperand="a:online"/>

    </o:permission>

</o:policy>

 

The intention here is to express that only Party A is prohibited from distributing the asset online. The first permission allows everyone else to distribute the asset in any fashion. The second permission allows Party A to distribute the asset in any fashion EXCEPT online.

 

My assumption had been that one has to specify how to resolve the conflict between the fact that the first permission says that Party A is permitted to distribute the asset online, while the second permission says that Party is NOT so permitted. Why is the 'conflict' attribute on the Policy not needed in this case? Two permissions that are identical will never conflict, so there will always be a difference in the expression if they do conflict, and that difference is going to usually be in the Constraints somewhere.

 

Francis

 

 

From: odrl-version2-bounces at odrl.net [mailto:odrl-version2-bounces at odrl.net] On Behalf Of ri at odrl.net
Sent: 18 November 2010 08:40
To: ODRL-Version2
Subject: Re: [Odrl-version2] Party constraints

 

 

On 18 Nov 2010, at 09:25, Francis Cave wrote:

 

That's fine so long as one is able to include conflict="prohibit" at the Policy level. But what happens if, for other reasons, one needs conflict="permit" at the Policy level?

 

If you have the exact same Action in both Permission and Prohibition, then the Perm will win out.

But in your case, the Action in the Prohibition is further constrained (hence, not the same) so there is actually no conflict to trigger.

 

	 This leads to a more general question. Suppose that a Policy contains some permissions and prohibitions where the intended resolution of conflicts is to prohibit, whereas there are other permissions and prohibitions where the intended resolution of conflicts is to permit. Would such cases be inexpressible in ODRL? Or would one simply attach multiple Policies to the asset in question?

 

I think multiple Policies is the safest way...

 

R

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://odrl.net/pipermail/odrl-version2_odrl.net/attachments/20101119/4bb3ba80/attachment-0001.html>