Re: Getting started with Best Practice document

Hello Jeremy,

I have placed a few comments inline...


2015-07-07 10:59 GMT+02:00 Jeremy Tandy <jeremy.tandy@gmail.com>:

> 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
>
> True, but I can imagine that publishers also want to get something out of
all the trouble they are taking. For example. a publishers may want many
consumers to discover the data because that increases possibilities for
improving data quality (e.g. by reporting or fixing errors, or by enriching
data (adding links)).



> … 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}
> ?
>

I think the division between consumers and publishers makes sense, but I
don't know if the causal relationship needs to be stressed. Data publishers
could have other drivers besides pleasing consumers. Nonetheless, it makes
a lot of sense to match consumer requirements to recommendations for
publishers.

>
> 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?
>
> Why do requirements need to be grouped?

The way I picture the BP deliverable is that it will basically be a set of
recommendations. Different recommendations could be chained to form a
recipe for doing something (publishing a data set, building a data driven
web application, ...). A recommendation could be directly linked to a
requirement from the UCR document, which in turn relates to one or more use
cases. In this perspective, what would be the added value of grouping
requirements, or distinguishing them based on their granularity?


>
>    - 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 :-)
>
> What would be wrong with having overlap? If a single best practice or
recommendation can be related to many different use cases, wouldn't that
strengthen the best practice?

>
>    - 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 …
>
> In my opinion that is something that we should have done (or should be
doing) in the UCR work: make sure that BP requirements are in scope for our
working group. Of course some requirements may have slipped through the
scoping filter. In such cases I think the BP editors should notify the UCR
editors because that may mean that the UCR document needs to be revised.



>
> —
>
> 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?
>
> I hope that in the process of making the UCR document much of the
 filtering and analyses of use cases that is necessary for the BP work has
already been done. The outcome of that process is the set of BP
requirements, which I would consider the basis for the BP work. Those are
the items that need to be ticked off. Requirements are related to multiple
use cases. There is a N:N relationship between use cases and requirements.
So that gives an idea of commonality. As for completeness, I hope that has
been checked in all the discussions we have had about the requirements.

Of course it is possible the UCR document is not perfect yet. In fact it is
likely, as indicated by the various unresolved issues. I think it is the
job of the UCR editors to make sure the UCR document is a good starting
point for the other deliverables. So please let us know if you see a gap
between the BP deliverables as they are presented in the UCR document and
what you need to create the BP deliverable.


Regards,
Frans


>
> —
>
> [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
>
>


-- 
Frans Knibbe
Geodan
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl
disclaimer <http://www.geodan.nl/disclaimer>