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

The figures are absolutely fantastic! Thanks!
[I would just skip fig 2. Is there any specific reason why Deployment is 
black in fig 10?]


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


-- 
Krzysztof Janowicz

Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net

Received on Monday, 24 April 2017 01:57:55 UTC