Re: Review UCR w.r.t. SSN

Hi Rob,

Thanks for the thorough analysis!
Further comments inline:

On 24 August 2016 at 14:53, Rob Atkinson <rob@metalinkage.com.au> wrote:

>
> 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.
>

I have just made a new thread
<https://lists.w3.org/Archives/Public/public-sdw-wg/2016Aug/0181.html>
about if and how we should include those topics in the UCR doc.

>
>
> 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).
>

I am afraid don't understand that comment. The SDWWG UC&R document is a
document about use cases and derived requirements for spatial data on the
web. DWBP is a collection of best practises for general data on the web.
Why should a relationship be clarified? Our BP document will be highly and
explicitly related to the DWBP document. That makes sense, they are the
same kind of document. What could be the relationship between our UCR
document and the DWBP and why should that relationship be clarified?

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

Again this seems to be about requirements for data on the web in general
versus requirements for spatial data only. I think it is a good thing that
the UCR document is scoped to spatial data only. Besides that, probably the
BP document will recommend following the DWBP. It is being rewritten as a
spatial extension of the DWBP. Isn't that sufficient?

>From a slightly different viewpoint: I think the UCR doc is about what is
needed, not so much how that should be accomplished. The how should be
specified in the deliverables for which the requirements are meant.

>
>
> 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.
>

Yes, some requirements are phrased from the supply point of view instead of
from the demand point of view. I think it would not hurt to rewrite the
former requirements, and in fact it would improve them. So, for instance,
we would get:

For the Sensor metadata requirement
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SensorMetadata>
:
It should be possible to request the metadata about the sensors producing
the observations.

For the Sensing procedure requirement
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SensingProcedure>
:
It should be possible to request the procedural description of a sensing
method.

How is that?



>
>
> 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,
>

It is about not reinventing the wheel, to ensure backward compatibility and
to look at existing work within the OGC and W3C realms specifically. I
think the requirement is not to tightly phrased on purpose, to give the
teams some freedom in which way they want to achieve ccompatibility with
existing practises. Is that all right or do you think we need to change the
wording? Anyway, your recommendation to the SSN editors is apt.

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

This goes back to the general question of if and how to link general (BP)
requirements to specialized deliverables like SSN and Coverages. I am OK
with adding links to SSN and Coverage to these requirements, but I will
await the outcome of discussion in this thread
<https://lists.w3.org/Archives/Public/public-sdw-wg/2016Aug/0182.html>.


>
>
> 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.
>

My thinking is that the editors of the SSN and Coverage deliverables will
naturally pick a sensible way of expressing time. Just like they will pick
sensible ways of modularization, provision of documentation and using data
types. But these are general things that need not be made explicit in a set
of requirements for spatial data.

If we would link this requirement to SSN and Coverages the requirement
would have two different meanings. As a requirement for the Time
deliverable, it says that the Time ontology should allow for representation
of dates, timestamps and durations - three different types of temporal
data. As a requirement for SSN and Coverages it would mean something else,
perhaps something like: please use a good standard for the temporal bits in
your specification.

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

 Well, the Dynamic sensor data requirement
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DynamicSensorData>
is
a requirement for the SSN deliverable and the Streamable data requirement
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#Streamable>
is a requirement for the BP deliverable. So they are not quite the same,
and it is imaginable that the requirement will be met in different ways.

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

I don't know, but isn't the trajectory of a satellite just a special kind
of CRS? It seems to me that the best way of encoding location data is out
of scope for SSN.

>
>
> 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.
>

Originally the requirement was to be able to model humans as sensors, e.g.
"this morning I saw a UFO hovering over the Eiffel Tower", "I am hearing a
lot of air traffic noise at the moment". I think it is about the wish to
transform such observations into  SSN data. So it says nothing about the
wish to identify the user. That could be considered as a separate
requirement, but I'd say that requirement would then be too general to be
in scope.

>
>
> 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,
>

I am afraid I don't understand this comment. Did you mean the requirement
title is too general? I can see that. Would changing the title to something
that better describes the requirement resolve this issue?

As for linking a requirement in the UCR doc to a best practise in the BP
doc: I think that would create an existential paradox: the BP doc is
supposed to be based on the UCR doc.

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

I can see how a link can be made. But it seems to me  that link should be
made within the SSN group/deliverables. I think this is an example of how
best practices in the BP doc could be viewed as requirements for the SSN of
Coverage deliverables, the topic of this thread
<https://lists.w3.org/Archives/Public/public-sdw-wg/2016Aug/0182.html>.

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

So we can leave it as it is? Or do you propose to remove the requirement?

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

Do you think this should be captured in a new SSN requirement (something
like "sensor data should conform to the standards or best practices
relevant type of data collected or used in description of a sensor")?

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

Actually I think this requirement is too general to be included in the UCR
document. But if we keep it, it does make sense to relate it to the other
deliverables too.

I have just create ISSUE-75
<https://www.w3.org/2015/spatial/track/issues/75> to formally address this
issue.

>
>
> 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)
>

I think in general SSN (and Coverage too) should aim to do things
consistent with the BP.

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

I notice that of the mentioned requirements, Spatial metadata
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialMetadata>
is
a BP requirement.

Is this comment about the UCR document possibly needing some change? Or is
it about mutual BP-SSN awareness and collaboration?


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

We are discussing this requirement in ISSUE-30
<https://www.w3.org/2015/spatial/track/issues/30>. But for now I have
related the requirement to the BP.

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

You are probably right. Perhaps I should change the title too. How about
"Satellites and SSN", to keep it short and to the point?

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

Why is this not an SSN requirement? Unlike say OWL Time or the spatial
ontology there is a real need for working with subsets of SSN that can be
validated and this requirement captures that.

Do you suggest we could remove the this requirement from the UCR doc?


>
> 20) 5.45 Subject equality
> see #19
>
> 21) 5.50 Temporal vagueness
> does this need to be a SSN requirement too?
>

I don't think so. If there is a need to have temporal vagueness in sensor
data (which could be the case with human as sensors) then it will be made
possible if the requirement is met by OWL time. And of course SSN will use
OWL Time, won't it?

>
>
> 22) 5.56 Valid time
> SSN requirement too?
>

I don't think so. It is not even in scope for the Time deliverable, really.
If SSN uses OWL time for its temporal components the problem will be
handled by the Time deliverable.

Greetings,
Frans


>
> ....
>
>
> 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
>
>
>