From:  Peter Graham, Rutgers University Libraries
To:  meta2 list  (following is about 2.5 pages long)

As a newcomer to the list, and a heretofore passive observer of the Dublin
Core development, let me make a few comments on the User Guide group report
that John Kunze let us know about last Friday 9/20.  I expect some of these
points will be naive but treat them perhaps as signals that your wider,
sympathetic but critical, audience might need fuller description or more
specificity.

1.  meta-element of DC:  I'm beginning to see a need for another element of
the Core, a meta-element, that would avoid redundancy in descriptions (saving
metaloguers a lot of grutwork) and provide necessary information.  Examples:

a.  Language of DC elements:  Pace 3.5 ("If language is not relevant, omit
it"), the language of neither the resource nor the meta-elements may be taken
for granted.  Consider a German metaloguer providing elements for a French
document to be processed by Yahoo and used by English speakers.  It is
unnecessarily cumbersome for the language element to be specified as a
qualifier to every element or every resource.  

A French metaloguer should be able to specify <META nom="dc.sujet"
content="the"> allowing the work on tea to be indexed and searched without
concern for stopwords.   (I know the accent comes into play but you take my
points.)

b.  Specification of schemes:  it seems likely to me that metaloguing will be
done according to general rules and not just element by element.  Allowing
specification of "scheme=AACR2", "scheme=RMV" and "scheme=LCSH" could save
labor, achieve human readability by reducing clutter, and answer real needs.

c.  Defaults:  it seems conceivable that specification of defaults could be a
meta-element issue.

2.  Digression on readability and redundancy:  the laudable effort so far to
achieve parsimony in expression needs to be balanced by the need for humans
to deal with this data, and humans need redundancy of expression more than
machines.  Some of the editors that will let us create DC records will
provide displays that have to be worked with by people.  Such displays might
have greyed areas for tags, e.g., with bolder areas for content; or formatted
regions of display that will be different from what the final record will
look like.

This leads me to the proposition that, sometimes,

3.  Less is less.  Publisher should be brought back as an element.  It is
meaningful, ubiquitously necessary, and distinct from other forms of
"contribution."  There is not much gained in terseness by specifying for
every record a contributor with role=publisher, and much to be lost in
readability of the record.  (Making publisher the default qualifier simply
completes the circle and affirms my argument.)  

4.  Sec. 3, Core elements:  This section needs to expand on the role of the
qualifiers.  In fact the qualifiers may be present for any and all elements. 
The lack of emphasis on them here means that when they are used later on they
seem privileged uses, leading users away from the realization that they may
be used at will in all elements.  

(I recognize that in a very strict definitional manual, in RFC form say, one
wouldn't need to do this; but this guide is presented as a more "popular"
document.)

3.3, Form: toward the end the phrase "poorer in information" is used to
describe a document in .txt as opposed to .html.  For most uses by real
people (not information specialists) this is not a useful description of the
case.  Most users seeing a phrase "poorer in information" will assume actual
text is lost.

3.6, Type:  

a.  Book:  the question is raised "how do you say in any meaningful way how
this differs from a document?"  Electronically, I don't think you do.  But as
long as the DC is being defined to include physical objects--and I applaud
this, for it may be a step toward the librarianship holy grail of simplified
cataloging--the distinction makes human and physical and historical sense.

b.  Secondary types:  here's one of several areas where I suggest that input
be obtained from the library community, where some effort has been spent in
taxonomizing.  Please don't reinvent a wheel that will have to be retooled.

c.  Genre qualifier:  the question is asked, "can we borrow some library
cataloging lists?"  The MARC 655 and 755 fields are created for Form and
Genre purposes, and indeed the LibOfCongress has established at least a dozen
genre thesauri for this purpose (photographic terms; graphic terms; literary
forms and genres; printing terms; etc.).

3.7, Contributor:  I disagree (as most librarians will) with making the role
of publisher be "who originally made the intellectual content...available";
this is a mare's nest, begging questions of "original" and "content" (not to
mention the earlier mention of "publisher in the traditional sense"--say
what?).  Leave this matter to 3.8, Relation.  The Publisher in the present
context is the organization or the person making the resource electronically
available.  Consider as precedent such examples as book and microform
reprints; the new publisher is emphatically not the original publisher.  

"You may specify non-original publishers..."  Again, leave this to 3.8,
Relation.

3.9, Subject:  The final example doesn't help me understand the descriptive
phrase before it; should Resource Description have been in quotes?  

3.10, Title:  Would it be useful to think about providing for hierarchies of
titles here?  Many works have more than one title (I don't mean in the alias
sense).  There are for example chapter titles, book titles, series titles,
conference titles, section titles, fascicles, and the like.  They could all
be provided as a set of multiples, but there could be virtue in making the
sequence have hierarchical meaning, or allowing Flags to give the hierarchy. 
Comments?

(Consider needing to search for a chapter on "Nuclear Reactors" in a book
entitled "Submarines--the Marvelous Profusion of Power Types" and thus
wanting to exclude book and monographic series titles of "Nuclear Reactors".)

4.2, Element and Qualifier Names:  The example given for Relation confuses
me.  Among the examples are "reln", which is certainly one to four letters,
but the two-letter code given is "rn".  Is there meant to be a thesaurus or
RMV reference?

4.4, Element Name Qualifiers:  

a.  The first two flag examples (d and s) seem to be specified
counter-intuitively, with the specification meaning "don't" where the
remaining specifications seem to mean "do".  Thus a specification for "do
display", the default, would be "-d".  Am I misreading this?  

b.  Flag=l:  Trivial matter:  can I ask that a flag of other than l be chosen
for this?  We've spent too much of our short lives disentangling lower case l
from 1 in pathnames, and I bet someone will later define a flag=1, and there
we'll be.
************************************************************************

Thanks for listening.  --pg

Peter Graham     [log in to unmask]     Rutgers University Libraries
169 College Ave., New Brunswick, NJ 08903  (908)445-5908; fax(908)445-5888
               <URL:http://aultnis.rutgers.edu/pghome.html>