## 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:

OpenDocument, MODS and Remaining Issues

From:

Date:

Thu, 17 Feb 2005 09:59:41 -0500

Content-Type:

text/plain

Parts/Attachments:

 text/plain (80 lines)
 I'm not sure I've ever given a larger perspective on a lot of the issues I raise on this list, so let me do that now. Long story, short, then: I'm not a professional software developer, but rather a scholar who got so frustrated with using Word and Endnote for my dissertation that I looked around for alternatives. When I realized there really weren't adequate ones, I decided to create one. I believe MODS (and perhaps MADS) will provide an important standard to make this happen. I'm now the co-project lead for the OpenOffice bibliographic project, which will provide a dramatically improved bibliographic support in the most widely used free software suite. My goal is not only a free alternative to Word and Endnote, but a superior one. Where MODS fits in: we would like to standardize on MODS as the new bibliographic representation, not only in OpenOffice the suite, but in the file format on which it is based: OpenDocument. OpenDocument is developed by an OASIS Technical Committee that includes members from a variety of projects and companies, including IBM most recently. The file format is headed for ISO approval. Our proposal will be to define MODS as *the* supported bibliographic format in OpenDocument. So if a user has citations in their document and saves it, a modsCollection file (probably called "bibliography.xml") will be embedded in the file wrapper directory. If that user -- using, say, OpenOffice - sends their document to a colleague using some other supporting application, the idea is they would be able to interoperate because the bib format is standardized too. 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. 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