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

Getting started with Best Practice document

From: Jeremy Tandy <jeremy.tandy@gmail.com>
Date: Tue, 07 Jul 2015 08:59:12 +0000
Message-ID: <CADtUq_1pGPYNZrMFWui=LwrEgk6XXOOMOt5WMvkqMd+UuiMryw@mail.gmail.com>
To: 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>
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 08:59:50 UTC

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