Re: Review UCR w.r.t. SSN

Thanks Frans

I wont go into any more detail myself yet - let others comment first.
There are of course two audiences - UCR editors and SSN, and some of the
comments are just about helping SSN folk to focus on the key parts to test
whether they are comfortable. The review was specifically requested to
ensure "completeness" from the SSN - as in are all the requirements assumed
by the SSN work expressed?

I think the wider debate about scope needs to happen first - in the SSN
group (particularly) there is the working premise that there must be a
driving requirement in the UCR for everything considered - and this isnt
limited to the spatial aspects. Or even spatio-temporal. I think the thing
that needs to be scoped as far as possible to spatio-temporal is the BP, in
UCR the scope is going to be the user concerns that have a spatial aspect -
not just the spatial aspect of the UC.

so - one key question is whether its a _requirement_ that SSN, Coverages
are consistent with each other and/or the BP? I think most people are
working on this assumption - but
AFAICT the implication is it needs to be in the UCR to be a formal
requirement. If the SSN and wider views are at odds here then we need to
resolve this first.

Furthermore on most calls in SDWPB and plenary I have attended we have
re-affirmed that where DWBP does not provide useful guidance on a general
issue, critical to spatial, then we will need to address it.

 I think we can only push this back to the wider group to make a
determination and record a coherent position (that can then be cited in the
UCR) about the scope and its rationale.

Other than that I think many of the concerns I raised are either simply to
suggest that both SSN or BP deliverables are relevant for many of the
requirements.

Rob

On Fri, 26 Aug 2016 at 00:45 Frans Knibbe <frans.knibbe@geodan.nl> wrote:

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