On Sun, 10 Aug 1997, Peter Graham, RUL wrote:
> We do the latter all the time (give a naked date before 1927)
>I think in his case he is confusing the label
> use of the date field with its capability for manipulation. So far I
> haven't seen in the DC element definition for date anything that says it has
> to be a field capable of manipulation, i.e. added to or subtracted from. If
> it is so to be we should specify; personally I think it should not be. This
> is a discovery tool, remember. If we put up a document on the Russian
My personal opinion, but I think that if you don't have fields capable
of manipulation you lose a lot of the point in creating metadata elements
in the first place. Time I thought was an easy one ...
On this planet, with things moving fairly slowly mostly in the same small
gravitational field, one has at least the chance of using a
universal time scheme (such as UTC which the Web uses). Time moves
forward in a nice monotonic way, so with a manipulable time field one
can answer questions like "which of these was published first", "list
the rainfall records for 1960-1969", etc. . The Web is full of
(hidden) transactions saying "give me this page if it's changed
since xxxx".
I assumed that these kinds of questions were useful, and that it would
also be useful to extend this into the past. Some surfing I did found a
substantial philatelic interest in resolving historic calendar schemes to
determine shipping and railway timetables in order to generate the precise
itinary of a particular stamp.
Re. translating dates, I found that some people commonly use "O.S."
for Old Style (Julian) and "N.S." for New Style (Gregorian) where
there was the possibility of confusion. For someone like myself,
who doesn't (didn't) think about different calendar schemes, putting
something down in black and white in ISO 8601 format gives it
a (perhaps spurious) aura of exactitude and manipulability, which
is why I suggested a (formal) tag for "approximate".
...however, everything I create is going to fit nicely in ISO 8601 ... ;-)
Andrew Daviel
|