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

Hi Armin,

Glad the review was useful and apologies for the additional work incurred
(should have realized this is best done via pull request).

Cheers, m.


On Wed, May 17, 2017 at 7:08 AM Armin Haller <armin.haller@anu.edu.au>
wrote:

> 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>
> 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
>
>