[tei-council] Fwd: Re: Fwd: Re: tei:notatedMusic

Sun Jun 19 19:45:49 EDT 2011

Comments from Raffaele

-James

-------- Original Message --------
Subject: Re: [tei-council] Fwd: Re: tei:notatedMusic
Date: Mon, 20 Jun 2011 00:40:40 +0100
From: Raffaele Viglianti <raffaele.viglianti at kcl.ac.uk>
To: James Cummings <james.cummings at oucs.ox.ac.uk>

Hi James,

These are my comments, if you want to forward them. Thanks!

Raffaele

On 19/06/11 15:16, Sebastian Rahtz wrote:
> In general, I am in favour, but I have some concerns, sharpened by
> hearing Raffaele explain this and discussing it with James.

It's quite possible that the fact that I had been up for 24hours
straight when we had that conversation made me less clear than what I'd
wanted to be :)

> Firstly, it seems clear to me that this<music>  (for short) element
> is very comparable to<formula>, and so i'd like to make sure they are
> aligned. That means I worry about it being in model.global alongside
> milestone elements and suchlike trash. I'd rather it was in
> model.graphicLike - and if that needs adjusting so be it.

I think it's closer to figure than formula. The thing is that, as far as
I can tell, one can encounter music notation at all levels.
At phrase level: e.g. a rhythmic pattern with few music symbols in a
sentence. See http://www.tei-c.org/SIG/Music/twm/index.html#twm05.2-inline
At paragraph level: e.g. music notation between paragraphs in a manuscript
At a division level: e.g. examples of music notation between chapters,
or articles in a journal (think of those books that put all figures - or
music notation examples if it's the right kind of literature) in a
section of the book printed on heavier paper.
At other levels in text such as an opening or closing of a letter, a
front matter, etc. For these last examples see:
http://www.tei-c.org/SIG/Music/twm/index.html#twm05.3-block
In "metadata fields", i.e. in descriptive prose in msDesc (?).

Surely other examples can be found.

> Secondly, I wonder about the<desc>. The example gives<desc>First bar
> of Chopin's Scherzo No.3 Op.39</desc>, which looks to me a bit like
> a<head>. Is this<desc>  intended to be a caption, or more like
> a<figDesc>? would one normally show it when rendering the doc? what
> is the difference here between a<desc>  and a<label>?

We chose <desc> to avoid creating a new element like musicDesc. Its
purpose would be to describe what the music notation is to a human
reading the code. An application could use it as fallback if any other
representations are missing/not render-able.
When the description is on the source text like a caption or a head,
then we believe that the musicNotation is in fact within a figure.
See a short argument and an example here:
http://www.tei-c.org/SIG/Music/twm/index.html#twm05.3.1-infigures

> Thirdly, I'd like to generalize the idea of a group of elements which
> are different ways of expressing the same content. The same model
> could be used for math, and for video, and for normal graphics.
> Therefore I wonder if we can name the general concept, and be clear
> that<notatedMusic>  is just syntactic sugar for<Thing type="music">.

This makes a lot of sense, especially if it is useful to avoid your
following example:

> Fourthly, the idea of unordered, untyped, bunch of representations
> of the same bit of music (or whatever) is a bit bothersome. I never
> liked that inside<surface>, and this perpetuates it. Raffaele's
> examples seem to belie the underlying idea, using two _separate_
> notatedMusic, and explaining in the desc  in human-reaable words what
> the representation is - I don't see the point of this. I'd insist on
> mimeType.
>
> <notatedMusic> <ptr target="bar1.xml"
> mimeType="application/vnd.recordare.musicxml"/> <desc>First bar of
> Chopin's Scherzo No.3 Op.39. Encoded in
> MusicXML</desc></notatedMusic>
>
> <notatedMusic> <ptr target="bar1.ly"/> <desc>First bar of Chopin's
> Scherzo No.3 Op.39. Encoded in Lilypond</desc></notatedMusic>
>

The proposed meaning for notatedMusic is: "here is some music notation
in the text", as opposed to: "here is a way *to represent* music
notation in the text". So If there is one occurrence of music notation,
only one element should be used. This is why we suggest to have multiple
pointers within the element if one wants to point to different
representations of the same music notation in the text. I agree that
this alternation could be expressed better, so it could be fine to add
that meaning to notatedMusic (like you suggest in your second point) or
to come up with another wrapping element. Having mimetype on ptr would
be ideal, regardless of where the semantics for "these are alternatives" go.

Raffaele

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