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

Hi Simon,

Thanks for the comment.

In fact, I'm not following the UML notation in the figures at all. I was 
not the original intention.

The principles followed for labeling properties have been more related 
to understandability:
1) To include the label near the source of the relationship (just 
opposite to the UML notation)
2) To try to group together those components more related to a concrete 
conceptual module (e.g., that's the reason usedProcedure appears inside 
the procedure module instead of inside the 
Observation/Actuation/Sampling one)

In any case, if you see a lot of value in labeling the arrows that way, 
I can try to come up with new figures.

Kind regards,

El 24/4/17 a las 12:32, Simon.Cox@csiro.au escribió:
> 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 14:02:05 UTC