Handling Time in SOSA and SSN

Issue: "Right now, there are 2 time-related properties in SOSA that are attached to an observation, in SSN there are another 2 attached to an observation and 2 that are not attached to anything." See https://www.w3.org/2015/spatial/track/issues/123.

Essentially, we need formal relations between observationResultTime and observationSamplingTime from (old) SSN and resultTime and phenomenonTime from SOSA. We also need to agree on what to do with startTime and endTime in SSN.

Proposed Mapping (based on Simon Cox's initial work)

Axiom: ssn:observationResultTime rdfs:subPropertyOf sosa:resultTime. %kjanowicz: IMHO, this is not OWL2 (DL) conform?

Comment: sosa:resultTime also applies to actuation and sampling. This is a DatatypeProperty describing the time instant at which the activity (e.g., an observation or actuation) was completed.

Axiom: ssn:observationSamplingTime owl:equivalentProperty sosa:phenomenonTime.

Comment: Note that sosa:phenomenonTime is an ObjectProperty. More specifically, phenomenonTime '[m]ay be an interval or an instant, or some other compound temporal entity'.

Alternative, Mapping-free Proposal (By Raul)

Deprecate ssn:observationSamplingTime and ssn:observationResultTime and use sosa:phenomenonTime and sosa:resultTime exclusively, making both of them object type properties (that make use of the new OWL-Time).

Properties that are only in SSN

• ssn:startTime (The start point of a time interval.)
• ssn:endTime (The end point of a time interval.)

Proposal: Remove both as they are not used. Update: The SSN subgroup voted on declaring ssn:startTime and ssn:endTime as deprecated properties.

Examples of other SSN classes that relate to time (but are not affected by the axioms above)

• ssn:BatteryLifetime
• ssn:ResponseTime
• ssn:SystemLifetime
• ssn:Latency