W3C home > Mailing lists > Public > public-sdw-wg@w3.org > July 2015

Re: Getting started with Best Practice document

From: Kerry Taylor <Kerry.Taylor@acm.org>
Date: Tue, 7 Jul 2015 21:06:51 +1000
Message-Id: <BA8B85B2-6980-48EA-9355-CF0DC20BCE53@acm.org>
Cc: SDW WG Public List <public-sdw-wg@w3.org>, Payam Barnaghi <p.barnaghi@surrey.ac.uk>, "Mcgibbney, Lewis J (398J)" <Lewis.J.Mcgibbney@jpl.nasa.gov>
To: Jeremy Tandy <jeremy.tandy@gmail.com>
Payam and/or Lewis, can you be in the call tomorrow to lead this discussion?
Kerry



> On 7 Jul 2015, at 6:59 pm, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
> 
> Hi-
> 
> At last week's call, I took an action to think about how we can identify "common themes" within the use cases that we can use as the basis to structure the best practice document.
> 
> I've jotted down my thinking (below) to share ahead of the call tomorrow- which unfortunately I cannot make (and I'll have very limited time for W3C SDW until Friday now). Hopefully it makes sense ... 
> 
> Critique and alternative approaches welcome.
> 
> Jeremy
> 
> ---
> 
> In the editor's call last week, we suggest that the BP document should be organised around narratives; where each narrative covers a “common practice” - or more likely a set of practices used to achieve a common outcome.
> 
> I think it is these _common outcomes_ that will be most useful to the audience in navigating this BP doc; they are likely to start from the perspective of “I want to achieve {this}” … they need to be able to find {this} in the table of contents of the BP document
> 
> Publishers vs consumers …
> publishers have the control in how the spatial data is presented on the web
> consumers are the ones who realise value from the spatial data on the web
> … we need to get publishers to adopt (best) practices that might make their life a little more complex- but enable the consumers to do more with their data; accruing greater value to their effort of data collection/curation and publication.
> 
> Do we need to segment the problem space as:
>     (i) data consumers want to do {this}; so
>     (ii) data publishers needs to do {that}
> ?
> 
> Looking at the Data on the web BP doc [1] their pro-forma for a Best Practice maps onto this approach. They have an ‘Intended Outcome’ section (which may be where we describe what data consumers want to do) and a ‘Possible Approach to Implementation’ section (which is where you would describe what publishers need to do to enable that intended outcome to occur).
> 
> —
> 
> Synthesis of requirements:
> the 56 requirements are of different granularity … for example: '5.1 Bounding box and centroid’ [2] talks about a very specific thing, whereas '5.10 Discoverability’ [3] talks about achieving an outcome. In fact, you might use a bounding box when making spatial data discoverable …
> my gut feeling is that we need to group these requirements into ‘buckets’ … I’m not sure how many or what buckets there are- but if we find ones like '5.10 Discoverability’ that talk about achieving some kind of outcome, then these might create a framework into which the other requirements fit? 
> these high-level outcomes _should_ relate back to the narratives that we propose to use to organise the BP document … IMO, it would be good if each  of the 56 requirements was related to one and only one of the top-level narratives. This may not be possible, but we should seek to minimise overlap … which may well help us partition the problem space :-) 
> we also need to cross-reference against the Data on the web BP doc [1] to make sure that we are not duplicating any of their work; we need to be looking at the issues specific to spatial / temporal data, coverages and sensor data … 
> 
> —
> 
> Synthesis of use cases:
> given that we have 48 use cases, it is difficult to determine if we’re covering all the relevant issues … there’s too many for a quick glance!
> the majority of the use cases are based around specific examples- which is good because it makes them _tangible_ …
> however, my intuition is that there will be common themes (processes / actions etc.) that are duplicated amongst those specific examples … we need to work through the existing use cases to identify the common activities … basically, we’re trying to infer the generic case from the specific- and see how many times that occurs
> … 
> this sounds pretty similar to looking for requirements within the use cases … WHAT DO THE UCR DOC EDITORS THINK? Have they already identified the commonality when establishing the requirements? 
> 
> —
> 
> [1]: http://w3c.github.io/dwbp/bp.html
> [2]: http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#BoundingBoxCentroid
> [3]: http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#Discoverability
> 

Received on Tuesday, 7 July 2015 11:07:24 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:17 UTC