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
> (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;
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?