Maybe I can get the discussion started with regards to MODS draft 1.0.

First off, everyone involved did a terrific job of defining an XML schema to
describe bibliographic resources in such a simple vocabulary.  The web site
looks great and the examples are very helpful in illustrating the concepts
you are proposing.  There are a few things that I would like you to
consider, however.

1) All of your example records utilize a default XML namespace.  However,
XML attributes without prefixes do not belong to any namespace, including
any default namespace.  A validating parser that supports namespaces should
complain that the attributes are undefined in these examples.

2) I really don't like the distinction between structured and unstructured
names in the name field. It adds additional complexity to the records
(software and humans will have to look in two places for a name (flat names
are stored as data content in the name field whereas structured names are
stored in "component" elements) and you are only using this construct in the
name field.  (It also raises the question as to what happens if a name field
has both content and "component" elements.) Subjects terms work as one would
expect with an element for each level of a hierarchy.

Why not have a "name" field with repeating sub-elements for each type of
name (personal, corporate, geographic) and rules about what can mix with
what?  It would also be more consistent with your subject element.

3) I would like to see an "authority" element sprinkled more liberally
throughout the schema.  Specifically, each subject or name element could be
validated by a particular authority list depending upon its content.

4) I would prefer you did not have a "Place of Publication Code" element.
The use of coded field data should be highly discouraged in this day and

5) I would prefer "formAndPhysicalDescription" field to be renamed to the
simpler "form".  The former is just too long.

6) I definitely like the "abstract" element. It will prove very useful for
automated data harvesting of the type done by search engines.

7) The "uri" attribute in the "note" field would be more useful as an
element instead of an attribute.  This will allow a uri to be embedded in
the middle of descriptive text.

8) Why not expand the "relatedItem" element to be a little more generic and
expand the list of types?  "See" and "see also" references come to mind,
along with "broader" and "narrower" terms.  In addition, a URI element would
be useful to link to electronic resources.

Otherwise, MODS is very impressive and will open up the creation of
standardized bibliographic data records to a much wider audience.  It may
take a while for you to get the kind of feedback you are hoping for because
the real test for your schema won't come until people try building systems
that process MODS data.

Geoff Mottram
Minaret Corp.
[log in to unmask]