- From: Dave Reynolds <dave.e.reynolds@gmail.com>
- Date: Sat, 07 Dec 2013 17:23:24 +0000
- To: Sarven Capadisli <sarven.capadisli@deri.org>, public-gld-wg@w3.org
On 07/12/13 17:01, Sarven Capadisli wrote: > On 12/07/2013 04:25 PM, Dave Reynolds wrote: >> [Not sure this is the best place to ask since most QB implementors are >> not in the WG but ...] > > True that. Just wanted to get a quick feel from a few that's still > keeping an eye on the mailing list and wanted to chime in. :) > >> On 07/12/13 11:36, Sarven Capadisli wrote: >>> How does your application consume and/or view QB observations? >> >> View as graphs, interactive tables, in-line numeric presentations, >> traffic-light widgets, dial-widgets, symbolic summaries - all sorts. >> >> Accessed via Linked Data API to slices and observations, via custom data >> cube specific APIs, via general SPARQL, via link following via bulk >> download of compressed Turtle - all sorts. >> >> [We've quite a lot of QB applications :) and pretty much any access >> approach will have come up at least once.] >> >> Contrary to the earlier discussion we do link to specific observations, >> this is a key value of the approach for *some* of our applications. For >> example, for the Bathing Water quality data then the human readable >> pages such as [1] make claims about the quality of water at particular >> places at particular times. These claims are linked to the individual >> observations. For example click on the "Lastest weekly in-season" title >> on the table takes you to [2]. From this observation you can get to the >> overall dataset and there's also a dct:source link to the specific line >> in the specific incremental CSV data file which was used to generate the >> linked data in the first place. This provenance traceback is one of the >> values of the linked data approach in this particular case. >> >> Of course there are also graphical presentation of subsets of particular >> slices [3]. Not everything is at a per-observation level. >> >> Dave >> >> [1] >> http://environment.data.gov.uk/bwq/explorer/info.html?site=ukk1202-36000 >> [2] >> http://environment.data.gov.uk/doc/bathing-water-quality/in-season/bathing-water/ukk1202-36000/latest >> >> >> [3] >> http://environment.data.gov.uk/bwq/explorer/sample-data.html?site=ukk1202-36000 >> > > > Thanks for sharing! Nice use of latest. > > If I understand you correctly, via slices, linking to individual > observations is necessary, and one can still make their way to the whole > dataset. > > What I fear is dealing with insane number of slices and observations > point from a dataset. I suppose caching or paginating are some ways to > remedy the problem. Sure, not saying that linked data following is the right want to handle cubes in general. I'd recommend cube-specific APIs with support for pagination and/or bulk download guided by void for routine use. But the ability to tie data presentations back to individual observations that dereference can be useful. Especially in a case like this where observations can be revised (so you can see if the data point replaced a prior publication or has itself been replaced). > Aside: I couldn't get much out of > http://environment.data.gov.uk/data/bathing-water-quality/LatestSampleSlice Not sure where that link came from. The Class is in /def rather than /data: http://environment.data.gov.uk/def/bathing-water-quality/LatestSampleSlice The slice itself is: http://environment.data.gov.uk/data/bathing-water-quality/in-season/slice/latest > or http://environment.data.gov.uk/id/bathing-water/ukk1202-3600 Final 0 has got lost: http://environment.data.gov.uk/id/bathing-water/ukk1202-36000 Dave
Received on Saturday, 7 December 2013 17:25:49 UTC