[MEI-L] Notation type

Raffaele Viglianti raffaeleviglianti at gmail.com
Wed Sep 21 15:51:52 CEST 2011 

Hello,

I think that what is good--and can be generalized to non-manuscript
documents-- in msDesc, is that the header is used a descriptor of all
possible scripts (and this is, I think, a bibliographical description). Once
that is done, it is possible to specify at any level in the text which of
the script styles are in used now.

My point wanted to be that by generalizing this idea to MEI (which has
already been done with several other (non-)bibliographical aspects), it
would be nice to have in the header a place where to define/describe all the
type of notation styles present in the document (regardless of its source;
ms, print, born digital) and be able to specify within the document which
style is in use at what point.

Best,
Raffaele

On Wed, Sep 21, 2011 at 2:29 PM, Andrew Hankinson, Mr <
andrew.hankinson at mail.mcgill.ca> wrote:

> 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
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110921/569b354e/attachment.html>

More information about the mei-l mailing list