Re: Review UCR w.r.t. SSN

Hi-

Thanks (and kudos!) to Rob for working through the UCR doc. Lot's of useful
comments and suggestions. From a BP (editor's) point of view, I thought I
would respond to a few of them.

I’ve not covered the ‘macro’ issue(s) about UoM etc. in this response …
there’s a separate thread and I’m also still trying to put all the pieces
together in my head! Will add more later in the separate thread.

...

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


In the BP doc we don’t assert an explicit requirement. We do, however, say
in the Audience [1] and Scope [2] sections respectively:

“We expect readers to be familiar both with the fundamental concepts of the
architecture of the Web [WEBARCH <http://w3c.github.io/sdw/bp/#bib-WEBARCH>]
and the generalised best practices related to the publication and usage of
data on the Web [DWBP <http://w3c.github.io/sdw/bp/#bib-DWBP>].”

“All of the best practices described in [DWBP
<http://w3c.github.io/sdw/bp/#bib-DWBP>] are relevant to publication of
spatial data on the Web. Some, such as Provide data license information
<http://www.w3.org/TR/dwbp/#DataLicense> need no further elaboration in the
context of spatial data <http://w3c.github.io/sdw/bp/#dfn-spatial-data>.
However, other best practices from [DWBP
<http://w3c.github.io/sdw/bp/#bib-DWBP>] are further refined in this
document to provide more specific guidance guidance forspatial data
<http://w3c.github.io/sdw/bp/#dfn-spatial-data>.”

That said, neither of these sections are normative.


> 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


In the email thread seeking to clarify “*describing properties that change
over time*” [3] I introduced the option of attaching a time-series of
values (a simple coverage) as a property of a spatial thing. One of the
examples I cite is the “GPS position of a fishing vessel” … or, indeed,
anything that you might want to track.

Do you think that this approach is suitable for “moving features”?

Arguably, the OGC Moving Features specification (OGC #14-083) [4] follows
this pattern, albeit with specific terminology such as “foliation”, uses a
“trajectory” element to describe the position plus the ability to add
varying attributes (such as orientation or rotation) alongside the tuples
in the trajectory. OGC also offer a CSV-format “compact encoding” (OGC
#14-084). I think that Moving Features conveys the same information as
would be achieved by embedding a time-series coverage as a property of a
feature, it just makes some different encoding choices.


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

“Assert known relationships” has been merged with “Publish links to related
resources” [6] as we felt that these were two sides of the same coin (so to
speak); essentially, we’re suggesting that if a data publishers knows
something about a spatial thing (and it is important to them) they should
state that explicitly rather than assuming that the data consumer can
reconcile these facts, perhaps using some spatial correlation.

(note: in Linda’s alignment of the SDWBP doc with DWBP, all the best
practices have been renumbered!)


> 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 […]


I think that the interrelations of our work items is a good topic for
discussion at TPAC … I’ve added it to the BP agenda scratch page on the WG
wiki [7]


> 17) 5.41 Spatial vagueness

> only linked to SSN, is a general BP issue.


We think that this is successfully incorporated into best practice “Provide
a minimum set of information for your intended application” [8]. We state:

“A 'place' may have an indistinct (or even undefined) boundary. It is often
useful to identify spatial things even though they are fuzzy. For example:
'Renaissance Italy' or 'the American West'.” etc.


HTH, Jeremy


[1]: http://w3c.github.io/sdw/bp/#audience

[2]: http://w3c.github.io/sdw/bp/#scope

[3]: https://lists.w3.org/Archives/Public/public-sdw-wg/2016Aug/0138.html

[4]: http://docs.opengeospatial.org/is/14-083r2/14-083r2.html

[5]: http://docs.opengeospatial.org/is/14-084r2/14-084r2.html

[6]: http://w3c.github.io/sdw/bp/#entity-level-links

[7]:
https://www.w3.org/2015/spatial/wiki/Meetings:F2F4-best-practice-agenda-scratch-pad


[8]: http://w3c.github.io/sdw/bp/#minimum

On Thu, 25 Aug 2016 at 23:08 Rob Atkinson <rob@metalinkage.com.au> wrote:

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