RE: Some background on Extended Date Time Format (EDTF) (was: ISSUE 14: temporal reasoning and relations)

I do have a concern with this approach. It amounts to embedding more and more information into a coded string. 
That information could be captured more explicitly by specific RDF predicates. 

Not that I am against micro-syntaxes in their place. 
There is some stuff that RDF is not good at (for example - ordered lists and arrays) so it is appropriate to break out into a micro-syntax sometimes. 

ISO 8601 and its web versions (xsd simple types) are almost universally accepted as a way to put 7 pieces of information in a string. 
But it is not clear to me that we should increase that to 8, 9 or 10! 
Maybe uncertainty belongs in a coded time-position, but let's not push this too far. 

Simon 

-----Original Message-----
From: Svensson, Lars [mailto:L.Svensson@dnb.de] 
Sent: Wednesday, 9 September 2015 5:24 AM
To: public-sdw-wg@w3.org
Cc: Denenberg, Ray <rden@LOC.GOV> (rden@LOC.GOV) <rden@LOC.GOV>
Subject: Some background on Extended Date Time Format (EDTF) (was: ISSUE 14: temporal reasoning and relations)

All,

On Wednesday, August 12, 2015 4:58 PM, Karl Grossner wrote:

[...]
> **************
> Further support for uncertain temporal expressions-- Contributed by 
> Karl Grossner <https://kgeographer.org> 2015-08-11
> 
> OWL-Time does support some uncertain expressions by means of interval 
> relations accounting for "before," "after," (sometime) "during," etc. 
> It does not allow for approximate and vague expressions such as "circa 
> 560 CE" or "sometime in the early 1920's." These could be covered in two ways:
> 
> 1. by allowing a '~' operator to accompany any ISO-8601 expression
> 
> 2. by allowing the hasBeginning and hasEnd elements to be specified by 
> intervals as well as by instants
> 
> e.g. the object of a hasEnd property could be an interval having 
> earliestEnd and latestEnd properties A number of further OWL-Time 
> extensions, such as adding an "uncertain"
> operator ('?') to '~', for an entire ISO-8601 expression or parts 
> thereof, are proposed in the fairly recent US Library of Congress 
> document, **"Extended Date/Time Format (EDTF) 1.0”** 
> <http://www.loc.gov/standards/datetime/pre-submission.html>

I've been in touch with Ray Denenberg from the Library of Congress (in cc) who is the primary editor of EDTF. He gave me some valuable background information on the document and allowed me to share that with the WG.

EDTF was developed on the request of Rebecca Guenther from the Library of Congress (LoC) who wanted a date/time format more friendly to library requirements. After the spec was published in its current form (2012-01-13) it was submitted to the W3C as a member submission (LoC is a W3C member) with the primary goal to make EDTF become a primitive data type (e. g. xs:edtf). The W3C rejected it as out of scope.

Ray then approached ISO and after quite some time he got the attention of TC154 where ISO 8601 resides. Timing was good, because they recently convened a working group for "8601 part 2", essentially extensions to 8601. Ray is on that group and on their conference calls much of the discussion has been about EDTF. The group seems to be willing to incorporate most or all of EDTF into 8601 part 2. Ray would want EDTF to be a profile of 8601 (he has introduced the notion of "profile" into the discussion) and that only works if the features of EDTF are all in 8601. A first draft of 8601 part 2 should be available in March 2016.

Ray is definitely willing to work with us to see that the SDWWG requirements are reflected in EDTF and he also suggests that someone from the group gets involved in the TC154 work.

My suggestion is that we invite Ray to one of the Wednesday telcos where he can present EDTF to the group. As Ray, I find it a bit astonishing that the W3C turned down the member submission (but I'm sure they had their reasons for it). If we decide that EDTF can solve some of our requirements, I think we should help to move the document forward (and if we want to use the format on the web, we definitely need a datatype).

Perhaps we can find a few minutes to talk about this tomorrow.

Best,

Lars

Received on Wednesday, 9 September 2015 00:50:10 UTC