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 (January 2005)Back to main MODS pageJoin or leave MODSReplyPost a new messageSearchProportional fontNon-proportional fontLog in
Date:         Fri, 28 Jan 2005 22:49:32 +0000
Reply-To:     Mike Rylander <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         Mike Rylander <[log in to unmask]>
Subject:      MODS part
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

On Fri, 28 Jan 2005 14:17:16 -0800, Karen Coyle <[log in to unmask]> wrote: > Mike Rylander wrote: > > >On Fri, 28 Jan 2005 14:54:31 -0500, Dick Thaxter <[log in to unmask]> wrote: > > > > > >>MODS folks, > >> > >> What I think is missing from this conversation is an understanding of > >>what a uniform title is designed to do in catalogs that follow AACR or > >>similar rules. It is a device that tacks on any number of elements in > >>order to coerce an unchaotic arrangement in what can be very long listings > >>of similar and derivative works. My own feeling is that it's unwise to > >>pick out language as one of these elements and treat it as not part of > >>that human-readable string that comprises the u.t. > >> > >> > > > >I don't want to treat $l as "not part of that human-readable string", > >I just want it to stay in it's own tag, just like in MARC. MARC has > >the language-of-work in a subfield apart from the title text. This > >allows you to use just the title text when appropriate, and to combine > >it with the language-of-work when needed. MODS does not allow you to > >make the distinction. In my book that is an example (albeit very > >small) of baby-with-the-bathwater. I don't want to force anyone to > >forget $l, I just want to retain a little more information (the fact > >that $l is NOT embedded in $a) from MARC. > > > > > Another reason to keep the title part of the uniform title separate from > the modifiers, like language, was mentioned in an earlier post: FRBR. If > you want to FRBR-ize a group of records you need to bring them together > on the title portion , which is the $a in MARC. I don't have a solution > for all of the other possible subfields in the uniform title (especially > those related to music, which are an added complexity), but I do think > that we should keep the $a portion "clean" since it has a particular > role in identifying the work itself. > Here, here! I was the one with the FRBR post from earlier today, and yes, that's exactly why I've not let this discussion die. One option for a general <mods:title> solution when coming from MARC is to do just what is done in <mods:name>. We can use a <titlePart> subnode with an attribute specifying the source subfield. To extend the analogy (and repeat myself a bit), in <name> we get <namePart> with no "type" attribute for subfield $a, and <namePart> with a "type" of "date" for subfield $d. Then the <role> child of <name> tells us the tag (100,110) that the data came from. These are not completely parallel as <titleInfo> uses an attribute instead of a subnode to tell us about the MARC tag (@type="uniform"), but using <titlePart type="languageOfWork"> would work, and keep the bloat down. Of course, I would prefer a <languageOfWork> subnode for <titleInfo>, but I'd settle for anything that keeps subfield $a "clean", as you put it. -- Mike Rylander [log in to unmask] GPLS -- PINES Development Database Developer http://open-ils.org -- Mike Rylander [log in to unmask] GPLS -- PINES Development Database Developer http://open-ils.org


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

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