[tei-council] notated music

[James Cummings]

On 04/07/11 21:08, Sebastian Rahtz wrote:
> Well, in general I'd agree, but this has been hanging around a long time
> and discommoding the MEI folks. It was discussed at the last
> council meeting, I understand?

In the minutes for the meeting:

"We agreed that an appropriate name for the proposed container 
element would be <notatedMusic> and requested the Music SIG to 
continue their excellent work by providing a preliminary ODD for 
the new element. This is now available in the SVN repository, 
along with a sample ODD embedding it; see further 
http://tei.svn.sourceforge.net/viewvc/tei/trunk/Documents/notatedMusic/ 
)"

http://www.tei-c.org/Activities/Council/Meetings/tcm46.xml#body.1_div.1_div.1_div.4

They provided the ODD within a few hours of being told that we 
approved the element and just wanted them to produce an ODD for 
us to tidy up and include in the Guidelines. While I think us 
quibbling about the definition of that ODD is entirely 
appropriate, I believe that we had in substance agreed to the 
element and were asking them to do some of the work of creating 
the ODD and prose text which we would refine before putting into 
the Guidelines.

Stuart says:
 > My reservation to this is that music is not the only content 
that can
 > appear in text in this manner and by crafting a solution to 
fit music we
 > may be embbedding assumptions about music rather than 
assumptions about
 > text.

Sure, and that is the reason for the proposed general purpose 
container element. notatedMusic is just a special case of this.

 > * graphs in scientific works, which typically have both 
parallel tabular
 > and graphical representation and deep-linking into the systems 
which
 > generated the experimental data.

We have a whole module and chapter for graphs, networks and 
trees. It is woefully underused and I'm sure that there are 
possible revisions to it. But otherwise I'd view graphs as I 
think you mean them as usually expressed as figures. Thus a 
general purpose containing element inside figure would suit this 
use-case perfectly.

 > * maps with embedded locators such as
 > 
https://secure.wikimedia.org/wikipedia/en/wiki/File:EU-United_Kingdom.svg 
which
 > are print-based half-way point between traditional maps and 
google maps.

I'm less sure about the right solution to that (other than 
embedding the SVG) but would suspect it involved figure again.

 > Having said all that, I do support getting a solution to these 
issues.

I think these are all fair points and justifications for the 
general purpose element. I don't think it stops us implementing 
the element as requested and then take feedback from the music 
encoding community and others as to whether any changes are 
necessary.   We have a value for @status on things like 
elementSpec of deprecated, unstable, changed, stable.

I would propose that notatedMusic be created (basically as 
specified) but with a @status of 'unstable' until we create the 
general purpose element which it is a syntatic sugar version. 
The whole point of that value of @status was to stop development 
blockages and instead flag that  "the item is new and still under 
review". (Really it might be good practice to have any new 
elements listed as such for one 6-month iteration if we are 
continuing with biannual releases.)

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford