Bruce, I'm not against adding a qualifier. But I think we have to be
realistic about how MODS will be used and figure out how stringent we
want to be with coding rules. If you have a citation that looks like:
Kleist, Peter. G.P.U. Justice . Edited by Maurice Edelman. London, 1938.
(This is a real citation, btw)... how would you want the date to be
coded? Do you want to assume that this is a firm date? Think of writing
the algorithm that would transfer a variety of citations into MODS
So I am arguing for the ability to encode both highly structured
bibliographic data AND the less structured in MODS. And to me that means
that you need to know how to interpret both. My preference is that you
assume nothing that isn't explicit. In this case, you would have a date
that cannot get any of the codes for dates, and the metadata format must
allow for that. If instead you received this as a highly coded MARC
Record number: 1
LDR 00907Qam 2200229Sa 4504
008 711129s1938 000 0 engx
040 |a DLC |c DLC |d CU-SC
1001 |a Edelman, Maurice, |d 1911-
24510 |a G. P. U. justice, |c by Maurice Edelman.
260 |a London, |b G. Allen & Unwin, ltd. |c 
300 |a 2 p. l., 7-231 p. |c 19cm.
500 |a "The narrative which follows [was] written
from the notes of Peter Kleist, a German engineer accused of espionage
and held in prison by the G. P. U. for examination."-Pref.
600 |a Stalin, Joseph, |d 1879-1953.
600 |a Trotsky, Leon, |d 1879-1940.
610 |a Soviet Union. |b Obedinennoe
gosudarstvennoe politicheskoe upravlenie.
650 0 |a Prisons |z Russia.
651 0 |a Soviet Union |x Politics and government.
70010 |a Kleist, Peter.
090 |a DK267.E46
your MODS record would be much richer as a result. (And the coding of
the date type would probably depend on your knowledge of the source as
much as the coding in the record.) But think about adding either or both
of these to your bibliography and how you would handle the data
On Tue, 2003-07-29 at 19:35, Bruce D'Arcus wrote:
> On Tuesday, July 29, 2003, at 06:15 PM, Karen Coyle wrote:
> >> I think what Bruce is getting at is that XML lets us separate data
> >> encoding
> >> from data presentation. This makes it a different animal from MARC,
> >> and
> >> there is good reason to rethink how cataloging rules are to interact
> >> with
> >> the data storage mechanism. In particular, cataloging rules
> >> proscribe data
> >> presentation, e.g., AACR2 *still* focuses on how to lay out a catalog
> >> card.
> >> The data encoding and presentation are not divorced, as they are in
> >> XML.
> >> Therefore, we should be cautious in how we allow cataloging rules to
> >> influence our encoding decisions.
> > I, too, prefer the separation of encoding from presentation. I just
> > don't
> > think that we can use MODS to be an XML-based carrier for previously
> > created metadata that doesn't have that separation (i.e., MARC) unless
> > we
> > allow that metadata to be translated to MODS with a minimum of
> > re-coding.
> > Yes, some of the re-coding can be done algorithmically, but my
> > experience
> > is that highly stringent rules end up not being followed. So you can
> > put in
> > a code in MODS for "this date is just a guesstimate", but you still
> > need to
> > expect to receive data that doesn't have that coding.
> But if I recall, Karen, you were saying MODS shouldn't even include
> facilities for this sort of coding. I firmly believe it should, and
> that strict separation of form from content ought to be the norm for
> MODS data. I realize that it may not be possible to auto-translate
> some of the more tricky stuff (though shouldn't strict cataloguing
> rules allow that?), but surely it ought to be encouraged. Likewise,
> the use documentation ought to make clear the distinctions, and promote
> the more forward-looking use of XML for new record creation.
> >> Anyhow, XML allows use to separate data encoding from presentation.
> >> This is
> >> true for date, authors, whatever. Cataloging rules, specifically
> >> AACR2, do
> >> not allow for this. Attempts to support various cataloging rules
> >> should not
> >> cause us to throw away the benefits of this separation.
> > No, but in reality we have to support both, and we should support both.
> My worry is that if people on this list don't take this issue more
> seriously, MODS data will end up much more limited than it ought to be.
> I just realized the other day that the arguments I've been making on
> this list amount to arguments about proper XML practice, and have
> little to do with bibliographic data per se. Yet virtually every time
> I'm met with the sense that there is something sacred in AACR2. I
> think these rules need a major rethink for the XML world.
> Again, I realize practical considerations matter, but they shouldn't
> hamper the MODS design. So, I really think we need a simple qualifier
> attribute that can cover dates and names. Oh, and it'd be nice if we
> could at some point come back to the subject of quotes and so forth in