[Odrl-version2] XML Encoding - early WD release

[Daniel Pähler]

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
-------------- 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/20100222/e40fe02d/attachment.bin>