SSN Wish List

See also: https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN

Wish list

This is a place to add your own issues/desires for the SSN deliverable. Please try to attach your name to it. See the first issue (Grab Bag) as a template contributed by Kerry. Feel free to build on those things already within "Grab bag" by extending the text there, but please also attach your name to that suggestion/comment/improvement/gripe. If you have a fresh suggestion not covered already in "grab bag" then create a new section with your name on it.

Grab bag

Contributed by: Kerry Taylor

This is a list of things I have collected from many people about things that should be done to the SSN ontology. Most of it came from discussion at the SSN workshop at ISWC October 2014, where around 35 people attended. Some is drawn from the SSN community group mailing list, and some is my own thoughts. I'm afraid my notes are not good enough to properly attribute most of them. I'm also afraid that there is rather a lot.... and I apologise for anything I have been told but lost or misrepresented: my hand note-taking is illegible to everyone including myself.

Modularity

Rarely does anyone use all aspects of the ontology. A conceptual modularity was produced here (Lefort and Garcia-Castro): [1], and later a file split was done (Compton) roughly along those lines. I think this is an excellent place to start and some comments on that work have been made on the SSN-CG mailing list. The down side is that maybe it makes using SSN even harder, because you have to think hard about which files you need.

Simon Cox has recently described a light-weight OWL implementation of the O&M model which might be considered as an alternative to the 'Skeleton' module from Lefort and Garcia-Castro. It simplifies the core still further by omitting the SensingDevice, SensorInput, SensorOutput and Sensing classes, which may still be too much for some classes of user.

DUL dependency

See above "modularity". The modularity split also removed the dependency on DUL so that no DUL terms are imported unless you want to, and an intermediate file is used to align the SSN terms with the DUL terms.

Multilanguage

Include non-English versions of all the annotation properties: Catherine Roussey (not in the group) has volunteered to do this for French. I (Armin Haller) can do it for German.

CSV data encoding

Show how to use a simple CSV encoding of observed values with SSN (this maybe all solved by the CSV on the Web Working Group). Or a tool to translate CSV to an SSN/RDF encoding. This should also adhere to the new CSV on the Web recommendation (https://www.w3.org/2013/csvw/wiki/Main_Page)

JSON data encoding

OM-JSON - a JSON encoding of Observation and Sampling Features - has recently been published as an OGC Discussion Paper. A SOS-ish implementation is hosted by the Irish Marine Institute sample query.

OM-JSON uses a geometry serialization that matches GeoJSON.

Note that JSON has notion of ordered lists, which may be nested as lists-of-lists, which allows ordered lists of coordinates and time-series. In RDF ordered lists are a heavyweight structure (linked list) and nesting is essentially impossible. This might challenge JSON-LD (which is essentially an RDF serialization) for spatial/sensor applications? -- Simon Cox 2015-02-12

More help for observed value encoding

SSN is rather off-hand about how to attach measurement data values, although the documentation does show at least one way. This is a common source of confusion.

Should we be more prescriptive or at least helpful? See comment for "CSV data encoding" above, and we should also seriously consider the relationship to the RDF datacube which presents a standard way for encoding time series RDF data http://www.w3.org/TR/vocab-data-cube/. A combination of SSN and Datacube has been done a few times (e.g. Lefort et al) but it might work better with adjustments to SSN. There is also emerging work from the OGC to watch TimeSeriesML Press release October 2014 and our own OWL time deliverable.

Many domains already have standards and controlled vocabularies in place, encompassing precision, accuracy and units of measure, but these are not fully exposed to the Web.

Activation

For IoT-style devices where sensing may be closely linked to acting. This may be a big challenge in the loosely-coupled Web architecture, but this may not stop us from defining an ontology around it, subject to important use cases. There is one here.

Network Structure

Contributed by: Manfred Hauswirth to the SSN-CG

Plus we need extension for energy and network structure. This is something you come across when working on practical cases immediately and it is fairly straight-forward but necessary. We extended SSN in SPITFIRE (www.spitfire-project.eu) in these respects and can provide this as a starting point for discussions.

SPITFIRE in my opinion is particularly interesting (shameless self-promotion) for providing input to SSN as we combine RDF, ontologies and REST (6LowPAN and CoAP - currently being standardized by IETF) in this project to make sensor networks look like normal Web resources, i.e., development should boil down to the same abstractions like normal Web development - but there is a lot of work you need to do under the hood to support this in a nice way.

CoAP will be the standard. The IoT people are going for REST. Ontologies in IoT are all over the place. We need to support this from SSN's side and get the necessary uptake outside the core Web community.

Humans as sensors

Examples contributed by: Chris Little

This is not incompatible with SSN already, but nor is it well developed. This could be important to citizen-science use cases, and maybe IoT as well.

For example, many citizen-scientists are expert at identifying animals and plants, and take part in regular biodiversity surveys and phenomena recording.

Another example is the observation of wind speed, ostensibly an objective measurement, but very commonly observed by a human comparing phenomena against a well-calibrated scale, such as State-of-sea: "Some airborne spray is present", or land conditions: "Large tree branches in motion" both of which indicate a "Strong Breeze", Force 6, 22-27 knots.

Systems, Platforms and Deployment

Already covered in SSN, but does it need more detail?

Validation

Can we help users by providing validation tools that reflect the intended or usual use of SSN (beyond basic OWL validation). There is a contribution here (Kolozali et al) A Validation Tool for the W3C SSN Ontology based Sensory Semantic Knowledge.

Location

SSN is rather non-prescriptive about modelling location. This working group should be the right time to tighten it up, either by extension to the vocabulary or by best practice advice. We must do this!

Mobile

Is SSN good enough for this use case? Certainly it *can* be done, but should SSN be more helpful? This would at least require better advice on modelling location (see "Location" above), especially moving location where the location will vary per observed value (or perhaps *is* the observed value), but may require deliberate extension.

Examples

Examples of SSN encodings are highly desirable for new users. This should include advice on the constellation of ontologies around the edges that have become popular in association with SSN e.g. for units of measurement. Should also collect references to and/or develop SSN-related tools.

Scope and Overlap

Contributed by: Chris Little

The OGC conceptual model Observation & Measurement (O&M), and associated standards such as SensorML, Sensor Web Enablement (SWE), Sensor Planning Service (SOS) and Sensor Observation Service (SOS) seem to cover a similar domain to SSN. The areas of overlap needed to be clarified, and the unique features of each need to be identified, with examples showing appropriate (and possibly inappropriate) use.

Examples showing how both the OGC standards and SSN could be used together could be useful.

Uncertainty

How should uncertainly of data values be represented? (note that uncertainty around sensor capability is well covered already)

Simplify

Is SSN too complicated for most use cases? Can this addressed by cutting back, modularity, or documentation including examples and design patterns to deal with common needs? What a bout a SSN-lite? This should also include an SSN-lite with labels/identifiers that are shortened for WoT devices with limited memory.

Success Stories

(also called use cases) as a way to understand whether SSN is the right tool for the job

Tutorial Introduction to SSN

and documentation for new users in general. Make a video version of the tutorial. (Given the expected user group for all the outputs of this WG, this idea should really extend to all the deliverables of the WG)

Reasoning and other Inference

SSN uses lots of OWL that enables reasoning support for clever stuff. This should be explained (how to leverage it?).

Modelling of Observations as Results of Events, not Events themselves

The choice of base classes for alignment of SSN with DOLCE creates an incompatibility with OGC's O&M. This is emphasized in recent papers discussing alignment with W3C PROV-O (see discussion [http://ceur-ws.org/Vol-1401/paper-05.pdf Sensor Data Provenance: SSNO and PROV-O Together at Last] and Ontology for observations and sampling features, with alignments to existing models). Arguably this points to a fundamental inconsistency between SSN and O&M. Given the distinction between records and events, ssn:Observation may not actually be the same concept as om:Observation. - SCox

Sampling Features and Specimens

-- Contributed by Simon Cox 2015-02-09

The OGC O&M also includes a model for 'sampling features'. These are things like stations, specimens, transects, cross-sections, pixels which are more-or-less ubiquitous in real observational exercises. Most analyses of observational systems have found that it is essential to include a treatment of the sampling feature and its relationship with the ultimate feature-of-interest in order to capture all the necessary semantics. A recent paper in to Semantic Web Journal describes a lightweight ontology for Sampling Features, which is linked to PROV-O.

Nits and infelicities

1. In http://www.w3.org/2005/Incubator/ssn/ssnx/ssn#Sensor the documentation of Sensor includes the comment "(which is thus wider than the O&M concept)" which I think is incorrect, and possibly was not intended. In the context of the comment I suggest "which is thus wider than the SensorML concept)" might be correct.