New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Express open-ended intervals in temporalCoverage #1365

Closed
tfrancart opened this Issue Sep 14, 2016 · 37 comments

Comments

Projects
None yet
@tfrancart
Contributor

tfrancart commented Sep 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 1, 2018

Contributor

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 #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).
Contributor

danbri commented Mar 1, 2018

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 #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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 1, 2018

Contributor

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

Contributor

danbri commented Mar 1, 2018

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

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 1, 2018

Contributor
  • 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!)

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.

Contributor

danbri commented Mar 1, 2018

  • 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!)

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

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Mar 1, 2018

@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

thadguidry commented Mar 1, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 1, 2018

Contributor

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

Contributor

danbri commented Mar 1, 2018

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

@nicholascar

This comment has been minimized.

Show comment
Hide comment
@nicholascar

nicholascar Mar 2, 2018

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.

nicholascar commented Mar 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@RichardWallis

RichardWallis Mar 2, 2018

Contributor

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.

Contributor

RichardWallis commented Mar 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tfrancart

tfrancart Mar 2, 2018

Contributor
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.

Contributor

tfrancart commented Mar 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Mar 2, 2018

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 ?

thadguidry commented Mar 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@RichardWallis

RichardWallis Mar 2, 2018

Contributor

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.

Contributor

RichardWallis commented Mar 2, 2018

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

This comment has been minimized.

Show comment
Hide comment
@dr-shorthair

dr-shorthair Mar 5, 2018

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.

dr-shorthair commented Mar 5, 2018

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

This comment has been minimized.

Show comment
Hide comment
@akuckartz

akuckartz Mar 5, 2018

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

akuckartz commented Mar 5, 2018

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

@dr-shorthair

This comment has been minimized.

Show comment
Hide comment
@dr-shorthair

dr-shorthair Mar 5, 2018

  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.

dr-shorthair commented Mar 5, 2018

  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.
@rvguha

This comment has been minimized.

Show comment
Hide comment
@rvguha

rvguha Mar 5, 2018

Contributor
Contributor

rvguha commented Mar 5, 2018

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 5, 2018

Contributor
Contributor

danbri commented Mar 5, 2018

@natashafn

This comment has been minimized.

Show comment
Hide comment
@natashafn

natashafn Mar 5, 2018

@rvguha : The use case in the Dataset world is to describe a dataset where the data is being collected continuously. Basically, you want to say something like "temporal coverage of this dataset is from 2000 to present". We had several requests along these lines. Doesn't require anything too fancy though.

natashafn commented Mar 5, 2018

@rvguha : The use case in the Dataset world is to describe a dataset where the data is being collected continuously. Basically, you want to say something like "temporal coverage of this dataset is from 2000 to present". We had several requests along these lines. Doesn't require anything too fancy though.

@rvguha

This comment has been minimized.

Show comment
Hide comment
@rvguha

rvguha Mar 5, 2018

Contributor
Contributor

rvguha commented Mar 5, 2018

@natashafn

This comment has been minimized.

Show comment
Hide comment
@natashafn

natashafn Mar 5, 2018

Completely agree: something simple will suffice.

natashafn commented Mar 5, 2018

Completely agree: something simple will suffice.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 5, 2018

Contributor
Contributor

danbri commented Mar 5, 2018

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 12, 2018

Contributor

I just left a comment in our wrong issue (the more general uncertain dates discussion, #242 (comment) ). Copying in from there:

Looking at this again, I would like Schema.org to tentatively endorse the pattern "1982-11/.."
for meaning "// End datetime open." as seen in JohnLukeBentley/open-datetime-standard-bootstrap#2 while we await ISO's official update to ISO 8601. ISO make it difficult for us by hiding their specs away and asking LOC to take down the EDTF note, but it seems that for the specific case of open-ended date ranges (needed e.g. for Dataset description), "1982-11/.." looks like the best current guess. This is not quite the "uncertain dates" issue but a related smaller part.

See also related discussion from another group frustrated by the opacity of the ISO 8601 update process.

I propose the following stopgap action:

  • Update https://schema.org/temporalCoverage to say something like this (but more concise): "In tentative anticipation of possible updates to the ISO 8601 standard, open-ended date ranges can be described using ".." in place of the end date. For example, "1982-11/.." indicates a range beginning in November 1982 and with no specified final date. This recommendation might be updated in future as consensus around the related standards developers".
  • Wait for ISO 8601 revisions to be published and try to track them, if they address this usecase.
Contributor

danbri commented Jul 12, 2018

I just left a comment in our wrong issue (the more general uncertain dates discussion, #242 (comment) ). Copying in from there:

Looking at this again, I would like Schema.org to tentatively endorse the pattern "1982-11/.."
for meaning "// End datetime open." as seen in JohnLukeBentley/open-datetime-standard-bootstrap#2 while we await ISO's official update to ISO 8601. ISO make it difficult for us by hiding their specs away and asking LOC to take down the EDTF note, but it seems that for the specific case of open-ended date ranges (needed e.g. for Dataset description), "1982-11/.." looks like the best current guess. This is not quite the "uncertain dates" issue but a related smaller part.

See also related discussion from another group frustrated by the opacity of the ISO 8601 update process.

I propose the following stopgap action:

  • Update https://schema.org/temporalCoverage to say something like this (but more concise): "In tentative anticipation of possible updates to the ISO 8601 standard, open-ended date ranges can be described using ".." in place of the end date. For example, "1982-11/.." indicates a range beginning in November 1982 and with no specified final date. This recommendation might be updated in future as consensus around the related standards developers".
  • Wait for ISO 8601 revisions to be published and try to track them, if they address this usecase.
@retorquere

This comment has been minimized.

Show comment
Hide comment
@retorquere

retorquere Jul 12, 2018

Just a few general comments:

  • 1982-Q4-XX // A year-quarter, with the day unspecified. Some day in the quarter.; not sure what the purpose of XX is here (wouldn't 1982-Q4 say the same?) other than perhaps than saying it was a single day event -- but if that is the purpose, how do I express a week-long event in 1982-Q4?
  • I still don't like <no value> for unknown, both for conceptual reasons (explicit over implicit) but also pragmatic reasons (I have to parse date soup, and nothing-means-something makes my life harder).
  • I am not sure what the strikeouts mean in the text. Are they part of the date format, or ways of saying "there used to be something here, but we've decided to do it another way"?

retorquere commented Jul 12, 2018

Just a few general comments:

  • 1982-Q4-XX // A year-quarter, with the day unspecified. Some day in the quarter.; not sure what the purpose of XX is here (wouldn't 1982-Q4 say the same?) other than perhaps than saying it was a single day event -- but if that is the purpose, how do I express a week-long event in 1982-Q4?
  • I still don't like <no value> for unknown, both for conceptual reasons (explicit over implicit) but also pragmatic reasons (I have to parse date soup, and nothing-means-something makes my life harder).
  • I am not sure what the strikeouts mean in the text. Are they part of the date format, or ways of saying "there used to be something here, but we've decided to do it another way"?
@thadguidry

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Jul 12, 2018

@danbri A general +1 from me, although the solidus character still makes me shudder (Thanks ISO for picking a character that actually shows up in Dates!!! pffft) , the ".." for describing continuation is much better than "contd" or "--" or "∞" !

thadguidry commented Jul 12, 2018

@danbri A general +1 from me, although the solidus character still makes me shudder (Thanks ISO for picking a character that actually shows up in Dates!!! pffft) , the ".." for describing continuation is much better than "contd" or "--" or "∞" !

@natashafn

This comment has been minimized.

Show comment
Hide comment
@natashafn

natashafn Jul 12, 2018

@danbri : +1 for ".." the open interval

natashafn commented Jul 12, 2018

@danbri : +1 for ".." the open interval

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 12, 2018

Contributor

@retorquere - are you reviewing the entire BibliographicDatetimeFormat.pdf document? At this point I'm only proposing we start using one small piece, the "1918/.." notation.

Contributor

danbri commented Jul 12, 2018

@retorquere - are you reviewing the entire BibliographicDatetimeFormat.pdf document? At this point I'm only proposing we start using one small piece, the "1918/.." notation.

@retorquere

This comment has been minimized.

Show comment
Hide comment
@retorquere

retorquere Jul 13, 2018

review is perhaps too strong a word -- I went through it and these points stuck out to me

retorquere commented Jul 13, 2018

review is perhaps too strong a word -- I went through it and these points stuck out to me

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 13, 2018

Contributor

I also asked on Twitter. Considering response here, there, and in particular the detailed sanity check and background perspective offered by @JohnLukeBentley, I think we can safely go with "..". I'll get something implemented for final review.

Contributor

danbri commented Jul 13, 2018

I also asked on Twitter. Considering response here, there, and in particular the detailed sanity check and background perspective offered by @JohnLukeBentley, I think we can safely go with "..". I'll get something implemented for final review.

danbri added a commit that referenced this issue Jul 13, 2018

@danbri danbri closed this in 06acf81 Jul 13, 2018

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 13, 2018

Contributor

Queued for review, http://webschemas.org/temporalCoverage

New paragraph is

ISO 8601, open-ended date ranges can be written with ".." in place of the end date. For example, "2015-11/.." indicates a range beginning in November 2015 and with no specified final date. This is tentative and this syntax might be updated in future when ISO 8601 is officially updated.

Comments welcomed here.

Contributor

danbri commented Jul 13, 2018

Queued for review, http://webschemas.org/temporalCoverage

New paragraph is

ISO 8601, open-ended date ranges can be written with ".." in place of the end date. For example, "2015-11/.." indicates a range beginning in November 2015 and with no specified final date. This is tentative and this syntax might be updated in future when ISO 8601 is officially updated.

Comments welcomed here.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 13, 2018

Contributor

(Tweaked it slightly, I've removed the redundant "ISO 8601" from start of first sentence)

Contributor

danbri commented Jul 13, 2018

(Tweaked it slightly, I've removed the redundant "ISO 8601" from start of first sentence)

@JohnLukeBentley

This comment has been minimized.

Show comment
Hide comment
@JohnLukeBentley

JohnLukeBentley Jul 14, 2018

Why not, for completeness ...

... can be written with ".." in place of the start date or end date.

?

Is it a matter of readily thinking of CreativeWork cases where the end date is open, as might occur with a community developed technical document (perhaps schemga.org itself); while being unable to think of cases where a CreativeWork would have an open start (these later cases don't readily spring to my mind)?

Edit: inserted "where"

JohnLukeBentley commented Jul 14, 2018

Why not, for completeness ...

... can be written with ".." in place of the start date or end date.

?

Is it a matter of readily thinking of CreativeWork cases where the end date is open, as might occur with a community developed technical document (perhaps schemga.org itself); while being unable to think of cases where a CreativeWork would have an open start (these later cases don't readily spring to my mind)?

Edit: inserted "where"

@thadguidry

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Jul 14, 2018

@JohnLukeBentley Describe an "open" start date / time. Something that has a long beginning ? (but it had a definite beginning and isn't the long part technically covered by what is between some beginning and a piece of the interval after that) ?

If we have a need to say that something is planned for starting, but the start date is unknown or open, then perhaps ".." could be used for that. However, I want to point out that in other systems an unknown is different than the idea of open, approximate, or circa. In scientific circles, they deal with uncertainty information and margin of errors and uncalibrated dates, where it's common to see "+-" or "cal" or confidence level "σ" , but that's much different than the usage case of "open" for date ranges, which is really the Simple English way to say an unbounded interval.

Do we really want to say that the symbol ".." will symbolize both open and unknown ?
I personally oppose squashing the concepts of open ".." and circa "c.", margin of error "+-", etc.
I am OK with using ".." on start date for the purpose of planning systems to say open or unknown.

thadguidry commented Jul 14, 2018

@JohnLukeBentley Describe an "open" start date / time. Something that has a long beginning ? (but it had a definite beginning and isn't the long part technically covered by what is between some beginning and a piece of the interval after that) ?

If we have a need to say that something is planned for starting, but the start date is unknown or open, then perhaps ".." could be used for that. However, I want to point out that in other systems an unknown is different than the idea of open, approximate, or circa. In scientific circles, they deal with uncertainty information and margin of errors and uncalibrated dates, where it's common to see "+-" or "cal" or confidence level "σ" , but that's much different than the usage case of "open" for date ranges, which is really the Simple English way to say an unbounded interval.

Do we really want to say that the symbol ".." will symbolize both open and unknown ?
I personally oppose squashing the concepts of open ".." and circa "c.", margin of error "+-", etc.
I am OK with using ".." on start date for the purpose of planning systems to say open or unknown.

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 14, 2018

Contributor
Contributor

danbri commented Jul 14, 2018

@JohnLukeBentley

This comment has been minimized.

Show comment
Hide comment
@JohnLukeBentley

JohnLukeBentley Jul 15, 2018

@thadguidry and @danbri ...

thadguidry wrote

If we have a need to say that something is planned for starting, but the start date is unknown or open, then perhaps ".." could be used for that. ... However, I want to point out that in other systems an unknown is different than the idea of open, approximate, or circa. ... I am OK with using ".." on start date for the purpose of planning systems to say open or unknown.

In the Bibliographic Datetime Format's Bibliographic ISO 8601 Profile (BP) (and so my unverified interpretation of (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) all those things are kept distinct. See:

  • Unknown in interval rule. (|BDF|, 32, sec. 3.1.11 Interval)
  • Open in interval rule. (|BDF|, 32, sec. 3.1.11 Interval)
  • Interval rule. (|BDF|, 31, sec. 3.1.11 Interval)
  • Approximate rule. (|BDF|, 30, sec. 3.1.10 Qualified Date)
  • Uncertain rule. (|BDF|, 30, sec. 3.1.10 Qualified Date)
  • Approximate-and-uncertain rule (|BDF|, 30-31, sec. 3.1.10 Qualified Date)

In particular something like ../1490 is only used where the start date is open. For a start date that is unknown then /1490 would be used (noting @retorquere supplies the right reasons above why we should think ISO has chosen poorly in using a blank for unknown).

Describe an "open" start date / time. ... which is really the Simple English way to say an unbounded interval.

Yes although ISO doesn't supply a definition of "open" in intervals I think it best to interpret this as a synonym for "unbounded".

danbri

It's more that the more we guess at possible 8601 revisions, the deeper we end up lost in our own "choose your own datetime standards" adventure.

Yes that could well be a precaution to take. That is, you could take the position that you'll only implement current stipulations, whether by looking directly at (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)| to level 1, not level 2) or via the Bibliographic ISO 8601 Profile in Bibliographic Datetime Format, so long as they constitute popular use cases. Because the popular use cases are going to be less at risk; or, regardless of the risk, you want to use something now for the popular cases and to deal with the less popular cases after ISO releases its standard.

Under that position you may well want to not support ../1600 to express "Japan prior to the Dutch arriving".

However, perhaps ironically, that position ends up being a "choose your own datetime standards" adventure of a sort ... minimally by constituting a subsetting of whatever datetime standard you are using as your foundation. If you want to formalise that subsetting then (|BDF|, 6-7. secs. 3.3.1 Conformance Types - 2.3.3 Generalizing the concept of a Standard-Transformation) may be of help.

I can think of CreativeWork usecases for "../", e.g. autobiography of someone with unknown birthday but known date of death (or publication).

As above, if you wanted to follow ISO's draft, you'd use blank for unknown. For "open" in an interval is distinct from "unknown" in an interval. So Alice Parker's lifespan is /1692-09-22. That is, with an unknown (not open) start date and a known death date. Her lifespan is not ../1692-09-22.

However, if it was an autobiography from someone who was unsure of their birthdate then, assuming they were also ISO aficionado's, then more likely be able to approximate their birthdate for a lifespan of 1955~/. That is, approximate (circa) start date with an unknown end date (if the author wants to avoid approximating their date of death while, nevertheless, reaming too skeptical about the possibility of life extension breakthroughs to regard their date of death as unbounded).

There is sometimes a grayness is interpreting whether a date in an interval is open or unknown. But that grayness need not count against keeping the two notions conceptually distinct, and not need count against a straightforward application for most cases.

But note a book about "Japan before the Dutch", "Alice Parker", or an autobiography by an author who is ensure of their birthday - would ordinarily have publishing dates that are distinct from their subject matter. The autobiography may well, for example, be straightforwardly published in 2004. Nevertheless older works (e.g. in the medieval period) often enough have indistinct publishing dates. Instead these works are often identified as written over an interval spanning years. Some of these works, I assume, have no distinct start date (so the start date may be judged to be unknown or approximated, depending on the particulars of the historical scholarship). But, again, you might sensibly want hold off on handling these edge cases until ISO releases its standard.

If we allow both, is "../.." allowed but uninformative, or disallowed?

It is Bibliographic ISO 8601 Profile VALID (See "Open in Interval Rule", |BDF|, 32, sec. 3.1.11 Interval). Whether you can think of a possible application for this for a CreativeWork is a separate matter.

In short, it seems your choice is between:

  • Holding off on edges cases until ISO publishes its standard, in which case if you wanted to also do some formal subsetting (|BDF|, 6-7. secs. 3.3.1 Conformance Types - 2.3.3 Generalizing the concept of a Standard-Transformation) may be of help; or
  • Implementing all the formats ISO currently stipulates in it's draft Annex C to level 1, whether by looking directly at (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)| to level 1, not level 2) or via the Bibliographic ISO 8601 Profile in Bibliographic Datetime Format. For this option all the cases currently at issue in this thread seem to be handled (I've only skimmed the topmost posts). But if you think there's a schema.org relevant case ISO or BDF doesn't handle then please do mention them.

All this is based on my assuming that for schema.org purposes were are confining ourselves to the topic of datetimes for bibliographic purposes (as would be required when identifying the published datetime of a creative work). If we want to talk about schema.org metadata for datetimes more generally (I'm not clear of the extent to which that need exists) then the discussion has to head off in a further direction.

JohnLukeBentley commented Jul 15, 2018

@thadguidry and @danbri ...

thadguidry wrote

If we have a need to say that something is planned for starting, but the start date is unknown or open, then perhaps ".." could be used for that. ... However, I want to point out that in other systems an unknown is different than the idea of open, approximate, or circa. ... I am OK with using ".." on start date for the purpose of planning systems to say open or unknown.

In the Bibliographic Datetime Format's Bibliographic ISO 8601 Profile (BP) (and so my unverified interpretation of (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) all those things are kept distinct. See:

  • Unknown in interval rule. (|BDF|, 32, sec. 3.1.11 Interval)
  • Open in interval rule. (|BDF|, 32, sec. 3.1.11 Interval)
  • Interval rule. (|BDF|, 31, sec. 3.1.11 Interval)
  • Approximate rule. (|BDF|, 30, sec. 3.1.10 Qualified Date)
  • Uncertain rule. (|BDF|, 30, sec. 3.1.10 Qualified Date)
  • Approximate-and-uncertain rule (|BDF|, 30-31, sec. 3.1.10 Qualified Date)

In particular something like ../1490 is only used where the start date is open. For a start date that is unknown then /1490 would be used (noting @retorquere supplies the right reasons above why we should think ISO has chosen poorly in using a blank for unknown).

Describe an "open" start date / time. ... which is really the Simple English way to say an unbounded interval.

Yes although ISO doesn't supply a definition of "open" in intervals I think it best to interpret this as a synonym for "unbounded".

danbri

It's more that the more we guess at possible 8601 revisions, the deeper we end up lost in our own "choose your own datetime standards" adventure.

Yes that could well be a precaution to take. That is, you could take the position that you'll only implement current stipulations, whether by looking directly at (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)| to level 1, not level 2) or via the Bibliographic ISO 8601 Profile in Bibliographic Datetime Format, so long as they constitute popular use cases. Because the popular use cases are going to be less at risk; or, regardless of the risk, you want to use something now for the popular cases and to deal with the less popular cases after ISO releases its standard.

Under that position you may well want to not support ../1600 to express "Japan prior to the Dutch arriving".

However, perhaps ironically, that position ends up being a "choose your own datetime standards" adventure of a sort ... minimally by constituting a subsetting of whatever datetime standard you are using as your foundation. If you want to formalise that subsetting then (|BDF|, 6-7. secs. 3.3.1 Conformance Types - 2.3.3 Generalizing the concept of a Standard-Transformation) may be of help.

I can think of CreativeWork usecases for "../", e.g. autobiography of someone with unknown birthday but known date of death (or publication).

As above, if you wanted to follow ISO's draft, you'd use blank for unknown. For "open" in an interval is distinct from "unknown" in an interval. So Alice Parker's lifespan is /1692-09-22. That is, with an unknown (not open) start date and a known death date. Her lifespan is not ../1692-09-22.

However, if it was an autobiography from someone who was unsure of their birthdate then, assuming they were also ISO aficionado's, then more likely be able to approximate their birthdate for a lifespan of 1955~/. That is, approximate (circa) start date with an unknown end date (if the author wants to avoid approximating their date of death while, nevertheless, reaming too skeptical about the possibility of life extension breakthroughs to regard their date of death as unbounded).

There is sometimes a grayness is interpreting whether a date in an interval is open or unknown. But that grayness need not count against keeping the two notions conceptually distinct, and not need count against a straightforward application for most cases.

But note a book about "Japan before the Dutch", "Alice Parker", or an autobiography by an author who is ensure of their birthday - would ordinarily have publishing dates that are distinct from their subject matter. The autobiography may well, for example, be straightforwardly published in 2004. Nevertheless older works (e.g. in the medieval period) often enough have indistinct publishing dates. Instead these works are often identified as written over an interval spanning years. Some of these works, I assume, have no distinct start date (so the start date may be judged to be unknown or approximated, depending on the particulars of the historical scholarship). But, again, you might sensibly want hold off on handling these edge cases until ISO releases its standard.

If we allow both, is "../.." allowed but uninformative, or disallowed?

It is Bibliographic ISO 8601 Profile VALID (See "Open in Interval Rule", |BDF|, 32, sec. 3.1.11 Interval). Whether you can think of a possible application for this for a CreativeWork is a separate matter.

In short, it seems your choice is between:

  • Holding off on edges cases until ISO publishes its standard, in which case if you wanted to also do some formal subsetting (|BDF|, 6-7. secs. 3.3.1 Conformance Types - 2.3.3 Generalizing the concept of a Standard-Transformation) may be of help; or
  • Implementing all the formats ISO currently stipulates in it's draft Annex C to level 1, whether by looking directly at (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)| to level 1, not level 2) or via the Bibliographic ISO 8601 Profile in Bibliographic Datetime Format. For this option all the cases currently at issue in this thread seem to be handled (I've only skimmed the topmost posts). But if you think there's a schema.org relevant case ISO or BDF doesn't handle then please do mention them.

All this is based on my assuming that for schema.org purposes were are confining ourselves to the topic of datetimes for bibliographic purposes (as would be required when identifying the published datetime of a creative work). If we want to talk about schema.org metadata for datetimes more generally (I'm not clear of the extent to which that need exists) then the discussion has to head off in a further direction.

@JohnLukeBentley

This comment has been minimized.

Show comment
Hide comment
@JohnLukeBentley

JohnLukeBentley Jul 15, 2018

I'll also draw your attention to the fact that (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) already divides use cases into popularity levels, from more popular to less: levels 0, 1, and 2. Level 2 is for really freaky edge cases, e.g. (|ISO/DIS 8601-2:2016(e)|, 11)

1560-XX-25 ... The 25th day of some month in year 1560

Furthermore (|BDF|, 8, sec. 2.2.4.3 Levels)

The Bibliographic ISO 8601 Profile tracks (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) to level 1.

That is, the Bibliographic ISO 8601 Profile, as it stands, is already sub-setting.

JohnLukeBentley commented Jul 15, 2018

I'll also draw your attention to the fact that (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) already divides use cases into popularity levels, from more popular to less: levels 0, 1, and 2. Level 2 is for really freaky edge cases, e.g. (|ISO/DIS 8601-2:2016(e)|, 11)

1560-XX-25 ... The 25th day of some month in year 1560

Furthermore (|BDF|, 8, sec. 2.2.4.3 Levels)

The Bibliographic ISO 8601 Profile tracks (|EDTF 8601 Profile - Annex C in ISO/DIS 8601-2:2016(e)|) to level 1.

That is, the Bibliographic ISO 8601 Profile, as it stands, is already sub-setting.

@thadguidry

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Jul 15, 2018

@JohnLukeBentley Just to clarify something... Do you think that ISO is aligned with saying "open" when fully expanded actually means "open to be changed" ? The phrase "the date is open", really should be fully expanded to "the date is open to be changed in the future" ? If that's the case, there is a call out for the planning concept of "tentative" as well. :-) How does that symbolization look like for a startDate ?

@danbri the decision is also going to affect us here: https://pending.schema.org/Schedule Where maybe for the benefit of consumers, we just call a spade a spade, and add 2 new properties... "tentativeStartDate" "tentativeEndDate" so we don't have to get caught up in symbolism for those. Tentative-ness (intent) goes both ways, for those planners trying to hold/reserve a place, as well as attendees acknowledging their intent to go (like is MS Outlook and online calendars). If we provided planners/schedulers with "tentativeStartDate" and "tentativeEndDate" for Event planning, they would likely use those instead of using symbolism on "startDate" and "endDate" to express that. Some of that was talked about in #1029

thadguidry commented Jul 15, 2018

@JohnLukeBentley Just to clarify something... Do you think that ISO is aligned with saying "open" when fully expanded actually means "open to be changed" ? The phrase "the date is open", really should be fully expanded to "the date is open to be changed in the future" ? If that's the case, there is a call out for the planning concept of "tentative" as well. :-) How does that symbolization look like for a startDate ?

@danbri the decision is also going to affect us here: https://pending.schema.org/Schedule Where maybe for the benefit of consumers, we just call a spade a spade, and add 2 new properties... "tentativeStartDate" "tentativeEndDate" so we don't have to get caught up in symbolism for those. Tentative-ness (intent) goes both ways, for those planners trying to hold/reserve a place, as well as attendees acknowledging their intent to go (like is MS Outlook and online calendars). If we provided planners/schedulers with "tentativeStartDate" and "tentativeEndDate" for Event planning, they would likely use those instead of using symbolism on "startDate" and "endDate" to express that. Some of that was talked about in #1029

@mfhepp

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp Jul 16, 2018

Contributor
Contributor

mfhepp commented Jul 16, 2018

@JohnLukeBentley

This comment has been minimized.

Show comment
Hide comment
@JohnLukeBentley

JohnLukeBentley Jul 16, 2018

@thadguidry the issue of tentative dates, in the context of event planning, is interesting.

Let's have three examples:

  1. A hippy festival is planned to committed to start on 2018-07-16 but end around 2018-07-25, the end date just depending on when the last stragglers leave.
  2. We arrange to begin work on a technical FAQ (to use @danbri's example) on 2018-07-16 to finish in about 2 months times, although it is understood there's no deadline: the work will be finished when it is judged to be finished.
  3. You and I plan on a walk 2018-07-16, "tentatively", in the sense that we both know either of us may cancel.

There's a sense in which all of these examples involve "tentative" dates.

From (|ISO/DIS 8601-2:2016(e)|, 6–7, sec. 3 Terms and definitions):

3.1 uncertain. date whose source is considered dubious.
3.2 approximate. date which is an estimate whose value is asserted to be possibly correct, and if not,
close to correct. Note 1 to entry: Where 'close to correct' means "close enough, for the application".

The first case might best be taken care of with an ISO VALID 2018-07-16/2018-07-25~, recalling tilde ~ is the symbol for Approximate (circa).

The second case might best be taken care of with ISO VALID "open" interval, as: 2018-07-16/.. (although you could, alternatively, make an argument for an "unknown" interval, as 2018-07-16/). In this sense "open" is "unbounded" because "the [end] date is open to be changed in the future" (rather than "unbounded" because infinite).

The third case could be taken care of with an ISO VALID 2018-07-16?, recalling ? is the symbol for uncertain. But that would be shoe-horning the meaning of "uncertain" given the ISO supplied definition of "date whose source is considered dubious". In our case the sources, ourselves when planning a walk, are not considered dubious. Rather, what's dubious is our plan.

Note ...

From (|ISO/DIS 8601-1:2016(e)|, 7, sec. 1 Scope):

This International Standard does not assign any particular meaning or interpretation to any data
element that uses representations in accordance with this International Standard. Such meaning will be
determined by the context of the application

Given that ISO does supply definitions for concepts, like "uncertain" and "approximate", that might be self-contradictory: it seems to suggest they are supplying guidance on interpretation while also claiming not to. But perhaps we can understand the quoted passage to express that each software system (or convention like schema.org) as a great deal of interpretive latitude. That is, I don't think anyone could fairly charge you with violating the ISO standard if you used ? for a tentative date.

The other possible ISO VALID formats you could avail yourself of, depending on what you have in mind for "tentative", are the "unspecifieds" (|BDF|, 29, sec. 3.1.8 Unspecified), E.g.

Year and month specified, day unspecified; Some day in a month; YYYY-MM-XX, 2019-02-XX

In conclusion, and without my head being properly in the needs of schema.org, for simplicity your choice is perhaps between:

  1. "[providing] planners/schedulers with "tentativeStartDate" and "tentativeEndDate" for Event planning, they would likely use those instead of using symbolism on "startDate" and "endDate" to express that."; and
  2. Stipulating that "?", for "uncertain", understood to mean "tentative" in this context, when affixed to a datetime entered into "startDate" or "endDate".

JohnLukeBentley commented Jul 16, 2018

@thadguidry the issue of tentative dates, in the context of event planning, is interesting.

Let's have three examples:

  1. A hippy festival is planned to committed to start on 2018-07-16 but end around 2018-07-25, the end date just depending on when the last stragglers leave.
  2. We arrange to begin work on a technical FAQ (to use @danbri's example) on 2018-07-16 to finish in about 2 months times, although it is understood there's no deadline: the work will be finished when it is judged to be finished.
  3. You and I plan on a walk 2018-07-16, "tentatively", in the sense that we both know either of us may cancel.

There's a sense in which all of these examples involve "tentative" dates.

From (|ISO/DIS 8601-2:2016(e)|, 6–7, sec. 3 Terms and definitions):

3.1 uncertain. date whose source is considered dubious.
3.2 approximate. date which is an estimate whose value is asserted to be possibly correct, and if not,
close to correct. Note 1 to entry: Where 'close to correct' means "close enough, for the application".

The first case might best be taken care of with an ISO VALID 2018-07-16/2018-07-25~, recalling tilde ~ is the symbol for Approximate (circa).

The second case might best be taken care of with ISO VALID "open" interval, as: 2018-07-16/.. (although you could, alternatively, make an argument for an "unknown" interval, as 2018-07-16/). In this sense "open" is "unbounded" because "the [end] date is open to be changed in the future" (rather than "unbounded" because infinite).

The third case could be taken care of with an ISO VALID 2018-07-16?, recalling ? is the symbol for uncertain. But that would be shoe-horning the meaning of "uncertain" given the ISO supplied definition of "date whose source is considered dubious". In our case the sources, ourselves when planning a walk, are not considered dubious. Rather, what's dubious is our plan.

Note ...

From (|ISO/DIS 8601-1:2016(e)|, 7, sec. 1 Scope):

This International Standard does not assign any particular meaning or interpretation to any data
element that uses representations in accordance with this International Standard. Such meaning will be
determined by the context of the application

Given that ISO does supply definitions for concepts, like "uncertain" and "approximate", that might be self-contradictory: it seems to suggest they are supplying guidance on interpretation while also claiming not to. But perhaps we can understand the quoted passage to express that each software system (or convention like schema.org) as a great deal of interpretive latitude. That is, I don't think anyone could fairly charge you with violating the ISO standard if you used ? for a tentative date.

The other possible ISO VALID formats you could avail yourself of, depending on what you have in mind for "tentative", are the "unspecifieds" (|BDF|, 29, sec. 3.1.8 Unspecified), E.g.

Year and month specified, day unspecified; Some day in a month; YYYY-MM-XX, 2019-02-XX

In conclusion, and without my head being properly in the needs of schema.org, for simplicity your choice is perhaps between:

  1. "[providing] planners/schedulers with "tentativeStartDate" and "tentativeEndDate" for Event planning, they would likely use those instead of using symbolism on "startDate" and "endDate" to express that."; and
  2. Stipulating that "?", for "uncertain", understood to mean "tentative" in this context, when affixed to a datetime entered into "startDate" or "endDate".
@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jul 18, 2018

Contributor

FWIW at Google we have updated the dataset markup documentation at https://developers.google.com/search/docs/data-types/datasets to encourage ".." for open-ended use. We aren't mentioning the ".." with other areas at this point. If the best practice evolves in a different direction, naturally we'll do our best to be backwards compatible for dataset publishers who've followed this guidance.

Contributor

danbri commented Jul 18, 2018

FWIW at Google we have updated the dataset markup documentation at https://developers.google.com/search/docs/data-types/datasets to encourage ".." for open-ended use. We aren't mentioning the ".." with other areas at this point. If the best practice evolves in a different direction, naturally we'll do our best to be backwards compatible for dataset publishers who've followed this guidance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment