An important goal of this project during its first year is to improve and expand the collection of beta-test transcriptions of chant source documents to NEUMES /NeumesXML. This is needed for establishing a 'test suite' of data, against which the data representation and applications programs can be validated. The domain of application (i.e., emergent writing systems for musical notation, covering some millions of Western- and Eastern-European chant documents, and spanning an historical period of 800 years or more) is enormously complex; there are dozens of early systems of musical notation to consider and a seemingly endless array of idiosyncracies, special cases, and conflicting requirements of the individual manuscripts.

Inevitably, this project's software-development process must remain flexible: we must frequently re-evaluate the technical difficulties, priorities, and cost/benefit ratios in allocating financial and labor resources to these problems. In particular, we expect that a comprehensive and stable NEUMES data representation will not be realistically achievable until after some years of field-trials and actual use by professional musicologists. Our response to this situation involves, basically, four tactical solutions, as follows.
  1. NEUMES transcription data are written in a system of mnemonic codes (such as, '&punctum;' instead of the hexadecimal value E0A5). XML parsers convert these mnemonics into their corresponding hexadecimal values as an immediate, first step in processing NeumesXML transcription files. (They do this by table-lookup against the file NEUMES_characters.pen.) One benefit of mnemonics is that transcriptions are more 'human readable'. A more important purpose, however, is that they introduce a layer of 'indirection' between transcription data and processes that use those data. If mnemonic codes are referenced instead of NEUMES codepoints, then the data representation can evolve in parallel with software development: the impact of data-representation changes on programs, and on existing transcriptions, will be mitigated.
  2. Initially, we intentionally are limiting the transcriptions we make to a rather small number. Until we are satisfied that the major cases in notation are being successfully handled by NEUMES and NeumesXML, it would be a financial- and time-burden to maintain a large number of transcriptions. A regrettable side-effect of limiting the number of transcriptions is that the project cannot yet serve as a resource for productive work in musicology.
  3. Despite the added expense and effort involved, we need to redesign the existing applications software (and constrain the designs of new applications software) to be data-driven. This means that the data structures and other source code relating to the content of the domain of application must be generated dynamically from the structure and data of this content. For example, the data-entry program should be redesigned so that the menus of neumatic symbols will be generated automatically from the NeumesXML Schema, the NEUMES character taxonomy, and the glyph image set for each type of notation, instead of being hard-coded in the data-entry program as is currently the case. (The dynamic generation of menus, etc., could be done at runtime. Likely, however, it will be more practical to implement this via a Java Servlet that would create new class files for the data-entry Applet; these class files would be automatically delivered to the client when the Applet is next retrieved via Java Web Start.) By making applications software data-driven, the data representation can evolve without incurring major expense in maintenance of applications software.
  4. An 'abstraction barrier' is needed that will separate Java applications software from the data representation; for this, a collection of Java classes should be created for commonly-needed functions in doing 'low-level' access or modification of transcription data. By having predictable and stable 'signatures' of these classes (i.e., an API, or applications programming interface), the applications programs should be minimally impacted by changes in NEUMES and NeumesXML. Many such changes would then affect just the implementation (viz., the hidden, internal details) of the 'abstraction barrier' classes.
As of the date of this writing, the Eduserv-funded project has realized the following expansions and additions to our 'test suite' of transcriptions and notation capabilities:
  • 1 transcription that was previously incomplete has been completed and 'migrated' to the current data format;
  • 5 new transcriptions of chant sources have been added;
  • 1 notation family that previously was defective in its visualization has undergone major improvement; and
  • 2 new notation families have been accommodated for visualization.
Currently, we have a total of 8 transcriptions, and the software supports 6 notation families. These numbers, however, account just for what has been delivered by our transcription personnel. Due to the related changes that must be implemented (in the visualization program, the NEUMES taxonomy, glyph image sets, etc.), there is some lag time in actually getting these transcriptions online.

Due the effort and expense that would be involved in maintaining redundant capability on two websites, the transcriptions are available for viewing only from the main NEUMES website. Click this link to open that page directly from here. Please note: JavaScript and HTML Frames must be enabled in your web browser in order to view the transcriptions.


Copyright © 2005 by the University of Oxford.
Contains software or other intellectual property protected by one or more of the following copyrights.

Copyright © 2003-2005 by Louis W.G. Barton.
Copyright © 2002-2003 by The President and Fellows of Harvard College.
Copyright © 1995-2001 by Louis W.G. Barton.
All rights reserved. The copyright holders provide this intellectual property online as reference material for educational, cultural, and charitable purposes. The material is provided "as is" without any warranty whatsoever.