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

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.

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

Received on Sunday, 23 April 2017 04:05:54 UTC