Thus spoke Stu Weibel (at least at 11:21 AM 12/3/96 -0500)
>Jon The Prolific writes, concerning CREATOR vs AUTHOR:
>> We just need to agree on one once and for
>> all and *_then_stick_to_it_*.
>The Image meta folk were pretty committed to changing this. I think
>the reasons for doing so are compelling.
I can agree that "Creator" is much more general than "Author". However,
when I walk into my local library, my work library, or access the
catalogs from my old school, I as a searcher am presented with a form
that says something like:
Author:________________
Title:________________
Subject:________________
... more detailed and variable
stuff down here ...
I think we stray from this simple model at our peril.
>and, concerning DESCRIPTION:
>
>My impression from last month's discussion is that DESCRIPTION is the
>more general term, and has broader support here. It includes SUBJECT,
>but SUBJECT does not as readily embrace the distinctions among the Virual
>Resource community between SUBJECT and CONTENT.
My impression of last month's discussion was that we were not deprecating
the SUBJECT element, but the SUBJECT (scheme=ABSTRACT) approach to providing
abstracts. That idiom would be replaced by a DESCRIPTION element. SUBJECT
would still be used for uncontrolled keywords, or for controlled terms
when a SCHEME qualifier is specified.
But I could be wrong on this.
>> > * OTHER AGENT (CONTRIBUTOR?)
>> >
>> > The person(s)
>
>> ...and/or organisation(s)...
>
>My sense is that
>
> CREATOR and CONTRIBUTOR generally will be individuals, whereas
>
> PUBLISHER will typically be an organization. I'm not unalterably
> wedded to this position... is it too simplistic to hold up?
Please allow organizations as authors and individuals as publishers.
There are MANY examples of the former and several of the later. With
cheap web-based publishing, we will see more of the latter over time.
>and on DATE:
>
>> Well, I've had five ideas/suggestions from people for schemes for my
>> qualifiers list for this element so far:
>
>[...]
>
>> * FGDC
>> Date conforms to the date formats described in the FGDC. For
>> example 19960831.
>
>
>The nice thing about this one is that it is simple and it collates
>numerically. RFC-822 dating is more complex to parse, but since its so
>common, maybe this is not a problem. Anyone else...?
I think that without a scheme being specified, we are going to see a LOT
of dates of the form:
<META Name="Date" Content="12/25/96">.
This is, of course, a nightmare from the internationalization standpoint
since we in the US write 12/25/96 and the rest of the world writes
25/12/96. There is also the 2 vs. 4 digit year ID problem. BUT, we are
going to see a LOT of these in hand-written descriptions.
I think that we cannot assume a safe default here, but can *strongly
recommend* one approach. As Stu points out, FGDC is nice and simple
and sorts easily. The GUIDE should recommend
<META Name="Date" Content="(scheme=FGDC) 19961225">
People attempting to parse dates when a scheme is not specified
should look for punctuation characters and shudder in horror if any are
found. What they do after that is up to them. :-)
Later,
Ron Daniel Jr. email: [log in to unmask]
Advanced Computing Lab voice: +1 505 665 0597
MS B287 fax: +1 505 665 4939
Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA 87545 obscure_term: "hyponym"
|