New figures added to the SSN document + issues + fixes

Dear all,

I have created the figures for the "Axiomatization" section of the 
document. You can find the document updated with the figures in a pull 
request:
https://github.com/w3c/sdw/pull/737

All the figures are in the "images" directory (I have appended "SSN-" to 
them to avoid confusions).

Feel free to comment on the figures and, if you like them, I can 
generate similar ones for the rest of the document.

Besides, while generating the figures, I came across several fixes and 
issues that I present next.

+------+
|ISSUES|
+------+

These are things that require (more or less) discussion, either on the 
issue or on how to solve it.

Documentation of cardinality restrictions
-----------------------------------------

This is something that happens in different places in the documentation.

Taking as an example the Observation class, the documentation states:
   sosa:madeBySensor must be exactly 1 sosa:Sensor
   sosa:madeBySensor must be sosa:Sensor

However, this is not a direct translation of the implementation, because 
the cardinality axiom is not qualified:
   rdfs:subClassOf [ a owl:Restriction ; owl:onProperty 
sosa:madeBySensor ; owl:cardinality "1"^^xsd:nonNegativeInteger ] ;
   rdfs:subClassOf [ a owl:Restriction ; owl:onProperty 
sosa:madeBySensor ; owl:allValuesFrom sosa:Sensor ] ;

I don't know if this is due to the generation of the documentation or 
because it is intended to be so.

I see two options, either we translate directly axioms or, since we are 
tweaking manually the documentation, we generate more concise and clear 
documentation (which is what I prefer).

That means that in the previous case the documentation would be just the 
conflation of the two statements:
   sosa:madeBySensor must be exactly 1 sosa:Sensor

Documentation of temporal cardinality restrictions in Observation
-----------------------------------------------------------------

Related to the previous issue, and this time particular to the 
documentation of the Observation class.

The documentation of Observation states:
   sosa:phenomenonTime must be exactly 1 time:TemporalEntity

While the axiom does not include time:TemporalEntity:
   rdfs:subClassOf [ a owl:Restriction ; owl:onProperty 
sosa:phenomenonTime ; owl:cardinality "1"^^xsd:nonNegativeInteger ] ;

In fact, the value is not restricted to time:TemporalEntity anywhere; it 
only appears in SOSA through schema:rangeIncludes.

For resultTime, the documentation in Observation states:
   sosa:resultTime must be exactly 1 xsd:dateTime

In this case xsd:dateTime is defined in sosa as the range of the 
property, so I'm not sure whether the documented restriction is correct.

ssn:qualityOfObservation
------------------------

ssn:qualityOfObservation is declared in ssn (was declared already in 
ssnx) but is not used anywhere in the ontologies.

Besides, the (non-exhaustive) usage analysis 
(http://w3c.github.io/sdw/ssn-usage/) shows that it has not been used.

I propose to remove from the current ontologies and deprecate it.

If we decide to leave it, in the document I would put it at the end of 
the section, not in the middle of the sosa terms as it is now.

ssn:hasProperty
---------------

ssn:hasProperty is defined as inverse of ssn:isPropertyOf and is 
documented as:
   "Relation between a FeatureOfInterest and a Property of that feature."

There are multiple properties that do not fit directly/intuitively with 
that definition and are defined as subproperties of ssn:hasProperty 
(ssn:qualityOfObservation, ssn:hasSystemCapability, 
ssn:hasSystemProperty, ssn:hasOperatingRange, ssn:hasOperatingProperty, 
ssn:hasSurvivalRange, ssn:hasSurvivalProperty).

I don't know if this may cause confusion and maybe we should remove some 
of those subproperty declarations?

ssn:hasProperty and ssn:isPropertyOf
------------------------------------

I think that this has been discussed before; I see a lot of value in 
being able to represent which properties belong to a certain feature of 
interest. For example, for discovery tasks: for which properties of this 
room can you act on?

Therefore, I would move the ssn:hasProperty and ssn:isPropertyOf 
properties from ssn to sosa.

It gives more cohesion to the core, makes no harm, and for those use 
cases people should not need to use the whole ssn.

hasResultingSample/isSamplingResultOf
-------------------------------------

I think that subclassing hasResult and isResultOf for the case of 
Samples adds unnecessary complexity to the core.

Right now in ssn only hasResultingSample is used in restricting the 
Sampling class, and that restriction could perfectly be defined with 
hasResult.

In order to reduce complexity, I would remove those properties, use the 
hasResult property in the ssn restriction, and include in the definition 
of hasResult (schema:domainIncludes Sampling) and in the definition of 
isResultOf (schema:rangeIncludes Sampling).

In this way, we don't fully specify in sosa that the range of Sampling 
is a Sample (just a Result), but anyone seeing the documentation and the 
restrictions in ssn will be able to know how to use it.

hosts/isHostedBy
----------------

In sosa it is stated that a platform hosts either systems (sensors, 
actuators, samplers) or platforms, using rangeIncludes (it is similarly 
defined in isHostedBy).

However, in ssn it is stated that sosa:hosts must be ssn:System, which 
does not fully support the previous definition.

Right now Platform and System are unrelated; we could say that System is 
a subclass of Platform, but it would add unnecessary complexity.

I would remove that Platform is a range of hosts and, if we think that 
being able to define platforms inside platforms is needed, I would 
define a specific property (with the risk of creating confusion with the 
existing hasSubSystem property).

Results section
---------------

The Results section may be misleading, since it is describing terms that 
are not 1st order citizens in the ontology (i.e., a result needs an 
Observation/Observation/Sampling to give context).

I would include some sentence saying that the Result class is intended 
to be used along an Observation/Actuation/Sampling class to provide the 
necessary context.

Naming convention
-----------------

This is something that Maxime already raised; we should follow the same 
naming convention in properties (e.g., madeBySensor vs actuationMadeBy).


+-----+
|FIXES|
+-----+

These are other fixes that are minor corrections in the document and in 
the ontologies and that do not require discussion.

All these fixes are included in the following pull request:
https://github.com/w3c/sdw/pull/736.

sosa:isResultOf restriction in sosa:Result
------------------------------------------

sosa:Result is restricted in ssn with the following restriction:
   inverse Of sosa:isResultOf must be at least 1

The restriction should be without the inverse part:
   sosa:isResultOf must be at least 1

sosa:resultTime
---------------

The documentation of sosa:resultTime states: Range Includes xsd:dateTime.

However, it is defined with rdfs:range xsd:dateTime in sosa, not with 
schema:rangeIncludes.

sosa:hosts
----------

sosa:hosts includes in its ssn definition: "Sub property of Chain 
ssn:hasDeployment o ssn:deployedSystem" while it should be "Sub property 
of Chain ssn:inDeployment o ssn:deployedSystem".

ssn:System
----------

ssn:System includes the restriction: "inverse Of ssn:implements must be 
sosa:Procedure", when it should be: "ssn:implements must be 
sosa:Procedure" (without the inverse of).

Writing corrections (document + ontologies)
-------------------------------------------
4.3.4 Feature of Interest and Properties
->
4.3.4 Features of Interest and Properties

A Platform is an entity that hosts other entities, particularly Sensors, 
Actuators and other Platforms.
->
A Platform is an entity that hosts other entities, particularly Sensors, 
Actuators, Samplers, and other Platforms.

System is a unit of abstraction for pieces of infrastructure that 
implements Procedures.
->
System is a unit of abstraction for pieces of infrastructure that 
implement Procedures.

Updates in the ontologies
-------------------------

Replaced all the unneeded multi-line literals (""") to single line ones (").

Kind regards,

-- 

Dr. Raúl García Castro
http://www.garcia-castro.com/

Ontology Engineering Group
Departamento de Inteligencia Artificial
Escuela Técnica Superior de Ingenieros Informáticos
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 65 96 - Fax: +34 91 352 48 19

Received on Saturday, 22 April 2017 10:43:44 UTC