Re: New dqv:inDimension

Hi Antoine,

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

This is a fair point, but then IIRC you could use owl unionOf, to make the inDimension flexible, yet focused on quality aspects … especially if we have a set of classes that we see fit in the quality metadata

dqv:inDimension rdfs:domain  [  a  owl:Class ;
                            owl:unionOf  ( dqv:Metric  dqv:QualityCertificate ... )
] ;

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

I think that it is important. I think it will be useless to have quality metadata which is of poor quality because of irrelevant information. My point is that the meta model should be focused.

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

It does not prevent you to make relevant things, but neither does it prevents someone to make irrelevant things - and the latter is the problem I find. As I said, I’m afraid that at the end we might run in the risk of producing quality metadata, which in itself is of poor quality. At the moment I still cannot find any motivating use case where the DQV (and subsequent metadata) would benefit with having an open domain for inDimension (or any other property)

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

From my understanding of ontologies, that would be perfectly good as the domain of inDimension (if the domain is restricted) with a dqv:Metric restriction, as the example metric is a subclass of dqv:Metric.

I would really like to hear what others think about this issue.

Cheers,
Jer

Received on Friday, 1 April 2016 15:04:46 UTC