[Odrl-version2] Some comments concerning Assigner/Assignee
Daniel Pähler
tulkas at uni-koblenz.de
Sat Feb 27 02:28:32 EST 2010
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>
More information about the Odrl-version2
mailing list