[tei-council] <notatedMusic> changes required

Raffaele Viglianti raffaele.viglianti at kcl.ac.uk
Sun Jul 10 08:56:25 EDT 2011


Martin Mueller wrote:
>  Would it be helpful if somebody did some kind of two-column explanation where the left column described in the language of laymen or musicologists what is wanted and the right column gives a technical account of the options that exist?

Dear Martin,

 From a musicological perspective, the problem is rather simple and possibly does not require a full "left" column. I'll try to re-iterate the research question here again, if you would like further clarification we can continue off-list.
Many texts contain snippets of music notation with different degrees of completeness, from the single music symbol, to a rhythmic pattern, to a full score. How this notation is integrated in the text depends on the medium and style/subject of writing. In manuscripts one is more likely to distinguish less between text and music flow (think of the Beethoven letters examples that I sent you), while printed texts will often (but not always) treat notated music as a figure or example.
How do digital representations deal with this music notation in text? The typical way is to include them as images. If anyone encoded a similar text in TEI, they probably used images as well. And here comes the problem. What if:
a) I want to clearly identify that the following "image" is in fact music notation and
b) I want to be able to mine/render/manipulate computationally the notation itself?

These prompted the SIG to come up with an element that would clearly mark the presence of music notation in text and that would allow to refer to an adequate (read: not an image!) digital representation of the music.

This leads me to get technical again and answer Lou's objection to ptr:

Lou Burnard wrote:

>>/  4. Rewrite the exx not to use ptr at all; use XInclude instead//
/>
>I would vote for this

I understand that the ghost of MEI is hovering above this conversation, but it should not in any way lead it. We want an element that is fully agnostic towards the format chosen to represent the music. Which means that it may not be in XML format at all (think Lilypond, Humdrum, and the very many binary formats out there). xinclude is not a desirable option.

Finally, I would reiterate my opinion that the rendering of the pointed digital object shall happen *before* inclusion rather than viceversa. Exactly like with<graphic>, it may even be that no processing is necessary, just embedding of the resource in the target format of the transformation; music formats are varied and supported at different levels.

Thank you very much for this very interesting conversation so far, I'm glad to see that it prompted debate on important issues for TEI in general.

Best wishes,
Raffaele


-- 
Raffaele Viglianti
PhD Candidate and PG Research Assistant
Department of Digital Humanities
King's College London



More information about the tei-council mailing list