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: Antoine Isaac <aisaac@few.vu.nl>
Date: 6 November 2015 at 15:41
Subject: Re: Problems removing hasDimension and hasMetric as abstract
properties
To: "Debattista, Jeremy" <Jeremy.Debattista@iais.fraunhofer.de>, Riccardo
Albertoni <albertoni@ge.imati.cnr.it>
Cc: Christoph LANGE <math.semantic.web@gmail.com>


Hi Jeremy,

I'm going to try to answer your earlier email that Riccardo forwarded to
the list. In the meantime, I thought I could try to first send a quick
answer to your newer email. It may be useful to make sure we agree on our
respective assumptions and proposals ;-)

My reaction would be on two points, largely disconnected though (as
following my second suggestion would make the first remark obsolete)

1. I agree that having dqv:hasDimension having, e.g., a range of
ex:Consistency is not useful. But what does in your subclass statements (or
in any other kind of RDF statements made for describing these metrics and
dimensions) lead to infering such a range?

2. The interesting point of the suggestion to use SKOS for Category
(modified as per may mail [1]) is that there's no need for sub-classing in
order to introduce types of Categories and Dimensions. Everything is done
by creating *instances* of these two classes (and using
skos:broader/narrower for "refining" these instances later).
Sthg like:
[
ex:availability a dqv:Dimension .
ex:consistency a dqv:Dimension .
]

This implies that there wouldn't be any question about unwanted side-effect
domain and range axioms for properties, no question about punning and other
OWL difficulties. Also, it avoid theoretical debates about whether e.g.,
(your) ex:Consistency a class and not an instance, and what the status
would be for possible specializations of this Dimension (i.e. if one would
like to create dimensions like ex:languageConsistency or
ex:StatisticalConsistency - that's allowed in daQ, isn't it?).

Cheers,

Antoine

[1] http://lists.w3.org/Archives/Public/public-dwbp-wg/2015Oct/0061.html


On 11/4/15 12:33 PM, Debattista, Jeremy wrote:

> 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