- From: Víctor Rodríguez Doncel <vrodriguez@fi.upm.es>
- Date: Thu, 22 May 2014 15:03:41 +0200
- To: public-odrl-contrib@w3.org
Hi,
Do we have any assessment on how many people/projects are using ODRL v2.0?
Regards,
Víctor
El 22/05/2014 14:58, Myles, Stuart escribió:
> Hi Mo,
>
> Minimally, I think that calling the new set of standards ODRL v2.1 could help make discussions clearer. ("Oh, the RightsML implementation examples are v2 - they need to be updated to match v2.1"). I also think that it will help foster the understanding that we're talking about a managed, measured change to ODRL, with a new version being an improvement on the previous one (for such-and-such reasons). And, we would be able to announce ODRL v2.1 to the wider world - "now with OWL and JSON encodings, too!"
>
> So, I like the ODRL v2.1 suggestion.
>
> Regards,
>
> Stuart
>
>
>
>
>
>
>
> -----Original Message-----
> From: Mo McRoberts [mailto:Mo.McRoberts@bbc.co.uk]
> Sent: Wednesday, May 21, 2014 6:27 PM
> To: Myles, Stuart
> Cc: Renato Iannella; ODRL Community Group (Contrib)
> Subject: Re: Updated ODRL in JSON DRAFT
>
> Hi Stuart,
>
> That was precisely what I was trying to determine - i.e., low effort, but potentially significant impact.
>
> I wonder, and it may not be a good option, whether it's worth considering the unified ODRL, with some of the profiled elements removed, and so on, to be an "ODRL 2.1", rather than just a minor variation on 2?
>
> M.
>
> On 2014-May-20, at 18:34, Myles, Stuart <SMyles@ap.org> wrote:
>
>> 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
>>
>
> --
> 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
>
>
>
>
>
>
>
--
Víctor Rodríguez-Doncel
D3205 - Ontology Engineering Group (OEG)
Departamento de Inteligencia Artificial
Facultad de Informática
Universidad Politécnica de Madrid
Campus de Montegancedo s/n
Boadilla del Monte-28660 Madrid, Spain
Tel. (+34) 91336 3672
Skype: vroddon3
Received on Thursday, 22 May 2014 13:04:00 UTC