[tei-council] <notatedMusic> changes required

[Martin Mueller]

Dear Raffaele,

This is very helpful, and I think I now understand what is going on.
Putting it in my words you are saying that both writing and musical
notation are symbolic systems. When you have them in the same digital
document you want them both 'transcribed' and machine actionable. Just as
the encoding of a text is algorithmically manipulable in  ways in which
the page image is not (at least not qua text), so you want the musical
bits to be algorithmically amenable.

The encoding of the musical bits may, but need not, come from within the
XML universe. That complicates the choice of the pointer mechanism that
fetches the musical bits.

Do I get this right?




On 7/10/11 7:56 AM, "Raffaele Viglianti" <raffaele.viglianti at kcl.ac.uk>
wrote:

>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
>
>_______________________________________________
>tei-council mailing list
>tei-council at lists.village.Virginia.EDU
>http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>PLEASE NOTE: postings to this list are publicly archived