Re: Your feedback requested on http://w3c.github.io/sdw/ssn/

Dear all,

Armin asked me for feedback on the SOSA and SSN ontologies.

So far, I have read through Sections 1-4 and I am appending my comments
here. I will try to complete the review by Wed evening CET. I guess I
should have done this via GitHub but my GitHub skills are work in progress.

First of all, I think the SSN revision is interesting and good work. I am
happy to see a lively community and progress around the SSN ontology. I
hope this can be sustained because it is important work.

I think the introduction of sosa:Sample is really exciting and an important
addition to the SOSA/SSN ontologies. Indeed, the distinction between
feature of interest and sample seems critical. Good addition to the
revisited work.

I am looking forward to applying SOSA/SSN in future work, which is
primarily in environmental research infrastructures (where adoption of
these technologies remains quite a challenge).

I am not a native English speaker, so my comments on language may not
really improve understanding. Also, I merely read through the Web page,
relatively quickly (due to time constraints). A more careful review would
be great but for me only possible through concrete use of the ontologies in
applications.

I am appending my comments below. Comments specify the section and,
typically, quote relevant text. After that follows my comment, sometimes a
suggested rephrasing. Hope that's easy enough to parse and process.

Cheers,
Markus

* Abstract, "Given their different scope and degree of axiomatization, SSN
and SOSA support a wide range of applications and use cases, including": I
am not sure how the first part on different scope and degree of
axiomatization links to the wide range of applications and use cases. I
wonder if you can simply drop the first part and start with "SSN and SOSA
support a wide range ...".

* Abstract, "satellite imagery": Perhaps it is in the best practices or
somewhere else, IMO it would be very useful to clarify what is the
right/best approach to represent satellite images using SSN.

* Abstract, "large-scale scientific monitoring": I know it is not strictly
within the scope of this WG, but the SSN (RDF) community needs to come up
with an answer regarding what to do with a trillion+ triples and how to
evaluate SSN SPARQL queries on such volumes (or otherwise be explicit about
the limitations). I collaborate with environmental research infrastructures
with fairly large-scale scientific monitoring, say the European Integrated
Carbon Observation System (ICOS). As you know, these systems have dozens,
hundreds, even thousands (e.g. Argo) platforms and devices deployed, some
of them sampling at fairly high frequency (ICOS has over a hundred
platforms each with a number of 10 Hz devices). These infrastructures are
expected to operate over decades. You quickly see the issue about using SSN
(RDF) technology for such kinds of data. It is arguably impossible to
manage level 0 ("raw") data represented as SSN in RDF using an off the
shelf triple store. Even aggregated data is too big (ICOS aggregates at 30
minutes for greenhouse gas flux measurement). IMO, we urgently need an
answer to scale, otherwise I think for such infrastructures these
technologies will at most play a role for metadata (still nice but ...).
This answer is ultimately also relevant for the Abstract here, because as
it stands the expectations are set very high (worst case it is misleading).

* Status of This Document, "It is inappropriate to cite this document as
other than work in progress": Should it be "... cite this document other
than as work in progress"?

* Introduction, "Sensor observations are a major source of data available
on the Web today.": I wonder if 'Sensors are a major source of data ...'
would be better. IMO, a sensor observation (as in SSN) is arguably an
information object, relating the result to contextual data. At any rate, it
is more than just values, which is what the second and third sentence are
about.

* Introduction, "Nonetheless, publishing, searching, reusing, and
integrating these data": I think this can be improved. First, IMO you can
publish sensor data as mere values; their fitness for reuse is just low.
Also, I am not sure "Nonetheless" relates well to the previous sentence.
How about this rephrasing: 'While sensor data may be published as mere
values, searching, reusing, integrating, and intepreting these data ...'.

* Introduction, "However, these standards are not yet integrated and
aligned with W3C Semantic Web technologies": Remove 'yet'?

* Modularization, "Semantic Sensor Network ontology": Check for consistent
writing ontology/Ontology

* Modularization, "offering several ontology files": documents instead of
files? Or, perhaps, 'offering several distinct ontologies'?

* Modularization, "direction from a dependant ontology to a dependency
ontology": I am not sure this is correct, dependant seems to be used for
people. Do you mean dependent to an independent ontology? Is there a better
wording?

* Modularization, "The importing ontology captures all the meaning": Better
word for 'captures', perhaps 'assumes'? See also the next sentence.

* Modularization, "Our modularization approach uses the first approach":
Drop the first instance of 'approach'

* Origins of SSN and SOSA, "The data returned is in XML, using Sensor Model
Language": 'The returned XML data conforms with Sensor Model Language'

* Origins of SSN and SOSA, "the latter which implements": 'whereby the
latter implements'

* Origins of SSN and SOSA, third paragraph: Citations for SensorML and
OandM already given. Also, you could use the acronyms at this point, if you
introduce them latest in the previous paragraph

* Generally, check for consistent writing of feature-of-interest vs.
feature of interest

* Origins of SSN and SOSA, "inferential semantics of their OWL-2
counterparts": I think it is just 'OWL 2'

* Origins of SSN and SOSA, "SOSA is also more explicit in its support for
virtual sensors and human sensors than SSO": 'SOSA is also more explicit
than SSO in its support for virtual and human sensors'

* Origins of SSN and SOSA, "Due to the widespread adaptation of SSN".
Adaptation or adoption? If adaptation perhaps specify 'widespread
adaptation of SSN in diverse domains and applications'.

* Origins of SSN and SOSA, "with the possibility of using high performance
reasoning": What is the difference between 'high performance reasoning' and
just reasoning? I suppose you mean RDFS/OWL reasoning. There exist
reasoners, say HermiT, Pellet, etc. and I guess they just perform (well or
not). Or do you mean that reasoning with the more lightweight SOSA performs
higher (because lower complexity)? Also, has the community implementation
evidence for high performance reasoning using SOSA, SSN?

* Origins of SSN and SOSA, "Almost all scientific observations make heavy
use of sampling strategies, and, therefore, the Sampling, Sampler, and
Sample classes, as well as their corresponding properties, have been added
to SOSA and SSN.": Have they been added to SOSA or SSN, or both? I mean,
Sampler is in the SOSA namespace, but I see SSN constrains its description.
So perhaps it is correct to say the classes where added to both ontologies.

* Origins of SSN and SOSA, "The SSN previously imported the Dolce-UltraLite
ontology (DUL) and many SSN terms inherited from DUL terms.": The DUL
acronym as been introduced earlier. I think it is OK to no longer spell it
out at this point. If you agree, perhaps check for consistency throughout
the document.

* In Figure 2 (Figure 3 and possibly others) why is Sensor not included in
"Observation/Actuation/Sampling", e.g.
"Sensing/Observation/Actuation/Sampling", or - to reflect SOSA -
"Sensing/Observation/Sampling/Actuation"? Is it because only Observation,
Actuation, and Sampling - but not Sensing - are patterns?

* sosa:Observation: The act of carrying out an observation procedure occurs
in time and space. sosa:Observation relates to time but it is unclear how
to relate an observation to space. Should this be made explicit or is it
described somewhere?

* sosa:Observation: An Observation may relate to multiple sosa:Result. Do
you have a use case where this is the case, for the same
ObservableProperty, FeatureOfInterest, and time?

* ssn:wasOriginatedBy: For me the notion of Stimulus has typically been
challenging to apply in practice. I think it would be useful to clarify how
an Observation is *originated* by a Stimulus. In sosa:Sensor, you state
that "a change in the environment" is an example Stimulus. Can we say that
an Observation was originated by a change in the environment?

* sosa:observedProperty, "The ObservableProperty should be a property of
the FeatureOfInterest": Can the case be made for 'must be'?

* ssn:qualityOfObservation, "This is complimentary to the SystemCapability
information recorded for the Sensor that made the Observation.": I think
you mean complementary?

* sosa:Sensor, "Sensors can be mounted on Platforms": 'hosted by'
Platforms? Same comment in the Example, "and so forth are Sensors that are
typically mounted on a modern smart phone": 'hosted by' a modern smart
phone? Also, I think it would be beneficial to add an example for software,
not least because you include human eyes as an example Sensor. Finally, as
I understand, the relation between Sensor and Platform is at the level of
System and is part of SSN. To my understanding, this means with SOSA alone
one cannot model the Sensor-Platform relationship, yes? I am wondering
because I consider this relationship rather fundamental. In my domain,
sensors as pretty much always hosted by a platform (think of marine
observatories).

* sosa:observes, "Relation between a Sensor and an ObservableProperty that
it is capable of sensing": 'Relation between a Sensor, capable of sensing,
and an ObservableProperty'. I suppose it is the Sensor that is capable of
sensing; you could also consider dropping 'capable of sensing'. Or do you
mean an ObservableProperty that can be observed?

* sosa:madeObservation, "Relation between a Sensor and an Observation it
has made": 'Relation between a Sensor and an Observation made by the Sensor'

* sosa:madeBySensor, "Relation between an Observation and the Sensor which
made the Observations": '... made the Observation'

* ssn:Stimulus: For some classes, e.g. sosa:Sensor, there are examples.
IMO, the ssn:Stimulus class would benefit from examples, e.g. examples for
events that trigger sensors as well as examples where the properties of
Stimulus are different from those of the observed property. Clarify what
'triggers' means. I think such examples would clarify the notion of
Stimulus. There are some examples in ssn:isProxyFor (e.g. expansion of
quicksilver). Also, "It is the event, not the object, that triggers the
Sensor": What is the object here?

* ssn:detects, "A relation from a Sensor to the Stimulus that the Sensor
can detect": '... that the Sensor detects'

* sosa:madeActuation, "Relation between an Actuator and the Actuation it
has made": '... the Actuation made by the Actuator' (IMO, it better
reflects the style in the sosa:madeByActuator description).

* Sampling (also for Observation, Actuation and other sections), "the
following figures provide an overview over the core classes and
properties": '... an overview of the core ...'

* sosa:Sample: I am not sure I completely understand the first example in
particular the latter part "and not to any physical artifact such as a
mooring, buoy, benchmark, monument, well, etc.". I would expect here that
the example suggests the observed properties relate to the physical medium
at the station and not to the 'ultimate feature of interest', which I would
not think is the station (mooring, buoy) but rather something like 'ocean'
or 'sea' or 'body of water'. In other words, the sensor makes observations
about a small water sample, rather than the whole body of water. Why are
the observed sample properties contrasted to the properties of a mooring or
buoy (the station)? Or am I reading this wrongly?

* sosa:Sample, Sub class of: the list ends with a comma

* sosa:hasSample, "Relation between a FeatureOfInterest and the Sample used
to represent it": '... and the Sample that represents the feature'

* sosa:isSampleOf, "Relation from a Sample to the FeatureOfInterest that it
is intended to be representative of": 'Relation between a Sample and the
FeatureOfInterest that the Sample intends to represent.

* sosa:Sampling, "Establishing a station for environmental monitoring":
Given as an example act of Sampling. I am unclear in what sense. Of course,
the station, or more accurately perhaps the sensors hosted by the station,
do sampling, carry out a sampling procedure. But is establishing the
station itself an act of Sampling?

* sosa:Sampler. The sampler can be a device different from a sensing device
that makes an observation about the sample. However, sometimes the
distinction is not evident, as the sampler and the sensing device are
packaged as a unit. For instance, a differential mobility particle sizer
takes a small volume of ambient air, the sample, and estimates the count of
particles in a range of diameter sizes in the sample. The sampler and the
sensor are tightly coupled in a single device (although you can distinguish
them if you look closely). Should this be noted in the description.

* sosa:madeSampling and sosa:madeBySampler: The former speaks of performing
and act of Sampling while the latter suggests an act of Sampling is made.
The property also suggests Sampling is made. Harmonize?

* 4.3.4 Features of Interest and Properties, "classes and properties that
are specifically related to modeling Features of interest and their
Properties": '... Feature of Interest ...'

* sosa:FeatureOfInterest, "20m may be the Result of the Observation": '20 m
...' (also elsewhere, e.g. sosa:Procedure)

* sosa:hasFeatureOfInterest, "For example, in an Observation of the weight
of a person, the FeatureOfInterest is the person and the property is its
weight": ', ... person is the FeatureOfInterest and weight is the observed
quality'

* ssn:Input: Should "[MMI OntDev]" be a reference? I think this description
could benefit from examples.

* ssn:Output: Here, too, I think the description could benefit from
examples.

* ssn:hasSystemProperty, "Relation from an SystemCapability of a System to
a SystemProperty describing the capabilities of the System":
'SystemProperty'
 not an active link

* ssn:ActuationRange: I think the description could read more like that of
ssn:MeasurementRange, e.g. 'The set of values that the Actuator can return
as the Result of an Actuation under the defined Conditions with the defined
system properties.'

* ssn:DetectionLimit: Has a rather technical description, perhaps extend
the description with 'In other words, ...' / 'i.e., ...'. IMO, this applies
also to some other descriptions (in System Capabilities), e.g. for
ssn:Sensitivity. Examples may be beneficial.

* ssn:SurvivalRange, "For example, to the lifetime of a System under a
specified temperature range.": 'For example, the lifetime ...'

On Mon, May 8, 2017 at 6:54 AM Armin Haller <armin.haller@anu.edu.au> wrote:

> Dear Markus,
>
>
>
> We have identified you as a user of the original Semantic Sensor Network
> Ontology and are seeking your feedback on our ongoing work to standardise
> the ontology through the Spatial Data on the Web Working group of the W3C,
> available at http://w3c.github.io/sdw/ssn/.
>
>
>
> The purpose of revisiting the original SSN ontology was to address the
> issue of its complexity, partly due to its layering underneath the
> Dolce-UltraLite upper level ontology. In response to this, the new Semantic
> Sensor Network ontology [1] offers several ontology subsets that are
> distinguished mainly through their ontological commitments. At its core, a
> new ontology is proposed, namely the Sensor, Observation, Sample, and
> Actuator (SOSA) ontology [2]. SOSA acts as a central building block for the
> SSN, but puts more emphasis on light-weight use and the ability to be used
> standalone, in particular, in a Web context providing an experience more
> related to Schema.org. It also introduces, as the name suggests, additional
> terms pertaining to Actuation, a concept of growing importance in the Web
> of Things and new terms around Sampling.
>
>
>
> As a user of the original Semantic Sensor Network ontology we believe you
> may want to make comments on the revised version. Please send any comments
> to public-sdw-comments@w3.org
> <public-sdw-comments@w3.org?Subject=Re%3A%20Comments%20sought%20on%20the%20Semantic%20Sensor%20Network%20%28SSN%29%20Ontology%20%20http%3A%2F%2Fw3c.github.io%2Fsdw%2Fssn%2F%2C&In-Reply-To=%3C02514848-2A09-459E-9EAE-880711B572AD%40anu.edu.au%3E&References=%3C02514848-2A09-459E-9EAE-880711B572AD%40anu.edu.au%3E>
> .
>
>
>
> The Working Group is short of time and the review phase will close in
> about two week’s time, so the sooner your comments are received the better.
>
>
>
> Kind regards,
>
> Armin
>
>
>
> [1] http://www.w3.org/ns/ssn/
>
> [2] http://www.w3.org/ns/sosa/
>
> [3] http://purl.oclc.org/NET/ssnx/ssn
>
>
>
>
>
> ---
>
> Armin Haller, PhD
>
> Senior Lecturer
>
> RSM, Australian National University
>
> P.A.P. Moran Building (26B), Room 1049
>
> Ph: +61 2 612 55020
>
> armin.haller@anu.edu.au
>
> CRICOS Provider: 00120C
>