Fwd: Problems removing hasDimension and hasMetric as abstract properties

Forwarding to the list some e-mails which  are related  to issue-204 and
issue-205.
Cheers,
Riccardo

[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 <
albertoni@ge.imati.cnr.it>
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.

Cheers,
Jeremy



--
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
Magenes"
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
http://purl.oclc.org/NET/riccardoAlbertoni
FOAF:http://purl.oclc.org/NET/RiccardoAlbertoni/foaf