Fwd: Problems removing hasDimension and hasMetric as abstract properties

Forwarding to the list some e-mails which  are related  to issue-204 and

[issue-204] https://www.w3.org/2013/dwbp/track/issues/204
[issue-205] https://www.w3.org/2013/dwbp/track/issues/205

---------- Forwarded message ----------
From: Debattista, Jeremy <Jeremy.Debattista@iais.fraunhofer.de>
Date: 4 November 2015 at 12:33
Subject: Problems removing hasDimension and hasMetric as abstract properties
To: Antoine Isaac <aisaac@few.vu.nl>, Riccardo Albertoni <
Cc: Christoph LANGE <math.semantic.web@gmail.com>

Hi Riccardo, Antoine (and Christoph on CC as one of the main contributors
of daQ)

I was fixing Luzzu and daQ to remove the hasDimension/hasMetric abstract
properties, but I found a problem which I had overlooked. If we remove it,
then it will be more difficult to assign a metric to a dimension and a
dimension to a category.

Consider this example:

ex:Accessibility rdfs:subClassOf dqv:Category .
ex:Intrinsic rdfs:subClassOf dqv:Category .

ex:Availability rdfs:subClassOf dqv:Dimension .
ex:Consistency rdfs:subClassOf dqv:Dimension .

ex:EndPointAvailablity rdfs:subClassOf dqv:Metric .
ex:OntologyHijacking rdfs:subClassOf dqv:Metric .

If we leave the hasDimension and hasMetric as non-abstract properties and
don’t require anyone to define which metric belongs to which dimension, an
inference engine will give us the following:

dqv:hasDimension rdfs:range ex:Availability, ex:Consistency ;
   rdfs:domain ex:Accessibility, ex:Intrinsic .

dqv:hasMetric rdfs:domain ex:Availability, ex:Consistency ;
   rdfs:range ex:EndPointAvailability, ex:OntologyHijacking .

which I believe is incorrect as it does not make sense to have an instance
_:Accessibility -> _:Consistency -> _:EndPointAvailability ; or _:Intrinsic
-> _:Availability -> _:EndPointAvailability .

In this way, we will end up with a lot of inconsistent metadata - something
that we have to avoid if we are talking about data quality :)

Therefore, whilst I still think that we should not enforce the “a metric is
in exactly 1 dimension and a dimension is in exactly 1 category” - but keep
it as a best practice, we should still keep the abstract properties that
define a correct Category -> Dimension -> Metric, and thus require the
definition. I know this will be an extra effort on behalf of the user, but
it will pay at the end with better quality metadata.

I really would like to hear what you think on this matter.


This message has been scanned by E.F.A. Project and is believed to be clean.

Riccardo Albertoni
Istituto per la Matematica Applicata e Tecnologie Informatiche "Enrico
Consiglio Nazionale delle Ricerche
via de Marini 6 - 16149 GENOVA - ITALIA
tel. +39-010-6475624 - fax +39-010-6475660
e-mail: Riccardo.Albertoni@ge.imati.cnr.it
Skype: callto://riccardoalbertoni/
LinkedIn: http://www.linkedin.com/in/riccardoalbertoni
www: http://www.ge.imati.cnr.it/Albertoni

Received on Friday, 27 November 2015 13:29:32 UTC