Re: [poe] Role of the ODRL Common Vocabulary

A. Re @riannella  above: yes and no ;-)
1. My understanding: "normative" means a definition by the ODRL Recommendation and ODRL-compliant processors must be able to process that. (Validator, Evaluator, Test Cases)
2. Currently there is only one **normative** statement about a Profile of a Policy. It is the definition of the profile property of the [Policy Class](https://w3c.github.io/poe/model/#policy) ...
3. ... while section 4. of the IM about the [Profile Class](https://w3c.github.io/poe/model/#profile) is already **non-normative**. If writes down what a Profile may define but it can't define what role things defined by a Profile have is this section is non-normative.
4. Some normative parts of the IM (version of 7 July) have semi-normative statements about Profiles, e.g. in the Policy Class section: " ... The Policy subclasses should be documented in the ODRL Common Vocabulary [odrl-vocab] or in **ODRL Profiles**. " Similar statements are in sections about the related property, function property, the Action Class, the (Compound) Constraint, Asset Constraint, Policy Conflict Strategy, 
5. From that I conclude: _for all those subclasses, sub-properties or instances of a class with such a statement including Profiles in the IM any corresponding subclass, sub-property or instance of a class defined by a Profile has to be processed in the same way as it is defined in the normative part of the IM._
Such a statement should be made in the normative part of the IM - maybe best having a short normative region at the top of the ODRL Profile section, then switching to non-normative.
6. re Turtle/schema: I see no mandatory need to define subclasses, sub-properties or instances of a class of a Profile in an RDF schema. I recall from WG calls: that all these IM things are also in the Core Vocabulary is only for a better support of RDF processors but not a mandatory need for the ODRL IM Recommendation. In this sense a Profile schema in Turtle could help too. (Maybe I'm wrong with this recollection, then I suggest to clarify the IM-Vocabulary relationship.)

B. Back to the issue of Common Vocabulary vs Core Vocabulary, shown in e.g. 
>  The Policy subclasses should be documented in the ODRL Common Vocabulary [odrl-vocab] or in ODRL Profiles.
1. the Policy subclasses Set, Offer and Agreement are not defined in the Common Vocabulary nor in a Profile, they are defined in the [ODRL Core Vocabulary](http://w3c.github.io/poe/vocab/#vocab-core). Therefore this statement is **unclear or wrong**.
2. Therefore the IM should make a correct split between Core Vocabulary, Common Vocabulary and Profiles in all similar statements.
3. The wording above leaves it open if it is sufficient to have the definition of an e.g. Action instance in the Common Vocabulary only but not in a Profile which makes ODRL ambiguous (see item 4 below). 
I suggest to rephrase this to such a template: "**The ..... are either documented in the ODRL Core Vocabulary or should be documented in ODRL Profiles which could adopt ... from the ODRL Common Vocabulary.**" (... stands for the thing which may be subclassed etc.)
4. A key reason for this suggestion: the initial wording above does not make any difference between the Core Vocabulary and the Common Vocabulary. If only the sheer existence of a thing in the Common Vocabulary is sufficient for a use in a Policy regardless of any (applied) Profile this thing would have the same role as a thing defined by the normative Core Vocabulary. And this makes the split into Core and Common Vocabulary irrelevant.
5. Then: the definition of the term Common Vocabulary in [1.3 Terminology ](https://w3c.github.io/poe/model/#terminology) should be modified (even if this section is non-normative): "A set of generic terms that may be used **by an ODRL Profile** with the ODRL core vocabulary to express Policies."
6. ... and the Terminology needs a new entry for the Core Vocabulary, e.g. "A set of terms defined by the normative ODRL Information Model."


-- 
GitHub Notification of comment by nitmws
Please view or discuss this issue at https://github.com/w3c/poe/issues/210#issuecomment-314361091 using your GitHub account

Received on Tuesday, 11 July 2017 07:38:34 UTC