Warning:
This wiki has been archived and is now read-only.
View source for SSN Wish List

Jump to: navigation, search
You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in one of the groups: Users, 106, 75471-chairs.
You can view and copy the source of this page.
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 ===
<small>Contributed by:</small> 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  [http://knoesis.org/ssn2014/ 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): [http://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/images/OntStructure-Overview.jpg],
and later a file split was done [https://lists.w3.org/Archives/Public/public-ssn-cg/2012Jun/0000.html (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.

[https://www.w3.org/users/1796 Simon Cox] has recently described a [http://www.semantic-web-journal.net/content/ontology-observations-and-sampling-features-alignments-existing-models-0 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====
[https://portal.opengeospatial.org/files/?artifact_id=64910 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 [http://spiddal.marine.ie/?REQUEST=GetObservation&SERVICE=SOS&ACCEPTVERSIONS=1.0.0&OFFERING=ie.marine.data:instrument:wetlabs.ecoflntu.3137&EVENTTIME=2016-01-27T08:00:00+00/2016-01-27T08:55:00+00&observedProperty=vocab.nerc.ac.uk/collection/P01/current/CPHLPR01/ 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? -- [https://www.w3.org/users/1796 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. [http://ceur-ws.org/Vol-904/paper10.pdf Lefort et al]) but it might work better  with adjustments to SSN.   There is also emerging work from the OGC to watch [http://www.opengeospatial.org/pressroom/pressreleases/2116 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 [http://dl.acm.org/citation.cfm?id=2459293 here].

==== Network Structure ====
<small>Contributed by: Manfred Hauswirth to the SSN-CG</small>  

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 ====
<small>Examples contributed by: Chris Little</small> 

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) [http://knoesis.org/ssn2014/paper_7.pdf 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 ====
<small>Contributed by: Chris Little</small>

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 [http://www.semantic-web-journal.net/content/ontology-observations-and-sampling-features-alignments-existing-models-0 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 [https://www.w3.org/users/1796 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 [http://www.semantic-web-journal.net/content/ontology-observations-and-sampling-features-alignments-existing-models-0 paper in to Semantic Web Journal] describes a lightweight ontology for Sampling Features, which is linked to PROV-O.

=== Nits and infelicities ===

# 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.
Return to SSN Wish List.
Retrieved from "https://www.w3.org/2015/spatial/wiki/SSN_Wish_List"
View source for SSN Wish List

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Navigation

extra links

Tools
