[MEI-L] Notation type

Wed Sep 21 15:29:01 CEST 2011

Thanks, Peter, it's great to have some perspective from how TEI addressed these issues.

Just a quick note to clarify two things:

1. This would be for more than just manuscript works. There are many printed books (guitar, especially) where it will have both the CMN and tablature but certainly cannot be attributed to a particular hand or script.

2. It would extend to more than just complete changes in notation. You might, for example, be doing a measure-by-measure transcription of a book for singer and lute where the top staff is in mensural notation, and the bottom in tablature. I would think you would want the ability to say "this staff is in mensural, and this staff is in tablature" for every measure.

I do agree with you that this is a non-bibliographic feature of the source.

On 2011-09-21, at 7:37 AM, Peter Stadler wrote:

> Dear all,
> 
> some comments to the discussion:
> 1. I disagree with Raffaele that the tei:msDesc is a good example ;-) Roughly, I'd prefer to put information about the notation type (somewhere) into profileDesc rather than sourceDesc. In my opinion it's not necessarily part of "a bibliographic description of a source" but belongs to the "non-bibliographic aspects". E.g. in Bach's autograph BWV 998 he switches (due to lack of space) from standard piano notation to keyboard tablature (I found an image at http://imageshack.us/photo/my-images/53/998p4allegroiw6.gif/). The point I'm trying to make is that the change of notation is (or at least can be) a textual rather than a bibliographic feature.
> 2. As a textual feature it will not nest properly with other features so it'd be good to have appropriate milesteone elements to deal with these shifts (well, maybe handshift suffices?)
> 3. TEI differentiates between "script" (only applicable in msDesc) and "scribe" (aka "hand") which is available within msDesc and profileDesc/handNotes. As far as I can tell from the online MEI schema at music-encoding.org the mei:handlist is only available within source/physdesc. Maybe the TEI distinction between script as a bibliographic feature and scribe as a textual feature isn't that bad and can be ported to MEI?
> 
> All the best
> Peter
> 
> 
> Am 21.09.2011 um 02:40 schrieb Andrew Hankinson, Mr:
> 
>> Perry,
>> 
>> This can certainly be an ongoing discussion -- no need to rush it into this year's release. I would like to get a sense of direction, though, as I encountered this problem when trying to put together some proposals for the neumes module.
>> 
>> Just to make sure I'm understanding you correctly, you're suggesting (e.g.,):
>> 
>> =====
>> <sourceDesc>
>> <source xml:id="S1">
>> 	<classification>
>>  	    <termList>
>> 		<term xml:id="foo">Mensural</term>
>> 		<term xml:id="bar">CMN</term>
>> 		... other possible (non-notational) terms ...
>>           </termList>
>> 	</classification>
>> </source>
>> </sourceDesc>
>> ...
>> <music>
>>  ...
>>  <section decls="foo">
>>     ... mensural things ...
>>  </section>
>>  <section decls="bar">
>>     ... cmn things ...
>>  </section>
>>  ...
>> </music>
>> =====
>> 
>> <classification /> seems to apply largely to *bibliographic* classification (it has attributes defined in att.bibl.attributes, for example). I see that as different than a functional label describing the type of notation being used in a section. "Metadata" vs. "data".
>> 
>> In the above example (if I'm characterizing it correctly), we identify this source document as belonging to both the "Mensural" and "CMN" document groups, but it seems like a bit of a stretch to also use that bibliographic grouping mechanism to identify the specific sections of the encoding for the reasons of parsing or rendering (human or automated).
>> 
>> Without an explicit notation description, are we assuming a "default" system of encoding? I.e., if we don't explicitly declare the notation type, is the only way to identify it by a) looking at the elements used and inferring it or b) having access to the modules that make the encoding valid? And if we can't tell, does it default to CMN? Or gamelan[1]? Or shakuhachi[2]? Or...? :)
>> 
>> -Andrew
>> 
>> 1. http://homepages.cae.wisc.edu/~jjordan/gamelan/notation.html
>> 2. http://www.rileylee.net/shaku_notation.html
>> 
>> 
>> On 2011-09-20, at 1:26 PM, Roland, Perry (pdr4h) wrote:
>> 
>>> Andrew,
>>> 
>>> It's true that there's no controlled vocabulary for notation types, but uncontrolled terms are permitted within <classification> so I don't see how <notationDesc> (where I presume the value of notationFamily/@name is uncontrolled) is a huge improvement over <classification>, especially since the kind of data element -> metadata linking that you suggest is already available via the decls attribute (which is available on 26 elements, among them music, section, staff, and layer).
>>> 
>>> <classification> does occur in the header, but it doesn't apply to the whole file.  It applies to its <source>, <relatedItem>, or <work> parent.  (N.B. Once upon a time, it existed within <fileDesc> as well and we could put it back there if classification of the file itself is necessary.)
>>> 
>>> The advantage of the <notationDesc> approach is that perhaps it can provide a natural language description of the notation as opposed to <classification> which is more of a thesaurus/ontology.  Still, I'm concerned that <notationDesc> provides a second place to put a specific kind (classification?) of classification information, leading users to question when/how to use it as opposed to <classification>.
>>> 
>>> Also, is this a change you'd like to see in the next release or can we postpone this discussion 'til later?
>>> 
>>> --
>>> p.
>>> 
>>> __________________________
>>> Perry Roland
>>> Music Library
>>> University of Virginia
>>> P. O. Box 400175
>>> Charlottesville, VA 22904
>>> 434-982-2702 (w)
>>> pdr4h (at) virginia (dot) edu
>>> ________________________________________
>>> From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson, Mr [andrew.hankinson at mail.mcgill.ca]
>>> Sent: Tuesday, September 20, 2011 11:17 AM
>>> To: Music Encoding Initiative
>>> Subject: Re: [MEI-L] Notation type
>>> 
>>> Thanks, Perry.
>>> 
>>> I looked at classification, but as you rightly point out there is no controlled vocabulary for notation types. I'm not interested in trying to create a controlled vocabulary for notation types, since that really does seem like a way to get nowhere, fast. <classification /> is also global (being in the header), and affects the whole file. If I were encoding both mensural and CMN in the same file (e.g., the tradition of including the original notation as an incipit in a modern edition), then simply noting what modules were used or capturing some sort of information in <classification /> would not be specific enough. The only indication that I was in mensural notation would have to be drawn from the use of mensural durations on the notes (breve, semibreve, etc.) or other elements specific to this notation. To do this automatically would require the computer to try and infer what was going on, and we all know how good a machine's inferences are…
>>> 
>>> I'm not too sure that there's an equivalent problem in the text world. Various parallels could be drawn to language, script style or hand, all of which are in TEI in some form or another. I think that perhaps the most direct parallel (although still imperfect) would be language, and I would be shocked to find out that TEI doesn't allow you to capture which language was being used at any given point in the document.
>>> 
>>> Perhaps the term "notation family" would be more appropriate. For neumed notation there are different sub-types (sangallan, aquitanian, hufnagel, etc.) that would all fall under the "neume" family. Likewise in mensural there is "white" and "black" notation.
>>> 
>>> My suggestion would be to add a <notationDesc /> section and allow pointers to it from <section />, <score />, or <music />, e.g.,
>>> 
>>> ============
>>> <notationDesc>
>>> <notationFamily xml:id="foo" name="mensural" />
>>> <notationFamily xml:id="bar" name="cmn" />
>>> </notationDesc>
>>> ...
>>> <music notationfamily="bar">
>>> ...
>>> <section notationfamily="foo">
>>>      ...
>>> </section>
>>> ...
>>> </music>
>>> ============
>>> 
>>> <notationFamily /> could then have child elements to describe characteristics of the notation itself (for neumes, the specific sub-type, heighted/unheighted, etc.)
>>> 
>>> -Andrew
>>> 
>>> On 2011-09-20, at 9:12 AM, Roland, Perry (pdr4h) wrote:
>>> 
>>>> Hi Andrew,
>>>> 
>>>> Your assessment is correct -- there's currently no dedicated way of recording the kind of notation or modules in use.
>>>> 
>>>> I've always thought this was a classification issue; that is, that one could use <classification> to hold an indication of the file's qualities not otherwise carried in the markup, including the notational type.  This isn't all that much different from saying this file is a motet or a symphony using <classification>.  What's required, of course, is agreement on standard labels for the various kinds of notation.  But there are lots of different types and sub-types of notation, and I fear that trying to reach agreement on their names and content will lead nowhere very quickly.
>>>> 
>>>> Perhaps we can avoid this problem by documenting which modules were used in this particular instance.  This is relatively easy to add, say, in the MEI header.  But how far do we go?  For instance, what if I've modified the mensural module, removing some existing elements and adding some new ones?  Can/should I still claim that I'm using the mensural module or even that the markup is "mensural notation" since I've changed the definition of "mensural"?  Must I document my ODD customization in the MEI header?  Isn't this redundant if the customized ODD itself is provided?  In fact, isn't any documentation of the syntax of the schema in the document instance redundant?
>>>> 
>>>> You see, when we start down this path, it gets rocky pretty quickly.  So, I chose to avoid it with the generic <classification> approach, but if reasonable arguments can be made for adding a more specific method, then I'm not opposed.
>>>> 
>>>> By the way, I don't think there's anything like this in TEI, so I wonder what the reasons were for not including something like this there.  Can anyone enlighten me?
>>>> 
>>>> Regards,
>>>> 
>>>> --
>>>> p.
>>>> 
>>>> __________________________
>>>> Perry Roland
>>>> Music Library
>>>> University of Virginia
>>>> P. O. Box 400175
>>>> Charlottesville, VA 22904
>>>> 434-982-2702 (w)
>>>> pdr4h (at) virginia (dot) edu
>>>> ________________________________________
>>>> From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson, Mr [andrew.hankinson at mail.mcgill.ca]
>>>> Sent: Tuesday, September 20, 2011 1:05 AM
>>>> To: Music Encoding Initiative
>>>> Subject: [MEI-L] Notation type
>>>> 
>>>> Hi all,
>>>> 
>>>> I've been looking through the documentation and I cannot seem to find a method (element or attribute) for specifying the type of notation being encoded.
>>>> 
>>>> We have modules for mensural, tablature, neumes, etc., but once the schema is constructed from these modules there seems to be no way of specifying the type of notation used. It seems that the type of notation can only be derived implicitly by looking at the elements and attributes present in the encoding.
>>>> 
>>>> There is the "@type" attribute on some possible candidate elements (<score />, for example), but that seems like it's meant to be generic and can be used for just about anything.
>>>> 
>>>> This seems like it should be possible, but I can't find it. Have I missed something?
>>>> 
>>>> Thanks,
>>>> -Andrew
>>>> _______________________________________________
>>>> mei-l mailing list
>>>> mei-l at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>> _______________________________________________
>>>> mei-l mailing list
>>>> mei-l at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>> 
>>> 
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>> 
>> 
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l