Re: sosa:Sample - was RE: Comments on the SOSA and SSN implementations

El 15/12/16 a las 2:35, Krzysztof Janowicz escribió:
> Spot on, thanks Simon. I think Raul's point was to declare Sample to be
> a subclass of FeatureOfInterest to allow for samples of samples and I
> agree that this is indeed a good idea and a change we should make to SOSA.

Yes, having Sample as subclass of FeatureOfInterest solves the issue.

Clearly, any FeatureOfInterest that isSampleOf another FeatureOfInterest 
will be a Sample, so giving a name to such class is good.

Kind regards,

> On 12/14/2016 05:17 PM, Simon.Cox@csiro.au wrote:
>>> * 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.
>> The documentation may need to be improved, but there is a strong need
>> for a Sample class.
>>
>> Many (most?) practical observations are on a sample of the ultimate
>> feature of interest. This may be a physical sample taken for ex-situ
>> analysis ('Specimen'), a spatial subset (e.g. cross-section, transect)
>> used to characterize something much larger, or a subset of a
>> population. In every case the intention is that the sample is
>> representative of something larger, which is the real thing of
>> interest. But the observation process uses the sample as a proxy for
>> the bigger thing.
>>
>> Now in some cases we can elide or ignore the distinction, but in
>> practice it is often the case in real world practice that having a
>> clear model which includes both the proximate- and ultimate- feature
>> of interest of an observation, and the relationships between them made
>> clear, is essential to disentangle the semantics.
>>
>> This was one of the key achievements of O&M, and should be preserved
>> in the work here.
>>
>> Simon
>>
>> -----Original Message-----
>> From: Raúl García Castro [mailto:rgarcia@fi.upm.es]
>> Sent: Thursday, 15 December, 2016 03:31
>> To: public-sdw-wg@w3.org
>> Subject: Comments on the SOSA and SSN implementations
>>
>> 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,
>>
>
>


-- 

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 Thursday, 15 December 2016 08:50:26 UTC