- From: Dave Reynolds <dave.e.reynolds@gmail.com>
- Date: Sat, 07 Dec 2013 15:25:31 +0000
- To: public-gld-wg@w3.org
[Not sure this is the best place to ask since most QB implementors are not in the WG but ...] 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
Received on Saturday, 7 December 2013 15:26:02 UTC