[Odrl-version2] XML Encoding - early WD release
Guth, Susanne, VF-Group
Susanne.Guth at vodafone.com
Thu Feb 25 03:29:20 EST 2010
OK,
Thanks for clarifying.
We highly appreciate your input and efforts.
Kind regards
Susanne
-----Original Message-----
From: odrl-version2-bounces at odrl.net
[mailto:odrl-version2-bounces at odrl.net] On Behalf Of Myles, Stuart
Sent: Mittwoch, 24. Februar 2010 17:24
To: ODRL-Version2
Subject: Re: [Odrl-version2] XML Encoding - early WD release
Hi Susanne,
> Why are you adding the party element again in the duty element?
> <o:party idref="urn:sony:10"
I didn't modify the <duty> element at all in the first version - it is
just a copy and paste from the 4.2 The Offer on the ODRL webpage
(http://odrl.net/2.0/WD-ODRL-XML-20100212.html#section-4). It contains
the party element already:
<o:duty id="1">
<o:action resource="http://odrl.net/2.0/action/pay"/>
<o:object measure="http://odrl.net/2.0/object/EUR"
value="0.50"/>
<o:party uid="urn:sony:10"
role="http://odrl.net/2.0/role/assigner/">
</o:duty>
In my suggested markup, I changed the @uid attribute to be an idref, to
indicate that this is a reference to the party with id="urn:sony:10".
> Having the party element within each permission is the heart of our
core
> model. Somewhere you have to clearly assign the permission to a party.
Absolutely - all I'm suggesting is that the assignment of parties and
their roles be done via reference in the XML, rather than by inclusion.
The information conveyed is the same, it is just represented in a more
concise, consistent and easy-to-process manner.
Regards,
Stuart
-----Original Message-----
From: odrl-version2-bounces at odrl.net
[mailto:odrl-version2-bounces at odrl.net] On Behalf Of Guth, Susanne,
VF-Group
Sent: Wednesday, February 24, 2010 10:15 AM
To: ODRL-Version2
Subject: Re: [Odrl-version2] XML Encoding - early WD release
Hi Stuart,
Why are you adding the party element again in the duty element?
<o:party idref="urn:sony:10"
Its already part of the permission.
Having the party element within each permission is the heart of our core
model. Somewhere you have to clearly assign the permission to a party.
Kind regards
Susanne
-----Original Message-----
From: odrl-version2-bounces at odrl.net
[mailto:odrl-version2-bounces at odrl.net] On Behalf Of Myles, Stuart
Sent: Mittwoch, 24. Februar 2010 15:50
To: ODRL-Version2
Subject: Re: [Odrl-version2] XML Encoding - early WD release
Leaving aside the contents of the identifiers (CURIEs or URIs), let me
see if I can illustrate my other suggestions? I suggest that ODRL needs
to more clearly distinguish an identifier from a reference to an
identifier. And I think that the current encoding requires (or at least
allows) quite a lot of duplication of markup. I think that reducing
this duplication and distinguishing identifiers from references to
identifiers will result in a simpler processing model for clients of
ODRL.
Here, I've combined two bits of example markup from
http://odrl.net/2.0/WD-ODRL-XML-20100212.html - specifically, I took the
"4.2 Offer" example markup and blended in the asset and party details
from section "3. XML Encoding". Is the following correct ODRL markup
per the current encoding model?
<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 uid="urn:music:4545">
<d:title>+555 5555 5555 Inc</d:title>
<d:creator>+555 5555 5555 Inc</d:creator>
</o:asset>
<o:action resource="http://odrl.net/2.0/action/play"/>
<o:duty idref="1"/>
<o:party uid="urn:sony:10"
role="http://odrl.net/2.0/role/assigner/">
<v:org>Sony Music International Inc</v:org>
<v:tel>+555 5555 5555 Inc</v:tel>
</o:party>
</o:permission>
<o:permission>
<o:asset uid="urn:music:4545">
<d:title>+555 5555 5555 Inc</d:title>
<d:creator>+555 5555 5555 Inc</d:creator>
</o:asset>
<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 idref="1"/>
<o:party uid="urn:sony:10"
role="http://odrl.net/2.0/role/assigner/">
<v:org>Sony Music International Inc</v:org>
<v:tel>+555 5555 5555 Inc</v:tel>
</o:party>
</o:permission>
<o:duty id="1">
<o:action resource="http://odrl.net/2.0/action/pay"/>
<o:object measure="http://odrl.net/2.0/object/EUR"
value="0.50"/>
<o:party uid="urn:sony:10"
role="http://odrl.net/2.0/role/assigner/"/>
</o:duty>
</o:rights>
The ability or need to repeat the details of the asset and party in each
permission block strikes me as odd. If an asset has those details, is
it necessary to repeat them exactly in each permission? What is a
client meant to do if there are different details in each permission
(e.g. one has the d:title and the other has the d:creator)? What
happens if there are different d:title values in each asset - should
they aggregrate them together? (Assets can certainly have more than one
title, right?) It seems to me a fairly complex processing model to
fully specify and comply with.
I like how the duty is represented - it is referenced in the two
permissions and defined in its own block. I suggest doing the same
thing for asset and party. That would give us something like this:
<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 idref="urn:music:4545" />
<o:action resource="http://odrl.net/2.0/action/play"/>
<o:duty idref="1"/>
<o:party idref="urn:sony:10"
role="http://odrl.net/2.0/role/assigner/" />
</o:permission>
<o:permission>
<o:asset idref="urn:music:4545" />
<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 idref="1"/>
<o:party uid="urn:sony:10"
role="http://odrl.net/2.0/role/assigner/" />
</o:permission>
<o:duty id="1">
<o:action resource="http://odrl.net/2.0/action/pay"/>
<o:object measure="http://odrl.net/2.0/object/EUR"
value="0.50"/>
<o:party idref="urn:sony:10"
role="http://odrl.net/2.0/role/assigner/"/>
</o:duty>
<o:asset id="urn:music:4545">
<d:title>+555 5555 5555 Inc</d:title>
<d:creator>+555 5555 5555 Inc</d:creator>
</o:asset>
<o:party id="urn:sony:10">
<v:org>Sony Music International Inc</v:org>
<v:tel>+555 5555 5555 Inc</v:tel>
</o:party>
</o:rights>
This is slightly more concise but - more importantly - it is much
simpler to process: assets, duties and parties are all references
within the permission blocks. The role of a party within a permission
block is labeled within that block, rather than being inherent to the
party itself. There's no question as to where and how often to include
the party or asset details, there's no possibility of contradiction or
aggregation.
Does this make sense? If not, can you explain why it is a good idea for
duty to be modeled in this way, but not asset or party?
Regards,
Stuart
-----Original Message-----
From: odrl-version2-bounces at odrl.net
[mailto:odrl-version2-bounces at odrl.net] On Behalf Of ri at odrl.net
Sent: Tuesday, February 23, 2010 12:25 AM
To: ODRL-Version2
Subject: Re: [Odrl-version2] XML Encoding - early WD release
On 23 Feb 2010, at 08:30, Myles, Stuart wrote:
> 1. Identifier and Identifier Reference Attribute Names There is some
> inconsistency in the naming and use of identifiers and references to
> identifiers. For example, you use @uid for //asset and //party, @id
> for //duty and @resource for //action and //measure. I suggest
> standardizing on @id/@idref for all of them.
Stuart - these names map onto what we used in the Core Model (for
consistency).
("resource" should be "name" for actions)
We could change the model and use the same term for all (that reference
to a URI)?
We use id/idref purely as an internal XML linking mechanism.
(these attributes should be prefixed with "xml:")
> 2. Structure of Identifiers
> You use URNs and URIs for various identifiers. I suggest you consider
> adopting the CURIE syntax http://www.w3.org/TR/curie/ which allows for
a
> very compact syntax that allows identifiers to be globally unique, but
> doesn't impose centralized control.
Will this be more work for implementors, as we would have to define
these elements as containing both URIs and CURIES?
I can understand using them for a micro-format?
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
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
_______________________________________________
Odrl-version2 mailing list
Odrl-version2 at odrl.net
http://odrl.net/mailman/listinfo/odrl-version2_odrl.net
_______________________________________________
Odrl-version2 mailing list
Odrl-version2 at odrl.net
http://odrl.net/mailman/listinfo/odrl-version2_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