Re: New DQV editor's draft

Thanks Antoine and all for this work. This captures the current thinking 
and raises issues where necessary, showing the direction of travel. 
That's what an FPWD is for :-)

On reusing DaQ: the fact that it is a project output (no matter how good 
that project may be) does make it a little risky. Against that, we're 
currently heading for DQV as a Note, not a Rec (unless you want to put 
it through Rec Track). So in that sense, the whole document is 
non-normative so dependencies are less critical.

However, I suggest one way forward would be to declare all relevant 
classes in the dqv namespace but then declare them all as 
owl:equivalentClass/property. How would that be?

And I re-raise the possibility of putting all these new terms, and DUV, 
in the DCAT namespace. For me, that's the thing to do but it's a WG 
decision of course.

Phil.

On 22/05/2015 09:45, Debattista, Jeremy wrote:
> Hi Antoine, Christophe, Riccardo,
>
> This looks great already. It seems to be comprehensive  and not much to add. I would like to point out two issues which are not clear to me as yet:
>
> 1) In the diagram, shouldn't the dcat:Dataset be "outside" of the quality metadata (and especially outside of the QualityGraph containment), and then the dcat:Dataset points to the quality metadata graph?
>
> I don't know if this was done on purpose there or should have been placed outside. If a dcat:Dataset (or distribution) is inside the quality metadata boundaries, then my understanding as a consumer (I might be a machine) would be that a dcat:Dataset instance is some kind of quality information.
>
> 2) How about doing dqv:QualityMetadata as a subclass of daq:QualityGraph?
>
> There are a number of advantages of doing so. First of all we don't have to rely on multiple graphs. Although nothing is wrong with that, this might make querying a bit harder. The daq:QualityGraph is a specialisation of the rdf:Graph which is also a qb:Dataset. In this case the qb:dataset property can have dqv:QualityMeasure as domain and dqv:QualityMetadata as its range. This way we can move dcat:Dataset from the graph containment, and removing the property "dqv:hasQualityMeasure" (this becomes redundant as it can be inferred, if there is some link between dcat:Dataset and dqv:QualityMetadata).
>
> Once we have a first draft of the RDF schema, I will be happy to support it in our Quality Assessment Framework.
>
> Cheers,
> Jeremy
>
> On 20 May 2015, at 23:39, Antoine Isaac <aisaac@few.vu.nl> wrote:
>
>> Dear all,
>>
>> We've created a new editor's draft of the Data Quality Vocabulary on Github [1].
>>
>> Most of it is in the diagram in section 3. We have placeholder for material in other sections, but this is still work in progress.
>>
>> As you can see the diagram and the doc still have a lot of open issues and questions. But we believe it's a positive evolution from the previous version [2]. The patterns that we would like to use are stabilizing
>> Actually I'm curious to see how much of Jeremy's last comments [3] would still apply!
>>
>> Needless to say, everyone else's feedback is highly welcome!
>>
>> Please excuse the discussion notes in the diagram itself. We thought of creating a wiki page as we had done previously [2]. But I lacked the time to do it. Maybe in the coming days, depending on how the discussion evolves...
>>
>> Cheers,
>>
>> Antoine, on behalf of co-editors Riccardo and Christophe
>>
>> [1]  http://w3c.github.io/dwbp/vocab-dqg.html
>> [2]  https://www.w3.org/2013/dwbp/wiki/Data_Quality_Vocabulary_%28DQV%29
>> [3]  http://lists.w3.org/Archives/Public/public-dwbp-wg/2015May/0037.html
>>
>
>
>

-- 


Phil Archer
W3C Data Activity Lead
http://www.w3.org/2013/data/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Friday, 22 May 2015 13:02:47 UTC