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:
Related emails:
  1. Re: Problems removing hasDimension and hasMetric as abstract properties (from Jeremy.Debattista@iais.fraunhofer.de on 2016-01-29)
  2. Re: Problems removing hasDimension and hasMetric as abstract properties (from albertoni@ge.imati.cnr.it on 2016-01-28)
  3. Fwd: Problems removing hasDimension and hasMetric as abstract properties (from albertoni@ge.imati.cnr.it on 2015-11-27)
  4. Fwd: Problems removing hasDimension and hasMetric as abstract properties (from albertoni@ge.imati.cnr.it on 2015-11-27)
  5. Fwd: Problems removing hasDimension and hasMetric as abstract properties (from albertoni@ge.imati.cnr.it on 2015-11-27)
  6. Fwd: Problems removing hasDimension and hasMetric as abstract properties (from albertoni@ge.imati.cnr.it on 2015-11-27)
  7. Fwd: Two new open issues closely related to design choices in DAQ (from albertoni@ge.imati.cnr.it on 2015-10-30)
  8. 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.
]

Antoine Isaac, 16 Mar 2016, 13:15:38

Display change log ATOM feed


Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 204.html,v 1.1 2017/02/13 15:26:30 ted Exp $