 |
 |
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 age. 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]