[Odrl-version2] Some comments concerning Assigner/Assignee
Helge Hundacker
hundacker at uni-koblenz.de
Wed Mar 3 02:41:13 EST 2010
Hello,
> 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...
I'm not an XML expert, but isn't the semantics of this statement nearly the same like in the old notification?
Arn't attributes global? I think, if a tool will interpete that statemant, this means, that the role is bound to the id, which then will mean, that the party knows as "P1" is always an assigner. But maybe I'm wrong.
Greets, Helge
> 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
>
>
>
> _______________________________________________
> Odrl-version2 mailing list
> Odrl-version2 at odrl.net
> http://odrl.net/mailman/listinfo/odrl-version2_odrl.net
>
More information about the Odrl-version2
mailing list