Role of the ODRL Common Vocabulary and of Profiles

[nitmws]

This issue started in the discussion of #202:
Properties taking the role of a short-cut may be added to a Policy. And Compact Policy of the IM tells, that Rules have to check the policy level for properties which should replicated to the Rule.

This raises the question: how can a receiver of a Policy know what property found at the policy-level is - because there is no earmark like "this is a sub-property of relation" in a policy serialised as JSON or XML.
A suggested approach was: all properties which are relevant for a policy must be defined by either the ODRL Core Vocabulary or by the profile applied to this policy. A note in this discussion added that the search by a Rule for applicable properties should include the properties of the ODRL Common Vocabulary.
By my view this does not fit.

I see this as a general question: what properties and what instances/individuals of a class are defined as "may be applied to an ODRL policy with a specific profile" and which not.
A receiver of such a policy has to expect only defined properties and instances and can adjust an ODRL processor accordingly.

I support the approach outlined above: any used property or instance of an ODRL class must be defined

• by the ODRL Core Vocabulary
  OR
• by a vocabulary of the applied profile
• all other properties and instances can be considered as unknown.

Under this condition the ODRL Common Vocabulary has only the role of an informal suggestion to profile-makers what they can adopt for their specific profile. But using a property defined by the Common Vocabulary without an adoption of it by the applied profile should make this property unknown/invalid.
This requires to change the basic definition of the Common Vocabulary

The ODRL Common Vocabulary defines semantics for generic terms that may be used in ODRL Policies. In addition, ODRL Common Vocabulary terms may be re-used in ODRL Profiles as described in the ODRL Information Model

as it supports the use of Common Vocabulary terms without adoption by a profile.

[riannella]

I assume from this you are saying that the ODRL Common Vocab terms cannot be used "as is" unless they are part of a (formal) ODRL Profile ??

[nitmws]

@riannella right, the definition of all concepts in the Common Vocab should be formally ok but they may not be used unless a) a concept is adopted by a profile and b) this profile is applied to a Policy. (You may consider it like a car tuning parts store: ready to be used, but not in use - must be integrated properly.)

[riannella]

This means then that:

1. Profiles need to be normative (currently non-normative)
   and all ODRL implementations will need to understand the turtle profile (schema)?

[nitmws]

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 ...
3. ... while section 4. of the IM about the Profile Class 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. 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 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."

[riannella]

A):

• In section 4.3: https://w3c.github.io/poe/model/#profile-requirements
  We state that you must understand a Profile (if you use one)
• Do we add something along the lines of "... in the same way as it is defined in the normative part of the IM." ?

B):

• We need to say: the IM is the Core Vocab.
• When we refer to Common Vocab/ Profiles - it is always in respect to additional terms.

[nitmws]

re A)

• Section 4.3 is non-normative, therefore even a must is not really relevant.
• That's why I have suggested to make a part of the Profile section 4 normative. Only in this case a must would be relevant.
• And: what does "understanding a Profile" mean?
  • In the Policy Class section an "ODRL processor" must understand, in section 4 "an ODRL consuming system" must understand - the ODRL newbie will ask: are both the same, and what if not?
  • I prefer to use the term "ODRL Processor" (as it would be great if also an ODRL generating system understands a Profile ;-) ) and a) add it to the Terminology section and b) use a consistent spelling (we have also uppercase Processors).
  • "understanding a Profile": I think this is like "being able interpret all classes, properties and entities as defined by the ODRL Information Model". Either use this longer explanation (my favourite) or define the term "understand" somewhere - Terminology section?

re B)

• I suggest to make the statement the other way round: The Core Vocabulary covers all things defined by the IM.
  This tells: the formal reference is the IM, the Core Vocabulary is its expression by Semantic Web means.
• re "When we refer ...": sorry, I think this condition is only in the head of ODRL-oldies like us :-), ODRL newbies will not interpret the wording in this way and there is no clear statement about that anywhere. I still suggest my wording above.
• E.g. Policy Class and Profiles again: this section starts with "An ODRL Policy may be subclassed ..." and the second sentence is the one quoted above. There is no word that the IM already defines subclasses and that they can be found in the Core Vocabulary.

[riannella]

A) I think we then need a WG decision on this. That is, all ODRL Policies must use a Profile (unless it is just Core).

B) ok

[simonstey]

@nitmws:

And: what does "understanding a Profile" mean?
[..]
"understanding a Profile": I think this is like "being able interpret all classes, properties and entities as defined by the ODRL Information Model (simon: s/Information Model/Profile/ ?)".

while "being able interpret all classes, properties and entities as defined by ..." is slightly less ambiguous than "must understand the Profile", there's still no clear-cut definition of what "being able to interpret" actually means..

It's about conformance, as actually already stated in Section 4.3:

In an ODRL Policy, the profile property is used to indicate the identifier (IRI) of the ODRL Profile for to which the Policy expression (simon: ODRL Policy==Policy expression?) conforms to.

however, for the remainder of the paragraph "conform to" was - for whatever reason - substituted by "understand":

This property is OPTIONAL, but if the property appears, then any ODRL consuming system that supports/implements the given profile MUST understand the identified ODRL Profile. If an ODRL consuming system does not understand the ODRL Profile, then it MAY continue processing the Policy expression, but it SHOULD NOT assume it has interpreted the Policy expression correctly.

1. better: s/understand/conform to/
2. the first sentence needs to be reworked

[nitmws]

re @riannella A) I strongly support such a decision. Because currently there are three options for the things in a Policy: a) only things defined by the IM = Core Vocabulary, b) things defined by the IM/Core Vocabulary and by an associated Profile, c) things defined by the IM/Core Vocabulary and not defined by the IM, coming from somewhere else.
Option c) would be awful for receivers.

re @simonstey

1. Mild reminder: section 4 of the IM is completely "non-normative" - I suggested above to make essential parts of it normative
2. I get your approach. So last sentence of the 1st para of 4.3 should be rewritten to "If an ODRL Processor does not conform also to the ODRL Profile, then it may continue processing the Policy expression, but it should not assume it has interpreted the Policy expression correctly."
   (I've inserted an "also" to make clear it has to conform to the IM and the Profile)

[nitmws]

Note: I've added "and of Profiles" to the issue title as the discussion has also a focus on Profiles now.

[nitmws]

Considering "what makes a processor conforming to a Profile" I had a wider look at the section 4 ODRL Profiles

• a simple issue in ODRL Purpose Profile: to the list of things which can be extended by Profile the instances of Action should be added, I guess they will have a key role in Profiles.
• What is a Profile allowed to define:
  • 4.1 tells: "... An ODRL Profile directly and explicitly serves their communities needs by specifying only the terms they wish to support in ODRL expressions. ...." - this allows also to exclude terms defined by the IM - is that ok?
  • 4.3 tells: "An ODRL Profile extends the ODRL Information Model classes, properties, and instances in the following ways: ..."
  • Conclusion: we need consistence - "extending" seems to be ok, "excluding" is unclear (and at least I'm not supporting it as it will be hard to draw a line between excluding IM parts and spoiling the IM. The only alternative I see is that the IM defines which things may be excluded by a Profile.)
• As said above I suggest to have a normative sub-section in section 4:
  • Head: ODRL Profile Definitions and Conformance
  • Content: (not supporting any "exclusion", see above)
    An ODRL Profile must not overrule the ODRL Information Model.
    An ODRL Profile may extend the ODRL Information Model classes, properties, and instances by defining subclasses, sub-properties and new instances.
    An ODRL Processor may conform to an ODRL Profile, in this case it has to conform to the Information Model and in addition to the definitions of the Profile. If an ODRL Processor does not conform to the ODRL Profile, then it may continue processing the Policy expression, but it should not assume it has interpreted the Policy expression correctly.

[riannella]

Excluding from the IM would be harder. You would then need to have stuff like:
odrl:AssetCollection owl:deprecated true .

So the IM/Core Vocab needs to be supported minimally by all ODRL Processors.

[riannella]

If we make Profiles mandatory, then the wording will have to be stronger than: "... then it may continue processing the Policy expression..."
If the ODRL Processor does not understand a profile ID, then it MUST stop processing.
(otherwise, why is a Profile mandatory?)

This means an ODRL Processor must understand the Profile Mechanism section.

[nitmws]

re IM/Core Vocab and ODRL Processors and Profiles:
Is it agreed by the WG that a Profile claims that a feature of the IM "does not have an active role in this Profile" - e.g. Offer and Duty should not be used by Policies of Profile XYZ?
Even in this case any ODRL Processor must be able to process any IM/Core Vocab term properly. By that I mean if in a Profile XYZ Policy a Duty is used the Processor can give a notice "should not be used with Profile XYZ" but it must not raise "Error: the thing Duty is unknown".
If the WG considers this to be too open to potentially spoiling the IM it is also ok not to support this "making features inactive".
(Ok, I say that with my RightsML Profile hat on my head :-) )

re " ... then it may continue ...": right, I agree this sentence is strange - if a Processor doesn't conform to a Profile why to discuss how it might process the Policy without the Profile, that's an implicit contradiction.
So it would be better to shorten the sentence to "If an ODRL Processor does not conform to the ODRL Profile it should stop processing the Policy."

[riannella]

Note: if agreed, then also need to support multiple profiles for a policy

[nitmws]

Reminder of my main reason form suggesting strict rules regarding the use of Profile(s): it supports the receivers of a Policy to know what terms may be used by it. All used terms must be defined either by the ODRL IM (Core Vocabulary) or by the Profile(s), anything else is not relevant for the evaluation of the Policy. This rule allows the receiver to build an ODRL processor based on definitions/specification and does not require to cover (best) guesses.
Such a "we know what we receive" scenario will widen the acceptance of ODRL because this makes it more reliable.

I suggest this basic WG decision regarding Profile:

• A Policy without a Profile conforms only to the ODRL IM.
• A Policy may define none to many Profiles it conforms to. (Note: it's the responsibility of the creator of a Policy to avoid contradictions by using multiple Profiles.)
• Terms used by a Policy which are not defined by the IM Core Vocabulary or by a related Profile stops the evaluation of the Policy conforming to specifications.
• Note: if considered as useful the Common Vocabulary could be defined as ODRL Profile, in any case the terms of the Common Vocabulary can be adopted by a Profile.

(Footnote: sorry, can't join the WG call on 24 July)

[riannella]

My concern is that we increase the barrier for implementors (producers and consumers) as there will now be additional processing. It makes sense for those that want "reliability" to do that, but I don't think this will be consistent across all ODRL implementations.

I can image large communities/companies only supporting profiles, but that does not mean all ODRL implementors must do that.

A good read is the Web architecture Extensibility:
https://www.w3.org/TR/2004/REC-webarch-20041215/#extensibility
Especially the part under "Two strategies have emerged..."

My proposal is that:

1. if there is a Profile declared, then you MUST understand all vocab terms
2. if no profile, then you interpret the vocab terms "as is"

So, a Profile becomes ODRL's "must understand" strategy

[nitmws]

I agree that the Web Architecture Extensibility provides a good outline for "how to extend a specification".
But in this sense I can't get the value of "interpret the vocab term 'as is'" - what "is" in this case?
How should a party interpret this received Policy (see Example 12 of the IM):

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:1012",
    "permission": [{
            "target": "http://example.com/music:1012",
            "assigner": "http://example.com/org:abc",
            "action": "ziplahuck"
     }]
}

... what "is" the action ziplahuck? It may be a valid identifier but an identifier does not share any semantics. And there is no must for accessing an identifier IRI and getting semantics delivered.
Back to the Web Architecture Extensions: it provides two options for unknown terms

• "must understand" = terms which cannot be understood are treated as an error
• "must ignore" = terms which cannot be understood are ignored = the Policy is processed as if this term does not exist.

Both options require that terms must be understood for a processing conforming to the specification, there is no option "treat a term which cannot be understood like a term which can be understood".
I'm afraid that allowing the use of terms with unknown semantics would undermine the status of ODRL as a standard.

[riannella]

I think this is an implementation issue.

ODRL says that "ziplahuck" is an Action.

An implementation may:
1 - raise an error
2 - it may simply inform the user "you can ziplahick music:1012"
3 - if may dereference ziplahick and find is is owl:sameAs odrl:play

NOTE: We removed the "undefined" property strategy from ODRL #139

[riannella]

Updated the IM and Vocab to make ODRL profiles mandatory.
See commit link above.