Raffaele,

Thanks for the thoughtful reply.
 
I agree with your assessment of the "domain thing".  The contents of <music> will define what the encoder means by using the tag, but my statement on "intent" didn't go far enough.  As you point out, the contents of <music> in this case have to be digital media.  So, <music> will be defined in terms of digital media that represent the various domains -- images for the graphical, audio for the gestural, music notation markup for the logical.

Your suggestion of

element music { (model.glossLike|model.ptrLike|binaryObject|graphic)* }

is ok.  I'd prefer to hear positive arguments for including each of the members of glossLike rather than assumptions that they might be useful somehow, somewhere, someday, but if others insist on their inclusion, so be it.

As you say, we started down the "music" route because a suitable name couldn't be agreed on.  But I still think the name "music" is overly broad.  Is there any chance at all that we could return to the original purpose of marking the presence of *music notation* in the midst of text (which is itself a notation of speech) by naming the new element "notatedMusic"?  <notatedMusic> also works (without an extra containing element) when an XML notation of the notated music (whew!) is included.  I think this is something we could all support, but let me know if I'm in error.

Regards,

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
[log in to unmask]
________________________________________
From: TEI and Music SIG discussion list [[log in to unmask]] On Behalf Of TEI-MUSIC-SIG automatic digest system [[log in to unmask]]
Sent: Wednesday, December 15, 2010 12:07 AM
To: [log in to unmask]
Subject: TEI-MUSIC-SIG Digest - 13 Dec 2010 to 14 Dec 2010 (#2010-16)

There is 1 message totalling 94 lines in this issue.

Topics of the day:

  1. TEI Members Meeting report and a feature request

----------------------------------------------------------------------

Date:    Tue, 14 Dec 2010 13:08:43 +0000
From:    Raffaele Viglianti <[log in to unmask]>
Subject: Re: TEI Members Meeting report and a feature request

Dear Perry and Micheal,

Thanks a lot for your insightful comments. Apologies for replying a bit
late, I enjoyed reading the discussion and I will avoid to reply to
every single point brought out, but I'll focus instead on what I think
are the latest shapes that your thoughts took. Nonetheless, please let
me know if you feel that something has been left behind or lost in
translation.

This new element was originally proposed to deal with music notation
*only*. The idea of generalizing it stemmed from the lack of a good tag
name that wouldn't clash with another unfortunately named TEI element
that describes the type of music notation in a manuscript:
<musicNotation>. It has been made pretty clear by some members of the
TEI council that musicalNotation would not be accepted as a name since
it's too similar to the aforementioned element.

Now, this generalization clearly needs better thinking, since we didn't
spend as much time on it as we did on the original proposal. This brings
us to a more generic and re-occuring problem: what do we mean by "music".
Following Babbitt's idea of music domains, Perry said: "The intent is to
allow the content to define the encoder's concept of "music". " Despite
me wanting to agree with this, I think that the weight of such
definition should not be put upon this <music> element we are tying to
agree on. I think that we should more simply recognize that as music can
exist in different digital media, we need to be able to point to (or
include) them.

This said, I understand why Perry ended up suggesting a model like this
one (I changed labelLike back into glossLike -at least for now):

element music { (model.glossLike|binaryObject|graphic|audio|musNot)* }

Though I think that a generic pointer can still be useful for the
encoders that don't think that their specific representation of music
fits into any of the three categories that the three elements graphic,
audio, musNot impose. So what about:

element music {
(model.glossLike|moldel.ptrLike|binaryObject|graphic|audio|musNot)* }

... but I struggle to want to add more new elements, when we merely want
to mark the presence of music in the text.

So I would suggest this model for now:

element music { (model.glossLike|moldel.ptrLike|binaryObject|graphic)* }

This would allow us to do what this element is mainly designed to do: to
mark the presence of music in the text, to describe it and to point to
any kind of representation. Additionally, the already TEI-available
binaryObject and graphic allow to include and to point to most digital
objects that can be called music.

(Please note that I am assuming that ptrLike will be part of
att.internetMedia at some point. We are backing this request:
<http://sourceforge.net/tracker/?func=detail&aid=3113682&group_id=106328&atid=644065>
)

We might later on start working on an <audio> element in liaison with
other SIGs (i.e. linguistics), which would behave similarly to <graphic>.

Finally, when music notation is included via ODD customization (and bare
in mind that this is a use that is not covered by the element that would
eventually make its way into the TEI guidelines) we might consider
whether it's a good idea to add in the customization itself an extra
wrapper like <musNot> or just embed it directly.

I realize that this solution might not be an answer to all the issues
brought up, but I think it makes good use of what the TEI already
offers, which might help in the process of approving our feature request.

Best,
Raffaele




--

Raffaele Viglianti
PhD candidate and PGRA
Centre for Computing in the Humanities
King's College London

------------------------------

End of TEI-MUSIC-SIG Digest - 13 Dec 2010 to 14 Dec 2010 (#2010-16)
*******************************************************************