I have sympathies in both camps (I'm easy)...
how about:
unqualified date: wording as per the Erway-Wolf miodification I
proposed earlier. date resource was issued, encoded according to the
8601 profile unless otherwise specified.
a small set of 'approved' subelements for those who want to go deeper.
since there really is a small set of them (6 or 7 max?), we can
enumerate them on the reference semantics page, and call them
date.whatever.
yes, I suppose this is the little white lie that Alan Emtage, I think,
insisted we own up to in canberra, but I can live with that.
stu
On Monday, September 29, 1997 6:22 AM, Dave Beckett
[SMTP:[log in to unmask]] wrote:
> >>>>> On Sun, 28 Sep 1997 21:14:49 -0400, Carl Lagoze
<[log in to unmask]> said:
> Carl> ...
> Carl> Am I the only person that thinks we need to have a serious
> Carl> discussion of this in Helsinki??
> Carl> ...
> Carl> My flame resistant suit is on :-)
>
> Don't you remember the heated discussions at Canberra about this very
> topic, hence the Date group.
>
> I see the Date element as a practical compromise. There was a bunch
of
> useful 'administrative' metadata about resources that needed really
> to go into the DC and a group of them dates. The proper place for
> these would be an administrative metadata package, linked to the DC,
> keeping the DC purely a description of the resource.
>
> Date can be viewed as a bucket -- a useful place to throw these
> resources without splitting Date into multiple elements. Of course I
> am a committed qualifier-ist so I'm happy with Date.creation etc.
>
> An alternate suggestion: Deprecate Date (kept with its original
> semantics) and add the administrative dates under Coverage.temporal.
>
> Please stay at 15 elements, after all, we have printed the T-shirt!
:-)
>
> Ciao till Helsinki
>
> Dave
|