Facsimiles of Text and Music from Distributed Resources
1. Facsimiles of Text and Music
From Distributed Resources
Benjamin Albritton
blalbrit@stanford.edu
Scholarly Editions and the Digital Age: Text and Music
31 August 2012, Bloomington, IN
2. Overview
• Brief context of current medieval manuscript
interoperability work
• Andrew W. Mellon Foundation
• Stanford and partners
• What do we mean by “interoperability”?
3. The Problem
• Medieval projects as “curated and
comprehensive” efforts
• Technical and social silos
• Expensive to maintain
• Difficult to extend
4. The Goal
• Toward a “commons” of distributed resources
• Aggregating information and extensibility as
an alternate to “curated and comprehensive”
• Allow people to do cool new stuff with our
stuff (without losing our relevance)
5. Text Repositories
• Long history
• Deep inventory
• Domain-specific (often)
• Some images
• Static Interface
• …
6. Image Repositories
• A “standard model”
• Lots of images
• Descriptive metadata
• Silo interfaces
• Built-in tools
• No way to access
outside “stuff” for
comparison
• Mediates use
• Expensive to maintain
7. Repository to Repository
Parker: CCCC 410 – De speculatione musice
• One-off sharing
• Human-brokered
• But:
• Expense
• Not scalable
• What if:
• CHMTL wants
images for all MSS
of its texts?
• Parker wants texts
for all its music
theory?
• BNF wants… ? CHMTL: 1970, Corpus scriptorum text
of De speculatione musice
8. But what about…
• Other resources
“about” an object
or text
• … stored and
served in other
places
• … that you might
not know about
• How to build
extensible
facsimiles?
9. “Interoperability”
• Step 1: Expose resources to
shared tools
• Step 2: Enhance resources
• Match text to image
• Match image to text
• Exposure is low cost
• Shared tools let other people
make your stuff better
• Specialists build the domain-
specific tools
12. Digital Facsimiles from
Distributed Resources
• Parker image served from Stanford
• Text provided by CHMTL
• Linkage produced in T-PEN
• Data for text re-stored at Los Alamos National
Lab
• Re-presented in a new environment that also
allows presentation of even more annotations
and links
15. Naïve Approach: Attach Transcription to Image
One problem example: Multiple Representations
CCC 26 f. iiiR
16. Naïve Approach: Attach Transcription to Image
One problem example: Multiple Representations
CCC 26 f. iiiR Fold A Open
17. Naïve Approach: Attach Transcription to Image
One problem example: Multiple Representations
CCC 26 f. iiiR Fold A Open Fold A and B Open
18. Naïve Approach: Attach Transcription to Image
One problem example: Multiple Representations
CCC 26 f. iiiR Fold A Open Fold A and B Open f. iiiV
19. The Shared Canvas
• Represents a real world thing we
want to “talk” about
• Has a unique name
• http://dms-data.stanford.edu/Parker/CCC026/canvas-12
25. Examples of other resources attached
to the facsimile:
• Detail images overlaid
26. Examples of other resources attached
to the facsimile:
• User-generated
comments (public
and private)
• Audio
performances of
notated music
• Overlaid text
transcription
• Also:
• Data sets
• Mark-up
• Base image
choices
27. Conclusion
• Distributed resources exist independently of the
aggregation – could be re-presented in any UI
• In short:
– Expose repository and project data via API and
common data models
– Leads to:
• Greater use of repository resources
• Sustainability
• Enhanced repository data
• Cool new uses of the data we’ve already produced
28. Thank You
• More Info:
– Benjamin Albritton, Stanford University Libraries
• blalbrit@stanford.edu
– CHMTL & Dr. Giuliano Di Bacco, Indiana University
• http://www.chmtl.indiana.edu/
– SharedCanvas
• Author and architect: Robert Sanderson, Los Alamos National Lab
– azaroth42@gmail.com
• Description and implementations:
– www.shared-canvas.org
– T-PEN
• PI: James Ginther (coming up next), Saint Louis University
• Try it!
– http://t-pen.org/TPEN
– Slides (within a week)
• http://www.stanford.edu/group/dmstech/
Editor's Notes
Can’t acquire each new resource through human interactions
, repositories provide the “killer carrot” not the “killer app”
New information for existing resourcesLine locations on image, line breaks in text
