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.
-----------------------------

Received on Monday, 19 May 2014 19:39:33 UTC