Thanks for starting a discussion. Some responses below.
On Fri, 15 Mar 2002, Geoff Mottram wrote:
> 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.
My lack of knowledge in this area doesn't allow me to comment too much
about this, but we did put the schema through the validator which is part
of XML Spy and it didn't complain.
> 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.
That is another possibility to consider. I guess this approach would then
take "personal" and "corporate" out of an attribute value and make them
subelements? It is only the case of corporate name where some idea of
hierarchy may be needed that we would want people to repeat them, not for
personal or conference. So there would not be much point in defining all
of these as separate subelements, since they would never be used except
for corporate. Please correct me if my assumption is incorrect.
> 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.
Both Subject and Name have an authority attribute and we refer to the MARC
list of sources for the values of that attribute.
http://www.loc.gov/marc/sourcecode/subject for Subject
http://www.loc.gov/marc/sourcecode/authorityfile for Name.
You'll find that at the very end of Subject and Name definitions.
Are there other places where it is needed?
> 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.
Perhaps one could argue that place of publication code isn't needed, but I
wouldn't agree that coded data should be discouraged. For one thing, there
are a couple of very well established, recognized and widely used
standards for codes (ISO 639-2 for language codes and ISO 3166 for
countries; MARC does not use the ISO list for countries but has its own;
the language one was based on MARC). These are international standards
approved for various uses worldwide. Secondly, using codes for some types
of data is language neutral, since they can be translated into any
language, but mean the same thing regardless of your tongue. So we need to
accommodate these codes. There are other areas where it should be
discouraged perhaps, but I don't think in the case of these
internationally recognized standards. MARC itself is of course used
world-wide and all systems are used to substituting for codes a display
form based on some sort of table that translates the code into a language
name consistent with the system and the environment in which it's used.
The use of codes has helped to allow MARC to be used in the international
realm.
> 5) I would prefer "formAndPhysicalDescription" field to be renamed to the
> simpler "form". The former is just too long.
A point worth considering.
> 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.
Another point to consider. We do want to be able to embed it within other
tags to show its relation to the other data.
> 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.
Related Item has a subelement Identifier that uses the same definitions as
the main element Identifier (so can be distinguished as a URI).
We will be working on a separate schema for authority records. This will
also be a subset of the elements in the full authority format and that is
where see and see also references will go.
> 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.
Yes, experimentation is needed. I'll be sending out a message shortly
about an experiment we are starting here at LC using MODS.
> Geoff Mottram
> Minaret Corp.
> [log in to unmask]
|
