ISSUE-26: clarification of temporal vagueness requirement

[frans]: time

Summary: the email thread discussion produced:

1. Useful examples of temporal vagueness("photo taken on a Christmas day, but year unknown", "Later part of the Jurassic")

2. Many of these could be addressed by allowing imprecision in the specification of time intervals (or the special case of instants). these would imple cahnges to the current Time-OWL.

Issue 26 Summary of discussion and resolution.

1. Firstly, there was discussion about whether Time was work of the SDW. Answer: yes, it is specifically in the scope of the Working Group's charter, and increasingly to know where something is, we need to know when!

2. Uncertainty in time is covered by the temporal vagueness requirement:
"It should be possible to describe time points and intervals in a vague, imprecise manner. For instance, to represent that an event happened on the afternoon of June 1st or at the second quarter of the 9th century."

Some useful further examples of temporal vagueness are: "photo taken on a Christmas day, but year unknown", "later part of the Jurassic", "about the reign of Khafra".

3. The Requirement could be addressed by allowing imprecision in the specification of time intervals. These would imply changes to the current OWL-Time. A new requirement was proposed: "OWL-Time should be updated to conform to the 2012 update of OWL datatypes."

"OWL-Time should support xsd:dateTimeStamp" Agreed and done, but note that OWL-Time has some datatypes that are not in OWL-2.

4. Temporal 'fuzziness' could also be accomodated by using pairs of intervals. OWL-Time restricts the range of the 'hasBeginning' and 'hasEnd' properties to Instant. If extended to include Intervals, many 'fuzzy' temporal expressions could be encoded, including using the 4-part pattern (earliestStart, latestStart, earliestEnd, latestEnd).

Two projects doing this are:
4.1 The Periods Organized project http://perio.do
4.2 Topotime http://dh.stanford.edu/topotime , which also includes operators like ‘before’, ‘after’, and ‘about’, and differentiates 'some time/duration within' and 'throughout.'

But OWL-Time does this already. Allen’s algebra (1983) makes intervals the primary structure, and instants a special case where we can not distinguish the beginning and end, at the current level of precision. No change in the OWL-Time ontology.

5. Extension proposed for non-Gregorian calendars, aiming for backward compatability with original OWL-Time (2006). Agreed and done.

6. Confusion between temporal 'vagueness' and '(im)precision' suggests requirement re-wording from:
6.1 'It should be possible to make use of possiblities of temporal reference systems to express time at various levels of precision';
to:
6.2 'It should be possible to make use of possiblities of temporal reference systems to express components of time at various levels of precision'.

The requirement is for OWL Time to not restrict the freedom in expressions of time that some TRSs use. In OWL-Time the position of a time:Instant is either:

(i) xsd:dateTime – YYY-MM-DDTHH:MM:SS.ss[Z|(-)NN.NN] The only part that can be dropped is the Time Zone;

(ii) time:DateTimeDescription, which has separate properties for year, month, day etc. but with a 'mandatory' time:unitType.

It is this last property which specifies the precision. However, its range is limited to (Year,Month,Week,Day,Hour,Minute,Second) which is clearly not enough. The current definition is:

time:TemporalUnit
rdf:type owl:Class ;
rdfs:subClassOf owl:Thing ;
owl:oneOf (
time:unitSecond
time:unitMinute
time:unitHour
time:unitDay
time:unitWeek
time:unitMonth
time:unitYear
) ;
.
And each of the members of the enumeration is separately defined like:

time:unitWeek
rdf:type time:TemporalUnit ;
.
Etc.

So this was relaxed to:

time:TemporalUnit
rdf:type owl:Class ;
rdfs:subClassOf owl:Thing ;
.

This leaves the definitions of the existing enumeration in place so they are still available, but opening it up to other values of rdf:type time:TemporalUnit.

7. The US Library of Congress has proposed the EDTF (Extended Date/Time Format) as Part 2 extension to ISO 8601, not by pairs of intervals, but by adding a '~' or '?' operators to accompany any ISO 8601 expression allowing examples such as "circa 560CE" or "sometime in the early 1920's. Unknown values are specified using the character 'u', as in "2016-uu-26".

This was presented and discussed at a face to face meeting in Barcelona, and rejected as not mature (e.g. references to Summer and Winter without location) and perhaps inappropriate for modern open computing environments (e.g. the use of '?' but not for a query).

8. Attempt to clarify terminology used:
8.1 Temporal System: notation, events, relations/operators
8.2 Temporal Reference System: notation, relations/operators, clocks, counts
8.3 Temporal Coordinate Reference System: notation, relations/operators, instants, durations, UoM, Axis, Epoch
8.4 Calendar: notation, units, periods, origin (epoch?), underpinning TRS or TCRS, algorithms.

Refer to official definitions of these terms, if they exist. Examples of each class:
geological time scale: <https://en.wikipedia.org/wiki/Geologic_time_scale>,
the three-age system : <https://en.wikipedia.org/wiki/Three-age_system>,
UNIX time: <https://en.wikipedia.org/wiki/Unix_time>,
Chronology of the universe: <https://en.wikipedia.org/wiki/Chronology_of_the_universe> or the
Conventional Egyptian chronology:
<https://en.wikipedia.org/wiki/Egyptian_chronology#Conventional_chronology>:

9. We should keep the basic requirement as it is ("It should be possible to describe time points and intervals in a vague, imprecise manner.").

A more extensive list of examples includes:

- An event happened at the second quarter of the 9th century (the calendar used for this fact is unknown)
- Something occured in the afternoon of July 1st, 2011 (the time interval 'afternoon' is not precisely defined)
- A photo is known to be taken on a Christmas Day (the year is unknown).
- An event took place in the later part of the Jurassic (with 'later part' being imprecise, as opposed to 'Late Jurassic')

This is is not a good example:
- Something is known to take place somewhere in August 2020 (only year and month are known)

Some Temporal Reference Systems (TRS) can express time at various levels of precision. August 2020 can be expressed in ISO8601, as the standard allows truncation from the right, but not the left (I.e 2020-08 is valid, but 12-25 for an unknown Christmas Day is not.) It can also be expressed as xsd:gYearMonth.

For "12-25" there is no valid ISO8601 expression or xsd datatype. It could be expressed in EDTF Level 2 as "uuuu-12-25".

> 4. Temporal 'fuzziness' could also be accomodated by using pairs of intervals. OWL-Time restricts the range of the 'hasBeginning' and 'hasEnd' properties to Instant. If extended to include Intervals, ...

> But OWL-Time does this already. Allen’s algebra (1983) makes intervals the primary structure, and instants a special case where we can not distinguish the beginning and end, at the current level of precision. No change in the OWL-Time ontology.

However
:hasBeginning rdfs:range :Instant .
:hasEnd rdfs:range :Instant .
:ProperInterval owl:disjointWith :Instant .
so I think this means that the beginning and end of a :TemporalEntity (including :Interval) must be an entity of zero length at the current precision. If precision increases and the length of the bounding entity is therefore finite, then there may be an inconsistency.

The description of the requirement was changed: more examples were added.

https://www.w3.org/TR/sdw-ucr/#TemporalVagueness relates