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

Dear Andrea,

Three months ago we owe you an update on your original feedback email at [1]. Besides an original answer [2] you could see that we've been actively discussing your comments, notably around Issue-202 we raised after your comments [3].

The status is currently:

1. We have not followed the PROV paths to express conformance. While relevant for many cases, we believe it is too complex for our simple requirements, and would count on provenance-focused applications (including ones seeking to implement ISO or GeoDCAT-AP) to come with their own PROV patterns for representing how a conformance statement has been produced.

2. We have made amendments on the DQV specification for expressing conformance in a way that follows the simpler DCAT-AP pattern using dcterms:conformsTo [4].
We would by the way welcome feedback on our example: is the way we introduce GeoDCAT as a dcterms:Standard appropriate, or would you prefer us to adapt the example on "COMMISSION REGULATION (EC) No 976/2009" at [5]?

3. We have discussed your suggestions of introducing "not evaluated" and "not conformant" as you suggested. We are convinced that adding "not conformant" would be very useful [5].
However, if we implement it, are you aware of a property and a value (URI) to build such statement in RDF?

4. The example of conformance is triggering a discussion on how to indicate that it's fine to use DQV to indicate the quality of metadata, not only 'original' datasets. This is less relevant to your original comment, but you may want to chime in.

We hope this progress somehow answers your original concerns!

If you do not have further input that is also fine. But we will have then to let Issue-202 open until we can get input otherwise. This is the current intention behind the note on this issue in [4].




On 9/24/15 9:59 AM, Andrea Perego wrote:
> Many thanks, Antoine.
> Looking forward to reading the meeting minutes
> Best,
> Andrea
> On Thu, Sep 24, 2015 at 1:46 AM, Antoine Isaac <> wrote:
>> 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.
>> Best,
>> Antoine
>> 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 Friday, 4 December 2015 19:08:58 UTC