Proposals for rewriting SSN

Please contribute proposals for how any restructure for SSN should look. Include proposals for alignment with other well-known ontologies. Include worked examples if you can. Include references to publications where the restructure is explained or used if you can. Include a file of the proposed ontology if you can. Include proposal for "modules" of your ontology if you can. Just sketch the general idea if that is all you have. Pictures are useful. Your contribution here will be leveraged for consideration of a redesign, or design tweak of SSN or possibly just as a "how to" in the primer. Please attach your name to the proposal you make. Please also comment on other proposals here that you did not make -- and attach your name to any comment. Please include a sentence or tow that suggests how this proposal *might* be raised in the FPWD as an issue.

It is not a proposal, but this page on the SSN conceptual modules can support discussions.

This will not be used in our FPWD but will be carefully considered prior to the second PWD.

Design constraints

(Advice from Phil A and agreed by Scott Simmons, https://lists.w3.org/Archives/Public/public-sdw-wg/2016Jul/0120.html)

The principle is, I think, straightforward: any change made to a vocabulary shouldn't break existing implementations. Since we don't know who has an implementation, we can't write to everyone and ask "if we change this will your thing break?" Therefore we have to be cautious.

That's what leads to W3C saying that vocabulary terms may not be deleted or their semantics changed radically. But it only applies at the namespace level. If you have a new namespace, you can do what you like since nothing will break. *However* it's going to be really confusing if some terms in the old and new namespaces are the same but with radically different semantics. So my interpretation is:

Same namespace:

• No deletions.
• No changing or tightening or semantics (i.e. don't add a new domain or range - make a sub class|property and put the new restrictions on that) Deprecation is OK.
• Loosening semantics is OK (so you *can* remove a domain or range restriction since it is extremely unlikely that doing so will break anyone's existing implementation).
• Adding new terms is fine.
• Clarifying existing definitions is OK.
• Adding new translations of labels is expressly encouraged.

Different namespace

• We can be a little more relaxed here. Recall that documents on w3.org are persistent so the original documentation will always be there (at the original URI or redirected from it).
• No need to replicate the whole of the old vocabulary, so no need to include deprecated terms - they are deprecated by not being included in the new namespace.
• Assuming the vocabulary has the same name then terms that appear in both old and new should broadly be the same although semantics can change a little. It's a matter of judgement.
• The case I keep in mind is Dublin Core/DC Terms. dc:creator took either text or a URI as a value - which was confusing. dcterms:creator should take a URI.

Proposal 1 made by whoever for example only

Sentence for FPWD: The SSN should be extended to include a taxonomy of sensor types (this is na example only).
And here is the meat of my proposal. See the highly cited publication. See all these examples documented here and see all these implementations of my proposal in industrial applications etc.

Proposal 2 made by Kerry

Michael Compton made this proposal (recorded in our charter) some time ago. While that proposal makes some sense, I feel it might be too modular. I described it already on our wiki here, where this a diagram to explain how the bits relate to each other. I presented this proposal in a meeting (date TBD). I tried it a few times but ended up needing to bring in all of the modules anyway, so I found the modularisation was unhelpful, and there is a cost with the separate files in understanding which ones you need. In particular the encoding of observation values is left to dul and, with pulling dul out, I think we need to make up for that.

Also I have received lots of comments about how hard it is to attach values. And there is a lot of confusion about how it is meant to be done, out there in the wild. I would like to see a number of alternatives for recording values -- one would point to a datacube structure, another to an iot-lite like "service" interface at least for "current" values, and using dul or another upper ontology could be another. Here is a nice paper (if I do say so myself) that shows how to get very good query performance on large datasets of values using ssn as it is now, using a specialised storage architecture in an industrial application: Stocker et al Emrooz.

My preferred option is to leave ssn very close to what it is now, with dul removed (as already done on the webprotege instance by Armin), some other optional modules added but not imported or included in any way (such as prov, datacube, o&m or semsos, iot-lite, and some other extensions as documented on the wishlist). These would be done by building on ssn, and maybe sometimes importing it, but more often importing only through an "alignment" ontology (like the one Armin built for dul), so that it can be used either with or without the rest of ssn. I would also twiddle the dul alignment a little (in particular change Sensor to be an immediate subclass of Object instead of Physical Object, as discussed at a meeting). I would revisit the representation of observation values in SSN -- but I am short of a firm proposal at present.

Suggested sentence for FPWD

That dul be disentangled from SSN (and not imported) but reconnectable by an alignment ontology fragment. That the representation of observation values be reconsidered in the light of dul removal, and a few options be offered for multiple circumstances. In general, that SSN as we know it know is very minimally altered beyond that.

Proposal 3 made by Sefki

SSN Observations and Feature of Interest

The SSN Ontology provides a vocabulary for describing concepts such as sensors, outputs, observation value and feature of interests. However, sensor observations can be in different format and shape. Therefore, there is room for improvement in the representation of sensor observations taking into account the multimodal sensory data, such as audio, video as well. I have developed an ontology called SAO Ontology [1], which enables people to annotate the observations as data streams (as a matrix), points, and segments based on TimeLine Ontology, PROV-O ontology, and SSN Ontology. This kind of conceptualisation can help the SSN Ontology to represent temporal features as well as different size and shape of data streams. I also think that feature of interest concept needs clarification as it often triggers a lot of discussions among the researchers.

The workflow of the SAO Ontology and its links with the SSN, PROV, and Timeline Ontology.

   @prefix DUL: <http://www.loa-cnr.it/ontologies/DUL.owl#> .
   @prefix ces: <http://www.insight-centre.org/ces#> .
   @prefix ct: <http://ict-citypulse.eu/city#> .
   @prefix daml: <http://www.daml.org/2001/03/daml+oil#> .
   @prefix dc: <http://purl.org/dc/elements/1.1/> .
   @prefix foaf: <http://xmlns.com/foaf/0.1/> .
   @prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
   @prefix muo: <http://purl.oclc.org/NET/muo/muo#> .
   @prefix owl: <http://www.w3.org/2002/07/owl#> .
   @prefix owlsg: <http://www.daml.org/services/owl-s/1.2/Grounding.owl#> .
   @prefix owlss: <http://www.daml.org/services/owl-s/1.2/Service.owl#> .
   @prefix owlssc: <http://www.daml.org/services/owl-s/1.2/ServiceCategory.owl#> .
   @prefix owlssp: <http://www.daml.org/services/owl-s/1.2/Profile.owl#> .
   @prefix owlssrp: <http://www.daml.org/services/owl-s/1.2/ServiceParameter.owl#> .
   @prefix prov: <http://www.w3.org/ns/prov#> .
   @prefix qoi: <http://purl.oclc.org/NET/UASO/qoi#> .
   @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
   @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
   @prefix sao: <http://purl.oclc.org/NET/UNIS/sao/sao#> .
   @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
   @prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#> .
   @prefix time: <http://www.w3.org/2006/time#> .
   @prefix tl: <http://purl.org/NET/c4dm/timeline.owl#> .
   @prefix tzont: <http://www.w3.org/2006/timezone#> .
   @prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
   @prefix wot: <http://xmlns.com/wot/0.1/> .
   @prefix xml: <http://www.w3.org/XML/1998/namespace> .
   @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
   <http://unis/ics/trafficsensor158324> a ssn:Sensor .
   <http://unis/ics/unit2:km-per-hour> a muo:UnitOfMeasurement .
   <http://unis/ics/trafficdataavgspeed001> a sao:StreamData ;
       sao:hasUnitOfMeasurement <http://unis/ics/unit2:km-per-hour> ;
       sao:time <http://unis/ics/timeinterval> ;     
       sao:value"66,69,69,70,64,75,73,59,61,63,62,62,59,67,65,60,61,58,70,61,60,64,63,63,65,61,67,68,56,52,59,68,62,62,65,57,75,66,68,69,72,73,68,65,62,62,66,67" ;
       ssn:observedBy <http://unis/ics/trafficsensor158324> ;
       ssn:observedProperty <http://unis/ics/property001> ;
       prov:wasAttributedTo <http://example.org/cityofaarhus> .
   <http://example.org/cityofaarhus> a prov:Agent .
   tl:universaltimeline a tl:PhysicalTimeLine .
   <http://unis/ics/saxword001> a sao:SymbolicAggregateApproximation ;
       sao:alphabetsize 5 ;
       sao:segmentsize 8 ;
       sao:value "ecbcbbec" ;
       prov:used <http://unis/ics/trafficdataavgspeed001> .
   <http://unis/ics/veryhightraffic001> a sao:StreamEvent .
   <http://unis/ics/veryhightraffic002> a sao:StreamEvent .
   <http://unis/ics/lowtraffic001> a sao:StreamEvent .
   <http://unis/ics/lowtraffic002> a sao:StreamEvent .
   <http://unis/ics/lowtraffic003> a sao:StreamEvent .
   <http://unis/ics/normaltraffic001> a sao:StreamEvent .
   <http://unis/ics/normaltraffic002> a sao:StreamEvent .
   <http://unis/ics/normaltraffic003> a sao:StreamEvent .
   <http://unis/ics/paa001> a sao:PiecewiseAggregateApproximation ;
       sao:time <http://unis/ics/timeinterval001> ;
       sao:value "0.8561" ;
       prov:wasDerivedFrom <http://unis/ics/segment001> ;
       prov:wasGeneratedBy <http://unis/ics/veryhightraffic001> .
   <http://unis/ics/paa002> a sao:PiecewiseAggregateApproximation ;
       sao:time <http://unis/ics/timeinterval002> ;
       sao:value "-0.2464" ;
       prov:wasDerivedFrom <http://unis/ics/segment002> ;
       prov:wasGeneratedBy <http://unis/ics/normaltraffic001> .
   <http://unis/ics/paa003> a sao:PiecewiseAggregateApproximation ;
       sao:time <http://unis/ics/timeinterval003> ;
       sao:value "-0.5804" ;
       prov:wasDerivedFrom <http://unis/ics/segment003> ;
       prov:wasGeneratedBy <http://unis/ics/lowtraffic001> .
   <http://unis/ics/paa004> a sao:PiecewiseAggregateApproximation ;
       sao:time <http://unis/ics/timeinterval004> ;
       sao:value "-0.2130" ;
       prov:wasDerivedFrom <http://unis/ics/segment004> ;
       prov:wasGeneratedBy <http://unis/ics/normaltraffic002> .
   <http://unis/ics/paa005> a sao:PiecewiseAggregateApproximation ;
       sao:time <http://unis/ics/timeinterval005> ;
       sao:value "-0.6139" ;
       prov:wasDerivedFrom <http://unis/ics/segment005> ;
       prov:wasGeneratedBy <http://unis/ics/lowtraffic002> .
   <http://unis/ics/paa006> a sao:PiecewiseAggregateApproximation ;
       sao:time <http://unis/ics/timeinterval006> ;
       sao:value "-0.4802" ;
       prov:wasDerivedFrom <http://unis/ics/segment006> ;
       prov:wasGeneratedBy <http://unis/ics/lowtraffic003> .
   <http://unis/ics/paa007> a sao:PiecewiseAggregateApproximation ;
       sao:time <http://unis/ics/timeinterval007> ;
       sao:value "1.1901" ;
       prov:wasDerivedFrom <http://unis/ics/segment007> ;
       prov:wasGeneratedBy <http://unis/ics/veryhightraffic002> .
   <http://unis/ics/paa008> a sao:PiecewiseAggregateApproximation ;
       sao:time <http://unis/ics/timeinterval008> ;
       sao:value "0.0877" ;
       prov:wasDerivedFrom <http://unis/ics/segment008> ;
       prov:wasGeneratedBy <http://unis/ics/normaltraffic003> .
   <http://unis/ics/point001> a sao:Point ;
       sao:time <http://unis/ics/timeinstant> ;
       sao:value "20" .
   <http://unis/ics/property001> a ssn:Property ;
       dc:description "Average Speed" .
   <http://unis/ics/segment001> a sao:Segment ;
       sao:value "66,69,69,70,64,75" ;
       prov:wasDerivedFrom <http://unis/ics/trafficdataavgspeed001> .
   <http://unis/ics/segment002> a sao:Segment ;
       sao:value "73,59,61,63,62,62" ;
       prov:wasDerivedFrom <http://unis/ics/trafficdataavgspeed001> .
   <http://unis/ics/segment003> a sao:Segment ;
       sao:value "59,67,65,60,61,58" ;
       prov:wasDerivedFrom <http://unis/ics/trafficdataavgspeed001> .
   <http://unis/ics/segment004> a sao:Segment ;
       sao:value "70,61,60,64,63,63" ;
       prov:wasDerivedFrom <http://unis/ics/trafficdataavgspeed001> .
   <http://unis/ics/segment005> a sao:Segment ;
       sao:value "65,61,67,68,56,52" ;
       prov:wasDerivedFrom <http://unis/ics/trafficdataavgspeed001> .
   <http://unis/ics/segment006> a sao:Segment ;
       sao:value "59,68,62,62,65,57" ;
       prov:wasDerivedFrom <http://unis/ics/trafficdataavgspeed001> .
   <http://unis/ics/segment007> a sao:Segment ;
       sao:value "75,66,68,69,72,73" ;
       prov:wasDerivedFrom <http://unis/ics/trafficdataavgspeed001> .
   <http://unis/ics/segment008> a sao:Segment ;
       sao:value "68,65,62,62,66,67" ;
       prov:wasDerivedFrom <http://unis/ics/trafficdataavgspeed001> .
   <http://unis/ics/timeinstant> a tl:Instant ;
       tl:at "2014-09-30T06:00:00" ;
       tl:onTimeLine tl:universaltimeline .
   <http://unis/ics/timeinterval> a tl:Interval ;
       tl:beginsAtDateTime "2014-09-30T08:00:00" ;
       tl:durationXSD "PT4H" .
   <http://unis/ics/timeinterval001> a tl:Interval ;
       tl:beginsAtDateTime "2014-09-30T08:00:00" ;
       tl:durationXSD "PT30M" .
   <http://unis/ics/timeinterval002> a tl:Interval ;
       tl:beginsAtDateTime "2014-09-30T08:30:00" ;
       tl:durationXSD "PT30M" .
   <http://unis/ics/timeinterval003> a tl:Interval ;
       tl:beginsAtDateTime "2014-09-30T09:00:00" ;
       tl:durationXSD "PT30M" .
   <http://unis/ics/timeinterval004> a tl:Interval ;
       tl:beginsAtDateTime "2014-09-30T09:30:00" ;
       tl:durationXSD "PT30M" .
   <http://unis/ics/timeinterval005> a tl:Interval ;
       tl:beginsAtDateTime "2014-09-30T10:00:00" ;
       tl:durationXSD "PT30M" .
   <http://unis/ics/timeinterval006> a tl:Interval ;
       tl:beginsAtDateTime "2014-09-30T10:30:00" ;
       tl:durationXSD "PT30M" .
   <http://unis/ics/timeinterval007> a tl:Interval ;
       tl:beginsAtDateTime "2014-09-30T11:00:00" ;
       tl:durationXSD "PT30M" .
   <http://unis/ics/timeinterval008> a tl:Interval ;
       tl:beginsAtDateTime "2014-09-30T11:30:00" ;
       tl:durationXSD "PT30M" .

Proposal 4 made by SimonCox

Sentence for FPWD: The SSN should be extended to include patterns for sampling-features.
Sampling is intrinsic to most observation activities, since it is often impossible to exhaustively observe the feature of interest because of its extent or accessibility. A sample is designed to be representative of the ultimate feature of interest. Some sampling strategies are common across disciplines, particularly in the environmental sciences where routine sampling strategies include the use of sample points (stations, sites, pixels), curves (transects, boreholes, flight-lines, ship-tracks, trajectories), surfaces (cross-sections, images, scenes and swaths, quadrats, map-horizons) as well as specimens - where a representative individual or piece of material is taken from the field and moved to a laboratory for further observation. Sampling features are often directly related to other sampling features (samples collected along a ships-track, pixels in a scene, stations on a transect). A key property of a sampling-feature is that it was designed to sample a domain-feature, though the sampling feature may not provide direct access to the properties of the ultimate feature of interest (e.g. pixels in a scene provide spectral information, which may relate to land-cover in a tract). These relationships follow common patterns across a range of applications and disciplines, so a common model can be constructed.

A lightweight ontology for sampling features is provided at http://def.seegrid.csiro.au/ontology/om/sam-lite

Proposal 5 made by KJanowicz

In short, I proposed a horizontal and vertical modularization with a tiny core ontology (pattern) in a schema.org-style i.e., with a lightweight axiomatization. Horizontal modules would then add more classes and relations (e.g., for deployment, sampling,...) and vertical modules would add more expressivity (beyond a simple surface semantics) and further ontological commitments. My proposal also includes removing the entire DUL alignment and replacing it with a deeper axiomatization as discussed wrt action-155. See https://www.w3.org/2015/spatial/wiki/SSN_core_modules for more details.

See SOSA Ontology for description of a strawman broadly following this proposal. - SimonCox 2016-07-04

Compromise Proposal 6 made by Kerry January 2017

Comments are welcome and encouraged -- feel free to interspersed here but please identify with your name (and colour-coding if that helps clarity)

First, some core principles that should be honoured and that drive this design

1. No modularisation should make SSN more complex since its sole purpose is to make ssn simpler and more usable
2. No multiple-named terms that differ only by the namespace
3. No stupidly named terms that are made up only to distinguish them (e.g. ssn:bigPlatofrm vs sosa:littlePlatform).
4. The ssn core and the rest of SSN (lets call this "extended SSN") must play together as neatly as is humanly possible
5. Any user of core ssn needs no knowledge nor awareness of extended ssn.
6. We should standardise the name and meaning of a core term (by its rdfs:comment)in the core and add deeper axiomatic semantics in extended ssn.
7. The use of a term in both the core and the extnded ssn should be understandable and consistent and non-conflicting from both perspectives.
8. User transition from core to extended requires instantiation of extended terms. Only instantiation of those extended terms that are used because they add value. No renaming or reassertion of existing instances in order to use extended terms in the extended ssn. One chooses between the use of the core or extended only by choosing the terms they instantiate (and, iff the user requires imports of terms used, also ensuring those terms that are used are imported).
9. Every core ssn instance (ie data) SHOULD be a valid extended SSN instance (NB this may not be enforcable by reasoning)
10. Every ssn term (whther core or extended) lives in the SAME namespace (NB if this is not achievable due to stupid tools then this could be sacrificed, but it would be fantastic for the user and our explanations)
11. Minimal impact on SSN in that *every* change that needs to be made to ssn from "old" ssn is defensible and justified in our spec and agreed by our WG. That's a high bar.
12. Term definitions (as in rdfs:comment) should be consistent in sosa and ssn.
13. A term cannot change its meaning (as described in rdfs:comment) or label in the core context vs the exapnded ssn context. The definition remains true in both contexts.
14. No alignments are necessary nor offered to implement ssn.
15. SSN alignment to dul has already been removed and stand alone as a helpful but optional product. However it must be maintained so as to be accurate wrt ssn. No further detail on this is offered here. There is no namespace as there are no new terms.
16. There are no other modules (decision taken at Lisbon F2F: core, extended, dul alignment). Other useful alignments are encouraged but do not form "modules". The more they help our users from different perspectives the better.
17. At all times the union of extended ssn, the core and any external alignment must be consistent and every term satisfiable.

So what does an architecture that meets these principles look like?

1. Core ssn and extended ssn are presented as different ontologies - in dfferent files with different ontology iris.
2. The core introduces the most used (“core”) concepts of ssn in a simple ontology language (the language choice is covered elsewhere and is not further addressed here. Conveniently, the core has no global domain nor range statements, and no subclass statments. Formally, it only declares classes, object properties and datatype properties.).
3. These core terms are imported and further refined in extended ssn.
4. "Imported" as used immediately above is via an owl:import statement (NB other ways are possible if this is a point of contention).
5. Further refinement in extended ssn takes some or all of the following forms
   1. classes declared
   2. object and datatype properties declared
   3. classes and properties arranged in class and property hierarchies
   4. Disjointness assertions made
   5. classes (whether introduced in the core or extended ssn) refined by OWL restrictions
   6. object properties refined by property characteristics
   7. global domain and range restrictions
   8. role composition
   9. anything else in owl that I have forgotten and that we *really* need. Even some of those things in the list are not in old ssn and are surely not needed.
6. Notably classess and properties introduced in the core are *directly* refined by additional axioms such as restrictions on the same terms. There is no need (and indeed every harm) to force extended ssn to subclass terms introduced in the core. There is no need (and indeed every harm) to force extended ssn to superclass terms introduced in the core. Every term in the core, where vertical refinement is needed, is refined directly without introducing a fresh term for just that purpose. There are no equivalentclass nor equivalentproperty axioms. Extended axioms are only that --- they are just not instantiated if only the core is used. But they are instantiated whenever the user requires.
7. rdfs: comments are aligned. This can be done by the notion of a "core" comment that explains the term in the context of the core (where the term is in the core) and "extended" comments that deepen that explanation in the context of extended ssn. However the "core" comment remains true in both contexts - both axiomatically and descriptively.
8. Only the extended comments can refer to ssn terms that are not in the core.
9. The traditional user base of extended ssn should be supported by using dul terms as part of the extended comments where appropriate (this does not imlpy that the dul alignment must be used, only it leverages the value of the upper ontology to describe and anchor ssn concepts descriptively).
10. core and extended comments are modelled as multiple rdfs:comment annotations on classes and properties.
11. That is, There need be no distinction in meaning at all amongst terms that occur in the aore alone --- only that the more complex ontology axiomatically constrains the meaning wheras the simpler core just asserts the mean via rdfs:comment.

Example

See option 1 in Platform

Update on SOSA and SSN Integration

Update 23 Feb 2017: visit [2] for an overview of options that integrate SOSA with SSN.