Computer Encoding of Neumed Manuscripts:
Proposal for a Unified Data Representation


Louis W. G. Barton
University of Oxford
[e-mail]

Decoration

Table of Contents
§ Abstract § Design Principles
§ Overview § Representation of Neume Height
§ About Data Representations § Representation of Uncertainty
§ The Unicode Standard § Sample of Taxonomic Encoding
§ Compatibility with SGML and XML § Acknowledgments
§ Musicological Assumptions § Bibliography

§ Abstract

This paper is in the "read this or suffer the consequences" vein. It is intended for medieval musicologists and anyone who has an interest in how computers will be used in the future for archiving, analysis, and printing of medieval chant. The author presents his preliminary research findings in this area and requests feedback about the most basic issue in this area: How should transcriptions of neumed chant be digitally encoded? Digital encodings are the infrastructure upon which all types of computer programs depend. Its uses include database storage, data transmission, comparative analysis, visual presentation in print or electronic media, computer-based instruction, and so on. This paper pays special attention to early Western-European neume notation, since unheighted neumes pose special difficulties. The techniques discussed here can be extended to Byzantine and other Oriental notation systems. A unified encoding is propsed, so that data can be exchanged between different applications or computer platforms, and so that melodies in different notational styles can be compared. Encoding for common-practice notation has significantly different requirements from neume notation and cannot be effectively adapted. The encoding system proposed here is designed to (a) capture all prima facie semantic content of neumed documents, (b) promote long-term usefulness and interoperability of transcription files, and (c) be computationally efficient and disambiguous. The use of technical jargon has been kept to a minimum.

Keywords: Neume notation; Data representation; Computer encoding; Unicode; Medieval manuscripts; Chant; XML
Top of document

§ Urgent Need for Musicologists to Agree upon a Standard

Computers have provided enormous benefits in many fields. In music, the main focus has been in three areas: control of electronic instruments; digitization of sound; and processing of standard-practice notation. Despite the historical and cultural importance of neumed documents, little attention has been given by software engineers to the special difficulties of neume notation. Some musicologists foresee tremendous benefit to be realized by bringing the power of computers to bear on this body of literature.

The user-friendly nature of today's desktop applications, however, gives non-engineers a false impression of simplicity regarding the underlying structure of the data. (For their part, software engineers might easily underestimate the complexities involved with neume notation.) This paper poses fundamental design questions that should be of concern to all medieval musicologists, as computers are likely to play an increasingly important role in their field. Because it is interdisciplinary, the discussion is somewhat technical, yet the decisions involved are crucial and deserve attention. Poor design decisions at this juncture could have detrimental effects that would impede progress for years to come.

This is especially true regarding fragmentation of digital libraries; this means that, transcription files made for one program might not be usable by another program. Given the complexity of neume notation, automatic translation from one data format to another might be ineffective: the details of transcription needed by one program might simply be absent in a file created for another. The investment of skilled labor in making detailed transcriptions, and the typically low funding available to this field, make it especially important that standards for neume digitization be carefully designed and thorougly discussed by the community at an early date. It is axiomatic to software engineering that how information is digitally encoded, i.e., its data representation, will have a profound effect how programs can use those data.

If an effective data representation can be arrived at through study, discussion, and cooperation between musicologists and software engineers, the long-term benefits will be enormous. Putting this data representation in the Private Use Area of the Unicode Standard ™, as I propose below, will go a long way toward enforcing standardization of transcription files and discourage individual projects from creating their own data formats that are not shareable by others. As there are likely tens of millions of extant chant documents, it is vital that that a cooperative agreement be reached about what the future uses of transcriptions will be, what types of information are needed to satisfy all these uses, and how best to digitally encode these types of information.

§ Rationale for Encoding Neumes in Unicode

I Surely, every educated person has heard that modern computers use streams of zeroes and ones for data. One can't represent anything interesting if the only choices are 0 and 1, and so these bits are chunked together into standard-length groups. The most common grouping is the 7-bit ASCII standard, which (like the dots and dashes of Morse code) has arbitrarily assigned alphabetic letters to particular patterns of zeroes and ones. It is easy to understand that there are 27 (or 128) distinct bit patterns in a 7-bit code space. The correspondence from alphabetic letters to a 7-bit binary codes is called a data representation for the Latin alphabet. There are many different data representations for alphabets and other kindsd of information.

One new data represenation that is fast gaining acceptance is the Unicode Standard ™ [110], which has a code space of 16 bits. With 16 bits it is possible to represent 216 (or 65,536) different bit patterns. The Unicode Consortium ® has assigned a 16-bit code to each letter of every modern, written language in the world. The Unicode Standard ™ specifically excludes music symbols, but a portion of the code space, called the Private Use Area, has been permanently reserved for special symbols needed by particular disciplines. One discipline (say, astronomy) may agree on using the Private Use Area for one set of symbols, while another discipline can use this same area for its symbols (say, neumes). So long as it is unlikely that a program will need both sets of symbols at the same time, no conflict arises from these multiple uses of the Private Use Area. At the beginning of a data file is a declaration of which symbol system is intended.

Prior to the advent of Unicode, 7-bit ASCII was the near-universal standard for data exchange. Having, basically, only the letters of the alphabet to work with, a trick had to be used to get ASCII to represent more than 128 different symbols. Commonly, these additional symbols were represented by spelling them out in alphabetic characters, for example "virga" or "pes". Ambiguity is a inherent with this trick, though. Let's say a symbol is represented by the three ASCII letters "pes"; when a program encounters these letters, it is not clear what is meant, the symbol or the literal word (as in the sentence, "The pes is a basic neume form.") The trick used for distinguishing between symbolic and literal uses of a word is something called mode switching. One or more symbols are reserved in the data representation as escape characters, which indicate a switch in mode. Many people are familiar with HTML, the data representation for Web documents. HTML reserves the angle bracket characters '<' and '>' as escape characters. For example, "bold" in HTML is a literal word, whereas "<bold>" is modal, indicating bold-face type.

In this paper I refer to ASCII as a first-order data representation, because it is one step removed from the baseline, or binary, representation. HTML is a second-order data representation, because it cannot stand on its own. It is modal to an underlying first-order data representation (which is, in this case, ASCII). The great majority of data representations that have been invented for music are second-order data representations based on ASCII [87]. An important part of my proposal is to represent neume symbols as first-order characters in the Private Use Area of the Unicode Standard ™.

In addition to their inherent ambiguity, there is another problem with modal data representations. To English speakers, a second-order word like "<bold>" seems quite natural for its "human readability." If one doesn't know English, this doesn't seem so natural. Putting these modal tags (as they are called) into another language can also be a problem, since 7-bit ASCII does not include letters with diacritical marks. So much more so regarding on-Latin alphabets; consider the problem of representing Chinese characters in ASCII, for instance. Thus, the notion of "human readability" of ASCII is relative and is biased toward English speakers.

Computer users are accustomed to typing, say, a letter 'M' on the keyboard and seeing an 'M' appear on the screen. What actually goes on, however, is not so obvious. When one types 'M', the keyboard hardware generates the binary series 1001101 (which is the ASCII code for 'M'). This binary series is what actually gets stored in computer memory; it is not "human-readable". To display the character, the display hardware reads this binary code, then draws a picture of 'M' on the screen. These functions are built into hardware because they are so frequently used, but they are really programs that translate between keyboard input, binary storage, and drawings on the screen. In principle, any other desired translation could be done as well. (Similarly, a Web browser program reads the ASCII series "<bold>" then causes the display screen to draw letters in boldface.) It is crucial to this discussion that one should acknowledge that, (a) all computer data are essentially binary, and (b) program intervention is always required to make those data "human-readable."

It is a core argument of this paper that neume symbols should be represented as first-order characters in 16-bit Unicode, rather than as second-order, modal tags in ASCII. Typically, the way this would work is that, (a) one clicks on the picture of a virga from an on-screen menu of neume forms, (b) the program stores in memory the 16-bit code for a virga, and (c) the program draws a picture of a virga at the appropriate place on the screen. The complaint I often hear, that Unicode characters are not "human readable" the same way ASCII characters are, is vitiated by the foregoing arguments. Since ASCII characters must be interpreted by a program, the program might just as well interpret Unicode characters directly as neume symbols.

I hope these arguments will make sense to most people. So, what's the problem? The problem is that musicologists and their collaborators who create databases, analysis programs, notation editors, and so on, tend to use modal ASCII data representations. These are easy to understand, readable in one's native language, and very simple to work with in popular programming tools like Microsoft Access® and Visual Basic®. The great danger is that one person's data format will not be useable in another person's program. So, why don't we just agree on a common ASCII encoding for neumed data? There are two compelling reasons; one is technical and the other is based on experience.

The first reason has to do with disambiguation and processing efficiency. As explained above with "pes" and "bold," second-order data representations are inherently ambiguous. This is necessarily so by definition of a second-order data representation: the mode-switching trick is used as a means of overloading the code space of the underlying first-order representation. For a program to discern the correct interpretation of a character in the file, the program must maintain a record ot its current modal state. Doing so is not much of a problem if the file is always read from front-to-back (as is the case with HTML). It is much more troublesome, however, if the program has to move back-and-forth across the file.

My preliminary investigations into the process of editing a neumed file, or searching a neumed files for a melodic pattern, strongly suggest that complex traversal of neumed files will be a frequently used procedure. By "complex traversal" I mean that a program must repeatedly go backwards-and-forwards in a data file in a complicated pattern. Maintaining modal state during complex traversal is a great deal more difficult than when simply reading a file sequentially. In the worst-case scenario, for a program to back up from point B to point A it must first reset to the beginning of the file, then read forward to point A in order to establish the correct mode at that point. I have done a formal proof involving computational complexity classes (inappropriate for discussion here) that establishes that complex traversal of second-order data representations is extremely inefficient compared to similar traversal of first-order representations. The difference in efficiency is so dramatic that certain types of musicological analysis would be infeasible. Comparing hundreds of documents in a second-order data representation would simply take too long to be practical as a research methodology.

The second compelling reason is that, a first-order data representation that satisfies most people's requirements effectively inhibits individuals from developing their own data formats. A principal goal of the Unicode Standard ™ was to do away with the Babel of different encoding schemes for non-Latin characters; by producing a universal and language-neutral standard for digital encoding of all types of text, Unicode has largely eliminated the fragmentation problem for text documents. I should clarify here that Unicode characters are abstract symbols that constitute the semantic content of documents; the font or shape of characters on the screen or printed page, their size, color and other visual attributes, are encoded in a second-order data representation, not in Unicode. This division of responsibilities allows for complete flexibility in visual formatting, but ensures that content per se can be universally exchanged. This wisdom of this approach comes from decades of practical experience by computer professionals in the many corporations and universities, both foreign and domestic, that make up the Unicode Consortium ®.

I am very sympathetic with, and in favor of, pioneering musicologists who want to use computers to advance their work. My own interest in this began with my frustration over including examples of chant in word-processing documents. I am interested in systematic comparison of large numbers of manuscripts for shedding light on the origins of music writing and the transmission of melodies. I can imagine how, when I was a music student, the study of Aquitanian staffless notation might have been made easier by computer media. My training and twenty years of experience as a software engineer, however, tell me that medieval musicology cannot afford to be anything less than well-informed, deliberative, and unanimous in its approach to the data representation problem. The field is just too small and meagerly-funded to support fiefdoms of incompatible data. A well-conceived data representation is something that is difficult to achieve: it requires time and discussion, and it will require musicologists to learn enough about software engineering that they can participate wisely in the decision process.

§ Compatibility with Wider Standards

As savvy Internet users know, HTML (Hypertext Markup Language) is the 'language' of Web documents that allows documents to be viewed on nearly any type of computer. It is efficient for transmitting documents over the Internet, and it includes commands for controlling how a document will be presented (such as text color, text size, placement of images, and so on). As explained above, HTML is a modal, or second-order data representation based on ASCII. It is a specialization of a much larger language called SGML (Standard General Markup Language) [ ]. A more recent offshoot of SGML is XML (Extensible Markup Language) [112, 113]. XML has two distinct advantages over HTML. First, it allows Unicode characters to be included in a document, whereas HTML allows only ASCII. (Technically, the polarity of the first bit in a group establishes whether the group is 7-bit ASCII code or 16-bit Unicode). Second, XML is more flexible than HTML in that one can define custom ways in which documents will be formatted. A separate document called a DTD (Document Type Definition) specifies rules for how to present an XML document. (A DTD can be used by many XML documents; one simply specifies at the beginning of an XML document the Web location of the corresponding DTD.) XML is rapidly gaining acceptance and is likely to eventually replace HTML as the standard for Web documents.

XML is, of course, is a second-order data representation. Characters that are not mode-switched are considered to be literal text. Literal text in XML can be a mixture of ASCII and Unicode. As in HTML, the angle brackets '<' and '>' are reserved as escape characters for mode switching. Normally the modal tags (i.e., characters between angle brackets) are only ASCII characters; this restriction can be enforced by the DTD. If we follow this convention, then our Private Use Area characters for neumes will appear only in the non-switched (literal) mode. This has a tremendous advantage for complex traversal of data files. When a program reads a character at position P, it can always distinguish between ASCII and Unicode (with at most a one-character-position move in the file). Unicode neumed data, then, always have an unambiguous interpretation. Complex traversal of a neumed file, therefore, does not require state maintenance and is computationally efficient. Note that the text of a chant, too, can be encoded in Unicode instead of ASCII, making complex traversal of both text and melody computationally feasible. The XML language specification requires that all interpreter programs must be able to read literal text in either ASCII or Unicode.

Second-order data representations like XML are appropriate for some purposes. The most important of these are presentation (or, visual formatting), editorial commentary, and linkage to other documents (such as links to photographic images). Here it is vitally important to understand the different roles that literal data and modal data play in XML documents. In XML (as with HTML) the basic stuff of a document is its literal content, which is always encoded in the default (non-modal) representation. For transcriptions of neumed documents, the 'basic stuff' consists mainly of the chant text and the neumes. These should, therefore, be represented non-modally. For example, a virga symbol should be represented as a single Unicode character, not as an ASCII string such as "virga". The final section of this paper gives concrete illustrations of this concept. It is quite important to sort out which elements of a transcription belong in Unicode and which belong in an XML tag (or, modal string). The guiding principle I have used in this proposal is that prima facie semantic content of a manuscript should be in Unicode, and all other information about the manuscript or transcription should be in modal, XML tags. The reason that one does not put everything in the first-order representation has to do with the notion of meta-data. Basically, meta-data consist of information about a document, as opposed to the literal content of the document. How a document is presented visually, or what an editor has to say about the document (including identification of the transcriber, location of the manuscript, its foliation, and so forth) are really meta-data and are best handled in the flexible and extensible medium of second-order modes. If for some reason another program is unable to read these meta-data, relatively little harm is done provided that the program can read the actual content of the document: the program s imply skips over any meta-data that it does not know how to handle.

Many corporations have taken to putting all their text documents in HTML form so that the documents can be read by a wide variety of computer systems. Industry commentators generally expect that the future trend will be to put sharable documents in XML form. The rationale for consolidating data formats is sound, as it reduces the fragmentation of document archives. Many programming languages such as Java® can read and write XML, and it seems very likely that the software industry will continue expanding its support for XML as a medium of data interchange. Likewise, Java uses Unicode as its internal data representation for symbolic information, and the software industry has been quick to adopt Unicode as the standard representation for encoding symbolic information. As stated above, Unicode is fully supported by, and integrated into, XML. It is important to note here that the Unicode-XML combination being proposed here is intended as the medium of exchange for neumed data. If a transcriber finds that s/he is working with a program that does not use Unicode or cannot read and write XML, then remediation should be undertaken to ensure data compatiblity. For example, if one's database were organized hierarchically in terms of chant/verse/syllable/neume/note, then ideally at each level XML tag strings should be storable, and at the note level Unicode neumes should be stored.

In the area of literary texts, the Text Encoding Initiative (TEI) [102, 103] has been developing an XML DTD to serve a wide variety of needs among scholars, libraries, and so on. Again, the literal content is assumed to be text only, but Unicode characters can be used to encode non-English texts. A subset of the TEI DTD intended for medieval and late-Renaissance texts is under development by the Digital Scriptorium project [31]. This is being done in a manner that is sensitive to the special needs of early manuscripts, but also readable by software written for the TEI format.The Digital Scriptorium DTD includes a wide assortment of meta-data tags; a few examples serve to give the general flavor, as follows.
  • <pb> for a page break in the manuscript;
  • <add>, <del>, <sic>, and <corr> for scribal alterations;
  • <handShift> for a change in the handwriting;
So that neumed transcriptions can be used in the wider environment of electronic documents, I have proposed that the Digital Scriporium DTD include opening and closing <chant> tags. These would alert an interpreting program that the intervening material is in Private Use Area neume notation; if the program is unequipped to handle neumes, then it would simply skip the intervening material. In NeumeXML (as I call it), a transcription file can serve a dual purpose of musicological treatment or text-only treatment.
Top of document

§ Musicological Assumptions

In this proposal for a unified data representation, I have made various musicological assumptions. I present these here for review by the musicological community. Musicologists are urged to contact the author via e-mail concerning any disagreement with these assumptions. Please include specific examples where an assumption fails and (if possible) suggest an alternative premise. Such feedback will help ensure that the final data representation plan will be consistent and complete.

Assumption #1:
The chant text can be determined without ambiguity.

One assumption is that the text of a neumed document can be determined without ambiguity. Such determination can be done from a clear reading of the scribe's hand, or by reference to a 'control document' that one asserts to have the same text. In the case of reference to a control document, the chant texts are presumed to have much greater stability of transmission than chant melodies do. For these reasons, no accommodation has been made for frequent uncertainty in the transcription of text. Exceptional cases can be handled in editor's remarks outside the first-order data representation [*].

Assumption #2:
Horizontal placement of neumes is not significant.
Neumes appear in series, and their sequential ordering within a series is of semantic importance. A series of neumes is associated with a particular syllable in the chant text, specifically with the vowel of that syllable (even though the vertical alignment on the manuscript might not be exactly over the vowel). The horizontal orientation of the first neume in a series is, therefore, presumed to align horizontally with the corresponding vowel. Aside from this constraint, however, the horizontal placement of neumes in source documents is assumed to be of little or no semantic significance [**].

The horizontal placement of neumes and text can be of great importance in the visual presentation of a document, such as for display or printing. Please note, however, that such horizontal placement information does not pertain to the semantics of the neumed data but, rather, to the layout of the presentation document. Therefore, this type of information does not belong in the semantic data representation, but rather in second-order markup tags, for instance in XML (see discussion of XML, below).

Assumption #3:
Notational families are not mixed in a single chant.
I am assuming that, in the overwhelming majority of cases, two notational styles are not mixed in one chant in the original manuscripts [***]. Indication of the notational family is, therefore, put in the second-order data representation. Exceptional cases could be handled by mode switching in the second-order representation.

In presentation, one often wishes to show several examples of chant in parallel, where the notational styles of the examples can be different. For example, one might wish to present a snippet of chant in St. Gall notation and, below that, a reference transcription in simple dot-head notation. Or, one might wish to compare two versions of a chant segment in Aquitanian and Beneventan notation in parallel. Such scenarios are certainly feasible with the proposed data representation: each snippet would be treated as a separate data series, and each would have its notational family specified in the second-order, markup language. The visualization program would be responsible for rendering the semantic neumes in the intended notational style. Key points where the examples should line up vertically could also be specified in the markup language as anchors, so that the visualization program would maintain the desired alignment.

Assumption #4:
Asserting semantic equivalence across notational families is of positive value.
Musicologists hypothesize that there is substantial taxonomic synonymy across styles of neume notation. For example, the notion of a virga is presumed to have similar ideational semantics, regardless of how the neume was written or what vocal phenomenon it represented in a particular oral tradition. If the "intensional" semantics of neume forms were fairly consistent across time, geography, and religious congregation, then the idea of a virga was understood by all music scribes, regardless of their method of writing it. This claim seems plausible, though it has yet to be adequately supported by evidence.

Whether or not this claim eventually is upheld, the benefits of asserting taxonomic synonymy across notational styles in the data representation outweighs the potential risks. This would allow for any number of notational families and sub-families to be defined, with little or no change to the data representation. By contrast, assigning a unique Unicode character to each neume form of each notational family would consume substantial code space, which is a finite resource. It would also inhibit individual researchers from establishing sub-families that they might need for specialized types of investigation. Automated comparison of melodic figures from many documents would be greatly simplified by using this convention of abstract neume forms. Since the notational style remains constant throughout a chant, the notational family is best represented in the second-order, markup language at the head of the data.
Notes:
* James Grier emphasizes that Assumption #1 does not imply that a particular chant melody can be identified from the text. Some texts have more than one melody in the transmission; some texts are used for more than one genre (antiphon, responsory, Alleluia verse, etc.). This is a weakness of the CANTUS indices, because they do not include melodic information. The occurrence of the same text in two or more manuscripts indexed by CANTUS does not necessarily mean that they all transmit the same melody.
** John Caldwell points out that horizontal placement could be semantically meaningful if it affected the phrase-divisions of the chant. In my opinion, such information should be captured in the second-order data representation. I would, however, welcome further discussion about this assumption.
*** Regarding Assumption #3, James Grier writes as follows: "I know of no situation in which notational families are mixed in a single chant, but there is at least one famous instance of the mixing of notational families in the first layer of a single manuscript, Paris, BNF latin 1240, which mixes Aquitanian and northern French dialect. John A. Emerson has written about this feature of this manuscript in Recherches nouvelles sur les tropes ..., ed. Wulf Arlt and Gunilla Bjorkvall (Stockholm 1993)" [private communication].
Top of document

§ Design Principles

The guiding principles in my solution are (a) to minimalize the fragmentation of digital libraries, and (b) to maximize the permanence (or, lasting usefulness) of transcription files [35]. My solution extends the Unicode Standard ™ [110] to represent as individual characters all semantic (i.e., musically or textually meaningful) information that is evident prima facie in a source document. Semantic content includes primarily Latin text and neumes. Descriptive information about the document (e.g., attribution, residuals of musicological analysis, and so on) is represented in a tagged language, such as XML. I discuss, below, the reasons for my handling transcription information differently from description information. My presentation necessarily relies on concepts from software engineering, but I have tried to clearly explain these concepts as needed.

The first goal of the Neume Notation Project is to design for neumed manuscripts what I call a "lossless data representation" (a term I coined). A data representation is a scheme for encoding units of information from source materials as digital data, such that the data can be used efficiently for analysis, visual presentation, and so on. A "lossless" (or universal) data representation is one that captures all semantic content of the source document in such a way that all present and anticipated future uses of the data are supported. The base representation should be capable of encoding the Latin chant text, neume identifiers, neume heights, and other information that is evident prima facie in the source document, and that can reasonably be considered as musically or textually meaningful. The data representation I have designed also includes certainty factors (CFs) that can be used to record the transcriber's uncertainty about neume identification or neume height. Graphical formatting is not in the semantic data representation, but rather is accommodated in markup tags (such as XML tags); likewise, document identification and editing remarks are placed in markup tags. Data representations for plainchant that have been devised by others have been conceived with particular uses in mind; chant features that were not needed for the particular purpose were ignored so as to keep the data representation simple. One consequence of this semantic simplification is that it has been difficult for researchers to reuse data files that were created by others. The data representation I propose is "lossless" in the sense that it captures all information that is likely to be needed, and documents encoded under this scheme have a high likelihood of being reusable. Features that are not of interest in a particular use can simply be ignored under program control.

Depending on how one counts them, the domain of source documents might number in the millions. Medieval musicologists should have an interest in bringing the power of computers to bear on this large body of material. One motivation is to automate the retrieval and comparative analysis of many neumed documents from digital archives; the goal would be to shed light on various musicological questions that have resisted manual methods, such as the transmission path of particular melodies, or the origins of neume notation. Undoubtedly, a new generation of musicologists–who have been raised in the digital age–will find novel ways to exploit digital libraries for innovative purposes.

There are two main categories of use that I anticipate for the proposed data representation. Their requirements are as follows:
  1. that the data representation be sufficiently formal and abstract as to allow comparative analysis of melodies and notational styles across many documents; and

  2. that it be possible to reconstruct from the data representation a diplomatic facsimile of source documents in their native notational styles for computer display, editing, or printing.
These two categories of use are normally called "processing" and "publishing." In terms of designing a data representation, the requirements of these uses conflict. (Data representations for post-medieval music typically specialize on one of these, but not both; still others focus on representation of musical performance.) I intend the data representation to serve both categories of use mainly to avoid redundancy of effort in making transcriptions, and to avoid data-consistency problems that arise from multiple file-formats. A high priority, therefore, is to design a data representation that will allow a single, unified data format for plainchant.

It is a considerable challenge to design a lossless data representation for neumed documents. To my knowledge, no data representation has yet been proposed that satisfies the criteria listed above. Though much work has been done during the past thirty years to "computerize" standard-practice notation of music, its requirements are markedly different from plainchant. One of the main differences is that standard-practice notation is grounded in the rule of discrete time units and discrete pitches. Data representations for standard-practice notation that I have studied incorporate this assumption deep in the data encoding. Though some scholars believe that neumes can designate discrete time intervals and definite "tones," this assertion has not been proven in the general case [*]. At the level of the base data representation, one must not make unwarranted assumptions about this crucial information, and (as stated above) it is important that there be a unified scheme for encoding all neumed documents. Force-fitting chant into a time- and tone-specific scheme would impose a particular interpretation of the source materials. Doing so "flattens" the semantics of the original documents, and is very likely to be injurious to scholarly study of them. Furthermore, in early neumed documents there can be genuine uncertainties, especially about the height of neumes. A lossless data representation seeks to preserve these ambiguities. Programs that use the data can simplify (or flatten) the semantics if doing so seems appropriate for a particular use. Uncertainty can be so frequent that a metric of it belongs in the data representation, itself, rather than in markup tags (see § Design Principles). Such is not the case with standard-practice notation, where uncertainties are normally in critical editions only and are relegated to occasional footnotes.

The Neume Notation Project includes other work, not discussed in this report, as follows:
  1. a graphically-oriented editing program (with neumes displayed in a stylization of their native forms) for visual data-entry, editing, and printing;
  2. a Web-accessible database of encoded documents and related information, which scholars can access or supplement; and
  3. proof-of-concept investigation into optical character recognition (OCR) for automatic, rough-draft data entry.
Each of these project modules interacts with the data representation described here. All of the programming I am doing is in the platform-independent Java language. While I do not plan to do much in terms of analysis methods myself, I am collaborating with John Caldwell's research group in Oxford to understand what implications analysis might have on the data representation. I also welcome collaboration from others toward this end. As data entry can be quite labor-intensive, the prospect of OCR holds the most promise for building archives. I am convinced that the best type of images to use for OCR are the sort of thing being done by another group in Oxford [37]: high-quality, full-color, digitized photographs of complete manuscripts that are accessible via the Web. I am experimenting with techniques in artificial intelligence for rough-draft recognition, especially for early manuscripts. In the broader view, I hope ultimately to arrive at a theoretical framework for digital encoding of archaic scripts that could be applied also to Byzantine ecphonic notation and Hebrew cheironomic notation. An interoperable data representation might facilitate study of possible links between plainchant and earlier forms of chant.
Notes:
* I am grateful to John Caldwell for pointing out to me that some scholars do argue that some neume notations do represent strict proportions.
Top of document

§ The Unicode Standard

Under the scenario of pattern matching of melodic contours, a huge burden is placed on an analysis program if it must deal with complex context-dependency. Processing would likely be very slow but, more significantly, the complexity that the programmer would face in writing such a program is vastly increased. An axiom of software engineering is that, if the complexity of a program becomes to great, then the program essentially becomes unmaintainable.

My semantic data representation for neumes uses the Private Use Area of the Unicode Standard in which to encode a distinct bit pattern for each neume form. I define a "neume form" as an abstract neume type (viz., punctum, virga, pes, etc.). Each general type can have many variants (such as pes at interval of 2nd, liquescent pes at interval of 2nd, pes at interval of 2nd with first note an apostropha, etc.); each distinct semantic variant has a separate Unicode assignment. Thus, the semantic data representation for neumes is a non-modal, first-order representation. There are three main advantages to this solution: (a) reduced program complexity; (b) faster processing; and (c) standardization that promotes interoperability of data files from different scholars and long-term usefulness of those files.

In a data stream the characters of chant syllables would be intermixed with characters that represent neumes and neume heights. The rule is that a neume series goes with the Latin syllable immediately preceding it, and ends at the next Latin syllable. A neume identifier is followed immediately by its height specifier(s). A simplified example might help clarify this concept. For this example, say that a letter like "K" denotes itself, and a bracketed word like "[pes]" denotes a Unicode character in the Private Use Area. The (simplified) data stream for the first "Kyrie eleison" of Kyrie XI from the Liber Usualis would be as follows:

Ky-[pes][LowerHeight][UpperHeight]ri-[clivis][UpperHeight][LowerHeight]e[clivis][UpperHeight][LowerHeight][epistema][Space]e-[punctum][Height][pes][LowerHeight][UpperHeight][virga][Height][punctum][Height][punctum][Height][virga][Height][punctum][Height][punctum][Height]le-[punctum][Height]i-[punctum[Height]son.[punctum][Height][iij]

A program interested in only the text could easy ignore the neume and height characters. Likewise, a program interested only in the melody could easily ignore the text characters. To ensure data integrity, the text and musical notation are kept together in the same file. To create a clone of the text, the program could easily strip out the text and copy it to a new file.
Notes:
* I am indebted to Ugo O. Gagliardi for first proposing the idea to me that 16-bit Unicode is the proper encoding scheme in which to represent neume information.
Top of document

§ Design Principles

In this section I discuss the guiding principles I have used in designing the semantic data representation for neumes. It might be of interest to musicologists, and comment is welcome.

Principle #1:
Keep most of the semantics at the character level.
The semantics of the data should be kept at the 'character level' (i.e., in a first-order representation) rather than at the 'metacharacter level' (i.e., in a second-order, or markup, representation). There are several compelling reasons for this, as follows:
  • it reduces conceptual complexity by imposing an orderly scheme of classification;
  • it reduces the complexity of programs that interpret the data, by minimizing context dependencies (viz., by simplifying the parsing process);
  • it reduces the bloat typical of ASCII-based, second-order representations (such as HTML) and, thus, speeds Internet transmission;
  • it typically results in faster processing time of programs that interpret the data;
  • it aids the formal specification of a grammar by minimizing the possibility of circular or ambiguous definitions of terms; and
  • it tends to enforce standardization and, therefore, long-term interoperability of data.
The latter point deserves further comment. The standardization issue poses, in my opinion, the strongest argument in favor of a first-order data representation for neumed documents. I have been observing proposed schemes for representing musical information since the late 1960s. During that time, nearly all proposed data representations have been second-order, ASCII representations. (For an in-depth discussion of data representations for music see [87].) (In fairness it must be said that, until the recent advent of the Unicode Standard the only feasible format for interoperable data was ASCII.) The many "standards" that have been put forward over the years have resulted in fragmentation of digital libraries, where it is difficult or impossible for one scholar to reuse the data files created by someone else. Translation between file-formats has been largely unsuccessful due to the following process:
  1. because data-entry is so labor-intensive, data representations were tailored to particular uses of interest to the designer; this tailoring simplified the semantics of neumes and resulted in what I call "lossy" data representations;
  2. because the needs of one researcher are often different from those of another, the semantic content that was left out by the design was often of central importance to the needs of another researcher; and
  3. in the second-order data representation, the proxy names given to semantic features followed American English usage or some other natural language, which posed difficulties for researchers whose native language was different.
The result has been that the many hours spent encoding chant have been wasted in so far as data interchange is concerned. I wish to help bring an end to the data incompatibility problem by designing a lossless data representation that will serve the present and future needs of most researchers. Having the semantics encoded in a first-order data representation discourages individuals from modifying the data representation for their particular needs. A second-order representation in ASCII, without the restraint of a governing standards body, invites such idiomatic customization, because it is so easy to modify the definition of ASCII descriptors.

A first-order data representation, on the other hand, occasions its own concerns: ease of data-entry, and extensibility. A lossless data representation contains so much detail that hand-coding of data is not feasible on a large scale. I am addressing the ease of data-entry problem on two fronts: (a) a graphically-oriented program that permits visualization of documents in a stylization of their native notational family, and with easy editing of transcriptions; and (b) optical character recognition (OCR) for automated rough-draft transcriptions . I plan to give a detailed treatment of these two topics in subsequent papers.

Extensibility means the capacity to extend the semantics of the data representation if such a need arises in the future. This type of flexibility conflicts somewhat with the need for standardization. If a "standard" can be modified, we risk that file formats will become incompatible. The approach taken by the Unicode Consortium (and a good one, I think) is to deliberate publicly before standards are adopted, not to invalidate previously-adopted decisions, and to leave gaps in the code space for future extensions. There is a tension between the immediate need for a standard, and the wisdom of proceeding with caution. A premature rush to standardization risks that experience of use might reveal that important semantic elements have been overlooked. I am leaving gaps in the code space of the data representation so that new codes can be added later without invalidating data or programs that were written under the original scheme. Basic architectural flaws in the design of a data representation are, however, difficult to remedy after a standard has been put into use. I am eager, therefore, for musicologists to try to understand the core ideas that I present in this essay, and to send me their general comments or specific reservations.

Principle #2:
Semantics that change with low frequency belong in at the metacharacter level.
Some features of a neumed document are fairly constant. Examples of features that change with low frequency are:
  1. identification and description of the source document (possibly with links to catalog databases such as the CANTUS project [22, 23];
  2. description of the chant (including its ecclesiastical purpose) and folio identification (possibly with a reference link to its on-line, digitized image);
  3. identification of the notational family (Aquitanian, St. Gall, square neume, and so on);
  4. specifications of the staff lines (if any) and colors used;
  5. changes in scribal hand; remarks about insertions and erasures; editing remarks by the transcriber; and so on.
These features should be in a second-order data representation, viz., in XML tags.

The decision about whether a given element-type belongs in the first-order data representation or in a second-order data representation is most practically done using the frequency-of-change criterion [*]. Assume that neume characters are the "atomic" unit of organization in the data representation. If, on average, an element-type (say, neume height) changes in value at least once per three or four "atomic" units, then the element-type should definitely be encoded in the first-order data representation. If there is one change per ten units or so, then it is a 'grey area' judgement call. If an element changes much less frequently than one in ten units, then it should likely be represented in a second-order data representation. To accurately determine rates of change, one would need to calculate the probability distribution over a representative sample of documents. Andrew Hughes asserts that "A minute number of these [neumed documents] are catalogued at all adequately, and many fewer [are] known in detail" [44, p. 2]. If I understand this statement correctly, then the selection of a statistically representative sample is not possible at this time. In assessing frequency-of-change I have, therefore, relied on estimates by experienced musicologists.

Principle #3:
Eliminate context-dependency as much as practically feasible.
Most people are familiar with Web content, which comes in fairly small chunks from a server. Because of the manageable size of these chunks, and because HTML documents are always read serially (from top to bottom) by the browser, the text content can be embedded inside complex, contextual information. Examples of context information include font specifiers, tables, bullet lists, and so on. Some types of context information can be nested (placed one inside another), creating complex interdependencies. The designers of HTML did not intend that a document could be accurately interpreted by starting to read it in the middle. By contrast, consider the scenario of comparing melodic fragments from hundreds of neumed documents, where the analysis program might need to go backwards and forwards in a document repeatedly to do pattern matching. Keeping track of complex contextual information for each document under such a scenario could result in a very complex programming job; the resulting program might be so complex that future modifications to it might be infeasible.

An HTML-like restriction (that a document must be serially interpreted from its beginning in order to correctly interpret a particular section) would be overly burdensome to the writers of analysis programs. Under a worst-case scenario, correct interpretation of the data in a particular folio might require downloading and interpreting all of the manuscript up to that point, even if pages of the manuscript are individually accessible from an archive. This illustrates one of the major problems with modal data representations for the purposes stated in this paper: it is not possible to reliably interpret the meaning of local information without first reading the whole context that has preceded it. One guideline for designing a data representation, therefore, is to minimize the dependency of local interpretation on global context. (Recognizing this problem with HTML, the designers of XML have devised "well-formedness" requirements to reduce context dependency; nevertheless, it falls short of the degree of context independence needed for pattern-matching analyses.)
Notes:
* The idea of using rate-of-change and probability distributions for determining what elements belong in the character-level data was first suggested to me by Ugo O. Gagliardi.
Top of document

§ Representation of Neume Height

A recalcitrant problem is the specifying of neume height (i.e., vertical position). Using the frequency-of-change criterion, specification of neume height belongs in the first-order data representation, not in a markup tag. Stated another way, neume height is part of the semantics of the neume, itself. Under the scheme I have devised allows three types of height specifiers:
  1. degree of the scale (with regard to the ecclesiastical modes, viz., 'doh', 're', 'mi', etc.);
  2. relative movement (i.e., qualitative, vertical offset from the previous neume, such as "up a little," "up a lot," "down a little," etc.); or
  3. absolute position (i.e, quantitative, vertical offset (measured in increments of, say, half a millimeter) from a reference line, such as the scribal line on which the chant text was written).
A neume character is followed by a height specifier, or it can be followed by two height specifiers. When there are two height specifiers, type #1 and type #2 are allowed together, or type #2 and type #3 are allowed together. Of course, in the case of a compound neume (one designating two or more tones) multiples of these height specifiers would be used, one set for each tone.

Type #3 (absolute position) would be possible to produce during the process of optical character recognition (OCR) from a digitized image of a document. Both the lower bound and the upper bound of the neume's absolute height should be recorded. It is an acknowledged problem that the scribal line for the text might not be reliably straight (possibly due to distortions of the parchment itself); perhaps another baseline could be chosen. It would be useful to store this information, even if it is not a consistent indicator, because it serves as a "sparse" record of visual position; it is an efficient middle-ground between (a) large file, fully-detailed photographic images, and (b) small file, abstract semantic transcriptions. Although OCR is not currently feasible for neumed documents in the general case, its potential benefits for ease of data-entry are so great that code space for absolute height has been reserved in the data representation. Increments of a half-millimeter above a local reference line should, I think, give sufficient resolution, and so not many character codes are consumed. One could (automatically or manually) convert absolute height to a type #1 or type #2 specifier, but I think it would be advisable to leave the original specifier also in the data.
Top of document

§ Representation of Uncertainty

Especially in early documents, the taxonomic identity of a neume can sometimes be difficult to determine. In such cases, the neumed data character can have associated with it a 'marker' to indicate uncertainty of transcription. More frequently, neume height can be quite difficult to determine, especially for sources having fewer than four 'staff' lines and where corrective insertions have been made. In the data representation, I have provided several certainty factor characters for marking the degree of certainty with which the transcription was made. If present, these follow immediately after the neume character (in the case of taxonomic uncertainty) and/or its height specifier(s). Transcription uncertainty can be an important consideration for programmed analysis or comparison; it can also signal the potential need for transcription checking by a more experienced transcriber or validation against another image of the source document.

It is worth noting that no distinction is made between uncertainty on the part of the transcriber and uncertainty by the scribe (due, perhaps, to the scribe's inexperience, or due to inexactitude in an evolving notational system). Furthermore, CFs in the data representation are reserved for visible neumes. Other types of 'uncertainty' (such as document damage, alternative interpretations, or transcriber's remarks) shall be represented in the second order data representation. The rationale is that such judgements do not represent prima facie semantic content of a document.

In the field of artificial intelligence, uncertainty (or, ambiguous interpretation) is commonly handled by attaching a certainty factor (CF) to the data item, where a CF is a number quantifying the degree of certainty. Ordinarily, a CF is assigned by a human transcriber; a common problem in such matters is to maintain consistency in the way CFs are assigned across transcribers or across transcription sessions. Although two musicologists might agree that the identification of a particular neume is uncertain, their CF assignments might be significantly different. It is difficult even for one person to maintain consistency in her/his CF assignments over time. The CF scale should, therefore, not make overly fine distinctions, and be presented to the transcriber in qualitative (rather than numeric) terms.

In this data representation I have allocated twenty-one Unicode characters for CFs. These characters correspond to numeric values from +1 to -1 in steps of one-tenth, {1.0, 0.9, 0.8, ..., -0.9, -1.0} [*]. (This range can, of course, be normalized to a different range on-the-fly if a program uses a different scale.) Table 1 summarizes of the meanings of these values [41, 42]. p. 5. Uncertainty: this seems OK to me. I do wonder about the four categories. I'd have thought there would be a default value, "is", and that only uncertainty would be noted: probably this, maybe this.


"definitely is" CF = 1.0
"probably is" 0.2 > CF < 1.0
"might be" 0.0 > CF <= 0.2
"completely uncertain" CF = 0.0
"might be wrong" -0.2 >= CF < 0.0
"probably is wrong" -1.0 > CF < -0.2
"definitely wrong" CF = -1.0

Table 1. The semantics of Certainty Factor values.


The value 1.0 denotes full positive certainty, taken in a reasonable way (such as, "quite confident"). The value 0.0 denotes "total guesswork." The negative numbers would normally not be present in transcriptions; they are reserved as counter indicators to denote evidence against a previously-made assignment. Negative CFs might appear in secondary data streams as the result of comparison between 'target' and 'control' documents. A negative CF might defeat an earlier-concluded neume identification or neume height.

In general, a CF greater than 0.2 indicates "known true"; a CF between -0.2 and 0.2 (inclusive) indicates "not known"; and a CF less than 0.2 indicates "known false."

If CFs are not present in the data stream, a CF value of 1.0 ("definitely is") should not be automatically assumed; rather, the CFs should be understood as 'missing' or 'unspecified'. A data-entry program may, however, make CF assignments 'by default' (unless the transcriber specifies otherwise) so as to save time during transcription.
Notes:
* The reader might notice that this system of positive and negative certainty factors expresses the truth values of a ternary (or, three-valued) logic. Under the CF scheme presented here, there are eight degrees of 'true," eight degrees of "false," and five degrees of "indeterminate" or "unknown." There is a tacit, fourth truth value in this data representation, namely that no CF was specified.
Top of document

§ Sample of Taxonomic Encoding

One of the first priorities of this research is to compile an exhaustive taxonomy of neume forms across all notational families. In a subsequent article I shall propose a complete neume taxonomy that I am constructing in consultation with my advisory panel. Public comment will be invited at the detail level before the Unicode assignments are finalized. In the meantime, I offer the following example of assignments for the pes/podatus neume form to give an indication of the code space needed to represent a two-note neume [*].

Note that the corpus of known documents in a given notational family might not exhibit every variant in the taxonomy. Furthermore, if one is interested in occurrences of neumes at a coarser granularity than is accommodated by the representation (e.g., if one wishes to identify pes neumes at the interval of a second regardless of the presence of an apostropha or any other sub-variant), then one simply needs a table of equivalences in the analysis program, such that all sub-variants of a form are equated to a single code. For example (using the sample codes given below), occurrences of E00D, E011, E016, E01B, E020, E025, E02A, E02F, and E034 in the data stream could all be mapped to E009 by the analysis program.

 
Neume form:	virga


Example: 
Number of variants = 4


Unicode	Variant
 E004	virga
 E005	liquescent virga
 E006	substitute-style virga
 E007	liquescent substitute-style virga

Table 2. Sample encodings for the virga neume form. 

Neume form:	pes (or podatus)


Stylized Examples: 


Number of variants = 50

Remarks:
"Oriscus 1" replaces the first note of the pes.
"Oriscus 2" replaces the second note of the pes.
"Oriscus 3" is a third note added at the end of the pes,
	and is at the same pitch as the last note of the pes.

Unicode  Variant
  E008   pes at interval of 2nd
  E009   pes at interval of 3rd
  E00A   pes at interval of 4th
  E00B   pes at interval of 5th
  E00C   pes at interval of 6th
  E00D   liquescent pes at interval of 2nd
  E00E   liquescent pes at interval of 3rd
  E00F   liquescent pes at interval of 4th
  E010   liquescent pes at interval of 5th
  E011   liquescent pes at interval of 6th
  E011   pes at interval of 2nd; first note is oriscus 1
  E012   pes at interval of 3rd; first note is oriscus 1
  E013   pes at interval of 4th; first note is oriscus 1
  E014   pes at interval of 5th; first note is oriscus 1
  E015   pes at interval of 6th; first note is oriscus 1
  E016   liquescent pes at interval of 2nd; first note is oriscus 1
  E017   liquescent pes at interval of 3rd; first note is oriscus 1
  E018   liquescent pes at interval of 4th; first note is oriscus 1
  E019   liquescent pes at interval of 5th; first note is oriscus 1
  E01A   liquescent pes at interval of 6th; first note is oriscus 1
  E01B   pes at interval of 2nd; first note is oriscus 2
  E01C   pes at interval of 3rd; first note is oriscus 2
  E01D   pes at interval of 4th; first note is oriscus 2
  E01E   pes at interval of 5th; first note is oriscus 2
  E01F   pes at interval of 6th; first note is oriscus 2
  E020   liquescent pes at interval of 2nd; first note is oriscus 2
  E021   liquescent pes at interval of 3rd; first note is oriscus 2
  E022   liquescent pes at interval of 4th; first note is oriscus 2
  E023   liquescent pes at interval of 5th; first note is oriscus 2
  E024   liquescent pes at interval of 6th; first note is oriscus 2
  E025   pes at interval of 2nd; oriscus 3 added at end
  E026   pes at interval of 3rd; oriscus 3 added at end
  E027   pes at interval of 4th; oriscus 3 added at end
  E028   pes at interval of 5th; oriscus 3 added at end
  E029   pes at interval of 6th; oriscus 3 added at end
  E02A   pes at interval of 2nd; first note is apostropha
  E02B   pes at interval of 3rd; first note is apostropha
  E02C   pes at interval of 4th; first note is apostropha
  E02D   pes at interval of 5th; first note is apostropha
  E02E   pes at interval of 6th; first note is apostropha
  E02F   liquescent pes at interval of 2nd; first note is apostropha
  E030   liquescent pes at interval of 3rd; first note is apostropha
  E031   liquescent pes at interval of 4th; first note is apostropha
  E032   liquescent pes at interval of 5th; first note is apostropha
  E033   liquescent pes at interval of 6th; first note is apostropha
  E034   pes at interval of 2nd; second note is apostropha
  E035   pes at interval of 3rd; second note is apostropha
  E036   pes at interval of 4th; second note is apostropha
  E037   pes at interval of 5th; second note is apostropha
  E038   pes at interval of 6th; second note is apostropha

Table 3. Sample encodings for the pes/podatus neume form.

Notes:
* I am indebted to Bradford Maiani for his suggestions on taxonomic variants of neume forms. See also [24].
Top of document

§ Acknowledgments

The author did early work on this project while an undergraduate student at Yale University under the supervision of James Grier and Peter J. Kindlmann. As a master's degree student in computer science at Harvard University, he continued this work under Thomas E. Cheatham, Jr., Thomas Forrest Kelly, and Ugo O. Gagliardi. The project is currently the subject of his doctoral research in software engineering at the University of Oxford under Peter Jeavons, and in collaboration with a research group headed by John A. Caldwell. Consultants to the project include Bradford Maiani, Analissa Doneda, Consuelo W. Dutschke, Charles Faulhaber, and Merrilee Proffitt. For their help along the way, the author wishes also to thank Andrew Hughes, Claude V. Palisca, Alejandro Planchart, Gregory Proctor, Leo Treitler, and Craig M. Wright.
Top of document

§ Bibliography

  1. Apel, Willi, Gregorian Chant, (Bloomington, IN: Indiana University, 1958).
  2. Arlt, Wulf, and Susan Rankin, Stiftsbibliothek Sankt Gallen Codices 484 & 381 / kommentiert und in Faksimile herausgegeben, (Winterthur: Amadeus, 1996).
  3. Babb, Warren, tr., Hucbald, Guido, and John on Music; Three Medieval Treatises, (New Haven: Yale University, 1978).
  4. Barker, Andrew, ed., Greek Musical Writings, Volume I: The Musician and his Art, (Cambridge, England: Cambridge University, 1984).
  5. Barksdale, A. Beverly, The Printed Note; 500 Years of Music Printing and Engraving, (Toledo, OH: Toledo Museum of Art, 1957).
  6. Barton, Louis W. G., "Charlemagne and Alcuin: The Dawn of Modern Plainchant," (unpublished paper, 1995).
  7. ––––––, "The Culture of Medieval Music Calligraphy and Early Music Notation," (unpublished paper, 1995).
  8. ––––––, "Data representation for medieval chant manuscripts," (unpublished paper, 2000).
  9. ––––––, "Medieval Music Notation Using Personal Composer," (unpublished paper, 1995).
  10. ––––––, "The Music Editor," (unpublished paper, 1973).
  11. ––––––, "Semantic Data Representation for Neumes," (unpublished paper, 2000).
  12. ––––––, "Semantic Modelling; A 4-tiered methodology for decomposing applications," (unpublished paper, 1997).
  13. ––––––, "Using Personal Composer for Windows with Louis Barton's Medieval Music Font," (unpublished paper, 1995).
  14. Belan, William Lee, "The Conducting of Gregorian Chant: A Study of Chironomy as Applied to the Semiology of Neumatic Notation, with Performance Editions of Five Selected Examples of Gregorian Chant," (Norman, OK: University of Oklahoma, doctoral thesis, 1984).
  15. Bergeron, Katherine, "A Lifetime of Chants," in Katherine Bergeron and Philip V. Bohlman, ed., Disciplining Music; Musicology and Its Canons, (Chicago: University of Chicago, 1992).
  16. Boethius, Anicius Manlius Severinus, Fundamentals of Music, Calvin M. Bower, tr., (New Haven: Yale University, 1989).
  17. Bray, Tim, "Adding Strong Data Typing to SGML and XML," at http://www.textuality.com/xml/typing.html
  18. Burnard, Lou, ed., "Reference Manual for the MASTER Document Type Definition," at http://www.hcu.ox.ac.uk/TEI/Master/Reference/.
  19. Caldwell, John Anthony, "Creation and Development of a Database of Neumed Ecclesiastical Chant," (research grant proposal to the Arts and Humanities Research Board [U.K.], 1999).
  20. ––––––, Editing Early Music, (Oxford: Clarendon, 1985).
  21. ––––––, Medieval Music, (Bloomington: Indiana University, 1978).
  22. CANTUS database project, at http://publish.uwo.ca/~cantus/fdes80.html.
  23. "CANTUS; A Database for Gregorian Chant," at http://www.cua.edu/www/musu/cantus/home.htm.
  24. Cardine, Dom Eugène, Gregorian Semiology, (Sablé-sur-Sarthe, France: Abbaye Saint-Pierre de Solesmes, 1982).
  25. Castan, Gerd, "Common music notation and computers: SMDL, NIFF, DARMS, GUIDO, abc," at http://www.s-line.de/homepages/gerd_castan/compmus/index_e.html.
  26. Corbin, Solange, Die Neumen, (Cologne: Arno Volk-Verlag; Hans Gerig KG, 1977).
  27. Coussemaker, Edmond de, Hucbald; moine de St. Amand et ses traités de musique, (Osnabrück, Germany: Biblio Verlag, 1974).
  28. Crocker, Richard L., The Early Medieval Sequence, (Berkeley: University of California, 1977).
  29. De Roover, Florence Edler, "The Scriptorium," in Thompson, Medieval Library, q.v.
  30. DIAMM (Digital Archive of Medieval Music), at http://www.diamm.ac.uk/.
  31. Digital Scriptorium, "The Digital Scriptorium: A Prototype Image Database & Visual Union Catalog Of Medieval And Renaissance Manuscripts," at http://sunsite.berkeley.edu/scriptorium/.
  32. Doneda , Annalisa, "Computer Applications to Byzantine Chant," Cantus Planus, Papers Read at the 10th Meeting, Visegrád Hungary 2000, (forthcoming), at http://scribe.fas.harvard.edu/medieval/Doneda.htm.
  33. Drogin, Marc, Medieval Calligraphy: Its History and Technique, (New York: Dover, 1980).
  34. "DScriptorium," at http://www.byu.edu/~hurlbut/dscriptorium/.
  35. Duguid, Paul, "Report of the Santa Fe Planning Workshop on Distributed Knowledge Work Environments: Digital Libraries; March 9-11, 1997," at http://www.si.umich.edu/SantaFe/cover.html.
  36. EAMMS (Electronic Access to Medieval Manuscripts), at http://www.hmml.org/eamms/index.html.
  37. Early Manuscripts at Oxford University, at http://image.ox.ac.uk/.
  38. Einhard, Vita Karoli Magni imperatoris, Samuel Turner, tr., (Ann Arbor: University of Michigan, 1964).
  39. Fassler, Margot, Gothic Song: Victorine Sequences and Augustinian Reform in Twelfth-Century Paris, (Cambridge, England: Cambridge University, 1993).
  40. Foley, Edward, Foundations of Christian Music: The Music of Pre-Constantinian Christianity, (Nottingham, England: Grove, 1992).
  41. Forgy, Charles L., CLIPS/R2, (Pittsburgh: Production Systems Technologies, 1996).
  42. Gonzalez, Avelino J., and Douglas D. Dankel, The Engineering of Knowledge-Based Systems: Theory and Practice, (Englewood Cliffs: Prentice Hall, 1993).
  43. Good, Michael, "Using XML for Musical Representation," at http://www.recordare.com/stanford.html.
  44. "Gregorian Chant Home Page on the World Wide Web, The," at http://www.music.princeton.edu:80/chant_html/.
  45. "Gregorian Chant Notation" at http://www.netaxs.com/~rmk/Chant/.
  46. Grier, James, "Neume," in J. Strayer, ed., Dictionary of the Middle Ages, (New York: Scribner's, 1987).
  47. Grout, Donald Jay, A History of Western Music, (New York: W. W. Norton, 1980).
  48. Haas, Max Otto, Mundliche Uberlieferung und altromischer Choral; historische und analytische computergestutzte Untersuchungen, (1997).
  49. ––––––, "Über einige Möglichkeiten der computergestützten Erforschung liturgischer einstimmigkeit," Festschrift M. Lütolf.
  50. Hayburn, Robert F., Papal Legislation on Sacred Music, 95 A.D. to 1977 A.D., (Collegeville, MN: Liturgical Press, 1979).
  51. Hoppin, Richard H., Medieval Music, (New York: W. W. Norton, 1978).
  52. Hucke, Helmut, "Toward a New Historical View of Gregorian Chant," Journal of the American Musicological Society, vol. XXXIII, no. 3 (Fall, 1980).
  53. Hughes, Andrew, Late Medieval Liturgical Offices; Resources for Electronic Research, (Toronto: Pontifical Institute of Mediaeval Studies, 1996).
  54. ––––––, Style and Symbol; Medieval Music: 800-1453, (Ottawa: Institute of Mediaeval Music, 1989).
  55. "Information processing -- Hypermedia/Time-based Structuring Language (HyTime) - 2d edition," ISO/IEC JTC 1/SC 18 WG8 N1920rev, at ftp://ftp.ornl.gov/pub/sgml/wg8/document/n1920/index.htm.
  56. Jeffery, Peter, Re-Envisioning Past Musical Cultures: Ethnomusicology in the Study of Gregorian Chant, (Chicago: University of Chicago, 1992).
  57. Kelly, Thomas Forrest, The Beneventan Chant, (Cambridge, England: Cambridge University, 1989).
  58. Khare, Rohit, and Adam Rifkin, "Capturing the State of Distributed Systems with XML," at http://www.xml.com/pub/w3j/s3.khare.html.
  59. King, James C., tr., and Werner Vogler, ed., The Culture of the Abbey of St. Gall; An Overview, (Stuttgart: Belser Verlag, 1991).
  60. Lee, Richard, "Chant Links," at http://comp.uark.edu/~rlee/otherchant.html/.
  61. Lesser, George, Gothic Cathedrals and Sacred Geometry, (London: Alec Tiranti, 1957).
  62. Levy, Kenneth, "On Gregorian Orality," Journal of the American Musicological Society, vol. XLIII, no. 2 (Summer 1990).
  63. Liber Usualis, Benedictines of Solesmes, ed., (Tournai, Belgium: Desclée, 1934).
  64. Marenbon, John, From the Circle of Alcuin to the School of Auxerre; Logic, Theology and Philosophy in the Early Middle Ages, (Cambridge, England: Cambridge University, 1981).
  65. "MASTER: Manuscript Access through Standards for Electronic Records," at http://www.cta.dmu.ac.uk/projects/master/.
  66. McGee, William, and Paul Merkley, "The Optical Scanning of Medieval Music," Computers and the Humanities, vol.25, no. 1 (1991).
  67. McKinnon, James W., ed., Music in early Christian literature, (Cambridge, England: Cambridge University, 1987).
  68. ––––––, "On the Question of Psalmody in the Ancient Synagogue," Early Music History, vol. 6 (1986).
  69. "Medieval manuscripts," at http://image.ox.ac.uk/pages/medcanon.htm.
  70. Medin, Douglas, and Andrew Ortony, "Psychological essentialism," Stella Vosniadou and Andrew Ortony, eds., Similarity and Analogical Reasoning, (Cambridge, England: Cambridge University, 1989).
  71. Mounce, Steve R., "NIFF Page: Notation Interchange File Format," at http://www.student.brad.ac.uk/srmounce/niff.html.
  72. ––––––, "SMDL Page: Standard Music Description Language," at http://www.student.brad.ac.uk/srmounce/smdl.html.
  73. Nettl, Bruno, "Historical Aspects of Ethnomusicology," American Anthropologist, no. 60 (1958).
  74. "Neume," in Don Michael Randel, ed., The New Harvard Dictionary of Music, (Cambridge, MA: Harvard University, 1986).
  75. "NIFF Notation File Standard," at http://www.musitek.com/niff.html.
  76. Oxford Chant Group, at http://www.music.ox.ac.uk/oxchant/.
  77. Panofsky, Erwin, Gothic Architecture and Scholasticism, (New York: Meridian; New World, 1957).
  78. Pearson, Lionel, Aristoxenus: Elementa Rhythmica, (Oxford: Clarendon, 1990).
  79. Piéchaud, Robert, "Medieval™ - A Finale plug-in," at http://www.klemm-music.de/medieval/index_e.htm.
  80. Powers, Harold S., "Mode," in Sadie, New Grove Dictionary, q.v.
  81. Roland, Perry, "Proposal for Encoding Western Music Symbols in ISO/IEC 10646," at http://www.lib.virginia.edu/dmmc/Music/UnicodeMusic/.
  82. Sachs, Curt, The Wellsprings of Music, (The Hague: Martinus Nijhoff, 1962).
  83. Sadie, Stanley, ed., The New Grove Dictionary of Music and Musicians, (London: Macmillan, 1980).
  84. Saint Meinrad Archabbey, "St. Meinrad Fonts," at http://www.saintmeinrad.edu/abbey/.
  85. Scholz, Bernard Walter, tr., Carolingian Chronicles; Royal Frankish Annals and Nithard's Histories, (Ann Arbor: University of Michigan, 1970).
  86. Seay, Albert, Music in the Medieval World, (Englewood Cliffs, NJ: Prentice-Hall, 1965).
  87. Selfridge-Field, Eleanor, ed., Beyond MIDI; The Handbook of Musical Codes, (Cambridge, MA: MIT, 1997).
  88. Sendrey, Alfred, Music in Ancient Israel, (New York: Philosophical Library, 1969).
  89. ––––––, Music in Social and Religious Life of Antiquity, (Rutherford, NJ: Fairleigh Dickenson University, 1974).
  90. Smith, Hermann, The World's Earliest Music: Traced to its Beginnings in Ancient Lands, (London: W. Reeves, no date).
  91. Smith, J. A., "The Ancient Synagogue, the Earliest Church and Singing," Music & Letters, vol 65, no. 1 (Jan. 1984).
  92. Solesmes, Monks of, The Musical Notation of Latin Liturgical Chants, (Sablé-sur-Sarthe, France: Abbaye Saint-Pierre de Solesmes, 1991).
  93. ––––––, Offertoriale triplex cum uersiculis, (Sablé-sur-Sarthe, France: Abbaye Saint-Pierre de Solesmes, 1985).
  94. ––––––, Paléographie musicale, (Sablé-sur-Sarthe, France: Abbaye Saint-Pierre de Solesmes, 1889-).
  95. Spiess, Lincoln Bunce, Historical Musicology; A Reference Manual for Research in Music, (New York: Institute of Mediaeval Music, 1963).
  96. Spencer, Jon Michael, Theological Music; Introduction to Theomusicology, (New York: Greenwood, 1991).
  97. Stäblein, Bruno, Schriftbild der Einstimmigen Musik, (Leipzig: Deutscher Verlag für Musik, VEB, 1975).
  98. Steiner, Ruth, "Gregorian and Old Roman chant," in Sadie, New Grove Dictionary, q.v.
  99. Strunk, Oliver, ed., Source Readings in Music History: Antiquity and the Middle Ages, (New York: W. W. Norton, 1965).
  100. Taliaferro, Robert Catesby, tr., St. Augustine on Music: Books I - VI, (Annapolis, St. John's Bookstore, 1939).
  101. Tauber, James K., "NIFF Documentation," at http://www.jtauber.com/music/encoding/niff.
  102. "TEI: The Text Encoding Initiative," at http://www.tei-c.org/.
  103. "Text Encoding Initiative," at http://www.uic.edu/orgs/tei/.
  104. Thompson, James Westfall, ed., The Medieval Library, (Chicago: University of Chicago, 1939).
  105. Treitler, Leo, "The Early History of Music Writing in the West," Journal of the American Musicological Society, vol. XXXV, no. 2 (Summer 1982).
  106. ––––––, "Homer and Gregory: The Transmission of Epic Poetry and Plainchant," The Musical Quarterly, vol. LX, no. 3 (July 1974).
  107. ––––––, "Medieval Improvisation," The World of Music, vol. 33 (1991).
  108. ––––––, "Reading and Singing: On the Genesis of Occidental Music-Writing," Early Music History, vol. 4 (1984).
  109. ––––––, "The 'Unwritten' and 'Written Transmission' of Medieval Chant and the Start-up of Musical Notation," The Journal of Musicology, vol. X, no. 2 (Spring 1992).
  110. Unicode Consortium, The Unicode Standard Version 3.0, (Reading MA: Addison-Wesley, 2000); on-line, "The Unicode Standard (ISO/IEC 10646)," at http://www.unicode.org.
  111. Velimirovic, Milos, and Mireille Helffer, "Neumatic Notations," in Sadie, New Grove Dictionary, q.v.
  112. W3C, "Extensible Markup Language (XML) 1.0; W3C Recommendation 10-February-1998," at http://www.w3.org/TR/REC-xml.
  113. W3C Unicode, "Unicode in XML and other Markup Languages; Proposed DRAFT Unicode Technical Report #20; W3C Working Draft 28-September-1999," at http://www.w3.org/TR/unicode-xml/.
  114. Wallach, L., Alcuin and Charlemagne: Studies in Carolingian History and Literature, (Ithaca: 1949).
  115. Wellesz, Egon, A History of Byzantine Music and Hymnography, (Oxford: Clarendon Press; Oxford University, 1949).
  116. Winnington-Ingram, R. P., "Greece," in Sadie, New Grove Dictionary, q.v.
  117. World Wide Web Consortium (W3C), Unicode Technical Committee, "Extensible Markup Language," at http://www.w3.org/TR/REC-xml.
  118. Wright, Craig M., Music and Ceremony at Notre Dame of Paris, 500-1550, (Cambridge, England: Cambridge University, 1989).
    119.
Top of document





Revision: 30 September 2001
Copyright © 2000, 2001, Louis W. G. Barton