[tei-council] notated music

[Laurent Romary]

Hi council,
I'm taking up on this thread to basically come to a similar conclusion as James. We have a duty to move forward with the creation of this element, probably letting the discussion of a more generic element to another ticket.
I also like the status='reviewed' (even more explicit than 'unstable', which is somehow frightening to read).
So:
- I suggest to have show of hands on this proposal
- expect a volunteer to file in a ticket for a more generic option
Laurent

Le 5 juil. 2011 à 11:10, James Cummings a écrit :

> 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
> _______________________________________________
> 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

Laurent Romary
INRIA & HUB-IDSL
laurent.romary at inria.fr