Re: DQV, ISO 19115/19157 and GeoDCAT-AP

Dear Andrea,

I am not sure whether your email has been acknowledged earlier. In case we've failed at it: we'd like to thank you. These are relevant comments, and should be addressed.
We've included your feedback in the agenda for our discussion at the DWBP F2F (starting tomorrow afternoon, European time)

#2 and #3 are rather specific issues, we will have to dive deeper in them.

As regards #1, it is a rather general comment and I feel I could try to start answering you now (we'll need further discussion of course)
I think DQV could be indeed qualified as "core" that can be "extended" or "refined", in the sense of creating new elements related to the core ones by sub-class or sub-property links.
In some places DQV is even what I'd call a "meta"-level framework, where classes are instantiated to represent resources that are still relatively generic E.g., an instance of dqv:Dimension could be ex:consistency, which is still fairly abstract. Here DQV works a bit like SKOS, in the Semantic technology stack.

Anyway, that is to say that DQV can be probably seen as belong to the same level as the ISO standards you refer, looking at the "data elements" defined by these standards.
So I believe we should try to making DQVcompatible with them.



On 8/31/15 12:51 AM, Andrea Perego wrote:
> Dear DWBP WG,
> I have a few of questions / comments on DQV, specifically related to
> its use for geospatial metadata (for this reason, I'm cc'ing also the
> SDW WG).
> 1. Data quality is one of the "elements" included in the current
> standards used for geospatial metadata, namely, ISO 19115:2003 and ISO
> 19157:2013 (see [1, 2] for an overview). I wonder whether you would
> consider (at least, partial) compatibility with the approaches defined
> in those ISO standards as a possible requirement. More in general, my
> question is about the design principles behind DQV. I wonder whether
> you see it as a "core" vocabulary, meant to define the main data
> quality concepts, common across domains, that can be possibly extended
> to address domain-specific requirements.
> 2. Specifically with respect to "conformance" with quality standards /
> benchmarks: ISO also includes it, with the notion of "conformance
> result". However, as far as I can see, in DQV you support only one
> specific case via dct:conformsTo, i.e., when data are "conformant",
> whereas ISO allows also to state that data are NOT conformant.
> Moreover, INSPIRE "extends" ISO by allowing to state that conformance
> has not been evaluated (see [3]).
> 3. Following from point (2): GeoDCAT-AP [4] addresses this issue by
> modelling conformance results with PROV (using nonetheless also
> dct:conformsTo when data are conformant with the referred
> specification). For the modelling "pattern" used, feedback has been
> asked from the PROV WG (see the relevant mail thread [5]). Actually,
> the original proposal was to use EARL - I contributed that approach in
> an earlier mail [6]. However, the GeoDCAT-AP WG eventually decided to
> switch to PROV, as a more sustainable solution. You can find an
> explanation in the description of the relevant issue:
> Here's an example:
> <a:Dataset> prov:wasUsedBy [
>   a prov:Activity;
> # Conformity degree
>    prov:generated [
>     dct:type <>
> ;
>    prov:qualifiedAssociation [
>     prov:hadPlan [
>       a prov:Plan;
>       prov:wasDerivedFrom [
> # Specification
>          a prov:Entity, dct:Standard;
>         dct:title "COMMISSION REGULATION (EC) No 976/2009 of 19 October
> 2009 implementing Directive 2007/2/EC of the European Parliament and
> of the Council as regards the Network Services"@en
>         dct:issued "2009-10-20"^^xsd:date
>       ]
>     ];
>   ];
> ] .
> and the same by using dct:conformsTo:
> <a:Dataset> dct:conformsTo [
> # Specification
>    a dct:Standard;
>    dct:title "COMMISSION REGULATION (EC) No 976/2009 of 19 October 2009
> implementing Directive 2007/2/EC of the European Parliament and of the
> Council as regards the Network Services"@en
>    dct:issued "2009-10-20"^^xsd:date ] .
> Of course, the PROV-based approach allows to attach additional
> information about the provenance of quality metadata - i.e., when the
> test has been carried out, by whom, with which methodology and/or test
> tool, etc.
> Any feedback you would provide on this approach would be very much
> relevant for the final specification of GeoDCAT-AP.
> Thanks in advance!
> Andrea
> ----
> [1]
> [2]
> [3]
> [4]
> [5]
> [6]

Received on Wednesday, 23 September 2015 23:46:46 UTC