SOSA CR: Remove `rdfs:range` on `sosa:resultTime`

[edmondchuc]

This change request is requesting the removal of the following statement from SOSA.

sosa:resultTime rdfs:range xsd:dateTime .

Many observations and sampling acts in the ecological domain do not have the precision of xsd:dateTime for their result time. In many cases, the precision of result time is a date.

Please can we remove the statement above.

The original issue which prompted this change request https://github.com/ternaustralia/ontology_tern/issues/135.

[ajnelson-nist]

Hello. I'm happy to file a separate issue on this, but thought it would be good to augment this thread a little.

The SOSA iPhone Barometer example includes two usages of sosa:resultTime. The usage attached to <Observation/346344> is as a owl:DatatypeProperty, which also matches the definition in the SOSA ontology file. The usage attached to <Observation/346345> is as an owl:ObjectProperty, having a time:Instant as its triple-object.

Usage of resultTime in both of these manners is a violation of OWL 2 DL's disjointedness of ObjectPropertys from DatatypePropertys.

Circling back to @edmondchuc 's requested relaxation: Is the intent to still keep resultTime as a DatatypeProperty? Or, with the removal of the range specification, is the intent to make resultTime into an ObjectProperty with time:Instant as the range, in satisfaction of the not-quite-guaranteed availability of timestamp precision?

If it's helpful for the example OWL 2 DL error to be raised as a separate Issue, I'm happy to file that if anyone suggests I do.

[dr-shorthair]

This is the only property whose range is set using rdfs:range.

[dr-shorthair]

@ajnelson-nist do we want to allow both literals (of type xsd:dateTime, xsd:date etc) and also objects (e.g. time:Instant)? That would require the property to be rdf:type rdf:Property which I think makes OWL processors choke, right?

Since it is intended to be a time position, not a period, then probably owl:DatatypeProperty is what we need.

I'll fix that error in example <Observation/346345> - see 6073399

[ajnelson-nist]

@ajnelson-nist do we want to allow both literals (of type xsd:dateTime, xsd:date etc) and also objects (e.g. time:Instant)? That would require the property to be rdf:type rdf:Property which I think makes OWL processors choke, right?

To allow both literals and objects on the same property, there are two options, which both (in my opinion) present drawbacks from the OWL perspective. (Apologies if you are already aware of these details, I only mean to confirm any of our overlapping contextual knowledge.)

1. Redefine resultTime to be an owl:AnnotationProperty. OWL permits annotations to link literals or objects (strings or things).
   1. This seems to me to be incongruous with the purpose of the property. "Annotation properties are used to encode information about (parts of) the ontology itself (like the author and creation date of an axiom) instead of the domain of interest" (OWL 2 Primer, Section 3). The result time seems like a significant property meant for describing data within the domain, especially in distinguishing versus phenomenon time.
   2. Annotation properties also do not get to be used in OWL class design - in particular, they can't be used in owl:Restrictions. This is a bit of an oblique conclusion, but you can confirm this yourself with the strict parsing enumerations in the OWL 2 mapping to RDF document.
      1. If resultTime can't be in an owl:Restriction, this is a significant limitation on SOSA being able to express that a Result can only have one resultTime - this won't be expressible in OWL, but could still be expressed in SHACL shapes.
   3. There is no "switching between" the three major property types with rdfs:subPropertyOf. Seeing again the OWL 2 mapping to RDF document, note the occurrences of rdfs:subPropertyOf stay strictly between object property to object property, datatype property to datatype property, and annotation property to annotation property.
2. Relax the property definition to rdf:Property. However, the specific way an OWL processor would "choke" as you put it would be in the OWL 2 DL requirement that all properties in the graph must be one of the OWL built-ins or inherited-from-RDFS structural properties (e.g., rdf:type, rdfs:comment); or if not built-in, exactly one of an object property, datatype property, or annotation property. (The typical place this pops up is an OWL processor complaining about an "undefined annotation property", which was not declared as one of the three OWL property-types.)

Since it is intended to be a time position, not a period, then probably owl:DatatypeProperty is what we need.

Another option that's available is splitting the goal of representing the time position between two properties, one an object property that ties to some notion of an instant of time, the other a datatype property that could encode that it is a "shortcut encoding" for the timestamp in an associated-but-not-represented instant. This latter approach is done in several other ontologies. To my recollection[^1]:

• gUFO represents an interval's end point with gufo:hasEndPoint when an object (time:Instant) is desired, and one of gufo:hasEndPointInXSDDate or gufo:hasEndPointInXSDDateTimeStamp handles literals. (And likewise with hasBeginPoint, etc.)
  • SOSA could use an owl:unionOf to let resultTime's literal-housing property store an xsd:date, xsd:dateTime, or xsd:dateTimeStamp.
• PROV-O represents end times as literals with prov:endedAtTime, and the associated reified form is the prov:InstantaneousEvent prov:End.
  • A property chain axiom prov:qualifiedEnd / prov:atTime is alluded to as an editorial note in the encoded ontology, but not implemented. OWL-Time makes the suggestion in a section that suggests a PROV/Time alignment.

Point being, there is an available design pattern that lets reified and literal time references coexist, and compose with one another. I would suggest following this pair-of-properties pattern, especially in support of referencing time:Instants when some topological event ordering might be needed when the literal-timestamps might not be known.

Maybe resultTime remaining a datatype property, and resultInstant being the object property, would work?

I'll fix that error in example <Observation/346345> - see 6073399

Thanks for the fix!

[^1]: Disclaimer: Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose.

[rob-metalinkage]

Also to note that JSON-LD implementations are compromised by not being able to determine if the schema element is an object or a literal. This can be worked around by having two separate profiles with different JSON-LD contexts, but this is both more complex and wont support heterogeneous use of both patterns in the same data.

Making the range open still means implementations need to be explicit to determine appropriate processing - whether it is JSON-LD or OWL reasoning. Perhaps using explicit *TimeInterval or startTime, endTime, properties would be better.

Alignment with PROV Activity with explicit start and end time simple properties could perhaps be used here. i.e. use PROV for intervals as a recommendation ?

[ajnelson-nist]

Also to note that JSON-LD implementations are compromised by not being able to determine if the schema element is an object or a literal. This can be worked around by having two separate profiles with different JSON-LD contexts, but this is both more complex and wont support heterogeneous use of both patterns in the same data.

Agreed. JSON-LD and programming language bindings would have an often-repeated bad time if they have to guess "Thing or string" all over the place.

Making the range open still means implementations need to be explicit to determine appropriate processing - whether it is JSON-LD or OWL reasoning. Perhaps using explicit *TimeInterval or startTime, endTime, properties would be better.

I have no commentary on usage of the non-RDFS range suggestions from schema.org.

However, I do think property-pairs to cover owl:ObjectPropertys and owl:DatatypePropertys would enable cleaner practice.

Though, my understanding is the object property would map to an always-0-dimensional time instant, not a potentially-1-dimensional interval.

Alignment with PROV Activity with explicit start and end time simple properties could perhaps be used here. i.e. use PROV for intervals as a recommendation ?

It looks like SOSA-SSN Section 6.5 (preview is linked from PR 175), "PROV Alignment Module," already suggests this. This helps me understand some of the original motivation of this Issue in dropping rdfs:range, when also considering SDW Issue 1421. (Also, whoops! I think I forgot about that thread from going to a conference at about the same time. I'll be back to it soon.)

Note that one side-effect of alignment with PROV (discussed in issue 1421) would mean that the inherited prov:atTime, prov:startTime, and prov:endTime would be constrained to be xsd:dateTime. SHACL-SPARQL could provide an enforcement mechanism to make sure the xsd:dateTime literals have time zones. I'm not sure if that can also be specified in OWL.

[dr-shorthair]

resultTime is a time instant. The PROV alignment is to prov:endTime - see https://www.w3.org/TR/vocab-ssn/#PROV_Alignment_property - which as you note has range xsd:dateTime.

The issue here was triggered by the concern that in practice the precision implied by xsd:dateTime is often beyond what is recorded (see above), so that is why I suggest relaxing the global range constraint, and mention (non-normatively) alternatives with lower precision (day, month, year) provided by the XSD built-ins xsd:date, xsd:gMonth, xsd:gYear - see #175

We really do not need to wrestle with ObjectProperties for resultTime, and my proposal would still be compatible with existing implementations that use xsd:dateTime.