[Odrl-version2] Some comments concerning Assigner/Assignee

[Daniel Pähler]

Dear all,

Andreas, Helge, Rainer and I talked about the ODRL-2.0-Java-implementation 
some more, and we discovered some problems that affect both the Core Model and 
the XML Encoding.

1. Stuart already remarked on this: in the originally proposed XML Encoding, 
the "role" attribute seems to be attached to the party - I say "seems" because 
XML does not have inherent semantics. In the Core Model, too, the roles are 
explained as belonging to the party.

We agree with Stuart: "Assigner" and "Assignee" should not belong to Party, 
because this means that if we have Party P that is Assigner of Permission X 
and Assignee of Permission Y, it would end up having both roles in its 
aggregated form (and the information "which role relates to which permission" 
would be lost). The only way to solve this would be splitting P up into to 
different Parties (which are mostly identical) with one role each, but this 
wouldn't be elegant, either.

Instead, we suggest that the "Assigner"/"Assignee" Information be put into 
Permission, Prohibition, and Duty. Put into Renato's "final example" (mailed 
yesterday at 07:59 CET), this could look as follows:

-------------------------------------------------
<o:rights xmlns:o="http://odrl.net/2.0/" uid="urn:exp:0231" 
xmlns:d="http://purl.org/dc/elements/1.1/"
    type="http://odrl.net/2.0/type/offer">
    <o:permission>
        <o:asset xml:idref="A1" />
        <o:action resource="http://odrl.net/2.0/action/play"/>
        <o:duty xml:idref="D1"/>
        <o:assigner>
                <o:party xml:idref="P1" />
        </o:assigner>     
    </o:permission>
    <o:permission>
        <o:asset xml:idref="A1" />
        <o:action resource="http://odrl.net/2.0/action/copy"/>
        <o:constraint name="http://odrl.net/2.0/constraint/count"
            operator="http://odrl.net/2.0/operator/lteq"  rightOperand="1"/>
        <o:duty xml:idref="D1"/>
        <o:assigner>           
                <o:party xml:idref="P1" />
        </o:assigner>                
    </o:permission>
    <o:duty xml:id="D1">
        <o:action resource="http://odrl.net/2.0/action/pay"/>
        <o:object measure="http://odrl.net/2.0/object/EUR" value="0.50"/>
        <o:assigner>           
                <o:party ixml:idref="P1"/>
        </o:assigner>               
    </o:duty>
    <o:asset xml:id="A1" uid="urn:music:4545">
        <d:title>Purple Rain</d:title>
        <d:creator>Prince</d:creator>
    </o:asset>
    <o:party xml:id="P1" uid="urn:sony:10">
        <v:org>Sony Music International Inc</v:org>
        <v:tel>+555 5555 5555 Inc</v:tel>
    </o:party>
</o:rights>
-------------------------------------------------

One obvious flaw is the fact that "Assignee", which is actually just a relation 
between entities in the Core Model, would become a separate XML element. Maybe 
someone else has a better idea, I just wanted to point out the problem.

2. Before actually adopting a solution for the role problem in the XML 
Encoding, a slight correction in the Core Model might be necessary: as far as 
we can see, each arrow in the diagram in [1] can be read as (prefixed with) 
"has", i.e. Rights has Permission, Action hasNextRights Rights, Permission 
hasTarget Asset, etc. Even the arrows for Assignee can be read as "Permission 
hasAssignee Party" - only the Assigner arrows don't work that way, so they 
should be turned around.

By the way, the cardinalities of "Assignee" are incorrect: a Permission can 
have 0..* Parties as Assignees, but one Party can also be Assignee of 0..* 
Permissions (the current diagram says "1" here). 

3. We couldn't figure out why the Core Model has the relation "Assignees" 
(notice the plural 's'). Come to look at [2] a little closer, I notice that 
for Permissions and Prohibitions, Assignee and Assignees both relate to 
consumers, but for duty, Assignee relates to a debtor while Assignees relates 
to creditors. I think what was meant in the latter case was probably an 
"Assigners" relation.

Apart from that, we think that the relation name should not convey the 
information if a Party represents one person/legal entity or many. If the user 
of an ODRL license wants to know if a Party comprises one or many, than this 
information should be found in the Party entity (if this is needed at all).

We suggest that Assignees be taken out, and the cardinality of Assigner 
between Party and Duty changed from "1" to "1..*" to allow for one Duty to 
have many Parties as its Assigners.

Greetings from Koblenz,
Daniel

PS: I'll be away from my office for a while, so I might not be able to 
participate in the discussion in the next two weeks.

PPS: If anyone of you is at the CeBIT next week, come and visit us at Hall 9, 
Booth C39, Table #33, where we present our ODRL-using project "Usage Rights 
Management".

[1] http://odrl.net/2.0/DS-ODRL-Model.html#section-2
[2] http://odrl.net/2.0/DS-ODRL-Model.html#section-23
-- 
Dipl.-Inform. Daniel Pähler

Institute for IS Research
University of Koblenz-Landau
Universitaetsstrasse 1
D-56070 Koblenz
Fon +49-(0)261-287-2644
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4295 bytes
Desc: not available
URL: <http://odrl.net/pipermail/odrl-version2_odrl.net/attachments/20100226/16cc4687/attachment.bin>