Re: DQV, DAQ and Data Cube graphs - ISSUE 182

Hi everyone,

That's a great discussion!
I'll focus on ISSUE-182 for the moment, even if we end up removing this class later...

According to Annette, it's not great to use the word 'Graph'. The discussion about ISSUE-181, which hints that we could remove the subclass axiom to rdfg:Graph, then it's clear we should not use that term in the class' name.

But to me the original problem with daq:QualityGraph (and qd:Dataset) is that it's expected to contain only (statistical) measures [1], and that this is absolutely not represented in the class name. Changing 'Graph' into 'Dataset' won't solve this. What I need is something that says 'Statistics' or 'Measures'.

So I propose QualityStatistics or QualityMeasures. The latter being better aligned (but also potentially mistaken) with the existing dqv:QualityMeasure.

Antoine

[1] http://www.w3.org/TR/vocab-data-cube/#cubes-model-datasets says "A DataSet is a collection of statistical data that corresponds to a defined structure"
http://butterbur04.iai.uni-bonn.de/ontologies/daq/daq#QualityGraph says"Defines a quality graph which will contain all metadata about quality metrics on the dataset."

On 9/3/15 7:56 PM, Riccardo Albertoni wrote:
> Hi Christophe, Jeremy and Nandana,
>
> Thanks for your replies, and the interesting discussion.
>
> It seems we have an agreement  on proposal 4,
>
> Proposal 4:   define  in DQV the new class dqv:QualityDataset which replaces daq:QualityGraph,   is defined as   subclass of qb:DataSet, but it is not a subclass of RDFg:Graph.
>
> In my opinion,  this should  solve ISSUE-182 : http://www.w3.org/2013/dwbp/track/issues/182 - The label of daq:QualityGraph does not fit well with the current model.
>
>
> Reading your replies,  I think we are not far from solving   also the
>
> ISSUE-181: http://www.w3.org/2013/dwbp/track/issues/181 - Should we have only the existing class daq:QualityGraph or keep the new class dqv:QualityMetadata?
>
> As far as I have understood, we want to keep  the class dqv:QualityMetadata, because  we want to provide provenance at different granularity levels,  and that is possible because both dqv:QualityMeasure and dqv:QualityMetadata are  prov:Entity.
>
> Perhaps , the   missing piece is if we want to have dqv:QualityMetadata as RDFg:Graph or not.
>
> So we might close the issue181 deciding between the two options mentioned  by Nandana in [1],
>
> namely,
>
> to keep dqv:QualityMetadata  as RDFg:Graph,
>
> or
>
>   to explicitly relate a set of quality measures and annotations to a dqv:QualityMetadata using some RDF relation defined in DQV ( similar to dqv:hasQualityMeasure or db:dataset). dqv:contains ( Domain: dqv:QualityMetadata -> Range: [ owl:unionOf ( dqv:QualityMeasure  dqv:QualityAnnotation) ] )
>
> What do you think? any preference?
>
> Regards,
>   Riccardo
>
> [1] https://lists.w3.org/Archives/Public/public-dwbp-wg/2015Sep/0003.html
>
>
> On 3 September 2015 at 13:23, Debattista, Jeremy <Jeremy.Debattista@iais.fraunhofer.de <mailto:Jeremy.Debattista@iais.fraunhofer.de>> wrote:
>
>     Hi Antoine, Riccardo, Christophe,
>
>     Sorry for my late reply but I got stuck on other things. I’ll try to group replies from all emails in one.
>
>     (1) Compatibility between daQ and DQV
>
>>     If we resolve ISSUE-180 [1] by not re-using directly the DaQ elements, we can solve both issues at once. Here are two proposals from me:
>>
>>     PROPOSAL 1: Replace daq:QualityGraph by a new class (say, dqv:QualityMeasureGraph)
>>     PROPOSAL 2: Drop daq:QualityGraph and represent quality measures in graphs of the same class as the other quality metadata (ie., graphs of type dqv:QualityMetadata)
>
>     I think if dqv:QualityMetadata and daq:QualityGraph are equivalent classes, then both will be compatible because they will have the same set of individuals. Please correct me if I’m wrong.
>
>>     We still have the issue  of backward compatibility between DQV and DAQ. I guess this issue might be solved by defining   daq:QualityGraph as  subclass of  dqv:QualityDataset, we might discuss this with DAQ designers, ( @Jeremy, what do you think? Does it work?)
>
>     I don’t think subclasses will work because instances will only be compatible one way (i.e DQV -> DAQ or DAQ -> DQV).
>
>     Therefore, in order to keep the data cube feature without using rdfg:Graphs, one possible solution is as Riccardo proposed:
>
>>     Proposal 4:   define  in DQV the new class dqv:QualityDataset which replaces daq:QualityGraph,   is defined as   subclass of qb:DataSet, but it is not a subclass of RDFg:Graph.
>
>     but making dqv:QualityDataset a subclass of qb:DataSet using the cube data structure definition defined in daQ (daq:dsd).
>
>     If what I’m saying is correct, then I think it will make daQ and DQV compatible with each other. What do you think?
>
>     On the other hand, if you think that the compatibility from DQV to daQ is not important, then subclassing should be enough.
>
>
>     (2) Usage of rdfg:Graph in daQ and Provenance
>
>>     You are right,  we don't need to keep the daq:QualityGraph as a rdfg:Graph, but we still need a subclass of qb:DataSet as  range of the property  qb:dataSet
>>     to facilitate the visualisation of the data as RDF cube.
>
>     The idea of storing quality metadata as graphs was in order to make a distinction between the data itself and the metadata. It also makes things easier for crawling and querying in my opinion, whilst also tracking the provenance of quality observations  Each daQ observation is also a prov-o entity [1].
>     I agree that provenance at different granularity levels - as Nandana wrote in his reply - is required.
>
>     Cheers,
>     Jer
>
>     [1] http://purl.org/eis/vocab/daq
>
>     On 27 Aug 2015, at 01:12, Antoine Isaac <aisaac@few.vu.nl <mailto:aisaac@few.vu.nl>> wrote:
>
>>     Dear all,
>>
>>     While preparing the last mail, Riccardo and I started a longer discussion on which the group's input would be welcome.
>>
>>     This is about the following issues:
>>
>>     http://www.w3.org/2013/dwbp/track/issues/181 - Should we have only the existing class daq:QualityGraph or keep the new class dqv:QualityMetadata?
>>     http://www.w3.org/2013/dwbp/track/issues/182 - The label of daq:QualityGraph does not fit well with the current model -
>>
>>
>>
>>     Riccardo has pointed out that we should keep in mind also issue 191 [2]
>>     DaQ has been made consistent with RDF Data Cube (qb: namespace [5]): daq:QualityGraph is a sub-class of qb:DataSet, so that results of the quality measures can be visualised by RDF-cube visualizer (see [3]). This is very useful feature and he thinks we should preserve it in DQV. And I agree.
>>     So when dropping daq:QualityGraph, we have to think where to put the qb:DataSet subclassing and to the rearrange qb:dataSet property in our graph at [4]
>>
>>     Riccardo suggests another (orthogonal) proposal:
>>
>>     PROPOSAL 3: define dqv:QualityMetadata as a subclass of daq:QualityGraph.
>>
>>     With this we keep compatibility with DaQ and Data Cube. We don't have nested graphs anymore - only a graph grouping together all the measures and annotations, and whose provenance can be easily tracked.
>>
>>     The problem is semantics: qb:Dataset is defined as "collection of statistical data" and a daq:QualityGraph "contain all metadata about quality metrics on the dataset". So these are rather numerical observations, while our dqv:QualityMetadata can include more diverse metadata, for example textual annotations.
>>
>>     What do you think?
>>
>>     Best,
>>
>>     Antoine
>>
>>     [1] http://www.w3.org/2013/dwbp/track/issues/180
>>     [2] http://www.w3.org/2013/dwbp/track/issues/191
>>     [3] http://eis-bonn.github.io/Luzzu/papers/semantics2014.pdf
>>     [4] http://www.w3.org/TR/vocab-dqv/#vocabulary-overview
>>     [5] http://www.w3.org/TR/vocab-data-cube/
>>
>
>
>     --
>     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.
>
>
>
>
> --
> ----------------------------------------------------------------------------
> 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 <mailto:Riccardo.Albertoni@ge.imati.cnr.it>
> Skype: callto://riccardoalbertoni/
> LinkedIn: http://www.linkedin.com/in/riccardoalbertoni
> www: http://www.ge.imati.cnr.it/Albertoni
> http://purl.oclc.org/NET/riccardoAlbertoni
> FOAF:http://purl.oclc.org/NET/RiccardoAlbertoni/foaf

Received on Friday, 4 September 2015 14:38:42 UTC