Date:         Thu, 4 Apr 2002 09:36:58 -0500
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: Alternate proposal
Comments: To: Metadata Object Description Schema List <[log in to unmask]>
In-Reply-To:  <003a01c1db5e$6567e140$0301a8c0@minaret>
Content-Type: TEXT/PLAIN; charset=US-ASCII

Concerning the "display form", to give a little background on that element
in MODS: It specifies as a comment that the name is assumed to be
structured, meaning entry form, i.e. surname before forename (or whatever
corresponds to that in the given language). The element "displayForm" is
intended for how it would appear in an unstructured form. Part of the
rationale behind this is from my work with the publishing community,
particularly ebook community, where it is a legal requirement for them to
include the name of the author as it appeared on the work. At one point in
MODS development we talked about two different elements, one called
"file-as" (for the structured) and the other "displayForm". We decided
instead to use the "file-as" form as the default, structured form that
would be expected and added this "displayForm. You will notice that the
mapping uses 245$c for displayForm; of course there may be extraneous
information in 245$c as well as the display form of the name. (In our
ONIX/MARC mapping we also used 245$c for this element which exists in
ONIX.

Rebecca


On Wed, 3 Apr 2002, Geoff Mottram wrote:

> > > I still like the idea of a "display form" element to
> > > distinguish between
> > > sorting and display versions of a field. How would that
> > > affect the idea of
> > > pulling all "text" data from a field?  For example:
> > >
> > > <creator>
> > >     <name>
> > >         <first>Geoff</first>
> > >         <last>Mottram</last>
> > >         <displayForm>Mottram, Geoff</displayForm>
> > >     </name>
> > > </creator>
> > >
> > > Collapsing this name field would be somewhat problematic.
> >
> > To me the <displayForm> is redundant and you are obviously
> > mixing content with presentation.  Something the HTML folks
> > have gotten sorely whipped for doing and was one of the
> > driving reasons why XML came into existence.  You should
> > markup content not try to present it.  That's what XSLT and
> > to a lesser degree CSS is for.  I only need to know the
> > content for <first> and <last>.  Your <displayForm> can be
> > derived from those two elements.  In your system maybe you
> > want to display <name> to your users in the AACR2 form.
> > Maybe I want it displayed as <first> followed by <last>.
> > Different communities will have different standards.  By
> > marking up the content only, each community can extract the
> > relevant content and present it appropriately.
>
> I will have to disagree with you here.  I don't see "displayForm" as
> presentation in the same way that font specifications and layout commands
> are.  I also think you are expecting too much of your data consumers.  If
> you want to subfield your data extensively, it should still be easy for a
> user of your data to display it without having to understand your content
> model.
>
> At the simplest level, MODS should contain the filing version of a field
> and, if its different, a display version.  I shouldn't have to figure out
> what's a first name, a last name or whatever in order to display the record.
> I may not understand anything about the cultural norms for the group who
> created a MODS record and it shouldn't matter.
>
> > This is my biggest complaint about the MODS examples where
> > LC assumes that copying the AACR2 data is good enough.  It's
> > not.  AACR2 is a kind of a specialized markup, where instead
> > of using tags, like XML, it uses punctuation to separate the
> > various content elements.  Using punctuation to separate
> > content elements is bad from an internationalization point
> > of view.  For example a semicolon (;) commonly used in
> > English for these situations is equivalent to question mark
> > in Greek.  When marking up AACR2 data, you should markup the
> > content and throw away the punctuation.  The punctuation can
> > be derived for presentation or conversion purposes.
>
> What's wrong with using whatever punctuation is appropriate for the language
> in use in a given record?  A Greek record would use whatever punctuation
> they would normally use.  If you remove punctuation, I fear an extreme
> amount of markup required and make the standard too difficult to implement.
>
> > However, after having been a little harsh on LC in the prior
> > paragraph, by incorporating the content model I proposed, in
> > an earlier message, into MODS, LC could plop the AACR2 textual
> > string into an element and my community could add refinement
> > elements for the AACR2 textual string.  Thus, LC and my
> > community would both be completely working within the confines
> > of the framework.  Refinements for AACR2 textual strings would
> > probably require my "smart" XSLT transforms to derive the
> > appropriate punctuation when collapsing the refinement
> > elements.  Obviously, refinement elements and "smart" XLST
> > transforms could, and probably should, be shared across
> > communities.
>
> I am concerned with any proposal that requires transforms in order to use
> the data.  A well designed schema should suffice for most users.
>
> Geoff Mottram
>