 |
 |
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? Bruce