ISSUE-204: Introducing abstract classes and properties
Introducing abstract classes and properties
- State:
- CLOSED
- Product:
- Quality & Granularity Vocabulary
- Raised by:
- Antoine Isaac
- Opened on:
- 2015-10-19
- Description:
- Is there any reason for turning the classes dqv:Dimension, dqv:Metric and dqv:Category as well as the properties dqv:hasDimension and dqv:hasCategory into "abstract" classes and properties as they were defined in daQ [1] ?
[1] http://butterbur04.iai.uni-bonn.de/ontologies/daq/daq , section "Extending the daQ". - Related Actions Items:
ACTION-261 on Antoine Isaac to Add a note to the effect of the decision about using shacl rather than abstract and sub classes. - due 2016-03-21, closed- Related emails:
- Re: Problems removing hasDimension and hasMetric as abstract properties (from Jeremy.Debattista@iais.fraunhofer.de on 2016-01-29)
- Re: Problems removing hasDimension and hasMetric as abstract properties (from albertoni@ge.imati.cnr.it on 2016-01-28)
- Fwd: Problems removing hasDimension and hasMetric as abstract properties (from albertoni@ge.imati.cnr.it on 2015-11-27)
- Fwd: Problems removing hasDimension and hasMetric as abstract properties (from albertoni@ge.imati.cnr.it on 2015-11-27)
- Fwd: Problems removing hasDimension and hasMetric as abstract properties (from albertoni@ge.imati.cnr.it on 2015-11-27)
- Fwd: Problems removing hasDimension and hasMetric as abstract properties (from albertoni@ge.imati.cnr.it on 2015-11-27)
- Fwd: Two new open issues closely related to design choices in DAQ (from albertoni@ge.imati.cnr.it on 2015-10-30)
- dwbp-ISSUE-204: Introducing abstract classes and properties [Quality & Granularity Vocabulary] (from sysbot+tracker@w3.org on 2015-10-19)
Related notes:
Resolved [https://www.w3.org/2016/03/14-dwbp-minutes]
[
We acknowledge the abstractness of dqv:Dimension and dqv:Category. We believe that defining them as classes is not optimal in terms of complexity of representation and interoperability. Looking at daQ we also think there is no fundamental feature of daQ that it lost in DQV if we represent instances dqv:Dimension and dqv:Category as skos:Concepts (as suggested for Issue-205), which is a way to express that they are abstract entities.
Matters are different for metrics. daQ uses classes and subclasses to represent constraints on specific measurement (e.g. type of values). However, this is rather a modeling “trick” (and a requirements for having subclasses of daq:Metric) rather than a real requirement for abstract classes. We also have doubts that with the (open world) RDFS/OWL semantics of classes, these axioms can really enforce constraints on metrics and measurements. With new languages being currently defined to properly represent constraints (SHACL) we think it is more appropriate not to recommend anything now about treating metrics as subclasses of dqv:Metric, and thus to postpone discussion on this part of the issue. We could add an editor’s note about this (daQ subclass trick, and SHACL for constraints), referring implementers to future progress on SHACL and related technology.
ACTION-261 - Add a note to the effect of the decision about using shacl rather than abstract and sub classes.
]
Display change log
