Re: DQV, DAQ and Data Cube graphs

Hi Christophe,
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.


Considering that  daq:QualityGraph is defined in Daq and we cannot change
its definition,  your  proposal might be refined as

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 this way,
 we  get rid of the inner rdfg:Graph, we don't change daq:QualityGraph that
can't be changed  and  we are  compatible with the RDFCube.
Does it work for you?


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

Concerning  dqv:QualityMetadata, the  outer RDFG:graph in the DQV schema,
it basically groups all the quality statements for a datasets in a graph,
so that  we can easily track the  provenance of quality statements;
as far as I remember, tracking the provenance of the quality statement is
one of the requirement on which we agree,  and I like that DQV is providing
an explicit guidance on it, but   by deleting the outer  graph, I think it
 gets lost.
 Before deleting the outer rdfg:graph,   I wonder if you/we  have an
alternative design pattern, not relying  on RDFG:Graph but  keeping track
of the "quality statement"  provenance.  Any proposal?

Otherwise, I would prefer to  keep the  outer RDFG:graph in the DQV schema
as it is.

Regards,
 Riccardo