RE: New figures added to the SSN document + issues + fixes

However, there is inconsistency on which end of the property links the labels are on. See my comment on the GitHub issue https://github.com/w3c/sdw/pull/737 

-----Original Message-----
From: Raúl García Castro [mailto:rgarcia@fi.upm.es] 
Sent: Monday, 24 April, 2017 17:04
To: janowicz@ucsb.edu; SDW WG Public List <public-sdw-wg@w3.org>
Subject: Re: New figures added to the SSN document + issues + fixes

El 24/4/17 a las 3:57, Krzysztof Janowicz escribió:
> The figures are absolutely fantastic! Thanks!
> [I would just skip fig 2. Is there any specific reason why Deployment 
> is black in fig 10?]

Hi Krzysztof,

Thanks for the praise. :)

I created figure 2 because we had a similar one in the XG report; it helps seeing at a glance all the domains covered by the ontology. But we can remove it also.

The reason for having Deployment in figure 10 is because that section deals with "Systems and Deployments"; therefore, the figure includes an overview of all the entities related to the section.

Kind regards,

> On 04/22/2017 03:43 AM, Raúl García Castro wrote:
>> 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 Monday, 24 April 2017 10:32:57 UTC