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



Hi Jeremy,
sorry for my late reply but the last two weeks I was completely overwhelmed
 by other stuff.

I agree with Antoine,  it seems  that we don’t have this kind of problems
 if we move  from “abstract classes” to  the  SKOS modelling pattern, as
 we are discussing in Issue  204 and 205.

Let me  complement the Antoine’s reply showing how your example looks like
if we move to skos ..

# New modelling in DQV /DAQ
dqv:Category   rdfs:subclass  skos:Concept
dqv:Dimension  rdfs:subclass  skos:Concept .
dqv:hasCategory rdfs:subPropertyOf  skos:broader .

#some dimensions and categories from ZAVERI et al.
ex:accessibility a  dqv:Category.
ex:intrinsic a  dqv:Category .

ex:availability a  dqv:Dimension ;
 dqv:hasCategory ex:accessibility ;
# you have a standard set of skos properties to annotate dimension and
categories..
skos:prefLabel “Data Availability”@en;
skos:altLabel    “Availability”@en;
skos:definition “Availability of a dataset is the extent to which data ( or
some portion of it) is present, obtainable and ready for use.”@en.

ex:consistency a  dqv:Dimension ;
    dqv:hasCategory ex:intrisic
 .......
  .

#we can still state sub type relation between dimension and category, for
example, supposing the inverse-property consistency is considered as a
subdimensions of   consistency,  we can state

ex:inversePropertyConsistency a  dqv:Dimension ;
skos:broader ex:consistency;
skos:prefLabel “Inverse Property Consistency”@en;


#we can  state relations  among dimensions from different quality
frameworks ( using standard  matching relation as skos:closeMatch,
skos:closeMatch, skos:exactMatch,  skos:narrowerMatch), for example, if  we
have that “consistency”, the dimension in the  ISO, is  known to be
equivalent to the “consistency” defined by zaveri, we can state

iso:consistency skos:exactMatch ex:consistency.

#and then the part related to metric

ex:endPointAvailablity a dqv:Metric .
ex:ontologyHijacking a dqv:Metric .

ex:ontologyHijacking  dqv:hasDimension  ex:consistency
ex:endPointAvailablity dqv:hasDimension ex:availability


Let me try to list some of the advantages  this modelling pattern seems to
exhibit :
- We are still using  forcing a kind of structure for dimensions and
categories, so that,  dimensions and categories from different quality
frameworks can be lately reconciled: they are skos:Concepts grouped in
dqv:Dimension dqv:Category;
- No need of  abstract classes / properties. No need for
 Dimension/Category subclasses. You can still use subclasses for Dimension
and Category if you want  but you don’t have necessary to do it. Thus when
you have to insert a new dimension or category you can just add it as an
new instance;
- Quite rich set of matching relations to say, this dimension is equivalent
to/a sub dimension  of   the one adopted by another system;
- Quite rich set of relation to express definitions, alternative and
preferred labels, editorial notes , history note about the considered
dimension and categories.

Besides, from the modelling point of view, there are other adjustments we
might consider:
-we might want to declare   dqv:Category dqv:Dimension, dqv:Metric disjoint.
-we are still discussing whether or not dqv:Metric  should be a
skos:Concept,   in that case, we will add the statement, dqv:hasDimension
 rdfs:subPropertyOf skos:broader .

What do you think?
Is there  any specific scenario DAQ needs to address  which is not
addressable with the aforementioned SKOS modeling?


 Cheers,
Riccardo



-- 
----------------------------------------------------------------------------
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