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

Hi Markus,

Thanks for your very detailed comments!

I have just issued a pull request that implements the changes you proposed below.

https://github.com/w3c/sdw/pull/894


I have not actioned all comments where I thought the current phrasing is ok.

I have created Issue https://www.w3.org/2015/spatial/track/issues/198 for one of your comments.

Some of your questions will also hopefully be answered by the examples that we are currently adding to the document.

Regarding your question for the Sensor-Platform relationship. It is possible to relate Sensors to platforms even in SOSA through the sosa:hosts relation. It is only the more general System class that is not available in SOSA. However, all things that are hosted onto a Platform are Systems.

Thanks,
Armin

From: Markus Stocker <markus.stocker@gmail.com>
Date: Monday, 15 May 2017 at 5:46 pm
To: "public-sdw-comments@w3.org" <public-sdw-comments@w3.org>
Cc: Armin Haller <armin.haller@anu.edu.au>
Subject: 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<mailto: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<mailto: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<mailto:armin.haller@anu.edu.au>
CRICOS Provider: 00120C