If anyone has some examples to send us, that will certainly help. The
guidelines was a large undertaking and it was just easier to use examples
from some of the MARC documentation. It was only for lack of time that
they reflect records converted from MARC.  Any input would be
appreciated. Send to me personally ([log in to unmask]), not to the list.

The citation enhancements will be added to MODS shortly, so you might want
to wait on your attempt to pull out citation data.


On Wed, 30 Apr 2003, Suzanne Pilsk wrote:

> One thing that I think would be a great help would be to have some more full
> examples that are not converted from MARC - but created in MODS and has some
> of these "librarian" things omitted.
> The guidelines and examples still seem to come from the perspective of a
> converted MARC record instead of an initially created MODS record.
> I am fiddling with trying to break down a record into fields so that a
> citation could be built out of the data.  My goal is to have the data pulled
> apart logically so that it can be put together by a style sheet or rules
> with out compromising the standard used for the citation.
> Has anyone else done this? Anybody have anything to share?
> Thanks,
> Suzanne
> Suzanne C. Pilsk
> Cataloging Services
> Smithsonian Institution Libraries
> PO Box 37012
> Natural History Building, Room 30- MRC 0154
> Washington, DC 20013-7012
> [log in to unmask]
> 202-357-3161
> >>> [log in to unmask] 04/30/03 09:24AM >>>
> We do need to be careful about confusing the MODS schema, the crosswalks,
> the guidelines, etc. It is a common misconception that MARC has been
> equated with AACR2, while it is intended to be used with any cataloging
> code. We want MODS to be able to accommodate records using AACR2 or any
> other cataloging code as well as simpler less controlled records using no
> particular cataloging rules. One reason for the guidelines is for those
> who do not use a set of rules so that there are still some content rules
> for populating the elements. Accommodating all these needs is indeed a
> challeng.
> In the case of the GMD ([sound recording], etc.), it is the case that the
> crosswalk says to put 245$h along with title. As I recall we debated this
> early on. This discussion has convinced me that the better approach would
> be to put 245$h in <physicalDescription><form> which has an attribute
> authority. We could use "gmd" as the authority in these cases, which would
> allow us to map from MODS to MARC and be able to put the GMD back in the
> title. As you probably have noticed, we took statement of responsibility
> (245$c) out of title and put it in a note (labelled as such). This is a
> similar situation, where the data doesn't really belong with title.
> Since it's a crosswalk change, we can make it without much of an
> impact. We will just have to change it in the document on our Web site and
> in our stylesheet that does the conversion. A schema change requires of
> course revising the schema, which we don't want to do too oftern. We do
> plan to do some changes to the schema shortly.
> As for indicating cataloging rules, we have thought of that and thought it
> was overkill to add. But if others think it important we could consider
> putting it in recordInfo in this next set of changes. We already have a
> list we use in MARC at:
> I suppose we would say that if the element isn't filled in, no rules are
> used or specified.
> Rebecca
> On Tue, 29 Apr 2003, Karen Coyle wrote:
> > At 04:00 PM 4/29/2003 -0700, Roy Tennant wrote:
> > >Are we visiting the sins of MARC on MODS? That is, are we once again
> > >building a structure with which we can mimic the layout of a card from
> > >our card catalog, without thinking critically about what metadata we
> > >actually need and how to best encode it?
> >
> > Are we confusing LC's cross-walk and examples with the capabilities of
> > MODS? There's nothing in MODS itself that seems to require the GMD. And
> of
> > course it would never exist in data that doesn't come from a MARC21
> record.
> >
> > Maybe we can make more progress if we parse out this problem into its
> > components:
> > 1- the MODS structure
> > 2- the MARC-to-MODS crosswalk
> > 3- [other metadata]-to-MODS crosswalks
> >
> > Bruce is interested in carrying citation information in MODS, so he
> > shouldn't have to be concerned about where AACR2 (library cataloging)
> > elements would appear since he won't have them -- unless his citations
> come
> > from a library database, but I have the feeling that's not the usual
> source
> > for his data. Others of us are indeed taking MARC records and turning
> them
> > into MODS, and so we might want to address the crosswalk defined by LC
> or
> > develop our own. If, however, Bruce does get data that originated in a
> > library catalog, he is going to see AACR2 cataloging because that's
> what's
> > in those records, just like he may see different citations formats from
> > different publications. We can get rid of the GMD, but heading choices
> will
> > be according to AACR2.
> >
> > I also think we need to separately address the structure of MODS and the
> > rules for its content. As you know, this has been the problem area for
> > Dublin Core, which defines a rather relaxed structure but does not have
> > cataloging rules that define the content of its fields. MARC is not just
> a
> > structure, at least not the way most of us refer to it -- MARC21 implies
> > the use of AACR2 to determine exactly what goes into a title or author
> > field. What seems to be happening is that some people are assuming the
> > also is informed by AACR2, and others have no interest in AACR2 at all.
> So
> > we need get clear about this -- will there be a way to know what rules
> were
> > used to create the MODS record? Do we know now if the record originated
> as
> > a MARC21 record? Is there a way to say that the record was derived from
> a
> > PubMed record structure, or an MLA-formatted bibliography.?
> >
> > I don't think we should go too far down this road, but I fear that if we
> > don't de-couple the record format and the bibliographic rules we'll
> > continue to have confusion of purpose.
> >
> > kc
> >