Feedback from Victor 6 July 2013

From ODRL Initiative
Jump to: navigation, search

1. Purpose

ODRL2.0 is specified with a Core Model and a Common Vocabulary.

This document discusses some design issues on the Draft ontology version of ODRL2.0. Other encodings exist for JSON (Draft) and XML (Specification).

2. Design Issues List

1. Lack of reuse / mappings to other vocabularies

Comment. The [Draft] ontology does not reuse existing terms and it is hardly connected with other vocabularies. Based on the guidelines for developing and publishing Linke Data [1], the new vocabulary should reuse as many terms as possible from those existing in the vocabularies already published. As a second step, mappings should be made.

We believe that the lack of connectivity with other pieces of the Linked Data is a critical drawback today: it will hinder the ODRL OWL spread, making the ontology possibly isolated and unused. The ontology should not merely describe the model but match the elements already present in other vocabularies who have gained spread.

Recommended action [ upm ]: Reuse existing terms. Match (subclassing, same as, etc.) the classes and properties to existing elements in other famous vocabularies. [this is a work that cannot be dispatched in a single comment]

[ RI ] Which vocabs should we reuse? Are there existing action terms available in other ontologies? We could continue as is, and latter, when we do more extensive mappings, we can add equivalence statements to other ontologies?

Further recommendations [UKL]: Additionally it could be useful to align the ontology to a foundation ontology. A foundation ontology, e.g. DOLCE [2] or DOLCE Ultra Light [3], provides a collection of upper level concepts, which other ontologies can use as a common basis. This improves the interoperability with other ontologies based on the same foundation ontology. This approach could be undertaken in addition to the improvement of the connectivity with Linked Data.

Comment: [MM]: Patches are more than welcome. However, I would caution against adopting a 'foundation ontology' wholesale (primarily because none has gained significant traction to date). Rather, I'd recommend matching against specific terms which are in widespread use.

2. Namespaces and scope of the files

In the week of June, 24th, we thought this was an important issue. After the discussion in the list, it has become more clear that a united namespace has to be defined for the JSON/OWL/XML serialization whenever is possible.

Comment: [Draft] proposes two separate files (core, vocab), as it was done in [Barcelona], while [Koblenz] uses up to 5 different namespaces. The scope is not complete, though. Having two files reflects the two namespaces defined in [model][vocab]. However, the current specification misses the Informative Section 5 in [model]. Also, some elements defined in the “model” are expressed as “vocab”. For example, “assignee” is defined in [Draft] to belong to the “vocab” namespace, while it is defined in “model” and not even mentioned in the [vocab] document.

Proposed action[ upm ]: Include elements from Section 5 in the same [model] namespace, properly annotated. Move terms to their correct namespace.

Comment [UKL]: Multiple namespaces would make ODRL more modular, e.g. it would be possible to use the Core Model with a custom vocabulary instead of the Common Vocabulary. Furthermore it is easier to avoid conflicts with multiple namespaces instead of one large namespaces with all elements inside. Other ontologies also use different namespaces to be modular, e.g. KAoS [4].

Comment [MM]: It's RDF, it's modular by default, regardless of whether it uses one namespace or two.

Comment [MM]: I've put forward a proposal which looks like it might strike a balance in the right way for everyone.

3. uid as the instance URI

Comment: Having “uid” as the instance URI is the intuitive meaning of an instance URI. [Draft, Koblenz]. Alternatively, it might have been a datatype property, respecting the “uid” term of ODRL. We believe the current state of the affairs is satisfactory as it simplifies the model, but it should be documented in the ontology.

Proposed action [ upm ]: Document that “uids” are understood to be the URI of the instances.

Comment/Question [UKL]: We support this recommendation. We noticed that permissions and prohibitions don’t have a uid in the current Core Model. Should a uid be added to these elements?

4. Relation as an object property

Comment. The logical meaning of “Relation” is equal to that of an object property, although the standard defines them as association classes. As we read in [model] “The Relation entity is an association class and can be used to link to an Asset from either Permission , Duty or Prohibition”. Having Relation as an object property looks a sound option, being the different values for its attribute “relation” (currently target and output) modeled as having subproperties of Relation. The Relation in [Draft] is an object property and it has two subproperties: target (where the action takes place) and output (newly Asset produced after the Action has been executed). The objectProperty name “hasAsset” used in [Koblenz] is more clear perhaps but abandons the ODRL specification terminology. However, the extended relations in Section 5.1 in [model] have not been included (AND,OR,XOR).

Proposed action [ upm ]: Stay with Relation as object property. Include the extended relations of Section 5.1 We also refer to the W3C Note Defining N-ary Relations on the Semantic Web

5. Asset as superclass of Policy / Asset not superclass of Policy. Asset same as Thing.

Comment: All the policies are certainly assets, although perhaps it is not needed that much to stress that all the policies are assets (they are not disjoint classes, either) Policy can be sublclass of Asset. But please note that by making Asset same as Thing, we say that all the assets are things –what is fine–, and that all the things are assets, what may be considered wrong: Asset is defined as “Content that is subject to an ODRL policy”. Not all the assets are subject to ODRL policies.

Proposed action [ upm ]: We strongly recommend not making Asset the same as Thing.

Proposed action [UKL]: We recommend that Asset should be equal to Thing, to cover as much concepts as possible, e.g. also abstract ideas. If Asset isn't the same as Thing, the possible uses-cases of ODRL are restricted.

6. Duty / Permission / Prohibition as subclasses of Rule

Comment: It is defined so by the specification [model]. Please see Section 5.2. [Draft] does not declare this superclass. A Rule superclass of Duty/Permission/Prohibition should be declared. Note that [Koblenz] also models this Rule class.

Proposed action [ upm ]: Create a Rule superclass.

[ RI ] Rule was only discussed in a non-normative section. However, if it does no harm in the ontology, then including it might useful.

Comment [UKL]: We support Rule as a superclass, because it simplifies the ontology.

Comment [MM]: I've implemented the superclass

7. Handling of conflicts (valid also for handling undefined, etc.)

Comment: Conflict is defined as an attribute of Policy, which can take one of three pre-defined values. While [Draft] defines a class for these three elements, [Koblenz] makes use of oneOf intelligently avoiding the use of an artificial class. However, this oneOf permits choosing among three strings, while ODRL2.0 specifies that URIs should be preserved.

Proposed action [ upm ]. We recommend not declaring an artificial class to contain these three elements, but declaring them as individuals with the correct URI.

Comment [UKL]: It is not entirely clear, if it should be possible to add more values in the future or if the current values cover all possible scenarios. If the current values are sufficient it is acceptable to use oneOf to avoid an artificial class. We think it is important to discuss what the requirements for modeling the conflict attribute are.

Comment [MM]: I can't see a downside to using the abstract class, here; happy to be steered if there is a good reason not to use one. Certainly, backwards-compatible extensibility was a concern.

8. Definition of Constraint

Comment: In [Draft], Constraint is both defined in model and vocab.

Proposed action [ upm ]: We recommend defining Constraint only in the model, as declared in 2.8 in model

Comment [MM]: it's actually not defined in both the model and the vocab (although there is a dangling reference from m:constraint’s range which currently should have an object of v:Constraint but erroneously points to m:Constraint which does not exist. I agree, however, that it should exist in one place or the other, and do so consistently, but not do both.

9. Direct import of SKOS

Comment: In [Draft], SKOS is directly imported. skos:definition is used only once in [Draft], in the vocab.rdf. Besides this, SKOS is only used in three occasions with skos:scopeNote. It is arguable that SKOS should be imported, their URIs might be directly used. Alternatively, SKOS might be avoided at all.

Recommended action [ upm ]: Remove skos completely, use rdfs:comment instead.

I've removed the owl:imports of SKOS in both documents -- Mo McRoberts 08:34, 19 July 2013 (UTC)

10. Example of Figure 3.1

Comment. Example of [Draft] for Figure 3.1 relates an Asset and a Policy with a dcterms:license element, omitting the ODRL term for this: a relation “target”. Easy reading, but not ODRL. Alternatively, “target” might be made a subproperty of dct:license (what might be discussed, too).

Recommended action [ upm ]: Use the object property target instead of an alien property.

11. Actions as classes or actions as individuals.

Comment. Actions in the [vocab] are represented as individuals in [Draft], while they are represented as subclasses in [Koblenz]. The first approach prevents from future extensions, but the second approach needs from instances not always meaningful. In order to reflect the ODRL specification, a “name” property should exist, but it can be assumed to be its URI.

Recommended action [ upm ]: Further dicuss this policy, as it is a critical piece. If they are to remain class instances, additionally include the name as a datatype property.

Comment [UKL]: We think the requirements for modeling actions should be discussed. The use of classes and subclasses could enhance the semantic, if there is a connection between certain actions. Given that it is desired to express such connections.

Comment [MM]: modelling them as Concepts may be the best choice here: they're individuals, but convey the potentially hierarchical nature of them

12. Relation / Role as top object properties

Comment. Relation is defined in [Draft] as an object property, parent of target and output. This is equivalent to the Role, logically parent of function. While “Relation” is defined, Role it is not.

Recommended action [ upm ]: Check consistency and either supress relation, or include Role as a super property of “Function”.

Recommended action [UKL]: Role and Relation should be modelled as association classes, because they have attributes, which cannot be expressed with properties. Furthermore Role and Relation express roles for Policys and Assets, e.g. an Asset is in the role “target”. We think this semantic is best expressed with an association class. A common superclass for Role and Relation should be considered.

Comment [MM]: What attributes, other than the 'relation' and 'function' (which have the effect of subclassing)? The use of association classes instead of object properties significantly complicates the expression and processing of ODRL policies without any clear benefit.

3. References

[1] Heath, T., Bizer, C.: Linked data: Evolving the Web into a global data space (1st edition). Morgan & Claypool (2011)

[2] DOLCE : a Descriptive Ontology for Linguistic and Cognitive Engineering

[3] DOLCE+DnS Ultralite

[4] KAoS

The reference for making the mapping is the ODRL specification given in April 2012:

- [model] ODRL Version 2.0 Core Model
- [vocab] ODRL Version 2.0 Common Vocabulary -

- [Draft] The draft version.

- [Koblenz] The version made in the framework of ROX at the University of Koblenz-Landau.

- [Barcelona] The version of ODRL1.1, at Universitat Politècnica de Catalunya.

UPM: Víctor Rodríguez-Doncel, Mari Carmen Suárez-Figueroa, Nandana Mihindukulasooriya. Ontology Engineering Group - Universidad Politécnica de Madrid

UKL: Universität Koblenz-Landau

MM: Mo McRoberts