On Wednesday, September 3, 2003, at 10:56  AM, Ray Denenberg, Library 
of Congress wrote:

> (1) The last time someone viewed the resource. (An indication of how 
> much interest there is. If the date is a year ago, not much interest. 
> If it's one minute ago, more interest.)
> (2)  The last time that someone responsible for the resource said it 
> was up to date.
> (3)The time when this resource becomes (or became) valid. Like a train 
> schedule. 
> (4) The last time it was accessed by a specific url.
> Now I think that Rebecca had (1) in mind, but that Bruce thought it 
> was (2) and suggested that that was really "date valid" which we 
> already have, to which Rebecca responded "no, date valid is (3)".  And 
> I think that (4) is extraneous to the discussion and just adds 
> un-necessary complexity.
> Aside from my editorializing about (4), is my interpretation of this 
> discussion (roughly) accurate?

I hadn't thought of it as you lay it out.  I definitely wasn't thinking 
of 1 or 3 (and wonder why 3 is even necessary, come to think of it).

I think I was indeed meaning 2, except that I don't see 4 a separate 
issue, nor extraneous.  If call numbers could change regularly, you'd 
need to put a date accessed or something analogous on that.  It's not, 
of course, and so there's no problem.  URLs, however, do change; 
sometimes frequently.

I guess you could say that you could have a dateUpdated or dateChanged 
or something like that for the record as a whole and use that as a 
proxy for the urls as well?  In other words, it would be understood 
that if a record with urls has been updated, then those urls are valid 
(e.g. correct, and not broken links) at that time.

Maybe it would be better -- though probably unlikely now I guess -- to 
just have a "date" element with different type attribute values?