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: 26 November 2015 at 10:44
Subject: Re: Problems removing hasDimension and hasMetric as abstract
properties
To: Riccardo Albertoni <albertoni@ge.imati.cnr.it>
Cc: Christoph LANGE <math.semantic.web@gmail.com>, Antoine Isaac <
aisaac@few.vu.nl>


HI Riccardo, Antoine,

Sorry for my late reply. I was also busy with other (more important) stuff.
I think we are not agreeing on how we perceive the concept classes
“Category” - “Dimension” - “Metric”. For me (and in daq), these are
abstract classes as they cannot really represent anything - just a concept
with some attributes. On the other hand, Accessibility is a concrete (as
opposed to abstract) category and not an instance of the more abstract
category, because it might have some (extra) properties which are different
than another category, say Intrinsic. Therefore, this is more a design
choice, which ensures that all future “quality metadata” is structured in
the same way. I usually explain this with the Mammal -> Dog and Human
analogy. Metrics (and the same for dimensions and categories) are similar
to each other (Dog and Human are both Mammals) but in nature different from
each other (I hope :)).  Yes, it is a bit of a pain for curators who want
to add such metadata, but at the end of the day this will all be done
automatically.

In any case, the examples you gave still give a problem when querying and
inferring data as I said in my first email.

I hope this explains my view better.

Cheers,
Jer

> On 24 Nov 2015, at 15:43, Riccardo Albertoni <albertoni@ge.imati.cnr.it>
wrote:
>
>
> 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



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