Re: New dqv:inDimension

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

Received on Tuesday, 22 March 2016 17:47:13 UTC