[Odrl-version2] Some comments concerning Assigner/Assignee
ri at odrl.net
ri at odrl.net
Tue Mar 2 12:22:49 EST 2010
Thanks Daniel....lets discuss/agree on these points at the next teleconference....
Quickly, we added Assignees (plural) to indicate that you are giving rights to a Group.
It was in the original requirements, but perhaps we can express it better [1].
For the party XML syntax, perhaps we can allow both by adding role to idref as well.
For example:
<o:party xml:idref="P1" role="http://odrl.net/2.0/role/assigner/" />
And P1 can then describe the Party separate from the role...
R
[1] http://odrl.net/2.0/issues/issueslist-1_13.html
On 27 Feb 2010, at 01:28, Daniel Pähler wrote:
> 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
> _______________________________________________
> Odrl-version2 mailing list
> Odrl-version2 at odrl.net
> http://odrl.net/mailman/listinfo/odrl-version2_odrl.net
Cheers
Renato Iannella
ODRL Initiative
http://odrl.net
More information about the Odrl-version2
mailing list