RIS

CSL Development
1

So work on EDTF is getting close to wrapping up at least the features
it will support. I put in this one. Any opinions on the details?---------- Forwarded message ----------
From: Ray Denenberg, Library of Congress rden@loc.gov
Date: Tue, Mar 8, 2011 at 4:46 PM
Subject: Re: RIS
To: DATETIME@listserv.loc.gov

“1999///Christmas edition” of course should have instead been
"1999—Christmas edition" which of course would be a problem if we
retain the double dash syntax. However the double dash syntax is on
the verge of removal as it is in “Last Call” status, and nobody has
spoken up for it.

Assuming that we remove the double dash syntax, would this be a good
solution: '1999—“Christmas Edition” ’ or '1999-12–“Christmas
Edition” ’ or '1999-12-25-“Christmas Edition” ’ ?

–Ray

From: Discussion of the Developing Date/Time Standards
[mailto:DATETIME@LISTSERV.LOC.GOV] On Behalf Of Ray Denenberg
Sent: Monday, March 07, 2011 2:53 PM

2

So work on EDTF is getting close to wrapping up at least the features
it will support. I put in this one. Any opinions on the details?

Someone else in the discussion wrote:

Looking quickly at it, it appears to allow you to say things like:
“1999///Christmas edition” or more generally “YYYY/MM/DD/otherinfo”
where “otherinfo’” can be any string, used to qualify the date.

If this other date-like info is specifically referring to the season
(Yuletide, Midsummer, etc.), then I think there’s an argument for
supporting these seasons that don’t correspond to the Big Four, and
hopefully in a structured way. Frank had worked on this some for
citeproc-js (gsl-nagoya-u.net - This website is for sale! - gsl nagoya u Resources and Information.).
He has implemented a general “literal” as well.

In general, though, I don’t think that the presence of unparsed
literals in the generally weak date model in RIS is justification
enough for adding unstructured date info to EDTF.

Avram2011/3/9 Bruce D’Arcus <@Bruce_D_Arcus1>:

3

To be clear, EDTF will support a structured season value (likely with
month values 41-44). I just thought it might be valuable to have this
unstructured fallback.

If not, I can request it be pulled.

Bruce

4

If this other date-like info is specifically referring to the season
(Yuletide, Midsummer, etc.), then I think there’s an argument for
supporting these seasons that don’t correspond to the Big Four, and
hopefully in a structured way. Frank had worked on this some for
citeproc-js (gsl-nagoya-u.net - This website is for sale! - gsl nagoya u Resources and Information.).
He has implemented a general “literal” as well.
[…]
To be clear, EDTF will support a structured season value (likely with
month values 41-44). I just thought it might be valuable to have this
unstructured fallback.

I think the fallback might have a place if the structured seasons will
be limited to four values; Shrovetide is a season of sorts, but it’s
only a week or so long. Such dates are rarely used these days, but
events in the past may be primarily dated in terms of them.

I haven’t followed EDTF’s development, but I would like to see room
for this sort of date.

Avram2011/3/9 Bruce D’Arcus <@Bruce_D_Arcus1>: