OCVE Philadelphia workshop, 26-27 May 2004
Document Contents
Room 201, Jaffe Building, University of Pennsylvania, 34th and Walnut Streets, Philadelphia, 26–27 May 2004
List of participants
Musicological Team
- John Rink (leader)
- Jeffrey Kallberg
- Benjamin Korstvedt
- J. Michael Cooper
Technical Team
- Marilyn Deegan (leader)
- John Bradley
- Tod Olson
- Ichiro Fujinaga
- Perry Roland
- Stephen Downie
- Julia Craig-McFeely
In attendance
- Suzanne Lodato (Andrew W. Mellon Foundation)
- Danae Stefanou
Timetable
Wednesday 26 May
| 12.30pm | Arrival |
| 1.00pm | Presentations by John Rink (30 minutes), Marilyn Deegan (20 minutes), John Bradley (60 minutes), Ichiro Fujinaga (15 minutes), Perry Roland (15 minutes), Stephen Downie (15 minutes) |
| 3.30pm | Break |
| 4.00pm | Presentation of DIAMM by Julia Craig-McFeely (60 minutes) |
| 5.00pm | Brainstorming session: Possibilities, problems and potential solutions? |
| 6.00pm | Dinner |
Thursday 27 May
| 9.00am | Workshop sessions among musicological and technical teams |
| 12.00pm | Lunch |
| 1.00pm | Plenary session: Presentations by musicological and technical teams (John Rink and Marilyn Deegan – rapporteurs) |
| 3.00pm | Final discussion: summary and action points |
| 4.00pm | End |
Workshop Reports
Technical Report
Recommendations from the technical group
Greenstone
We had in-depth discussions of the implementation of Greenstone by the Chicago Early Editions project. This was extremely useful and will be written up at a later date. Greenstone should be investigated alongside some other solutions for delivering CFEO.
Symbolic representation of underlying data
We need:
- a strong underlying symbolic representation of all the works to hold all the information together and to better enable superimposition, juxtaposition, and recombination. With this representation we can create ‘polyglot’ files that can be mixed and matched
- a search mechanism
- a facility to allow users to hear versions of audio performed
The underlying representation is very difficult to achieve accurately. There are a number of possible solutions:
- use automated techniques like Gamera
- create MIDI files
- rekey, though it is very difficult to do this accurately, even with double rekeying (which is why music typesetting is very expensive)
- work with several passes through the material, with Gamera providing the first pass, then proofing, correcting, and markup being done later.
There are also issues to be resolved (in digital musicology generally) about the representation of textual data.
Metadata
- we need strong structural metadata: METS (the Metadata Encoding and Transmission System) is a candidate for this, but some other projects have had some problems with this.
- if we have good markup and encoding (possibly using MEI) then we can create different versions for different purposes.
- if we can solve Chopin music notation, we can solve a lot of other problems.
Tools
- we need to create reusable tools.
- the annotation tool can be used in many different environments/projects.
- we also need to develop a ‘paths’ tool that can take users through preset examples, and that can also allow them to create their own paths.
- we need tools to provide commentaries as well as annotations, and we need to create ‘filters’ so that annotations can be viewed in different ‘layers’.
General Issues
- Who puts in annotations? Are they part of a public forum? A closed shop? Annotation is a ‘strong’ scholarly presence
- Scholarly additions (annotations) will contribute to the creation of ‘dynamic’ editions. How will this operate in terms of the fixity that scholars expect from editions? How will we manage version control?
- How would perfomers use electronic editions/scores? Would this allow them to create personalized editions? Could they integrate a number of editions on a screen? What would they play from? Screen? Printouts?
- Can we integrate editions and published performances and work out what editions were used in certain performances?
- How do we deal with issues of sustainability and longevity? What is the long-term overload of maintenance and preservation of editions? What will happen about moving to other systems?
- We need to have discussions with textual scholars working on electronic scholarly editions about how large complex projects present materials is a layered way?
- We need to do more dissemination and promotion. Conference papers, posters, papers in online journals. DigiNews and Dlib would probably be interested.
- This is likely to be a long, complex and multi-partnered project. Careful thought needs to be given to phasing, and other funders need to be approached.
Musicological Report
Issues discussed
Manipulation / Display
- Superimposition not the main focus of the project, but rather an added benefit. Juxtaposition perhaps a more intuitive tool? Function of bringing up alternative readings as the key advantage of OCVE.
- Large-scale variorum project would need to define what the potential users could be, in order to provide maximum end-user flexibility. Scholarly element necessary, but should operate on different levels (see indexing/navigation)
- Encoding: partial or systematic? Full XML encoding might require unrealistic resources. Need to conceive of project in phases.
- Advances in text encoding and potential uses of MEI. Possible use of an information retrieval programme (e.g. MIR) to effect number comparisons and assist basic comparative function. Once such comparison has yielded results, interpretation could be left to the user.
- Physical Object vs Content (image versus encoded text): theoretical and practical (including copyright-related) implications of dichotomy.
- Synoptic overview function necessary in variorum (especially e.g. in large-scale orchestral compositions)
- Audio component? Possibilities and potential problems. Suggested use of historical recordings in large-scale variorum would require extensive licensing negotiations.
Indexing / Navigation
- Background-level textual concordance: the site should be completely searchable on all parameters, including notational idiosyncracies, and possibly even accounting for variations in ink / paper types.
- Structural bifurcation to enforce distinction between didactic and plain/presentative facets of the variorum. Scholarly pages should be closed, but user participation could be effected in the form of a public open forum.
- Applications needed for notation on part of users: these could be downloadable rather than part of the browser itself. But if no browser is used at all, then downloading is not necessary (e.g. using a central depository)
- Cross-referencing: possibility of adding metadata fields, so that one can look for re-situated material
- Contextual mutability: accounting for the history of a piece in context, e.g. in cases where its appearance in different collection of pieces might signify both philological and musical changes (e.g. Mendelssohn songs).
- Stemmatic filiation: possibility of including a stemma tool, e.g. including flow-charts to guide one’s search.
- Performers’ use of the variorum: possibilities opened by MusicPad. Future uses could include a true “variorum” for performers (making all versions available on screen, each tagged with a different colour and enabling the performer to construct their own full text for performance.
Dissemination
- Evolution of Pilot into large-scale Chopin Variorum Edition: would need to be phased, with each phase carefully delineated. E.g. first phase to develop a set of tools that could be applied to other similar projects, such as a Mendelssohn Variorum Edition.
- Copyright and licensing issues: is encoding “legal”? A library holds license of an image but the variorum is using encoded content. Possible problems in allowing users to construct their own digital library as opposed to marking on online browser.
- Storage issues: agreement with AHDS? Would this extend to maintenance?
- Support and maintenance issues: need to investigate reliable and consistent support mechanisms for when project is no longer covered by external funding bodies.
- Planning for future technological developments and changes will also need to be addressed, not only with regard to storage, but also in terms of readability. E.g. content will need to be easily translatable when XML is no longer used.
General Observations
OCVE seen as a dynamic edition, potentially dismissing the notion of a singular Urtext edition and instead allowing each user to rely on multiple instantiations of a musical text. It can also act as a multi-level platform to be navigated by different types of users, whereby each user could essentially define the flexibility of each subsidiary component according to their need. Such open-endedness is a clear advantage for scholars and performers, but might appear problematic for libraries, unless they are clearly included in the effort; this could be in the form of metadata giving users the location and access details for each source.