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

Dear all,

In the following the remaining comments for sections 5 and 6.

Cheers,
Markus

* Looks like ssn:SensingDevice no longer exit in the SSN ontology?

* 5.1 Dolce-Ultralite Alignment Module, "This section introduces the
alignment of SSN to DOLCE+DNS Ultralite upper ontology": '... alignment of
SSN to the ... ontology'

* 5.1 Dolce-Ultralite Alignment Module, "It also will be imported to the
alignment module of the previous SSN to the current one. Note that it can
be used independent to the previous version of SSN to align with more
generic concepts/properties of DUL alone.": Difficult to understand,
consider rephasing for clarity.

* 5.1 Dolce-Ultralite Alignment Module, 5.1.2 Class Alignments, "Similar to
the previous SSN ontology extending some more generic classes of DUL, the
following classes in SOSA and SSN can be aligned via the subclass relation
as follows.": Drop the reference to the previous SSN, I am not sure how
helpful it is here. Also, 'SOSA and SSN classes can be aligned via the
subclass relation as follows.' You may want to specify RDFS subclass
relation.

* 5.1 Dolce-Ultralite Alignment Module, 5.1.2 Class Alignments: I believe
ssn:Sensor should be sosa:Sensor and ssn:FeatureOfInterest should be
sosa:FeatureOfInterest while sosa:Deployment should be ssn:Deployment?
Also, for sosa:Result and sosa:Deployment there are some squared brackes in
the alignment axiom which seem to be superfluos.

* 5.1 Dolce-Ultralite Alignment Module, 5.1.3 Property Alignments,
"Additional alignments from DUL properties to SOSA/SSN are defined as
follows.": '... from SOSA/SSN to DUL properties ...'?

* 5.1 Dolce-Ultralite Alignment Module, 5.1.3 Property Alignments:
ssn:usedProcedure should probably be sosa:usedProcedure

* 5.2 SSNX Alignment Module, "Note that, SSN-SSNX imports SSN-DUL.": Drop
the comma

* 5.2 SSNX Alignment Module, 5.2.2 Class Alignments: oldssn:Observation
seems to align to oldssn: terms only? Is the ssn:Observation missing? Also,
why aligning oldssn: with oldssn: terms/axioms? Without having given this
much thought, I would expect on the right to be either ssn: or sosa: terms
only. IMO, these tables are not obvious, perhaps one alignment for each
table could also be explained in words to make it more clear to readers.

* 5.3 O&M Alignment Module, "transforming OM-XML data into RDF or OWL
individuals according to the SOSA/SSN ontologies.": RDF speaks of resources
while OWL has a notion of individual.

* 5.3 O&M Alignment Module, "The explicit translation from the UML comes at
a cost": '... translation from UML comes ...'? Also, the sentence could be
improved for readability. I am not sure what it is trying to say. Does the
UML depend on many other UML models and hence in translation one ends up
with many dependencies between OWL ontologies?

* 5.3 O&M Alignment Module, "NOTE: At time of writing, the ISO-specified
URIs do not de-reference, however, ...": Terminate the sentence, then
'However, ...'

* 5.3 O&M Alignment Module: I like the style here as it is more explanatory
compared to the previous sections on alignments. For instance, it is useful
to be told why sosa:FeatureOfInterest is a subclass of GFI_DomainFeature

* 5.4 OBOE Alignment Module, "The following properties from [OBOE] may be
direct aligned with SOSA properties.": '... may be directly aligned ...'

* 5.5 PROV Alignment Module: the punctuation in the first paragraph is a
bit odd, perhaps "Entity, which is ...; Activity, which is ... and may
include ...; and Agent, the class of things ...'

* 5.5 PROV Alignment Module, "described alignments of the SSN-X and O&M
models with PROV": SSNX

* 5.5 PROV Alignment Module, "Procedures for observation, actuation or
sampling are a kind of Plan,": 'prov:Plan' (akin to prov:Entity, or remove
it here)

* 5.5 PROV Alignment Module, "Then sosa:usedProcedure is given by a
property chain axiom :": Remove space before colon and unclear why
sosa:usedProcedure is red

* 6.1 Sample Relations Module, "specimens retrieved withina borehole": '...
within a ...'

* Section 6 seems to be work in progress.

On Mon, May 15, 2017 at 9:35 AM Markus Stocker <markus.stocker@gmail.com>
wrote:

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