- From: Kerry Taylor <Kerry.Taylor@acm.org>
- Date: Tue, 7 Jul 2015 21:06:51 +1000
- To: Jeremy Tandy <jeremy.tandy@gmail.com>
- 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>
- Message-Id: <BA8B85B2-6980-48EA-9355-CF0DC20BCE53@acm.org>
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