Thank you both for starting a dialogue. MODS is really under construction
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
encoding decisions before letting it out for wider review with the
intention of making changes as needed. So this feedback is very helpful.

The suggestion about XLink is a good one; we are looking at incorporating
it. I'm not quite sure what you mean about copying subject headings

We have been working on the mapping for awhile and we realize that that is
a big piece that has been missing. I am happy to report that we have now
put it up at:
http://www.loc.gov/standards/mods/mods-mapping.html

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
we are undergoing, we will change the specifications for the
project. Without testing we will never know how things work. And, as I
said earlier, we are interested in comments, that is why we set up this
list before announcing it more widely.

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.

Rebecca

On Wed, 27 Mar 2002, Houghton,Andrew wrote:

> > From: Geoff Mottram [mailto:[log in to unmask]]
> > Sent: Wednesday, March 27, 2002 11:08 AM
> >
> > I came across a
> > statement about how subject headings might be entered that
> > made me realize
> > there is much about MODS I don't understand.  In your email
> > you mention:
> >
> >>     "2.      MODS offers a lot of flexibility in terms of how
> >> specific you
> >> want the
> >> markup to be (e.g. you can subfield the elements of a subject
> >> heading or
> >> just use an LCSH string). That will allow for different
> >> methods of input
> >> depending upon the expertise of the person creating the
> >> record. It will
> >> also serve us well as a preliminary catalog record if we can
> >> receive the
> >> more detailed encoding."
> >
> > I happen to disagree with you on this.  I don't see why a
> > MODS record should
> > support both forms of a subject entry (as a single XML
> > element with dashes
> > or as a series of XML elements without dashes).  If a user is
> > capable of
> > typing in those double dashes, they can just as easily split
> > out the subject
> > into sub-elements.  This is another example of MODS trying to
> > make too many
> > people happy and the end result is a system that will be difficult for
> > machines to process when you are done.  MODS subjects should
> > be required to
> > be sub-divided in cases where a user would have input dashes.
>
> I agree here.  The subdivisions of a subject headings should be
> separately marked up.  As I indicated earlier in a previous post,
> nobody should have to parse data content to derive meaning.  This
> is what markup is all about.  Appropriately markup the data to
> indicate its meaning.  In places where AACR2 doesn't cut it,
> markup the data further.
>
> On a second point here.  When dealing with subject headings you
> should not be copying the subject headings from established
> vocabularies, like LCSH.  This is the MARC21 way of doing it,
> and it cause all sorts of problems.  For example, LC changes the
> subject heading and the data is no longer correct in the record,
> or the cataloger miss-types the data and you cannot find the
> corresponding subject heading in the authority file.  Please use
> the XLink standard for pointing to established vocabularies.  The
> XLink standard can also be used for ad hoc subject terminology
> that is not related to established vocabularies.
>
> > This brings me to a second point.  I believe I now know why
> > you are getting
> > so little feedback on MODS and why I often have to drag
> > myself to critique
> > it: because your MODS web site lacks a document like the MARC concise
> > formats to describe in English how each MODS element is
> > applied.  Pouring
> > over the schema (and I suspect that many other subscribers to
> > this list know
> > as little about XML schemas as I do) and example records is
> > too much like
> > having to interpret ancient texts and trying to divine the
> > author's intent.
>
> I'm in agreement here as well.  If LC wants people to use this
> standard then they need to provide the explicit mapping from MARC21
> fields/subfields/AACR2 to MODS along with mapping guidance.  Placing
> disclaimers on the Web Site saying its up to others to develop the
> business rules is not adequate.  For example, without any guidance,
> OCLC and RLG most likely will develop different business rules for
> mapping.  Thus creating additional problems for adoption and
> interoperability.
>
> The fact that this project is going ahead before any serious review
> of the MODS schema, seems to say to me, that LC is not interested
> in comments.  There are other problems with the schema, especially
> in regard to Dewey Decimal Classification identifiers.
>
>
> Andy.
>