- From: Frans Knibbe <frans.knibbe@geodan.nl>
- Date: Mon, 26 Sep 2016 14:40:15 +0200
- To: Jon Blower <j.d.blower@reading.ac.uk>
- Cc: SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CAFVDz433tYOyKsh=6swFUvoyMFkzSzN-ECQxa6=dLev4UBpYOA@mail.gmail.com>
Issue-75 was closed at the Lisbon F2F. I have just rephrased the Quality metadata requirement and renamed it to Quality per sample <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#QualityPerSample> . Regards, Frans On 14 September 2016 at 15:33, Jon Blower <j.d.blower@reading.ac.uk> wrote: > Hi Francs, > > > > Yes, good thoughts. I’m happy with the phrasing, “It should be possible to > describe properties of data quality (e.g. uncertainty) per data sample”. > > > > Ø By the way, are there other quality properties next to uncertainty > that should be possible to record per sample in a coverage? > > > > Yes – quality flags are another common use case. > > > > Ø If it is only uncertainty that matters, couldn't that be adequately > addressed by using significant digits? > > > > No – that’s precision, which is a different thing. Uncertainty can be > expressed in a load of different ways. The ideal situation (for some) is to > have a probability density function for each sample value – but most people > collapse this to a “x plus or minus y” kind of simplified representation. > Summary statistics are a middle ground. > > > > (It’s worth noting that if you don’t convey a view of uncertainty then you > are actually transmitting no information at all… We get around this by > either assuming that values are exact or by applying some implicit > knowledge about uncertainty. But that’s probably a diversion into > beard-stroking.) > > > > Cheers, > > Jon > > > > *From: *Frans Knibbe <frans.knibbe@geodan.nl> > *Date: *Wednesday, 14 September 2016 13:42 > *To: *Jon Blower <sgs02jdb@reading.ac.uk> > *Cc: *SDW WG Public List <public-sdw-wg@w3.org> > *Subject: *Re: UCR ISSUE-75: Coverage requirement for quality metadata in > scope? > > > > Hi Jon, > > > > Thank you for your thoughts. It seems to me that your first point, quality > information for the entire dataset, does not really justify the explicit > requirement. It is something that should already be covered by general best > practices for data on the web, right? > > > > But data quality data per sample value seems to be something that needs > specific guidance. By the way, is it OK to use 'sample' instead of 'pixel'? > Not all coverage data are raster data... > > > > So how about rephrasing the requirement to "It should be possible to > describe properties of data quality (e.g. uncertainty) per data sample"? > > > > By the way, are there other quality properties next to uncertainty that > should be possible to record per sample in a coverage? If it is only > uncertainty that matters, couldn't that be adequately addressed by using > significant digits? > > > > Regards, > > Frans > > > > > > > > On 13 September 2016 at 20:31, Jon Blower <j.d.blower@reading.ac.uk> > wrote: > > Hi Frans, > > > > I agree that data quality is a general issue. However, there may be some > specific things to say about coverages. For example: > > > > 1. “General” quality information (e.g. sensor accuracy) could be > recorded as metadata with the coverage. > > 2. However, if we want **per-pixel** quality information in the > coverage, this implies that we need a set of range values for the quality > information (e.g. one set of range values for temperature, and one for the > uncertainty on the temperature, howsoever measured). It also means that > there ought to be a way to link these two sets of range values together, to > advertise to clients that they should consider those two things together. > > > > There are no widely-used standards for per-pixel quality information as > far as I know, but we have proposed such a mechanism in CoverageJSON [1]. > In a previous project (GeoViQua) we developed a way to do this in WMS too > [2]. Both are incomplete and could be further developed. > > > > (UncertML provides a vocabulary for probability density functions and > statistics, which can be reused here.) > > > > Best wishes, > Jon > > > > [1] https://covjson.org/spec/#parametergroup-objects > > [2] http://dx.doi.org/10.3390/ijgi4041965 > > > > *From: *Frans Knibbe <frans.knibbe@geodan.nl> > *Date: *Friday, 9 September 2016 14:57 > *To: *SDW WG Public List <public-sdw-wg@w3.org> > *Subject: *UCR ISSUE-75: Coverage requirement for quality metadata in > scope? > *Resent-From: *<public-sdw-wg@w3.org> > *Resent-Date: *Friday, 9 September 2016 14:57 > > > > Hello everyone, > > > > I just realised ISSUE-75 <https://www.w3.org/2015/spatial/track/issues/75> > did not have its own e-mail thread yet. Of course that won't do. So this is > the official thread for ISSUE-75. > > > > The issue is about the quality metadata requirement > <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#QualityMetadata>. > It is a requirement for the Coverage deliverable. It currently reads "It > should be possible to describe properties of the data quality, e.g. > uncertainty." > > > > The need to describe data quality is a general data issue, so it does not > seem in scope for the Coverage deliverable and perhaps it does not need to > be mentioned in the UCR document. > > > > Should we decide to keep the requirement, perhaps it could just as well be > related to the other deliverables. > > > > Is there something about coverage data that justify making this > requirement explicit for the coverage deliverable? > > > > > > Greetings, > > Frans > > > > > > >
Received on Monday, 26 September 2016 12:40:48 UTC