Fwd: New dqv:inDimension

Forwarding Antoine's email to the mailing list, so that we have this mail
related to action https://www.w3.org/2013/dwbp/track/actions/258
Cheers, Riccardo

 ---------- Forwarded message ----------
From: Antoine Isaac <aisaac@few.vu.nl>
Date: 22 March 2016 at 18:46
Subject: Re: New dqv:inDimension
To: public-dwbp-wg@w3.org


Hi Jeremy, all,

I have to say that I don't understand where the discussion has gone. We
suggest to remove the domain of dqv:inDimension, which was set to
dqv:Metric. This says that dqv:inDimension can be applied to any resource
without forcing that resource to be a dqv:Metric.

The main value is to enable a classification of any quality information
(not just metrics) against a same dimension space. We believe this is
really useful. For example there can be a quality certificate that is
mostly about the 'accessibility' dimension.
This would be hindered if the domain dqv:inDimension is retricted to
dqv:Metric. This would imply that e.g. a QualityCertificate will be
classified as a Metric if we apply dqv:inDimension to it. And Certificates
are not Metrics. To void this we would have to create in DQV other 'clones'
of dqv:inDimension with other domains, which is really bad ontological
design.

Again, our point is really to allow to apply dqv:inDimension to things that
are not Metrics. From this perspective, removing the domain seems the most
natural thing to do.

There is the risk of being able to apply dqv:inDimension to thing that are
less relevant to quality, like foaf:Profile, indeed. There is a risk here,
but honestly I don't think it's important. Plus, the current open-world
semantics of rdfs:domain actually doesn't prevent applying inDimension to
foaf:Profile, even if we keep the domain. And who knows, some instances of
types of resource that we thought were irrelevant for quality may end up
being good for quality classification.

So the question is: does this choice prevent you to make relevant things?
I fail to understand what we miss if we remove the domain. You mention the
ability to constrain the cardinality of dqv:inDimension on certain
resources. This is a valid requirement, but the presence or absence of
domain doesn't influence anything here.

Considering your example, i.e. you want to say that a metric exists in one
and only one dimension.
This is done by creating a new subclass of dqv:Metric with the axioms
[
ex:MetricInOnlyOneDimension rdfs:subClassOf dqv:Metric ;
   rdfs:subClassOf [ rdf:type  owl:Restriction ;
      owl:maxCardinality  "1"^^xsd:nonNegativeInteger ;
      owl:onProperty dqv:inDimension
    ] .
]
What's the impact of removing the domain of dqv:inDimension on these axioms?

Cheers,

Antoine


On 3/22/16 5:57 AM, Debattista, Jeremy wrote:

> Hi Riccardo,
>
> In fact,  as a consequence of the inDimension domain removal, the foaf
>> profile you have mentioned  is not  becoming a metric,  If someone wants
>> it  as a  metric,  she/he must instantiate  it as dqv:Metric ..
>>
>
> In your reply, you implied that the inDimension property will still have
> the dqv:Metric concept as its domain.
>
> If you are using inDimension alone you are basically saying "I have
>> something which might be connected to a quality dimension",  that's it ..
>>
>
> That is pretty big assumption which would make the quality metadata
> largely subject to different interpretations. Not sure that quality
> metadata (which should be of high quality) will benefit from that.
>
>
>     I think inDimension domain should be restricted, and future quality
>> stuff, should adhere to that restriction. Otherwise if we allow anyone to
>> do anything in the DQV I’m afraid that we will end up with low quality,
>> quality metadata.
>>
>>
>> It is not that anyone can do anything, when the stuff about quality is of
>> one the foreseen types ( annotations, metrics, quality policies,
>> standards), our  DQV document explains how it should be made fitting  ;)
>>
>
> Theoretically, yes. Anyone can do anything with an open domain. This is
> said with the same reasoning that lightweight vocabularies (like daQ)
> cannot put constraints on for example the fact a metric exists in one and
> only one dimension, even though the document explains it.
>
> Therefore, considering all these points, I vote against having an open
> domain for the inDimension property, and I urge you to really reconsider
> this design.
>
> Cheers,
> Jer
>




-- 
----------------------------------------------------------------------------
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.imati.cnr.it/ <http://www.imati.cnr.it/>*
http://purl.oclc.org/NET/riccardoAlbertoni
FOAF:http://purl.oclc.org/NET/RiccardoAlbertoni/foaf