W3C home > Mailing lists > Public > public-dwbp-wg@w3.org > September 2015

Re: DQV ISSUE-187 - cardinality of the link between Metric and Dimension

From: Annette Greiner <amgreiner@lbl.gov>
Date: Fri, 18 Sep 2015 11:31:48 -0700
Cc: Antoine Isaac <aisaac@few.vu.nl>, "Debattista, Jeremy" <Jeremy.Debattista@iais.fraunhofer.de>, Public DWBP WG <public-dwbp-wg@w3.org>
Message-Id: <155373FB-661F-4D92-BE65-DFF267831356@lbl.gov>
To: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
Thanks, Nandana,
I totally agree with this approach.
+ oodles,

Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory

On Sep 18, 2015, at 5:50 AM, Nandana Mihindukulasooriya <nmihindu@fi.upm.es> wrote:

> Hi Annette,
> On Wed, Sep 16, 2015 at 8:51 PM, Annette Greiner <amgreiner@lbl.gov> wrote:
> Whoops, I was confusing the DQV and DUV. Anyway, the idea applies to both. It should be easy to implement each vocabulary, and our docs should contain all the info one needs to do that, at least for the common cases. So, I think we should define our own metrics and dimensions. That seems to me a big part of the potential value of a specific quality vocabulary for data on the web.
> -Annette
> +1 for for having a set of good examples as sort of a primer for both DUV and DQV, . 
> And regarding the definition of our own metrics, dimensions, and categories: I think it has two sides. On the one hand, if I am a quality metrics (report) publisher, at the moment I have define a set of my own metrics (which might mean that I have mint URIs, and if I want them to be easily discovered, exposing them in dereferenceable resources, etc.). It seems a bit too much for a common scenario. For the consumers of these metrics, they will also have to deal with metric definitions coming from many parties and see the metric definitions to understand them. However, at some point of time, I guess some common metrics definitions that are widely accepted will emerge from W3C groups or third-parties that quality metrics publishers will use without going through that trouble. 
> On the other hand, if we want to define our own metrics in DQV,  it will be hard to define concrete metrics that work for all as the DQV scope is quite wide (i.e., it covers any type of data). So the flexibility to define custom metrics is a must so that everyone can express their metrics which suits to certain types of data and with fine-grained details. May be it is a bit more easier to define the dimensions and categories (compared to metrics) as they are somewhat generic. I see there have been discussions about this already [1, 2, 3]. Another option, (that I already saw in DQV schedule), is to adapt the dimensions defined in ISO 25012 [4]. We have been analyzing the quality dimensions defined in ISO 25012, ISO 8000 [5], and various other models from Richard Wang, Gamble and Goble, Domenico Natale, etc. We saw a huge overlap in them and ISO 25012 captures the essence of them nicely.
> So may be a middle ground would be to define a common dimensions and a set of generic metrics that allow people to get started without much effort in common scenarios while allowing people to define their own metrics, dimensions, and categories (as it is now) when the ones defined in DQV don't fit well. Probably that would mean representing the instances of dimensions and metric hints using the DQV vocabulary with their URIs so that people can directly use them in their quality reports. This would help both the quality report producers and consumers. 
> (Sorry if this topic was already discussed and some conclusions were already made)
> Best Regards,
> Nandana
> [1] - http://www.w3.org/TR/vocab-dqv/#dimensions-and-metrics-hints
> [2] - http://www.w3.org/2013/share-psi/wiki/Timisoara/Scribe#Tuesday_17th_March_.2811:30_-_12:40_Parallel_Sessions_B.29
> [3] - http://www.slideshare.net/OpenDataSupport/open-data-quality-29248578/8
> [4] - http://iso25000.com/index.php/en/iso-25000-standards/iso-25012
> [5] - http://www.eccma.org/iso8000/ 

Received on Friday, 18 September 2015 18:32:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:41 UTC