W3C home > Mailing lists > Public > public-dwbp-wg@w3.org > February 2016

Re: Data Quality Vocabulary - feedback welcome!

From: Riccardo Albertoni <albertoni@ge.imati.cnr.it>
Date: Tue, 9 Feb 2016 18:09:38 +0100
Message-ID: <CAOHhXmTqzEUrJ=98sQu7RiRj2HrSPOSqT9w9SB2fdHcf+hsvPA@mail.gmail.com>
To: DWBP Public List <public-dwbp-wg@w3.org>
Cc: Antoine Isaac <aisaac@few.vu.nl>, "Debattista, Jeremy" <Jeremy.Debattista@iais.fraunhofer.de>
Dear All,
Some considerations about ISSUE-223: Parameters for metrics
which hopefully will help in closing this issue.

As already explained by Jeremy,
DAQ includes the possibility to express that a metric has some extra
parameters, for example a metric about completeness can point to a specific
dataset providing the "ground truth", by using the property daq:requires.

In that case,   we can have

a dqv:Metric;
daq:requires :groundTruth;
dqv:hasDimension  :completeness.

so my FIRST basic  PROPOSAL is  to add  explicitly in the DQV draft a
property dqv:requires, which is defined  in analogy with DAQ.

in addition to this, Werner in his reply has suggested that we can even
think to subclass the properties.

 That sounds extremely interesting to me,  since it might  model in  more
precise way  the extra parameters required by metrics such as  the Linkset
Importing, a metric  on which my group is working,   that   we have already
mentioned in DQV draft 's section 5.7 "Express the quality of a linkset".

thus my SECOND PROPOSAL is to  add the following  example in dqv to provide
guidance on  how to add extra parameters for quality metrics.

I would exploit the Linkset Importing as example for showing how to add
extra parameters.

 Linkset Importing requires two extra properties :language and :property,
 respectively ranging in the  ISO 639-1 language codes, and rdfs:properties.

A possible way to  manage extra parameters follows..

####  http://example.com/ex#onLanguage

<http://example.com/ex#onLanguage>    rdfs:range <
http://www.loc.gov/mads/rdf/v1#Language> ;

                                   rdfs:subPropertyOf <
http://www.w3.org/ns/dqv#requires> .

###  http://example.com/ex#onProperty

<http://example.com/ex#onProperty>    rdfs:subPropertyOf   <
http://www.w3.org/ns/dqv#requires> .

we can  use  the subclassing trick, in order to enforce that a certain type
of metric has certain parameters specified. For example,  LinksetImporting
is a   subclass dqv:Metrics with the extra properties onLanguage and
###  http://example.com/ex#LinksetImporting


                                         rdfs:subClassOf <
http://purl.org/eis/vocab/daq#Metric> ,
http://www.w3.org/ns/dqv#Metric> ,
                                                         [ rdf:type
owl:Restriction ;
                                                           owl:onProperty <
http://example.com/ex#onLanguage> ;

 owl:someValuesFrom <http://www.loc.gov/mads/rdf/v1#Language>
                                                         ] ,
                                                         [ rdf:type
owl:Restriction ;
                                                           owl:onProperty <
http://example.com/ex#onLanguage> ;

 owl:allValuesFrom <http://www.loc.gov/mads/rdf/v1#Language>
                                                         ] ,
                                                         [ rdf:type
owl:Restriction ;
                                                           owl:onProperty <
http://example.com/ex#onProperty> ;

 owl:someValuesFrom rdfs:Resource
                                                         ] ,
                                                         [ rdf:type
owl:Restriction ;
                                                           owl:onProperty <
http://example.com/ex#onProperty> ;

 owl:allValuesFrom rdfs:Resource
                                                         ] .

Then we can instanciate the metric LinksetImporting with two metrics which
 work on Italian and English prefLabel respectively,

###  http://example.com/ex#linksetImportingENSKOSPrefLabel

<http://example.com/ex#linksetImportingENSKOSPrefLabel> rdf:type <
http://example.com/ex#LinksetImporting> ;

                      <http://www.w3.org/ns/dqv#hasDimension> <
http://example.com/ex#completenessOfComplemented> ;

                       <http://example.com/ex#onProperty> <
http://example.com/ex#skosPrefLabel> ;

                       <http://example.com/ex#onLanguage> <
http://id.loc.gov/vocabulary/iso639-1/en> .

###  http://example.com/ex#linksetImportingITSKOSPrefLabel

<http://example.com/ex#linksetImportingITSKOSPrefLabel> rdf:type <
http://example.com/ex#LinksetImporting> ;

                     <http://www.w3.org/ns/dqv#hasDimension> <
http://example.com/ex#completenessOfComplemented> ;

                      <http://example.com/ex#onProperty>  <
http://example.com/ex#skosPrefLabel>   ;

                      <http://example.com/ex#onLanguage> <
http://id.loc.gov/vocabulary/iso639-1/it> .

And finally we can state the actual quality measurements.

###  http://example.com/ex#actual_metricValue

<http://example.com/ex#actual_metricValue> rdf:type
                           <http://www.w3.org/ns/dqv#QualityMeasure> ;

           <http://www.w3.org/ns/dqv#value> 0.5 ;

<http://www.w3.org/ns/dqv#hasMetric> <
http://example.com/ex#linksetImportingITSKOSPrefLabel> .

###  http://example.com/ex#actual_metricValue2

<http://example.com/ex#actual_metricValue2> rdf:type
http://www.w3.org/ns/dqv#QualityMeasure>  ;

                <http://www.w3.org/ns/dqv#value> 1 ;

http://www.w3.org/ns/dqv#hasMetric> <
http://example.com/ex#linksetImportingENSKOSPrefLabel> .

A final consideration  about  mapping the extra- parameter into RDF
 in  the case of the linkset importing,  extra parameters should be
modelled as dimensions when defining the RDF cube data structure.    I
guess we can provide a mapping script that considered the extra parameters
adds to the rdf cube structure the proper components. Probably, in this
direction,  it would be  wise to group all the extra parameters that are
expected to be mapped as rdf cube dimensions in a specific  dqv:requires
subproperty such as http://www.w3.org/ns/dqv#mandatoryParameters, so that
they can eventually collected by the mapping script.

THIRD PROPOSAL:  as in the second but grouping extra parameters that are
expected to be transformed into dimension for the rdf data cube under a
specific  the property http://www.w3.org/ns/dqv#mandatoryParameters

please let me know which of  the previous proposals you support or if you
have any amendments.


On 7 December 2015 at 12:48, Bailer, Werner <werner.bailer@joanneum.at>

> > https://www.w3.org/2013/dwbp/track/issues/223 - Parameters for metrics
> I see that daq:requires can be used for this purpose. However, it's a
> fairly generic way, that may point to ground truth data, parameters, etc.
> So in for the sake of interoperability, it may be useful to define
> subproperties being more specific about the role of the external resource.

Riccardo Albertoni
Istituto per la Matematica Applicata e Tecnologie Informatiche "Enrico
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
Received on Tuesday, 9 February 2016 17:10:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 9 February 2016 17:10:05 UTC