Express open-ended intervals in temporalCoverage

[tfrancart]

See discussion at https://lists.w3.org/Archives/Public/public-schemaorg/2016Sep/0055.html
An idea would be to allow something similar to http://www.lyberty.com/meta/iso_8601.htm :

"""
Open Date Ranges

Some record-keeping metadata requires specification of date ranges.
For example, a Business Activity may only have been valid between the
years 1949 and 1953. ISO 8601 allows the specification of date ranges
using a forward slash (/) to separate dates representing the start and
end of the range. For example, "1949/1953". Recordkeeping metadata
also requires specification of open date ranges. For example, an
Agency may have an operational period from July 1st 1998 until the
present date. Open date ranges such as this are not defined in ISO
8601. The RKMS Extension to ISO 8601 allows open date ranges to be
specified by extending the ISO 8601 syntax to allow the omission of
either the start or end date in the range. Acceptable RKMS date ranges
are then:

Closed date range: DateTime/DateTime (e.g. 1949/1953-01-01)
Date range with unknown start: /DateTime (e.g. /2000-12-31T11:59:59)
Date range with no end date: DateTime/ (e.g. 1998-07-01/)"""

[danbri]

I very nearly made a new issue, but then discovered #1365 - thanks @tfrancart ! I will share my notes here instead.

(Dataset) temporalCoverage - idiom to represent open-ended/ongoing date range

A question that arose within Google as we work on dataset search:

"Datasets --- how does one indicate that it is, say 2000 to present (basically, continuous)? Is there a way?""

looking at temporalCoverage

"The temporalCoverage of a CreativeWork indicates the period that the content applies to, i.e. that it describes, either as a DateTime or as a textual string indicating a time period in ISO 8601 time interval format. In the case of a Dataset it will typically indicate the relevant time period in a precise notation (e.g. for a 2011 census dataset, the year 2011 would be written "2011/2012"). "

This suggests the ISO 8601 notation is the place to look. However it is not immediately obvious from https://en.wikipedia.org/wiki/ISO_8601#Time_intervals

Since the date of "the present" keeps changing, and often nobody knows for sure when a time series will stop, it seems like there's a need for an idiom that means "continuing indefinitely, but probably not until the end of time". Do conventions for this exist in ISO-8601 time intervals, in the DCAT community, or other dataset-related metadata standards?

I looked around, found some prior discussion:

• on Stack Overflow, a very recent answer says "No, it is up to you how you interprete the end marker of an interval. The actual valid ISO-8601-version is silent about open or closed interval boundaries. And its appendix containing examples does not mention infinite intervals at all. There is no word about how to express such infinite boundaries as text." ... but mentions that an open interval notation (possible '..') is under consideration.
• in the W3C Schema.org CG, it also appears that some characters called @RichardWallis and @danbri discussed exactly this matter in 2016. Naturally I remembered nothing of this.
• having gone to the trouble of writing up this "new" issue, I now see that @tfrancart had the forsight to do this back in 2016, issue Express open-ended intervals in temporalCoverage #1365. I did search for older discussions but made the mistake of scoping my queries with "dataset"; the issue is clearly broader (e.g. Legislation and other creative works).

[danbri]

I have also just posted in the W3C Datasets WG, hoping others there are tuned in to any emerging best practices.

[danbri]

• From the Stack Overflow post I linked,

Future version of ISO-8601:

A new version will come. The draft of the second part suggests for 
example in its section 4.4 different representations like 
"../2018-05-14" where the double dot would be interpreted as 
open (=missing) start.

So in the future, yes, you can probably express infinite interval 
boundaries but I still miss any word about open versus closed 
boundaries (open=exclusive, closed=inclusive).

See also the actual ISO site for work in progress, https://www.iso.org/standard/70908.html (only 58 CHF!)

• From the earlier CG mail thread, a nearby discussion (with @akuckartz @philipashlock @justgrimes @rebeccawilliams @pandzel ...): Guidance on use of temporal date interval with no final end date project-open-data/project-open-data.github.io#415

• From http://www.lyberty.com/meta/iso_8601.htm also discussed previously,

RKMS Extension for ISO 8601 - Open Date Ranges
 ISO 8601 allows the specification of date ranges using a forward slash (/) to 
separate dates representing the start and end of the range. 
For example, "1949/1953". Recordkeeping metadata also 
requires specification of open date ranges. For example, 
an Agency may have an operational period from 
July 1st 1998 until the present date. Open date ranges 
such as this are not defined in ISO 8601. The RKMS Extension 
to ISO 8601 allows open date ranges to be specified by 
extending the ISO 8601 syntax to allow the omission 
of either the start or end date in the range. Acceptable 
RKMS date ranges are then:

Closed date range: DateTime/DateTime (e.g. 1949/1953-01-01)
Date range with unknown start: /DateTime (e.g. /2000-12-31T11:59:59)
Date range with no end date: DateTime/ (e.g. 1998-07-01/)

The RKMS work seems to be an old effort from within the Dublin Core Metadata Initiative.

[thadguidry]

@danbri The term is called "unbounded" (sometimes called "infinite"). This terminology is used in a lot of FOSS software projects that deal with Datasets. A Twitter stream is an example of an unboundedDataset. The use case that Google deals with (and others) is showcased in this article https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101

As far as Characters that signify an unbounded set ... In mathematics there is Interval Notation that handles this... https://en.wikipedia.org/wiki/Interval_(mathematics)#Notations_for_intervals

In programming, it is simply the omission or absence of an "end point" or "start point", as you found. And most good libraries know how to deal with this.
https://github.com/JodaOrg/joda-time/blob/master/src/main/java/org/joda/time/format/DateTimeParserBucket.java#L582 - null means infinite
http://www.joda.org/joda-time/key.html - Concepts

[danbri]

Thanks @thadguidry! "Infinite" seems a bit optimistic :)

[nicholascar]

Is there an OWL Time view of open-ended time intervals? It looks to me as though it would simply be a time:Interval (or perhaps better a time:ProperInterval) with no time:intervalFinishes or time:intervalFinishedBy property given.

This is likely to address unp-and-coming Dataset best practice given the recent ratification of v2 of OWL Time as a Recommendation and also the overlapping OWL Time and DXWG people.

[RichardWallis]

Looking in to the library metadata world, that have been doing this sort of stuff in data formats since the late 1960's (and on bits of card from a little while earlier). The convention is to separate two dates, and or times or date/times, with a separator '-' unknown values being omitted.
e.g.
Beethoven, Ludwig van, 1770-1827
Dangerfield, Rodney, 1921-

Mapping this to ISO 8601, and work such as RKMS mentioned earlier, I believe that the pragmatic approach would be to go for:

Closed date range: DateTime/DateTime (e.g. 1949/1953-01-01)
Date range with unknown start: /DateTime (e.g. /2000-12-31T11:59:59)
Date range with no end date: DateTime/ (e.g. 1998-07-01/)

There maybe several reasons for an unknown element in a date range: 'the thing has not finished yet', 'the person is still alive', 'we don't know', etc. So attaching labels such as 'infinite' may be a little misleading.

One of the suggestions in the links above was to use an ellipsis '...' in place of an unknown value. I would suggest with Schema.org being used across so many domains, some like libraries with their own practice, such a practice should only be an option not the only acceptable syntax.

[tfrancart]

Closed date range: DateTime/DateTime (e.g. 1949/1953-01-01)
Date range with unknown start: /DateTime (e.g. /2000-12-31T11:59:59)
Date range with no end date: DateTime/ (e.g. 1998-07-01/)

I agree with this approach. This seems the most reasonable and intuitive as it avoids any specific characters or words "...", "infinite", "unbounded", etc. that would be error prone.

[thadguidry]

I was not suggesting for us to use "infinite" or "unbounded". I was merely providing information from wider domains where Temporal Things are used especially concerning Datasets (my domain).

I am +1 on using some format convention to express "unknown", "no end date" for Date Intervals (Periods).
I am +1 on using /Datetime or Datetime/ to express an unbounded temporal range for Date Intervals (Periods).

Work needed: temporalCoverage also needs to have an expected subType of a Period as it says in its description...but Periods can be more than just Time based in the scientific / math / book world and also represent Sequences.

Pages [1,2,4-12,16-]
Sequence [5,6,7,...]

So are we also discussing all unbounded Interval types in this issue, not just Date Intervals ?
And which format convention is agreeable for those non-Date unbounded Intervals to help the scientific / math / book domains ?

[RichardWallis]

As the description of temporalCoverage is all time period based, I would expect that it, and any future subtypes, would constrain their description to time based issues.

I am not against using similar conventions to described unboundedness in other sequences such as you reference, for example on properties such as pagination or the proposed materialExtent property.

[dr-shorthair]

As hinted by @nicholascar above, OWL-Time does provide a model for temporal topology, based on Allen's interval alegebra. The OWL-Time model is summarized in Fig 1. here https://www.w3.org/TR/owl-time/#topology . I wouldn't suggest that the RDF serialization of OWL-Time is for everyone (particularly not in the schema.org context) but it can stabilize the terminology. In particular note that

1. an interval has beginning and end instants, and its extent is referred to as duration
2. an interval may be started and finished by (smaller) intervals (and there are a whole lot of other relationships between intervals shown in Figure 2).

OWL-Time does not explicitly say anything about closed- or open-ends. The Open World Assumption is that any information that is not stated is unknown. That is consistent with the idea that an open-ended interval is strictly just one whose end (or start) is not known or defined (yet), though it may have one some day ...

As far as serialization is concerned, if you are already committed to ISO 8601 style date-time notation, then going along with 8601's notation for intervals - using the '/' separator, and leaving one side blank - clearly makes sense.

[akuckartz]

Do SPARQL engines implement ISO 8601 intervals ? If not that would be a reason for me to dislike such intervals in SDO.

[dr-shorthair]

1. the OWL-Time spec is quite careful to point out that comparisons based on its temporal logic would not be supported natively by a basic OWL processor. Implicitly also not by a generic SPARQL engine.
2. schema.org is only weakly axiomatized so it is not clear that SPARQL processing is the appropriate criterion.