RE: Getting started with Best Practice document

I like Jeremy’s suggested approach of the publishers vs consumers, and the narratives/user stories structure.

I guess most requirements from a publisher's point of view are rooted in meeting the requirements of a consumer. There will be cases where a publisher needs to put their data on the web primarily to meet a legal requirement (eg INSPIRE compliance...), but most would want their data to be discovered and used by real end users.

So, thinking along the narrative of an application developer or data scientist harvesting data from the web, something that we may be missing in the requirements is a way for a consumer to identify which datasets follow the best practices (claim to follow? or pass a compliance test against?), particularly if the best practices end up involving any default values for CRS or other datums.

I will be on the call today...

Cheers,
Rachel


From: Jeremy Tandy [mailto:jeremy.tandy@gmail.com]
Sent: 07 July 2015 09:59
To: SDW WG Public List; Payam Barnaghi; Mcgibbney, Lewis J (398J)
Subject: Getting started with Best Practice document

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


________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
________________________________