Re: ODRL 2.1 specs - terminology issues

I’ve checked it and re-written the first paragraph in Approach. Stuart, please confirm this re-drafting of the complexity language is OK.

	ODRL can express complex contracts and policies which may require quite sophisticated systems to evaluate contractual permissions, restrictions and duties. However, the ODRL in JSON encoding is designed to be lightweight and requires only standard JSON software to generate or parse the representation.

Cindy

> On Feb 24, 2015, at 10:01 AM, Myles, Stuart <SMyles@ap.org> wrote:
> 
> Yes – good suggestions. And I’ve made all of the ones you’ve suggested for the ODRL in JSON spec.
> 
> Regards,
> 
> Stuart
>  
>  
>  
> From: Víctor Rodríguez Doncel [mailto:vrodriguez@fi.upm.es <mailto:vrodriguez@fi.upm.es>] 
> Sent: Tuesday, February 24, 2015 9:09 AM
> To: public-odrl@w3.org <mailto:public-odrl@w3.org>
> Subject: Re: ODRL 2.1 specs - terminology issues
>  
> Thanks Michael for your feedback.
> 
> The changes look correct.
> 
> Víctor
> 
> El 24/02/2015 14:55, Michael Steidl (IPTC) escribió:
> Hi all,
> I tried to have an unbiased look at the different spec documents to find unclear or inconsistent terminology.
> Find below proposed changes with “MS notes” added.
>  
> ·         Common Vocabulary
> o   Section 1:
> The Common Vocabulary specifies the terms (vocabulary) used by the Core Model [ODRL-MODEL] <https://www.w3.org/community/odrl/work/2-0-common-vocabulary-constraint-draft-changes/#section-References> for policy expression needs.
> MS note: as other vocabularies may be used with ODRL “the terms” sounds too strict, “the terms” and nothing else
> o   Section 2 / 1:
> MS note: the wording implies a specific view on how the URI for the vocabulary and URIs for the terms are associated – but e.g. W3C SKOS has a much wider view on that and I recommend aligning to it:
> Proposed changes:
> The Namespace URI for  identifying the ODRL Version 2.0 Common Vocabulary is defined as:
> (MS note: SKOS has no namespace for vocabularies, only an identifier)
> This Namespace URI must be used in all encodings of ODRL policies to refer to the ODRL Common Vocabulary terms.
> (MS note: this URI identifies the vocabulary – and nothing else.)
> The Namespace URI uniquely identifies the ODRL Common Vocabulary term by appending the identifier of that term.
> change to à A URI identifying an ODRL Common Vocabulary term is created by appending the identifier of that term to the URI of the vocabulary.
> (MS note: the current wording is confusing as it says the namespace URI is identifying by appending … but this makes a different URI!)
> o   Section 2 / 2:
> In some cases the vocabulary term may have two (or more) identifiers in which case they are considered semantically equivalent (ie synonyms).
> MS note: sorry, I can’t get the message of this sentence: a term of the ODRL vocab has its ODRL identifier, if there is an identifier for the same Thing from another vocabulary then this is a sameAs or skos:exactMatch relationship between the two terms/concepts/Things but this not define synonyms.
> ·         XML Encoding
> o   Section 2:
> QCodes are similar to QNames but also allow numeric values a digit as the first characters of the value.
> o   Section 3 / 1:
> “The mandatory Policy element contains …” vs “uid – a URI/Qname/Qcode (required)”
> MS note: if we want to express the XML Schema cardinality (1) then we should use either mandatory or required but not both in a mixed way.
> o   Section 3 / 2:
> MS note: we should state that the default cardinality is “optional” (is currently the cardinality of elements and attributes without “required” is unclear)
> o   Section 3 / 3:
> Note that under the ODRL context rules (see ODRL Model [ODRL-MODEL] <https://www.w3.org/community/odrl/work/2-0-xml-encoding-constraint-draft-changes/#section-References>) there MUST be at least one Permission in the complete ODRL Policy, for example, taking into account any Profile and Inheritance requirements.
> MS note: it should not be optional to take into account Profile and Inheritance.
> o   Section 3 / 4:
> The cardinality of the Asset element attributes MUST be either:
> MS note: this statement and lines of attribute names with required or optional does not give clear guidance: why are there multiple lines with different sets of attributes and each attribute has its own cardinality.
> Proposed change: 
> Asset element attributes MUST be used as defined by one of the sets of attributes and their cardinalities below:
> ·         JSON Encoding:
> o   MS note: I propose it should adopt numbered sections like the other spec docs
> o   Re Approach 1:
> with the XML encoding which has a Party element and with a Role attribute.
> o   Re Approach 2:
> MS note: I propose to copy the paragraph “All of the URIs used in ODRL XML instances MUST follow …” from the XML Encoding document, section 2, into the JSON Encoding specs.
> ·         All docs: the copyright year should be set to 2015 (some are, some not …)
> ·         All docs: from the previous posting I assume that you, Renato, will take care of updating release/publishing date
>  
>  
> Depending on feedback from the community I would edit the proposed changes.
>  
> Best,
> Michael
>  
> Michael Steidl
> Managing Director of the IPTC [mdirector@iptc.org <mailto:mdirector@iptc.org>]
> International Press Telecommunications Council 
> Web: www.iptc.org <http://www.iptc.org/> - on Twitter @IPTC <http://www.twitter.com/IPTC>
> Business office address:
> 25 Southampton Buildings, London WC2A 1AL, United Kingdom
> Registered in England, company no 101096
>  
> 
> 
> 
> -- 
> Víctor Rodríguez-Doncel
> D3205 - Ontology Engineering Group (OEG)
> Departamento de Inteligencia Artificial
> ETS de Ingenieros Informáticos
> Universidad Politécnica de Madrid
>  
> Campus de Montegancedo s/n
> Boadilla del Monte-28660 Madrid, Spain
> Tel. (+34) 91336 3753
> Skype: vroddon3
> 
> 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, 24 February 2015 18:58:53 UTC