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.
- 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.
- 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.
- 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.
- 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.
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.
Homepage