Skip
repetitive navigational links
L-Soft  -  Home of  the  LISTSERV  mailing list  manager LISTSERV(R) 14.5
Skip repetitive navigational links
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (September 2004)Back to main MODS pageJoin or leave MODSReplyPost a new messageSearchProportional fontNon-proportional fontLog in
Date:         Wed, 8 Sep 2004 09:26:18 -0400
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         "Rebecca S. Guenther" <[log in to unmask]>
Subject:      Re: mods:name is broken
Comments: To: Metadata Object Description Schema List <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>
Content-Type: TEXT/PLAIN; charset=US-ASCII

I would like to make a few general points about MADS in response to various messages that have gone out on the list. 1. There is no assumption that we have to have round-trip mapping between MARC authorities and MADS and back. As with MODS, the information that doesn't map well probably won't be lost, but some of the specificity in coding might, because MADS is a subset and derivative of MARC. If you want something in XML that is fully round-trippable, use MARCXML. 2. In using the tag <name> we were grouping together various entities that had similar characteristics, that is, people, organizations, and events. We hadn't come up with a better word. I have heard many argue that they don't care what sort of name/entity it is (i.e. person or organization), that they should be all grouped together. Thus we used <name> in MADS as an entity described in the record that has a name (person, organization or event) and in MODS as an entity used in the record that has a name and is associated with the work in some way. 3. We specifically didn't want to use <contributor> in either MODS or MADS because its definition would conflict with the Dublin Core definition. In Dublin Core, a contributor is defined as "An entity responsible for making contributions to the content of the resource." Because there is also a DC element Creator defined in terms of primary contributions to the resource, it has been used for those entities playing a secondary role. So we did not want to be making the distinction between primary and secondary role, nor did we want to limit it to contributions to the content of the resources, since there may be other roles that an entity plays where we want to give access from a person/organization's name. So we wanted something more neutral. Thus <name>. Maybe there's a better tag, but we didn't come up with one. 4. In terms of the necessity to be using AACR2 or some other body of cataloging rules, what we wanted to bring that is inherited from rules is the notion that there is an authoritative form of the name that is chosen for some reason (maybe because of a body of rules, maybe because of local convention, etc.) and other alternative forms are given as variants. The institution creating the record could choose an English form in Roman script or a Russian form in Cyrillic script; this would be indicated by the language attribute on <name> under either <authority> or <ref>. It is also possible that another institution could create a MADS record for what is the alternate form in the other record. The language attribute would distinguish them and xlink could be used to point from one to the other (as a related record). 5. In the MODS record, xlink could be used to point to the MADS record, which includes the variant forms of the name and other information identifying the entity. You could use this MADS record in various ways. For instance, the MODS <name> may or may not have additional elements; it could have just xlink and then your system could display whatever form you want (for example, the variant with lang="fre" if you wanted to display the French). I'll try to address some of the specific points raised in the latest flurry in further messages. Rebecca On Mon, 6 Sep 2004, Andrew E Switala wrote: > >>> [log in to unmask] 09/06/04 4:52 PM >>> > > It should be possible to xlink the MODS author/creator/contributor to > > its MADS authority file. Strictly speaking, you cannot do this now > > because while role indicates a relationship between an entity and the > > work in question (and so is contextual), mods:name wrongly assumes > that > > role is internal to that entity. This is going to be a mess as a > > consequence. > > Cannot do this? I've been doing it since before MADS (with MODS > pseudo-authority records). What's the problem with: > <mods> > ... > <name xlink:href="auth.xml#smith.john"> > <role> > <roleTerm authority="marcrelator" type="code">aut</roleTerm> > </role> > </name> > ... > </mods> > In an authority record, by my understanding, <role> should only appear > in name/title combinations, where there *is* a context for the role. An > authority record representing a person would not have <role>. > > For the case of multiple forms of the same name on the same work, that > sounds like a job for <displayForm>: > <mods> > ... > <name xlink:href="auth.xml#ichiro.suzuki"> > <displayForm>Ichiro Suzuki/ $BNkLZ (B< $B0lO) (B</displayForm> > </name> > ... > </mods> > The parsed forms of the name, in both scripts, would be in the MADS > record, one in <authority> and one in a <variant>. > > --Andy >


Back to: Top of message | Previous page | Main MODS page

LISTSERV.LOC.GOV CataList email list search Powered by LISTSERV email list manager