Birgit Kellner wrote:
...
> 1.) Alternative titles of works contained in a manuscript or manuscript
> convolute
> We have cases where three or more titles are known for a work, and we
> would like to list all of them for convenience. How to proceed?
> If we have a standard title and an alternate title, I understand we
> sould code:
>
> <title reg="standard title">some other form of title</title>
>
I would strongly recommend AGAINST doing this. The chances are high that
you will want to introduce some markup into your regularised or standard
title (for example, because it contains a foreign word or italicized
phrase, or maybe even a special character) and in XML the markup within
an attribute value is not processed.
The way to deal with this (which also deals with your question about
multiple variants) is simply to provide multiple title elements
<title type="standard">Standardised title</title>
<title type="alt1">Alternate type of title</title>
<title type="alt2">Yet another alternate form of title</title>
The Master recommendations for cataloguers suggest using a recognised
source (such as LC) to provide the uniform title, but such things
probably don't exist for your materials.
> But what if there are more variants of a title?
>
> (This affects both the <title> element in <msHeading> and in <msContents>.)
>
>
> 2.) Colophons and additions: some manuscripts have different colophons,
> author colophons and scribal colophons.
> It seems to us most reasonable to enter author colophons under
> <colophon> in <msContents>, and to treat scribal colophons as
> <additions> under <physDesc>.
I am not sure that I agree with this, though I am not a ms expert by any
means. <additions> is really for material extrinisic to the intellectual
content of the work in the ms, such as subsequent scribblings ("this
book belongs to me" rather than "I completed writing this book today")
However, if the distinction makes sense to you, by all means use it.
> However, we would like to structure the information under <additions>,
> distinguishing writer colophons from marginal additions, corrections
> (interlinear/marginal), presence of special title pages that might have
> Tibetan verses written on them, etc.
> What would be the best way to go about this?
>
At present <additions> like many other bits of the Master structure is
just generic prose. Without checking, I am not sure whether or not the
<colophon> element is allowed here, but it should be, since a <colophon>
is just a specialized form of <title> and a <title> is definitely
allowed anywhere within prose. Alternatively, I'd recommend using the
general purpose <q> element with an appropriate type:
<additions><p>Last five leaves include colophon
<q type="scribal-colophon">Kilroy wuz ere</q></p></additions>.
>
> 3.) Punctuation: there seems to be no provision to especially note the
> punctuation used in a manuscript (in Sanskrit e.g. half dandas, full
> dandas, no interpunction). This information seems best included in
> <handDesc> under <physDesc>, perhaps in free form without special
> tagging. Or are there better possibilities?
> (Mind you, we don't want to have punctuation as a special output
> category, so an extra tag won't be necessary for the purpose of parsing.)
If you are talking about the usage of particular punctuation marks, then
yes this would seem to right place to put it.
>
> 4.) Under <physDesc>, we don't understand the tag <collation>:
> "Description of how the leaves or bifolia are physically arranged".
> Could someone give examples for the kind of information expected here?
>
This is a subject which experts in western mss have raised to a fine
art, not to say an arcane science. It's intended to hold the detailed
description of the physical make up of a codex that is typical of
Western traditional manuscript cataloguing. Eg, choosing an edition at
random from my shelf, I see things like
ff. iii+152+i
ff. iii+32+many blank sheets bound with the ms in the 18th c. to make of
a volume of convenient thickness.
ff. viii+340+iii
> The next big question concerns data entry. The XML files generated by us
> will be uploaded to a central Hyperwave server that processes all search
> request and so forth. But we also need possibilities for decentralised
> data entry, on both Windows and Linux machines. In addition, these
> possibilities should be useable by people for whom a real XML editor is
> too demanding, and a plain vanilla text editor too cumbersome. Because
> one manuscript record might contain several instances of <msPart>, a
> relational database seems the best choice. But we are still wondering
> how to implement this. I looked at StarOffice, which offers Adabas as a
> database and is available for both Windows and Linux, but so far
> couldn't get past installation problems. Any suggestions? How do other
> people handle this?
>
The Master project did look at a number of different choices, and
experimented with a number of different approaches, both for input and
for retrieval of records. On the input side, the IRHT, for example,
produced a relational database implementation, using Ms Access, which
was OK, but quite cumbersome. Most others have used simple tag-aware
editors such as Notetab, or properly customized XML-aware editors such
as Xmetal. On the retrieval side, we developed an experimental native
XML database solution called Phelix here at Oxford, while at Leicester,
the Anastasia program is used to provide access to the records.
We developed a customized Xmetal application for the Wellcome Institute,
which is being used (I think) for cataloguing their collection of Jain
materials. It included some special features for the input of sanskrit
characters (in romanized form), and also made it much easier to input
complex records by means of a set of menus and choice forms. You can
download the customization itself from the TEI website
(http://www.tei-c.org/Software/master-xmetal.exe) but obviously it's no
use to you unless you also buy Xmetal, which is not cheap.
If I were starting a project like yours, I think I'd look into using one
of the freely available XML databases now available: eXist for example.
And I'd certainly consider developing a form and menu-based front end to
collect the data -- but it would definitely be in XML terms, not in
relational database terms.
Hope this helps...
Lou
>
> Many thanks in advance,
>
> Birgit Kellner
> Institute for South Asian, Tibetan and Buddhist Studies
> University of Vienna / Austria
>
|
