Religious canons of literature often involve texts attributed to divine voices or inspiration rather than to the actual human person who delivered the text into this world as the agent of at least its dissemination. In a Buddhist context, these divine voices are most typically the various Buddhas inhabiting the cosmos, though they can also be Bodhisattvas or other divinities. In addition, reincarnation raises additional problems, since people might claim to be now revealing texts they authored or received from famous saints in previous lifetimes. In a related but different practice, Buddhist texts are often attributed to much earlier saints in order to gain legitimacy. This results in complicated questions of authorship for non-divine texts as well. Thus visionary practices and assumptions concerning the production of texts complicates issues of authorship compared to the much more simple practices of modern literary production. Finally, even at the very mundane level of ordinary composition, we often find group composition where a number of hands are deeply involved in the actual formation of the text - the purported author may have simply given a lecture which inspired the composition, or even simply have commanded the composition, which is actually written by several other people, and then further revised by still others.

From a modern critical point of view, such are thus often understood as a compilation of heterogeneous materials belonging to different authorial hands and different temporal periods. In this way, from modern and traditional perspectives, religious canons, and in particular Buddhist canons, can be quite complicated in terms of identifying the precise identity and character of an author. Modern notions of authorship are just not adequate with their assumptions of a single author producing a easily defined text with his/her name stamped on it. Instead we must identify an entire set of figures, including divine author, original redactor, concealer, revealer, and so forth, each of whom may have had a hand in the actual shape of the received text. We must also be sensitive to how reincarnation or notions of inspiration can blur historical differences between figures involved in this process. We are thus dealing with this problem by not simply documenting the author; instead, utilizing traditional nomenclature, we document every single figure involved in this process of creating the text, both human and divine. We thus track authorial pedigree across domains - the human and the divine - and lives - the multiple lives of any given individual during which s/he may have had a hand in the texts final form.

When we turn to notions of what constitutes a text, we also face problems that cannot be dealt with when we assume modern notions of a single, stable text that view unacknowledged textual borrowings as simple plagiarism. At the simplest level, we have the Tibetan compositional practice of writing literary cycles of many short and long interdependent texts. We have to recall this was before the days of journals to which authors could submit shorter pieces, or edited volumes to which authors submitted individual chapters. In addition, the same authors would pen texts that were ritual, yogic, devotional, and philosophical in character.

Many anthologies and/or canons contain texts which are often short and group together many such texts of different authorship. In addition, there is the problem of extensive intertextuality: entire sections are shared by texts which claim different authorship and titles. Often a given text seems clearly to function as an anthology of shorter texts previously circulated independently but now used as chapters of this longer text either in their original form or in somewhat modified form. Finally, there is a problem with root (rtsa ba) texts being gradually expanded with additional sections often labeled supplements (phyi ma) or secondary supplements (phyi mai phyi ma). These supplements sometimes have chapters numbered from one but other times have chapters whose enumeration begins where the previous texts enumeration ended. In some cases, it seems likely that these different textual units were written by different authors.

Thus in addition to the problem of identifying the author, we have a central problem of defining the boundaries of a text in Tibetan literaturewhat constitutes a Tibetan text? Is a supplement a distinct text or the same text as the root and secondary supplement? Stipulating the constitution and boundaries of a text is often a second order act that is a function of commentarythis stretch of material is what constitutes a text in this case, and so forth. We can see the changing definitions of text in Western Tibetological literature, for example, in how scholars initially cited the sNying thig ya bzhi as if it were a single text. However, the sNying thig ya bzhi is actually an eleven volume anthology of five quite distinct collections of texts, three of which consist of texts of varying authors. The next stage occurred when Western Tibetanists began to refer to the distinct collections which they cited a passage, such as saying from the Bi ma snying thig. Yet, for example, in this case the collection contains many individual texts authored by completely different authors. Finally, a third phase was when Tibetanists began to refer to the individual titles within each collection, along with the individual author(s).

After a detailed analysis, we have decided to provisionally define a separate Tibetan text as that which is terminated by a Tibetan term meaning (It is) completed. (rdzogs so) and is framed by traditional front elements (title line, homage, etc.) and back elements (closing comments followed by rdzogs so, colophons, etc.). On this principle, we have found that in general supplements (phyi ma) and secondary supplements (phyi mai phyi ma) are all classified as separate texts, even when chapter enumeration is directly continuous with the preceding text. In these ways, we have examined indigenous issues of how authorship and text are understood and throughout our work indicated how we are dealing with these issues in the cataloging and describing of the texts.

A third critical issue pertains to the editorial organization of religious canons of literature in terms of the classification of texts under different rubrics. These rubrics are themselves sometimes organized into nested hierarchies, as well as internally divided into further nested hierarchies of sub-rubrics. These intellectual classifications can be found in a cycle of texts, or collected works authored by a single author, as well as in a canon or anthology of texts by very diverse authors. In the former case, for example, a cycle of texts might be divided up into a series of trilogies; or it may consist of one hundred instructions, which themselves are classified into ten sets of ten instructions apiece.

When we consider canons of diverse authorship, we find that often the intellectual schemes for organizing the grouping and sequencing of texts are both helpful in understanding the relationships between texts and highly debatable in terms of their attempts to connect texts into coherent canons (or sub-canonical formations). In short, editorial activity on this level involves trying to retroactively construct traditions that the texts themselves seem unaware of, and/or constructing an artificial unity by grouping together diverse texts for reasons that are not always clear or valid. It is thus not surprising that a given canon can have the same texts grouped in different ways by different editions or, in some editions, can lack any apparent editorial organization at all. Still, these different editorial schemes often yield invaluable information on how a given text should be understood in relationship to other texts and movements, as well as how distinct movements were historically constructed. This process of construction sometimes occurred as texts were produced, sometimes stimulated the production of texts, and in some cases long postdated the production of the very texts it claims constitute a distinct tradition, or sect.

It may be helpful to examine this issue in the context of a particular case. In the case of the rNying ma rgyud bum (NGB), all five of the mainstream editionsthe mTshams brak (Tb), gTing skye (Tk), sKyid grong (Kg), sDe dge (Dg) and Waddell (Wa)are organized into three overarching groups of texts that correspond to three distinct literary, ritual and philosophical traditions known as Atiyoga, Anuyoga, and Mahyoga. In each case, the beginning and end of the sections correspond to the beginning and end of individual volumes. The sixth editionThe Collected Tantras of Vairocanais unique in that it contains only the Atiyoga texts. Other editions of these texts are either individual editions of single texts, or published as part of a much smaller subset of materials. When we look at the internal organization of these three sectionsAtiyoga, Anuyoga and Mahyogawe find that the sDe dge edition has precisely organized each of the three into a system of subdivisions and sub-subdivisions. Each of these corresponds to supposed sub-traditions within the broader traditions. While the beginning and end of these subsections often correspond to the beginning and end of volumes, sometimes they are found within a given volume. This intellectual scheme of organization within the sDe dge edition is made explicit in the catalog for the edition written by the editor himself. He not only outlines the categories and subcategories but also provides a list of titles found in each. Finally, these editions often have a final volume or two of miscellaneous titles which are not precisely classifiedthese are often texts which were only obtained after the first printing.

The gTing skyes and sKyid grong editions seem to have internal organizations of texts groupings and sequencing which are closely related to those of the sDe dge, though there are some variations. Indeed, the classification scheme underlying our own digital master edition of the canon is closely based on the sDe dges. We are as of yet unsure about the Waddell editions organization. The mTshams brag edition, however, is quite different. Its Atiyoga section seems to lack any internal organization, though the Anuyoga and Mahyoga section do seem structured in ways generally parallel to sDe dge.

For all these reasons, it is important that our canonical cataloging and descriptive schemes account for these different intellectual organizations. In reality, a canon, or an edition of a canon, creates for itself a new textual identity: in some sense all the individual texts become subsumed as individual pieces of a far larger text. We can thus focus on the individual texts apart from their existence in the canon, or we can focus on the canon per se and see the texts as the interlocking pieces which constitute it. This ambiguity is evident in how Tibetan scholars will at times focus on the title of a particular texts within The Collected Tantras of the Ancients, and at other points just cite something as being from the The Collected Tantras of the Ancients without any concern for the particular textual and authorial source.

Thus between the collection-level and the individual text-level we have what we might term the classification level, i.e. the ways in which individual texts within a given collection/canon/edition are grouped into sequential and sometimes hierarchical classification schemes. These classification schemes can thus have several different nested layers. In the case of The Collected Tantras of the Ancients, it appears at present that three layers is the deepest that any scheme has: the Atiyoga layer, then its sub-divisions, and then its sub-subdivisions. Given the above considerations, these classification schemeswhich differ from edition to editionare as important for the edition-as-a-text perspective as chapters are to an individual text. They are critical to understanding how a given edition of a canon is structured as a canon.

Our objective is thus to offer two different ways to access and view the individual titles grouped together for printed editions: (i) by means of the individual volumes, and (ii) by means of the intellectual classifications. In both cases, they terminate with the individual text titles. This also provides us with a template for dealing with other Tibetan collections that have quite diverse ways of organizing the individual texts. For our own master digital edition, which lacks any physical volumes, access will be purely via the intellectual organization of the texts which classifies them into traditions.

As mentioned in previous sections, extended Wylie transliteration is used to encode and store Tibetan data. This provides an unambiguous means for recording the information contained in the texts. However, for this information to be useful to the broadest possible audience, it is absolutely necessary that it can be displayed in the Tibetan script as well as in transliteration and translation. This requires the appropriate Tibetan fonts.

Tibetan fonts present unique problems in the digital milieu. The Tibetan syllabary contains only 30 consonants, 6 vowels, a small assortment of characters for transliterating Sanskrit, and a variety of punctuationtotalling less than 100 "glyphs". However, in written Tibetan these characters are often stack one on top of the other. Standard stacks often have up to four different characters vertically aligned: the root letter, a superscript, a subscript, and a vowel. This is where the difficulty arises for fonts and display.

There are two different means to handle this issue of stacking characters. The character glyphs can be drawn in a full size as well as compacted stack size. Stacks are then built as the data is entered or interpreted. Or, a glyph can be drawn for each unique stack, which is then given its own encoding. The data is then interpreted and the appropriate stack glyph is called. To date, most proprietary Tibetan fonts have chosen the latter method, which significantly increases the number of required glyphs. When stacks used for the transliteration of Sanskrit are included, the number of required glyphs is on the order of 1,000. This requires that the set of glyphs be spread over several font files, as the upper limit of ASCII encoding is 256 glyphs. Thus, the average, proprietary Tibetan font is in actuality a set of 5 or more fonts. On the other hand, the Unicode Consortium has chosen the former route of assigning each character two forms, a base form and a subscripted form, implying that stacks are to be built on the fly. In the long run, Unicode will provide the standard system of font encoding used by all. However, the software and fonts required to successfully implement Tibetan Unicode have yet to be created. For this reason, the most viable solution at present is to utilize a public-domain Tibetan font based on an earlier, widely-spread proprietary encoding scheme. Through the combined efforts of the Tibetan and Himalayan Digital Library, the Tibetan Computer Company, and the Trace Foundation, such has been achieved and is being prepared for public release!

The next two sub-sections will cover 1) the issues of a Unicode Tibetan font and its implementation and 2) the public domain font and its underlying encoding and use.

Our ultimate goal is to use Unicode Tibetan fonts, though presently these are not available. The promise of Unicode is that it will provide a standard encoding for use in representing all scripts in the world. Presently, non-Latin fonts map their glyphs onto the 256 places in the ASCII character set and call those glyphs using those codes. This requires that the user has downloaded the specific font and installed it in their system. In order to view it on the web, the browser must be specifically told which font to use and when to switch back to the Latin font. The problems with this are 1. the different Tibetan fonts use different mappings of their glyphs onto the ASCII codes and therefore are not interchangeable, 2. not having the appropriate font installed will result in a display of meaningless strings, and 3. in order to display English and Tibetan on the same page, the browser must be told to repeatedly switch fonts. By reserving a unique range of codes for each of the worlds languages, Unicode solves all these problems. Though at present no workable versions exist, every Tibetan Unicode font would have the exact same encoding and would thus be interchangeable. Furthermore, Unicode makes it possible to create a single font to display multiple languages. For instance, English (with the Extended Latin character set to include diacritics), Sanskrit, Tibetan, Chinese, and Japanese glyphs could all be included in a single font, each character having a unique reference code. Finally, use of the Unicode encoding would disambiguate the call to the browser so that the browser would automatically know what character to display without being told to change fonts. The immense benefits of such a development are obviouse-mails could be easily sent in Tibetan, documents easily traded back and forth, and so on.

However, significant barriers remain to implementing Unicode Tibetan as a functional solution. The Unicode Standard for Tibetan script takes an on-the-fly stack-construction approach. Written Tibetan words often include a number of silent characters, much like the English word, knight. Unlike English, however, some these letters are frequently stacked vertically on top of each other. Stacks of four distinct characters (including the vowel) are common in Tibetan. The Unicode Consortiums approach to this problem as embodied in the 3.0 standard is to encode two forms for each consonantthe form it takes when on top of a stack and the form it takes when subjoined to another character. Such an encoding requires software to build these stacks on the fly. This is equivalent to having to build a complex Chinese ideogram from the simpler ideograms that compose it. With Chinese, the encoding did not take this approach, but rather all the Chinese ideograms were given a unique code. As such was not done with Tibetan, some preprocessing of the Unicode Tibetan is required before the glyphs can be displayed. The recent advent of OpenType fonts has made this more possible, but there needs to be a corresponding commitment from the side of both font and software developers. Other issues such as formatting difficultiesline breaks, spacing and so forthmust also be addressed on the software side. In addition, Unicode works well for modern languages, but it runs into trouble with ancient languages because of expanded character sets for which Unicode is not necessarily adequate. Thus there is a Unicode standard for Tibetan, but the character set for all glyphs is not complete. In other words, it may be sufficient for ordinary Tibetan, but transliterated Sanskrit stacks and bizarre stacks like found in Atiyoga literature pose special problems. Because of the present lack of tools, there is at present no functioning Unicode Tibetan font, though with the rapid advance of technology this lacuna will no doubt be eventually filled.

While an operable Unicode Tibetan font is still several years off, there is an immediate, interim solution, namely the use of a public-domain, ASCII Tibetan font. With funding from the Trace Foundation, Tony Duff of the Tibetan Computer Company worked in collaboration with various members of the Tibetan and Himalayan Digital Library to create such a font: Tibetan Machine Web. This font will soon be made available on both the THDL and TCC web-sites for free distribution and use. There is also work being done on various conversion routines to convert back and forth between other proprietary fonts and Tibetan Machine Web, in order to enhance the usability of Tibetan fonts in the digital medium.

Tibetan Machine Web is a cross-platform, web-usable, ASCII font based on the Tibetan Computer Companys Tibetan Machine font. In collaborating with the TCC and the Trace foundation, we desired to create a font that had the artistic grace of the Tibetan Machine but was also functional on a variety of platforms. Tibetan Machine was only available for Windows. Furthermore, it was absolutely necessary that the public-domain font be viewable in web-browsers, as this was to be our main use for it. Tony Duff visited the THDL for several weeks, over the course of which we assisted him in creating this new font. In order to meet the requirements that the font be cross-platform and web-accessible, it was necessary only to use the lower half of the ASCII range. Thus, what was once a five file font, became a ten file font. These fonts, however, can be used on the Mac OS, Windows, and possibly Linux platforms, and therefore also in the standard Web browsers. Due to the Trace Foundations financial support, this new font set has been made public-domain so that users will be free to download the font and view literary material in Tibetan script. The site for downloading the font is presently under development.

We are also developing means for entering data directly into Tibetan script. There are a number of prototypes being worked on. There is a Java Applet and Servlet that allow one to type Wylie but view the resultant Tibetan script over the web. This is already being connected to our dictionary project and it also allows one to view the dictionary entries in Tibetan script as well. As mentioned above, work is being done on converters from various encodings as well as from Wylie transliteration into Tibetan Machine Web. We are almost finished developing the first release of a macro for Microsoft Word that converts entered Wylie into Tibetan Machine Web, either on the fly or after entry, and mechanisms are being developed for creating web-pages using Tibetan Machine Web that will assist in the speed of web-based publication in Tibetan.

The problem of converting from Wylie transcription to Tibetan script is related to the Unicode issue. Until a Unicode Tibetan font becomes available and workable, one is required to use specific ASCII-based fonts. As mentioned above, there has been no standardization for overlaying Tibetan glyphs on the ASCII codes, so that each font has a different encoding scheme. There are also differences between fonts that build their stacks on the fly and those that have preformed stack. The latter generally use more than one set of glyphs in order to represent the upwards of 600 different Tibetan stacks. Given such a variety, conversion programs must take into account for various fonts or be tied to a specific one. The Library has been developing various technologies to convert our Extended Wylie transliteration into Tibetan script. We have developed a word-processor macro which when activated turns Wylie into Tibetan as it is typed. A similar JAVA program has been written for a database of Tibetan words and phrases, and finally a PERL script has been written for batch conversions of text files from Wylie to Tibetan encoding. All of these are in their beta-phase and are not presently available to the public. Work is also being done on conversion from Tibetan script to Wylie transliteration. Our ultimate goal is to allow the user both to see and enter informationsuch as queries and so forthdirectly in Tibetan script through the use of either Wylie or a special Tibetan keyboard. Further documentation of the algorithms for conversion will be made available upon the public release of the free software.

We are also considering the creative uses of colors, fonts, and so forth. For example, we could make all sigla red, all variant readings blue, and so forth. Or we could color-code editions all mTshams brag readings are blue, sDe dge reading are red, etc.

In the variant element, we will have a mixture of English and Tibetan. Even if we separated the sigla and the variants, the variants can use English words like omit or insert.

We note variants at the syllabic level, not the word or phrase level. Thus if a two syllable word only varies in one syllable, only that one syllable is noted in the annotation giving variants.

In listing sigla that share a common reading, the sigla are noted together without intervening spaces or commas. Thus TbTkKg. This is possible because upper case are only used in our Sigla in the first letter slot.

After sigla and before the variant, our convention is the insertion of a colon and space.

If an insertion is being documented, it is indicated as follows: Tb inserts yang.

If an omission is being documented, it is indicated as follows: Tb omits yang.

Usually critical editions will separate variants into two groupsthe significant and the insignificantin order to prevent the reader from being overwhelmed by the masses of variants. Thus the significant group is footnoted, and the insignificant are end-noted. Significant readings are variants which are shared across editions that show common patterns of errors that are useful for stemmatic analysis or single readings which are semantically significant; insignificant readings are those that are single readings of trivial difference that do not show a pattern of shared errors. We thus want two types of variant reading holdersthe significant and insignificant. Then we can specify whether we want to see one, the other, or both. In addition, the marker in the text that a variant exists for that word should be colored coded so that one color indicates a significant variant and one color indicates an insignificant variationif it has both, both colors appear.

The first of the two sections covers templates for multiple texts.

These are the words of Turrell Wylie in 1959, proponent and co-author of what is arguably the most widely used Tibetan transliteration system to date. With the burgeoning of digital technology in humanities and the recent surge of scholarly interest in Tibetan studies, the need for a standard transliteration system is even more compelling at present. However, Wylies own scheme is not comprehensive, and incommensurable extensions of it have proliferated in the digital world. While the international standards community (ISO) has established standards for the transliteration of other languages using non-Roman alphabets, no such standard has been established for Tibetan, either de facto or ISO-approved. We thus feel the time has come to establish such an initiative in order to promote a standard format for information exchange dealing with Tibetan texts and language.

Wylies fundamental argument was that a Tibetan transcription system should be of minimal complexity and capable of reproduction on a standard typewriter, i.e. one lacking special keys for diacritical marks. His system succeeds in avoiding the use of diacritical marks and capitalization employed by other systems, and has been widely adopted by many scholars since its introduction. For this reason, it seems clear that Wylies scheme should be the basis for any proposed standard. Some within the PRC have modified Wylies system by using v and x respectively to transcribe the a-chung (23rd letter) and the a-chen (30th letter). We can see no compelling reason for such an alteration. Our system is geared towards a disambiguated transliteration required for digital processing and aims to make as little change as possible to already extant scholarly practices in most countries, especially those where transliteration is most commonly used to represent Tibetan. We have not been persuaded by arguments that the a-chung and a-chen should be represented by v and x since they are treated as consonants in most Tibetan grammars. Firstly, the apostrophe used to represent a-chung in Wylie is not a vowel; secondly, the status of a-chung and a-chen in Tibetan grammar are controversial; and thirdly, while Wylie is not a phonetic system, it does have the advantage of using reasonable phonetic approximations of Tibetan letters, and v and x would completely contradict that principle.

Though we have adopted Wylies basic scheme, there are several fundamental gaps in the Wylie transliteration scheme that need to be addressed, if one is to develop a comprehensive standard. These are: The ability to represent Tibetan transliterations of Sanskrit characters not normally found in the Tibetan language, The ability to represent unusual stacks of Tibetan characters in the transliteration of mantras and the like, and The ability to represent various Tibetan punctuation marks not covered by Wylie.

Various solutions have been proposed, though there has been no consensus. The following presents an unambiguous solution to these problems, with an eye toward digitally processing Tibetan documents as well as orthographic considerations. This is a provisional proposal, and we plan to systematically revise it as necessary in coordination with critical feedback from Tibetan scholars and Tibetan computing experts from around the world. Our goal is establishing an internationally accepted standard that is both used by scholars and computing experts, and approved by the relevant international standards organization. Wylies basic scheme, adopted for transliterating the consonant and vowels, is outlined in the tables below. What follows is an explanation for the proposed additions to Wylies system.

It should be noted that a proposed transliteration scheme must serve the needs of print publication and electronic publication. Print publications most typically use transliteration for references to terms or names, as well as for citations of short passages; less frequently, an entire text may be given in transliteration rather than Tibetan script. Electronic publications differ from print publications in having the added flexibility of being able to store material in transliteration, but then deliver it for display in various modes, such as in a different transliteration system (such as one with diacritics), in Tibetan script, in a phonetic rendering and so on. For the most part, the needs of print and digital publication are identical when it comes to a transliteration system, with the latter simply adding more stringent requirements.

However, there is one potential problem with regards to the transliteration system proposed here, namely the use of capital letters and plus signs as detailed below, which are vital to articulate a comprehensive transliteration system beyond the basic scheme now commonly used. While not formally part of the Wylie system, many authors have taken to using a capital letter to indicate a place or personal name. In print publications authors could continue to use capital letters to mark place and person names as an informal practicewhich is its current status within Wyliebut this could not be done in data intended to be used in computer contexts. Additionally, in the scheme proposed here, the capital letters and plus signs can look odd visually to people accustomed to the basic Wylie scheme. In this regards, we should note that the capital letters and plus signs are used to represent special words, such as Sanskrit transliterations, and thus will not typically appear in standard Tibetan passages.

Because of the great importance of translation of Indian Buddhist scripture in Tibetan religious culture from the eighth century onwards, Tibetans developed a method for accurately transliterating Sanskrit using Tibetan orthography. However, to do so they had to make modifications to their glyphs and writing conventions. There were two basic problems. First, Sanskrit contains a whole series of characters not found in Tibetan, mainly the retroflex characters but also the anusvara and visarga, to name a few. The last two were dealt with by adopting the Sanskrit ligaturesa circle above the character and a colon-like glyph at the end of a word, respectively. For the retroflex characters, Tibetans took their closest relative, generally the dentals with one exception, and reversed them. The second problem was that Sanskrit contains consonant combinations that do not conventionally occur in Tibetan. This was easily solved by stacking the consonants with the first on top and the last on the bottom, though such combinations often transgressed the traditional grammatical rules for creating stacks in Tibetan. While Wylies system can account for the abnormal stacks by just stringing the consonants together, it presents no way to

In the proposed system, these retroflex characters are handled in a way similar to the Tibetan method, namely by capitalization of the corresponding dental. There are five main retroflex characters, represented below with their diacritical transliteration:

Even with the computer, diacritical marks are hard to type, requiring several keystrokes for one character. Yet, if a simple, unambiguous transliteration is adopted, the computer can easily be programmed to represent those characters with diacritical marks if so desired, as well as correspondingly represent them with the correct Tibetan glyph. Thus, it is proposed that for these characters, the capital forms of their corresponding letters be used, rendering them:

TaThaDaNaSha

This would of course preclude using capitals to distinguish proper names or root letters. We believe there is little practical benefit in distinguishing root letters that way, as anyone who can read Tibetan can easily pick out the root letters. Capitalization of proper names could be allowed when imbedded in English for conformity to English practice, but should not be used for strict transliteration. For the sake of consistency it is proposed that the anusvara and visarga be handled in a similar way through capitalization:

MH

While the objection could be raised that interspersed capital letters are difficult to read, the purpose here is to develop an unambiguous and simple transliteration system as Wylie proposed. In print publications, diacritics could still be used, as they are today. However, with digital technology, it is desirable to have the transliterated text easily transferable between machines and platforms. The use of diacritics, which are font specific, hinders this, whereas the use of capitals does not. Conversely, conversion from our extended Wylie system to a diacritic font would be relatively straightforward, as long as the transliteration system is, like this one, disambiguated.

Non-standard Tibetan stacks found in Tibetan transliteration of Sanskrit also present a problem for transliteration. These stacks can be represented in Wylies system by merely stringing consonants together. However, some of these Sanskrit stacks can be confused for letter combinations found in standard Tibetan. For instance, there is a Sanskrit stack consisting of an n over a y. Unless provision is made for distinguishing this combination, it would naturally be confused with the eighth Tibetan letter, nya. For this situation, we suggest the use of the plus sign (+) between all non-standard stack letters found in Tibetan transliteration of Sanskrit. For instance there are aspirated letters in Sanskrit not found in Tibetan, such as dha, gha, and bha. These would be transliterated as d+ha, g+ha, and b+ha respectively. We have, however, retained the use of the period between a g prefixed to a y to distinguish such a combination from the stack gy, because this is an already well-established practice. Thus, the Tibetan words for right and left are transliterated g.yon and g.yas, whereas the word for ornament would be rgyan.

The other major omission of the Wylie scheme lies in its limited coverage of punctuation. This system adopts the basic policy, as does Wylie, of using a space for a tsheg, the intersyllablic dot, with the special exception of using an asterisk (*) for a non-breaking tsheg, which will not allow a line break to occur after it. In other Wylie-based transliteration systems that use a space for a tsheg, there is no way to represent the white space that can actually occur in Tibetan texts. To disambiguate this situation, the underscore (_) is proposed as an equivalent to Tibetan white space.It would be up to software manufactures and encoders to determine whether the whitespace character had a fixed or variable size, depending on the degree of accuracy desired in representing Tibetan texts digitally. Besides the tsheg, Wylie presents no policy concerning punctuation in his article. Yet, Tibetan has as much punctuation as English, if not more. It is therefore necessary to develop a standard for transcribing these unpronounced marks. The common convention of using the slash (/) for a shad, the vertical line ending a phrase, has been adopted. The remaining punctuation marks are less frequent, though the attempt has been made to represent them with standard Latin-I character set glyphs that are, if possible, somewhat similar in form to the corresponding Tibetan glyph. Thus, the tsheg shad, a line with a dot above it, is represented by the semicolon (;). The rin chen spungs shad, a shad with three dots above it, is represented by the vertical bar (|). The sbrul shad is represented by an exclamation mark (!), and the gter shad represented by the colon (:). Although it could be argued that the colon is more appropriate for the visarga, as they are almost identical in shape, the counter argument is that the gter shad not only is similar in form to a colon but they are both punctuation marks (albeit with different functions), whereas the visarga represents an aspiration at the end of the word. Given the method of dealing with transliterated Sanskrit above, visarga is best represented by a capital H. The final punctuation mark to mention is the yig mgo mark, which has two forms mdun ma (front) and sgab ma (back) respectively. The first is represented by a similar looking glyph, the at-sign (@), while the second is represented by the next symbol over on the keyboard, the pound sign (#) for ease of typing. This covers the major punctuation marks; others are listed in the punctuation chart below.

Not all the punctuation marks in the chart below have transliteration equivalents. This is because there are not enough characters on the standard keyboard to correspond to every character that is found in the Unicode 3.0 Tibetan character set. Besides, there should be a secondary way of transcribing a character as some keyboards may lack certain keys such as the dollar-sign and so forth. To this end, it is proposed that the use of an escape character is standardized. The escape character would be inserted before the desired characters Unicode value, just as one can now use the alt key to type in a decimal code for a character. This can be done with any character in the Tibetan character set. The proposed escape character is the backslash (\) and the code should be the Unicode 3.0 Tibetan character code. Thus, the rgya gram shad, (transliterated by a left bracket: ]) could also be encoded by typing a back slash followed by its Unicode hexadecimal equivalent: \0F12. The astrological sign sgra gcan char rtags, lacking a transliteration equivalent, will have to be entered: \0F17. As the Unicode is unambiguous and always four characters long, there is no need for a closing marker. Because the consonants, vowels, Sanskrit-derived characters, and punctuation marks make use of every available key on the standard keyboard, such escape codes will have to be used for the other Tibetan characters in Unicode 3.0 (Chart VI) and later releases. These escape codes could be used for other character sets as well, such as Devangari or Chinese, which may be interspersed with Tibetan. This accounts for all the Unicode 3.0 character set; however, some provision needs to be made to deal with punctuation not included in that set. The last chart below (Chart VII) includes some marks found in Tibetan Computer Companys Tibetan Machine font that do not appear to be included in the Unicode standard for Tibetan.

The Extended Wylie Transliteration Scheme thus proposed covers all the various possible letter combinations found in Tibetan literature in an unambiguous way. For most situations, Wylies basic system will suffice. So, it has been left in tact here. However, if the more unusual letter combinations are found, they can be easily and clearly transliterated using the above system. The following charts give the complete proposed Extended Wylie system of transliteration as described above. There are seven tables:

ConsonantsVowelsNumeralsSanskrit lettersPunctuationOther Tibetan characters found in Unicode 3.0Characters not found in Unicode 3.0

The transliteration of all characters, except the vowels, includes the short a sound implicit in all Tibetan characters. This sound is only pronounced when that character is the root character of the syllable (tsheg bar), but not when it is a prefix, superscript, subscript, or suffix. The same is true in transliteration, such letters dropping their implicit a. The vowels are written in their common stand-alone form using the a-chen as their base, though they of course can be appended to any root letter or stack.Except in the case of the Sanskrit semi-vowels, Ri/RI and Li/LI. These are given in combination with the consonants ha and ka respectively with which they are in more natural combination. As with other Sanskrit derivatives, the long simple vowels are represented by capitals, while complex vowels are represented by the corresponding diphthong.

For each character in each of the charts, the Tibetan glyph is given in the middle of the cell, the proposed transliteration is given immediately below it in boldface. To the left of that is the main Unicode character code, and to the right, if there is a number, is the Unicode character code for the alternate subscribed version of that character.

For the purpose of translating texts, audio recording, video transcripts, and so forth, a standard glossary of terms will be compiled to aid translators and to ensure a base-level of consistency among translations by different hands. The Library is already working on a terminological database that will be web-accessible that will cover the broad scope of definitions and illustrations available for much of the Tibetan language. There will be fields for:

Basic termLinguistic etymologyGlossesEnglish translationsSanskrit equivalentsChinese equivalentsOther equivalentsNumerical indexGrammatical indexRelated keywordsDefinitionsPassagesGlobal comments

Readers with sufficient credentials will be able to submit comments, signed and dated, to add further information, draw attention to errata, or contest an interpretation. The electronic interface for this is in the process of being constructed, and a significant body of terms is being amassed.

The other type of terms employed in the Library are of a categorical nature in reference to linguistic and bibliographic information. In the process of cataloging the mTshams brag edition of The Collected Tantras of the Ancients it became apparent that we needed to standardize the use of certain terms and phrases in the descriptions of the texts and define these uses to provide the clearest possible description.

A canon consists not only of differing editions, but also of multiple texts within each edition. In order to refer to the different editions as well as to individual texts in an unambiguous way, we need a canonical scheme of ID numbers. Such a scheme must be stable and unchanging. ID numbers are thus crucial to the Tibetan Literature Archive in terms of identifying the editions, texts within editions, and passages within texts. These ID numbers are instrumental for scholarly reference, for navigation, for searches, and for collation. In addition to ID schemes for particular published editions, our ID scheme also deals with the purely electronic editions of our master catalogs, which have no printed correlate.

ID numbers will also be assigned to individual texts that are not part of larger collections. In all of these abbreviation schemes, we will have machine translations to spell out each abbreviation so that users are not required to remember the abbreviations. In general, sigla allow quick input and require limited space, two considerations which are not as relevant for electronic collections as for traditional books. However, there remain significant cases when space limitations apply for an electronic edition as well, such as in listing variant readings in a critical edition.

The NGB ID numbers have three components: (i) the identification of a particular edition of the NGB (edition ID); (ii) the identification of a particular text within a given NGB edition (text ID); and (iii) the identification of a particular line within a given text (passage ID). If the full ID is given, it will begin with the edition ID, continue with the text ID, and terminate with the passage ID. However, when working within a particular edition, or a particular text, it would be possible to leave out one or two components of the IDfor example just citing the passage ID when it is understood what text is being referred to.

The main standard in the use of Sigla has been recently established in reference to editions of the bKa gyur and bsTan gyur canon, the main two part canon of Tibetan translations of Indic texts. These have been given in PIATS 7 vol. 1, p. xvii-xx, and discussed in the bKa gyur volume (IATS 7 vol III). They basically assign single letter siglum to each edition. We will follow this scheme for references to the bKa gyur/bsTan gyur:

These are important to the extent that they have rnying rgyud sections, as do the Tawang, sDe dge, and so forth.

We have decided that for all collections of multiple texts other than the bKa gyur standardsi.e., various canons, as well as various collected works (gsung bum) and miscellaneous works (gsung thor bu)we will follow our principle of assigning sigla of two letters (the first letter is upper case, and the second letter is lower case). The text ID will follow the standard Collected Tantras of the Ancients scheme, while the passage ID will include chapter and then the page/line of the manuscript. Thus Rc84.6-4.2.3 is the 3rd line of the 2nd page of the 4th chapter of the 6th text in the 84th volume of the Rin chen gter mdzod.

We are reserving the sigla Li# for lists of texts found in other texts. Ng-Li# specifically indicates lists of rnying rgyud prior to the fifteenth century that may indicate now lost texts. The use of the standard Li allows the user to immediately identify this as a list rather than an edition. All the lists together from a given text will be entered as a single file, assigned numbers with the two letter code, and then cross referenced against The Collected Tantras of the Ancients indexes.

Works printed individually or separately from The Collected Tantras of the Ancients, such as commentaries, the source of lemma, and individual editions of texts from The Collected Tantras, are essential to a thorough understanding of The Collected Tantras. Sigla for individual works consist of three letters, the first of which is upper case and the latter two of which are lower case. We begin by using the root letters of the first three words, and then use the successive words as necessary until we have a unique siglum. In terms of variant editions of a given work, we simply use a number in the fourth slot to distinguish them (Tdd, Tdd1, Tdd2, etc.).

THDL asks that subcomponents follow the standard format for home pages to maintain consistency of look and use for projects at their root level as part of an integrated approach. This involves the standard visual appearance and structure of the home page. The basic visual design for these subcomponents follows a single library pattern, but the color and font differ depending on which component of the library the subcomponent belongs to.

In the main part of the page, a short blurb to the left and an illustrative image to the right, and then the standard set of info links on the right lower part of the page.The left framing banner should have a list of components of the project that are hot-linked, and at the bottom should be the hot-linked name of the component of the library it belongs to (The Environmental Archive, etc.), and below that the hot-linked name of The Tibetan and Himalayan Library.

Thus there will be a left bar which will be the locus for the chief menu options for the front page. At the bottom of the left bar, and in this order, it should read vertically arranged: Modes of Access, The name of this Library component (i.e. which of the six components this subcomponent belongs to), and finally a link to the home page for the Tibetan and Himalayan Digital Library.There will be a top bar with the name of the subcomponent as the large header, and with the name in Tibetan script below it. To the right of the large header will appear either the University of Virginia, or other Universities as appropriate. Both left and top bars are colored to match the color coding for that part of the library.The standard logo of the THDL is in the upper left hand cornerthe sacred knot. As mentioned above, in the body of the page inside of the two frames is a paragraph on the left hand side describing the project, and to the right hand side a visual image that somehow embodies this subcomponent. The image should have a one line caption in cursive.Below the blurb and image, to the right hand side below the image should be the standard set of info links on the subcomponent. See one of the pages for the structure of the infolinks and content.

For email contact addresses, and update/announcement mailing lists, THDL follows a common format. The basic email contact address is the name of the project@. Thus The Samantabhadra Collections email contact is samantabhadra@virginia.edu. If the name is too long, then an appropriate abbreviated form is used. For mailing lists used for announcements and updates, we use the form Name of Project-update@. Thus, in the previous case, samantabhadra-update@virginia.edu

Entering the Tibetan text into an SGML data structure requires that we take the flow of the Tibetan text and divide it up within an SGML-defined set of structural elements. This involves striking a balance between recording the texts own structural divisions and inserting new divisions for our own purposes. Another issue is preserving reference to the original manuscripts pagination and lineation, in contrast to the structure of the texts thematic divisions (chapters, outlines, etc.). Both sets of information can be preserved, but one only can become the basis for the SGML structural division of the text. This has consequences for the degree to which searches and display can be based on one or the other.

We can speak of 6 distinct layers to the texts structure: Section-level elements: front, body, backChapter-level elements: divisions of the preceding, such as the chapters of the bodySubsection-level elements: labeled divisions of the chapters, such as in an outline (sa bcad) structureParagraph-level elements: paragraphs for prose or line groups for verseSentence-level/sub-paragraph level elements: defined as shad-delimited lines in our schemeIndividual syllables

We have chosen to base our structure on the texts own thematic divisions rather than the editions pagination. This allows the text to be displayed according to its own internal structure rather than the accidental structure of what text fit on what page in this printing. We will preserve the original artifacts pagination and lineation, but our own IDs will follow our own numbering scheme that is common across all editions (see ID/SIGLA documentation).

The key TEI element that defines the basic structure of an SGML file is the DIV tag. A DIV element represents a DIVISION within the text. DIV tags can contain subdividing elements, which allows one to construct a series of nested hierarchies that mirror the structure of the text. Thus, DIV1 elements can contain DIV2 elements, which in turn can contain DIV3s, and so on. A document can also contain multiple DIV1 elements, since these represent the basic divisions of the text.

The DIV thus allows us to represent the structural elements of the subdivisions of the FRONT, BODY and BACK, as well as any nested outlines contained within those subdivisions. Every text has three DIV1s, which represent its Front, Body, and Back sections. Within each DIV1, DIV2s represent the chapter-level elements within the Front, Body and Back. When a text has chapters and no outline (sa bcad), the DIV2s of the Body correspond to the chapters and there are no DIV3s. When a text has chapters with nested hierarchies of subsections that are contained in a single chapter, the chapter occupies the DIV2, the first layer of the outline occupies the DIV3, the second layer of the outline occupies the DIV4, and so forth. We need at least thirty layers of DIVs, because the nested hierarchies can easily be that complex. Thus, there is a fluid number of DIV layers that depend on the complexity of the outline. This direct correlation of the nested hierarchy of DIVs and the nested hierarchy of the texts own outline allows for searches on the individual sections of the outline.

When a texts outline has a nested hierarchy of subsections which spans multiple chapters in terms of its enumeration (e.g., topic I.ii.2 begins chapter two rather than the outline beginning anew with I in each chapter), the hierarchy of DIVs begins at DIV2 with the first layer of the outlines own hierarchy and then directly maps onto that hierarchy. Chapters will then be marked with the MILESTONE TEI element, which is simply an empty marker. This means the chapters wont participate in any meaningful hierarchy within the SGML data structurethey will just be things marked along the way, which we happen to put information in. We cannot then say where in the hierarchy these things belong. Thus when a text has chapter-spanning outlines, the chapter sequence will no longer coincide in any meaningful way with the hierarchical structure of the SGML. However, we will artificially link the chapters to the outlines contained within them, so that the TOC on the left-hand side of the screen will go from Body to Chapters to Outlines.

In all types of texts, IDs are assigned to the chapter-level elements within the Front, Body and Back; they are also assigned to all individual lines/sentences within those chapter-level elements. For example, the Passage ID b4.45 represents the forty-fifth line (45) of the fourth (4) chapter of the body (b).

Thus, there are two possible ways to navigate through the electronic versions of Tibetan texts that make use of structural divisions within the texts themselves. The first uses the chapter divisions and pagination of the original physical artifact (that is, the manuscript). The second makes use of the thematic outline that organizes the texts contents within a nested hierarchy of meaning. Using the former as the structure for electronic versions of a text allows one to know the section in which a term occurs as well as its pagination/lineation, but not where it lies in the thematic outline, because one is electronically preserving the physical layout of the artifact. However, with critical editions there is no artifact to preserve; rather, a new version of the text is being created. In this case, it will be possible to organize the text in terms of the thematic outline. When both versions of a text are present, searching will be possible not only by chapter or page number of the original, but also by referring to the critical edition one will be able to search designated parts of the thematic outline. Another way of providing access to both structures electronically has been discussed by the projects editorial staff. This would entail initially marking the outline hierarchy with DIV tags and the chapter/page divisions with MILESTONE markers. A script would then be written that could convert the outline hierarchy DIV tags into MILESTONE markers and the chapter/page division MILESTONE markers into DIV tags. Then, by clicking a single toggle button the user could see either presentation of the text. The feasibility of this method has, however, yet to be determined.

In the TEI community, standards are emphasized. The opposite of adherence to standards is the tag abuse syndromeif you dont have a tag for what you want, you just call it anything you want and attach a type attribute to it. Tagging in SGML can be broken down into three categories:

Encoding is driven by whether one is going to do anything with the item in question. One should only tag items that one is going to do something withsearch, display, or something elseand no more than that. Thus, when considering naming a particular thing in the text, keep the following issues in mind:

We plan to hold several conferences of Western and Tibetan scholars in the next year to create schemes for tagging. Constructing a solid classification scheme of the categories of things to tag is an essential task, and one that must be done very carefully and in collaboration with other Tibetologists. These are scholarly decisions. When we enter the Tibetan texts in Tibetan, we will only be encoding them structurally; thematic tagging will be done subsequently. Of course to do the tagging at the data entry level, one must have advanced knowledge of Tibetan, enabling one to decide if a given Tibetan word in context should be tagged in a particular way.

Thematic tags could, for example, mark standard and generic categories of information, such as dates, place names, personal names, names of Buddhas, names of monasteries, and so forth. Tagging these allows the user to search for all personal names, or all names of Buddhas, etc. Another function of tagging is to eliminate ambiguity, such as when a word may have two quite distinct semantic fields. For instance, in Tibetan the word "rgyal po" can be part of a personal name or it can mean king. By tagging it differently for each kind of usage, searching for all occurrences of it as a personal name will not yield hundreds of false hits when it occurs in its meaning as king. This enables one to contextually identify important things which are otherwise ambiguous, and to do more sophisticated searches than just searching for the word-string directly. It also allows one to tag types of information which might be called by different names.

Marking text with thematic tags is analogous to constructing the index for a traditional bound book. One has to consider what types of users will use the collections, and what types of searches of texts we are trying to facilitate for those users. In addition, one should try to use up-to-date terminology, and in the future do global updates as terminology evolves. However, updating in that way can lose points of historical research for intellectual history, such as in the change of terminology from Mohammedanism to Islam.

As one proceeds in identifying thematic tag schemes, the process begins to tip over into scholarly research. For example, we may want to create the element Death, which we use to mark each reference to death in a text. Then we can specify what type of death-related reference it is: funerary rituals, bardo (post-death) theory, accidental death, etc. Those subdivisions can be further subdivided, and so forth. The more granular level is done through attribute specification, namely specifying a distinct attribute for the element. Another example is making the higher level category ritual, and then having within ritual death-related, birth-related, and so forth. In this way, one could articulate a complex nested hierarchy of tags which at the most granular level is exceedingly specific. In general, the finer the level of specificity in tags, the more pinpointed the searches that users can perform; however, the more generic the tags are, the more items can be retrieved. Also, the more granular the categories of tags, the more difficult the decision-making process in selecting tags becomes. One must take considerable time and care in defining the granularity. Thus, a shallow level of tagging with broader categories is better than very narrow categories. In addition, a shallower scheme allows single things to be tagged for a variety of different shallow schemes, rather than a strict hierarchy.

Outlines (sa bcad): each outlined subsection is prefaced by an inserted header in boldface underlined type that gives the name of that section. These names will be prefaced by their enumeration within that overall hierarchy using the repeating sequence I.1.i (section level 1-1, section level 2-1, section level 3-1 and so forth). Since these can get too long to display easily, every 8 levels will be represented by an X, with the full string displayable at a click.

Prose: prose refers to non-metrical lines of text, generally within a paragraph. In TEI it is marked by the sentence tags S> /S>. Each paragraph of prose will be a separate textual unit consisting of a number of sentences delimited by the paragraph tags P> /P>. A paragraph is defined as a prose section that ends with a terminating particle (for instance, the do in bshad do) and which appears to form a thematic unit. Thus, this requires a scholarly judgement which is sometimes straightforward, sometimes debatable. We will be drawing up guidelines as we encounter difficult cases. In terms of formatting, prose lines will wrap within paragraphs, but paragraphs will be separated by carriage returns, just as they are in a Western book.

Verse: verse is a separate category from prose. It is composed of metrical lines of text. In TEI, lines are marked with the line tags L> /L>, while verses are marked with the line-group tagsLG> /LG>, which each contain several lines. In terms of formatting, verse will have each shad-delimited line as a separate physical line. In their display, we will use blank lines to separate stanzas, mark shifts to a different syllabic verse (e.g., from a six-syllable line to an eight-syllable line), and to distinguish couplets, quatrains, terminating particles and so forth.

Lists: while lists in Tibetan texts are seldom numbered, we would like to insert numbering in some cases.

Lineation: each shad-delimited line will have an ID that begins at 1 with each new chapter. These numbers will be displayed at the end of the line as a smaller font superscript; one can change the VIEW to either display or suppress these numbers.

Citations: citations in general will be block indented, and citations within citations will be double-block indented. Otherwise, the componentsparagraphs, verses, lists, etc.will be formatted the same way they are formatted in the rest of the text. In terms of the formatting of citations, we have at least four basic types: (i) verse, (ii) prose, (iii) cited verse within a citation, and (iv) cited prose within a citation.

Annotations: some texts have annotations that are in smaller type and are connected to the text by a string of dots. We would like to make these into hyperlinks with a distinctive visual marker specific to annotations in the main textby clicking on the marker, the annotation appears in a box off to the side.

Pagination/lineation in original manuscript: we will mark the pagination and lineation from the editions physical manuscript with the TEI MILESTONE element. These wont allow us to do any searches in reference to themfor instance, searching for all occurrences of the Tibetan word stong pa on page 4but will enable navigation in reference to them. MILESTONE> is an empty element that simply indicates a significant event happens here, while the tag tells one what the event is. By giving each milestone a unique ID number, it can used for location purposes. One can also use it to indicate a poem, prose paragraph, and so forth.

We will make a style sheet so these markers can be displayed or suppressed, depending on the users needs. When displayed, they will appear as highlighted small numbers.

Root verses and auto-commentary: Some texts are structured as a series of root verses (rtsa ba) followed by an auto-commentary (rang grel), which repeats the root verses in clumps, followed each time by prose commentary and explanatory citations. We want the capability of searching the root verses or the auto-commentary, plus the ability to format the root verses so that they are distinctive.

Conversations and debates: We would like to reformat these so they are easier to follow.

Variant readings: There is also the issue of hyperlinks when there are variant readings across different editions of a single text. We are not sure how this will be handled or where it fits in. However, we would like any word that has a variant reading to occur in the text itself in a distinct color, such as blue, and then clicking on it should bring you to a list of the variant readings, with each indicating their source and location within that source.

The simple search feature is accessible directly from the button-bar at the bottom of the collection browse window. Below the row of navigational icons, there is a text field followed by a search button. Simple searches may be entered here. One may search on a single syllable or phrase or use one of the wildcards listed below. Furthermore, it is possible to enter advanced searches in this field using, for instance, the boolean and/or/not keywords. Double quotes indicate an exact phrase; search criteria in parentheses are evaluated first.

Wildcards: Two wildcards are available for all searches. The question mark "?" represents any single character; e.g., "sky?b" returns both skyob and skyab. The asterisk (*) represents any set of 0 or more characters up to the end of the word, e.g., "sky*" would return skye, skyon and the English word, sky, as well as skyob and skyab. (Note: Due to an apparent bug in the software, the asterisk does not always seem to function as it should.)

Note on the Apostrophe (a chung): When performing searches on a Tibetan phrase containing an a chung, represented by an apostrophe ('), although the searching software recognizes the apostrophe, in some situations the apostrophe is not highlighted in the search results.

Note on Transliteration: All Tibetan terms must be entered using THDL's extended Wylie transliteration system and/or English.

The search capability of DynaWeb has made it possible for the Textual Collections to offer three different advanced search features to accompany the catalogs. DynaWeb (the software used to display the SGML catalogs in HTML) has its own search language for specifying contextual as well as the other searches. However, for the average user to benefit from this capability they would not only need to know this language but be intimately familiar with the Tibbibl DTD that defines our SGML/XML tags. Because such a requirement is unreasonable, advanced search forms have been created to provide a pre-formatted way to search for specific kinds of information. Click here to view forms.

The three types of advanced searching that are presently offered are:

All three types of searches provide one with the option of narrowing the search to a particular doxographical category. The Collected Tantras of the Ancients is generally organized into three large categories: Atiyoga, Anuyoga, Mahayoga. One can perform any of these searches within a particular doxographical category or in all of them, through the check boxes underneath each search form.

IBabble is a synoptic Unicode SGML-aware browser and publication tool; it is a stand-alone application. Synoptic means it runs multiple texts side by side. The ability to browse and display a Unicode document is the primary reason IBabble was first developed at IATH by Robert Bingler. Before it was developed, browsers couldnt even look at Unicode; even now, most wont enable the user to do anything more than display fonts. IBabble allows a user to work directly with SGML in Unicode, to hide all the tags, to do easy searching of Unicode, and to use a special virtual keyboard with foreign language glyphs on the screen, etc.

We plan to adapt IBabble to work with Tibetan glyphs once we have developed a Unicode Tibetan font. Its elaborate interface allows the simultaneous viewing of multiple texts, an important tool when inspecting multiple editions of a single text for variant readings. It works by tagging the texts so that they scroll together. IBabble allows blocking of associated tags, which means that scrolling one window (one text) automatically makes the other windows (other editions of that text) scroll such that the corresponding parts of each edition of the text is displayed in each window. IBabble doesnt attempt to interpret the tags, but it is aware of them and has the ability to link or associate tags together. However, a style sheet can be used through IBabble to display the tags in formatted ways.

IBabble can also be set up as a helper application for a browser.

We have been looking into applications that will facilitate the collation of variant readings of individual texts from edition to edition in order to aid in the compilation of critical editions. We are trying to develop two different procedures for creating electronic editions of individual texts as well as diplomatic editions and critical editions that note all variants.

There are two ways to enter cataloging information into the system. Initially, editors were entering information directly into SGML documents. Standard templates for bibliographic records have been created and are stored at the top level of Astoria within a folder called templates. These documents contain the basic structure of a bibliographic level and there are distinct documents for edition, volume, and text bibliographic records. However, each template must be specifically tailored for the particular record at hand. Text bibliographic records will have to add or delete chapter TIBBIBLs to match their specifications. If other persons, such as revisers, are listed in the Provenance the SGML for these will need to be added, and so forth.

To minimize the amount of SGML editing and knowledge necessary to enter a catalog record, and therefore to quicken the process, a form has been devised to allow editors to quickly and easily enter cataloging information. This form is subsequently processed through a MS Word Visual Basic macro that transforms the simple table into a complete SGML document. This has two benefits: increased speed of cataloging and decreased need for editors to have in-depth knowledge of SGML. Editors can still enter information directly into SGML document, but it is recommended for larger collections, such as The Collected Tantras of the Ancients (rNying ma rgyud bum) that editors use the form-entry method. The standard form contains a discrete number of fields that can be added to or subtracted from in order to mirror the structure of the text. The basic form looks like this:

This form only represents five chapters, which is a relative low number on average. Often, editors will pre-format an entry form to represent as many as 100 chapters, since deleting unused lines is easier than adding new ones. Also, such information as edition sigla, editors initials, date and so forth can be entered into the template one uses as these remain the same over the course of several documents. Such decisions are, of course, left up to the editor.

The form documents the basic information that every text regularly contains. Fields are to be deleted only when they are duplicates that are not necessary for a particular text, for instance, lines for recording chapters numbered beyond what a text actually contains. In general, if information required by the form is not available, this is noted by one of a series of standard English phrases such as Not specified. or No title given. This is to indicate that it is not an oversight by the cataloger but is in fact absent in the text itself.

The entry form has four columns. The first column contains the name for the information contained in that row or in that section of the form. Generally, the information is entered in the second column in the same row as the description or name. Thus, the normalized title is entered in the second column of the same row that says normalized title in the first column. Exceptions are with chapters where the number of the chapter is indicated in the first column and with EOC titles (see below for description of EOC), where the EOC text-title is listed in the first column, as described below. The third column contains paginations for certain items, namely the chapters and EOC titles. The fourth column is for notes. These are not directly inserted into the SGML file by the conversion program but are extracted and placed in a separate note file (a text file). Notes are put in the fourth column 1) to be inserted as note fields in the SGML document by the person who converts the file, 2) to alert the person who converts the file to some anomaly in the record, or 3) for information that does not have a designated row in the table but should be entered in the file, such as redactors and others in the provenance other than the translators.

All entries are to be made in extended Wylie transliteration or English descriptions. For English descriptions, in general, only the first word is capitalized. This applies to section names such as Closing section and Title line, as well as indications of lack of information such as No title given. and Not specified.. The latter, however, should also be followed by a period, whereas the former will generally be followed by a comma and a pagination (no period in any case with section names). All entries of transliterated Tibetan should be followed by a shad, i.e, the backslash (/), unless the entry ends in the letter ga or ka, as per Tibetan grammatical rules. If the entry ends in a nga the shad should be preceded by a tsheg, which in transliteration is a space, also according to Tibetan rules.

For an example of a completed entry form see the next section.

This is an actual entry form for the mTshams brag edition, filled in by Steve Weinberger. It demonstrates some, but not all, of the special characteristics that can be recorded in the form. For instance, the fourth column is reserved for notes. Notes are either to alert the person who converts the table into SGML of some peculiarity or to be inserted into the SGML as a note. Also, the Kaneko number is listed as Not found.one of the special phrases used to indicate a lack of information. Similarly, the Indian scholar is Not specified. as is the title line (a generally uncommon occurrence). Most of the chapters do not list a text title, but one does. Also, there is no non-Tibetan title. Of course, such things vary from text to text.

The following list details the process of filling out the entry form. The steps go through each of the lines in the entry form, describing what kind of information goes there and how they are to be filled in. An editor is not required to follow the steps in this particular order, as long as each piece of information is entered and all the categories are filled. This list below deals with the general form (the first one above); exceptions and peculiarities will be dealt with subsequently:

DateEnter the date the table-file was created.CreatorEnter your standardized editing initials, e.g. ndg. Your initials should be submitted to the project manager for approval so that no conflicts occur.Normalized titleThe normalized title is entered here. Generally, the normalized title is taken from the title line, omitting the zhes bya ba. If the title line is absent, the normalized title is taken from the closing section. If that is absent, then the most common end of chapter text-title is used. If you know that another separate title is commonly used for the text, this may be used, but you must enter yourself as the source in the field below.Source of normalized titleEnter the source for the above entry. If it comes from the text, enter the section name, comma, pagination, as in Title line, 419.6. The first letter of the section name only is capitalized. If you are the source, enter your editing initials.English normalizedThis is for the English translation of the normalized title. Unless otherwise instructed, this field should be left blank.Edition nameEnter the name, not the sigla, for the edition. Thus, mTshams brag. This is for display, so the root letter of the first syllable should be capitalized.Edition siglaEnter the standardized edition or collection sigla for the collection that the text belongs to. Examples are Tb, Bg, Tk1 and so forth. Sigla are standardized and always have the first letter capitalized. See the section below with a list of sigla.Text numberThis is the sequential number of the text within its collection. These numbers continue sequentially over volumes so that each text has a unique ID number. Only collections organized doxographically (the electronic master editions) have multipart numbers describing the texts position in the doxographical hierarchy. In these situations, the numbers would look like 3.1.5.8.Volume numberFor multi-volume collections, this is the Arabic number of the volume which contains the text being recorded, e.g., 10, 5, 37.Volume letterThis is the transliteration of the Tibetan letter or syllable used to identify the volume, e.g., cha, a, ki, etc.Number in volumeThis is the sequential number of the text within its volume, e.g., 5 for the fifth text in that volume.TAI numberThis is only for The Collected Tantras of the Ancients. It refers to the number of the listing for a text in the Taiwan catalog of the mTshams brag edition. If it is not found in the catalog, enter Not found. (Always capitalize the first letter and end with a period.)Kaneko numberAgain, only for The Collected Tantras of the Ancients. This is the number of the listing for the text in Kanekos catalog for the gTing skyes edition. Not found. should be entered when appropriate.PaginationThis lists the range from beginning page and line to ending page and line, separated by a dash. Page and line numbers are separated by a period. Thus, 795.3846.6.Total sidesHere one enters the total number of sides the text covers. In the example above it would be 52.Total CLEsCLE refers to Chapter Level Element. The structure of a text is broken into front, body, and back. The body of the text has sections called chapters, but the front and back also have constituent elements, such as title line, homage, closing section, and translators colophon, to name a few. Chapter level element refers to any of these sections that falls at the same level as a chapter. Total CLEs refers to the total number of these. For instance, if a text had a title line, an homage, 10 chapters, a closing section, and a translators colophon, it would have 14 CLEs and one would enter 14 here. See the list of chapter-level elements in the Editors Quick Reference Guide.Front CLEsThe number of front chapter-level elements as described above. If there are no front sections, a zero should be entered here.Body CLEsThe number of chapter-level elements in the body. Generally, this is identical to the number of chapters. However, this does not have to be the case if the chapters are misnumbered.Name of chaptersHere one lists all the designations given for chapters in the text. Often, it is leu but can also be rtog pa, skabs, or some other designation. All such designations should be listed here separated by a backslash and underscore combination. A note should be written in the fourth column to alert the converter that there are multiple chapter names, as this requires some special mark-up in the SGML. If chapters are not given a generic name such as leu or skabs, enter Not specified.Back CLEsThe number of chapter-level elements contained in the back section, as described above. If there are no back sections, a zero should be entered.Doxographical categoryThis is for the doxographical category of the text. For The Collected Tantras of the Ancients, we are entering only the texts most general categoryAtiyoga, Anuyoga, or Mahyoga. These will be refined in the future. For the standard in other projects, consult your project manager.Object of homageEnter the full title and name for the deity referred to in the homage. Include all epithets and so forth. The basic rule of thumb is everything up to but not including the la phyag tshal lo/. If there is no homage, enter Not specified.Homage sourceRefers to object of homage source. The word Homage does not need to be included in ones entry here, since it is assumed that the source is the homage CLE. Instead, merely enter the pagination for the immediately preceding entry. If there is no homage, leave this blank.Indian scholarThese next couple of slots are for the translators of the text. The conversion program deals only with translators and so any other persons involved in the provenance of the text, such as redactors or editors, should be listed in the note column. The name of the Indian scholar is put in the second column, exactly as given in the text, including that persons title, if it is given, e.g. rgya gar gyi mkhan po bi ma la mit+ra/. If the scholar is of some other nationality, do not change the label for the column, as this is used by the converting software, but make a note of this in the fourth column so that the converter can change the label in the SGML document from Indian scholar to, for example, Nepalese scholar or Chinese scholar. If there is no translators colophon, enter Not specified.Tibetan translatorHere enter the full title and name of the Tibetan translator, such as ba gor lo tsa ba bai ro tsa na. If there is no translators colophon, enter Not specified.Date translatedEnter the Tibetan date as given in the text. If no date is given, enter Not specified.Place translatedEnter the place translated if mentioned. Include the full place name. If not given, enter Not specified.Trans sourceEnter the source for any and all of the above information concerning translation activity. The source should reflect the section name and pagination. Thus, Translators colophon, 345.6-345.7. The first word of the section name only is capitalized. If all the fields above say Not specified., but the title line does say rgya gar skad du, enter just the pagination for that phrase, i.e., the beginning of the title line, to indicate that the text does represent a translation. If even this is lacking and there is no non-Tibetan title, leave this blank.Original languageEnter the Tibetan for the original language of the text. Generally but not always, this is rgya gar skad. Exclude the du, but follow it with a shad. If this is the only information given concerning translation, the source field above should reflect this section of the title line.DiscussionThis is for any extended, scholarly discussions concerning the translation of the text. This should be left blank unless one is a scholar qualified to comment on this topic.Normalized titleThis repeats the information entered above in exactly the same form.Normalized sourceThis also repeats the source for the normalized title in exactly the same form.DiscussionThis is for discussion concerning the origin of the normalized title. If the normalized title is simply the title line, nothing should be entered here. If for some reason, another version of the title is used, the reason for choosing that normalized title can be entered here as a discussion. All discussions should be followed by the editors standardized initials in parentheses.No. of front titlesThe next several rows deal with titles for the text as a whole or text-titles, beginning from the front and progressing to the back. This particular row records the number of titles for the text, found in front sections. For instance, if there is a title line and a title page, one would enter 2. If there was also a title in the homage, one would enter 3. However, whatever number is entered must match the number of front text-titles that follow immediately after it, as described next. A title line title should always be listed even if there is no title line! In such cases, enter 1 here, and in the title line slot enter Not specified.Title lineThere are only rows for the title lines Tibetan text title included in the entry form, because in general that is the only front text-title given. However, in cases where there are 2 or 3 front text-titles (that is, titles for the text included in front sections), rows should be inserted and filled out in the same manner. The first row contains the name of the sectionin this case, title linein the first column and the text-title given in the second column. The second row says pagination in the first column and lists the pagination itself in the second. These refer only to Tibetan text title and not to the non-Tibetan text title, which is also given in the title line. This has a separate row for entry below. If there is no title line, enter Not specified.PaginationIn the second column of this row, enter the pagination for the text-title given above. If there is no title line, this can be left blank. The above two rows can be repeated mutatis mutandis for all text-titles given in front sections, though only the title line would be listed as Not specified. if it is not included in the text.No. of EOC titlesThis refers to the number of End Of Chapter titles found in the text. Generally, a chapter will end with {text-title} las {chapter-title} kyi leu ste {chapter-number}. EOC titles refers to the distinct or unique text-titles given at the ends of chapters. For each unique title, a list will be created in the section below, listing all the chapters that use that text-title, so that the title does not need to be entered numerous times. In the example given above, most of the chapters did not include a text-title, so they were entered in the list under No title given. One chapter, however, chapter 7, did include a text-title, so it is the sole entry in the second list. Thus, in the second column of this row, the number 2 was entered.{blank cell}The next row is completely blank. This row and the next five are the model for an EOC title list. In this row, one enters the EOC text-title in the first column, and the other columns are left blank, unless for some reason there is need to include a note in the fourth column. A list should be made, as in the example, for chapters that do not list a text-title. This list should be under No title given.{blank cell followed by number in second column}The rows under the EOC text-title row are for all the chapters that use this text-title at their end. The number of the chapter is listed in the second column and the pagination for the EOC text-title is listed in the third column. The numbers 1 through 5 included in the generic entry-form are just place holders. Lists of chapters under EOC text-titles often will not be sequential but will skip numbers because intermediate chapters will have different text-titles. Nonetheless, these lists should be ordered from lowest chapter number to highest. An editor will generally have to add and delete rows here to match the specifics of the text.No. of back titlesAs with front titles, this refers to the number of text-titles included in the back sections. Enter 0 if there are no text-titles in the back sections and delete the following two rows.Closing sectionThis row is for the text-title found in the closing section. If there is none, this row should be deleted. If there is one, the title should be entered in the second column of this row and the pagination in the next row. Titles found in other back sections, such as translators colophon, should follow the same pattern with the section name in the first column and the text-title in the second.PaginationThe pagination for the text-title listed above this line should be entered in the second column here. If there is no text-title for any back section, this row should be deleted.Non-Tibetan titleIn the second column enter the non-Tibetan title as is most commonly found between the rgya gar skad du and the bod skad du using the extended Wylie transliteration system. All such text titles that are non-Tibetan should be entered in this method; if needed, repeat this and the next two rows. Original LanguageAs with the same field above, the Tibetan for the name of the original language of the text is put here.PaginationThe pagination for the Non-Tibetan title is put here.{FRONT SECTIONS)This a simple header line. The second column should be left blank.Title lineThe remaining rows are for describing the chapter-level elements in the text. With a few minor differences they all follow the same pattern. The names for the elements listed are only the most commonly occurring ones; rows should be deleted or added depending on which elements appear in a given text. For instance, if there is no title line, that row is taken out, as in the example above. For the Front Sections, the name of the chapter-level element is in the first column. All words in these names should be capitalized. The second column contains the number of front section, in ascending, sequential order. The third column should contain the pagination for that section. There should be one row for each Front Section and no more.{BODY SECTIONS}This too is a header line. Nothing needs to be entered in this row.1Body sections are dealt with in the following manner. The first column contains the number of the section as listed in the Tibetan. This means that if the chapter is misnumbered, the misnumbering should be reflected in the first column. If the first chapter is numbered leu bcu dgu pa, then 19 is entered in the first column of the first row. The conversion program will automatically insert the sequential identification numbers b1, b2 and so forth. The number in the first column should correspond to whatever the Tibetan says. If no numbers are given, then the sequential number should be entered in brackets to indicate it is an insertion and a note should be included for the converter, who will have to change the header to read [Chapter 1] and so forth. In the second column, enter the exact Tibetan title for the chapter (not including the text-title), followed by a shad. The source for the title is included in the same column, after the title, within parentheses. In the third column put in the pagination for the chapter. If the chapter is not titled, enter Untitled. (first cap, ending in period).{BACK SECTIONS}This also is a header line.Closing SectionBack sections are dealt with in an identical manner to front sections. The name of the section goes in the first column (all words capitalized). The number of back section it is goes in the middle column and the third column is for the sections pagination. The sections included in the entry form are the most common ones. If any of them do not exist for a certain text, that row should be deleted from the table.

The data entered into the cataloging forms is generally extended Wylie transliteration or numeric data for volume number, pagination and the like. However, there are several instances where the use of English is require, such as when we want to explicitly indicate that no information was supplied by the text and to note anomalies and so forth within the text. While catalogers have the flexibility to indicate their precise meaning, the use of standard English phrases is recommended in the more common situations. Included here is a table of those standard English phrase and the situation in which they are used.

Points to NoteSome instances have a period at the end; others do not. Please be mindful of this.If you create a Physfacet or a Discussion, always include your initials in parentheses at the end of the content.English PhraseOccasions When Phrase is UsedNo title given.No text title at the end of a chapter (occasionally these are at the beginning).Not found.No TAIWAN catalogue number; no KANEKO catalogue numberNot specified.If there is no:Object of Homagenon-Tibetan titletitle line titlechapter designationIndian scholarTibetan translatordate translatedplace translatedoriginal languageNo colophon given.If there is no colophon (Used in the abbreviated entry form).

The catalogs of the Samantabhadra Collection are composed of numerous and various SGML documents. Not only does each text in The Collected Tantras of the Ancients have an SGML document as its separate bibliographic record, but the volumes and editions themselves also have bibliographic records. On top of this, there are cataloging records that serve to concatenate the information into a single SGML file, publishable through Dynaweb. Given that there are in the neighborhood of 1,000 texts in The Collected Tantras of the Ancients, the task of managing and maintaining definitive versions of these files while multiple editors work on them is daunting. Fortunately, the Astoria SGML file-management software assists us in this task.

As Astoria is used to keep track of the plethora of SGML files we continue to create, it would serve us well to review the different files involved in an edition catalog. Only the name and a brief description of each kind of file will be given here for reference in the following discussion. A full list of files and more detailed descriptions can be found in the section on SGML files.

File NameDescriptionTb.###The folder containing files on text ###.Tb.###.bib.sgmThe bibliographic record for a single text.Tb.v##The folder containing files for volume ##. Tb.v##.bib.sgmThe bibliographic record for a volume. Tb.v##.cat.sgmThe volume catalog file concatenates its texts bib. records. Tb.bib.sgmThe bibliographic record for the mTshams brag edition. Tb.cat.sgmThe catalog file that concatenates all the volume catalogs.Tb.ed.sgmThe final published catalog of an edition.

For illustration purposes, the following discussion will cite particular texts and volumes, such as Tb.412.bib.sgm and Tb.v07.cat.sgm, rather than the formulas above. This will hopefully provide concrete illustrations of general procedures.

Being a type of electronic library, Astoria utilizes a system for organizing its files, in the same way that a physical library needs a system to organize its books. Astoria does so in a hierarchical way, that is, folders nested within folders any of which can contain SGML documents. It uses the genealogical metaphor to describe the various levels. The higher level is the parent or ancestor of the lower level, which is called the child (or, less-frequently, descendent). The highest level or root directory of any collection is a filing cabinet. In our case, the filing cabinet for storing the data is called Sam. Within Sam, at present, there are two children/folders: one for templates and the other for the mTshams brag edition. As other editions are cataloged, they will have their own folder and also become the children of Sam. Within the mTshams brag folder there are 49 children. These are the Tb.ed.sgm, Tb.cat.sgm, Tb.bib.sgm, and 46 folders for the 46 volumes of the edition. Within a volume folder, say Tb.v04, there would be its catalog record (Tb.v04.cat), bibliographic information (Tb.v04.bib) and a series of folders, one for each text found in volume 4. These text folders at present contain only a single document--the bibliographic record for that text--but in the future they will contain representational files and scholarship files for that text. The structure of the collection can be pictured thus:

The first thing an editor should do once the table of bibliographic information on a text has been converted into an SGML document is to enter it into the Astoria database. This can be done directly from Epic. However, the folder in which it is to be placed needs to be set up already. To do this, one goes into Astoria itself, navigates to the place where you want the folder, chooses New Folder from the file menu, and creates a folder with the appropriate name. Volume folders should be named: Tb.v## with no extension (such as .sgm). Text folders are named: Tb.### using the sequential text number and again no extension. The create folder window gives one the option to place the folder before or after, or as first child or last child. Before will place the new folder before the object highlighted when one chose new folder. After will place the new folder after the highlighted object. First child places the folder as the first item within the highlighted folder. Last child places it at the end of all other contents of the highlighted folder. Once the folder is created, an SGML file can then be entered into it. This is done through Epic as follows. The second to last menu on the menu bar of Epic (i.e., the one to the left of the help menu) is called Astoria. The third option under the Astoria menu is Save As Document Object. When this option is chosen, if one has not already opened the Astoria database, one will be asked for their handle and password. Once in, a window pops up. One needs then to enter the name Astoria is to give the file, such as Tb.141.bib. Since all files in Astoria are SGML files, the extension .sgm has been left off of files saved there, but when exported out of Astoria, the extension .sgm should be applied. Next, one needs to choose a destination for the file, that is, where the file is to be saved in Astoria. The bottom input field of the window is for this. Click on the browse button. There will be two sub-windows in this Browse window. The one to the right displays the hierarchy of folders and files. The one to the left shows the possible destinations available within the folder highlighted on the right. Navigate down the hierarchy until one sees the desired destination folder appear in the left-hand window. Choose this and its name will appear in the bottom input field of the original window. The middle input field of that window is for any kind of notes, descriptions, and so forth concerning the file. This information is displayed in Astoria but not used in display or publishing. Make sure the Revoke Save on Errors option is checked so that Astoria will validate the document before saving it and alert one if there are any errors. Finally, click save. After some wait, the document will reappear with a split screen, showing the documents structure and the SGML tags. One needs to save it again and check in the document as described below.

When a document has been entered into Astoria, it may be checked out by those authorized with a valid password. Assuming one is in Astoria, one can navigate down the graphic hierarchy by double clicking on cabinets, folders, or files that one wishes to open. When the folder where the desired document is reached, the documents name will appear with a graphic of a piece of paper to its left. One needs to double click on this, which will open up access to the SGML document itself. There will be a yellow or red arrow pointing to the name of the document with the .sgm extension. This name comes from the SYSID field in the SGML template. For this reason, one must always use the .sgm extension in the SYSID field. Next, highlight this arrow and file name by clicking on it once and then right click it. A pop up menu appears with two or three options. Choosing Edit will check the document out of Astoria and open it up in Epic. One can then make changes to the document and have sole control over it. All other clients can access the document for viewing but will not be allowed to make changes, because the document is checked out to you. When finished with editing the document, choose save from the file menu or press Ctrl S. A save window will pop-up. If one is done editing, click on check in and then OK. This will check the document back into Astoria and any authorized client will then be able to check it out. If one wants to save changes into Astoria but still continue to edit the document, click on check out again. This option becomes available only when one has first chosen check in. Doing this will save ones changes into the Astoria database. If one merely saves the document without choosing check in, this will save ones changes to the temporary file stored on the computer being working on but will not save them to Astoria until the check in option is chosen. Note: In all situations the Revoke Save on Errors option should be chosen so that Astoria validates the in-coming SGML and will not allow any context errors to be saved.

Another feature of Astoria is that file names can be changed without checking files out of Astoria and files can be moved within the hierarchy without having to export and re-import them. To rename or change the description of a file, highlight it and right click. From the pop-up menu, chose properties. This will present a window similar to the Save As Document Object widow, with fields containing the file name and description. These can then be edited and the changes will be recorded upon clicking OK. These changes will not affect the SGML output but merely the labels used in Astoria itself. To move a file around Astoria, the Object menu is used. The process is similar to cutting and pasting with a slight terminological difference. First, highlight the object one wishes to move. Then choose move under the Object menu. The object will be grayed out. Then, move to the place where you want to put the object and under the same menu, choose paste. Astoria will give you the options of before, after, and so forth. Choose one and click OK. The file will then be placed in the desired location.

One of the most versatile features of Astoria is the ability to include pieces of an SGML document within another document. Such sharing cannot violate the rules of the DTD, so the destination of the shared chunk must be a place where it is in context or permissible. Otherwise, Astoria will reject the attempt to share the SGML. One does not have to share a whole document but can share any autonomous section of any particular document. These autonomous sections are known as Objects, so Astoria calls this sharing of SGML Reusing an Object. The catalog files for the Collection are built through reusing objects in this way. The SGML hierarchy for an edition catalog file, which is mirrored in Astorias file hierarchy, is displayed below. The overarching tag set is a modified TEI called TIB; the particular tag set for Tibetan bibliographic information is TIBBIBL. DIV1 through DIV3 are hierarchical division markers:

Tb.cat.sgm (TIB document) includes ...Tb.bib.sgm (TIBBIBL)*DIV1 Type=AtiyogaDIV2 ID=Tb.v01 Type=Volume N=1*Tb.v01.bib.sgm (TIBBIBL)*DIV3 ID=Tb.1.bib Type=Text N=1Tb.1.bib.sgm (TIBIBL)*DIV3ID=Tb.2.bib Type=Text N=2 Tb.2.bib.sgm (TIBIBL)* and so forth.

The asterisks (*) show which files are being shared or reused through Astoria. Notice that there is sharing within sharing. In other words, text files are first shared into volume catalogs and then the volume catalogs (DIV2 above) are shared into the edition catalog. The actual unshared SGML for the edition catalog is quite insubstantial. It merely consists of the Control information, a Front Section and a Body Section, which includes three DIV1s for Atiyoga, Anuyoga, and Mahyoga, each of which begins with a brief description of that doxographical category. (At present we have no use for the Back Section, but this could be added if needed.) All other information in the edition catalog file is reused from other files. Below is an image of the Epic window displaying the mTshams brag edition catalog file. (The plus-indicator means portions of the SGML are not being shown. This is because they are irrelevant here.)

In the front section the catalog file reuses the whole Tb.bib.sgm file. Then within each of the DIV1s of the body it reuses the DIV2s extracted from the volume catalogs of those volumes in that particular category. The Atiyoga DIV1 includes DIV2s reused from the catalog files of volumes 1 through 14, and so forth. The volume catalog files have a complete structure-a BODY, a DIV1, a DIV2 containing DIV3s for each text-but only the DIV2 and its contents (the DIV3s) are reused in the edition catalog. This is so that the volume catalog can stand on its own, yet when it is reused in the edition catalog the SGML will still be in context. The volume catalog in its own turn reuses the full TIBBIBL of each text. Its single DIV2 contains a DIV3 for each text. The ID attribute for each DIV3 is the name of the record, such as Tb.23.bib (without extension); its N attribute is set to the sequential text number, here it would be 23; and its TYPE attribute is set to text. Each texts DIV3 contains a HEAD element, which contains the following:

Here, even the normalized title is reused from the TIBBIBL for that text. Following the header the complete TIBBIBL is reused or inserted. The header is used for the TOC window in Dynaweb.

Reusing an object is actually done through the SGML editor, providing it has a bridge to Astoria. In our case, the editor is Epic. The document in which the reusing will occur must be one checked out of Astoria, however. First, one places the cursor where one wants the reused SGML to be placed. Then, choose the eighth option under the Astoria menu in Epic. This option is called Reuse Object. A window will appear with the Astoria hierarchy on the right and a blank window on the left. Navigate through the hierarchy to the document to be reused. When this document is opened (double-clicked), a red arrow will appear below it in the hierarchy as well as on the left in the Object window. Only items that appear in the left Object window can be shared. The first object to appear will be a complete TIBBIBL. However, one can navigate further into the guts of that TIBBIBL and take out just a piece, such as the Normalized title mentioned above. Double click on the arrow in the right window and all that elements immediate children will appear. One can reuse one of the children or click on it and see its children. In this way, one can navigate to a single element and share just that. Whatever is to be shared must be highlighted in the left-hand window before one presses OK. Astoria/Epic will not allow one to place SGML out-of-context and will reject such a request. To illustrate this with an example, when creating the edition catalog, I place my cursor in the DIV1 type=Atiyoga and then do Reuse Object. I navigate through Astoria with the pop-up window: first opening the edition folder, then opening the Volume 1 folder, and then opening the Tb.v1.cat file. This is the catalog file for volume 1. I see two options within it: CONTROLINFO and TEXT. Under TEXT there is a DIV1 type=Atiyoga. As this is already in the edition catalog, I do not want to share it but open it and go down a level further. There I find a DIV2 Type=Volume, N=1. When I open the parent element, the DIV1 in the right-hand window, The DIV2 appears both below it in the right window and also in the left window. I then highlight the one in the left window and click OK. The SGML of the DIV2 is then inserted as a file entity into the edition catalog. Note that the DIV2 itself reuses the TIBBIBLs for each text in volume 1, so that these text records are first shared into the volume catalog and then from there into the edition catalog. This allows a user to navigate in the same hierarchical fashion when browsing the collection through Dynaweb.

This kind of SGML sharing not only saves one from extensive cutting and pasting but also assures that any changes made in one document will be reflected in the places where it is shared. Thus, for each file there is one definitive version to which changes can be made, and these changes will be reflected in the documents that share said file. However, the final product we want here is a single SGML file that concatenates all the information in the other files. How is this done? In Astoria it is done through making an edition. Making an edition in Astoria is like taking a snap shot of the whole SGML file including all shared data or reused objects. In this case, we will make an edition of the Tb.cat.sgm document, the catalog file for the mTshams brag edition. In doing so, Astoria will place all reused SGML in the appropriate place and create a static, unchangeable version of the complete file so that it can be published on the internet. Any changes subsequently made to any of the files will not be reflected in the edition until the edition is remade and reposted. One makes an edition by first highlighting the edition catalog file or Tb.cat. Then, under the Object menu, the last option is called Make Edition. Choose this, give the edition a name (Tb.ed in this case) and a description (date or some distinguishing piece of information about this edition), choose where to place it (generally before the catalog file), and click OK. After some time, a book icon will appear above the catalog file. This is the published edition. It cannot be changed or modified in Astoria but is a snap shot or a version of the edition frozen in time. One can then export this edition and post it to Dynaweb, making the information available on the web.

If, for whatever reason, one would like to have a copy of any particular file in Astoria, the program does allow one to export information to a disk. The resulting SGML document will have no ties to Astoria and can be edited and used as desired. Changes made to it will not be reflected in Astoria, nor will changes made to the Astoria file be reflected in it. In general, it should only be used to get material for prototyping other stages of the project or for publishing an edition to Dynaweb, as mentioned above. To export a file from Astoria, highlight that file and then choose Export from the file menu, or press F7. Use the resulting pop-up window to tell Astoria where to place the exported file and click OK. A clean copy of the file will be deposited on your disk in the specified location. (Note: When exporting text bibliographic records there are two ways to do it: by highlighting the document-that is, the image of a piece of paper followed by the SYSID-or by highlighting the TIBBIBL contained in that document. The former is the desirable option here. That way the exported document will have a public doctype declaration, which will be recognized by Epic. The other way, by opening that page icon and highlighting the yellow or red arrow and exporting, will give you a document with a system doctype declaration. This means Epic will look for the TIB or TIBBIBL DTD on your machine. Since it will not find the DTD there, the document will not parse and will instead open as a text file.)

Once the catalog record is complete, it can then be published. Because of the amount of sharing that is done in the Samantabhadra catalog, it is more time efficient to publish each volume individually and then cut and paste these into the edition catalog record, also published separately. This is done in the following way:

When the full catalog edition has been published, you need to run a Dynatext routine called Mkbook (i.e., make book) on the SGML file, which processes SGML and indexes it. If this is a final proofed version to be put up on the web, you do nothing but give it, along with the style sheets, to the network systems manager, who will run the Dynaweb's Mkbook on the Unix server and make the catalog from the link on our web-page. However, it is also possible to do this locally on a machine with DynaText and Dynaweb installed on it in order to locally view the catalog and proof it for style-sheet or SGML mistakes that proofreaders will not catch. But, before the new catalog can be view locally you have to locally make book on it. This is done as follows:

Once the book is "made", it can then be copied over into the corresponding folder in the Dynaweb application. If you are working on styles either manually or using InSted, these styles are kept on the Dynaweb. So, make sure you always copy the latest styles from Dynaweb to DText before making book. Then, after book is made, the whole folder can be copied back into Dynaweb for viewing. On the Dynaweb option on the Start Menu>Programs, there is a choice for "Dynaweb Internet Server http-6336 Controller" which will be the local server. (The number may be different.) Use this to start, stop, and restart the local Dynaweb server. This needs to be done every time you change the style sheets or re-make book.