Re: Getting started with Best Practice document

I will be in the call tomorrow.


Best,

Payam


________________________________
From: Kerry Taylor <Kerry.Taylor@acm.org>
Sent: 07 July 2015 12:06
To: Jeremy Tandy
Cc: SDW WG Public List; Barnaghi P Dr (Electronic Eng); Mcgibbney, Lewis J (398J)
Subject: Re: Getting started with Best Practice document

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<mailto: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:14:38 UTC