I wonder if we couldn't treat math like we do other non-latin
vernaculars, and allow for alternate forms -- one that is the equivalent
of a transliteration, the other that is native. That would give systems
that have limited display capabilities the option of selecting the
latin- or unicode-based form, while MathML-compliant systems could
select that version of the heading or text. It also seems to be better
to treat whole fields rather than parts of fields, that is that we would
have a title field that is transliterated, and another title field that
is MathML compliant even though it also will have basic Unicode
characters in it.
But, as I recall, we haven't really developed a method of creating
parallel fields in different encodings, i.e. transliterated vs. vernacular.
kc
Timothy W. Cole wrote:
>As a mathematics librarian, I'd lobby for MathML even in MODS titles, and
>would strongly second David's assessment that capacity for MathML in
>abstracts is essential. It can even be an issue in specialized subject
>headings (e.g., the full Mathematical Subject Classification [MSC], used
>universally in research mathematics), assuming the possibility that such
>classification schemes could eventually be used in practice with MODS.
>
>Granted mathematicians currently have to live with the fact that existing
>online catalogs don't do a decent job of incorporating mathematics in title
>and bibliographic descriptions. That doesn't make it a good situation. Based
>on my observations here at Illinois, what this means in practice is that
>academic research mathematicians just don't use online catalogs when
>subject searching as much as they might otherwise. They use instead
>MathSciNet and/or ZentralBlatt Math, both of which fortunately index the
>print monograph literature in mathematics well and thoroughly. Online
>catalogs are turned to mostly for known-item searching, after they've
>identified the works of interest from another source. Not accommodating
>embedded markup such as MathML in MODS records won't make the situation
>worse, but it won't make it better either -- and it will limit potential
>reach of MODS to communities that need to allow markup from other namespaces
>in metadata records.
>
>Of course even in MathSciNet math searching is crude. Basically MathSciNet
>just embeds and indexes TeX in titles and abstracts. This allows researchers
>literate in TeX (and that includes most academics in this discipline as well
>as a number of physicists and engineers) to do crude searching in MathScinet
>on the TeX itself. If you don't know TeX, too bad, and even if you do there
>are serious limits in how well you can search raw, often author-generated
>TeX.
>
>So the current TeX approach to searching math is still seen as insufficient
>by many, which is why there is considerable ongoing work in this domain --
>e.g., last spring's meeting on enhancing the searching of mathematics hosted
>by the Institute for Mathematics and its Applications
>(http://www.ima.umn.edu/complex/spring/searching.html). Better ways to
>search both TeX and MathML are being investigated, though the smart money
>seems to be that MathML will ultimately be more useful and powerful, at
>least for searching purposes.
>
>>From my perspective, MODS would be of greater interest if it allowed
>inclusion of markup from other namespaces in at least a few appropriate
>elements. Initially we can assume that most MODS-aware applications would do
>an inadequate job of dumbing-down, indexing and displaying such non-MODS
>content, but that would improve over time, certainly for systems designed to
>meet needs of special communities. I'm not too concerned about standardizing
>right this minute on how MODS-aware applications handle these issues in the
>short-term. (If you can get use to seeing raw TeX embedded in bibliographic
>records, you can get use to almost anything.) But it'd be a shame if MODS
>didn't at least anticipate the basic content needs and build in early on the
>facility to deal with them.
>
>In my opinion this would best be done by allowing foreign-namespace elements
>as children of appropriate MODS elements. The alternative approach suggested
>of adding a <span> or similar element as a default child element for this
>purpose would also probably work, though it seems to me a little cumbersome.
>Display rendering is a tough nut, but right now there are Unicode characters
>you can embed in your titles that no existing generic MODS application will
>render correctly (because some of the specialized glyphs aren't widely
>disseminated yet -- see the STIX font project). You can't do everything at
>once. Figure out how to allow the essential content and markup and then
>fine-tune the rendering issue, perhaps by experimentation with different
>alternatives.
>
>Timothy W. Cole
>Mathematics Librarian
>University of Illinois at UC
>
>
>
>>-----Original Message-----
>>From: Metadata Object Description Schema List
>>[mailto:[log in to unmask]] On Behalf Of Bruce D'Arcus
>>Sent: Wednesday, March 30, 2005 4:02 PM
>>To: [log in to unmask]
>>Subject: [MODS] back to inline markup, math
>>
>>I think I forgot to report this excerpt of a conversation
>>with David Carlisle; XML and XSLT (and unicode) expert, as
>>well as editor of the MathML spec and co-chair of the W3 math group.
>>
>>I asked him about the necessity of using MathML -- versus
>>just using unicode characters -- in titles for
>>mathematicians, who have long been able to add inline
>>equations to bibliographic records in BibTeX. Here was his response:
>>
>>
>>
>>>For many titles, even mathematical titles, unicode plain text is
>>>sufficient, you have greek and all the operators.
>>>
>>>
>>mathematicians have
>>
>>
>>>a long history of having to get their article titles into search
>>>engines and printed book catalogues that don't have mathematical
>>>capability so it is exceptionally rare to require really fancy 2
>>>dimensional formating in a title. The main problem is not
>>>
>>>
>>titles, it's
>>
>>
>>>abstracts or other paragraph sized texts that your biblio
>>>
>>>
>>format might
>>
>>
>>>allow, there you really do need full mathematical layout
>>>
>>>
>>possibilities
>>
>>
>>>so mathml is your friend.
>>>
>>>
>>Bruce
>>
>>
>
>
>
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
|