What is in <titleInfo> contains the complete title. We did use <nonSort>
like the new control characters that were defined in MARC to surround any
characters that are not to be regarded in sorting. So if you want to
display the whole title you drop the tags and display the content of each
(so that an article wouldn't get dropped). Roy's suggestion of including a
sort title is a possibility, although, as already expressed, requires
redundant keying or extra programming.
As for [electronic resource] in the title: we have had this discussion
before. Roy brought it up several months ago. At the time we changed the
MARC to MODS mapping to put the content of 245$h in <physical Description>
<form authority="gmd">. However, if someone insists on
including the GMD in the title string while doing AACR2 cataloging then it
could just be strung out there (and previously in MODS, it was just strung
out in title). But the stylesheets that do the conversions now use
physical description for it. So, Roy, maybe you want to use the new
stylesheet (if you got your original record from MARC) to put the GMD in
what is now the right place.
On Fri, 23 Jan 2004, Roy Tennant wrote:
> Frankly, I find it strange to have a <title> tag that is no such thing.
> In other words, the <title> cannot be found in the <title>, it must be
> found in <nonSort> (if such exists) and <title>. How intuitive is that?
> But if that is the collective wisdom of the group, I can live with it.
> Meanwhile, to use a local example, this is a sample from one of our
> MODS records for our online books (see
> <nonSort>A </nonSort>
> <title>shield in space? [electronic resource] :</title>
> technology, politics, and the strategic defense initiative : how the
> Reagan Administration set out to make nuclear weapons "impotent and
> obsolete" and succumbed to the fallacy of the last move
> It is utterly unusable for any public display (e.g., what is
> "[electronic resource]" doing in the <title> tag?!). Thank god we have
> another metadata record from an internal UC Press database, from which
> we can extract information we can actually put in front of a user. I
> would like to see MODS actually become something usable beyond
> perpetuating the many mistakes of MARC/AACR2, which I believe is the
> rightful role of MARCXML.
> On Jan 23, 2004, at 8:13 AM, Brian Tingle wrote:
> >>>>>> [log in to unmask] 2004-01-23 10:20:12 >>>
> >>> You should be able to define them as xs:string, in which case white
> >>> space is retained. Well, in theory, anyway.
> >> On Fri, 2004-01-23 at 07:30, Andrew E Switala wrote:
> >>> Whitespace normalization is done at the level of the XML parser, so
> >>> by
> >>> the time schema validation happens the attributes have already been
> >>> normalized.
> > On Fri, 2004-01-23 at 07:49, Karen Coyle wrote:
> >> Well, it sounds like "the parser" isn't schema compliant.
> > Well, you have XML parsers, and some of them optionally implement
> > schema
> > validation and some of them don't. But an XML parser that is just
> > trying to get DOM from a well formed XML document has to make the same
> > DOM weather it is bothering to do schema validation or not.
> >> In which case
> >> the same would be true for the strings within the <nonSort> element.
> >> So
> >> this whole nonSort thing really doesn't work.
> > That does not follow at all. He made an assertion about *attribute*
> > space normalization rules in XML parsers, not white space in
> > *elements*. My understanding is that whitespace rules in elements are
> > not the same as in attributes.
> >> In which case, we should
> >> go with Roy's solution, even though that's not how MARC does it.
> > Okay, now this is really a stretch. Please leave it the way it is
> > now:)
> > -- Brian Tingle
> > Content Management Designer
> > California Digital Library