RE: Review UCR w.r.t. SSN

Rob,

I think most of your suggestions are sensible and support them.

In particular, I strongly support 3, 6 ,7, 9, 10, 14, 16, 17, 21 and 22.

I do not agree on your point 11: moving features and properties that change over time (on static features) are different enough that they should be separated, unless there is some neat, elegant, simple solution (but see  http://www.brainyquote.com/quotes/authors/h/h_l_mencken.html  ).

Chris

From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Wednesday, August 24, 2016 1:53 PM
To: SDW WG Public List
Subject: Review UCR w.r.t. SSN


Review of UCR document [1]

(https://www.w3.org/2015/spatial/track/actions/195)

first a general note - the effort made to cross reference Use Cases to
requirements and requirements to deliverables is well worth it - kudos for
Frans.  The review here looks worse than it is - mostly its about
leveraging this structure to include all the relevant cross-references.

This review is necessarily limited by my own limited experience in sensors,
which is more with practical implementation of systems dealing with
aggregated results, rather than sensor design and deployment in general.
However UC from such perspectives seem fairly well represented, relative to
the concerns of users dealing with the results of sensors.

I have also reviewed from the pragmatic perspective of "is the requirement
testable?" - or if i was asked to implement something conformant to these
requirements could i contemplate a fixed price contract :-)

we have raised and discussed the question of UoM, precision and accuracy.
These are vital to spatio-temporal, but general issues. They have not
however been covered in the DWBP - so as per the SDW plenary (i havent
looked up minutes sorry) we have agreed we will need to include treatment
on behalf of the spatial domain. As such they need to be reflected in the
UCR using the terminology used in the wider spatial domain.

Perhaps this can be done by widening the scope of

5.9 Determinable CRS
"For users of geometric spatial data it should always be possible to
determine which coordinate reference system (CRS) is used."

to perhaps
5.9 Determinable attributes of spatio-temporal values

For users of spatial or temporal data it should always be possible to
determine which reference system (CRS or TRS) and unit of meaure (UoM) is
used for a numeric value. It should also be be possible to determine if
precision and accuracy are specified. [link to
https://en.wikipedia.org/wiki/Accuracy_and_precision ]?  Note such metadata
may be attached to individual values or metadata for collections. in the
latter case, it implies that the collection metadata can be determined for
a given data instances.


General suggestion:  cross reference the deliverables to where these will
be published. If necessary put in a link to the working draft now and
update on final publication?

I've looked at each requirement - i think that the UC here are covered:
https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Summary_wrt_UCRs_for_SSN

- but it would be good for everyone to look at it using their own knowledge
of where things get tricky in specific cases.

Having got that out of the way - a lot of comments on individual cases (but
there is nothing very earth shattering in here - mainly some additional
cross-reference suggestions)

1) The first issue is one of scope - from comments in the meetings there
appears to be some disparity of views here. In particular, the relationship
of the UCR to the more general Data on the Web Best Practices [2] needs
clarification IMHO, (and this flows to SSN requirements regarding
requirements for conformance with general DWBP).


2) should there be a _requirement_ to follow DWBP ?  In the BP document the
cross references are extensive and made explicit.

3)  : Proscriptive vs aspirational requirements:

The sensor network requirements tend to be phrased:
"it should be possible to include/attach" (e.g. 5.35 Sensor metadata, 5.36
Sensing procedure)

whereas many of the more general requirements have evolved to be more
proscriptive:
"There should be recommended ways for describing " (e.g. 5.38 Spatial
metadata)

I prefer the style of requirement used in 5.9 Determinable CRS :

"For users of geometric spatial data it should always be possible to
determine which coordinate reference system (CRS) is used."

user determination is more powerful than attachment - as it constrains the
practices to something common to a community at least, rather than an
ad-hoc decision by each data publisher.

4) 5.3 Compatibility with existing practices
I'm not sure how to interpret "compatible" here - but some interpretation
of this needs to be made by the SSN with regards to compatibility with any
existing or future things - such as IoT - I recommend the SSN editors pay
attention to this and make sure they are comfortable they can make such a
statement,

5) 5.6 Crawlability (and 5.11 Discoverability)
Discoverability of sensors and data was one of the driving use cases for
SSN, but this has not reflected into a requirement on SSN
I suspect that it could be linked in via UC 4.38 Metadata and search
granularity and 4.43 Improving discovery of spatial data on the Web

6) 5.8 Date, time and duration
currently linked to Time, but i think should be lined to SSN and Coverages,
as time is a prime concern.
I also think the requirement needs to be strengthened as per issue 3 - an
image of a cuneform tablet showing the time conforms to the requirement "It
should be possible to represent dates, time and duration." - as would a
sensor that used a different time encoding syntax every time it reported a
time, or a dataset that used a random property for time for each record,
but none of these would meet BP expectations I think, so a more
proscriptive approach is required, and in IMHO we should _require_
consistency between approaches in time, coverages and SSN, conformant to a
more general BP.

7) 5.12 Dynamic sensor data (and 5.44 Streamable data)
This is fine - but reflects issue 1 - this is a general requirement for
DWBP handing time varying and streaming data.  ([2] DWBP: Best Practice 20:
Provide real-time access)
Can these two be merged?

8) 5.15 Georectification
Does this need to link to SSN to handle things like satellites and other
trajectory or viewpoint defined sensing?

9) 5.17 Humans as sensors
does "represent observations" cover the requirement to identify the user,
or the class of user - or whatever is the testable requirement here? Do we
need a standard way - should it be something more like "it should be
possible for the user to determine the human responsible, or the mechanism
by which the human is identified in case privacy concerns requires
anonymous reporting"

such a requirement has a stronger requirement than using an occasional
ad-hoc reference in a comment to the user for example.

10) 5.20 Lightweight API
I know this has been discussed a bit - but we have a generic BP title and a
very specific description. I think the issue here is that this should be
linked to other deliverables - i.e.
SDWBP Best Practice 28: Expose entity-level data through 'convenience APIs'
[3].  This in turn will aid understanding of the SSN requirement,

11) 5.25 Moving features
same issue as #10 - should be linked to sdwbp: Best Practice 11: How to
describe properties that change over time

12) 5.27 Nominal observations
linked to SSN only, but is a general DWBP issue

13) 5.30 Observed property in coverage
This probably applies to SSN where the result is a coverage.  Maybe a
general requirement that SSN conforms to the requirements relevant to the
type of data collected or used in description of a deployed sensor

14) 5.32 Quality metadata
This is linked to coverages, but also applies to SSN

merge with 5.52 Uncertainty in observations ?

15) 5.34 Sampling topology
Should this include the requirement that SSN does this in a way consistent
with BP? (sdwbp: Best Practice 13: Assert known relationships)

16) 5.35 Sensor metadata, 5.36 Sensing procedure (and 5.37 Space-time
multi-scale, 5.38 Spatial metadata)
These seem to be special cases of broader requirements - probably need to
reference that. Broader issue is where we want BP to refer to SSN - does
this meant there needs to be an explicit requirement that SSN provides the
means to define these things in metadata according to sdwbp: 5.38 Spatial
metadata or  dwbp: Best Practice 1: Provide metadata ?

17) 5.41 Spatial vagueness
only linked to SSN, is a general BP issue.

18) 5.42 SSN-like representation
Also a requirement for SSN

19) 5.43 SSN profiles
Raised by SSN probably because its necessarily going to be a complex model
- but its not a SSN specific requirement. I think this should be a general
requirement on dwbp: Best Practice 1: Provide metadata - the ability to
identify whatever profiles of relevant metadata standards are used for
different aspects. This can also applies to the data - what speicfic
profiles of more general data standards apply to the data is vital
information.

 (note this provides one way of handling requirement 5.45 Subject equality

20) 5.45 Subject equality
see #19

21) 5.50 Temporal vagueness
does this need to be a SSN requirement too?

22) 5.56 Valid time
SSN requirement too?

....


1.  http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html
2.  https://www.w3.org/TR/dwbp/

3. https://www.w3.org/TR/sdw-bp/#convenience-apis