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

El 23/4/17 a las 6:05, Armin Haller escribió:
> Hi Raul,
>
> Thanks! I like them a lot, like I did the old SSN diagrams. I accepted the pull request.
>
> Comments on your issues are inline.

Hi Armin,

Thanks for the comments; I think that we can rapidly go through the 
issues in the next telco and try to close them.

Kind regards,

> On 22/4/17, 8:43 pm, "Raúl García Castro" <rgarcia@fi.upm.es> 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
>
> ➢ That was me doing the documentation manually. You are right, we should just remove the one documented axiom.
>
>     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.
>
> ➢ Yes, I included that in the documentation. I thought it would be worth to add the TemporalEntity to the axiom in SSN as we define the range in SOSA. I had that on my todo list to ask the group on what to do about those.
>
>     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.
>
> ➢ Yes, there are several terms that we may want to deprecate after the usage analysis and implementation evidence. ssn:qualityOfObservation is one of them.
>
>     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 think that is a leftover issue from the fact that the documentation of the class did not keep track with the new sub-classes added. We did have a resolution to make those properties subclasses of ssn:Property, but we may need to adjust the documentation of the class a bit.
>
>     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.
>
> ➢ We can discuss that again. Initially, the feeling was that using the word property in the simple core is confusing for non-ontologists as it clearly has different meanings in the Web developers community.
>
>     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.
>
> ➢ I think that was raised by Maxime as well. I agree, we should probably keep them out of SOSA.
>
>     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.
>
> ➢ We could adjust the axiom for hosts in SSN to include Systems and Platforms.
>
>     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).
>
> ➢ Yes, I think now that we have all others aligned, there is no harm in doing so for the actuation properties.
>
>
>     +-----+
>     |FIXES|
>     +-----+
>
> ➢ Agree with all the below. Just the “System is a unit of abstraction for pieces of infrastructure that implements Procedures.” is correct, in my opinion, but I stand corrected by native speakers.
>
>
>     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
>
>
>


-- 

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 07:01:05 UTC