ODRL 2.1 specs - terminology issues

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
<https://www.w3.org/community/odrl/work/2-0-common-vocabulary-constraint-dra
ft-changes/#section-References> [ODRL-MODEL] 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
<https://www.w3.org/community/odrl/work/2-0-xml-encoding-constraint-draft-ch
anges/#section-References> [ODRL-MODEL]) 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]

International Press Telecommunications Council 
Web:  <http://www.iptc.org/> www.iptc.org - on Twitter
<http://www.twitter.com/IPTC> @IPTC

Business office address: 

25 Southampton Buildings, London WC2A 1AL, United Kingdom

Registered in England, company no 101096