RE: Updated ODRL in JSON DRAFT

Hi Mo,

You're right, of course, that any kind of change boils down to weighing the costs and benefits.

What exactly are the benefits of making this change?  (Which I take to be to have the element names in XML and maybe the JSON property names match the OWL Class names)

In terms of the costs, you're right that there are not a lot of current implementations of ODRL v2 using XML (and none using JSON or RDF/OWL, I suspect). And that, since we decided to alter the vocabulary and namespace URLs, there is already some amount of change that existing implementations are going to need to accommodate.

In my view, altering the existing uses of XML to use a different namespace URI and to use a different vocabulary prefix is relatively small and unlikely to provoke too much worry. Whereas changing the element names could trigger more fundamental pushback, because it might seem that ODRL v2 is more of a shifting foundation than you would expect from a mature, ready-to-implement standard. Within the IPTC RightsML group, I've mentioned that we are going to need to bring our implementation examples (http://dev.iptc.org/RightsML-Implementation-Examples) into compliance, not to mention the specs for RightsML and other published documents. Certainly not impossible, but when I mentioned it, the first reaction is, "well, we did say that we don't need to have RightsML stay in lock step with ODRL v2, so we'll need to decide whether to make these changes". Of course, this is partly just the tricky dynamics of different organizations working together. But it does highlight that there is some impact to published work.

If we're going to make changes, it is better to do them sooner, rather than later, for obvious reasons. We just need to be able to articulate clearly why it will be better and to be reasonably confident that those benefits outweigh the costs.

Regards,

Stuart



-----Original Message-----
From: Mo McRoberts [mailto:Mo.McRoberts@bbc.co.uk] 
Sent: Monday, May 19, 2014 3:39 PM
To: Myles, Stuart
Cc: Renato Iannella; ODRL Community Group (Contrib)
Subject: Re: Updated ODRL in JSON DRAFT


On  2014-May-19, at 15:51, Myles, Stuart <SMyles@ap.org> wrote:

> That's the way these kinds of plans go, I know.
>
> Ø  2 - Update the XML Encoding to use the same URIs from the ODRL 
> Ontology [2] Ø  (this includes uppercase changes to the XML Schema, 
> such as <policy> to <Policy>)
>
> Oh - I don't recall that ever being discussed. Did I miss it? It is a pretty large change. For example, all of the examples that we've compiled on the IPTC website use the current XML syntax and element names:
>
> http://dev.iptc.org/RightsML-Simple-Example-An-Action

My take on this is that it would be a nice thing to transition to - but it obviously needs to be managed sanely. With LOD you can use plain old HTTP redirects and entries in the schema to manage that, but there isn't a well-defined mechanism for XML itself...

Do we have any idea of numbers of people/applications actively using the schema? i.e., the real-world impact of any change?

(I'm wondering how this applies to some of the deprecated elements, too?)

> Ø  In the *long term* the ODRL Ontology will become our normative 
> specification, so using the same URIs now in the other encodings will 
> save us some grief ;-)
>
> I can certainly see that using the same URIs makes sense. But there is also the question of backwards compatibility. It is one thing to be able to change the URL scheme for vocabulary values, but it is quite another to alter the element and attribute names in XML. For example, the current RightsML examples use the current XML encoding spec:
>
> <o:policy uid="http://example.com/RightsML/policy/idActionPrint1"
>  type="http://w3.org/ns/odrl/vocab#set"
>  xmlns:o="http://w3.org/ns/odrl/2/">
>    <o:permission>
>       <o:asset uid="urn:newsml:example.com:20090101:120111-999-000022"
>        relation="http://w3.org/ns/odrl/vocab#target"/>
>       <o:action name="http://w3.org/ns/odrl/vocab#print"/>
>       <o:party uid="http://example.com/cv/party/epa"
>        function="http://w3.org/ns/odrl/vocab#assigner"/>
>       <o:party uid="http://example.com/cv/policy/group/epapartners"
>        function="http://w3.org/ns/odrl/vocab#assignee"/>
>    </o:permission>
> </o:policy>
>
> It is relatively simple to instead use the Ontology URLs for vocabulary items:
>
> <o:policy uid="http://example.com/RightsML/policy/idActionPrint1"
>  type="http://www.w3.org/ns/odrl/2/set"
>  xmlns:o="http://www.w3.org/ns/odrl/2/">
>    <o:permission>
>       <o:asset uid="urn:newsml:example.com:20090101:120111-999-000022"
>        relation="http://www.w3.org/ns/odrl/2/target"/>
>       <o:action name="http://www.w3.org/ns/odrl/2/print"/>
>       <o:party uid="http://example.com/cv/party/epa"
>        function="http://www.w3.org/ns/odrl/2/assigner"/>
>       <o:party uid="http://example.com/cv/policy/group/epapartners"
>        function="http://www.w3.org/ns/odrl/2/assignee"/>
>    </o:permission>
> </o:policy>
>
> The two are essentially equivalent - just different URL schemes and easy for a parse to support both, for example.
>
> However, altering the element and attribute names means that they are totally different schemas:

I'm guessing you're thinking that, e.g., XSLT transforms will have to be updated in a more in-depth way than just updating the namespace URI?

To be a bit pedantic, it is a different schema in either case (given it's applied to (ns,local-name) - and if either part of that changes for a given element or attribute, it's a new 'thing'.) - but it's certainly true that it's easier to update a transform if it's *only* the namespace URI which is changing!

>
> <o:Policy Uid="http://example.com/RightsML/policy/idActionPrint1"
>  Type="http://www.w3.org/ns/odrl/2/set"
>  xmlns:o="http://www.w3.org/ns/odrl/2/">
>    <o:Permission>
>       <o:Asset Uid="urn:newsml:example.com:20090101:120111-999-000022"
>        Relation="http://www.w3.org/ns/odrl/2/target"/>
>       <o:Action Name="http://www.w3.org/ns/odrl/2/print"/>
>       <o:Party Uid="http://example.com/cv/party/epa"
>        Function="http://www.w3.org/ns/odrl/2/assigner"/>
>       <o:Party Uid="http://example.com/cv/policy/group/epapartners"
>        Function="http://www.w3.org/ns/odrl/2/assignee"/>
>    </o:Permission>
> </o:Policy>
>
> (I'm guessing the attribute names would need to be different, too. However, hopefully the above illustrates my point).

attribute names are still lowercase - it's only things which constitute classes in the model which have an initial cap. doesn't affect the meaning of your point, though!

M.

--
Mo McRoberts - Chief Technical Architect - Archives & Digital Public Space, Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA.

Inside the BBC? My movements this week: http://neva.li/where-is-mo








-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
-----------------------------


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 email. Thank you.
[IP_US_DISC]

msk dccc60c6d2c3a6438f0cf467d9a4938

Received on Tuesday, 20 May 2014 17:35:27 UTC