[Odrl-version2] XML Encoding - early WD release

Tue Feb 23 08:57:58 EST 2010

I suggest that the rightsholder may be the creator or the contributor or the publisher or that it may be an entirely different entity.  For example, an aggregator (such as Factiva) may become the rightsholder in a particular contractual situation. Also, a rightsholder may be different in different legal jurisdictions.  For example, I believe that photo's created by the French Press Agency (AFP) have AFP as the rightsholder within France, but the European Pressphoto Agency outside of France.

On the other hand, I support your suggestion of adopting the Dublin Core concepts of creator, contributor and publisher.  A given party could play any of the four roles.

In particular, it may be important to give attribution to the original creator of asset, even if that creator is not the publisher or the rightsholder.

Regards,

Stuart
--
P.S. I have some suggestions for the XML encoding, which I will send a different email, since they are not to do with the model, only the XML syntax.

-----Original Message-----
From: odrl-version2-bounces at odrl.net [mailto:odrl-version2-bounces at odrl.net] On Behalf Of Daniel Pähler
Sent: Monday, February 22, 2010 11:49 AM
To: ODRL-Version2
Cc: Andreas Kasten; Weißenfels; Rainer
Subject: Re: [Odrl-version2] XML Encoding - early WD release

Dear all,

On Friday 12 February 2010 07:27:25 ri at odrl.net wrote:
> Dear all - the ODRL V2.0 XML Encoding Working Draft is now available:
> 
>   http://odrl.net/2.0/WD-ODRL-XML-20100212.html
> [...]
> Please send any comments to the list....

Just last Friday, Andreas, Helge and I talked with our student Rainer about his bachelor thesis, which involves the parsing and writing of XML-encoded ODRL 2.0 in Java, and we had some insights that I'd like to share with you.

1. Up to now, we have been using ODRL 1.1 in our project "Usage Rights Management". We used (and, in a way, misused) the "rightsholder" element in user-generated licenses which were meant to be transferred to other users, so that the creator and the receiver of the license could still be distinguished.

We have noticed though that, in general, the semantics of "rightsholder" is very unclear: the Core Model says in section 2.3 [1]:
'A Party entity can be related to an Asset by being the Rights holder (owner) of such. This role allows expressing that someone simply "owns" an asset.'
Thus the question arises: Is the creator the rights holder? Or is the distributor the rights holder? And, since someone who buys a virtual asset also "owns" their copy and has the right to use it, could the buyer be the rights holder?

While thinking about this, we noticed the "ISSUE" at the bottom of section 3 [2] of the ODRL XML Encoding WD: 
"How do we express the rightsholder associations - do we really need it - we need an example".
In our opinion, rightsholder should be left out completely. Instead, we suggest that the Dublin Core vocabulary be used. As you can see in [3], Dublin Core has the properties "creator", "publisher", and "contributor", which are more precisely defined and probably better known than ODRL's "rightsholder".

2. As for the use of the DC properties in XML-encoded ODRL, it could probably be improved. In the example in [1], the asset has the string value "+555 5555
5555 Inc" as its d:creator, which is (coincidentally?) the same as v:tel of the only party in the license. Andreas and I think that a more direct link between a particular party and an asset should be possible by referencing a party from the asset, for example:

-------------------------------------------------
<o:asset uid="urn:music:4545">
    <d:title>+555 5555 5555 Inc</d:title>
    <d:publisher uid="urn:sony:10" />
</o:asset>       

<o:party uid="urn:sony:10">
    <v:org>Sony Music International Inc</v:org> </o:party>
-------------------------------------------------

The intended semantics is the following: the d:publisher element within the o:asset element is to be read as "has publisher", the uid contains the publishers unique name. Since the uid in d:publisher is the same as in the o:party element, it can be seen that we're talking about the same party in both cases, i.e. "Sony Music International Inc" is the publisher of asset "urn:music:4545".

If you don't like the double use of the attribute "uid", "resource" could be used as an alternative:

-------------------------------------------------
<o:asset uid="urn:music:4545">
    <d:title>+555 5555 5555 Inc</d:title>
    <d:publisher resource="urn:sony:10" /> </o:asset> 

<o:party uid="urn:sony:10">
    <v:org>Sony Music International Inc</v:org> </o:party>
-------------------------------------------------

By the way, it occured to Andreas and me that the XML attribute "resource" is not defined anywhere, and even though it is only used with o:action, its meaning is not obvious on first sight.

3. When looking at how entities are linked to each other, we came across section 4.3 [4] of the WD, where there's the question at the bottom: "Can we extrapolate the two Parties to make it more compact?" We think that the answer is "no", at least not in the given example. If there were additional data for of of the parties, e.g. a v.:tel, that would not have to be repeated each time, and could be put into a standalone XML element. But with the uid and the role attributes, there is no redundance that could be optimized away (even though it looks that way), since a party's role could be different for each permission, prohibition or duty (and the uid can obviously not be left out, either).

I hope that I could express our thoughts understandibly.

Greetings from Koblenz,
Daniel

[1] http://odrl.net/2.0/DS-ODRL-Model.html#section-23
[2] http://odrl.net/2.0/WD-ODRL-XML-20100212.html#section-3
[3] http://dublincore.org/2008/01/14/dcelements.rdf#
[4] http://odrl.net/2.0/WD-ODRL-XML-20100212.html#section-4
--
Dipl.-Inform. Daniel Pähler

Institute for IS Research
University of Koblenz-Landau
Universitaetsstrasse 1
D-56070 Koblenz
Fon +49-(0)261-287-2644

The information contained in this communication is intended for the use
of the designated recipients named above. If the reader of this 
communication is not the intended recipient, you are hereby notified
that you have received this communication in error, and that any review,
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please 
notify The Associated Press immediately by telephone at +1-212-621-1898 
and delete this e-mail. Thank you.
[IP_US_DISC]
msk dccc60c6d2c3a6438f0cf467d9a4938