Re: DQV, DAQ and Data Cube graphs

Hi Antoine,

I'm actually not a big fan of using the graphs as part of the model and
would rather let this up to the implementers. Some may want to put all the
quality data in one graph, some others may want to put every single
statement into its own graph in order to track its provenance. We may
suggest something but I would rather not impose anything.

That said I understand that the grouping proposed by DAQ in
daq:QualityGraph is there to facilitate the visualisation of the data. I
agree this is a feature we may want to keep but I would rather look for
another, fourth, proposal that would consist in removing the two graphs and
finding another type of entry point. As far as I know, DataCube does not
impose any use of graphs and yet is easy to visualise thanks to the DSD and
indication of slices.

Cheers,
Christophe

On 27 August 2015 at 01:12, Antoine Isaac <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 -
>
> 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)
>
> Riccardo has pointed out that we should keep in mind also issue 191 [2]
> 'DQV backward compatibility with DAQ and Data Cube'.
> 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/
>
>


-- 
Onderzoeker
DANS, Anna van Saksenlaan 51, 2593 HW Den Haag
+31(0)6 14576494
christophe.gueret@dans.knaw.nl


*Data Archiving and Networked Services (DANS/KNAW)*[image:
http://dans.knaw.nl] <http://dans.knaw.nl>

*e-Humanities Group (KNAW)*
[image: eHumanities] <http://www.ehumanities.nl/>

*World Wide Semantic Web community*
http://worldwidesemanticweb.org/