[Odrl-version2] Model change?

[Francis Cave]

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/20101118/37edd62a/attachment.html>