Re: SOSA time properties - was RE: Comments on the SOSA and SSN implementations

I created an issue for the datatypes for phenomenonTime and resultTime:

https://www.w3.org/2015/spatial/track/issues/109



On 15/12/16, 8:12 pm, "Raúl García Castro" <rgarcia@fi.upm.es> wrote:

    Hi,
    
    My main concerns are:
    
    * If we don't further specify more classes in SOSA, it seems strange. 
    However, if we are going to also define properties for values, units of 
    measurement and so on, then this concern disappears.
    
    * Coherence among SOSA+SSN temporal properties. I have no problems with 
    the current labels and descriptions of these properties, but when 
    looking at a whole at SOSA+SSN the use of the different properties 
    should be clear.
    
    * Property ranges. Beyond coherence/elegance, Chris just mentioned that 
    some results have a duration and not just an instant. So having a 
    datatype property with xsd:dateTime as range does not satisfy this 
    requirement. We have the option of stating that we won't satisfy that 
    requirement and continue with xsd:dateTime. Anyway, regarding the 
    comment about market acceptability, maybe the Time ontology subgroup has 
    some answer/solution for this, since it will be something present in 
    their concerns.
    
    Kind regards,
    
    El 15/12/16 a las 6:41, Armin Haller escribió:
    > +1 to all of Simon’s comments below.
    >
    > To keep it simple for Web developers, I favour xsd:dateTime for both, phenomenonTime and resultTime.
    >
    > On 15/12/16, 1:12 pm, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au> wrote:
    >
    >     > * 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.
    >
    >     We need a time property, else the ontology is not useful.
    >     Then it is important to remain clear which time it refers to.
    >     phenomenonTime is usually the most important for users of observation data - i.e. the time associated with the phenomenon in the world. I agree that that the name is clumsy, but 'observationTime' is hopelessly ambiguous ... which is why there are multiple temporal properties under consideration. What would you call it?
    >
    >     > 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.
    >
    >     I fear that elegance is not the primary concern for SOSA. This module is aimed at a broad market. The complexity of OWL-Time when all you want to say is "2016-12-15" would fail the 'laugh-test' for most web-developers.  Besides, resultTime is really just a database timestamp.
    >
    >     > 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.
    >
    >     Again, we are caught in a bind here - yes, the elegance and coherence would be good, but we also need to consider market acceptability.
    >
    >     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
    >
    >
    >
    
    
    -- 
    
    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 10:37:22 UTC