## MODS@LISTSERV.LOC.GOV

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: OpenDocument, MODS and Remaining Issues

From:

Date:

Thu, 17 Feb 2005 16:26:23 -0500

Content-Type:

TEXT/PLAIN

Parts/Attachments:

 TEXT/PLAIN (73 lines)
 On Thu, 17 Feb 2005, Bruce D'Arcus wrote: > This is why I remain worried about two primary issues: > > 1) Names. > > If I cannot include more than one representation of a name in MODS, > then I cannot reasonably support authors who work across languages. > Using the extension element for this is not enough, because > interoperability then becomes much more fragile. This is where we see the MADS record come in. We use what we call an authority record to detail variants of a name. Because of the size of library catalogs, we have a long standing convention of picking one form of the name that is used to bring together all the variants. We use cataloging rules to pick that form; these are complex, but generally it uses the names in the vernacular, so that e.g. a German university would use a German form of the name. We realize that there may be one name preferred by one group over another name. In this instance probably the best approach is to have authority records in MADS with the variants. If you include the xml:lang attribute with the various forms of name in the MADS record, you could then extract the form you want by using a MADS record identifier (instead of a textual form) in your MODS data. That could reference the MADS record and pull out the form that you want. Does this help, or am I misunderstanding what you're looking for? I don't really have an answer about your second point; perhaps someone else can weigh in here, but at least you have a possible approach. Rebecca  > > 2) Markup within titles and abstracts. > > The most basic example are titles-within-titles (which could be > supported with the addition of single element like xhtml:span), but the > following more tricky example seems to me equally important long-term. > > >> I'm going to continue lobbying the LoC to allow some kind of > >> additional markup in title fields, but it may be difficult because it > >> can be a can-of-worms (e.g. why not just allow MathML?). > > > > My question is why not support mathml instead of just hand selecting > > some of the features? I understand that it will be harder for you to > > implement but at least that's a well known standard albeit not widely > > spread. > > > > You see, my problem is that where i work professors write papers that > > sometimes contains some mathematics in the title. Usually nothing too > > fancy, for instance (in latex) $H_\infty$. However in the abstracts we > > have some more complicated math in there. > > > > Could you please take that into consideration? > > I do realize this is a can-of-worms, but I dread the idea of having to > write and maintain our own schema just to be able to support this > (which has been supported in BibTeX since the beginning; if we won't > have an XML bibligraphic representation that can do this, the Math and > Physics people will never have any interest in it). > > One option is perhaps to do something like Atom does, where you define > a few elements that allow additional foreign markup, and indicate what > that markup is with a content attribute so supporting applications know > if they can display it. I suppose it could be embedded in the > extension element if necessary, but it would be something like: > > blah, blah, blah > > Bruce >