Re: Comments on the SOSA and SSN implementations

>
> * sosa:Platform
> The documentation says "(including rdf:type rdfs:Class, owl:Class 
> humans)", should this be "(including humans)"?

Well spotted; corrected. We have too many people editing SOSA right now, 
no idea how this got there.

> * sosa:hasValue
> Why not including meta:domainIncludes sosa:Result in this property? 

Agreed. No harm in that; corrected.

> * sosa:Sample
> From the documentation, a Sample is a FeatureOfInterest (shouldn't 
> Sample be a subclass of FeatureOfInterest?). I also think that there 
> is no need for a Sample class; I would just state that a 
> FeatureOfInterest can have as a sample another FeatureOfInterest. In 
> any case, unless some of these changes are made, the current model 
> "does not allow" taking samples of samples. 

This is a longer discussion. We removed subclasses from SOSA some time 
ago and there are many good reasons for the sample class (see our 
argumentation for a FeatureOfInterest class). I agree with the 
sub-sampling issue and the subclass as a solution. Let me delay this for 
now, nonetheless. We will get back to this. Again, well spotted.

> * Units of measurement
> Also, regarding values, I think that right now the ontology falls 
> short on supporting how to describe them when they require a unit of 
> measurement. Along the documentation plenty of examples are included 
> that mention a unit of measurement (e.g., "20m") but in the 
> documentation of sosa:hasValue it only appears "23 or true", without 
> mentioning the unit anymore. Since sosa:hasValue is a datatype 
> property, do we expect people to attach the unit of measurement to a 
> sosa:Result? 

Yes, the unit of measure would be attached to the result in the same way 
the value does. We simply have not done this so far as we have not 
discussed whether such relation should be a datatype property or not.

>
> * sosa:hosts
> The documentation mentions a SamplingDevice that is not mentioned in 
> the ontology. 

Fixed. There was a sampling device in an early version of SOSA. 
RangeIncludes is informal anyway, so sampling devices can still be 
mounted on SOSA platforms.

> * sosa:madeObservation
> Why is the inverse observedBy property not defined? 

To avoid collisions with isObservedBy which related an observable 
property to a sensor. We will fix this, but need to be careful with the 
naming.

* Importing SKOS
> I would move the last triples defining the SOSA ontology to the 
> beginning. Related to these, why do we need to import SKOS? 

We wanted to use skos:definition and so forth. I am actually not sure 
whether this is a good idea and whether we should not keep SOSA as 
import free as possible, but this is a larger discussion we all need to 
have together.

> * sosa:phenomenonTime and sosa:resultTime
> I would remove these properties from SOSA, mainly because I think that 
> they aim for a richer level of detail than the other concept 
> descriptions in the ontology. 

This is your only suggestion where I would strongly disagree. I see your 
point about the way we handle them and that this will need some 
revisions but time as such is absolutely critical to describe 
observations. We describe their location via the FOI.

> In other (now more positive) words, I think that SOSA is the result of 
> a very good work, and I'd like it to be a proper core part of SSN.
> Let's see how we can do it! 

Yes, more work over the next weeks in required and we will get there. 
Thanks for your productive suggestions and for having positive attitude.

Best,
Krzysztof


On 12/14/2016 08:31 AM, Raúl García Castro wrote:
> Dear all,
>
> I've been reviewing the implementations of SOSA and SSN and here you 
> have some comments (plus a couple of pull requests) on each of them 
> and on the combination.
>
> SOSA
> ----
>
> * sosa:Platform
> The documentation says "(including rdf:type rdfs:Class, owl:Class 
> humans)", should this be "(including humans)"?
>
> * sosa:Sample
> From the documentation, a Sample is a FeatureOfInterest (shouldn't 
> Sample be a subclass of FeatureOfInterest?). I also think that there 
> is no need for a Sample class; I would just state that a 
> FeatureOfInterest can have as a sample another FeatureOfInterest. In 
> any case, unless some of these changes are made, the current model 
> "does not allow" taking samples of samples.
>
> * sosa:hasValue
> Why not including meta:domainIncludes sosa:Result in this property?
>
> * Units of measurement
> Also, regarding values, I think that right now the ontology falls 
> short on supporting how to describe them when they require a unit of 
> measurement. Along the documentation plenty of examples are included 
> that mention a unit of measurement (e.g., "20m") but in the 
> documentation of sosa:hasValue it only appears "23 or true", without 
> mentioning the unit anymore. Since sosa:hasValue is a datatype 
> property, do we expect people to attach the unit of measurement to a 
> sosa:Result?
>
> * sosa:hosts
> The documentation mentions a SamplingDevice that is not mentioned in 
> the ontology.
>
> * sosa:madeObservation
> Why is the inverse observedBy property not defined?
>
> * sosa:phenomenonTime and sosa:resultTime
> I would remove these properties from SOSA, mainly because I think that 
> they aim for a richer level of detail than the other concept 
> descriptions in the ontology.
> Having them inside is no main problem, but then their definition is 
> quite weird since one is defined as an object property and the other 
> as a datatype property. I understand why they have been defined that 
> way, but it is not elegant.
> On the one hand, in sosa:phenomenonTime we talk about time intervals 
> and instants; we have here an opportunity to link to the W3C Time 
> ontology, and even talk about TemporalEntities?
> On the other hand, in sosa:resultTime we talk about xsd:dateTime 
> (being the only property in the ontology that specifies a rdfs:range); 
> to be coherent we should talk about time instants.
>
> * Importing SKOS
> I would move the last triples defining the SOSA ontology to the 
> beginning. Related to these, why do we need to import SKOS?
>
> SSN
> ---
>
> * ssn:startTime and ssn:endTime
> They are not documented in the ontology with rdfs:comment (it happens 
> in others such as observedBy). And the link that appears in the 
> description is "broken" 
> (http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Base#Time). They are 
> not used in any of the other entities in the ontology; should we 
> remove them?
>
> * dul:includesEvent
> The dul:includesEvent property has dissapeared and the local 
> restriction that relates an Observation to a Stimulus has dissapeared to.
> Maybe it has been made in purpose, but the possibility of relating 
> those two classes is not there anymore.
>
> * ssn:SensorDataSheet
> This class is not related to other classes or properties in the model. 
> Should we remove it or relate it?
>
> SSN+SOSA
> --------
>
> Taking the SSN ontology as it is (in GitHub) and SOSA, right now it 
> cannot be said that one is a core module of the other, since:
>  -  SSN does not reuse SOSA vocabulary terms (this could be 
> implemented by mappings)
>  - SOSA adds actuation and sampling
>  - SOSA renames plenty of classes and properties. In some cases maybe 
> the intended meaning is more or less equivalent, but in others it 
> radically changes (for example, ssn:hasValue is an object property and 
> sosa:hasValue is a datatype property).
>  - The modelling decisions in both are different; for example, in SOSA 
> a Sensor is hosted by a Platform, in SSN a SensingDevice (not a 
> Sensor) is on a Platform.
>
> The result is that currently we don't have a clean view on the 
> ontology as a whole as a composition of modules. And for anyone using 
> the ontology it will be quite difficult to digest everything (e.g., 
> there are 2 time-related properties in SOSA attached to an 
> observation, in SSN there are another 2 attached to an observation and 
> 2 that are not attached to anything.
>
> In other words, my opinion is that right now SOSA is something derived 
> from SSN but we still have plenty of work to do (either changing SOSA, 
> SSN, or both) to put them together so it can be considered a proper 
> core module.
>
> If not, the risk is to produce two different (even if compatible) 
> ontologies which is not desirable for interoperability.
>
> In other (now more positive) words, I think that SOSA is the result of 
> a very good work, and I'd like it to be a proper core part of SSN.
> Let's see how we can do it!
>
> 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 Wednesday, 14 December 2016 17:32:45 UTC