Re: Missing provenance metadata on DQV Observations

dear  Jeremy,
Thanks for your email, I am happy to learn about further cases of  reuse of
the   DQV.

 My reply follows inline with your email.

On 6 June 2016 at 13:10, Debattista, Jeremy <
Jeremy.Debattista@iais.fraunhofer.de> wrote:

> Hi Antoine, Riccardo, all
>
> I hope this email finds you well. Dimitris (cc’ed) created a tool that
> translates quality results from RDFUnit and SHACL to the DQV (@Dimitris:
> please correct me if I am wrong). Apart quality values, RDFUnit produces
> quality reports that describes the assessment “activity” of a metric. Such
> provenance reports are an asset that should be attached to quality
> observations. One problem in DQV is that dqv:Observation is only a subclass
> of qb:Observation, therefore in theory we cannot do something like this:
>
> ex:testExecutionIRI a rut:TestExecution, prov:Activity;
> # some other triples ...
> rut:totalTriples “10”^^xsd:Integer.
>
> <dataset IRI> dqv:hasQualityMeasure ex:qm1.
>
> ex:qm1 prov:wasGeneratedBy ex:testExecutionIRI ;
> dqv:computedOn <dataset IRI>;
> dqv:hasMetric rdqv:CardinalityMetric
>   dqv:value "0.1"^^xsd:double .
>

> On the other hand, this can be done in daQ - daq:Observation is a subclass
> of both qb:Observation and prov:Entity.
>

In the last DQV  W3C Working Draft [2],  we have  different points where
 dqv:QualityMeasurement, formerly named dqv:Observation,  is a
prov:Entity.  For example,
-we refer to wasDerivedFrom as one of the possible relations to deploy to
interrelate quality artifacts ( see fig 2),  and as a consequence, we
explicity mention prov:wasderivedFrom in [3] and we provide examples of
possible use of this property in [4];
- we have defined dqv:QualityMeasurement equivalent to daq:Observation,
which is subclass of prov:Entity;
- we make  an  example about how to document the provenance of single
quality measurement [5];

 So, the fact that  the prov:Entity subclassing is not explicitly stated
should not prevent you from applying Prov properties to
 dqv:QualityMeasurement.

 The group  discussed whether dqv:QualityMeasurement should have been
explicitly stated  as  a sub-class of prov:Entity.  We decided to not do
 it, because it seems that prov:Entity is more  meant to be inferred than
 stated:  stating the  "prov:Entity" as a type  does not say much alone,
and on the other hand,  if you apply some prov relations to any instance,
then  the  prov:Entity type is be automatically inferred.

Said that,  your comment reveals that this design choice  can  be
misunderstood,  Do you think  we should add a note or a sentence to  make
our point clearer?



> Dimitris and I were discussing the potential of such quality reports
> today, and we concluded that these reports would give a better
> understanding of the dqv:value, which I humbly say that in Luzzu (for
> example) we miss out. As it stands out, a consumer would know that the
> value of metric X is 10% (in this case), but with this additional
> provenance metadata a consumer would know exactly what 10% means.
> Therefore, my suggestion is - lets make dqv:Observation a subclass of
> pro:Entity (as it is in daQ).
>
> On a similar note, I think that we should also add a section of tools that
> are implementing the DQV vocabulary, and I think we should add the tool
> Dimitris developed for RDFUnit [1]. I think Dimitris can also provide some
> examples of how to convert SHACL data to DQV.
>

Collecting  the DQV implementations  is a good idea, but I am not sure we
should list them  in the  DQV Document.  Very soon,   we are supposed  to
have the final DQV vote,  and after the last vote, we are not allowed to
update the document anymore.
Then the risk is to leave out  many of the implementations that are still
in progress.

What do you think about  having the implementations collected in a   the
w3c DWBP wiki page?  A wiki page   can be easily maintained  after the vote
and  I guess we are allowed to refer to such a  page from the DQV document.

Cheers,
Riccardo


> Let us know what you think.
>
> [1] https://github.com/AKSW/RDFUnit/tree/master/rdfunit-w3c-dqv
>
>
> Cheers,
> Jer
>
> --
> This message has been scanned for viruses and dangerous content by
> *E.F.A. Project* <http://www.efa-project.org>, and is believed to be
> clean.
>

[2]http://www.w3.org/TR/2016/WD-vocab-dqv-20160519/
[3]https://www.w3.org/TR/vocab-dqv/#prov:wasDerivedFrom
[4]https://www.w3.org/TR/vocab-dqv/#expressQualityDerivation
[5] https://www.w3.org/TR/2016/WD-vocab-dqv-20160519/#DocumentProvSingleQM

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

Received on Monday, 6 June 2016 17:06:05 UTC