Fwd: Two new open issues closely related to design choices in DAQ

Forwarding  to the list   a discussion  which  has taken place behind the
scenes.

Riccardo

---------- Forwarded message ----------
From: Debattista, Jeremy <Jeremy.Debattista@iais.fraunhofer.de>
Date: 29 October 2015 at 11:55
Subject: Re: Two new open issues closely related to design choices in DAQ
To: Riccardo Albertoni <albertoni@ge.imati.cnr.it>
Cc: Antoine Isaac <aisaac@few.vu.nl>


Hi Riccardo, Antoine,


During our last call,  we have opened two issues which are  closely related
to the  design choices of DAQ.

The first issue is issue-204,  https://www.w3.org/2013/dwbp/track/issues/204 ,
 which  is about the use of abstract  classes and properties.


Since it was decided against specifically having one metric in only one
dimension and one dimension in only one category, we can do without
abstract properties. The abstract properties were there for that sole
reason.

In DAQ, the classes daq:Dimension, daq:Metric and daq:Category as well as
some of their properties are declared "abstract". However, reasoning on
some simple examples, this does not seem  necessary for DQV.
Thus, we have  simplified the definition of new metric/dimension/categories
by not forcing the use of extra  subclasses for the Metric, Category, and
Dimension.

In your opinion,  are we overlooking any significative Use Case by leaving
"abstract classes" out ?


The idea behind having abstract classes was to ensure that all data quality
users abide by the Category-Dimension-Metric pattern. Once everyone is
given the liberty to define quality metrics in his/her own way, then the
interoperability between different quality metadata will be jeopardised. I
know that it makes life a bit more difficult (well actually it is just an
extra triple ;)), but imo we must make sure that the quality metadata
structure looks the same. One reason is that imagine we need to have some
portal ranking and filtering based on quality aspects - how will this work
if different quality metadata follow different structures?  In my opinion,
forcing the use of extra subclasses will pay off in the end. In daQ we
follow the Architectural Design Pattern [1], therefore trying to constrain
how an ontology (in our case some ontology with data quality concepts) look
like.

Also, if we look at it from a theoretical POV, a metric is a generic
concept whilst for example “Valid usage of Inverse Functional Property” is
a more concrete metric with a well defined objective. To explain this
further, I usually give this example: Consider the concept “Mammal” - a
“Mammal” has some properties, but is also a generic concept as further down
in the hierarchy there are concepts with a more specific kind of mammal,
example “Person” or “Dog”.

I hope this clears up a bit the importance of having abstract classes, but
we can discuss this further.

The second Issue-205:  https://www.w3.org/2013/dwbp/track/issues/205 is
about
 representing dimensions and categories as instances of skos:Concept.
 This would allow publishers of quality framework to express (hierarchical)
relations between dimensions or categories. This could also enable to align
with quality-focused categorizations less focused on metrics. Including the
DWBP Best Practices dimensions, or even the parts of DQV about annotations.

Could you check the draft proposal described  in
https://lists.w3.org/Archives/Public/public-dwbp-wg/2015Oct/0060.html


daQ and DQV are both structured in a way to express hierarchical
relationships category -> dimension -> metric. I did not understand
“quality-focused categorisation” though - can you explain what you had in
mind further please?
On the other hand, I am no expert in SKOS - actually I am not very familiar
with it or with its semantics, therefore I cannot comment on the pros and
cons of having concepts as subclasses of skos:Concept. I will try to go
through the documentation and then I would be able to comment further on
that :)

I hope these replies help. Please let me know if I can help in any other
way.

Also, I know I had to update the daQ but did not have time yet. Rest
assured that the things we discussed during our last call will be reflected
in the ontology.

Cheers,
Jeremy


[1] http://ontologydesignpatterns.org/wiki/Category:ArchitecturalOP


-- 
This message has been scanned for viruses and dangerous content by
*E.F.A. Project* <http://www.efa-project.org>, 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