> From: Rebecca S. Guenther [mailto:[log in to unmask]]
> Sent: Wednesday, March 27, 2002 01:45 PM
> Thank you both for starting a dialogue. MODS is really under
> at this point; we realize that we need some additional
> documentation and
> that will be coming. We did want to get feedback about some of our
We look forward to the additional documentation.
> it. I'm not quite sure what you mean about copying subject headings
The current problem with MARC21, that was propagated to MODS, is that
you copy the LC Subject Authority 1XX Heading into the 6XX field of
the bibliographic record. There are some minor punctuation differences
with trailing periods, etc., probably due to AACR2. The problem is that
LC changes the Subject Authority Heading and now the Bibliographic
records is out of sync. Or the cataloger whom copies the LC Subject
Authority 1XX Heading copies it incorrectly.
Now we have a situation where, when you try to cross reference the 6XX
field with LC Subject Authority file you cannot find the appropriate
1XX Heading. LC should really mandate using subfield-0, in their
cataloging, so the 6XX refers back to the appropriate Subject Authority
records. They should probably use subfield-5 as well.
By making that small change to LC's cataloging practices, at least you know
which Authority record to go back to when the heading is in error. You can
then place the correct heading into the bibliographic record. But the whole
notion of copying from one to the other is wrong. You should just link to
the appropriate Authority record. This is essentially what the subfield-0
does. So the only essential subfield in the 6XX should be subfield-0.
> Your comment about the project going ahead without serious review of
> MODS: I assume you are referring to the Minerva project that I sent a
> message about. We are using this project to test MODS as an element
> set. If some of the details in MODS changes because of the
> current review
I guess that wasn't clear to me, that you were using it as a test pilot.
Thank you for the clarification.
> You made a comment about problems with the schema,
> particularly with DDC
> identifiers, but you didn't elaborate, so I don't really know
> what you had
> in mind.
There is a reason why the 082 field in MARC21-a and MARC21-b use
indicator 1 and subfield-2. A DDC class without edition and
possible translation information is a useless DDC class. LCC
doesn't have the concept of edition and revision. Other
classification schemes do. For example, you could have a DDC
class in Edition 19 of the full Edition that was valid. In
Edition 20 it was deleted and in Edition 22 the number was reused
for something entirely different.
The current MODS format does not seem to take that into account
for classification schemes nor Subject vocabularies. In reality,
this follows the same reasoning as Subject Headings, classification
identifiers should be linked with XLink rather than embedding them
into the data. This nicely, takes care of the problems with other
classification schemes that have additional components such as
edition, revision, and translation. You should only specify the
URI to the class in question.
MODS needs to make better use of URI's. In addition I would prefer
to see a DTD schema as well as the XML Schema version. XML Schema
is bulky and fine for server to server or server to workstation
class transmission. When you start looking at small computing
devices, it is unlikely that the 500+ page XML Schema specification
will be implemented by those devices. It appears that you can
easily provide both, if you would use NMTOKEN encoded values rather
than the XML Schema xsd:string (analogous to DTD CDATA), specific
For example in MODS you have:
<language authority="iso 639-2b">eng</language>
Specify the encoding for the authority element according to the rules
for NMTOKEN. Thus "iso 639-2b" would become "iso639-2b". This way
they can be checked by an XML parser when using a DTD implementation.
As a matter of fact, here again is a place were you should be using
URI's and/or XLink. For example:
<language role="http://lcweb.loc.gov/standards/iso639-2b#eng" />
or (note tag name changed to be more generic)