From andrew.hankinson at mail.mcgill.ca  Tue Jan  4 16:29:58 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 4 Jan 2011 10:29:58 -0500
Subject: [MEI-L] MEI Website on mobile browsers
Message-ID: <F8ED74B6-BE94-4150-9EA8-FC73315CD27C@mail.mcgill.ca>

Hi all,

I was just trying to look up a reference to a MEI tag on my iPod Touch and noticed that the MEI website doesn't work well with the Mobile Safari browser. The scroll bars on the left and right columns in the tag library pages (and other pages where the content overflows the border container) do not appear, and you can only scroll with two fingers, instead of the usual one-fingered scroll, a technique that is not immediately obvious - I only found this out by Googling the problem.

-Andrew






From kepper at edirom.de  Tue Jan  4 17:52:00 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Tue, 4 Jan 2011 17:52:00 +0100
Subject: [MEI-L] MEI Website on mobile browsers
In-Reply-To: <F8ED74B6-BE94-4150-9EA8-FC73315CD27C@mail.mcgill.ca>
References: <F8ED74B6-BE94-4150-9EA8-FC73315CD27C@mail.mcgill.ca>
Message-ID: <8914D875-9D70-45DA-9938-B62A3C774319@edirom.de>

Hi Andrew,

we already had a request for a separate version for mobile devices a while ago. Although there is a workaround I agree that we need to fix this at some point. Unless someone else opts in for this, I'll add it to my list. It might have to rest there for a couple of weeks, but I hope to be faster than that?

Best regards,
Johannes



Am 04.01.2011 um 16:29 schrieb Andrew Hankinson, Mr:

> Hi all,
> 
> I was just trying to look up a reference to a MEI tag on my iPod Touch and noticed that the MEI website doesn't work well with the Mobile Safari browser. The scroll bars on the left and right columns in the tag library pages (and other pages where the content overflows the border container) do not appear, and you can only scroll with two fingers, instead of the usual one-fingered scroll, a technique that is not immediately obvious - I only found this out by Googling the problem.
> 
> -Andrew
> 
> 
> 
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From atge at kb.dk  Wed Jan  5 18:50:49 2011
From: atge at kb.dk (Axel Teich Geertinger)
Date: Wed, 5 Jan 2011 18:50:49 +0100
Subject: [MEI-L] relateditem and relations between mei elements
Message-ID: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>

Hi Perry (& others who might be interested)

I've been testing <relatedItem> to describe composite sources, and it seems to do the job nicely.
However, I have also been trying for some time to figure out how to model relations not just between sources (and parts of sources), but between different versions of a work - i.e. encodings which may have several sources each. How should I model the relation between, say, some incidental music, encoded in one MEI file, and some excerpt or arrangement encoded in another MEI file?
I noticed that one of the relations possible in <relatedItem> is "otherVersion". That's exactly what I was looking for, except that it needs to be on a higher level than <source> (because it relates to all the sources to this particular version). One solution could be using <extptr>; something like

    <filedesc>
      <notesstmt>
        <annot type="links">
          <extptr xl:role="isVersionOf" xl:href="..."/>
        </annot>
      </notesstmt>
    </filedesc>

Any better ideas? I am not sure <notesstmt> is the best place for this type of information.

Happy new year to all!
Axel


[cid:image001.jpg at 01CBAD05.D850B240]

Det Kongelige Bibliotek
Nationalbibliotek og K?benhavns Universitetsbibliotek

Axel Teich Geertinger
Forsker | Researcher

Det Kongelige Bibliotek | The Royal Library
Dansk Center for Musikudgivelse | Danish Centre for Music Publication
P.O. Box 2149 | DK-1016 K?benhavn K
tel +45 3347 4706 | Fax +45 3393 2218 | atge at kb.dk<mailto:atge at kb.dk> | www.kb.dk<http://www.kb.dk>

Bes?gsadresse | Visiting address | S?ren Kierkegaards Plads 1
Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 K?benhavn K

EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42
IBAN DK2002164069032583 | Swiftcode DABADKKK


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110105/c7fb4e25/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14433 bytes
Desc: image001.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110105/c7fb4e25/attachment.jpg>

From pdr4h at eservices.virginia.edu  Wed Jan  5 19:02:43 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Wed, 5 Jan 2011 13:02:43 -0500
Subject: [MEI-L] relateditem and relations between mei elements
In-Reply-To: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>
References: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>
Message-ID: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DBD2@MCCLANE.eservices.virginia.edu>

Hi, Axel,

I think what you need is <relatedItem> directly under <meihead> in order to express relationships between MEI instances.  Of course, it isn't there yet, but now that there's a use case for it, I'll add that to the feature request list.

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h at virginia.edu

________________________________
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger [atge at kb.dk]
Sent: Wednesday, January 05, 2011 12:50 PM
To: Music Encoding Initiative
Subject: [MEI-L] relateditem and relations between mei elements

Hi Perry (& others who might be interested)

I?ve been testing <relatedItem> to describe composite sources, and it seems to do the job nicely.
However, I have also been trying for some time to figure out how to model relations not just between sources (and parts of sources), but between different versions of a work ? i.e. encodings which may have several sources each. How should I model the relation between, say, some incidental music, encoded in one MEI file, and some excerpt or arrangement encoded in another MEI file?
I noticed that one of the relations possible in <relatedItem> is ?otherVersion?. That?s exactly what I was looking for, except that it needs to be on a higher level than <source> (because it relates to all the sources to this particular version). One solution could be using <extptr>; something like

    <filedesc>
      <notesstmt>
        <annot type="links">
          <extptr xl:role="isVersionOf" xl:href="..."/>
        </annot>
      </notesstmt>
    </filedesc>

Any better ideas? I am not sure <notesstmt> is the best place for this type of information.

Happy new year to all!
Axel


[cid:image001.jpg at 01CBAD05.D850B240]

Det Kongelige Bibliotek
Nationalbibliotek og K?benhavns Universitetsbibliotek

Axel Teich Geertinger
Forsker | Researcher

Det Kongelige Bibliotek | The Royal Library
Dansk Center for Musikudgivelse | Danish Centre for Music Publication
P.O. Box 2149 | DK-1016 K?benhavn K
tel +45 3347 4706 | Fax +45 3393 2218 | atge at kb.dk<mailto:atge at kb.dk> | www.kb.dk<http://www.kb.dk>

Bes?gsadresse | Visiting address | S?ren Kierkegaards Plads 1
Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 K?benhavn K

EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42
IBAN DK2002164069032583 | Swiftcode DABADKKK


-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14433 bytes
Desc: image001.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110105/d6b92580/attachment.jpg>

From atge at kb.dk  Wed Jan  5 19:16:55 2011
From: atge at kb.dk (Axel Teich Geertinger)
Date: Wed, 5 Jan 2011 19:16:55 +0100
Subject: [MEI-L] pghead
In-Reply-To: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DBD2@MCCLANE.eservices.virginia.edu>
References: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DBD2@MCCLANE.eservices.virginia.edu>
Message-ID: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B301@KBMBX.kb.dk>

That would be great, thanks. 
I've got another problem (minor, though): I would like to be able to provide titles for indvidual movements in different languages (Niels W. Gade, for instance, provided titles in both Danish and German for many of his works). Would it be reasonable to allow multiple <pghead1> elements with different language attributes? As it is, only one <pghead1> is allowed in each <scoredef>. I understand why, of course, but in this case it seems a bit too restrictive.

/axel

-----Oprindelig meddelelse-----
Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry (pdr4h)
Sendt: 5. januar 2011 19:03
Til: Music Encoding Initiative
Emne: Re: [MEI-L] relateditem and relations between mei elements

Hi, Axel,

I think what you need is <relatedItem> directly under <meihead> in order to express relationships between MEI instances.  Of course, it isn't there yet, but now that there's a use case for it, I'll add that to the feature request list.

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h at virginia.edu

________________________________
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger [atge at kb.dk]
Sent: Wednesday, January 05, 2011 12:50 PM
To: Music Encoding Initiative
Subject: [MEI-L] relateditem and relations between mei elements

Hi Perry (& others who might be interested)

I've been testing <relatedItem> to describe composite sources, and it seems to do the job nicely.
However, I have also been trying for some time to figure out how to model relations not just between sources (and parts of sources), but between different versions of a work - i.e. encodings which may have several sources each. How should I model the relation between, say, some incidental music, encoded in one MEI file, and some excerpt or arrangement encoded in another MEI file?
I noticed that one of the relations possible in <relatedItem> is "otherVersion". That's exactly what I was looking for, except that it needs to be on a higher level than <source> (because it relates to all the sources to this particular version). One solution could be using <extptr>; something like

    <filedesc>
      <notesstmt>
        <annot type="links">
          <extptr xl:role="isVersionOf" xl:href="..."/>
        </annot>
      </notesstmt>
    </filedesc>

Any better ideas? I am not sure <notesstmt> is the best place for this type of information.

Happy new year to all!
Axel


[cid:image001.jpg at 01CBAD05.D850B240]

Det Kongelige Bibliotek
Nationalbibliotek og K?benhavns Universitetsbibliotek

Axel Teich Geertinger
Forsker | Researcher

Det Kongelige Bibliotek | The Royal Library Dansk Center for Musikudgivelse | Danish Centre for Music Publication P.O. Box 2149 | DK-1016 K?benhavn K tel +45 3347 4706 | Fax +45 3393 2218 | atge at kb.dk<mailto:atge at kb.dk> | www.kb.dk<http://www.kb.dk>

Bes?gsadresse | Visiting address | S?ren Kierkegaards Plads 1 Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 K?benhavn K

EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42 IBAN DK2002164069032583 | Swiftcode DABADKKK




From kepper at edirom.de  Wed Jan  5 19:43:46 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Wed, 5 Jan 2011 19:43:46 +0100
Subject: [MEI-L] pghead
In-Reply-To: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B301@KBMBX.kb.dk>
References: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DBD2@MCCLANE.eservices.virginia.edu>
	<60BE838F256D564B8BAEE3B5E57E9B730203E4B8B301@KBMBX.kb.dk>
Message-ID: <2E22CDCC-0E3B-45BD-8894-D202684525C8@edirom.de>

I think in this case you have to make a difference between what's on the page and how you're going to use it. If you want to capture the written text, you use one pghead which contains two titles and a linebreak:

<pghead1>
	<title xml:lang="dk">?danish title?</title>
	<lb/>
	<title xml:lang="dk">?german title?</title>
</pghead1>

(this of course depends on the actual layout!)

If you want to use this in your metadata you can do the same: just add a second title with a different xml:lang. Is there something I've missed, or is this a valid solution for your problem?

Best regards to K?benhavn,
Johannes



Am 05.01.2011 um 19:16 schrieb Axel Teich Geertinger:

> That would be great, thanks. 
> I've got another problem (minor, though): I would like to be able to provide titles for indvidual movements in different languages (Niels W. Gade, for instance, provided titles in both Danish and German for many of his works). Would it be reasonable to allow multiple <pghead1> elements with different language attributes? As it is, only one <pghead1> is allowed in each <scoredef>. I understand why, of course, but in this case it seems a bit too restrictive.
> 
> /axel
> 
> -----Oprindelig meddelelse-----
> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry (pdr4h)
> Sendt: 5. januar 2011 19:03
> Til: Music Encoding Initiative
> Emne: Re: [MEI-L] relateditem and relations between mei elements
> 
> Hi, Axel,
> 
> I think what you need is <relatedItem> directly under <meihead> in order to express relationships between MEI instances.  Of course, it isn't there yet, but now that there's a use case for it, I'll add that to the feature request list.
> 
> --
> p.
> 
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h at virginia.edu
> 
> ________________________________
> From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger [atge at kb.dk]
> Sent: Wednesday, January 05, 2011 12:50 PM
> To: Music Encoding Initiative
> Subject: [MEI-L] relateditem and relations between mei elements
> 
> Hi Perry (& others who might be interested)
> 
> I've been testing <relatedItem> to describe composite sources, and it seems to do the job nicely.
> However, I have also been trying for some time to figure out how to model relations not just between sources (and parts of sources), but between different versions of a work - i.e. encodings which may have several sources each. How should I model the relation between, say, some incidental music, encoded in one MEI file, and some excerpt or arrangement encoded in another MEI file?
> I noticed that one of the relations possible in <relatedItem> is "otherVersion". That's exactly what I was looking for, except that it needs to be on a higher level than <source> (because it relates to all the sources to this particular version). One solution could be using <extptr>; something like
> 
>    <filedesc>
>      <notesstmt>
>        <annot type="links">
>          <extptr xl:role="isVersionOf" xl:href="..."/>
>        </annot>
>      </notesstmt>
>    </filedesc>
> 
> Any better ideas? I am not sure <notesstmt> is the best place for this type of information.
> 
> Happy new year to all!
> Axel
> 
> 
> [cid:image001.jpg at 01CBAD05.D850B240]
> 
> Det Kongelige Bibliotek
> Nationalbibliotek og K?benhavns Universitetsbibliotek
> 
> Axel Teich Geertinger
> Forsker | Researcher
> 
> Det Kongelige Bibliotek | The Royal Library Dansk Center for Musikudgivelse | Danish Centre for Music Publication P.O. Box 2149 | DK-1016 K?benhavn K tel +45 3347 4706 | Fax +45 3393 2218 | atge at kb.dk<mailto:atge at kb.dk> | www.kb.dk<http://www.kb.dk>
> 
> Bes?gsadresse | Visiting address | S?ren Kierkegaards Plads 1 Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 K?benhavn K
> 
> EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42 IBAN DK2002164069032583 | Swiftcode DABADKKK
> 
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From pdr4h at eservices.virginia.edu  Wed Jan  5 19:46:30 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Wed, 5 Jan 2011 13:46:30 -0500
Subject: [MEI-L] pghead
In-Reply-To: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B301@KBMBX.kb.dk>
References: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DBD2@MCCLANE.eservices.virginia.edu>,
	<60BE838F256D564B8BAEE3B5E57E9B730203E4B8B301@KBMBX.kb.dk>
Message-ID: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DBD3@MCCLANE.eservices.virginia.edu>

Axel,

The following is already permitted --

<pghead1>
  <title xml:lang="ger">German Title</title>
  <title xml:lang="dan">Danish Title</title>
</pghead1>

no changes required.  :)

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h at virginia.edu
________________________________________
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger [atge at kb.dk]
Sent: Wednesday, January 05, 2011 1:16 PM
To: Music Encoding Initiative
Subject: [MEI-L] pghead

That would be great, thanks.
I've got another problem (minor, though): I would like to be able to provide titles for indvidual movements in different languages (Niels W. Gade, for instance, provided titles in both Danish and German for many of his works). Would it be reasonable to allow multiple <pghead1> elements with different language attributes? As it is, only one <pghead1> is allowed in each <scoredef>. I understand why, of course, but in this case it seems a bit too restrictive.

/axel

-----Oprindelig meddelelse-----
Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry (pdr4h)
Sendt: 5. januar 2011 19:03
Til: Music Encoding Initiative
Emne: Re: [MEI-L] relateditem and relations between mei elements

Hi, Axel,

I think what you need is <relatedItem> directly under <meihead> in order to express relationships between MEI instances.  Of course, it isn't there yet, but now that there's a use case for it, I'll add that to the feature request list.

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h at virginia.edu

________________________________
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger [atge at kb.dk]
Sent: Wednesday, January 05, 2011 12:50 PM
To: Music Encoding Initiative
Subject: [MEI-L] relateditem and relations between mei elements

Hi Perry (& others who might be interested)

I've been testing <relatedItem> to describe composite sources, and it seems to do the job nicely.
However, I have also been trying for some time to figure out how to model relations not just between sources (and parts of sources), but between different versions of a work - i.e. encodings which may have several sources each. How should I model the relation between, say, some incidental music, encoded in one MEI file, and some excerpt or arrangement encoded in another MEI file?
I noticed that one of the relations possible in <relatedItem> is "otherVersion". That's exactly what I was looking for, except that it needs to be on a higher level than <source> (because it relates to all the sources to this particular version). One solution could be using <extptr>; something like

    <filedesc>
      <notesstmt>
        <annot type="links">
          <extptr xl:role="isVersionOf" xl:href="..."/>
        </annot>
      </notesstmt>
    </filedesc>

Any better ideas? I am not sure <notesstmt> is the best place for this type of information.

Happy new year to all!
Axel


[cid:image001.jpg at 01CBAD05.D850B240]

Det Kongelige Bibliotek
Nationalbibliotek og K?benhavns Universitetsbibliotek

Axel Teich Geertinger
Forsker | Researcher

Det Kongelige Bibliotek | The Royal Library Dansk Center for Musikudgivelse | Danish Centre for Music Publication P.O. Box 2149 | DK-1016 K?benhavn K tel +45 3347 4706 | Fax +45 3393 2218 | atge at kb.dk<mailto:atge at kb.dk> | www.kb.dk<http://www.kb.dk>

Bes?gsadresse | Visiting address | S?ren Kierkegaards Plads 1 Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 K?benhavn K

EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42 IBAN DK2002164069032583 | Swiftcode DABADKKK



_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

From atge at kb.dk  Wed Jan  5 19:49:26 2011
From: atge at kb.dk (Axel Teich Geertinger)
Date: Wed, 5 Jan 2011 19:49:26 +0100
Subject: [MEI-L] pghead
In-Reply-To: <2E22CDCC-0E3B-45BD-8894-D202684525C8@edirom.de>
References: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DBD2@MCCLANE.eservices.virginia.edu>
	<60BE838F256D564B8BAEE3B5E57E9B730203E4B8B301@KBMBX.kb.dk>
	<2E22CDCC-0E3B-45BD-8894-D202684525C8@edirom.de>
Message-ID: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B302@KBMBX.kb.dk>

Yes, of course! I just hadn't thought of having several titles within pghead.
Thanks to you both, and please forgive me for asking stupid questions sometimes!
/axel


-----Oprindelig meddelelse-----
Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Johannes Kepper
Sendt: 5. januar 2011 19:44
Til: Music Encoding Initiative
Emne: Re: [MEI-L] pghead

I think in this case you have to make a difference between what's on the page and how you're going to use it. If you want to capture the written text, you use one pghead which contains two titles and a linebreak:

<pghead1>
	<title xml:lang="dk">.danish title.</title>
	<lb/>
	<title xml:lang="dk">.german title.</title>
</pghead1>

(this of course depends on the actual layout!)

If you want to use this in your metadata you can do the same: just add a second title with a different xml:lang. Is there something I've missed, or is this a valid solution for your problem?

Best regards to K?benhavn,
Johannes



Am 05.01.2011 um 19:16 schrieb Axel Teich Geertinger:

> That would be great, thanks. 
> I've got another problem (minor, though): I would like to be able to provide titles for indvidual movements in different languages (Niels W. Gade, for instance, provided titles in both Danish and German for many of his works). Would it be reasonable to allow multiple <pghead1> elements with different language attributes? As it is, only one <pghead1> is allowed in each <scoredef>. I understand why, of course, but in this case it seems a bit too restrictive.
> 
> /axel
> 
> -----Oprindelig meddelelse-----
> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry (pdr4h)
> Sendt: 5. januar 2011 19:03
> Til: Music Encoding Initiative
> Emne: Re: [MEI-L] relateditem and relations between mei elements
> 
> Hi, Axel,
> 
> I think what you need is <relatedItem> directly under <meihead> in order to express relationships between MEI instances.  Of course, it isn't there yet, but now that there's a use case for it, I'll add that to the feature request list.
> 
> --
> p.
> 
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h at virginia.edu
> 
> ________________________________
> From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger [atge at kb.dk]
> Sent: Wednesday, January 05, 2011 12:50 PM
> To: Music Encoding Initiative
> Subject: [MEI-L] relateditem and relations between mei elements
> 
> Hi Perry (& others who might be interested)
> 
> I've been testing <relatedItem> to describe composite sources, and it seems to do the job nicely.
> However, I have also been trying for some time to figure out how to model relations not just between sources (and parts of sources), but between different versions of a work - i.e. encodings which may have several sources each. How should I model the relation between, say, some incidental music, encoded in one MEI file, and some excerpt or arrangement encoded in another MEI file?
> I noticed that one of the relations possible in <relatedItem> is "otherVersion". That's exactly what I was looking for, except that it needs to be on a higher level than <source> (because it relates to all the sources to this particular version). One solution could be using <extptr>; something like
> 
>    <filedesc>
>      <notesstmt>
>        <annot type="links">
>          <extptr xl:role="isVersionOf" xl:href="..."/>
>        </annot>
>      </notesstmt>
>    </filedesc>
> 
> Any better ideas? I am not sure <notesstmt> is the best place for this type of information.
> 
> Happy new year to all!
> Axel
> 
> 
> [cid:image001.jpg at 01CBAD05.D850B240]
> 
> Det Kongelige Bibliotek
> Nationalbibliotek og K?benhavns Universitetsbibliotek
> 
> Axel Teich Geertinger
> Forsker | Researcher
> 
> Det Kongelige Bibliotek | The Royal Library Dansk Center for Musikudgivelse | Danish Centre for Music Publication P.O. Box 2149 | DK-1016 K?benhavn K tel +45 3347 4706 | Fax +45 3393 2218 | atge at kb.dk<mailto:atge at kb.dk> | www.kb.dk<http://www.kb.dk>
> 
> Bes?gsadresse | Visiting address | S?ren Kierkegaards Plads 1 Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 K?benhavn K
> 
> EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42 IBAN DK2002164069032583 | Swiftcode DABADKKK
> 
> 
> 
> _______________________________________________
> 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


From esfield at stanford.edu  Wed Jan  5 20:07:19 2011
From: esfield at stanford.edu (Eleanor Selfridge-Field)
Date: Wed, 5 Jan 2011 11:07:19 -0800 (PST)
Subject: [MEI-L] relateditem and relations between mei elements
In-Reply-To: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>
References: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>
Message-ID: <00c701cbad0b$c5858ae0$5090a0a0$@edu>

Hi, Axel,



I constructed a typology for source  ?variants? in my contribution
?Musical Variants in Digital Practice? to Digitale Edition zwischen
Experiment und Standardisierung (Peter Stadler und Joachim Veit, eds.,
Niemeyer 2009).



In it I considered variants that pertain to scores (and parts) at four
levels of granularity: (1) note-level variants, (2) note-group and
phrase-level variants, (3) part-level and/or orchestral variants, and (4)
tree-structure variants. (This typology accommodates variant editorial
readings up to a point.)



Because there were some difficulties with one of the figures in the
circulated version, I am attaching the final edit version here (for
MEI-group use only).



For durable code structures, one really needs to accommodate ?variants? at
whatever level suits the repertory at hand. I am sure there are situations
in which all of the above occur together.



?         (1) Provisions for note-level variants should usually work for
monophonic repertories, but one can easily conjure up exceptions
(folk-song repertories with translated texts that change syllabification
and add or subtract notes in arbitrary numbers).

?         (2)Note-group and phrase-level variants need to operate on the
second tier for repertories that have beams and slurs, which means most
repertories from 1600 on and quite a bit from before that time.

?         (3) Variations in voicing, instrumentation, instrument grouping,
et al., reflect the steady improvements in printing from the eighteenth
century onward.

?         (4) Tree-structure variants are rampant in manuscript studies
where multiple versions exist (or are reflected?as they often are in
Handel and Vivaldi?by writing them into margins).



Thinking in the first two levels is also useful for handling some
articulations (such as trills, which consume time but do not appear to do
so on the page) and basso continuo figuration. 1:1 (note-level) works in
some situations but not in all.



A ?just enough? scheme for MEI markup (i.e., use Level 1 where it works
throughout the piece, default to it from higher levels within more complex
pieces) would have much to recommend it.



Since a lot of music at the Danish National Library site (which I value
for its transparent organization: thanks!!) come from the eighteenth and
nineteenth centuries, I believe that its interests would be well served
from the ability to accommodation Levels 1, 2, and 3.



Eleanor





Eleanor Selfridge-Field

Stanford University

Stanford, CA 94305-3076

USA

http://www.stanford.edu/~esfield/

http://www.ccarh.org









From: mei-l-bounces at lists.uni-paderborn.de
[mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich
Geertinger
Sent: Wednesday, January 05, 2011 9:51 AM
To: Music Encoding Initiative
Subject: [MEI-L] relateditem and relations between mei elements



Hi Perry (& others who might be interested)



I?ve been testing <relatedItem> to describe composite sources, and it
seems to do the job nicely.

However, I have also been trying for some time to figure out how to model
relations not just between sources (and parts of sources), but between
different versions of a work ? i.e. encodings which may have several
sources each. How should I model the relation between, say, some
incidental music, encoded in one MEI file, and some excerpt or arrangement
encoded in another MEI file?

I noticed that one of the relations possible in <relatedItem> is
?otherVersion?. That?s exactly what I was looking for, except that it
needs to be on a higher level than <source> (because it relates to all the
sources to this particular version). One solution could be using <extptr>;
something like



    <filedesc>
      <notesstmt>
        <annot type="links">
          <extptr xl:role="isVersionOf" xl:href="..."/>
        </annot>
      </notesstmt>
    </filedesc>



Any better ideas? I am not sure <notesstmt> is the best place for this
type of information.



Happy new year to all!

Axel






http://support.kb.dk/images/kb_logo.jpg

Det Kongelige Bibliotek
Nationalbibliotek og K?benhavns Universitetsbibliotek


Axel Teich Geertinger
Forsker | Researcher

Det Kongelige Bibliotek | The Royal Library
Dansk Center for Musikudgivelse | Danish Centre for Music Publication
P.O. Box 2149 | DK-1016 K?benhavn K
tel +45 3347 4706 | Fax +45 3393 2218 |  <mailto:atge at kb.dk> atge at kb.dk |
<http://www.kb.dk> www.kb.dk

Bes?gsadresse | Visiting address | S?ren Kierkegaards Plads 1
Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 K?benhavn
K

EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42
IBAN DK2002164069032583 | Swiftcode DABADKKK



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110105/d2dec86a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 14433 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110105/d2dec86a/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Padernborn__v3_Mar2009.pdf
Type: application/pdf
Size: 634626 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110105/d2dec86a/attachment.pdf>

From pdr4h at eservices.virginia.edu  Thu Jan  6 00:08:55 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Wed, 5 Jan 2011 18:08:55 -0500
Subject: [MEI-L] relateditem and relations between mei elements
In-Reply-To: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>
References: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>
Message-ID: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DBD4@MCCLANE.eservices.virginia.edu>

Axel,

I've given more thought to my statement earlier about adding <relateditem> to <filedesc> and to the use of <relateditem> in general.  We must be clear that the purpose of <relateditem> is to permit relationships between *bibliographic items*, not *works*.  

In the following example --

<relateditem xml:id="chanson01" rel="constituent">
  <!-- Title of the *chanson* -->
  <titlestmt>
    <title>Qui souhaitez</title>
    <!-- Composer -->
    <respstmt>
      <persname authority="lcnaf">
        <choice>
          <orig>Certon</orig>
          <reg><rend>Certon, Pierre, d. 1572</rend></reg>
        </choice>
      </persname>
    </respstmt>
  </titlestmt>
  <!-- Relateditem can also be used to point to other formats of this, e.g., the text/poetry and/or a Sibelius transcription located on the web -->
  <relateditem rel="otherFormat" n="Text">
    <extref xlink:href="pointer.to.text"/>
  </relateditem>
  <relateditem rel="otherFormat" n="Sibelius">
    <extref xlink:href="pointer.to.SibeliusFile"/>
  </relateditem>
</relateditem>

the top-level <relateditem> is used to enumerate the individual chansons within a composite work, hence rel="constituent".  The nested <relateditem> elements are pointing to *the same intellectual content* in a different *physical form*.  This is fine and dandy.

We begin to get into trouble, however, when <relateditem> is used to relate musical works. I think I didn't read your message carefully enough. Sorry :(

Currently, work-to-work relationships can be described in a couple of places.  One method is to use titlestmt/title type="uniform"; the other is to use profiledesc/creation or /classification.  The first is the traditional librarian-ish method, which is not generally known to or used by non-librarians.

The second is not exactly intuitive either. (<profiledesc> is the container for work-related info., but you'd never know it from the name. It's a lousy name, but it has historical precedent.)

Allowing <relateditem rel="otherVersion"> in <source> and <filedesc> I fear will only encourage users to (mis|ab)use it.

Perhaps what we need is a <relatedwork> element in <profiledesc>.  (And maybe even a name change from <profiledesc> to <workdesc>!)  But, before doing anything I'd like to hear how the current methods don't address your needs and I'd like to investigate work-to-work relationship approaches that others have used.  Of course, I'd like to hear comments from everyone else on the list, too!

Sorry for the back-pedalling,

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14433 bytes
Desc: image001.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110105/842025ed/attachment.jpg>

From atge at kb.dk  Thu Jan  6 11:24:56 2011
From: atge at kb.dk (Axel Teich Geertinger)
Date: Thu, 6 Jan 2011 11:24:56 +0100
Subject: [MEI-L] relateditem and relations between mei elements
In-Reply-To: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DBD4@MCCLANE.eservices.virginia.edu>
References: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B300@KBMBX.kb.dk>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DBD4@MCCLANE.eservices.virginia.edu>
Message-ID: <60BE838F256D564B8BAEE3B5E57E9B730203E4B8B3B9@KBMBX.kb.dk>

Hi Perry,

as <relateditem> is modelled after <source>, using it in <filedesc> would of course require some redefinition or probably even a different element (like <relatedWork>, as you suggest). I thought that was what was implied in your response. As it is, I am aware that <relateditem> is usable for bibliographic items only - hence my question about how to relate works. 
Using a uniform title to tie together different versions seems to me a bit too vague. The connection to other versions would be obscured until the entire collection is searched and a matching title in another file is found. Also the kind of relationship would not be clear from a matching title alone, and finally there is the risk of accidentally displaying as related versions two works which just happen to have the same uniform title. Or do I misunderstand the concept?
Using profiledesc/classification I guess would mean something like <keywords n="relatedWorks"><term n="otherVersion">some.id</term></keywords>. This may be somewhat misleading, as I am listing external references, not keywords.
With the existing elements I would prefer using <extptr> or <extref> with @targettype="otherVersion" or @xl:role to explicitly reference related works. In profiledesc/creation however I would have to wrap it in <p></p>, even though it has nothing to do with a paragraph of text.
I could use some of these solutions (preferably the last one), they just don't seem very convincing to me. 

/axel

-----Oprindelig meddelelse-----
Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry (pdr4h)
Sendt: 6. januar 2011 00:09
Til: Music Encoding Initiative
Emne: Re: [MEI-L] relateditem and relations between mei elements

Axel,

I've given more thought to my statement earlier about adding <relateditem> to <filedesc> and to the use of <relateditem> in general.  We must be clear that the purpose of <relateditem> is to permit relationships between *bibliographic items*, not *works*.  

In the following example --

<relateditem xml:id="chanson01" rel="constituent">
  <!-- Title of the *chanson* -->
  <titlestmt>
    <title>Qui souhaitez</title>
    <!-- Composer -->
    <respstmt>
      <persname authority="lcnaf">
        <choice>
          <orig>Certon</orig>
          <reg><rend>Certon, Pierre, d. 1572</rend></reg>
        </choice>
      </persname>
    </respstmt>
  </titlestmt>
  <!-- Relateditem can also be used to point to other formats of this, e.g., the text/poetry and/or a Sibelius transcription located on the web -->
  <relateditem rel="otherFormat" n="Text">
    <extref xlink:href="pointer.to.text"/>
  </relateditem>
  <relateditem rel="otherFormat" n="Sibelius">
    <extref xlink:href="pointer.to.SibeliusFile"/>
  </relateditem>
</relateditem>

the top-level <relateditem> is used to enumerate the individual chansons within a composite work, hence rel="constituent".  The nested <relateditem> elements are pointing to *the same intellectual content* in a different *physical form*.  This is fine and dandy.

We begin to get into trouble, however, when <relateditem> is used to relate musical works. I think I didn't read your message carefully enough. Sorry :(

Currently, work-to-work relationships can be described in a couple of places.  One method is to use titlestmt/title type="uniform"; the other is to use profiledesc/creation or /classification.  The first is the traditional librarian-ish method, which is not generally known to or used by non-librarians.

The second is not exactly intuitive either. (<profiledesc> is the container for work-related info., but you'd never know it from the name. It's a lousy name, but it has historical precedent.)

Allowing <relateditem rel="otherVersion"> in <source> and <filedesc> I fear will only encourage users to (mis|ab)use it.

Perhaps what we need is a <relatedwork> element in <profiledesc>.  (And maybe even a name change from <profiledesc> to <workdesc>!)  But, before doing anything I'd like to hear how the current methods don't address your needs and I'd like to investigate work-to-work relationship approaches that others have used.  Of course, I'd like to hear comments from everyone else on the list, too!

Sorry for the back-pedalling,

--
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 andrew.hankinson at mail.mcgill.ca  Thu Jan  6 17:45:31 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Thu, 6 Jan 2011 11:45:31 -0500
Subject: [MEI-L] Music21 MEI support
Message-ID: <0C75F795-483D-4C6D-92C8-53F8D13AE0C4@mail.mcgill.ca>

Hi all,

I've started writing a module to support MEI in Music21, a new music analysis package for Python from some folks at MIT. It's still at a very preliminary stage, but it will parse a couple of example MEI files, including the Bach Toccata & Fugue BWV 565 example (a fairly complex example).

There's a long ways to go before it's fully implemented, but I thought I'd send it around to gauge interest and get feedback. You can find the code for it here:

http://github.com/ahankinson/music21-mei

If you're interested in using it, please read the README for more information on what it currently can and cannot do.

If you don't know Music21, you can find out more about it here: http://mit.edu/music21/

Any feedback, or even just "Hey, that's great! I can use this" messages would be greatly appreciated.

Cheers,
-Andrew

======
Andrew Hankinson, BMus, MLIS
PhD Candidate in Music Technology

Centre for Interdisciplinary Research
 in Music Media and Technology (CIRMMT)
Schulich School of Music, McGill University
555 Sherbrooke St. West
Montr?al, QC, Canada H3A 1E3

Tel: 514.398.4535 x0300
Fax: 514.398.8061
andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>

h<http://www.music.mcgill.ca/~ahankinson>ttp://www.transientstudent.net


From donbyrd at indiana.edu  Sat Jan  8 03:15:50 2011
From: donbyrd at indiana.edu (Byrd,  Donald A.)
Date: Fri,  7 Jan 2011 21:15:50 -0500
Subject: [MEI-L] Music21 MEI support
In-Reply-To: <0C75F795-483D-4C6D-92C8-53F8D13AE0C4@mail.mcgill.ca>
References: <0C75F795-483D-4C6D-92C8-53F8D13AE0C4@mail.mcgill.ca>
Message-ID: <20110107211550.ys06772cgg88oc4o@webmail.iu.edu>

For years Michael Cuthbert, the leader of the Music21 project, and I 
have been exchanging e-mail, mostly about demanding features of music 
notation but occasionally about things like visualizations of music, 
especially coordinated visualizations, which we're both very interested 
in. I like his ideas a lot, e.g., the fact that (or so he's told me) he 
tells his students that "if a feature is in Don Byrd's [Extremes of 
Conventional Music Notation]list, we have to at least try!" ...okay, I 
may be a little biased about that :-) . Anyway, what I've seen of 
Music21 is impressive.

--Don


On Thu, 6 Jan 2011 11:45:31 -0500, "Andrew Hankinson, Mr" 
<andrew.hankinson at mail.mcgill.ca> wrote:

> Hi all,
>
> I've started writing a module to support MEI in Music21, a new music
> analysis package for Python from some folks at MIT. It's still at a
> very preliminary stage, but it will parse a couple of example MEI
> files, including the Bach Toccata & Fugue BWV 565 example (a fairly
> complex example).
>
> There's a long ways to go before it's fully implemented, but I
> thought I'd send it around to gauge interest and get feedback. You
> can find the code for it here:
>
> http://github.com/ahankinson/music21-mei
>
> If you're interested in using it, please read the README for more
> information on what it currently can and cannot do.
>
> If you don't know Music21, you can find out more about it here:
> http://mit.edu/music21/
>
> Any feedback, or even just "Hey, that's great! I can use this"
> messages would be greatly appreciated.
>
> Cheers,
> -Andrew
>
> ======
> Andrew Hankinson, BMus, MLIS
> PhD Candidate in Music Technology
>
> Centre for Interdisciplinary Research
> in Music Media and Technology (CIRMMT)
> Schulich School of Music, McGill University
> 555 Sherbrooke St. West
> Montr?al, QC, Canada H3A 1E3
>
> Tel: 514.398.4535 x0300
> Fax: 514.398.8061
> andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>
>
> h<http://www.music.mcgill.ca/~ahankinson>ttp://www.transientstudent.net
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>



--
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics & Music
Indiana University, Bloomington



From cuthbert at MIT.EDU  Sun Jan  9 08:13:22 2011
From: cuthbert at MIT.EDU (Michael Cuthbert)
Date: Sun, 9 Jan 2011 02:13:22 -0500
Subject: [MEI-L] Music21 MEI support
In-Reply-To: <20110107211550.ys06772cgg88oc4o@webmail.iu.edu>
References: <0C75F795-483D-4C6D-92C8-53F8D13AE0C4@mail.mcgill.ca>
	<20110107211550.ys06772cgg88oc4o@webmail.iu.edu>
Message-ID: <034301cbafcc$b401b0f0$1c0512d0$@edu>

Thanks Andrew and Don for the kind words about the project; it's great to hear
such support.  

For those on this list that might not know the project, music21 is a toolkit
for computer-aided research in musicology and music theory.  It's spiritual
forefather of course is the great Humdrum framework, but music21 aims for a
more object-oriented approach that makes representing hierarchical musical
structures, and reusing code easier.  This approach has let us support a number
of music encoding formats (most prominently MusicXML and Humdrum but also abc,
Lilypond, musedata, base40, and MIDI and hopefully soon, though our
"plug-in"-like framework, Braille music notation).

As a musicologist, building a system that can deal with ambiguity and rich
Metadata is very important to me.  MEI is a very rich system there that we hope
to watch closely and hopefully help it grow.  One of the things that the
music21 internal representation allows for is Metadata that applies to specific
parts of a score.  So if you want to show that a particular 4 measure passage
is not by Mozart, it can be tagged like that.  Or to show that there's
uncertainty about the date of one movement of a piece but not the rest, that
can be done too.  I'd love to hear from more librarians about tools that are
not currently present in notation software that will help with your work and
analysis.

All the best,
Michael

 
---                                                     ---
Michael Scott Cuthbert
   Assistant Professor of Music, M.I.T.  

4-246 Music and Theater Arts                +1-413-575-6024
77 Massachusetts Ave.               http://www.trecento.com
Cambridge, MA 02139                        cuthbert at mit.edu          



-----Original Message-----
From: Byrd, Donald A. [mailto:donbyrd at indiana.edu] 
Sent: Friday, January 07, 2011 21:16
To: Music Encoding Initiative; Andrew Hankinson, Mr
Cc: mei-l at lists.uni-paderborn.de
Subject: Re: [MEI-L] Music21 MEI support

For years Michael Cuthbert, the leader of the Music21 project, and I 
have been exchanging e-mail, mostly about demanding features of music 
notation but occasionally about things like visualizations of music, 
especially coordinated visualizations, which we're both very interested 
in. I like his ideas a lot, e.g., the fact that (or so he's told me) he 
tells his students that "if a feature is in Don Byrd's [Extremes of 
Conventional Music Notation]list, we have to at least try!" ...okay, I 
may be a little biased about that :-) . Anyway, what I've seen of 
Music21 is impressive.

--Don


On Thu, 6 Jan 2011 11:45:31 -0500, "Andrew Hankinson, Mr" 
<andrew.hankinson at mail.mcgill.ca> wrote:

> Hi all,
>
> I've started writing a module to support MEI in Music21, a new music
> analysis package for Python from some folks at MIT. It's still at a
> very preliminary stage, but it will parse a couple of example MEI
> files, including the Bach Toccata & Fugue BWV 565 example (a fairly
> complex example).
>
> There's a long ways to go before it's fully implemented, but I
> thought I'd send it around to gauge interest and get feedback. You
> can find the code for it here:
>
> http://github.com/ahankinson/music21-mei
>
> If you're interested in using it, please read the README for more
> information on what it currently can and cannot do.
>
> If you don't know Music21, you can find out more about it here:
> http://mit.edu/music21/
>
> Any feedback, or even just "Hey, that's great! I can use this"
> messages would be greatly appreciated.
>
> Cheers,
> -Andrew
>
> ======
> Andrew Hankinson, BMus, MLIS
> PhD Candidate in Music Technology
>
> Centre for Interdisciplinary Research
> in Music Media and Technology (CIRMMT)
> Schulich School of Music, McGill University
> 555 Sherbrooke St. West
> Montr?al, QC, Canada H3A 1E3
>
> Tel: 514.398.4535 x0300
> Fax: 514.398.8061
> andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>
>
> h<http://www.music.mcgill.ca/~ahankinson>ttp://www.transientstudent.net
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>



--
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics & Music
Indiana University, Bloomington




From esfield at stanford.edu  Tue Jan 11 00:49:33 2011
From: esfield at stanford.edu (Eleanor Selfridge-Field)
Date: Mon, 10 Jan 2011 15:49:33 -0800 (PST)
Subject: [MEI-L] Music21 MEI support
In-Reply-To: <034301cbafcc$b401b0f0$1c0512d0$@edu>
References: <0C75F795-483D-4C6D-92C8-53F8D13AE0C4@mail.mcgill.ca>	<20110107211550.ys06772cgg88oc4o@webmail.iu.edu>
	<034301cbafcc$b401b0f0$1c0512d0$@edu>
Message-ID: <002201cbb121$04d360f0$0e7a22d0$@edu>

Mike has a good point here about "metadata that applies to specific parts
of a score". I can interpret that two ways--"parts" as in instrumental
parts of a performing score, but also "portions" as in the B section of a
movement, or simply a foreign hand that enters in some random part of a
musical work.

People who work only from printed sources will not be concerned with the
second, but people who work with manuscripts are regularly confronted with
many varieties of the second.

Thus I support the idea. I am wondering what the practicalities of
implementation in MEI are.

Eleanor




-----Original Message-----
From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de
[mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de] On
Behalf Of Michael Cuthbert
Sent: Saturday, January 08, 2011 11:13 PM
To: 'Music Encoding Initiative'
Cc: mei-l at lists.uni-paderborn.de
Subject: Re: [MEI-L] Music21 MEI support

Thanks Andrew and Don for the kind words about the project; it's great to
hear
such support.

For those on this list that might not know the project, music21 is a
toolkit
for computer-aided research in musicology and music theory.  It's
spiritual
forefather of course is the great Humdrum framework, but music21 aims for
a
more object-oriented approach that makes representing hierarchical musical
structures, and reusing code easier.  This approach has let us support a
number
of music encoding formats (most prominently MusicXML and Humdrum but also
abc,
Lilypond, musedata, base40, and MIDI and hopefully soon, though our
"plug-in"-like framework, Braille music notation).

As a musicologist, building a system that can deal with ambiguity and rich
Metadata is very important to me.  MEI is a very rich system there that we
hope
to watch closely and hopefully help it grow.  One of the things that the
music21 internal representation allows for is Metadata that applies to
specific
parts of a score.  So if you want to show that a particular 4 measure
passage
is not by Mozart, it can be tagged like that.  Or to show that there's
uncertainty about the date of one movement of a piece but not the rest,
that
can be done too.  I'd love to hear from more librarians about tools that
are
not currently present in notation software that will help with your work
and
analysis.

All the best,
Michael


---                                                     ---
Michael Scott Cuthbert
   Assistant Professor of Music, M.I.T.

4-246 Music and Theater Arts                +1-413-575-6024
77 Massachusetts Ave.               http://www.trecento.com
Cambridge, MA 02139                        cuthbert at mit.edu



-----Original Message-----
From: Byrd, Donald A. [mailto:donbyrd at indiana.edu]
Sent: Friday, January 07, 2011 21:16
To: Music Encoding Initiative; Andrew Hankinson, Mr
Cc: mei-l at lists.uni-paderborn.de
Subject: Re: [MEI-L] Music21 MEI support

For years Michael Cuthbert, the leader of the Music21 project, and I
have been exchanging e-mail, mostly about demanding features of music
notation but occasionally about things like visualizations of music,
especially coordinated visualizations, which we're both very interested
in. I like his ideas a lot, e.g., the fact that (or so he's told me) he
tells his students that "if a feature is in Don Byrd's [Extremes of
Conventional Music Notation]list, we have to at least try!" ...okay, I
may be a little biased about that :-) . Anyway, what I've seen of
Music21 is impressive.

--Don


On Thu, 6 Jan 2011 11:45:31 -0500, "Andrew Hankinson, Mr"
<andrew.hankinson at mail.mcgill.ca> wrote:

> Hi all,
>
> I've started writing a module to support MEI in Music21, a new music
> analysis package for Python from some folks at MIT. It's still at a
> very preliminary stage, but it will parse a couple of example MEI
> files, including the Bach Toccata & Fugue BWV 565 example (a fairly
> complex example).
>
> There's a long ways to go before it's fully implemented, but I
> thought I'd send it around to gauge interest and get feedback. You
> can find the code for it here:
>
> http://github.com/ahankinson/music21-mei
>
> If you're interested in using it, please read the README for more
> information on what it currently can and cannot do.
>
> If you don't know Music21, you can find out more about it here:
> http://mit.edu/music21/
>
> Any feedback, or even just "Hey, that's great! I can use this"
> messages would be greatly appreciated.
>
> Cheers,
> -Andrew
>
> ======
> Andrew Hankinson, BMus, MLIS
> PhD Candidate in Music Technology
>
> Centre for Interdisciplinary Research
> in Music Media and Technology (CIRMMT)
> Schulich School of Music, McGill University
> 555 Sherbrooke St. West
> Montr?al, QC, Canada H3A 1E3
>
> Tel: 514.398.4535 x0300
> Fax: 514.398.8061
> andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>
>
> h<http://www.music.mcgill.ca/~ahankinson>ttp://www.transientstudent.net
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>



--
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics & Music
Indiana University, Bloomington



_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l


From andrew.hankinson at mail.mcgill.ca  Tue Jan 11 01:12:55 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Mon, 10 Jan 2011 19:12:55 -0500
Subject: [MEI-L] Music21 MEI support
In-Reply-To: <20110110234951.11664F0C117@asmx2.McGill.CA>
References: <0C75F795-483D-4C6D-92C8-53F8D13AE0C4@mail.mcgill.ca>
	<20110107211550.ys06772cgg88oc4o@webmail.iu.edu>
	<034301cbafcc$b401b0f0$1c0512d0$@edu>
	<20110110234951.11664F0C117@asmx2.McGill.CA>
Message-ID: <70AEADAF-75D4-49EF-8C1A-9C1D72C0AA88@mail.mcgill.ca>

For that specific example (changing hands), MEI already provides support for that: The "hand", "handlist" and "handshift" elements.

As I understand it, the generic "section" element in MEI can be used to annotate different parts, e.g., the beginning of a fugue section, a transition point from solo to choir, or even just to mark a changing clef or key signature.

-Andrew

On 2011-01-10, at 6:49 PM, Eleanor Selfridge-Field wrote:

> Mike has a good point here about "metadata that applies to specific parts
> of a score". I can interpret that two ways--"parts" as in instrumental
> parts of a performing score, but also "portions" as in the B section of a
> movement, or simply a foreign hand that enters in some random part of a
> musical work.
> 
> People who work only from printed sources will not be concerned with the
> second, but people who work with manuscripts are regularly confronted with
> many varieties of the second.
> 
> Thus I support the idea. I am wondering what the practicalities of
> implementation in MEI are.
> 
> Eleanor
> 
> 
> 
> 
> -----Original Message-----
> From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de
> [mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de] On
> Behalf Of Michael Cuthbert
> Sent: Saturday, January 08, 2011 11:13 PM
> To: 'Music Encoding Initiative'
> Cc: mei-l at lists.uni-paderborn.de
> Subject: Re: [MEI-L] Music21 MEI support
> 
> Thanks Andrew and Don for the kind words about the project; it's great to
> hear
> such support.
> 
> For those on this list that might not know the project, music21 is a
> toolkit
> for computer-aided research in musicology and music theory.  It's
> spiritual
> forefather of course is the great Humdrum framework, but music21 aims for
> a
> more object-oriented approach that makes representing hierarchical musical
> structures, and reusing code easier.  This approach has let us support a
> number
> of music encoding formats (most prominently MusicXML and Humdrum but also
> abc,
> Lilypond, musedata, base40, and MIDI and hopefully soon, though our
> "plug-in"-like framework, Braille music notation).
> 
> As a musicologist, building a system that can deal with ambiguity and rich
> Metadata is very important to me.  MEI is a very rich system there that we
> hope
> to watch closely and hopefully help it grow.  One of the things that the
> music21 internal representation allows for is Metadata that applies to
> specific
> parts of a score.  So if you want to show that a particular 4 measure
> passage
> is not by Mozart, it can be tagged like that.  Or to show that there's
> uncertainty about the date of one movement of a piece but not the rest,
> that
> can be done too.  I'd love to hear from more librarians about tools that
> are
> not currently present in notation software that will help with your work
> and
> analysis.
> 
> All the best,
> Michael
> 
> 
> ---                                                     ---
> Michael Scott Cuthbert
>   Assistant Professor of Music, M.I.T.
> 
> 4-246 Music and Theater Arts                +1-413-575-6024
> 77 Massachusetts Ave.               http://www.trecento.com
> Cambridge, MA 02139                        cuthbert at mit.edu
> 
> 
> 
> -----Original Message-----
> From: Byrd, Donald A. [mailto:donbyrd at indiana.edu]
> Sent: Friday, January 07, 2011 21:16
> To: Music Encoding Initiative; Andrew Hankinson, Mr
> Cc: mei-l at lists.uni-paderborn.de
> Subject: Re: [MEI-L] Music21 MEI support
> 
> For years Michael Cuthbert, the leader of the Music21 project, and I
> have been exchanging e-mail, mostly about demanding features of music
> notation but occasionally about things like visualizations of music,
> especially coordinated visualizations, which we're both very interested
> in. I like his ideas a lot, e.g., the fact that (or so he's told me) he
> tells his students that "if a feature is in Don Byrd's [Extremes of
> Conventional Music Notation]list, we have to at least try!" ...okay, I
> may be a little biased about that :-) . Anyway, what I've seen of
> Music21 is impressive.
> 
> --Don
> 
> 
> On Thu, 6 Jan 2011 11:45:31 -0500, "Andrew Hankinson, Mr"
> <andrew.hankinson at mail.mcgill.ca> wrote:
> 
>> Hi all,
>> 
>> I've started writing a module to support MEI in Music21, a new music
>> analysis package for Python from some folks at MIT. It's still at a
>> very preliminary stage, but it will parse a couple of example MEI
>> files, including the Bach Toccata & Fugue BWV 565 example (a fairly
>> complex example).
>> 
>> There's a long ways to go before it's fully implemented, but I
>> thought I'd send it around to gauge interest and get feedback. You
>> can find the code for it here:
>> 
>> http://github.com/ahankinson/music21-mei
>> 
>> If you're interested in using it, please read the README for more
>> information on what it currently can and cannot do.
>> 
>> If you don't know Music21, you can find out more about it here:
>> http://mit.edu/music21/
>> 
>> Any feedback, or even just "Hey, that's great! I can use this"
>> messages would be greatly appreciated.
>> 
>> Cheers,
>> -Andrew
>> 
>> ======
>> Andrew Hankinson, BMus, MLIS
>> PhD Candidate in Music Technology
>> 
>> Centre for Interdisciplinary Research
>> in Music Media and Technology (CIRMMT)
>> Schulich School of Music, McGill University
>> 555 Sherbrooke St. West
>> Montr?al, QC, Canada H3A 1E3
>> 
>> Tel: 514.398.4535 x0300
>> Fax: 514.398.8061
>> andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>
>> 
>> h<http://www.music.mcgill.ca/~ahankinson>ttp://www.transientstudent.net
>> 
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>> 
> 
> 
> 
> --
> Donald Byrd
> Woodrow Wilson Indiana Teaching Fellow
> Adjunct Associate Professor of Informatics & Music
> Indiana University, Bloomington
> 
> 
> 
> _______________________________________________
> 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



From rfreedma at haverford.edu  Tue Feb  1 02:23:49 2011
From: rfreedma at haverford.edu (Richard Freedman)
Date: Mon, 31 Jan 2011 20:23:49 -0500
Subject: [MEI-L] Freedman, Du Chemin, and ACLS Grant
Message-ID: <AANLkTiktAiCk4VKVm6prRw9ndp+0NgeA0TMw-13xwGg3@mail.gmail.com>

Friends:

Just a short note to share some good news:  I was just awarded a ACLS
Digital Innovations Fellowship to support the work of the Du Chemin
project.    I will have a sabbatical for 2011-12, and a good budget for
technical work, conferences, etc.

We will finish our facsimiles, editions, and our reconstructions.  Our plan
is to use the MEI if possible to coordinate variant readings, alternative
reconstructions, and linkages among related compositions, theoretical ideas.

I hope to see some of you during our work, either here in the US or in
Europe!

until later,

Richard

-- 
Richard Freedman
John C. Whitehead Professor of Music
Haverford College
Haverford, PA 19041

610-896-1007
610-896-4902 (fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110131/045cd826/attachment.htm>

From andrew.hankinson at mail.mcgill.ca  Tue Feb  1 02:37:28 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Mon, 31 Jan 2011 20:37:28 -0500
Subject: [MEI-L] Freedman, Du Chemin, and ACLS Grant
In-Reply-To: <20110201012403.0F2DFD8806B@asmx3.McGill.CA>
References: <20110201012403.0F2DFD8806B@asmx3.McGill.CA>
Message-ID: <6103D139-62C8-4B4C-80EE-14A50C5AA6EC@mail.mcgill.ca>

Fantastic news! Congratulations!

-Andrew

On 2011-01-31, at 8:23 PM, Richard Freedman wrote:

> Friends:
> 
> Just a short note to share some good news:  I was just awarded a ACLS Digital Innovations Fellowship to support the work of the Du Chemin project.    I will have a sabbatical for 2011-12, and a good budget for technical work, conferences, etc.
> 
> We will finish our facsimiles, editions, and our reconstructions.  Our plan is to use the MEI if possible to coordinate variant readings, alternative reconstructions, and linkages among related compositions, theoretical ideas.
> 
> I hope to see some of you during our work, either here in the US or in Europe!
> 
> until later,
> 
> Richard
> 
> -- 
> Richard Freedman
> John C. Whitehead Professor of Music
> Haverford College
> Haverford, PA 19041
> 
> 610-896-1007
> 610-896-4902 (fax)
> 
> <ATT00001..txt>



From veit at weber-gesamtausgabe.de  Tue Feb  1 09:06:36 2011
From: veit at weber-gesamtausgabe.de (Joachim Veit)
Date: Tue, 01 Feb 2011 09:06:36 +0100
Subject: [MEI-L] Freedman, Du Chemin, and ACLS Grant
In-Reply-To: <AANLkTiktAiCk4VKVm6prRw9ndp+0NgeA0TMw-13xwGg3@mail.gmail.com>
References: <AANLkTiktAiCk4VKVm6prRw9ndp+0NgeA0TMw-13xwGg3@mail.gmail.com>
Message-ID: <4D47BF0C.6030402@weber-gesamtausgabe.de>

Dear Richard,
congratulations!! This is absolutely fascinating news!
Best wishes for the project!
Joachim


Am 01.02.11 02:23, schrieb Richard Freedman:
> Friends:
>
> Just a short note to share some good news:  I was just awarded a ACLS 
> Digital Innovations Fellowship to support the work of the Du Chemin 
> project.    I will have a sabbatical for 2011-12, and a good budget 
> for technical work, conferences, etc.
>
> We will finish our facsimiles, editions, and our reconstructions.  Our 
> plan is to use the MEI if possible to coordinate variant readings, 
> alternative reconstructions, and linkages among related compositions, 
> theoretical ideas.
>
> I hope to see some of you during our work, either here in the US or in 
> Europe!
>
> until later,
>
> Richard
>
> -- 
> Richard Freedman
> John C. Whitehead Professor of Music
> Haverford College
> Haverford, PA 19041
>
> 610-896-1007
> 610-896-4902 (fax)
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110201/1811d579/attachment.htm>
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : veit.vcf
Dateityp    : text/x-vcard
Dateigr??e  : 364 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110201/1811d579/attachment.vcf>

From pdr4h at eservices.virginia.edu  Tue Feb  1 14:47:43 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Tue, 1 Feb 2011 08:47:43 -0500
Subject: [MEI-L] Freedman, Du Chemin, and ACLS Grant
In-Reply-To: <AANLkTiktAiCk4VKVm6prRw9ndp+0NgeA0TMw-13xwGg3@mail.gmail.com>
References: <AANLkTiktAiCk4VKVm6prRw9ndp+0NgeA0TMw-13xwGg3@mail.gmail.com>
Message-ID: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC34@MCCLANE.eservices.virginia.edu>

Wonderful news, Richard!
Congratulations!

--
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 Richard Freedman [rfreedma at haverford.edu]
Sent: Monday, January 31, 2011 8:23 PM
To: mei-l at lists.uni-paderborn.de
Subject: [MEI-L] Freedman, Du Chemin, and ACLS Grant


Friends:

Just a short note to share some good news:  I was just awarded a ACLS Digital Innovations Fellowship to support the work of the Du Chemin project.    I will have a sabbatical for 2011-12, and a good budget for technical work, conferences, etc.

We will finish our facsimiles, editions, and our reconstructions.  Our plan is to use the MEI if possible to coordinate variant readings, alternative reconstructions, and linkages among related compositions, theoretical ideas.

I hope to see some of you during our work, either here in the US or in Europe!

until later,

Richard

-- 
Richard Freedman
John C. Whitehead Professor of Music
Haverford College
Haverford, PA 19041

610-896-1007
610-896-4902 (fax)

From raffaeleviglianti at gmail.com  Tue Feb  1 19:02:08 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Tue, 1 Feb 2011 18:02:08 +0000
Subject: [MEI-L] TEI with Music Notation
Message-ID: <AANLkTi=oynEA==ukjqTFj1TuSC7jNL4-Wy9x43UOj9Gf@mail.gmail.com>

TEI with Music Notation customization

The Text Encoding Initiative Special Interest Group in Music is pleased to
announce the results of a TEI-funded project to bring music encoding into
TEI documents.

Music, like many other art forms, is often mentioned, discussed and
described in writings of various kinds. This applies to both historical and
contemporary documents, even though the way of notating music has changed
considerably in western history. In most cases, music notation enters the
text flow in a way similar to figures, images or graphs. On other occasions,
elements of music notation are treated as inline characters in running text.

The TEI with Music Notation customization introduces a way of signalling the
presence of music notation in text, but defers to other representations to
describe the music notation itself, which is not covered by TEI guidelines.
In fact, several commercial, academic and standard bodies have developed
digital representations of music notation and, given the topic's complexity,
these representations often focus on different aspects and adopt different
methodologies. Therefore, the customization defines a container element to
encode the occurrence of music notation and allows linking to the data
format preferred by the encoder.  This element is called notatedMusic, which
has been proposed to enter the TEI specifications and TEI's namespace in a
feature request available
here<http://sourceforge.net/tracker/?func=detail&aid=3086726&group_id=106328amp;&atid=644065>
for
further discussion.

The customization also allows the use of elements from the Music Encoding
Initiative format as content of the new notatedMusic element.

We would like to invite those of you who are interested in the encoding of
texts which contain music notation to access the documentation, the ODD and
the schema on the SIG's webspace:

http://www.tei-c.org/SIG/Music/twm/index.html

We consider this output as a *beta* release and we are very interested in
collecting comments, feedback and discussing possible use scenarios. Please
join our mailing
list<http://listserv.brown.edu/archives/cgi-bin/wa?SUBED1=tei-music-sig&A=1>
if
you would like to discuss any aspect of this customization.

With kind regards,
Raffaele Viglianti


-- 
Raffaele Viglianti
PhD Candidate and PGRA
Centre for Computing in the Humanities
King's College London
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110201/ad147acb/attachment.htm>

From andrew.hankinson at mail.mcgill.ca  Mon Feb  7 19:51:05 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Mon, 7 Feb 2011 13:51:05 -0500
Subject: [MEI-L] Encoding staff positions
Message-ID: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>

I'm currently trying to work out a method of encoding staff system positions on a page using MEI.

Let's assume that there is a single page of unmeasured music, with four systems on the page and I want to create a <zone> element for each system describing its layout.

Currently, the <staff> element seems to indicate a continuous line of music independent of its layout in systems, with the empty <sb /> element used to indicate a break in the system layout. This empty element has an @facs attribute, but I would be hesitant to encode spatial information with an empty element.

Before I go any further, can anyone think of something I'm missing? Any possible solutions?

If not, I can see two options. 

The first is to create an element that is similar to the <span> element (call it "<mspan>"). This element would be a non-wrapping element that is generic and simply supplies a method of wrapping arbitrary information. This would be modelled after the use in the hOCR specification -- you can see an example here: http://code.google.com/p/hocr-tools/source/browse/sample.html

Thus, you might have:

<staff>
  <mspan facs="123">
 	.... system 1 ....
  </mspan>
  <sb />
  <mspan facs="456">
	.... system 2 ....
  </mspan>
  <sb />
</staff>

While the <mspan> element would be a pretty powerful addition, its semantic value is minimal. Thus, the other option might be to introduce an explicit <system> element that would be a child of the <staff> and function as an explicit wrapper for a system, in place of the empty <sb /> element; thus

<staff>
  <system n="1" facs="123">
    .... system 1 ....
  </system>
  <system n="2" facs="456">
    .... system 2 ....
  </system>
</staff>

Any ideas? Thoughts?

-Andrew




From pdr4h at eservices.virginia.edu  Mon Feb  7 20:10:15 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Mon, 7 Feb 2011 14:10:15 -0500
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
Message-ID: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>

Hi Andrew,

You're absolutely right that <staff> attempts to capture the logical nature rather than the physical nature of staves.  <sb/> is of secondary importance in this approach.

However, Laurent and I have had several conversations about creating a page-oriented version of MEI.  I think this would address your needs as one of the major features of this approach would be a <system> element.  In other words, in this approach the physical layout would be primary.



I think turning the current schema "inside-outside" would be a good place to start; that is, the things that are empty now, such as <lb/> and <sb/> will end up being containers and some current container elements will end up being empty.  I think your suggestions a're definitely on the right track, but I'm reluctant to intermingle the logical-is-primary approach with the physical-is-primary method.  So, I think the choice will have to be mutually exclusive, implemented by switching on a page-oriented module.  The big question is, How many of the existing elements will have to make the empty <--> container switch?



Is this something we can take up after the next release in May?



--

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: Monday, February 07, 2011 1:51 PM
To: Music Encoding Initiative
Subject: [MEI-L] Encoding staff positions

I'm currently trying to work out a method of encoding staff system positions on a page using MEI.

Let's assume that there is a single page of unmeasured music, with four systems on the page and I want to create a <zone> element for each system describing its layout.

Currently, the <staff> element seems to indicate a continuous line of music independent of its layout in systems, with the empty <sb /> element used to indicate a break in the system layout. This empty element has an @facs attribute, but I would be hesitant to encode spatial information with an empty element.

Before I go any further, can anyone think of something I'm missing? Any possible solutions?

If not, I can see two options.

The first is to create an element that is similar to the <span> element (call it "<mspan>"). This element would be a non-wrapping element that is generic and simply supplies a method of wrapping arbitrary information. This would be modelled after the use in the hOCR specification -- you can see an example here: http://code.google.com/p/hocr-tools/source/browse/sample.html

Thus, you might have:

<staff>
  <mspan facs="123">
        .... system 1 ....
  </mspan>
  <sb />
  <mspan facs="456">
        .... system 2 ....
  </mspan>
  <sb />
</staff>

While the <mspan> element would be a pretty powerful addition, its semantic value is minimal. Thus, the other option might be to introduce an explicit <system> element that would be a child of the <staff> and function as an explicit wrapper for a system, in place of the empty <sb /> element; thus

<staff>
  <system n="1" facs="123">
    .... system 1 ....
  </system>
  <system n="2" facs="456">
    .... system 2 ....
  </system>
</staff>

Any ideas? Thoughts?

-Andrew



_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l


From kepper at edirom.de  Mon Feb  7 20:27:24 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 7 Feb 2011 20:27:24 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
Message-ID: <E2BA8DBE-62D5-413B-9495-C3DDDE31CE6F@edirom.de>

Hi Andrew,

actually MEI already covers both perspectives with the <body> branch (logical) and the <facsimile> branch (physical) inside <music>. I agree that this might be somewhat confusing, as you don't have the measure directly available inside a <surface> / page, and there is also no system break available here. I just wonder if improving the current solutions might not be sufficient, instead of creating a completely different structured model parallel to the existing solution. Possible improvements I see are:

- backlinks from <zone> to <measure> (<zone data="measureID"/>, could be other elements as well)
- typeable <zone> (<zone type="system"/>?)
- nestable <zone> (<zone type="system"><zone type="measure"/></zone>)

I think that those are really cheap additions, which don't change the complete model if MEI, but instead preserve the general distinction between graphical and logical perspective. Of course this is still not as convenient as a model solely commiting to the graphical aspects, but it fits better into the existing structures. 

Do you think that this direction might help to address your problem sufficiently?

Best,
Johannes





Am 07.02.2011 um 20:10 schrieb Roland, Perry (pdr4h):

> Hi Andrew,
> 
> You're absolutely right that <staff> attempts to capture the logical nature rather than the physical nature of staves.  <sb/> is of secondary importance in this approach.
> 
> However, Laurent and I have had several conversations about creating a page-oriented version of MEI.  I think this would address your needs as one of the major features of this approach would be a <system> element.  In other words, in this approach the physical layout would be primary.
> 
> 
> 
> I think turning the current schema "inside-outside" would be a good place to start; that is, the things that are empty now, such as <lb/> and <sb/> will end up being containers and some current container elements will end up being empty.  I think your suggestions a're definitely on the right track, but I'm reluctant to intermingle the logical-is-primary approach with the physical-is-primary method.  So, I think the choice will have to be mutually exclusive, implemented by switching on a page-oriented module.  The big question is, How many of the existing elements will have to make the empty <--> container switch?
> 
> 
> 
> Is this something we can take up after the next release in May?
> 
> 
> 
> --
> 
> 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: Monday, February 07, 2011 1:51 PM
> To: Music Encoding Initiative
> Subject: [MEI-L] Encoding staff positions
> 
> I'm currently trying to work out a method of encoding staff system positions on a page using MEI.
> 
> Let's assume that there is a single page of unmeasured music, with four systems on the page and I want to create a <zone> element for each system describing its layout.
> 
> Currently, the <staff> element seems to indicate a continuous line of music independent of its layout in systems, with the empty <sb /> element used to indicate a break in the system layout. This empty element has an @facs attribute, but I would be hesitant to encode spatial information with an empty element.
> 
> Before I go any further, can anyone think of something I'm missing? Any possible solutions?
> 
> If not, I can see two options.
> 
> The first is to create an element that is similar to the <span> element (call it "<mspan>"). This element would be a non-wrapping element that is generic and simply supplies a method of wrapping arbitrary information. This would be modelled after the use in the hOCR specification -- you can see an example here: http://code.google.com/p/hocr-tools/source/browse/sample.html
> 
> Thus, you might have:
> 
> <staff>
>  <mspan facs="123">
>        .... system 1 ....
>  </mspan>
>  <sb />
>  <mspan facs="456">
>        .... system 2 ....
>  </mspan>
>  <sb />
> </staff>
> 
> While the <mspan> element would be a pretty powerful addition, its semantic value is minimal. Thus, the other option might be to introduce an explicit <system> element that would be a child of the <staff> and function as an explicit wrapper for a system, in place of the empty <sb /> element; thus
> 
> <staff>
>  <system n="1" facs="123">
>    .... system 1 ....
>  </system>
>  <system n="2" facs="456">
>    .... system 2 ....
>  </system>
> </staff>
> 
> Any ideas? Thoughts?
> 
> -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



From pdr4h at eservices.virginia.edu  Mon Feb  7 20:50:16 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Mon, 7 Feb 2011 14:50:16 -0500
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <E2BA8DBE-62D5-413B-9495-C3DDDE31CE6F@edirom.de>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>,
	<E2BA8DBE-62D5-413B-9495-C3DDDE31CE6F@edirom.de>
Message-ID: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4F@MCCLANE.eservices.virginia.edu>

Yes, of course, if simpler measures (no pun intended) will do, then the page-oriented version won't be necessary.

- links from <zone> to <measure> is easily accomplished.

- <zone> has no type attribute, but it already has @n, which can be used for the same effect.

- I'm not sure what the advantage of nesting <zone> elements is and I'm afraid it may create more problems than it alleviates as users attempt to replicate the visual layout of the page using hierarchically-structured zones (better to leave the zones as a list where the coordinates of any zones may overlap).

--
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 Johannes Kepper [kepper at edirom.de]
Sent: Monday, February 07, 2011 2:27 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Encoding staff positions

Hi Andrew,

actually MEI already covers both perspectives with the <body> branch (logical) and the <facsimile> branch (physical) inside <music>. I agree that this might be somewhat confusing, as you don't have the measure directly available inside a <surface> / page, and there is also no system break available here. I just wonder if improving the current solutions might not be sufficient, instead of creating a completely different structured model parallel to the existing solution. Possible improvements I see are:

- backlinks from <zone> to <measure> (<zone data="measureID"/>, could be other elements as well)
- typeable <zone> (<zone type="system"/>?)
- nestable <zone> (<zone type="system"><zone type="measure"/></zone>)

I think that those are really cheap additions, which don't change the complete model if MEI, but instead preserve the general distinction between graphical and logical perspective. Of course this is still not as convenient as a model solely commiting to the graphical aspects, but it fits better into the existing structures.

Do you think that this direction might help to address your problem sufficiently?

Best,
Johannes





Am 07.02.2011 um 20:10 schrieb Roland, Perry (pdr4h):

> Hi Andrew,
>
> You're absolutely right that <staff> attempts to capture the logical nature rather than the physical nature of staves.  <sb/> is of secondary importance in this approach.
>
> However, Laurent and I have had several conversations about creating a page-oriented version of MEI.  I think this would address your needs as one of the major features of this approach would be a <system> element.  In other words, in this approach the physical layout would be primary.
>
>
>
> I think turning the current schema "inside-outside" would be a good place to start; that is, the things that are empty now, such as <lb/> and <sb/> will end up being containers and some current container elements will end up being empty.  I think your suggestions a're definitely on the right track, but I'm reluctant to intermingle the logical-is-primary approach with the physical-is-primary method.  So, I think the choice will have to be mutually exclusive, implemented by switching on a page-oriented module.  The big question is, How many of the existing elements will have to make the empty <--> container switch?
>
>
>
> Is this something we can take up after the next release in May?
>
>
>
> --
>
> 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: Monday, February 07, 2011 1:51 PM
> To: Music Encoding Initiative
> Subject: [MEI-L] Encoding staff positions
>
> I'm currently trying to work out a method of encoding staff system positions on a page using MEI.
>
> Let's assume that there is a single page of unmeasured music, with four systems on the page and I want to create a <zone> element for each system describing its layout.
>
> Currently, the <staff> element seems to indicate a continuous line of music independent of its layout in systems, with the empty <sb /> element used to indicate a break in the system layout. This empty element has an @facs attribute, but I would be hesitant to encode spatial information with an empty element.
>
> Before I go any further, can anyone think of something I'm missing? Any possible solutions?
>
> If not, I can see two options.
>
> The first is to create an element that is similar to the <span> element (call it "<mspan>"). This element would be a non-wrapping element that is generic and simply supplies a method of wrapping arbitrary information. This would be modelled after the use in the hOCR specification -- you can see an example here: http://code.google.com/p/hocr-tools/source/browse/sample.html
>
> Thus, you might have:
>
> <staff>
>  <mspan facs="123">
>        .... system 1 ....
>  </mspan>
>  <sb />
>  <mspan facs="456">
>        .... system 2 ....
>  </mspan>
>  <sb />
> </staff>
>
> While the <mspan> element would be a pretty powerful addition, its semantic value is minimal. Thus, the other option might be to introduce an explicit <system> element that would be a child of the <staff> and function as an explicit wrapper for a system, in place of the empty <sb /> element; thus
>
> <staff>
>  <system n="1" facs="123">
>    .... system 1 ....
>  </system>
>  <system n="2" facs="456">
>    .... system 2 ....
>  </system>
> </staff>
>
> Any ideas? Thoughts?
>
> -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

From andrew.hankinson at mail.mcgill.ca  Mon Feb  7 21:03:55 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Mon, 7 Feb 2011 15:03:55 -0500
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <20110207192733.B5181F44089@asmx4.McGill.CA>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
Message-ID: <30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>

Thanks Johannes,

I'm giving your proposal some thought.

One thing I am a bit unsure of is how "divorcing" the physical from the logical will impact us. I thought we would want to keep everything as contextual as possible, including system definitions. But now I'm re-thinking that approach.

I'm in the middle of implementing this, so I'll let you know how it goes!

-Andrew

On 2011-02-07, at 2:27 PM, Johannes Kepper wrote:

> Hi Andrew,
> 
> actually MEI already covers both perspectives with the <body> branch (logical) and the <facsimile> branch (physical) inside <music>. I agree that this might be somewhat confusing, as you don't have the measure directly available inside a <surface> / page, and there is also no system break available here. I just wonder if improving the current solutions might not be sufficient, instead of creating a completely different structured model parallel to the existing solution. Possible improvements I see are:
> 
> - backlinks from <zone> to <measure> (<zone data="measureID"/>, could be other elements as well)
> - typeable <zone> (<zone type="system"/>?)
> - nestable <zone> (<zone type="system"><zone type="measure"/></zone>)
> 
> I think that those are really cheap additions, which don't change the complete model if MEI, but instead preserve the general distinction between graphical and logical perspective. Of course this is still not as convenient as a model solely commiting to the graphical aspects, but it fits better into the existing structures. 
> 
> Do you think that this direction might help to address your problem sufficiently?
> 
> Best,
> Johannes
> 
> 
> 
> 
> 
> Am 07.02.2011 um 20:10 schrieb Roland, Perry (pdr4h):
> 
>> Hi Andrew,
>> 
>> You're absolutely right that <staff> attempts to capture the logical nature rather than the physical nature of staves.  <sb/> is of secondary importance in this approach.
>> 
>> However, Laurent and I have had several conversations about creating a page-oriented version of MEI.  I think this would address your needs as one of the major features of this approach would be a <system> element.  In other words, in this approach the physical layout would be primary.
>> 
>> 
>> 
>> I think turning the current schema "inside-outside" would be a good place to start; that is, the things that are empty now, such as <lb/> and <sb/> will end up being containers and some current container elements will end up being empty.  I think your suggestions a're definitely on the right track, but I'm reluctant to intermingle the logical-is-primary approach with the physical-is-primary method.  So, I think the choice will have to be mutually exclusive, implemented by switching on a page-oriented module.  The big question is, How many of the existing elements will have to make the empty <--> container switch?
>> 
>> 
>> 
>> Is this something we can take up after the next release in May?
>> 
>> 
>> 
>> --
>> 
>> 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: Monday, February 07, 2011 1:51 PM
>> To: Music Encoding Initiative
>> Subject: [MEI-L] Encoding staff positions
>> 
>> I'm currently trying to work out a method of encoding staff system positions on a page using MEI.
>> 
>> Let's assume that there is a single page of unmeasured music, with four systems on the page and I want to create a <zone> element for each system describing its layout.
>> 
>> Currently, the <staff> element seems to indicate a continuous line of music independent of its layout in systems, with the empty <sb /> element used to indicate a break in the system layout. This empty element has an @facs attribute, but I would be hesitant to encode spatial information with an empty element.
>> 
>> Before I go any further, can anyone think of something I'm missing? Any possible solutions?
>> 
>> If not, I can see two options.
>> 
>> The first is to create an element that is similar to the <span> element (call it "<mspan>"). This element would be a non-wrapping element that is generic and simply supplies a method of wrapping arbitrary information. This would be modelled after the use in the hOCR specification -- you can see an example here: http://code.google.com/p/hocr-tools/source/browse/sample.html
>> 
>> Thus, you might have:
>> 
>> <staff>
>> <mspan facs="123">
>>       .... system 1 ....
>> </mspan>
>> <sb />
>> <mspan facs="456">
>>       .... system 2 ....
>> </mspan>
>> <sb />
>> </staff>
>> 
>> While the <mspan> element would be a pretty powerful addition, its semantic value is minimal. Thus, the other option might be to introduce an explicit <system> element that would be a child of the <staff> and function as an explicit wrapper for a system, in place of the empty <sb /> element; thus
>> 
>> <staff>
>> <system n="1" facs="123">
>>   .... system 1 ....
>> </system>
>> <system n="2" facs="456">
>>   .... system 2 ....
>> </system>
>> </staff>
>> 
>> Any ideas? Thoughts?
>> 
>> -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



From kepper at edirom.de  Mon Feb  7 21:38:25 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 7 Feb 2011 21:38:25 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
Message-ID: <2053DF0F-4EEB-47CE-A16B-76AC96DE3DEE@edirom.de>

Hi Andrew,

it's the usual distinction between document and text, which sometimes helps and often does not. If you could arrange with this with small(er) changes to the schema, I would favor this solution. I'm a little bit anxious to introduce a completely different approach in MEI when not absolutely necessary. And although XML clearly favors one hierarchy, I think that milestones (like <sb/>) are an absolutely valid way to introduce a second (third?) hierarchy into the data. 

Good luck with your implementation, and I'm sure we're all happy to hear more from it.

Johannes





Am 07.02.2011 um 21:03 schrieb Andrew Hankinson, Mr:

> Thanks Johannes,
> 
> I'm giving your proposal some thought.
> 
> One thing I am a bit unsure of is how "divorcing" the physical from the logical will impact us. I thought we would want to keep everything as contextual as possible, including system definitions. But now I'm re-thinking that approach.
> 
> I'm in the middle of implementing this, so I'll let you know how it goes!
> 
> -Andrew
> 
> On 2011-02-07, at 2:27 PM, Johannes Kepper wrote:
> 
>> Hi Andrew,
>> 
>> actually MEI already covers both perspectives with the <body> branch (logical) and the <facsimile> branch (physical) inside <music>. I agree that this might be somewhat confusing, as you don't have the measure directly available inside a <surface> / page, and there is also no system break available here. I just wonder if improving the current solutions might not be sufficient, instead of creating a completely different structured model parallel to the existing solution. Possible improvements I see are:
>> 
>> - backlinks from <zone> to <measure> (<zone data="measureID"/>, could be other elements as well)
>> - typeable <zone> (<zone type="system"/>?)
>> - nestable <zone> (<zone type="system"><zone type="measure"/></zone>)
>> 
>> I think that those are really cheap additions, which don't change the complete model if MEI, but instead preserve the general distinction between graphical and logical perspective. Of course this is still not as convenient as a model solely commiting to the graphical aspects, but it fits better into the existing structures. 
>> 
>> Do you think that this direction might help to address your problem sufficiently?
>> 
>> Best,
>> Johannes
>> 
>> 
>> 
>> 
>> 
>> Am 07.02.2011 um 20:10 schrieb Roland, Perry (pdr4h):
>> 
>>> Hi Andrew,
>>> 
>>> You're absolutely right that <staff> attempts to capture the logical nature rather than the physical nature of staves.  <sb/> is of secondary importance in this approach.
>>> 
>>> However, Laurent and I have had several conversations about creating a page-oriented version of MEI.  I think this would address your needs as one of the major features of this approach would be a <system> element.  In other words, in this approach the physical layout would be primary.
>>> 
>>> 
>>> 
>>> I think turning the current schema "inside-outside" would be a good place to start; that is, the things that are empty now, such as <lb/> and <sb/> will end up being containers and some current container elements will end up being empty.  I think your suggestions a're definitely on the right track, but I'm reluctant to intermingle the logical-is-primary approach with the physical-is-primary method.  So, I think the choice will have to be mutually exclusive, implemented by switching on a page-oriented module.  The big question is, How many of the existing elements will have to make the empty <--> container switch?
>>> 
>>> 
>>> 
>>> Is this something we can take up after the next release in May?
>>> 
>>> 
>>> 
>>> --
>>> 
>>> 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: Monday, February 07, 2011 1:51 PM
>>> To: Music Encoding Initiative
>>> Subject: [MEI-L] Encoding staff positions
>>> 
>>> I'm currently trying to work out a method of encoding staff system positions on a page using MEI.
>>> 
>>> Let's assume that there is a single page of unmeasured music, with four systems on the page and I want to create a <zone> element for each system describing its layout.
>>> 
>>> Currently, the <staff> element seems to indicate a continuous line of music independent of its layout in systems, with the empty <sb /> element used to indicate a break in the system layout. This empty element has an @facs attribute, but I would be hesitant to encode spatial information with an empty element.
>>> 
>>> Before I go any further, can anyone think of something I'm missing? Any possible solutions?
>>> 
>>> If not, I can see two options.
>>> 
>>> The first is to create an element that is similar to the <span> element (call it "<mspan>"). This element would be a non-wrapping element that is generic and simply supplies a method of wrapping arbitrary information. This would be modelled after the use in the hOCR specification -- you can see an example here: http://code.google.com/p/hocr-tools/source/browse/sample.html
>>> 
>>> Thus, you might have:
>>> 
>>> <staff>
>>> <mspan facs="123">
>>>      .... system 1 ....
>>> </mspan>
>>> <sb />
>>> <mspan facs="456">
>>>      .... system 2 ....
>>> </mspan>
>>> <sb />
>>> </staff>
>>> 
>>> While the <mspan> element would be a pretty powerful addition, its semantic value is minimal. Thus, the other option might be to introduce an explicit <system> element that would be a child of the <staff> and function as an explicit wrapper for a system, in place of the empty <sb /> element; thus
>>> 
>>> <staff>
>>> <system n="1" facs="123">
>>>  .... system 1 ....
>>> </system>
>>> <system n="2" facs="456">
>>>  .... system 2 ....
>>> </system>
>>> </staff>
>>> 
>>> Any ideas? Thoughts?
>>> 
>>> -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



From kepper at edirom.de  Mon Feb  7 21:52:50 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 7 Feb 2011 21:52:50 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4F@MCCLANE.eservices.virginia.edu>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>,
	<E2BA8DBE-62D5-413B-9495-C3DDDE31CE6F@edirom.de>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4F@MCCLANE.eservices.virginia.edu>
Message-ID: <2419793F-8BEA-4AC0-BCC0-C3E4BF778726@edirom.de>

Perry,

> 
> - <zone> has no type attribute, but it already has @n, which can be used for the same effect.
> 

I think a @type is something different than @n. Using @n as replacement for a missing @type seems to be "attribute abuse". Either there's a reason why there is no @type (in which case using @n is obviously wrong), or we should introduce it (in which case using @n is unnecessary). Btw: Anyone else who thinks that @n should be xs:string instead of xs:NMTOKEN? Think of <mdiv n="Allegro moderato"/>?

> - I'm not sure what the advantage of nesting <zone> elements is and I'm afraid it may create more problems than it alleviates as users attempt to replicate the visual layout of the page using hierarchically-structured zones (better to leave the zones as a list where the coordinates of any zones may overlap).
> 

You're probably right, although it might be interesting to group zones somehow. Question is if a parent-zone must be a bounding box for all child-zones, or maybe if it even has to have coordinates? But I'm just thinking loud, I'm not yet convinced of anything. Any other arguments, wishes, opinions out there?

Johannes 

From raffaeleviglianti at gmail.com  Mon Feb  7 22:22:57 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Mon, 7 Feb 2011 21:22:57 +0000
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <2419793F-8BEA-4AC0-BCC0-C3E4BF778726@edirom.de>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<E2BA8DBE-62D5-413B-9495-C3DDDE31CE6F@edirom.de>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4F@MCCLANE.eservices.virginia.edu>
	<2419793F-8BEA-4AC0-BCC0-C3E4BF778726@edirom.de>
Message-ID: <AANLkTinVOnFDi0reM0qjTovLd+73Z9t7i5dwmdsWPZtW@mail.gmail.com>

Dear all,

The genetic encoding group within the Manuscript SIG of the TEI faced
similar issues. They came up with a new TEI module that takes a documentary
approach before a semantic one. It suggests to use the element ge:document
as an alternative to tei:text, the element that contains the semantic
tagging. They extend the model of tei:zone and introduce new elements like
ge:page (a non-empty element) and ge:line (non-empty), which simply marks a
line of text, regardless of its orientation. Attribute like @rotate and the
integration of SVG allow for the encoding of complex manuscript material.
Here is their current proposal:
http://www.tei-c.org/SIG/Manuscripts/genetic.html

<http://www.tei-c.org/SIG/Manuscripts/genetic.html>I think MEI could be
looking at using some of the concepts introduced here and possibly include
some of this TEI elements (possibly with their namespace) into a
document-oriented customization. Something like ge:line might not make sense
for MEI, though it might be used to model a mei:system.

Having a look at the work done by this group might shed some light on some
of the topics of this discussion.

Best wishes,
Raffaele

On Mon, Feb 7, 2011 at 8:52 PM, Johannes Kepper <kepper at edirom.de> wrote:

> Perry,
>
> >
> > - <zone> has no type attribute, but it already has @n, which can be used
> for the same effect.
> >
>
> I think a @type is something different than @n. Using @n as replacement for
> a missing @type seems to be "attribute abuse". Either there's a reason why
> there is no @type (in which case using @n is obviously wrong), or we should
> introduce it (in which case using @n is unnecessary). Btw: Anyone else who
> thinks that @n should be xs:string instead of xs:NMTOKEN? Think of <mdiv
> n="Allegro moderato"/>?
>
> > - I'm not sure what the advantage of nesting <zone> elements is and I'm
> afraid it may create more problems than it alleviates as users attempt to
> replicate the visual layout of the page using hierarchically-structured
> zones (better to leave the zones as a list where the coordinates of any
> zones may overlap).
> >
>
> You're probably right, although it might be interesting to group zones
> somehow. Question is if a parent-zone must be a bounding box for all
> child-zones, or maybe if it even has to have coordinates? But I'm just
> thinking loud, I'm not yet convinced of anything. Any other arguments,
> wishes, opinions out there?
>
> Johannes
> _______________________________________________
> 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/20110207/eed4ec02/attachment.htm>

From laurent at music.mcgill.ca  Mon Feb  7 22:43:10 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Mon, 7 Feb 2011 22:43:10 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
	<201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
Message-ID: <AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>

Hi all,

As Perry mentioned it, we already had conversations about adding the
opportunity to use another hierarchy depending one the goal being
pursued. The case given by Andrew a typical one where it would be much
easier with a page-oriented hierarchy. Of course, if things are well
organized, it should be possible to automatically change the
hierarchy. Nodes in the tree would become milestones (i.e. leafs), and
reverse. With reasonably complex cases, I don't see any reason why it
could not be lossless. So one might say, if we can encode it with the
current schema and just convert it to another hierarchy internally,
why would we need another way of encoding it?

If think that the first point is that being able to choose the most
appropriate hierarchy would make the encoding and the processing much
simpler. To some extend, it would not necessary be very different from
the score vs parts representations. And as for score and parts, it is
very ofter possible to go from one to the other, but not always, and
we could also have more complex cases where it would not be possible
to go back and forth between a page oriented and a score/parts
oriented representation.

One interesting thing to look at is the TEI module for genetic
editions, and for our discussion in particular points 1.3 (document
vs. text) and 3 (the document level)
http://www.tei-c.org/Activities/Council/Working/tcw19.html

It goes far beyond the simple example we are discussing here, and with
such complex cases being able to change the hierarchy without losing
anything seems very challenging. I am not sure we have to go so far,
but we should think about it because it would not necessary create
backward compatibility with the current schema. It would mainly make
it easier to use it when the goal is to encode a document with more
focus on the physical aspect of it.

Laurent


On Mon, Feb 7, 2011 at 9:38 PM, Johannes Kepper <kepper at edirom.de> wrote:
> Hi Andrew,
>
> it's the usual distinction between document and text, which sometimes helps and often does not. If you could arrange with this with small(er) changes to the schema, I would favor this solution. I'm a little bit anxious to introduce a completely different approach in MEI when not absolutely necessary. And although XML clearly favors one hierarchy, I think that milestones (like <sb/>) are an absolutely valid way to introduce a second (third?) hierarchy into the data.
>
> Good luck with your implementation, and I'm sure we're all happy to hear more from it.
>
> Johannes
>
>
>
>
>
> Am 07.02.2011 um 21:03 schrieb Andrew Hankinson, Mr:
>
>> Thanks Johannes,
>>
>> I'm giving your proposal some thought.
>>
>> One thing I am a bit unsure of is how "divorcing" the physical from the logical will impact us. I thought we would want to keep everything as contextual as possible, including system definitions. But now I'm re-thinking that approach.
>>
>> I'm in the middle of implementing this, so I'll let you know how it goes!
>>
>> -Andrew
>>
>> On 2011-02-07, at 2:27 PM, Johannes Kepper wrote:
>>
>>> Hi Andrew,
>>>
>>> actually MEI already covers both perspectives with the <body> branch (logical) and the <facsimile> branch (physical) inside <music>. I agree that this might be somewhat confusing, as you don't have the measure directly available inside a <surface> / page, and there is also no system break available here. I just wonder if improving the current solutions might not be sufficient, instead of creating a completely different structured model parallel to the existing solution. Possible improvements I see are:
>>>
>>> - backlinks from <zone> to <measure> (<zone data="measureID"/>, could be other elements as well)
>>> - typeable <zone> (<zone type="system"/>?)
>>> - nestable <zone> (<zone type="system"><zone type="measure"/></zone>)
>>>
>>> I think that those are really cheap additions, which don't change the complete model if MEI, but instead preserve the general distinction between graphical and logical perspective. Of course this is still not as convenient as a model solely commiting to the graphical aspects, but it fits better into the existing structures.
>>>
>>> Do you think that this direction might help to address your problem sufficiently?
>>>
>>> Best,
>>> Johannes
>>>
>>>
>>>
>>>
>>>
>>> Am 07.02.2011 um 20:10 schrieb Roland, Perry (pdr4h):
>>>
>>>> Hi Andrew,
>>>>
>>>> You're absolutely right that <staff> attempts to capture the logical nature rather than the physical nature of staves. ?<sb/> is of secondary importance in this approach.
>>>>
>>>> However, Laurent and I have had several conversations about creating a page-oriented version of MEI. ?I think this would address your needs as one of the major features of this approach would be a <system> element. ?In other words, in this approach the physical layout would be primary.
>>>>
>>>>
>>>>
>>>> I think turning the current schema "inside-outside" would be a good place to start; that is, the things that are empty now, such as <lb/> and <sb/> will end up being containers and some current container elements will end up being empty. ?I think your suggestions a're definitely on the right track, but I'm reluctant to intermingle the logical-is-primary approach with the physical-is-primary method. ?So, I think the choice will have to be mutually exclusive, implemented by switching on a page-oriented module. ?The big question is, How many of the existing elements will have to make the empty <--> container switch?
>>>>
>>>>
>>>>
>>>> Is this something we can take up after the next release in May?
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> 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: Monday, February 07, 2011 1:51 PM
>>>> To: Music Encoding Initiative
>>>> Subject: [MEI-L] Encoding staff positions
>>>>
>>>> I'm currently trying to work out a method of encoding staff system positions on a page using MEI.
>>>>
>>>> Let's assume that there is a single page of unmeasured music, with four systems on the page and I want to create a <zone> element for each system describing its layout.
>>>>
>>>> Currently, the <staff> element seems to indicate a continuous line of music independent of its layout in systems, with the empty <sb /> element used to indicate a break in the system layout. This empty element has an @facs attribute, but I would be hesitant to encode spatial information with an empty element.
>>>>
>>>> Before I go any further, can anyone think of something I'm missing? Any possible solutions?
>>>>
>>>> If not, I can see two options.
>>>>
>>>> The first is to create an element that is similar to the <span> element (call it "<mspan>"). This element would be a non-wrapping element that is generic and simply supplies a method of wrapping arbitrary information. This would be modelled after the use in the hOCR specification -- you can see an example here: http://code.google.com/p/hocr-tools/source/browse/sample.html
>>>>
>>>> Thus, you might have:
>>>>
>>>> <staff>
>>>> <mspan facs="123">
>>>> ? ? ?.... system 1 ....
>>>> </mspan>
>>>> <sb />
>>>> <mspan facs="456">
>>>> ? ? ?.... system 2 ....
>>>> </mspan>
>>>> <sb />
>>>> </staff>
>>>>
>>>> While the <mspan> element would be a pretty powerful addition, its semantic value is minimal. Thus, the other option might be to introduce an explicit <system> element that would be a child of the <staff> and function as an explicit wrapper for a system, in place of the empty <sb /> element; thus
>>>>
>>>> <staff>
>>>> <system n="1" facs="123">
>>>> ?.... system 1 ....
>>>> </system>
>>>> <system n="2" facs="456">
>>>> ?.... system 2 ....
>>>> </system>
>>>> </staff>
>>>>
>>>> Any ideas? Thoughts?
>>>>
>>>> -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
>
>


From kepper at edirom.de  Mon Feb  7 22:53:16 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 7 Feb 2011 22:53:16 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
	<201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
	<AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>
Message-ID: <3FC2331D-3F58-4510-AD48-F9CF16CF0888@edirom.de>

Hi again,

I agree that TEI's genetic encoding approach is something we should try to combine with MEI, but as Raffaele suggested, we should try to (re)use their namespace as much as possible. This thing is definitely designed for more complicated situations than most of us will encounter on a daily basis. For me, the main question is if there is a need for a smaller solution within MEI's namespace that addresses something like 80% of the situations out there. It's just like <zone> vs. SVG: Simple solution within the format vs. mighty solution by including something else. The only problem then is to find where those 80% might end, and what is needed to get there?




Am 07.02.2011 um 22:43 schrieb Laurent Pugin:

> Hi all,
> 
> As Perry mentioned it, we already had conversations about adding the
> opportunity to use another hierarchy depending one the goal being
> pursued. The case given by Andrew a typical one where it would be much
> easier with a page-oriented hierarchy. Of course, if things are well
> organized, it should be possible to automatically change the
> hierarchy. Nodes in the tree would become milestones (i.e. leafs), and
> reverse. With reasonably complex cases, I don't see any reason why it
> could not be lossless. So one might say, if we can encode it with the
> current schema and just convert it to another hierarchy internally,
> why would we need another way of encoding it?
> 
> If think that the first point is that being able to choose the most
> appropriate hierarchy would make the encoding and the processing much
> simpler. To some extend, it would not necessary be very different from
> the score vs parts representations. And as for score and parts, it is
> very ofter possible to go from one to the other, but not always, and
> we could also have more complex cases where it would not be possible
> to go back and forth between a page oriented and a score/parts
> oriented representation.
> 
> One interesting thing to look at is the TEI module for genetic
> editions, and for our discussion in particular points 1.3 (document
> vs. text) and 3 (the document level)
> http://www.tei-c.org/Activities/Council/Working/tcw19.html
> 
> It goes far beyond the simple example we are discussing here, and with
> such complex cases being able to change the hierarchy without losing
> anything seems very challenging. I am not sure we have to go so far,
> but we should think about it because it would not necessary create
> backward compatibility with the current schema. It would mainly make
> it easier to use it when the goal is to encode a document with more
> focus on the physical aspect of it.



From laurent at music.mcgill.ca  Tue Feb  8 09:15:18 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Tue, 8 Feb 2011 09:15:18 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <201102072201.p17M11kA001106@drizzle.cc.mcgill.ca>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
	<201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
	<AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>
	<201102072201.p17M11kA001106@drizzle.cc.mcgill.ca>
Message-ID: <AANLkTi=uSwx7YmqyEPRV_6-HJhML7yLifc7M7fgrkYyM@mail.gmail.com>

Hi,

yes, I agree that the cases described by the genetic encoding group
are rather extreme ones for which the best thing to do for music would
probably be to use MEI within TEI together with the GE module.

It should not preclude us to improve MEI itself for the 80% of the
situations, and I also agree the it can be a 'small' solution. My
impression is that with <pb> and <sb> becoming <page> and <system>, we
would have pretty much everything we need for the new hierarchy.
Inside it, the sub-tree is likely to stay the same, but some
containing elements (such as <measure>) would definitely have to
become milestones. That is the big question, as Perry said, but if
they are not too many of them, I see it as a small solution that would
do it.

In my opinion, it can be useful to capture the original source at the
very beginning of an editorial process, but it could also be useful at
the end of the process. If we think of the case where MEI is used to
encode a new edition, this feature could also make it easier to encode
its layout and to represent it. If we have an orchestra score with,
let's say, hundreds of pages, turning a page would require every time
the entire tree to be parsed to get all the <pb> and all the <sb>. I
know software issues are not the starting point when defining an
encoding, but this is seriously not optimal. Why shouldn't I have to
option to have the encoding in a page-oriented way when the edition
reached a publishing stage? And maybe to add some more detailed layout
information for making it easier to read? I don't know, it is just one
way I see to use MEI.

Laurent

On Mon, Feb 7, 2011 at 10:53 PM, Johannes Kepper <kepper at edirom.de> wrote:
> Hi again,
>
> I agree that TEI's genetic encoding approach is something we should try to combine with MEI, but as Raffaele suggested, we should try to (re)use their namespace as much as possible. This thing is definitely designed for more complicated situations than most of us will encounter on a daily basis. For me, the main question is if there is a need for a smaller solution within MEI's namespace that addresses something like 80% of the situations out there. It's just like <zone> vs. SVG: Simple solution within the format vs. mighty solution by including something else. The only problem then is to find where those 80% might end, and what is needed to get there?
>
>
>
>
> Am 07.02.2011 um 22:43 schrieb Laurent Pugin:
>
>> Hi all,
>>
>> As Perry mentioned it, we already had conversations about adding the
>> opportunity to use another hierarchy depending one the goal being
>> pursued. The case given by Andrew a typical one where it would be much
>> easier with a page-oriented hierarchy. Of course, if things are well
>> organized, it should be possible to automatically change the
>> hierarchy. Nodes in the tree would become milestones (i.e. leafs), and
>> reverse. With reasonably complex cases, I don't see any reason why it
>> could not be lossless. So one might say, if we can encode it with the
>> current schema and just convert it to another hierarchy internally,
>> why would we need another way of encoding it?
>>
>> If think that the first point is that being able to choose the most
>> appropriate hierarchy would make the encoding and the processing much
>> simpler. To some extend, it would not necessary be very different from
>> the score vs parts representations. And as for score and parts, it is
>> very ofter possible to go from one to the other, but not always, and
>> we could also have more complex cases where it would not be possible
>> to go back and forth between a page oriented and a score/parts
>> oriented representation.
>>
>> One interesting thing to look at is the TEI module for genetic
>> editions, and for our discussion in particular points 1.3 (document
>> vs. text) and 3 (the document level)
>> http://www.tei-c.org/Activities/Council/Working/tcw19.html
>>
>> It goes far beyond the simple example we are discussing here, and with
>> such complex cases being able to change the hierarchy without losing
>> anything seems very challenging. I am not sure we have to go so far,
>> but we should think about it because it would not necessary create
>> backward compatibility with the current schema. It would mainly make
>> it easier to use it when the goal is to encode a document with more
>> focus on the physical aspect of it.
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>


From kepper at edirom.de  Tue Feb  8 09:36:20 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Tue, 8 Feb 2011 09:36:20 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <AANLkTi=uSwx7YmqyEPRV_6-HJhML7yLifc7M7fgrkYyM@mail.gmail.com>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
	<201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
	<AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>
	<201102072201.p17M11kA001106@drizzle.cc.mcgill.ca>
	<AANLkTi=uSwx7YmqyEPRV_6-HJhML7yLifc7M7fgrkYyM@mail.gmail.com>
Message-ID: <6415D944-9935-47F5-A97D-55F3B7858269@edirom.de>

Hi Laurent,


Am 08.02.2011 um 09:15 schrieb Laurent Pugin:

> Hi,
> 
> yes, I agree that the cases described by the genetic encoding group
> are rather extreme ones for which the best thing to do for music would
> probably be to use MEI within TEI together with the GE module.

I would even try to integrate it without TEI in the middle, but that's something for a long and lonely evening?

> 
> It should not preclude us to improve MEI itself for the 80% of the
> situations, and I also agree the it can be a 'small' solution. My
> impression is that with <pb> and <sb> becoming <page> and <system>, we
> would have pretty much everything we need for the new hierarchy.
> Inside it, the sub-tree is likely to stay the same, but some
> containing elements (such as <measure>) would definitely have to
> become milestones. That is the big question, as Perry said, but if
> they are not too many of them, I see it as a small solution that would
> do it.

You already can use <barline> instead of <measure>. Not sure if this buys you anything, but maybe it's worth to think over. 

> 
> In my opinion, it can be useful to capture the original source at the
> very beginning of an editorial process, but it could also be useful at
> the end of the process. If we think of the case where MEI is used to
> encode a new edition, this feature could also make it easier to encode
> its layout and to represent it. If we have an orchestra score with,
> let's say, hundreds of pages, turning a page would require every time
> the entire tree to be parsed to get all the <pb> and all the <sb>. I
> know software issues are not the starting point when defining an
> encoding, but this is seriously not optimal. Why shouldn't I have to
> option to have the encoding in a page-oriented way when the edition
> reached a publishing stage? And maybe to add some more detailed layout
> information for making it easier to read? I don't know, it is just one
> way I see to use MEI.
> 

I see your problem, and maybe you're right with this. In Edirom's internal data model we chose a different approach. We always have a double structure inside a source: One perspective is source/movements/measures, the other is source/pages/measures. The logical structure is our main structure, where all objects are actually stored. The page structure contains only pointers to those elements. Of course this produces some overhead, but you may extract it easily from MEI, and you have the best of both approaches all the time. I cannot tell if this is a model for Andrew or you, but it helps us a lot. 


Honestly, I don't want to cut this idea short, I'm just somewhat reluctant to introduce another tree possibility. <parts><part> and <score> is something different to me, as they behave absolutely similar below this level. 

Johannes




> Laurent
> 
> On Mon, Feb 7, 2011 at 10:53 PM, Johannes Kepper <kepper at edirom.de> wrote:
>> Hi again,
>> 
>> I agree that TEI's genetic encoding approach is something we should try to combine with MEI, but as Raffaele suggested, we should try to (re)use their namespace as much as possible. This thing is definitely designed for more complicated situations than most of us will encounter on a daily basis. For me, the main question is if there is a need for a smaller solution within MEI's namespace that addresses something like 80% of the situations out there. It's just like <zone> vs. SVG: Simple solution within the format vs. mighty solution by including something else. The only problem then is to find where those 80% might end, and what is needed to get there?
>> 
>> 
>> 
>> 
>> Am 07.02.2011 um 22:43 schrieb Laurent Pugin:
>> 
>>> Hi all,
>>> 
>>> As Perry mentioned it, we already had conversations about adding the
>>> opportunity to use another hierarchy depending one the goal being
>>> pursued. The case given by Andrew a typical one where it would be much
>>> easier with a page-oriented hierarchy. Of course, if things are well
>>> organized, it should be possible to automatically change the
>>> hierarchy. Nodes in the tree would become milestones (i.e. leafs), and
>>> reverse. With reasonably complex cases, I don't see any reason why it
>>> could not be lossless. So one might say, if we can encode it with the
>>> current schema and just convert it to another hierarchy internally,
>>> why would we need another way of encoding it?
>>> 
>>> If think that the first point is that being able to choose the most
>>> appropriate hierarchy would make the encoding and the processing much
>>> simpler. To some extend, it would not necessary be very different from
>>> the score vs parts representations. And as for score and parts, it is
>>> very ofter possible to go from one to the other, but not always, and
>>> we could also have more complex cases where it would not be possible
>>> to go back and forth between a page oriented and a score/parts
>>> oriented representation.
>>> 
>>> One interesting thing to look at is the TEI module for genetic
>>> editions, and for our discussion in particular points 1.3 (document
>>> vs. text) and 3 (the document level)
>>> http://www.tei-c.org/Activities/Council/Working/tcw19.html
>>> 
>>> It goes far beyond the simple example we are discussing here, and with
>>> such complex cases being able to change the hierarchy without losing
>>> anything seems very challenging. I am not sure we have to go so far,
>>> but we should think about it because it would not necessary create
>>> backward compatibility with the current schema. It would mainly make
>>> it easier to use it when the goal is to encode a document with more
>>> focus on the physical aspect of it.
>> 
>> 
>> _______________________________________________
>> 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



From laurent at music.mcgill.ca  Tue Feb  8 14:24:48 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Tue, 8 Feb 2011 14:24:48 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <201102080841.p188f1PU008998@torrent.cc.mcgill.ca>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
	<201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
	<AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>
	<201102072201.p17M11kA001106@drizzle.cc.mcgill.ca>
	<AANLkTi=uSwx7YmqyEPRV_6-HJhML7yLifc7M7fgrkYyM@mail.gmail.com>
	<201102080841.p188f1PU008998@torrent.cc.mcgill.ca>
Message-ID: <AANLkTikMO_-3FWv1Sn7VdQBup9mC6XNhdh0CyjtZOQOC@mail.gmail.com>

Hi Johannes,

On Tue, Feb 8, 2011 at 9:36 AM, Johannes Kepper <kepper at edirom.de> wrote:
> Hi Laurent,
>
>
> Am 08.02.2011 um 09:15 schrieb Laurent Pugin:
>
>> Hi,
>>
>> yes, I agree that the cases described by the genetic encoding group
>> are rather extreme ones for which the best thing to do for music would
>> probably be to use MEI within TEI together with the GE module.
>
> I would even try to integrate it without TEI in the middle, but that's something for a long and lonely evening?
>

Yes, you are right.

>>
>> It should not preclude us to improve MEI itself for the 80% of the
>> situations, and I also agree the it can be a 'small' solution. My
>> impression is that with <pb> and <sb> becoming <page> and <system>, we
>> would have pretty much everything we need for the new hierarchy.
>> Inside it, the sub-tree is likely to stay the same, but some
>> containing elements (such as <measure>) would definitely have to
>> become milestones. That is the big question, as Perry said, but if
>> they are not too many of them, I see it as a small solution that would
>> do it.
>
> You already can use <barline> instead of <measure>. Not sure if this buys you anything, but maybe it's worth to think over.
>

Thanks for the tip. I forgot about that one, it should do it.

>>
>> In my opinion, it can be useful to capture the original source at the
>> very beginning of an editorial process, but it could also be useful at
>> the end of the process. If we think of the case where MEI is used to
>> encode a new edition, this feature could also make it easier to encode
>> its layout and to represent it. If we have an orchestra score with,
>> let's say, hundreds of pages, turning a page would require every time
>> the entire tree to be parsed to get all the <pb> and all the <sb>. I
>> know software issues are not the starting point when defining an
>> encoding, but this is seriously not optimal. Why shouldn't I have to
>> option to have the encoding in a page-oriented way when the edition
>> reached a publishing stage? And maybe to add some more detailed layout
>> information for making it easier to read? I don't know, it is just one
>> way I see to use MEI.
>>
>
> I see your problem, and maybe you're right with this. In Edirom's internal data model we chose a different approach. We always have a double structure inside a source: One perspective is source/movements/measures, the other is source/pages/measures. The logical structure is our main structure, where all objects are actually stored. The page structure contains only pointers to those elements. Of course this produces some overhead, but you may extract it easily from MEI, and you have the best of both approaches all the time. I cannot tell if this is a model for Andrew or you, but it helps us a lot.
>
>

Your solution is an excellent one to get both at the same time, which
is of course ideal. It is a elegant workaround to keep both in memory
in order to avoid to have to re-parse the tree every single time you
need to access something that is spread over several branches in the
hierarchy. But if you think of a large repository of MEI files from
which you want to quickly access specific pages over the web, you
would need another solution. Something built in MEI would be nice.

Your case also illustrates the fact that, in many applications, having
access to both representations is necessary. You choose as main
structure the one that is the most relevant for you. In some cases, it
can be the other one, and in some cases, only one is necessary. If I
just want to generate a midi file, the logical representation is
enough (and better), but if I just want to display a page, it is the
opposite. So if we can get a good page-oriented representation, with
maybe a stylesheet to go from one to the other (at least for not too
complicated cases), I see it as a way to avoid people to have to do it
internally for each single piece of software that needs it.

> Honestly, I don't want to cut this idea short, I'm just somewhat reluctant to introduce another tree possibility. <parts><part> and <score> is something different to me, as they behave absolutely similar below this level.

Yes, it is not the exactly the same, I agree.

Laurent

>
> Johannes
>
>
>
>
>> Laurent
>>
>> On Mon, Feb 7, 2011 at 10:53 PM, Johannes Kepper <kepper at edirom.de> wrote:
>>> Hi again,
>>>
>>> I agree that TEI's genetic encoding approach is something we should try to combine with MEI, but as Raffaele suggested, we should try to (re)use their namespace as much as possible. This thing is definitely designed for more complicated situations than most of us will encounter on a daily basis. For me, the main question is if there is a need for a smaller solution within MEI's namespace that addresses something like 80% of the situations out there. It's just like <zone> vs. SVG: Simple solution within the format vs. mighty solution by including something else. The only problem then is to find where those 80% might end, and what is needed to get there?
>>>
>>>
>>>
>>>
>>> Am 07.02.2011 um 22:43 schrieb Laurent Pugin:
>>>
>>>> Hi all,
>>>>
>>>> As Perry mentioned it, we already had conversations about adding the
>>>> opportunity to use another hierarchy depending one the goal being
>>>> pursued. The case given by Andrew a typical one where it would be much
>>>> easier with a page-oriented hierarchy. Of course, if things are well
>>>> organized, it should be possible to automatically change the
>>>> hierarchy. Nodes in the tree would become milestones (i.e. leafs), and
>>>> reverse. With reasonably complex cases, I don't see any reason why it
>>>> could not be lossless. So one might say, if we can encode it with the
>>>> current schema and just convert it to another hierarchy internally,
>>>> why would we need another way of encoding it?
>>>>
>>>> If think that the first point is that being able to choose the most
>>>> appropriate hierarchy would make the encoding and the processing much
>>>> simpler. To some extend, it would not necessary be very different from
>>>> the score vs parts representations. And as for score and parts, it is
>>>> very ofter possible to go from one to the other, but not always, and
>>>> we could also have more complex cases where it would not be possible
>>>> to go back and forth between a page oriented and a score/parts
>>>> oriented representation.
>>>>
>>>> One interesting thing to look at is the TEI module for genetic
>>>> editions, and for our discussion in particular points 1.3 (document
>>>> vs. text) and 3 (the document level)
>>>> http://www.tei-c.org/Activities/Council/Working/tcw19.html
>>>>
>>>> It goes far beyond the simple example we are discussing here, and with
>>>> such complex cases being able to change the hierarchy without losing
>>>> anything seems very challenging. I am not sure we have to go so far,
>>>> but we should think about it because it would not necessary create
>>>> backward compatibility with the current schema. It would mainly make
>>>> it easier to use it when the goal is to encode a document with more
>>>> focus on the physical aspect of it.
>>>
>>>
>>> _______________________________________________
>>> 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
>
>


From kepper at edirom.de  Tue Feb  8 20:38:26 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Tue, 8 Feb 2011 20:38:26 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <AANLkTikMO_-3FWv1Sn7VdQBup9mC6XNhdh0CyjtZOQOC@mail.gmail.com>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
	<201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
	<AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>
	<201102072201.p17M11kA001106@drizzle.cc.mcgill.ca>
	<AANLkTi=uSwx7YmqyEPRV_6-HJhML7yLifc7M7fgrkYyM@mail.gmail.com>
	<201102080841.p188f1PU008998@torrent.cc.mcgill.ca>
	<AANLkTikMO_-3FWv1Sn7VdQBup9mC6XNhdh0CyjtZOQOC@mail.gmail.com>
Message-ID: <37F6E443-DAC6-4429-A466-42276974395A@edirom.de>


Am 08.02.2011 um 14:24 schrieb Laurent Pugin:
> 
> 
>>> 
>>> In my opinion, it can be useful to capture the original source at the
>>> very beginning of an editorial process, but it could also be useful at
>>> the end of the process. If we think of the case where MEI is used to
>>> encode a new edition, this feature could also make it easier to encode
>>> its layout and to represent it. If we have an orchestra score with,
>>> let's say, hundreds of pages, turning a page would require every time
>>> the entire tree to be parsed to get all the <pb> and all the <sb>. I
>>> know software issues are not the starting point when defining an
>>> encoding, but this is seriously not optimal. Why shouldn't I have to
>>> option to have the encoding in a page-oriented way when the edition
>>> reached a publishing stage? And maybe to add some more detailed layout
>>> information for making it easier to read? I don't know, it is just one
>>> way I see to use MEI.
>>> 
>> 
>> I see your problem, and maybe you're right with this. In Edirom's internal data model we chose a different approach. We always have a double structure inside a source: One perspective is source/movements/measures, the other is source/pages/measures. The logical structure is our main structure, where all objects are actually stored. The page structure contains only pointers to those elements. Of course this produces some overhead, but you may extract it easily from MEI, and you have the best of both approaches all the time. I cannot tell if this is a model for Andrew or you, but it helps us a lot.
>> 
>> 
> 
> Your solution is an excellent one to get both at the same time, which
> is of course ideal. It is a elegant workaround to keep both in memory
> in order to avoid to have to re-parse the tree every single time you
> need to access something that is spread over several branches in the
> hierarchy. But if you think of a large repository of MEI files from
> which you want to quickly access specific pages over the web, you
> would need another solution. Something built in MEI would be nice.
> 

But of course you wouldn't keep the whole repository in memory / your local data model. Using xquery on an eXist database for example, you can get a page that holds a given measure in a couple of milliseconds, especially since MEI's switch to xml:id. But you're right, the overhead we produce slows us down significantly. On a medium size piece of music (a total of ~ 2000 measures in 5 different sources), we experienced a slowdown by the factor of 10 to build our second hierarchy (looping through all zones, looping through all measures to find the right @facs). We still have acceptable loading times, but one of our first improvements to MEI will be the already mentioned backlink from zone to measure ? it will reduce the slowdown to the factor 2, which seems fair regarding the fact that we build two hierarchies? I see no reason why it shouldn't be possible to extract solely a page-oriented structure in time n with this addition to MEI. But of course, if you don't have a local data model and work on the xml directly, you always have an extra IDREF to follow. But as long as you keep //zone[@type eq 'measure'] in the same order as the measures appear logically on that page, it shouldn't be too expensive. 


> Your case also illustrates the fact that, in many applications, having
> access to both representations is necessary. You choose as main
> structure the one that is the most relevant for you. In some cases, it
> can be the other one, and in some cases, only one is necessary. If I
> just want to generate a midi file, the logical representation is
> enough (and better), but if I just want to display a page, it is the
> opposite. So if we can get a good page-oriented representation, with
> maybe a stylesheet to go from one to the other (at least for not too
> complicated cases), I see it as a way to avoid people to have to do it
> internally for each single piece of software that needs it.

What about a compromise? I'm still against adding a second, equally possible format design to MEI. Looking at MusicXML's timewise vs. partwise, which is definitely a less complicated problem, I'm afraid that we will run into lots of problems. One of the more disturbing is clearly the increased cost to learn MEI, as you have to make a decision on how to use it quite early in the encoding process. But, what if we use the benefits we gain from ODD? I could imagine an official variation of MEI that redesigns it in that particular way (<pb/> to <page>?</page and so on). Such a modification could be provided on the website, and the XSLTs you mentioned could be there as well. This way, we would keep the solution out of the "official" MEI design, but we could offer a standardized, well-documented proposal on how to deal with MEI in page-oriented projects. Programmers could take this over and adjust it to their applications without having to do the complete work on their own. I could see that as a solution for your problem, and at the same time it would be a great way to exemplify the benefits of ODD for MEI. So how about that?

Johannes



> 
>> Honestly, I don't want to cut this idea short, I'm just somewhat reluctant to introduce another tree possibility. <parts><part> and <score> is something different to me, as they behave absolutely similar below this level.
> 
> Yes, it is not the exactly the same, I agree.
> 
> Laurent



From pdr4h at eservices.virginia.edu  Tue Feb  8 21:28:41 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Tue, 8 Feb 2011 15:28:41 -0500
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <37F6E443-DAC6-4429-A466-42276974395A@edirom.de>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
	<201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
	<AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>
	<201102072201.p17M11kA001106@drizzle.cc.mcgill.ca>
	<AANLkTi=uSwx7YmqyEPRV_6-HJhML7yLifc7M7fgrkYyM@mail.gmail.com>
	<201102080841.p188f1PU008998@torrent.cc.mcgill.ca>
	<AANLkTikMO_-3FWv1Sn7VdQBup9mC6XNhdh0CyjtZOQOC@mail.gmail.com>,
	<37F6E443-DAC6-4429-A466-42276974395A@edirom.de>
Message-ID: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC56@MCCLANE.eservices.virginia.edu>

Johannes, everyone,

I don't see the real distinction between offering an "official varation" and a "second, equally possible format design to MEI."  To me, it's either officially sanctioned, or not.  If it's not, then it shouldn't be provided.  If it is officially sanctioned, then it must be documented and supported.

I agree that if we decide to create such a customization, then the amount of change is best kept to the minimum that accomplishes the task.

--
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+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Johannes Kepper [kepper at edirom.de]
Sent: Tuesday, February 08, 2011 2:38 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Encoding staff positions

Am 08.02.2011 um 14:24 schrieb Laurent Pugin:
>
>
>>>
>>> In my opinion, it can be useful to capture the original source at the
>>> very beginning of an editorial process, but it could also be useful at
>>> the end of the process. If we think of the case where MEI is used to
>>> encode a new edition, this feature could also make it easier to encode
>>> its layout and to represent it. If we have an orchestra score with,
>>> let's say, hundreds of pages, turning a page would require every time
>>> the entire tree to be parsed to get all the <pb> and all the <sb>. I
>>> know software issues are not the starting point when defining an
>>> encoding, but this is seriously not optimal. Why shouldn't I have to
>>> option to have the encoding in a page-oriented way when the edition
>>> reached a publishing stage? And maybe to add some more detailed layout
>>> information for making it easier to read? I don't know, it is just one
>>> way I see to use MEI.
>>>
>>
>> I see your problem, and maybe you're right with this. In Edirom's internal data model we chose a different approach. We always have a double structure inside a source: One perspective is source/movements/measures, the other is source/pages/measures. The logical structure is our main structure, where all objects are actually stored. The page structure contains only pointers to those elements. Of course this produces some overhead, but you may extract it easily from MEI, and you have the best of both approaches all the time. I cannot tell if this is a model for Andrew or you, but it helps us a lot.
>>
>>
>
> Your solution is an excellent one to get both at the same time, which
> is of course ideal. It is a elegant workaround to keep both in memory
> in order to avoid to have to re-parse the tree every single time you
> need to access something that is spread over several branches in the
> hierarchy. But if you think of a large repository of MEI files from
> which you want to quickly access specific pages over the web, you
> would need another solution. Something built in MEI would be nice.
>

But of course you wouldn't keep the whole repository in memory / your local data model. Using xquery on an eXist database for example, you can get a page that holds a given measure in a couple of milliseconds, especially since MEI's switch to xml:id. But you're right, the overhead we produce slows us down significantly. On a medium size piece of music (a total of ~ 2000 measures in 5 different sources), we experienced a slowdown by the factor of 10 to build our second hierarchy (looping through all zones, looping through all measures to find the right @facs). We still have acceptable loading times, but one of our first improvements to MEI will be the already mentioned backlink from zone to measure ? it will reduce the slowdown to the factor 2, which seems fair regarding the fact that we build two hierarchies? I see no reason why it shouldn't be possible to extract solely a page-oriented structure in time n with this addition to MEI. But of course, if you don't have a local data model and work on the xml directly, you always have an extra IDREF to follow. But as long as you keep //zone[@type eq 'measure'] in the same order as the measures appear logically on that page, it shouldn't be too expensive.


> Your case also illustrates the fact that, in many applications, having
> access to both representations is necessary. You choose as main
> structure the one that is the most relevant for you. In some cases, it
> can be the other one, and in some cases, only one is necessary. If I
> just want to generate a midi file, the logical representation is
> enough (and better), but if I just want to display a page, it is the
> opposite. So if we can get a good page-oriented representation, with
> maybe a stylesheet to go from one to the other (at least for not too
> complicated cases), I see it as a way to avoid people to have to do it
> internally for each single piece of software that needs it.

What about a compromise? I'm still against adding a second, equally possible format design to MEI. Looking at MusicXML's timewise vs. partwise, which is definitely a less complicated problem, I'm afraid that we will run into lots of problems. One of the more disturbing is clearly the increased cost to learn MEI, as you have to make a decision on how to use it quite early in the encoding process. But, what if we use the benefits we gain from ODD? I could imagine an official variation of MEI that redesigns it in that particular way (<pb/> to <page>?</page and so on). Such a modification could be provided on the website, and the XSLTs you mentioned could be there as well. This way, we would keep the solution out of the "official" MEI design, but we could offer a standardized, well-documented proposal on how to deal with MEI in page-oriented projects. Programmers could take this over and adjust it to their applications without having to do the complete work on their own. I could see that as a solution for your problem, and at the same time it would be a great way to exemplify the benefits of ODD for MEI. So how about that?

Johannes



>
>> Honestly, I don't want to cut this idea short, I'm just somewhat reluctant to introduce another tree possibility. <parts><part> and <score> is something different to me, as they behave absolutely similar below this level.
>
> Yes, it is not the exactly the same, I agree.
>
> Laurent


_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

From kepper at edirom.de  Tue Feb  8 22:03:04 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Tue, 8 Feb 2011 22:03:04 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC56@MCCLANE.eservices.virginia.edu>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
	<201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
	<AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>
	<201102072201.p17M11kA001106@drizzle.cc.mcgill.ca>
	<AANLkTi=uSwx7YmqyEPRV_6-HJhML7yLifc7M7fgrkYyM@mail.gmail.com>
	<201102080841.p188f1PU008998@torrent.cc.mcgill.ca>
	<AANLkTikMO_-3FWv1Sn7VdQBup9mC6XNhdh0CyjtZOQOC@mail.gmail.com>,
	<37F6E443-DAC6-4429-A466-42276974395A@edirom.de>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC56@MCCLANE.eservices.virginia.edu>
Message-ID: <BAD7CF50-EF10-4D99-AEF0-5B89FFB8F00C@edirom.de>


Am 08.02.2011 um 21:28 schrieb Roland, Perry (pdr4h):

> Johannes, everyone,
> 
> I don't see the real distinction between offering an "official varation" and a "second, equally possible format design to MEI."  To me, it's either officially sanctioned, or not.  If it's not, then it shouldn't be provided.  If it is officially sanctioned, then it must be documented and supported.

I have no real example from the TEI, but maybe it's something like TEI all vs. TEI Tite. TEI Tite contains elements which aren't in TEI all, but which can be mapped to canonical TEI. TEI Tite is offered and documented by the Council, but it's not canonical TEI, it's built for a certain, well-defined purpose. I would like to keep this out of the regular tag library, but instead offer it on a separate customizations page, perhaps with its own tag library (should be easy to extract from the ODD). That way it is clear that it's not canonical MEI, but a specialized version of it. I expect this to help newbies distinguish which MEI is best for them. It remains clear that there is one basic format design approach behind MEI, not an arbitrary number of them. But of course, I'd still prefer to address the whole issue with a small solution within the current scheme, if this could solve all of Andrew's and Laurent's problems?

Johannes


> 
> I agree that if we decide to create such a customization, then the amount of change is best kept to the minimum that accomplishes the task.
> 
> --
> 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+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Johannes Kepper [kepper at edirom.de]
> Sent: Tuesday, February 08, 2011 2:38 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Encoding staff positions
> 
> Am 08.02.2011 um 14:24 schrieb Laurent Pugin:
>> 
>> 
>>>> 
>>>> In my opinion, it can be useful to capture the original source at the
>>>> very beginning of an editorial process, but it could also be useful at
>>>> the end of the process. If we think of the case where MEI is used to
>>>> encode a new edition, this feature could also make it easier to encode
>>>> its layout and to represent it. If we have an orchestra score with,
>>>> let's say, hundreds of pages, turning a page would require every time
>>>> the entire tree to be parsed to get all the <pb> and all the <sb>. I
>>>> know software issues are not the starting point when defining an
>>>> encoding, but this is seriously not optimal. Why shouldn't I have to
>>>> option to have the encoding in a page-oriented way when the edition
>>>> reached a publishing stage? And maybe to add some more detailed layout
>>>> information for making it easier to read? I don't know, it is just one
>>>> way I see to use MEI.
>>>> 
>>> 
>>> I see your problem, and maybe you're right with this. In Edirom's internal data model we chose a different approach. We always have a double structure inside a source: One perspective is source/movements/measures, the other is source/pages/measures. The logical structure is our main structure, where all objects are actually stored. The page structure contains only pointers to those elements. Of course this produces some overhead, but you may extract it easily from MEI, and you have the best of both approaches all the time. I cannot tell if this is a model for Andrew or you, but it helps us a lot.
>>> 
>>> 
>> 
>> Your solution is an excellent one to get both at the same time, which
>> is of course ideal. It is a elegant workaround to keep both in memory
>> in order to avoid to have to re-parse the tree every single time you
>> need to access something that is spread over several branches in the
>> hierarchy. But if you think of a large repository of MEI files from
>> which you want to quickly access specific pages over the web, you
>> would need another solution. Something built in MEI would be nice.
>> 
> 
> But of course you wouldn't keep the whole repository in memory / your local data model. Using xquery on an eXist database for example, you can get a page that holds a given measure in a couple of milliseconds, especially since MEI's switch to xml:id. But you're right, the overhead we produce slows us down significantly. On a medium size piece of music (a total of ~ 2000 measures in 5 different sources), we experienced a slowdown by the factor of 10 to build our second hierarchy (looping through all zones, looping through all measures to find the right @facs). We still have acceptable loading times, but one of our first improvements to MEI will be the already mentioned backlink from zone to measure ? it will reduce the slowdown to the factor 2, which seems fair regarding the fact that we build two hierarchies? I see no reason why it shouldn't be possible to extract solely a page-oriented structure in time n with this addition to MEI. But of course, if you don't have a local data model and work on the xml directly, you always have an extra IDREF to follow. But as long as you keep //zone[@type eq 'measure'] in the same order as the measures appear logically on that page, it shouldn't be too expensive.
> 
> 
>> Your case also illustrates the fact that, in many applications, having
>> access to both representations is necessary. You choose as main
>> structure the one that is the most relevant for you. In some cases, it
>> can be the other one, and in some cases, only one is necessary. If I
>> just want to generate a midi file, the logical representation is
>> enough (and better), but if I just want to display a page, it is the
>> opposite. So if we can get a good page-oriented representation, with
>> maybe a stylesheet to go from one to the other (at least for not too
>> complicated cases), I see it as a way to avoid people to have to do it
>> internally for each single piece of software that needs it.
> 
> What about a compromise? I'm still against adding a second, equally possible format design to MEI. Looking at MusicXML's timewise vs. partwise, which is definitely a less complicated problem, I'm afraid that we will run into lots of problems. One of the more disturbing is clearly the increased cost to learn MEI, as you have to make a decision on how to use it quite early in the encoding process. But, what if we use the benefits we gain from ODD? I could imagine an official variation of MEI that redesigns it in that particular way (<pb/> to <page>?</page and so on). Such a modification could be provided on the website, and the XSLTs you mentioned could be there as well. This way, we would keep the solution out of the "official" MEI design, but we could offer a standardized, well-documented proposal on how to deal with MEI in page-oriented projects. Programmers could take this over and adjust it to their applications without having to do the complete work on their own. I could see that as a solution for your problem, and at the same time it would be a great way to exemplify the benefits of ODD for MEI. So how about that?
> 
> Johannes
> 
> 
> 
>> 
>>> Honestly, I don't want to cut this idea short, I'm just somewhat reluctant to introduce another tree possibility. <parts><part> and <score> is something different to me, as they behave absolutely similar below this level.
>> 
>> Yes, it is not the exactly the same, I agree.
>> 
>> Laurent
> 
> 
> _______________________________________________
> 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



From laurent at music.mcgill.ca  Wed Feb  9 09:33:06 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Wed, 9 Feb 2011 09:33:06 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <20110208194010.F328CD8803E@asmx3.McGill.CA>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
	<201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
	<AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>
	<201102072201.p17M11kA001106@drizzle.cc.mcgill.ca>
	<AANLkTi=uSwx7YmqyEPRV_6-HJhML7yLifc7M7fgrkYyM@mail.gmail.com>
	<201102080841.p188f1PU008998@torrent.cc.mcgill.ca>
	<AANLkTikMO_-3FWv1Sn7VdQBup9mC6XNhdh0CyjtZOQOC@mail.gmail.com>
	<20110208194010.F328CD8803E@asmx3.McGill.CA>
Message-ID: <AANLkTi=BSNoeVZfnb+F877k9RZeD2Z9KiXXJdc3LkiAv@mail.gmail.com>

On Tue, Feb 8, 2011 at 8:38 PM, Johannes Kepper <kepper at edirom.de> wrote:
>
> Am 08.02.2011 um 14:24 schrieb Laurent Pugin:
>>
>>
>>>>
>>>> In my opinion, it can be useful to capture the original source at the
>>>> very beginning of an editorial process, but it could also be useful at
>>>> the end of the process. If we think of the case where MEI is used to
>>>> encode a new edition, this feature could also make it easier to encode
>>>> its layout and to represent it. If we have an orchestra score with,
>>>> let's say, hundreds of pages, turning a page would require every time
>>>> the entire tree to be parsed to get all the <pb> and all the <sb>. I
>>>> know software issues are not the starting point when defining an
>>>> encoding, but this is seriously not optimal. Why shouldn't I have to
>>>> option to have the encoding in a page-oriented way when the edition
>>>> reached a publishing stage? And maybe to add some more detailed layout
>>>> information for making it easier to read? I don't know, it is just one
>>>> way I see to use MEI.
>>>>
>>>
>>> I see your problem, and maybe you're right with this. In Edirom's internal data model we chose a different approach. We always have a double structure inside a source: One perspective is source/movements/measures, the other is source/pages/measures. The logical structure is our main structure, where all objects are actually stored. The page structure contains only pointers to those elements. Of course this produces some overhead, but you may extract it easily from MEI, and you have the best of both approaches all the time. I cannot tell if this is a model for Andrew or you, but it helps us a lot.
>>>
>>>
>>
>> Your solution is an excellent one to get both at the same time, which
>> is of course ideal. It is a elegant workaround to keep both in memory
>> in order to avoid to have to re-parse the tree every single time you
>> need to access something that is spread over several branches in the
>> hierarchy. But if you think of a large repository of MEI files from
>> which you want to quickly access specific pages over the web, you
>> would need another solution. Something built in MEI would be nice.
>>
>
> But of course you wouldn't keep the whole repository in memory / your local data model. Using xquery on an eXist database for example, you can get a page that holds a given measure in a couple of milliseconds, especially since MEI's switch to xml:id. But you're right, the overhead we produce slows us down significantly. On a medium size piece of music (a total of ~ 2000 measures in 5 different sources), we experienced a slowdown by the factor of 10 to build our second hierarchy (looping through all zones, looping through all measures to find the right @facs). We still have acceptable loading times, but one of our first improvements to MEI will be the already mentioned backlink from zone to measure ? it will reduce the slowdown to the factor 2, which seems fair regarding the fact that we build two hierarchies? I see no reason why it shouldn't be possible to extract solely a page-oriented structure in time n with this addition to MEI. But of course, if you don't have a local data model and work on the xml directly, you always have an extra IDREF to follow. But as long as you keep //zone[@type eq 'measure'] in the same order as the measures appear logically on that page, it shouldn't be too expensive.
>

It does sound quick enough, it is not the main question. What
interests me is more that with your system, you have got somehow built
in the XSLT we mentioned - for an application that manipulates both
hierarchy, in is unavoidable, I agree. But having to do it every time
does not mean only every time you load it (it is apparently quick
enough), but also for every application that needs it. An application
that focus  only (or mostly) on the second hierarchy would have 1) do
implement the same built-in XSLT, and 2) run it every time it load and
save a file. That is not optimal, no matter how good is the programmer
and how quick is the computer.

The second point is that we are assuming here that both
representations are equivalent. This would be ideal, of course, but I
am not sure that it has to be the case. It might very well be not
possible to keep everything we have in a <system> element in the <sb>
when the hierarchy if flipped. That is, I can decide to use one or the
other because it is more comfortable to use but also because it allows
me to do more. If I need to change to the other representation, I can
do it, knowing that most of it (but not necessary everything) will be
keep. We could see it as TEI encoding using the GE module and where we
would remove all the GE elements and keep the text, but in a more
integrated way.

>
>> Your case also illustrates the fact that, in many applications, having
>> access to both representations is necessary. You choose as main
>> structure the one that is the most relevant for you. In some cases, it
>> can be the other one, and in some cases, only one is necessary. If I
>> just want to generate a midi file, the logical representation is
>> enough (and better), but if I just want to display a page, it is the
>> opposite. So if we can get a good page-oriented representation, with
>> maybe a stylesheet to go from one to the other (at least for not too
>> complicated cases), I see it as a way to avoid people to have to do it
>> internally for each single piece of software that needs it.
>
> What about a compromise? I'm still against adding a second, equally possible format design to MEI. Looking at MusicXML's timewise vs. partwise, which is definitely a less complicated problem, I'm afraid that we will run into lots of problems. One of the more disturbing is clearly the increased cost to learn MEI, as you have to make a decision on how to use it quite early in the encoding process. But, what if we use the benefits we gain from ODD? I could imagine an official variation of MEI that redesigns it in that particular way (<pb/> to <page>?</page and so on). Such a modification could be provided on the website, and the XSLTs you mentioned could be there as well. This way, we would keep the solution out of the "official" MEI design, but we could offer a standardized, well-documented proposal on how to deal with MEI in page-oriented projects. Programmers could take this over and adjust it to their applications without having to do the complete work on their own. I could see that as a solution for your problem, and at the same time it would be a great way to exemplify the benefits of ODD for MEI. So how about that?
>

There is a huge flexibility in MEI, I don't think that that particular
addition would make it much more difficult to learn. My impression is
that it will make it more complicated to maintain and to explain.

Laurent

> Johannes
>
>
>
>>
>>> Honestly, I don't want to cut this idea short, I'm just somewhat reluctant to introduce another tree possibility. <parts><part> and <score> is something different to me, as they behave absolutely similar below this level.
>>
>> Yes, it is not the exactly the same, I agree.
>>
>> Laurent
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>


From laurent at music.mcgill.ca  Wed Feb  9 10:20:06 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Wed, 9 Feb 2011 10:20:06 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <201102082111.p18LB1QL016994@torrent.cc.mcgill.ca>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
	<201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
	<AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>
	<201102072201.p17M11kA001106@drizzle.cc.mcgill.ca>
	<AANLkTi=uSwx7YmqyEPRV_6-HJhML7yLifc7M7fgrkYyM@mail.gmail.com>
	<201102080841.p188f1PU008998@torrent.cc.mcgill.ca>
	<AANLkTikMO_-3FWv1Sn7VdQBup9mC6XNhdh0CyjtZOQOC@mail.gmail.com>
	<37F6E443-DAC6-4429-A466-42276974395A@edirom.de>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC56@MCCLANE.eservices.virginia.edu>
	<201102082111.p18LB1QL016994@torrent.cc.mcgill.ca>
Message-ID: <AANLkTi=bD6KvRhNdrSibtGsDG+iLpJrFo4PitZS=42XK@mail.gmail.com>

On Tue, Feb 8, 2011 at 10:03 PM, Johannes Kepper <kepper at edirom.de> wrote:
>
> Am 08.02.2011 um 21:28 schrieb Roland, Perry (pdr4h):
>
>> Johannes, everyone,
>>
>> I don't see the real distinction between offering an "official varation" and a "second, equally possible format design to MEI." ?To me, it's either officially sanctioned, or not. ?If it's not, then it shouldn't be provided. ?If it is officially sanctioned, then it must be documented and supported.
>
> I have no real example from the TEI, but maybe it's something like TEI all vs. TEI Tite. TEI Tite contains elements which aren't in TEI all, but which can be mapped to canonical TEI. TEI Tite is offered and documented by the Council, but it's not canonical TEI, it's built for a certain, well-defined purpose. I would like to keep this out of the regular tag library, but instead offer it on a separate customizations page, perhaps with its own tag library (should be easy to extract from the ODD). That way it is clear that it's not canonical MEI, but a specialized version of it. I expect this to help newbies distinguish which MEI is best for them. It remains clear that there is one basic format design approach behind MEI, not an arbitrary number of them. But of course, I'd still prefer to address the whole issue with a small solution within the current scheme, if this could solve all of Andrew's and Laurent's problems?

Interesting example, I will think about it.

Laurent

>
> Johannes
>
>
>>
>> I agree that if we decide to create such a customization, then the amount of change is best kept to the minimum that accomplishes the task.
>>
>> --
>> 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+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Johannes Kepper [kepper at edirom.de]
>> Sent: Tuesday, February 08, 2011 2:38 PM
>> To: Music Encoding Initiative
>> Subject: Re: [MEI-L] Encoding staff positions
>>
>> Am 08.02.2011 um 14:24 schrieb Laurent Pugin:
>>>
>>>
>>>>>
>>>>> In my opinion, it can be useful to capture the original source at the
>>>>> very beginning of an editorial process, but it could also be useful at
>>>>> the end of the process. If we think of the case where MEI is used to
>>>>> encode a new edition, this feature could also make it easier to encode
>>>>> its layout and to represent it. If we have an orchestra score with,
>>>>> let's say, hundreds of pages, turning a page would require every time
>>>>> the entire tree to be parsed to get all the <pb> and all the <sb>. I
>>>>> know software issues are not the starting point when defining an
>>>>> encoding, but this is seriously not optimal. Why shouldn't I have to
>>>>> option to have the encoding in a page-oriented way when the edition
>>>>> reached a publishing stage? And maybe to add some more detailed layout
>>>>> information for making it easier to read? I don't know, it is just one
>>>>> way I see to use MEI.
>>>>>
>>>>
>>>> I see your problem, and maybe you're right with this. In Edirom's internal data model we chose a different approach. We always have a double structure inside a source: One perspective is source/movements/measures, the other is source/pages/measures. The logical structure is our main structure, where all objects are actually stored. The page structure contains only pointers to those elements. Of course this produces some overhead, but you may extract it easily from MEI, and you have the best of both approaches all the time. I cannot tell if this is a model for Andrew or you, but it helps us a lot.
>>>>
>>>>
>>>
>>> Your solution is an excellent one to get both at the same time, which
>>> is of course ideal. It is a elegant workaround to keep both in memory
>>> in order to avoid to have to re-parse the tree every single time you
>>> need to access something that is spread over several branches in the
>>> hierarchy. But if you think of a large repository of MEI files from
>>> which you want to quickly access specific pages over the web, you
>>> would need another solution. Something built in MEI would be nice.
>>>
>>
>> But of course you wouldn't keep the whole repository in memory / your local data model. Using xquery on an eXist database for example, you can get a page that holds a given measure in a couple of milliseconds, especially since MEI's switch to xml:id. But you're right, the overhead we produce slows us down significantly. On a medium size piece of music (a total of ~ 2000 measures in 5 different sources), we experienced a slowdown by the factor of 10 to build our second hierarchy (looping through all zones, looping through all measures to find the right @facs). We still have acceptable loading times, but one of our first improvements to MEI will be the already mentioned backlink from zone to measure ? it will reduce the slowdown to the factor 2, which seems fair regarding the fact that we build two hierarchies? I see no reason why it shouldn't be possible to extract solely a page-oriented structure in time n with this addition to MEI. But of course, if you don't have a local data model and work on the xml directly, you always have an extra IDREF to follow. But as long as you keep //zone[@type eq 'measure'] in the same order as the measures appear logically on that page, it shouldn't be too expensive.
>>
>>
>>> Your case also illustrates the fact that, in many applications, having
>>> access to both representations is necessary. You choose as main
>>> structure the one that is the most relevant for you. In some cases, it
>>> can be the other one, and in some cases, only one is necessary. If I
>>> just want to generate a midi file, the logical representation is
>>> enough (and better), but if I just want to display a page, it is the
>>> opposite. So if we can get a good page-oriented representation, with
>>> maybe a stylesheet to go from one to the other (at least for not too
>>> complicated cases), I see it as a way to avoid people to have to do it
>>> internally for each single piece of software that needs it.
>>
>> What about a compromise? I'm still against adding a second, equally possible format design to MEI. Looking at MusicXML's timewise vs. partwise, which is definitely a less complicated problem, I'm afraid that we will run into lots of problems. One of the more disturbing is clearly the increased cost to learn MEI, as you have to make a decision on how to use it quite early in the encoding process. But, what if we use the benefits we gain from ODD? I could imagine an official variation of MEI that redesigns it in that particular way (<pb/> to <page>?</page and so on). Such a modification could be provided on the website, and the XSLTs you mentioned could be there as well. This way, we would keep the solution out of the "official" MEI design, but we could offer a standardized, well-documented proposal on how to deal with MEI in page-oriented projects. Programmers could take this over and adjust it to their applications without having to do the complete work on their own. I could see that as a solution for your problem, and at the same time it would be a great way to exemplify the benefits of ODD for MEI. So how about that?
>>
>> Johannes
>>
>>
>>
>>>
>>>> Honestly, I don't want to cut this idea short, I'm just somewhat reluctant to introduce another tree possibility. <parts><part> and <score> is something different to me, as they behave absolutely similar below this level.
>>>
>>> Yes, it is not the exactly the same, I agree.
>>>
>>> Laurent
>>
>>
>> _______________________________________________
>> 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
>
>


From laurent at music.mcgill.ca  Wed Feb  9 21:21:10 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Wed, 9 Feb 2011 21:21:10 +0100
Subject: [MEI-L] Encoding staff positions
In-Reply-To: <AANLkTi=bD6KvRhNdrSibtGsDG+iLpJrFo4PitZS=42XK@mail.gmail.com>
References: <F05E56BA-9B79-4BC1-A62B-5D36E9D5BBDD@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC4C@MCCLANE.eservices.virginia.edu>
	<20110207192733.B5181F44089@asmx4.McGill.CA>
	<30CDDC43-874D-4032-8219-5D1725388088@mail.mcgill.ca>
	<201102072041.p17Kf1Lc009889@drizzle.cc.mcgill.ca>
	<AANLkTikOrgP=EpaYUf7U__gJPDLXe+aADCaB3Q+fXZa3@mail.gmail.com>
	<201102072201.p17M11kA001106@drizzle.cc.mcgill.ca>
	<AANLkTi=uSwx7YmqyEPRV_6-HJhML7yLifc7M7fgrkYyM@mail.gmail.com>
	<201102080841.p188f1PU008998@torrent.cc.mcgill.ca>
	<AANLkTikMO_-3FWv1Sn7VdQBup9mC6XNhdh0CyjtZOQOC@mail.gmail.com>
	<37F6E443-DAC6-4429-A466-42276974395A@edirom.de>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC56@MCCLANE.eservices.virginia.edu>
	<201102082111.p18LB1QL016994@torrent.cc.mcgill.ca>
	<AANLkTi=bD6KvRhNdrSibtGsDG+iLpJrFo4PitZS=42XK@mail.gmail.com>
Message-ID: <AANLkTi=tj37Cd2woz-bqg6rHtNRYr4DMQHSW0rJ1Y3yj@mail.gmail.com>

Hi,

I tried to figure how customizations work. It seems that it can be
defined it with one source file, as for tei tite
http://www.tei-c.org/release/xml/tei/custom/odd/tei_tite.odd
Is is correct?

Then, what is the simplest way to generate a schema? Do we have to
install ROMA locally, or is there a web-based installation we can use?
Can we use the TEI one?

Laurent

On Wed, Feb 9, 2011 at 10:20 AM, Laurent Pugin <laurent at music.mcgill.ca> wrote:
> On Tue, Feb 8, 2011 at 10:03 PM, Johannes Kepper <kepper at edirom.de> wrote:
>>
>> Am 08.02.2011 um 21:28 schrieb Roland, Perry (pdr4h):
>>
>>> Johannes, everyone,
>>>
>>> I don't see the real distinction between offering an "official varation" and a "second, equally possible format design to MEI." ?To me, it's either officially sanctioned, or not. ?If it's not, then it shouldn't be provided. ?If it is officially sanctioned, then it must be documented and supported.
>>
>> I have no real example from the TEI, but maybe it's something like TEI all vs. TEI Tite. TEI Tite contains elements which aren't in TEI all, but which can be mapped to canonical TEI. TEI Tite is offered and documented by the Council, but it's not canonical TEI, it's built for a certain, well-defined purpose. I would like to keep this out of the regular tag library, but instead offer it on a separate customizations page, perhaps with its own tag library (should be easy to extract from the ODD). That way it is clear that it's not canonical MEI, but a specialized version of it. I expect this to help newbies distinguish which MEI is best for them. It remains clear that there is one basic format design approach behind MEI, not an arbitrary number of them. But of course, I'd still prefer to address the whole issue with a small solution within the current scheme, if this could solve all of Andrew's and Laurent's problems?
>
> Interesting example, I will think about it.
>
> Laurent
>
>>
>> Johannes
>>
>>
>>>
>>> I agree that if we decide to create such a customization, then the amount of change is best kept to the minimum that accomplishes the task.
>>>
>>> --
>>> 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+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Johannes Kepper [kepper at edirom.de]
>>> Sent: Tuesday, February 08, 2011 2:38 PM
>>> To: Music Encoding Initiative
>>> Subject: Re: [MEI-L] Encoding staff positions
>>>
>>> Am 08.02.2011 um 14:24 schrieb Laurent Pugin:
>>>>
>>>>
>>>>>>
>>>>>> In my opinion, it can be useful to capture the original source at the
>>>>>> very beginning of an editorial process, but it could also be useful at
>>>>>> the end of the process. If we think of the case where MEI is used to
>>>>>> encode a new edition, this feature could also make it easier to encode
>>>>>> its layout and to represent it. If we have an orchestra score with,
>>>>>> let's say, hundreds of pages, turning a page would require every time
>>>>>> the entire tree to be parsed to get all the <pb> and all the <sb>. I
>>>>>> know software issues are not the starting point when defining an
>>>>>> encoding, but this is seriously not optimal. Why shouldn't I have to
>>>>>> option to have the encoding in a page-oriented way when the edition
>>>>>> reached a publishing stage? And maybe to add some more detailed layout
>>>>>> information for making it easier to read? I don't know, it is just one
>>>>>> way I see to use MEI.
>>>>>>
>>>>>
>>>>> I see your problem, and maybe you're right with this. In Edirom's internal data model we chose a different approach. We always have a double structure inside a source: One perspective is source/movements/measures, the other is source/pages/measures. The logical structure is our main structure, where all objects are actually stored. The page structure contains only pointers to those elements. Of course this produces some overhead, but you may extract it easily from MEI, and you have the best of both approaches all the time. I cannot tell if this is a model for Andrew or you, but it helps us a lot.
>>>>>
>>>>>
>>>>
>>>> Your solution is an excellent one to get both at the same time, which
>>>> is of course ideal. It is a elegant workaround to keep both in memory
>>>> in order to avoid to have to re-parse the tree every single time you
>>>> need to access something that is spread over several branches in the
>>>> hierarchy. But if you think of a large repository of MEI files from
>>>> which you want to quickly access specific pages over the web, you
>>>> would need another solution. Something built in MEI would be nice.
>>>>
>>>
>>> But of course you wouldn't keep the whole repository in memory / your local data model. Using xquery on an eXist database for example, you can get a page that holds a given measure in a couple of milliseconds, especially since MEI's switch to xml:id. But you're right, the overhead we produce slows us down significantly. On a medium size piece of music (a total of ~ 2000 measures in 5 different sources), we experienced a slowdown by the factor of 10 to build our second hierarchy (looping through all zones, looping through all measures to find the right @facs). We still have acceptable loading times, but one of our first improvements to MEI will be the already mentioned backlink from zone to measure ? it will reduce the slowdown to the factor 2, which seems fair regarding the fact that we build two hierarchies? I see no reason why it shouldn't be possible to extract solely a page-oriented structure in time n with this addition to MEI. But of course, if you don't have a local data model and work on the xml directly, you always have an extra IDREF to follow. But as long as you keep //zone[@type eq 'measure'] in the same order as the measures appear logically on that page, it shouldn't be too expensive.
>>>
>>>
>>>> Your case also illustrates the fact that, in many applications, having
>>>> access to both representations is necessary. You choose as main
>>>> structure the one that is the most relevant for you. In some cases, it
>>>> can be the other one, and in some cases, only one is necessary. If I
>>>> just want to generate a midi file, the logical representation is
>>>> enough (and better), but if I just want to display a page, it is the
>>>> opposite. So if we can get a good page-oriented representation, with
>>>> maybe a stylesheet to go from one to the other (at least for not too
>>>> complicated cases), I see it as a way to avoid people to have to do it
>>>> internally for each single piece of software that needs it.
>>>
>>> What about a compromise? I'm still against adding a second, equally possible format design to MEI. Looking at MusicXML's timewise vs. partwise, which is definitely a less complicated problem, I'm afraid that we will run into lots of problems. One of the more disturbing is clearly the increased cost to learn MEI, as you have to make a decision on how to use it quite early in the encoding process. But, what if we use the benefits we gain from ODD? I could imagine an official variation of MEI that redesigns it in that particular way (<pb/> to <page>?</page and so on). Such a modification could be provided on the website, and the XSLTs you mentioned could be there as well. This way, we would keep the solution out of the "official" MEI design, but we could offer a standardized, well-documented proposal on how to deal with MEI in page-oriented projects. Programmers could take this over and adjust it to their applications without having to do the complete work on their own. I could see that as a solution for your problem, and at the same time it would be a great way to exemplify the benefits of ODD for MEI. So how about that?
>>>
>>> Johannes
>>>
>>>
>>>
>>>>
>>>>> Honestly, I don't want to cut this idea short, I'm just somewhat reluctant to introduce another tree possibility. <parts><part> and <score> is something different to me, as they behave absolutely similar below this level.
>>>>
>>>> Yes, it is not the exactly the same, I agree.
>>>>
>>>> Laurent
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>


From rfreedma at haverford.edu  Wed Feb 16 16:23:23 2011
From: rfreedma at haverford.edu (Richard Freedman)
Date: Wed, 16 Feb 2011 10:23:23 -0500
Subject: [MEI-L] Fwd: [AMS-announce] CONF: Music Linked Data Workshop, London,
	12 May 2011
In-Reply-To: <4d5be159.4c8de50a.72db.0923@mx.google.com>
References: <4d5be159.4c8de50a.72db.0923@mx.google.com>
Message-ID: <AANLkTikDzfOnGNX-Q4Fps3WCKEXi4vd_2XdowsNg540B@mail.gmail.com>

A short query:  does anyone have further information (or connections?) with
this event?  Not at all sure I can attend, but I am curious.

Richard

---------- Forwarded message ----------
From: Announcements for the AMS <ams-announce at list.bowdoin.edu>
Date: Wed, Feb 16, 2011 at 9:35 AM
Subject: [AMS-announce] CONF: Music Linked Data Workshop, London, 12 May
2011
To: ams-announce at list.bowdoin.edu


MusicNet is pleased to announce a workshop on Music Linked Data, to be held
on 12 May 2011, 10:30-16:00. The event will take place at the JISC London
meeting rooms (Brettenham House (South Entrance), 5 Lancaster Place, London
WC2E 7EN).


The morning will feature presentations by the MusicNet team (University of
Southampton; MusicNet), David De Roure (University of Oxford; SALAMI), Simon
Dixon (Queen Mary UoL; LinkedBrainz), Nicholas Humfrey (BBC; BBC?s music
linked data), and David Flanders (JISC; JISC?s plans for linked data). In
the afternoon presenters and other exhibitors will be available to answer
questions, offer advice on using linked music data, and provide
?mini-tutorials? to attendees.

The event will be of equal interest to:

computer scientists with an interest in music;
music technologists;
music librarians and library scientists;
digital humanities scholars and digital musicologists;
musicologists planning research projects with an online component or
website.

Full details:
http://musicnet.mspace.fm/blog/2011/02/11/music-linked-data-workshop/


_______________________________________________

AMS-announce mailing list
To post: see the guidelines, www.ams-net.org/announce.php
To unsubscribe, see the archives, etc.:
http://list.bowdoin.edu/mailman/listinfo/ams-announce



-- 
Richard Freedman
John C. Whitehead Professor of Music
Haverford College
Haverford, PA 19041

610-896-1007
610-896-4902 (fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110216/b4aa8549/attachment.htm>

From ich at music.mcgill.ca  Wed Feb 16 16:43:38 2011
From: ich at music.mcgill.ca (Ichiro Fujinaga)
Date: Wed, 16 Feb 2011 10:43:38 -0500
Subject: [MEI-L] Fwd: [AMS-announce] CONF: Music Linked Data Workshop,
	London, 12 May 2011
In-Reply-To: <201102161531.p1GFV16W015754@drizzle.cc.mcgill.ca>
References: <4d5be159.4c8de50a.72db.0923@mx.google.com>
	<201102161531.p1GFV16W015754@drizzle.cc.mcgill.ca>
Message-ID: <BLU0-SMTP79B55D70AA09A3AEF3A6EEBED20@phx.gbl>

We, at McGill, work closely with David De Roure through the SALAMI / NEMA projects. We also work with David Bretherton of the Southampton group.
We've known Simon Dixon for close to 10 years within the Music Information Retrieval community. 

Ichiro

On 2011-02-16, at 10:23 AM, Richard Freedman wrote:

> A short query:  does anyone have further information (or connections?) with this event?  Not at all sure I can attend, but I am curious.
> 
> Richard
> 
> ---------- Forwarded message ----------
> From: Announcements for the AMS <ams-announce at list.bowdoin.edu>
> Date: Wed, Feb 16, 2011 at 9:35 AM
> Subject: [AMS-announce] CONF: Music Linked Data Workshop, London, 12 May 2011
> To: ams-announce at list.bowdoin.edu
> 
> 
> MusicNet is pleased to announce a workshop on Music Linked Data, to be held on 12 May 2011, 10:30-16:00. The event will take place at the JISC London meeting rooms (Brettenham House (South Entrance), 5 Lancaster Place, London WC2E 7EN).
> 
> 
> The morning will feature presentations by the MusicNet team (University of Southampton; MusicNet), David De Roure (University of Oxford; SALAMI), Simon Dixon (Queen Mary UoL; LinkedBrainz), Nicholas Humfrey (BBC; BBC?s music linked data), and David Flanders (JISC; JISC?s plans for linked data). In the afternoon presenters and other exhibitors will be available to answer questions, offer advice on using linked music data, and provide ?mini-tutorials? to attendees.
> 
> The event will be of equal interest to:
> 
> computer scientists with an interest in music;
> music technologists;
> music librarians and library scientists;
> digital humanities scholars and digital musicologists;
> musicologists planning research projects with an online component or website.
> 
> Full details:  http://musicnet.mspace.fm/blog/2011/02/11/music-linked-data-workshop/
> 
> 
> _______________________________________________
> 
> AMS-announce mailing list
> To post: see the guidelines, www.ams-net.org/announce.php
> To unsubscribe, see the archives, etc.: http://list.bowdoin.edu/mailman/listinfo/ams-announce
> 
> 
> 
> -- 
> Richard Freedman
> John C. Whitehead Professor of Music
> Haverford College
> Haverford, PA 19041
> 
> 610-896-1007
> 610-896-4902 (fax)
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From jdownie at illinois.edu  Wed Feb 16 17:38:02 2011
From: jdownie at illinois.edu (J. Stephen Downie)
Date: Wed, 16 Feb 2011 10:38:02 -0600
Subject: [MEI-L] Fwd: [AMS-announce] CONF: Music Linked Data Workshop,
 London, 12 May 2011
In-Reply-To: <AANLkTikDzfOnGNX-Q4Fps3WCKEXi4vd_2XdowsNg540B@mail.gmail.com>
References: <4d5be159.4c8de50a.72db.0923@mx.google.com>
	<AANLkTikDzfOnGNX-Q4Fps3WCKEXi4vd_2XdowsNg540B@mail.gmail.com>
Message-ID: <4D5BFD6A.1080400@illinois.edu>

Hi Gang:

As a NEMA and SALAMI dude I am about to head off to the UK this 
afternoon. I will be talking to David De Roure in London later this 
week. I also hope to drop in on Simon Dixon at Queen Mary. I will ask 
them for the inside dope on the meeting.

Off to pack.

Cheers,
Stephen

On 2/16/2011 9:23 AM, Richard Freedman wrote:
> A short query:  does anyone have further information (or connections?) with
> this event?  Not at all sure I can attend, but I am curious.
>
> Richard
>
> ---------- Forwarded message ----------
> From: Announcements for the AMS<ams-announce at list.bowdoin.edu>
> Date: Wed, Feb 16, 2011 at 9:35 AM
> Subject: [AMS-announce] CONF: Music Linked Data Workshop, London, 12 May
> 2011
> To: ams-announce at list.bowdoin.edu
>
>
> MusicNet is pleased to announce a workshop on Music Linked Data, to be held
> on 12 May 2011, 10:30-16:00. The event will take place at the JISC London
> meeting rooms (Brettenham House (South Entrance), 5 Lancaster Place, London
> WC2E 7EN).
>
>
> The morning will feature presentations by the MusicNet team (University of
> Southampton; MusicNet), David De Roure (University of Oxford; SALAMI), Simon
> Dixon (Queen Mary UoL; LinkedBrainz), Nicholas Humfrey (BBC; BBC?s music
> linked data), and David Flanders (JISC; JISC?s plans for linked data). In
> the afternoon presenters and other exhibitors will be available to answer
> questions, offer advice on using linked music data, and provide
> ?mini-tutorials? to attendees.
>
> The event will be of equal interest to:
>
> computer scientists with an interest in music;
> music technologists;
> music librarians and library scientists;
> digital humanities scholars and digital musicologists;
> musicologists planning research projects with an online component or
> website.
>
> Full details:
> http://musicnet.mspace.fm/blog/2011/02/11/music-linked-data-workshop/
>
>
> _______________________________________________
>
> AMS-announce mailing list
> To post: see the guidelines, www.ams-net.org/announce.php
> To unsubscribe, see the archives, etc.:
> http://list.bowdoin.edu/mailman/listinfo/ams-announce
>
>
>
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-- 
**********************************************************
    "Research funding makes the world a better place"
**********************************************************
J. Stephen Downie, PhD
Associate Professor,
Graduate School of Library and Information Science; and,
Center Affiliate, National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
[Vox/Voicemail] (217) 649-3839
NEMA Project Home: http://nema.lis.uiuc.edu


From zupftom at googlemail.com  Wed Feb 23 11:18:47 2011
From: zupftom at googlemail.com (TW)
Date: Wed, 23 Feb 2011 11:18:47 +0100
Subject: [MEI-L] coordinates
Message-ID: <AANLkTinRB1ge3R4m941hvOEe08-jRn5Vg776w7YkHcbx@mail.gmail.com>

Dear MEI list members,

I'm exploring different approaches to music encoding and am especially
interested in the relationship between graphics and semantics as well
as graphical flexibility and precision.

One basic question about the graphical capabilities of MEI is how the
x/y coordinates are meant to work.  What is the "output coordinate
system" that the schema talks about?  Is it page based, staff based
like in SCORE, staff/measure based like in MusicXML or maybe dependent
on context?  Is there a standard unit like MusicXML's "tenth" or is
the encoder free to choose units of his liking?

Thanks
Thomas Weber


From kepper at edirom.de  Wed Feb 23 13:20:12 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Wed, 23 Feb 2011 13:20:12 +0100
Subject: [MEI-L] coordinates
In-Reply-To: <AANLkTinRB1ge3R4m941hvOEe08-jRn5Vg776w7YkHcbx@mail.gmail.com>
References: <AANLkTinRB1ge3R4m941hvOEe08-jRn5Vg776w7YkHcbx@mail.gmail.com>
Message-ID: <53AAC4CC-97EA-4E07-873D-43D6428615E8@edirom.de>

Hi Thomas,

MEI has different approaches to graphics. When you plan to describe an existing image, you should use the @facs-attribute and refer to a zone-element in facsimile (sibling of body). I don't think that this is what you're looking for, but it is surely the better established way to deal with graphics in MEI. The other way is what you already mentioned: Using @x / @y. The unit of this is not clearly defined, but it makes a lot of sense to refer to the unit defined in scoredef. In scoredef/@page.units you can decide whether to use cm / mm or inches. Adding pix to that list would require to specify the resolution (which is not possible yet, I think). There are lots of other interesting attributes for you on scoredef when you consider to render your MEI. The origin for your @x / @y coordinates would be the upper left corner of the page (even though the current documentation does not say so, unfortunately?). 

I hope this helps you a bit to get things started. Please ask if you have any further questions ? I'm happy to hear more about your project!

Best regards,
Johannes


Am 23.02.2011 um 11:18 schrieb TW:

> Dear MEI list members,
> 
> I'm exploring different approaches to music encoding and am especially
> interested in the relationship between graphics and semantics as well
> as graphical flexibility and precision.
> 
> One basic question about the graphical capabilities of MEI is how the
> x/y coordinates are meant to work.  What is the "output coordinate
> system" that the schema talks about?  Is it page based, staff based
> like in SCORE, staff/measure based like in MusicXML or maybe dependent
> on context?  Is there a standard unit like MusicXML's "tenth" or is
> the encoder free to choose units of his liking?
> 
> Thanks
> Thomas Weber
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



------------------------
Dr. Johannes Kepper
Wiss. Mitarbeiter
DFG-Projekt Edirom

Musikwiss. Seminar Detmold/Paderborn
Gartenstr. 20
32756 Detmold

Tel. +49 5231 975665
Mail: kepper at edirom.de







From andrew.hankinson at mail.mcgill.ca  Wed Feb 23 14:37:38 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Wed, 23 Feb 2011 08:37:38 -0500
Subject: [MEI-L] coordinates
In-Reply-To: <20110223122030.6C65DF0C117@asmx2.McGill.CA>
References: <AANLkTinRB1ge3R4m941hvOEe08-jRn5Vg776w7YkHcbx@mail.gmail.com>
	<20110223122030.6C65DF0C117@asmx2.McGill.CA>
Message-ID: <D473182F-23C7-4DBE-A78F-1F47F080C4D2@mail.mcgill.ca>

Hi Thomas,

We're currently using MEI to in an optical music recognition application, and relating the graphical musical symbols (from a scanned book) to the semantic "interpretation" of these symbols via the <facsimile> system that Johannes mentions.

Basically, within facsimile you define a number of bounding boxes using <zone>, defined by ulx,uly/lrx,lry coordinates. These all have a unique ID. Then on every musical element, you use the @facs attribute to refer to the unique ID of the corresponding zone.

We recently did a bit of looking, and apparently in similar applications to ours (METS/ALTO), the standard metric unit is tenths of a millimeter. This gives you the ability to work with integers at a very fine level while maintaining resolution independence. This is not similar to MusicXML's "tenth," which is 1/10th the height of inter-line staff space (i.e., a tenth is equal to 1/40th of a five-line staff).

I don't know if this is at all what you are describing, but I hope it helps!
-Andrew


On 2011-02-23, at 7:20 AM, Johannes Kepper wrote:

> Hi Thomas,
> 
> MEI has different approaches to graphics. When you plan to describe an existing image, you should use the @facs-attribute and refer to a zone-element in facsimile (sibling of body). I don't think that this is what you're looking for, but it is surely the better established way to deal with graphics in MEI. The other way is what you already mentioned: Using @x / @y. The unit of this is not clearly defined, but it makes a lot of sense to refer to the unit defined in scoredef. In scoredef/@page.units you can decide whether to use cm / mm or inches. Adding pix to that list would require to specify the resolution (which is not possible yet, I think). There are lots of other interesting attributes for you on scoredef when you consider to render your MEI. The origin for your @x / @y coordinates would be the upper left corner of the page (even though the current documentation does not say so, unfortunately?). 
> 
> I hope this helps you a bit to get things started. Please ask if you have any further questions ? I'm happy to hear more about your project!
> 
> Best regards,
> Johannes
> 
> 
> Am 23.02.2011 um 11:18 schrieb TW:
> 
>> Dear MEI list members,
>> 
>> I'm exploring different approaches to music encoding and am especially
>> interested in the relationship between graphics and semantics as well
>> as graphical flexibility and precision.
>> 
>> One basic question about the graphical capabilities of MEI is how the
>> x/y coordinates are meant to work.  What is the "output coordinate
>> system" that the schema talks about?  Is it page based, staff based
>> like in SCORE, staff/measure based like in MusicXML or maybe dependent
>> on context?  Is there a standard unit like MusicXML's "tenth" or is
>> the encoder free to choose units of his liking?
>> 
>> Thanks
>> Thomas Weber
>> 
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> 
> 
> 
> ------------------------
> Dr. Johannes Kepper
> Wiss. Mitarbeiter
> DFG-Projekt Edirom
> 
> Musikwiss. Seminar Detmold/Paderborn
> Gartenstr. 20
> 32756 Detmold
> 
> Tel. +49 5231 975665
> Mail: kepper at edirom.de
> 
> 
> 
> 
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From pdr4h at eservices.virginia.edu  Wed Feb 23 16:43:24 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Wed, 23 Feb 2011 10:43:24 -0500
Subject: [MEI-L] coordinates
In-Reply-To: <D473182F-23C7-4DBE-A78F-1F47F080C4D2@mail.mcgill.ca>
References: <AANLkTinRB1ge3R4m941hvOEe08-jRn5Vg776w7YkHcbx@mail.gmail.com>
	<20110223122030.6C65DF0C117@asmx2.McGill.CA>,
	<D473182F-23C7-4DBE-A78F-1F47F080C4D2@mail.mcgill.ca>
Message-ID: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC6F@MCCLANE.eservices.virginia.edu>

Hello, Thomas,

Welcome to the list!  Thanks for your interest in MEI.

As Johannes and Andrew have already said, if you're working with an existing image, then you can define bounding boxes with the origin at the upper left corner.  Elements representing musical semantics can be related to these bounding boxes using the facs attribute.

If on the other hand, you want to specify where a feature is supposed to wind up in rendered version of the encoding, then x and y coordinates should be used.  Because it's impossible to mandate a single coordinate system for all uses/users, the values of x and y are left to the user.  I suppose these values could be contextual, but it probably would be most useful to employ a single, page-based coordinate system.

MEI provides a page.units attribute on scoredef for recording the real-world units of the output coordinate system.  Currently the values allowed are in, cm, and mm, but this could be extended to include px and other values.

MEI also has a page.scale attribute on the scoredef element that can be used to indicate the relationship between "virtual units" and real-world units given in the page.units attribute.  Virtual units are not currently defined as such, but for relative placement MEI uses half the distance between adjacent staff lines as the basic unit of measurement.  (For example, ho=".5" indicates half of the basic unit or one quarter of the distance between two staff lines.)  Practically speaking, I think this is MEI's "virtual unit".  So a value of 1:1 in page.scale where page.units="cm" indicates that half the distance between adjacent staff lines equals one centimeter.  (Not a realistic example, but you get the idea.)

Of course, all of this stems from my understanding, or lack thereof, of what's needed in MEI for handling graphics.  I freely admit to not being an expert in this area.  If you have suggestions for improvement, please contribute them on this list.

Thanks again for your interest in MEI.  I look forward to hearing from you again soon,

--
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: Wednesday, February 23, 2011 8:37 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] coordinates

Hi Thomas,

We're currently using MEI to in an optical music recognition application, and relating the graphical musical symbols (from a scanned book) to the semantic "interpretation" of these symbols via the <facsimile> system that Johannes mentions.

Basically, within facsimile you define a number of bounding boxes using <zone>, defined by ulx,uly/lrx,lry coordinates. These all have a unique ID. Then on every musical element, you use the @facs attribute to refer to the unique ID of the corresponding zone.

We recently did a bit of looking, and apparently in similar applications to ours (METS/ALTO), the standard metric unit is tenths of a millimeter. This gives you the ability to work with integers at a very fine level while maintaining resolution independence. This is not similar to MusicXML's "tenth," which is 1/10th the height of inter-line staff space (i.e., a tenth is equal to 1/40th of a five-line staff).

I don't know if this is at all what you are describing, but I hope it helps!
-Andrew


On 2011-02-23, at 7:20 AM, Johannes Kepper wrote:

> Hi Thomas,
>
> MEI has different approaches to graphics. When you plan to describe an existing image, you should use the @facs-attribute and refer to a zone-element in facsimile (sibling of body). I don't think that this is what you're looking for, but it is surely the better established way to deal with graphics in MEI. The other way is what you already mentioned: Using @x / @y. The unit of this is not clearly defined, but it makes a lot of sense to refer to the unit defined in scoredef. In scoredef/@page.units you can decide whether to use cm / mm or inches. Adding pix to that list would require to specify the resolution (which is not possible yet, I think). There are lots of other interesting attributes for you on scoredef when you consider to render your MEI. The origin for your @x / @y coordinates would be the upper left corner of the page (even though the current documentation does not say so, unfortunately?).
>
> I hope this helps you a bit to get things started. Please ask if you have any further questions ? I'm happy to hear more about your project!
>
> Best regards,
> Johannes
>
>
> Am 23.02.2011 um 11:18 schrieb TW:
>
>> Dear MEI list members,
>>
>> I'm exploring different approaches to music encoding and am especially
>> interested in the relationship between graphics and semantics as well
>> as graphical flexibility and precision.
>>
>> One basic question about the graphical capabilities of MEI is how the
>> x/y coordinates are meant to work.  What is the "output coordinate
>> system" that the schema talks about?  Is it page based, staff based
>> like in SCORE, staff/measure based like in MusicXML or maybe dependent
>> on context?  Is there a standard unit like MusicXML's "tenth" or is
>> the encoder free to choose units of his liking?
>>
>> Thanks
>> Thomas Weber
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
>
> ------------------------
> Dr. Johannes Kepper
> Wiss. Mitarbeiter
> DFG-Projekt Edirom
>
> Musikwiss. Seminar Detmold/Paderborn
> Gartenstr. 20
> 32756 Detmold
>
> Tel. +49 5231 975665
> Mail: kepper at edirom.de
>
>
>
>
>
>
> _______________________________________________
> 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

From zupftom at googlemail.com  Thu Feb 24 12:28:18 2011
From: zupftom at googlemail.com (TW)
Date: Thu, 24 Feb 2011 12:28:18 +0100
Subject: [MEI-L] coordinates
In-Reply-To: <DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC6F@MCCLANE.eservices.virginia.edu>
References: <AANLkTinRB1ge3R4m941hvOEe08-jRn5Vg776w7YkHcbx@mail.gmail.com>
	<20110223122030.6C65DF0C117@asmx2.McGill.CA>
	<D473182F-23C7-4DBE-A78F-1F47F080C4D2@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC6F@MCCLANE.eservices.virginia.edu>
Message-ID: <AANLkTik-Xii5R-UcVvrRx0izjpUz-xBwUD5j4avOO-EP@mail.gmail.com>

Thanks Johannes, Andrew and Roland,

2011/2/23 Johannes Kepper <kepper at edirom.de>:
> MEI has different approaches to graphics. When you plan to describe an existing image, you should use the @facs-attribute and refer to a zone-element in facsimile (sibling of body). I don't think that this is what you're looking for, but it is surely the better established way to deal with graphics in MEI.

You're right, I'm more interested in data that allows reproducing the
graphics and is editable (i.e. no preexisting image). ?That's probably
not what MEI is designed for. ?I'm looking for inspiration from
existing music encoding solutions and whether one already covers
everything that might be needed or whether it can be extended to do
so.  So all my comments are from this perspective.  I have only a
vague idea of what MEI has to accomplish from the musicologist's
perspective.

I'll just go ahead and write down questions and things that came to my
mind while reading in the documentation.


2011/2/23 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
> Basically, within facsimile you define a number of bounding boxes using <zone>, defined by ulx,uly/lrx,lry coordinates. These all have a unique ID. Then on every musical element, you use the @facs attribute to refer to the unique ID of the corresponding zone.

I'm not sure whether I understand the <facsimile> element correctly.
Where do the <graphic>s come into play? ?Both <surface> and <zone> can
hold <graphic>s, so is a <surface> meant to hold a single <graphic>
for the whole "page", or are the <zones> meant to hold <graphic>s that
in combination make up the page? ?Or are both approaches valid?

What about vector graphics? ?If you have the facsimile e.g. as SVG
data, would it be possible to provide it with @xml:id attributes and
point to those using @facs attributes? ?If I understand the XML specs
correctly, then an IDREF can only reference an element in the same
file. ?As far as I can see, MEI can only reference graphics as
external files, not embed them.


If I'm getting this correctly, there can be more than one <facsimile>
element.  Wouldn't it be reasonable to give corresponding <zone>s in
different facsimiles the same "non-unique ID" (would that be of type
xs:key then)?  Or are the correspondences not always bijective?


2011/2/23 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>
> If on the other hand, you want to specify where a feature is supposed to wind up in rendered version of the encoding, then x and y coordinates should be used. ?Because it's impossible to mandate a single coordinate system for all uses/users, the values of x and y are left to the user. ?I suppose these values could be contextual, but it probably would be most useful to employ a single, page-based coordinate system.
>

For my targeted application, page-based absolute coordinates wouldn't
give me much added benefit over a finalized facsimile layout (which
seems to be sufficiently covered by MEI).  Relative positions would be
more useful for editable music.  For example, it's more useful to read
or set the vertical position of an <artic> relative to the note or
staff (in half staff line line distances, or let me call it "steps").
I'd most likely leave this relative position constant when I only want
to display/print one system instead of the whole page, change the page
margins, change the system breaks, move the staffs up or down a bit,
add a cautionary accidental and rejustify the line of music or if I
create parts (or a score) from the data.

Relative coordinates would of course require thorough documentation
defining where they are "anchored".


> [...] for relative placement MEI uses half the distance between adjacent staff lines as the basic unit of measurement. ?(For example, ho=".5" indicates half of the basic unit or one quarter of the distance between two staff lines.)

I'm not yet convinced of the offsets' usefulness in their currently
documented form.  The @ho/@vo attributes are specified to be an
"adjustment of a feature's programmatically-determined location".  If
the initial location is programmatically determined, then I can't tell
what effect the offset will have, can I?  Let's take for example a
<dynam>f</dynam>.  An application might place it at an arbitrary y
location.  It might have a built-in fixed default y level for dynamics
that I don't know about, it might try to avoid collisions and keep a
certain unknown distance from other elements.  If there are other
elements at the same place, there are different "stacking" orders it
might choose from, it might even shift the symbol horizontally for
collision prevention, it might put it above or below the staff,
depending on how "intelligently" it recognizes vocal parts.  So there
is a virtually unlimited number of potential
"programmatically-determined" initial positions.  I think the offsets
can only be useful if the initial position is clearly defined.

By the way, is the @stem.length attribute also meant to be in "steps"
(half staff line line distances)?

There are certainly more questions to come.
Thomas Weber


From kepper at edirom.de  Thu Feb 24 13:40:05 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Thu, 24 Feb 2011 13:40:05 +0100
Subject: [MEI-L] coordinates
In-Reply-To: <AANLkTik-Xii5R-UcVvrRx0izjpUz-xBwUD5j4avOO-EP@mail.gmail.com>
References: <AANLkTinRB1ge3R4m941hvOEe08-jRn5Vg776w7YkHcbx@mail.gmail.com>
	<20110223122030.6C65DF0C117@asmx2.McGill.CA>
	<D473182F-23C7-4DBE-A78F-1F47F080C4D2@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC6F@MCCLANE.eservices.virginia.edu>
	<AANLkTik-Xii5R-UcVvrRx0izjpUz-xBwUD5j4avOO-EP@mail.gmail.com>
Message-ID: <E6FCA061-C739-4810-8C26-588E6AF02A30@edirom.de>

Hi Thomas,

Am 24.02.2011 um 12:28 schrieb TW:

> Thanks Johannes, Andrew and Roland,
> 
> 2011/2/23 Johannes Kepper <kepper at edirom.de>:
>> MEI has different approaches to graphics. When you plan to describe an existing image, you should use the @facs-attribute and refer to a zone-element in facsimile (sibling of body). I don't think that this is what you're looking for, but it is surely the better established way to deal with graphics in MEI.
> 
> You're right, I'm more interested in data that allows reproducing the
> graphics and is editable (i.e. no preexisting image).  That's probably
> not what MEI is designed for.  I'm looking for inspiration from
> existing music encoding solutions and whether one already covers
> everything that might be needed or whether it can be extended to do
> so.  So all my comments are from this perspective.  I have only a
> vague idea of what MEI has to accomplish from the musicologist's
> perspective.
> 
> I'll just go ahead and write down questions and things that came to my
> mind while reading in the documentation.
> 
> 
> 2011/2/23 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>> Basically, within facsimile you define a number of bounding boxes using <zone>, defined by ulx,uly/lrx,lry coordinates. These all have a unique ID. Then on every musical element, you use the @facs attribute to refer to the unique ID of the corresponding zone.
> 
> I'm not sure whether I understand the <facsimile> element correctly.
> Where do the <graphic>s come into play?  Both <surface> and <zone> can
> hold <graphic>s, so is a <surface> meant to hold a single <graphic>
> for the whole "page", or are the <zones> meant to hold <graphic>s that
> in combination make up the page?  Or are both approaches valid?
> 

Normally you have one facsimile for each source you want to encode. The facsimile contains one <surface> for each page of this source. Within <surface> you'll typically find one <graphic> that points to a digital image of that page (multiple graphics for different kinds of images like x-ray?). The <zone>-elements are normally siblings of that <graphic>. Btw: It seems like you can't refer from a <zone> to a specific <graphic> when there is more than one of them? Seems like a bug to me? 

> What about vector graphics?  If you have the facsimile e.g. as SVG
> data, would it be possible to provide it with @xml:id attributes and
> point to those using @facs attributes?  If I understand the XML specs
> correctly, then an IDREF can only reference an element in the same
> file.  As far as I can see, MEI can only reference graphics as
> external files, not embed them.

You can refer to a SVG instead of a JPG without any problems. You could also include SVGs within <surface> in order to get non-rectangular <zones>. This needs only little customization and is the intended way to go. I hope we have the time to prepare such a customization for the next release. 

> 
> 
> If I'm getting this correctly, there can be more than one <facsimile>
> element.  Wouldn't it be reasonable to give corresponding <zone>s in
> different facsimiles the same "non-unique ID" (would that be of type
> xs:key then)?  Or are the correspondences not always bijective?
> 

You wouldn't do that kind of connecting in the <facsimile>-subtree normally. Instead you would point to multiple <zone>s from the "semantical" element: As @facs is of type xs:IDREFs a <measure> can point to a number of <zone>s. All of them represent this particular measure then. But of course, modelling such relationships is possible in many other ways?

> 
> 2011/2/23 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>> 
>> If on the other hand, you want to specify where a feature is supposed to wind up in rendered version of the encoding, then x and y coordinates should be used.  Because it's impossible to mandate a single coordinate system for all uses/users, the values of x and y are left to the user.  I suppose these values could be contextual, but it probably would be most useful to employ a single, page-based coordinate system.
>> 
> 
> For my targeted application, page-based absolute coordinates wouldn't
> give me much added benefit over a finalized facsimile layout (which
> seems to be sufficiently covered by MEI).  Relative positions would be
> more useful for editable music.  For example, it's more useful to read
> or set the vertical position of an <artic> relative to the note or
> staff (in half staff line line distances, or let me call it "steps").
> I'd most likely leave this relative position constant when I only want
> to display/print one system instead of the whole page, change the page
> margins, change the system breaks, move the staffs up or down a bit,
> add a cautionary accidental and rejustify the line of music or if I
> create parts (or a score) from the data.
> 
> Relative coordinates would of course require thorough documentation
> defining where they are "anchored".
> 

Definitely a good point. As Perry already mentioned, MEI is primarily tailored to describe preexisting notation, whereas output description is surely treated somewhat "stepmotherly". There is definitely room for improvement, and I'm sure to speak for the whole community when saying that help on this is more than welcome? (Though I have to admit that a possible direction of this (interchange between multiple scorewriters) is probably not the foremost goal of MEI)

> 
>> [...] for relative placement MEI uses half the distance between adjacent staff lines as the basic unit of measurement.  (For example, ho=".5" indicates half of the basic unit or one quarter of the distance between two staff lines.)
> 
> I'm not yet convinced of the offsets' usefulness in their currently
> documented form.  The @ho/@vo attributes are specified to be an
> "adjustment of a feature's programmatically-determined location".  If
> the initial location is programmatically determined, then I can't tell
> what effect the offset will have, can I?  Let's take for example a
> <dynam>f</dynam>.  An application might place it at an arbitrary y
> location.  It might have a built-in fixed default y level for dynamics
> that I don't know about, it might try to avoid collisions and keep a
> certain unknown distance from other elements.  If there are other
> elements at the same place, there are different "stacking" orders it
> might choose from, it might even shift the symbol horizontally for
> collision prevention, it might put it above or below the staff,
> depending on how "intelligently" it recognizes vocal parts.  So there
> is a virtually unlimited number of potential
> "programmatically-determined" initial positions.  I think the offsets
> can only be useful if the initial position is clearly defined.

For vertical relative positioning, I'd say the origin is the timestamp of that particular feature. If a <dynam>f</dynam> happens on the second beat, its standard position would be right below a note on this position. Of course this reveals some problems when thinking about the interdependencies between the regular unit of half inter-staff-line distances and the density of the notation, but currently it seems to be the most promising interpretation. This does not help much on vertical positioning, though.

> 
> By the way, is the @stem.length attribute also meant to be in "steps"
> (half staff line line distances)?

Yes. 

> 
> There are certainly more questions to come.

Good to hear ? looking forward :-) Honestly, there are definitely too many underdefined issues in the schema / tag library. We try to address as much of them as possible in the next release (which should be stable in the second half of the year), but we're always happy for additional input (and people who regard themselves as community members?). 

Best,
Johannes





> Thomas Weber
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From zupftom at googlemail.com  Fri Feb 25 10:54:29 2011
From: zupftom at googlemail.com (TW)
Date: Fri, 25 Feb 2011 10:54:29 +0100
Subject: [MEI-L] coordinates
In-Reply-To: <E6FCA061-C739-4810-8C26-588E6AF02A30@edirom.de>
References: <AANLkTinRB1ge3R4m941hvOEe08-jRn5Vg776w7YkHcbx@mail.gmail.com>
	<20110223122030.6C65DF0C117@asmx2.McGill.CA>
	<D473182F-23C7-4DBE-A78F-1F47F080C4D2@mail.mcgill.ca>
	<DDFD6060B452C84F9550AC6C1CCB3BAC3F9082DC6F@MCCLANE.eservices.virginia.edu>
	<AANLkTik-Xii5R-UcVvrRx0izjpUz-xBwUD5j4avOO-EP@mail.gmail.com>
	<E6FCA061-C739-4810-8C26-588E6AF02A30@edirom.de>
Message-ID: <AANLkTikPSw9waBgK-tfCufYd4EU4w_FB+95Wt6utniAs@mail.gmail.com>

2011/2/24 Johannes Kepper <kepper at edirom.de>:
> Hi Thomas,
>
> Am 24.02.2011 um 12:28 schrieb TW:
>
>> Thanks Johannes, Andrew and Roland,
>>
>> 2011/2/23 Johannes Kepper <kepper at edirom.de>:
>>> MEI has different approaches to graphics. When you plan to describe an existing image, you should use the @facs-attribute and refer to a zone-element in facsimile (sibling of body). I don't think that this is what you're looking for, but it is surely the better established way to deal with graphics in MEI.
>>
>> You're right, I'm more interested in data that allows reproducing the
>> graphics and is editable (i.e. no preexisting image). ?That's probably
>> not what MEI is designed for. ?I'm looking for inspiration from
>> existing music encoding solutions and whether one already covers
>> everything that might be needed or whether it can be extended to do
>> so. ?So all my comments are from this perspective. ?I have only a
>> vague idea of what MEI has to accomplish from the musicologist's
>> perspective.
>>
>> I'll just go ahead and write down questions and things that came to my
>> mind while reading in the documentation.
>>
>>
>> 2011/2/23 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>>> Basically, within facsimile you define a number of bounding boxes using <zone>, defined by ulx,uly/lrx,lry coordinates. These all have a unique ID. Then on every musical element, you use the @facs attribute to refer to the unique ID of the corresponding zone.
>>
>> I'm not sure whether I understand the <facsimile> element correctly.
>> Where do the <graphic>s come into play? ?Both <surface> and <zone> can
>> hold <graphic>s, so is a <surface> meant to hold a single <graphic>
>> for the whole "page", or are the <zones> meant to hold <graphic>s that
>> in combination make up the page? ?Or are both approaches valid?
>>
>
> Normally you have one facsimile for each source you want to encode.

If you have multiple sources for am piece, would one encode each one
separately?  Would you have one MEI file for each source and another
one for a potential edited version?  How do you link them together?

> Within <surface> you'll typically find one <graphic> that points to a digital image of that page (multiple graphics for different kinds of images like x-ray?).

I didn't understand the x-ray part.  Do you mean that one image
"shines through" the others?

>> What about vector graphics? ?If you have the facsimile e.g. as SVG
>> data, would it be possible to provide it with @xml:id attributes and
>> point to those using @facs attributes? ?If I understand the XML specs
>> correctly, then an IDREF can only reference an element in the same
>> file. ?As far as I can see, MEI can only reference graphics as
>> external files, not embed them.
>
> You can refer to a SVG instead of a JPG without any problems. You could also include SVGs within <surface> in order to get non-rectangular <zones>. This needs only little customization and is the intended way to go. I hope we have the time to prepare such a customization for the next release.
>

That's not really what I meant.  SVG can be structured, and the
individual graphical elements (like notes, rests, clefs etc.) can be
addressed directly using @xml:id attributes.  That's much better than
rectangular <zones>, as the rectangle may contain elements that don't
really belong to what the <zone> is meant to represent (e.g. the
bounding box of a slur can be very large, in the worst case it could
even encompass virtually everything that's on a staff).

Here's an example of what I mean (please ignore what's in there
musically, e.g. there are no proper time/key signatures):

<?xml version="1.0"?>
<mei xmlns="http://www.music-encoding.org/ns/mei">
  <meihead>
    What's a minimal mei header?
  </meihead>
  <music>
    <body>
      <mdiv>
        <score>
          <scoredef key.sig="0" meter.count="4" meter.unit="4">
            <staffdef n="1"/>
          </scoredef>
          <section facs="example">
            <measure facs="measure1">
              <staff n="1" facs="staff1">
                <layer>
                  <note pname="c" oct="4" dur="4" dots="1" facs="note1"/>
                  <note pname="d" dur="8" facs="note2"/>
                  <note pname="e" accid="f" dur="4" facs="note3"/>
                  <note pname="c" facs="note4"/>
                </layer>
              </staff>
            </measure>
            <measure facs="measure2">
              <staff facs="staff1">
                <layer>
                  <note pname="g" accid="f" dur="1" facs="note5"/>
                </layer>
              </staff>
            </measure>
          </section>
        </score>
      </mdiv>
    </body>
    <facsimile>
      <surface>
        <graphic>
          <svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="350"
height="160" viewBox="0 0 350 160">
            <defs class="used-symbols">
              <g id="treble-clef" stroke="black" stroke-width="5"
fill-rule="evenodd" transform="scale(.035)">
                <path d="M65 -172L100 28L102 47L101 57L99 63L97 67L93
73L87 79L82 82L75 84L69 85L64 85L54 84L49 83L45 81L46 75L50 76L52
76L56 75L60 73L63 71L66 68L69 63L70 60L71 55L71 53L70 48L67 42L65
40L61 37L59 36L53 34L48 34L43 35L38 37L35 39L32 42L29 47L28 50L27
55L27 59L28 65L30 70L33 75L38 80L42 83L49 86L54 87L64 88L67 88L75
87L80 86L85 84L90 81L97 74L101 68L104 59L105 55L106 46L104 28L69
-172L65 -172" fill="black"/>
                <path d="M58 -4L71 -3L79 -3L90 -4L96 -5L102 -7L110
-11" fill="none"/>
                <path d="M110 -11L117 -18L119 -21L122 -26L124 -31L125
-34L126 -38L127 -45L127 -50L126 -56L125 -60L123 -65L119 -71L116
-74L112 -77L107 -80L102 -82L98 -83L89 -84L88 -84L79 -83L71 -81L67
-79L61 -75L57 -70L55 -66L53 -61L52 -53L53 -46L55 -41L58 -36L62 -32L71
-26L70 -25L60 -30L56 -33L51 -38L46 -45L43 -53L42 -60L42 -65L43 -71L44
-75L47 -82L50 -87L53 -91L58 -96L64 -101L69 -104L73 -106L82 -108L86
-108L96 -107L103 -105L110 -102L117 -98L124 -91L129 -84L133 -76L135
-69L136 -63L136 -57L135 -49L134 -44L132 -37L129 -31L126 -26L122
-21L117 -16L110 -11" fill="black"/>
                <path d="M58 -4L52 -5L44 -7L38 -9L30 -13L26 -16L20
-21L15 -26L10 -33L6 -41L3 -49L1 -58L0 -67L0 -77L2 -92L5 -104L9 -114L14
-124L21 -133L30 -143L47 -159L58 -169L83 -193L94 -206L100 -216L104
-225L106 -231L108 -239L109 -248L109 -254L108 -261L107 -264L113
-268L115 -260L116 -254L117 -245L117 -243L116 -229L115 -223L113
-214L110 -203L106 -193L101 -183L94 -171L83 -158L46 -123L35 -111L29
-103L23 -93L21 -89L18 -82L16 -75L15 -66L15 -59L16 -50L18 -42L21 -34L26
-25L30 -20L35 -15L40 -11L46 -8L51 -6L58 -4" fill="black"/>
                <path d="M65 -172L61 -200L60 -219L60 -234L62 -253L64
-262L67 -270L71 -277L76 -284L81 -290L89 -298L93 -300L94 -300L96
-299L101 -293L107 -282L113 -268L107 -264L105 -269L102 -273L99 -274L98
-274L94 -273L93 -272L90 -270L86 -266L79 -256L73 -244L70 -236L67
-222L66 -211L66 -204L67 -189L69 -172L65 -172" fill="black"/>
              </g>
              <g id="flat" stroke="black" stroke-width="5"
transform="scale(.035)" fill-rule="evenodd">
                <path d="M-60 -98L-60 39" fill="none"/>
                <path d="M-60 -11L-54 -20" fill="none"/>
                <path d="M-54 -20L-48 -26L-42 -28L-35 -28L-29 -26L-26
-23L-24 -19L-23 -14L-23 -5L-25 3L-29 11L-34 17L-40 23L-60 39L-46
25L-40 17L-36 9L-34 0L-34 -13L-35 -18L-37 -21L-41 -23L-47 -23L-54 -20"
fill="black"/>
              </g>
              <g id="filled-notehead" stroke="black" stroke-width="5"
fill-rule="evenodd" transform="scale(.035)" >
                <path d="M19 27L26 27L32 26L41 23L49 19L56 14L59 11L64
5L67 -1L68 -7L68 -11L67 -15L66 -17L63 -21L59 -24L57 -25L54 -26L49
-27L42 -27L36 -26L30 -24L27 -23L19 -19L12 -14L9 -11L4 -5L1 1L0 7L0
11L1 15L2 17L5 21L9 24L11 25L14 26L19 27" fill="black"/>
              </g>
              <g id="whole-notehead" stroke="black" stroke-width="5"
transform="scale(.035)" fill-rule="evenodd">
                <path d="M35 -27L27 -26L19 -24L14 -22L9 -19L6 -16L3
-12L1 -8L0 -3L0 3L1 8L3 12L6 16L9 19L14 22L19 24L27 26L35 27L42 27L50
26L58 24L63 22L68 19L71 16L74 12L76 8L77 3L77 -3L76 -8L74 -12L71
-16L68 -19L63 -22L58 -24L50 -26L42 -27L35 -27M34 -26L28 -25L25 -24L22
-22L20 -20L18 -17L17 -13L17 -9L18 -3L20 5L22 11L25 18L27 21L29 23L33
25L38 26L43 26L49 25L52 24L55 22L57 20L59 17L60 13L60 9L59 3L57 -5L55
-11L52 -18L50 -21L48 -23L44 -25L39 -26L34 -26" fill="black"/>
              </g>
              <g id="flag" stroke="black" stroke-width="5" fill-rule="evenodd">
                <path id="subflag" stroke-width="5"
transform="translate(0,-6) scale(.035) " stroke="black" d="M59 16L60
22L61 36L61 41L60 52L59 58L56 68L53 75L50 81L46 87L41 93L36 98L30
103L21 109L11 114L0 118L0 172L3 160L4 157L6 152L10 144L13 139L16
135L21 129L32 117L36 113L43 105L47 100L51 94L55 87L58 80L60 74L62
66L63 60L64 48L64 37L63 26L62 19L61 14L60 10L59 16" fill="black"/>
                <path transform="translate(0,-6) scale(.035) " d="M62
19L61 14L60 10L58 3L54 -8L56 -1L57 4L58 9L59 16L60 22L62 19"
fill="black"/>
              </g>
            </defs>
            <g class="page" xml:id="example"><rect fill="#fffffc"
height="160" stroke="black" width="350" x="0" y="0"><g x="0" x1="0"
x2="350" y="0" y1="0" y2="160"/></rect>
              <g class="system">
                <g class="staff" xml:id="staff1"><g class="stafflines"
stroke="black"><line x1="30" x2="320" y1="90" y2="90"/><line x1="30"
x2="320" y1="82" y2="82"/><line x1="30" x2="320" y1="74"
y2="74"/><line x1="30" x2="320" y1="66" y2="66"/><line x1="30"
x2="320" y1="58" y2="58"/></g>
                  <g class="clef"><use xlink:href="#treble-clef"
transform="translate(38,90) scale(4)"/></g>
                  <g class="measure" xml:id="measure1"/>
                    <g class="note" xml:id="note1"><path
class="ledgerlines" fill="none" stroke="black" d="M66 98h18"/>
                      <g class="stem"><line stroke="black" x1="80"
x2="80" y1="98" y2="70"/></g>
                      <g class="head"><use
xlink:href="#filled-notehead" transform="translate(70,98) scale(4)"/>
                        <g class="dots"><circle cx="87" cy="94" r="1.6"/></g>
                      </g>
                    </g>
                    <g class="note" xml:id="note2">
                      <g class="head"><use
xlink:href="#filled-notehead" transform="translate(110,94)
scale(4)"/></g>
                      <g class="stem"><line stroke="black" x1="120"
x2="120" y1="94" y2="66"/>
                        <g class="flags"><use xlink:href="#flag"
transform="translate(120,66) scale(4,-4)"/></g>
                      </g>
                    </g>
                    <g class="note" xml:id="note3">
                      <g class="head"><use
xlink:href="#filled-notehead" transform="translate(146,90)
scale(4)"/></g>
                      <g class="stem"><line stroke="black" x1="156"
x2="156" y1="90" y2="62"/></g>
                      <g class="accidental"><use xlink:href="#flat"
transform="translate(146,90) scale(4)"/></g>
                    </g>
                    <g class="note" xml:id="note4"><path
class="ledgerlines" fill="none" stroke="black" d="M178 98h18"/>
                      <g class="stem"><line stroke="black" x1="192"
x2="192" y1="98" y2="70"/></g>
                      <g class="head"><use
xlink:href="#filled-notehead" transform="translate(182,98)
scale(4)"/></g>
                    </g>
                    <g class="barline"><line stroke="black" x1="230"
x2="230" y1="90" y2="58"/></g>
                  </g>
                  <g class="measure" xml:id="measure2">
                    <g class="note" xml:id="note5">
                      <g class="head"><use
xlink:href="#whole-notehead" transform="translate(254,82)
scale(4)"/></g>
                      <g class="accidental"><use xlink:href="#flat"
transform="translate(254,82) scale(4)"/></g>
                    </g>
                    <g class="barline"><rect fill="black" height="32"
width="4.8" x="315.2" y="58"/><line stroke="black" x1="312.8"
x2="312.8" y1="90" y2="58"/></g>
                  </g>
                </g>
              </g>
            </g>
          </svg>
        </graphic>
      </surface>
    </facsimile>
  </music>
</mei>


This is my first attempt at MEI and I don't know whether it would be a
correct MEI file.  (I was too lazy to find out what exactly is needed
in the header as it's not really the point here.)

>
> Definitely a good point. As Perry already mentioned, MEI is primarily tailored to describe preexisting notation, whereas output description is surely treated somewhat "stepmotherly". There is definitely room for improvement, and I'm sure to speak for the whole community when saying that help on this is more than welcome?

I'm happy to help if I can.

> (Though I have to admit that a possible direction of this (interchange between multiple scorewriters) is probably not the foremost goal of MEI)
>

Is the generation of presentable graphics from MEI, be it for
electronic display or print, a set goal?

Thomas Weber


From bohl at edirom.de  Wed Apr  6 09:39:36 2011
From: bohl at edirom.de (Benjamin Wolff Bohl)
Date: Wed, 06 Apr 2011 09:39:36 +0200
Subject: [MEI-L] Figured Bass in MEI
In-Reply-To: <AANLkTimbXyhUhJB+wJgFF9kwXxLPZK7XcJk9cbPXFWGj@mail.gmail.com>
References: <6D8ED03D-58AE-4D57-920D-D8770D000FA6@edirom.de>	<DDFD6060B452C84F9550AC6C1CCB3BAC3F50EC611A@MCCLANE.eservices.virginia.edu>	<201011302321.oAUNL4qA000566@drizzle.cc.mcgill.ca>
	<AANLkTimbXyhUhJB+wJgFF9kwXxLPZK7XcJk9cbPXFWGj@mail.gmail.com>
Message-ID: <4D9C18B8.3080003@edirom.de>

Hi everybody!

Sorry for replying this late to Maja's and Johannes' proposal for 
figured bass. Nonetheless, I greatly appreciate your initative in 
tackling figured-bass in MEI Maja and Johannes!

Navigating in the space of possibilities between
> "very precise, interpretative and very loose, uninterpreted markup needs".
I think MEI is neither nor but tends to be of the first kind.
In terms of elementary parts of CMN (staff, measure, note...) MEI is 
very precise,but in terms of additional (text-based) elements such as 
figured-bass (so far encoded in <harm>) MEI allows FOR a rather loose 
encoding. But each instance of <harm> already can be enriched by means 
of references to a <chorddef> of parts of a facsimile.

The harm-chorddef concept an the possible child-nodes in harm and 
chorddef seem to be designed for common chord-symbols or tabulature 
renditions. Why not enhance it for FB needs? In a way offering a same 
level of verbosity to all three "chord-types" and avoiding unbalanced 
richness in favour of one of them.

Some qustions and possibilities:
1.) Should a FB be encoded as a chord giving semi-tone distances to a 
root-note or is there another concept?
-- This would mean to translate FB-figures to common chord-symbols and 
then encode it; as a result notes without a figure will not necessarily 
be associated to the same <chorddef> as it could turn out to be either a 
major or a minor triad.
-- If there were some kind of measurement-unit one could give in a 
<chorddef>, let's say "PITCH_SCALE_STEP", same figures (be it in major 
or minor scale) could be encoded as the same thing, for example in case 
of a "8 3" or "5 3" figuring. A tiny drawback: For interpretational 
purposes the current scale would have to be known.

2.) what is being encoded a source or an edition?
-- Should there be a difference?
-- MEI should allow both!
-- When encoding a source, you might want to put as much of the original 
rendition into the code as possible. This might result in the need of 
encoding every single FB individually (en contraire to my above idea). 
We might think of a solution with @facs or similar, as (by now) you 
cannot replace the original or a facsimile in all of it's aspects.

3.) Do I have to encode it verbose?
-- No. As <harm> should not be eliminated, loose markups are still possible.

It should be clear that MEI encodes music in an interpretative way 
(other than DARMS - thank you Eleanor for the example). That is why it 
should also encode FB as something else than mere strings and thus allow 
logical access.


Sincerely,
Benjamin

Am 01.12.2010 11:18, schrieb Laurent Pugin:
> Hi all,
>
> Thanks for the very complete proposal. A short comment about the 
> placement question. I saw cases of printed sources where the figured 
> bass symbols (sharps or flats) are within the staff, usually just 
> before the note to which they apply. I remember having seen cases with 
> symbols places a third or a fifth higher than the note, or a third 
> below, but also sometimes at the same pitch. In that last case, the 
> result is ambiguous because it looks exactly like a normal sharp or a 
> normal flat. I don't think we have to bother with encoding the 
> ambiguity, but at least the original placement would be nice. Any 
> thoughts?
>
> Best wishes,
> Laurent
>
> On Wed, Dec 1, 2010 at 12:13 AM, Eleanor Selfridge-Field 
> <esfield at stanford.edu <mailto:esfield at stanford.edu>> wrote:
>
>     Perry,
>
>     What a masterpiece of ingenuity! The only way, finally, to know
>     what will
>     work and what will not is to test it on real data with real software.
>
>     Until that happens, I can't resist commenting on your introductory
>     phrase
>     "very precise, interpretative and very loose, uninterpreted markup
>     needs".
>     This pendulum has gone back and forth throughout the history of modern
>     music representation (all 50 years of it). No would should expect
>     it to
>     stop moving any time soon.
>
>     DARMS (1960s) originated in an era insistent on non-interpretative
>     approaches. That is why it encoded only staff positions, not
>     letter names
>     of "notes". We could only "know" what we saw, not what it meant. The
>     practical downside was, of course, that if the key signature
>     happened to
>     be wrong, everything that followed was wrong. Neutral
>     interpretations may
>     need some good defenses against total misunderstanding.
>
>     There are likely to be similar trade-offs in any detailed spec for
>     individual musical features. The physical appearance of the output
>     is a
>     matter of negotiation between the encoding and the output
>     software. With
>     regard to figured bass, MEI faces the same obstacle as optical
>     recognition
>     programs: unless the output method is known, it is hard to know
>     how best
>     and most unambiguously to organize the data. Every program has its own
>     expectations, which are geared to its own processing hierarchy.
>     Ideally,
>     at the output stage one would select a specific style of FB
>     presentation
>     (English style, French style, etc.)
>
>     Eleanor
>     ----------------
>
>     Eleanor Selfridge-Field
>     Stanford University
>     Stanford, CA 94305-3076
>     USA
>     http://www.stanford.edu/~esfield/
>     <http://www.stanford.edu/%7Eesfield/>
>     http://www.ccarh.org
>
>
>
>
>
>
>     -----Original Message-----
>     From: mei-l-bounces at lists.uni-paderborn.de
>     <mailto:mei-l-bounces at lists.uni-paderborn.de>
>     [mailto:mei-l-bounces at lists.uni-paderborn.de
>     <mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of
>     Roland, Perry
>     (pdr4h)
>     Sent: Tuesday, November 30, 2010 8:36 AM
>     To: Music Encoding Initiative
>     Subject: Re: [MEI-L] Figured Bass in MEI
>
>
>     Hi Maja and Johannes,
>
>     Thanks for the well-thought out proposal.  I appreciate the effort
>     that
>     went into creating it.
>
>     <harm> was created to accommodate (and group) various kinds of
>     harmonic
>     labels.  While some are more "structured" than others, in the end
>     they're
>     *labels*.  When it is necessary to have access to an
>     *interpretation* of
>     the label, other mechanisms can be used.  A simple example of this
>     is the
>     use of a simple label, say "7", which may occur many, many times
>     throughout an MEI instance, which may be linked to a more
>     meaningful (and
>     more verbose) interpretation stored elsewhere, say in <chorddef>.
>      Using
>     the verbose form at every occurrence of the label swells the size
>     of the
>     file and complicates the markup for those users who are not
>     interested in
>     the interpretation.  I believe we have to strike a balance between
>     very
>     precise, interpretative and very loose, uninterpreted markup needs.
>
>     Also, when multiple layers of interpretation may exist, say in the
>     case
>     where the original figured bass was "7" and a later hand added a
>     natural
>     below, but that was crossed out by a still later hand, and so on,
>     it is
>     important to treat the figured bass as element content; i.e., strings.
>     Therefore, I have some problem with your reliance on attributes in
>     many
>     cases.
>
>     So, I want to make some suggestions:
>
>     1. Let's make <fb> a child of <harm>.  This way <harm> continues
>     to act in
>     the role of gathering harmonic labels, be they figured bass or
>     something
>     else.  (We may have proposals in the future for more specific
>     handling of
>     additional harmonic indications, such as Roman numeral analysis, etc.)
>     Putting all harmonic labels inside <harm> allows one to mix and
>     match, for
>     example, to use Roman numeral analysis for one measure, Baroque
>     figured
>     bass for another, and letter notations, such as "Cm7", for others.
>
>     This does not preclude putting figured bass in a separate module.  The
>     elements defined by the module would simply be included in the
>     content of
>     <harm> rather than <measure>.  In fact, doing so would be better
>     because
>     a) the content model of measure is complex enough already without
>     complicating it even more and b) it would permit
>     model.transcriptionLike
>     elements to be used as descendants of <harm> to capture the editorial
>     processes described above, but within <measure> to indicate the
>     addition/deletion of harmonic labels over all.
>
>     <fb> should not take the attributes of <harm>. <fb> should only group
>     figure components. <harm> will continue to provide staff, duration,
>     placement, etc. data.  This way, there's no confusion over when to use
>     <fb> and when to use <harm>.
>
>     2. Recognizing the need, which you've pointed out, to treat individual
>     figure components as separate elements, <fb> should contain <f>
>     elements.
>     Each figure component then is a first-class object, with the
>     possibility
>     of participating in multiple attribute classes and content models.
>      For
>     example, each <f> can be associated with a user-defined symbol via
>     @sym or
>     be analytically linked to other elements via @corresp, @sameas, or
>     @copyof.  The <f> element should have an @extender attribute.
>
>     With just these small changes, it's possible to address the
>     examples given
>     in your proposal --
>
>     Example 1 presents no particular problems. <harm> continues in its
>     former
>     role, <fb> gathers <f> elements, and <f> contains a single figure
>     component.
>
>     Ex. 1
>     <harm staff="1" tstamp="1" place="above">
>     <fb>
>     <f>6</f>
>     </fb>
>     </harm>
>
>     I believe it's important to allow those users who want to use
>     <harm> in
>     its current non-specific way to continue to do so.  A possible
>     alternative
>     to the markup above is therefore:
>     <harm staff="1" tstamp="1" place="above">6</harm>
>
>     By the way, all the following examples can be encoded using the
>     current
>     content model of <harm>, but I won't provide the markup.  I leave
>     it as an
>     "exercise to the reader" to do that. :)
>
>     In example 2, the figured bass consists of a "7" with a natural sign
>     below.  Each is treated as a figure, with the natural encoded
>     using the
>     Unicode MUSIC NATURAL SIGN character.
>
>     Ex. 2:
>     <harm staff="1" tstamp="1" place="above">
>     <fb>
>     <f>7</f>
>     <f>&#x266E;</f>
>     </fb>
>     </harm>
>
>     There's no need for an accid.pos attribute in example 3 and 4
>     since the
>     encoding order of the characters in <f> explicitly locates the
>     accidentals
>     after the "7" and before the "3".  (By the way, while they often
>     use the
>     same signs, "accidentals" in figured bass aren't actual
>     accidentals.  They
>     are simply convenient signs to indicate chromatic alteration.  A sharp
>     doesn't necessary mean that there should be a sharp sign in front
>     of the
>     note forming the interval, but rather than the note should be
>     raised by a
>     half step.  That's why <accid> isn't allowed/necessary within <f>.)
>
>     Ex. 3:
>     <harm place="below">
>     <fb>
>     <f>7&#x266D;</f>
>     </fb>
>     </harm>
>
>     Ex. 4:
>     <harm>
>     <fb>
>     <f>6</f>
>     <f>4+</f>
>     <f>&#x266E;3</f>
>     </fb>
>     </harm>
>
>     By handling the slashed numbers with Unicode characters (&#x20e5; =
>     COMBINING REVERSE SOLIDUS OVERLAY and &#x338; = COMBINING LONG SOLIDUS
>     OVERLAY), there's no need for the "within" value of @accid.pos.  The
>     combining nature of these Unicode characters indicates very
>     clearly that
>     they "overstrike" (or are "within") the preceding character.  Even so,
>     there's also no reason why the usual convention for slashes can't be
>     followed, e.g. "6\" and "6/". At some point we could implement
>     something
>     like the <tei:g> element or allow <symbol> within <f>, but Unicode
>     provides everything needed at this point.
>
>     Ex. 5:
>     <harm>
>     <fb>
>     <f>6&#x20E5;</f>
>     <!-- <f>6\</f> -->
>     </fb>
>     </harm>
>
>     Your proposal rightly draws attention to the fact that currently
>     @extender
>     can't be used on individual parts of the harmonic label.
>      Therefore, it's
>     a good idea to wrap each figure component in an <f> element so
>     @extender
>     can be used. Similarly, @sym can be used to point to a
>     user-defined symbol
>     that better represents the figure component, for example, the
>     combined "2"
>     and "+" below.  Similar to the slash in the preceding example
>     before, the
>     small curve over the "5" in example 6 can be represented by the
>     Unicode
>     COMBINING INVERTED BREVE.
>
>     Ex. 6:
>     <harm tstamp="1">
>     <fb>
>     <f extender="true">5&#x0311;</f>
>     <f sym="combo2plus">2+</f>
>     </fb>
>     </harm>
>     <harm tstamp="3">
>     <fb>
>     <f>3</f>
>     </fb>
>     </harm>
>
>     For figures which consist entirely of a mark indicating repetition
>     of the
>     preceding figure, as in example 7, I would argue that these are not
>     extenders and that they should be represented by a dash or another
>     appropriate character.  In some repertoires the repetition sign is a
>     solidus, i.e. "/".  [My personal copy of the Harvard Dictionary of
>     Music
>     (which the Library doesn't have so I can't cite it right now) has an
>     example in which "/" is used instead of "-" to indicate
>     repetition.]  If
>     we hope to capture these varying signs, then treating them as
>     characters
>     is a better option.  Using "-" is also consistent with other
>     figured bass
>     encoding schemes, such as MuseData.
>
>     Ex. 7:
>     <harm tstamp="1.5">
>     <fb>
>     <f>-</f>
>     </fb>
>     </harm>
>
>     Since only <harm> is allowed to carry @tstamp, etc., there must be a
>     <harm> element for each figured bass indication. <add> and its
>     editorial
>     brothers are not yet allowed within <fb> or <f> so they must be
>     wrapped
>     around <harm> to indicate the editorially supplied indication on
>     the 2nd
>     beat.  If <add> and such are allowed in <fb> or <f>, they will have a
>     different meaning; that is, they indicate changes to an already
>     existing
>     figured bass or figure, e.g.,
>
>     <fb>
>     <f>3<add>&#x266F;</add></f>
>     <add><f>7</f></add>
>     </fb>
>
>     This indicates that the alteration to "3" and the "7" were added
>     later.
>
>     The editorially supplied extender in example 8 is somewhat
>     problematic,
>     but not distressingly so.  How it's handled depends on what the
>     encoder
>     wants to emphasize about the notation and whether what's being
>     encoded is
>     an "edition" or a "source".  If the fact that the figure "3" is
>     intended
>     to sound throughout the measure in this edition, then @dur on the
>     <harm>
>     element is appropriate.  What can't be captured by doing this is the
>     supplied nature of the value for @dur.  In order to capture this
>     aspect of
>     source encoding, we must use an element.  While we could add an
>     <extender>
>     element to each <f> and/or <harm>, I would simply treat the added
>     line as
>     just that -- a line.  This approach can provide greater detail
>     regarding
>     the visual characteristics of the line than @extender or @dur can;
>     that it
>     starts somewhat farther to the right than the usual extender, for
>     instance.  The set of attributes used on the line element (and
>     their exact
>     values) is rendering system dependent, but it's possible to relate the
>     line in visual space and time to any other elements and use @type to
>     distinguish this class of line from other lines.  *Currently,
>     <line> isn't
>     allowed within <supplied>, but that's fixable. :)*
>
>     Ex. 8:
>     <harm tstamp="1" dur="0m+3.5">
>     <fb>
>     <f>7</f>
>     <f>&#x266E;</f>
>     </fb>
>     <supplied resp="MH">
>     <line type="extender" [other visual attributes]/>
>     </supplied>
>     </harm>
>     <supplied resp="JK">
>     <harm tstamp="2">
>     <fb>
>     <f>5&#x266F;</f>
>     </fb>
>     </harm>
>     </supplied>
>     <harm tstamp="3">
>     <fb>
>     <f>6</f>
>     </fb>
>     </harm>
>
>     In example 9, as in example 7, the "-" above the "3" on beat 4 is
>     not an
>     extender, but a repetition sign. Likewise, for the "-" on beat
>     4.5.  When
>     extenders are really indicated, @extender may be used on any <f>
>     element
>     to indicate that an extender should be drawn.  Whenever @extender
>     is used
>     @dur (or probably a better-named substitute) should also be used to
>     indicate the endpoint of the extending line.
>
>     Ex. 9:
>     <harm tstamp="3.5">
>     <fb>
>     <f>&#x266D;3</f>
>     <f extender="true">6</f>
>     <f>5</f>
>     </fb>
>     </harm>
>     <harm tstamp="4">
>     <fb>
>     <f>-</f>
>     <f extender="true">&#x266F;3</f>
>     </fb>
>     </harm>
>     <harm tstamp="4.5">
>     <fb>
>     <f>7</f>
>     <f>-</f>
>     </fb>
>     </harm>
>
>     I believe the primary goal in using <fb> is not to capture all the
>     visual
>     "weirdnesses" that can be found in printed and manuscript scores
>     throughout the centuries, but to provide a more-or-less standardized
>     label.  Neither "6&#x266E;" or "6\" is intended to capture the
>     exact look
>     and placement of the slash, only its presence. (When you think
>     about it
>     carefully, "4" doesn't capture the precise look of anything
>     either!) The
>     @sym attribute can be used to point to a user-defined symbol that
>     can be
>     substituted and/or @facs can be used to point to a region in an image
>     where an example can be seen.  This is consistent with the use of
>     @sym and
>     @facs elsewhere in MEI.
>
>     Ex. 10a:
>     <harm tstamp="3">
>     <fb>
>     <f>8</f>
>     <f sym="weird6_1">6&#x266E;</f>
>     <f>4+</f>
>     <f>2</f>
>     </fb>
>     </harm>
>     <harm tstamp="4">
>     <fb>
>     <f sym="weird6_2">6\</f>
>     <f>4</f>
>     <f>3</f>
>     </fb>
>     </harm>
>
>     Ex. 10b:
>     <harm tstamp="4.5">
>     <fb>
>     <f>6\</f>
>     </fb>
>     </harm>
>
>     Ex. 10c:
>     <harm tstamp="1">
>     <fb>
>     <f>5/</f>
>     </fb>
>     </harm>
>
>     I do not agree with your statement that "@startid implies that
>     there is an
>     endid".  In fact, @startid is intended to "hold a reference to the
>     first
>     element in a sequence of events to which the feature applies" even
>     when
>     the sequence contains only a single event. So, there's nothing
>     wrong with
>     using @startid to reference the bass note to which the figure
>     (actually,
>     the <harm> element in my counter proposal) is attached.  Care
>     should be
>     exercised, however, that identifying the bass note is not the
>     start of an
>     attempt to use the contents of <harm> to derive a sounded or
>     intervallically analyzable version.  That capability already exists in
>     <chorddef>.
>
>     I agree with your suggestion regarding a move from IDREFs to URIs.
>      It's
>     already on the feature request list.
>
>     I believe my suggestions provide a compromise between the current
>     method
>     for representing harmonic labels and your proposal.  They
>     facilitate more
>     detailed markup while still treating figured bass indications as
>     labelling
>     strings, providing optimum flexibility.
>
>     Some additional "tweaking" may be necessary so I encourage more
>     discussion.  For example, I'm not wedded to the names above for
>     the new
>     elements.  Instead of <fb> and <f> we could use <figbass> and <fc>
>     (figure
>     component).
>
>     Thanks again for the great proposal.  It's wonderful to work with such
>     intelligent and committed people.
>
>     --
>     p.
>
>     __________________________
>     Perry Roland
>     Music Library
>     University of Virginia
>     P. O. Box 400175
>     Charlottesville, VA 22904
>     434-982-2702 (w)
>     pdr4h at virginia.edu <mailto:pdr4h at virginia.edu>
>
>     ________________________________________
>     From: mei-l-bounces at lists.uni-paderborn.de
>     <mailto:mei-l-bounces at lists.uni-paderborn.de>
>     [mei-l-bounces at lists.uni-paderborn.de
>     <mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of
>     Johannes Kepper
>     [kepper at edirom.de <mailto:kepper at edirom.de>]
>     Sent: Monday, November 15, 2010 5:28 AM
>     To: Music Encoding Initiative
>     Subject: [MEI-L] Figured Bass in MEI
>
>     Dear all,
>
>     although it took us longer than expected, we have finally finished our
>     proposal for a (hopefully) improved encoding of figured bass in
>     MEI. We
>     don't provide a technical schema, but instead offer a couple of
>     examples
>     that might help to slice the problem down. We hope that this paper
>     will
>     start an intense discussion that might pave the way for some
>     changes in
>     the next release of MEI - maybe even a new module!?!
>
>     We're looking forward to lots of comments and suggestions for
>     improvement,
>
>     Maja and Johannes
>     _______________________________________________
>     mei-l mailing list
>     mei-l at lists.uni-paderborn.de <mailto: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 <mailto: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

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110406/eecfc024/attachment.htm>

From andrew.hankinson at mail.mcgill.ca  Mon Apr 25 20:37:45 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Mon, 25 Apr 2011 18:37:45 +0000
Subject: [MEI-L] MEI Incubator proposal
Message-ID: <83CE5165-4D32-43B5-BB87-4007C048BE39@mail.mcgill.ca>

Hi all,

I've spent the last couple weeks in Virginia with Perry, working on some extensions to MEI. As part of this, we've been discussing a general framework for supporting and encouraging community development, so that members of the community can create, develop, and share their MEI extensions with others.

Towards this goal, we've come up with the idea for an "incubator" setup, where community members can publicly share their modifications and additions to MEI in a Subversion repository that is separate from the "main" MEI schema. A typical incubator project will include ODD files that will apply against and extend or modify the most current MEI schema, and documentation for the functionality the modifications bring to MEI.

Once an incubator project has reached a certain level of maturity, it may be considered for inclusion into the main MEI specification. Incubator developers may submit their ODD files to an editorial board (yet to be determined) to ensure it fits within the overall schema and goals of MEI. This is entirely optional, however -- Incubator projects are welcome to co-exist without becoming part of the core (although once they reach a certain maturity, it may be useful to move them to a "community modules" section, or something like that.) Everyone will be able to check out the latest version of the modules and see the code, but committing will be restricted to accepted project developers.

Accompanying the Subversion repository will be a wiki where community members will be invited to document their ODD module -- what functionality the module provides, any examples of how it is used, etc. Naturally, if an incubator project makes it into the MEI spec, then the documentation for the module will make it into the main MEI Guidelines document.

Any thoughts or comments about this plan? For now, I thought we could start small and keep this fairly simple. I have a couple ODD modules that are ready to go, so if some actual examples of how this would work are required, I can set this up and then send around some links.

Thanks,
-Andrew

From andrew.hankinson at mail.mcgill.ca  Tue May 31 01:18:37 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Mon, 30 May 2011 23:18:37 +0000
Subject: [MEI-L] clef as milestone element
Message-ID: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>

Hi all,

tl;dr Should clefs be considered a milestone element?

The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.

*However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.

So, to give an example. Suppose the following:

<staff n="1">
  <layer n="1">
    <sb n="1"/>
    <clef line="3" shape="F"/>
    <note pname="f" oct="3"/>
    <note pname="g" oct="3"/>
    ...
    <sb n="2" />
    <clef line="3" shape="F"/>
    <note pname="c" oct="3"/>
    <note pname="d" oct="3"/>

    ...etc...

This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.

What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)

-Andrew

From maja.hartwig at gmx.de  Tue May 31 08:11:41 2011
From: maja.hartwig at gmx.de (Maja Hartwig)
Date: Tue, 31 May 2011 08:11:41 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
Message-ID: <AA4A97BB-A75E-4A5F-9E60-16975DB29539@gmx.de>

Hi Andrew!
We think you are right, that a clefchange makes no sense within this context. 
Did you already tried this solution?

                       <measure>
                           <staff>
                               <layer>
                                   <note/>
                                 <sb/>
                                   <staffgrp>
                                       <staffdef>
                                           <clef line="2" shape="G"/>
                                       </staffdef>
                                   </staffgrp>
                                   <note/>
                               </layer>
                           </staff>
                       </measure>

Nothing against crazy solutions ;-), but in our opinion, allowing <clef> within <sb>  is not the best way to encode this, because <sb>  applies only the layout as you said, but the <clef> should be  regarded as an independent element. If the clef appears in the second measure  after a systembreak e.g, you have to indicate that, too, but it has nothing to do with a <sb>.
 
        <measure n="1"/>
                        <sb/>
                        <measure n="2"/>
                        <measure n="3">
                            <staffgrp>
                                <staffdef n="1" clef.line="2" clef.shape="G"/>
                            </staffgrp>
                            <staff n="1">
                                <layer>
                                    <note/>
                                </layer>
                            </staff>
                        </measure>
 
We would prefer to keep it within <staffdef>.

Best,
Kristina and Maja





Am 31.05.2011 um 01:18 schrieb Andrew Hankinson, Mr:

> Hi all,
> 
> tl;dr Should clefs be considered a milestone element?
> 
> The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.
> 
> *However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.
> 
> So, to give an example. Suppose the following:
> 
> <staff n="1">
>  <layer n="1">
>    <sb n="1"/>
>    <clef line="3" shape="F"/>
>    <note pname="f" oct="3"/>
>    <note pname="g" oct="3"/>
>    ...
>    <sb n="2" />
>    <clef line="3" shape="F"/>
>    <note pname="c" oct="3"/>
>    <note pname="d" oct="3"/>
> 
>    ...etc...
> 
> This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.
> 
> What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)
> 
> -Andrew
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110531/59ccd24f/attachment.htm>

From kepper at edirom.de  Tue May 31 08:36:33 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Tue, 31 May 2011 08:36:33 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <AA4A97BB-A75E-4A5F-9E60-16975DB29539@gmx.de>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<AA4A97BB-A75E-4A5F-9E60-16975DB29539@gmx.de>
Message-ID: <0746CC30-0F36-492D-9403-7A839FE8C31C@edirom.de>

Hi Andrew,

what about solution d): add a new attribute to <staffdef> called @clef.repeat (or similar)? This could provide a rule of thumb which could then be overridden by staffdef/clef if necessary. Seems to be much simpler to me, and <staffdef> already captures defaults like this one.

Best,
Johannes 


Am 31.05.2011 um 08:11 schrieb Maja Hartwig:

> Hi Andrew!
> We think you are right, that a clefchange makes no sense within this context. 
> Did you already tried this solution?
> 
>                        <measure>
>                            <staff>
>                                <layer>
>                                    <note/>
>                                  <sb/>
>                                    <staffgrp>

<!-- what's the reason for the extra <staffgrp> here? As we're in <layer>already, it should be clear that only this one staff is affected -->

>                                        <staffdef>
>                                            <clef line="2" shape="G"/>
>                                        </staffdef>
>                                    </staffgrp>
>                                    <note/>
>                                </layer>
>                            </staff>
>                        </measure>
> 
> Nothing against crazy solutions ;-), but in our opinion, allowing <clef> within <sb>  is not the best way to encode this, because <sb>  applies only the layout as you said, but the <clef> should be  regarded as an independent element. If the clef appears in the second measure  after a systembreak e.g, you have to indicate that, too, but it has nothing to do with a <sb>.
>  
>         <measure n="1"/>
>                         <sb/>
>                         <measure n="2"/>
>                         <measure n="3">
>                             <staffgrp>
>                                 <staffdef n="1" clef.line="2" clef.shape="G"/>
>                             </staffgrp>
>                             <staff n="1">
>                                 <layer>
>                                     <note/>
>                                 </layer>
>                             </staff>
>                         </measure>
>  
> We would prefer to keep it within <staffdef>.
> 
> Best,
> Kristina and Maja
> 
> 
> 
> 
> 
> Am 31.05.2011 um 01:18 schrieb Andrew Hankinson, Mr:
> 
>> Hi all,
>> 
>> tl;dr Should clefs be considered a milestone element?
>> 
>> The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.
>> 
>> *However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.
>> 
>> So, to give an example. Suppose the following:
>> 
>> <staff n="1">
>>  <layer n="1">
>>    <sb n="1"/>
>>    <clef line="3" shape="F"/>
>>    <note pname="f" oct="3"/>
>>    <note pname="g" oct="3"/>
>>    ...
>>    <sb n="2" />
>>    <clef line="3" shape="F"/>
>>    <note pname="c" oct="3"/>
>>    <note pname="d" oct="3"/>
>> 
>>    ...etc...
>> 
>> This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.
>> 
>> What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)
>> 
>> -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



From andrew.hankinson at mail.mcgill.ca  Tue May 31 08:40:48 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 31 May 2011 06:40:48 +0000
Subject: [MEI-L] clef as milestone element
In-Reply-To: <20067_1306822315_4DE486A9_20067_63_1_AA4A97BB-A75E-4A5F-9E60-16975DB29539@gmx.de>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<20067_1306822315_4DE486A9_20067_63_1_AA4A97BB-A75E-4A5F-9E60-16975DB29539@gmx.de>
Message-ID: <BE2D2C64-018A-4D2E-8946-4D7D5B3FDAAB@mail.mcgill.ca>

Hi Kristina & Maja,

Thanks for getting in touch and keeping the conversation going!

The problem is that a <sb> doesn't necessarily imply a different <staff>, and thus a whole new <staffdef> seems semantically awkward. While it is technically possible to put <staffgrp> and <staffdef> *inside* a staff, it does not make a whole lot of sense to me in this particular case. I think this is why the <clefchange /> element exists in the first place -- so that you can suggest a milestone without redefining a whole new staff.

After sending my last e-mail, I realized there may be some precedent for associating <clef> and <sb> -- the <custos> element, which is currently allowed as a child to <sb>. It is very similar to a clef in this specific use. It has no musically semantic value (both serve as a guide to the performer), but both supply information that is specific to a particular layout. In other words, if you could write the whole work on a single, continuous staff, you would have need for neither <custos> nor <clef> (once it has been defined and assuming it doesn't change).

It's true that <clef> *can* be an independent element; indeed, I think it will be used within <staffdef> and <clefchange> for most cases where it serves as the primary indicator of pitch locations. But allowing in to be tied to <sb /> will also allow us to encode the particular use of a <clef> as a performer guide too.

So, I guess what I'm advocating is one or both of the following:

<staff n="1">
 <layer n="1">
   <sb n="1" clef.line="3" clef.shape="F" />
   <note pname="f" oct="3"/>
   <note pname="g" oct="3"/>
   ...
   <sb n="2">
      <clef line="3" shape="F" />
   </sb>
   <note pname="c" oct="3"/>
   <note pname="d" oct="3"/>

   ...etc...

-Andrew

On 2011-05-31, at 2:11 AM, Maja Hartwig wrote:

Hi Andrew!
We think you are right, that a clefchange makes no sense within this context.
Did you already tried this solution?

                       <measure>
                           <staff>
                               <layer>
                                   <note/>
                                 <sb/>
                                   <staffgrp>
                                       <staffdef>
                                           <clef line="2" shape="G"/>
                                       </staffdef>
                                   </staffgrp>
                                   <note/>
                               </layer>
                           </staff>
                       </measure>

Nothing against crazy solutions ;-), but in our opinion, allowing <clef> within <sb>  is not the best way to encode this, because <sb>  applies only the layout as you said, but the <clef> should be  regarded as an independent element. If the clef appears in the second measure  after a systembreak e.g, you have to indicate that, too, but it has nothing to do with a <sb>.

        <measure n="1"/>
                        <sb/>
                        <measure n="2"/>
                        <measure n="3">
                            <staffgrp>
                                <staffdef n="1" clef.line="2" clef.shape="G"/>
                            </staffgrp>
                            <staff n="1">
                                <layer>
                                    <note/>
                                </layer>
                            </staff>
                        </measure>

We would prefer to keep it within <staffdef>.

Best,
Kristina and Maja





Am 31.05.2011 um 01:18 schrieb Andrew Hankinson, Mr:

Hi all,

tl;dr Should clefs be considered a milestone element?

The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.

*However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.

So, to give an example. Suppose the following:

<staff n="1">
 <layer n="1">
   <sb n="1"/>
   <clef line="3" shape="F"/>
   <note pname="f" oct="3"/>
   <note pname="g" oct="3"/>
   ...
   <sb n="2" />
   <clef line="3" shape="F"/>
   <note pname="c" oct="3"/>
   <note pname="d" oct="3"/>

   ...etc...

This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.

What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)

-Andrew
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto: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<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From andrew.hankinson at mail.mcgill.ca  Tue May 31 08:46:54 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 31 May 2011 06:46:54 +0000
Subject: [MEI-L] clef as milestone element
In-Reply-To: <21864_1306823802_4DE48C79_21864_3384_1_0746CC30-0F36-492D-9403-7A839FE8C31C@edirom.de>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<AA4A97BB-A75E-4A5F-9E60-16975DB29539@gmx.de>
	<21864_1306823802_4DE48C79_21864_3384_1_0746CC30-0F36-492D-9403-7A839FE8C31C@edirom.de>
Message-ID: <054BA89F-30F0-4279-8517-4B50CD4D16ED@mail.mcgill.ca>

Thanks, Johannes,

I guess I would still have a semantic problem with a particular <staffdef /> defining a staff property while it was a *child* of a given staff. If I understand correctly, you're suggesting:

<staff>
   ...
   <sb />
   <staffdef clef.repeat="?true?" />
   ...

In this case, the staffdef would define the properties of its parent, which is what I think I have the biggest semantic problem with. This, and for optimal parsing we would have to have some way of linking which clef it would repeat, which would be problematic (but certainly not impossible) if we were to go with the convention of pre-defining <staffdef>s outside of the "flow" of the notation.

-A



On 2011-05-31, at 2:36 AM, Johannes Kepper wrote:

> Hi Andrew,
> 
> what about solution d): add a new attribute to <staffdef> called @clef.repeat (or similar)? This could provide a rule of thumb which could then be overridden by staffdef/clef if necessary. Seems to be much simpler to me, and <staffdef> already captures defaults like this one.
> 
> Best,
> Johannes 
> 
> 
> Am 31.05.2011 um 08:11 schrieb Maja Hartwig:
> 
>> Hi Andrew!
>> We think you are right, that a clefchange makes no sense within this context. 
>> Did you already tried this solution?
>> 
>>                       <measure>
>>                           <staff>
>>                               <layer>
>>                                   <note/>
>>                                 <sb/>
>>                                   <staffgrp>
> 
> <!-- what's the reason for the extra <staffgrp> here? As we're in <layer>already, it should be clear that only this one staff is affected -->
> 
>>                                       <staffdef>
>>                                           <clef line="2" shape="G"/>
>>                                       </staffdef>
>>                                   </staffgrp>
>>                                   <note/>
>>                               </layer>
>>                           </staff>
>>                       </measure>
>> 
>> Nothing against crazy solutions ;-), but in our opinion, allowing <clef> within <sb>  is not the best way to encode this, because <sb>  applies only the layout as you said, but the <clef> should be  regarded as an independent element. If the clef appears in the second measure  after a systembreak e.g, you have to indicate that, too, but it has nothing to do with a <sb>.
>> 
>>        <measure n="1"/>
>>                        <sb/>
>>                        <measure n="2"/>
>>                        <measure n="3">
>>                            <staffgrp>
>>                                <staffdef n="1" clef.line="2" clef.shape="G"/>
>>                            </staffgrp>
>>                            <staff n="1">
>>                                <layer>
>>                                    <note/>
>>                                </layer>
>>                            </staff>
>>                        </measure>
>> 
>> We would prefer to keep it within <staffdef>.
>> 
>> Best,
>> Kristina and Maja
>> 
>> 
>> 
>> 
>> 
>> Am 31.05.2011 um 01:18 schrieb Andrew Hankinson, Mr:
>> 
>>> Hi all,
>>> 
>>> tl;dr Should clefs be considered a milestone element?
>>> 
>>> The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.
>>> 
>>> *However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.
>>> 
>>> So, to give an example. Suppose the following:
>>> 
>>> <staff n="1">
>>> <layer n="1">
>>>   <sb n="1"/>
>>>   <clef line="3" shape="F"/>
>>>   <note pname="f" oct="3"/>
>>>   <note pname="g" oct="3"/>
>>>   ...
>>>   <sb n="2" />
>>>   <clef line="3" shape="F"/>
>>>   <note pname="c" oct="3"/>
>>>   <note pname="d" oct="3"/>
>>> 
>>>   ...etc...
>>> 
>>> This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.
>>> 
>>> What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)
>>> 
>>> -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



From maja.hartwig at gmx.de  Tue May 31 08:58:27 2011
From: maja.hartwig at gmx.de (Maja Hartwig)
Date: Tue, 31 May 2011 08:58:27 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <054BA89F-30F0-4279-8517-4B50CD4D16ED@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<AA4A97BB-A75E-4A5F-9E60-16975DB29539@gmx.de>
	<21864_1306823802_4DE48C79_21864_3384_1_0746CC30-0F36-492D-9403-7A839FE8C31C@edirom.de>
	<054BA89F-30F0-4279-8517-4B50CD4D16ED@mail.mcgill.ca>
Message-ID: <0D697D64-5404-440A-AF57-D9620708000C@gmx.de>

Hi Andrew!
What about this solution? There would be no need for a new <staffdef>.

<sb/>
  <measure>
    <staff>
     <layer>
       <clef visible="true">
    <layer>
   </staff>
</measure>

K and M

Am 31.05.2011 um 08:46 schrieb Andrew Hankinson, Mr:

> Thanks, Johannes,
> 
> I guess I would still have a semantic problem with a particular <staffdef /> defining a staff property while it was a *child* of a given staff. If I understand correctly, you're suggesting:
> 
> <staff>
>   ...
>   <sb />
>   <staffdef clef.repeat="?true?" />
>   ...
> 
> In this case, the staffdef would define the properties of its parent, which is what I think I have the biggest semantic problem with. This, and for optimal parsing we would have to have some way of linking which clef it would repeat, which would be problematic (but certainly not impossible) if we were to go with the convention of pre-defining <staffdef>s outside of the "flow" of the notation.
> 
> -A
> 
> 
> 
> On 2011-05-31, at 2:36 AM, Johannes Kepper wrote:
> 
>> Hi Andrew,
>> 
>> what about solution d): add a new attribute to <staffdef> called @clef.repeat (or similar)? This could provide a rule of thumb which could then be overridden by staffdef/clef if necessary. Seems to be much simpler to me, and <staffdef> already captures defaults like this one.
>> 
>> Best,
>> Johannes 
>> 
>> 
>> Am 31.05.2011 um 08:11 schrieb Maja Hartwig:
>> 
>>> Hi Andrew!
>>> We think you are right, that a clefchange makes no sense within this context. 
>>> Did you already tried this solution?
>>> 
>>>                      <measure>
>>>                          <staff>
>>>                              <layer>
>>>                                  <note/>
>>>                                <sb/>
>>>                                  <staffgrp>
>> 
>> <!-- what's the reason for the extra <staffgrp> here? As we're in <layer>already, it should be clear that only this one staff is affected -->
>> 
>>>                                      <staffdef>
>>>                                          <clef line="2" shape="G"/>
>>>                                      </staffdef>
>>>                                  </staffgrp>
>>>                                  <note/>
>>>                              </layer>
>>>                          </staff>
>>>                      </measure>
>>> 
>>> Nothing against crazy solutions ;-), but in our opinion, allowing <clef> within <sb>  is not the best way to encode this, because <sb>  applies only the layout as you said, but the <clef> should be  regarded as an independent element. If the clef appears in the second measure  after a systembreak e.g, you have to indicate that, too, but it has nothing to do with a <sb>.
>>> 
>>>       <measure n="1"/>
>>>                       <sb/>
>>>                       <measure n="2"/>
>>>                       <measure n="3">
>>>                           <staffgrp>
>>>                               <staffdef n="1" clef.line="2" clef.shape="G"/>
>>>                           </staffgrp>
>>>                           <staff n="1">
>>>                               <layer>
>>>                                   <note/>
>>>                               </layer>
>>>                           </staff>
>>>                       </measure>
>>> 
>>> We would prefer to keep it within <staffdef>.
>>> 
>>> Best,
>>> Kristina and Maja
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Am 31.05.2011 um 01:18 schrieb Andrew Hankinson, Mr:
>>> 
>>>> Hi all,
>>>> 
>>>> tl;dr Should clefs be considered a milestone element?
>>>> 
>>>> The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.
>>>> 
>>>> *However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.
>>>> 
>>>> So, to give an example. Suppose the following:
>>>> 
>>>> <staff n="1">
>>>> <layer n="1">
>>>>  <sb n="1"/>
>>>>  <clef line="3" shape="F"/>
>>>>  <note pname="f" oct="3"/>
>>>>  <note pname="g" oct="3"/>
>>>>  ...
>>>>  <sb n="2" />
>>>>  <clef line="3" shape="F"/>
>>>>  <note pname="c" oct="3"/>
>>>>  <note pname="d" oct="3"/>
>>>> 
>>>>  ...etc...
>>>> 
>>>> This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.
>>>> 
>>>> What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)
>>>> 
>>>> -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



From zupftom at googlemail.com  Tue May 31 09:13:29 2011
From: zupftom at googlemail.com (TW)
Date: Tue, 31 May 2011 09:13:29 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
Message-ID: <BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>

Hi Andrew,

do you want the clef element for rendering purposes?  As far as I
understand, for storing rendering information you're developing a
separate layout tree anyway, so can't you record the clef (and even
the system break) there?  Then the musical data doesn't get cluttered
with layout information.  When there are different readings of
differing length, then different layouts are required anyway.  When
generating performance material, different layouts for the score and
each individual part are required as well (or would this be out of
scope?).

I hope I didn't totally misunderstand the issue.

Thomas Weber


2011/5/31 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
> Hi all,
>
> tl;dr Should clefs be considered a milestone element?
>
> The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.
>
> *However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.
>
> So, to give an example. Suppose the following:
>
> <staff n="1">
> ?<layer n="1">
> ? ?<sb n="1"/>
> ? ?<clef line="3" shape="F"/>
> ? ?<note pname="f" oct="3"/>
> ? ?<note pname="g" oct="3"/>
> ? ?...
> ? ?<sb n="2" />
> ? ?<clef line="3" shape="F"/>
> ? ?<note pname="c" oct="3"/>
> ? ?<note pname="d" oct="3"/>
>
> ? ?...etc...
>
> This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.
>
> What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)
>
> -Andrew
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>


From kepper at edirom.de  Tue May 31 09:13:41 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Tue, 31 May 2011 09:13:41 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <054BA89F-30F0-4279-8517-4B50CD4D16ED@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<AA4A97BB-A75E-4A5F-9E60-16975DB29539@gmx.de>
	<21864_1306823802_4DE48C79_21864_3384_1_0746CC30-0F36-492D-9403-7A839FE8C31C@edirom.de>
	<054BA89F-30F0-4279-8517-4B50CD4D16ED@mail.mcgill.ca>
Message-ID: <C537461D-9807-4CFE-81D0-348A86DD5E38@edirom.de>


Am 31.05.2011 um 08:46 schrieb Andrew Hankinson, Mr:

> Thanks, Johannes,
> 
> I guess I would still have a semantic problem with a particular <staffdef /> defining a staff property while it was a *child* of a given staff. If I understand correctly, you're suggesting:
> 
> <staff>
>   ...
>   <sb />
>   <staffdef clef.repeat="?true?" />
>   ...
> 

No, I would add this at the very first <staffdef>, within <scoredef>. There would be no need to care for the clef at each <sb/> (or <pb/> as well!). But I think your reference to <custos> convinced me that this is also a solution. Also, after thinking twice, I see that a general solution within <scoredef> is rather inconvenient for OMR purposes. I think I would add both options, @clef.repeat (or @clef.rpt, to be more consistent) on <staffdef>, and <clef> within <sb/> and <pb/>. By doing so we have a general solution that's easy to encode by hand, and we have a very specific solution suitable for OMR and catching details of these symbols. Very MEI-like, I'd say. 

Johannes


> In this case, the staffdef would define the properties of its parent, which is what I think I have the biggest semantic problem with. This, and for optimal parsing we would have to have some way of linking which clef it would repeat, which would be problematic (but certainly not impossible) if we were to go with the convention of pre-defining <staffdef>s outside of the "flow" of the notation.
> 
> -A
> 
> 
> 
> On 2011-05-31, at 2:36 AM, Johannes Kepper wrote:
> 
>> Hi Andrew,
>> 
>> what about solution d): add a new attribute to <staffdef> called @clef.repeat (or similar)? This could provide a rule of thumb which could then be overridden by staffdef/clef if necessary. Seems to be much simpler to me, and <staffdef> already captures defaults like this one.
>> 
>> Best,
>> Johannes 
>> 
>> 
>> Am 31.05.2011 um 08:11 schrieb Maja Hartwig:
>> 
>>> Hi Andrew!
>>> We think you are right, that a clefchange makes no sense within this context. 
>>> Did you already tried this solution?
>>> 
>>>                      <measure>
>>>                          <staff>
>>>                              <layer>
>>>                                  <note/>
>>>                                <sb/>
>>>                                  <staffgrp>
>> 
>> <!-- what's the reason for the extra <staffgrp> here? As we're in <layer>already, it should be clear that only this one staff is affected -->
>> 
>>>                                      <staffdef>
>>>                                          <clef line="2" shape="G"/>
>>>                                      </staffdef>
>>>                                  </staffgrp>
>>>                                  <note/>
>>>                              </layer>
>>>                          </staff>
>>>                      </measure>
>>> 
>>> Nothing against crazy solutions ;-), but in our opinion, allowing <clef> within <sb>  is not the best way to encode this, because <sb>  applies only the layout as you said, but the <clef> should be  regarded as an independent element. If the clef appears in the second measure  after a systembreak e.g, you have to indicate that, too, but it has nothing to do with a <sb>.
>>> 
>>>       <measure n="1"/>
>>>                       <sb/>
>>>                       <measure n="2"/>
>>>                       <measure n="3">
>>>                           <staffgrp>
>>>                               <staffdef n="1" clef.line="2" clef.shape="G"/>
>>>                           </staffgrp>
>>>                           <staff n="1">
>>>                               <layer>
>>>                                   <note/>
>>>                               </layer>
>>>                           </staff>
>>>                       </measure>
>>> 
>>> We would prefer to keep it within <staffdef>.
>>> 
>>> Best,
>>> Kristina and Maja
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Am 31.05.2011 um 01:18 schrieb Andrew Hankinson, Mr:
>>> 
>>>> Hi all,
>>>> 
>>>> tl;dr Should clefs be considered a milestone element?
>>>> 
>>>> The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.
>>>> 
>>>> *However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.
>>>> 
>>>> So, to give an example. Suppose the following:
>>>> 
>>>> <staff n="1">
>>>> <layer n="1">
>>>>  <sb n="1"/>
>>>>  <clef line="3" shape="F"/>
>>>>  <note pname="f" oct="3"/>
>>>>  <note pname="g" oct="3"/>
>>>>  ...
>>>>  <sb n="2" />
>>>>  <clef line="3" shape="F"/>
>>>>  <note pname="c" oct="3"/>
>>>>  <note pname="d" oct="3"/>
>>>> 
>>>>  ...etc...
>>>> 
>>>> This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.
>>>> 
>>>> What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)
>>>> 
>>>> -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



From andrew.hankinson at mail.mcgill.ca  Tue May 31 09:21:46 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 31 May 2011 07:21:46 +0000
Subject: [MEI-L] clef as milestone element
In-Reply-To: <21600_1306825115_4DE4919B_21600_921_1_0D697D64-5404-440A-AF57-D9620708000C@gmx.de>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<AA4A97BB-A75E-4A5F-9E60-16975DB29539@gmx.de>
	<21864_1306823802_4DE48C79_21864_3384_1_0746CC30-0F36-492D-9403-7A839FE8C31C@edirom.de>
	<054BA89F-30F0-4279-8517-4B50CD4D16ED@mail.mcgill.ca>
	<21600_1306825115_4DE4919B_21600_921_1_0D697D64-5404-440A-AF57-D9620708000C@gmx.de>
Message-ID: <81A61CEA-76AD-40CE-8690-8D6A7F9CBC4C@mail.mcgill.ca>

Currently, <clef> isn't allowed directly in <layer>, which was what spurred the whole problem in the first place. And, although this was my first suggestion -- that we do allow <clef> in <layer> -- I think I'm now of the opinion that it could be made a part of <sb/>.

<sb /> is, almost by definition, a child of a staff. A system is a page layout convention, because we can't fit staves on a single continuous piece of paper (unless we're encoding Piano Roll music, but I suspect that's a job for the PRMEI project. :). So we use <sb/> to encode where a system break occurs while still maintaining the music notation as a member of a given staff. So I definitely think that <sb> should be a child or descendent of <staff>.

That, and we don't have measures in our music, so we can't assume a split over two measures.

-Andrew


On 2011-05-31, at 2:58 AM, Maja Hartwig wrote:

> Hi Andrew!
> What about this solution? There would be no need for a new <staffdef>.
> 
> <sb/>
>  <measure>
>    <staff>
>     <layer>
>       <clef visible="true">
>    <layer>
>   </staff>
> </measure>
> 
> K and M
> 
> Am 31.05.2011 um 08:46 schrieb Andrew Hankinson, Mr:
> 
>> Thanks, Johannes,
>> 
>> I guess I would still have a semantic problem with a particular <staffdef /> defining a staff property while it was a *child* of a given staff. If I understand correctly, you're suggesting:
>> 
>> <staff>
>>  ...
>>  <sb />
>>  <staffdef clef.repeat="?true?" />
>>  ...
>> 
>> In this case, the staffdef would define the properties of its parent, which is what I think I have the biggest semantic problem with. This, and for optimal parsing we would have to have some way of linking which clef it would repeat, which would be problematic (but certainly not impossible) if we were to go with the convention of pre-defining <staffdef>s outside of the "flow" of the notation.
>> 
>> -A
>> 
>> 
>> 
>> On 2011-05-31, at 2:36 AM, Johannes Kepper wrote:
>> 
>>> Hi Andrew,
>>> 
>>> what about solution d): add a new attribute to <staffdef> called @clef.repeat (or similar)? This could provide a rule of thumb which could then be overridden by staffdef/clef if necessary. Seems to be much simpler to me, and <staffdef> already captures defaults like this one.
>>> 
>>> Best,
>>> Johannes 
>>> 
>>> 
>>> Am 31.05.2011 um 08:11 schrieb Maja Hartwig:
>>> 
>>>> Hi Andrew!
>>>> We think you are right, that a clefchange makes no sense within this context. 
>>>> Did you already tried this solution?
>>>> 
>>>>                     <measure>
>>>>                         <staff>
>>>>                             <layer>
>>>>                                 <note/>
>>>>                               <sb/>
>>>>                                 <staffgrp>
>>> 
>>> <!-- what's the reason for the extra <staffgrp> here? As we're in <layer>already, it should be clear that only this one staff is affected -->
>>> 
>>>>                                     <staffdef>
>>>>                                         <clef line="2" shape="G"/>
>>>>                                     </staffdef>
>>>>                                 </staffgrp>
>>>>                                 <note/>
>>>>                             </layer>
>>>>                         </staff>
>>>>                     </measure>
>>>> 
>>>> Nothing against crazy solutions ;-), but in our opinion, allowing <clef> within <sb>  is not the best way to encode this, because <sb>  applies only the layout as you said, but the <clef> should be  regarded as an independent element. If the clef appears in the second measure  after a systembreak e.g, you have to indicate that, too, but it has nothing to do with a <sb>.
>>>> 
>>>>      <measure n="1"/>
>>>>                      <sb/>
>>>>                      <measure n="2"/>
>>>>                      <measure n="3">
>>>>                          <staffgrp>
>>>>                              <staffdef n="1" clef.line="2" clef.shape="G"/>
>>>>                          </staffgrp>
>>>>                          <staff n="1">
>>>>                              <layer>
>>>>                                  <note/>
>>>>                              </layer>
>>>>                          </staff>
>>>>                      </measure>
>>>> 
>>>> We would prefer to keep it within <staffdef>.
>>>> 
>>>> Best,
>>>> Kristina and Maja
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Am 31.05.2011 um 01:18 schrieb Andrew Hankinson, Mr:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> tl;dr Should clefs be considered a milestone element?
>>>>> 
>>>>> The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.
>>>>> 
>>>>> *However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.
>>>>> 
>>>>> So, to give an example. Suppose the following:
>>>>> 
>>>>> <staff n="1">
>>>>> <layer n="1">
>>>>> <sb n="1"/>
>>>>> <clef line="3" shape="F"/>
>>>>> <note pname="f" oct="3"/>
>>>>> <note pname="g" oct="3"/>
>>>>> ...
>>>>> <sb n="2" />
>>>>> <clef line="3" shape="F"/>
>>>>> <note pname="c" oct="3"/>
>>>>> <note pname="d" oct="3"/>
>>>>> 
>>>>> ...etc...
>>>>> 
>>>>> This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.
>>>>> 
>>>>> What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)
>>>>> 
>>>>> -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



From raffaeleviglianti at gmail.com  Tue May 31 09:35:40 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Tue, 31 May 2011 08:35:40 +0100
Subject: [MEI-L] clef as milestone element
In-Reply-To: <81A61CEA-76AD-40CE-8690-8D6A7F9CBC4C@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<AA4A97BB-A75E-4A5F-9E60-16975DB29539@gmx.de>
	<21864_1306823802_4DE48C79_21864_3384_1_0746CC30-0F36-492D-9403-7A839FE8C31C@edirom.de>
	<054BA89F-30F0-4279-8517-4B50CD4D16ED@mail.mcgill.ca>
	<21600_1306825115_4DE4919B_21600_921_1_0D697D64-5404-440A-AF57-D9620708000C@gmx.de>
	<81A61CEA-76AD-40CE-8690-8D6A7F9CBC4C@mail.mcgill.ca>
Message-ID: <BANLkTi=xnUyaKQ3+4Yz47ybK_Uip1o39Rg@mail.gmail.com>

Dear all,

I agree that using clefchange and staffdef for courtesy clef repetitions is
a bit cumbersome, but I would advise against overweighting <pb/> and <sb/>.
In my opinion they should only signify the break and contain nothing. A
custos should occur *before* (or occasionally after) the system break and
not within the system break. If you think about it, that is what happens on
the page. In the same way, the clef repetition should not be attached to sb
or pb.

Moreover, I have come across clef repetitions that do not happen at system
or page break. This is quite common for orchestral works, where some
instruments may not play for a few pages and on reprise, the scribe writes
the clef for clarity. You can see how this can easily happen in the middle
of the page.

Best,
Raffaele



On Tue, May 31, 2011 at 8:21 AM, Andrew Hankinson, Mr <
andrew.hankinson at mail.mcgill.ca> wrote:

> Currently, <clef> isn't allowed directly in <layer>, which was what spurred
> the whole problem in the first place. And, although this was my first
> suggestion -- that we do allow <clef> in <layer> -- I think I'm now of the
> opinion that it could be made a part of <sb/>.
>
> <sb /> is, almost by definition, a child of a staff. A system is a page
> layout convention, because we can't fit staves on a single continuous piece
> of paper (unless we're encoding Piano Roll music, but I suspect that's a job
> for the PRMEI project. :). So we use <sb/> to encode where a system break
> occurs while still maintaining the music notation as a member of a given
> staff. So I definitely think that <sb> should be a child or descendent of
> <staff>.
>
> That, and we don't have measures in our music, so we can't assume a split
> over two measures.
>
> -Andrew
>
>
> On 2011-05-31, at 2:58 AM, Maja Hartwig wrote:
>
> > Hi Andrew!
> > What about this solution? There would be no need for a new <staffdef>.
> >
> > <sb/>
> >  <measure>
> >    <staff>
> >     <layer>
> >       <clef visible="true">
> >    <layer>
> >   </staff>
> > </measure>
> >
> > K and M
> >
> > Am 31.05.2011 um 08:46 schrieb Andrew Hankinson, Mr:
> >
> >> Thanks, Johannes,
> >>
> >> I guess I would still have a semantic problem with a particular
> <staffdef /> defining a staff property while it was a *child* of a given
> staff. If I understand correctly, you're suggesting:
> >>
> >> <staff>
> >>  ...
> >>  <sb />
> >>  <staffdef clef.repeat="?true?" />
> >>  ...
> >>
> >> In this case, the staffdef would define the properties of its parent,
> which is what I think I have the biggest semantic problem with. This, and
> for optimal parsing we would have to have some way of linking which clef it
> would repeat, which would be problematic (but certainly not impossible) if
> we were to go with the convention of pre-defining <staffdef>s outside of the
> "flow" of the notation.
> >>
> >> -A
> >>
> >>
> >>
> >> On 2011-05-31, at 2:36 AM, Johannes Kepper wrote:
> >>
> >>> Hi Andrew,
> >>>
> >>> what about solution d): add a new attribute to <staffdef> called
> @clef.repeat (or similar)? This could provide a rule of thumb which could
> then be overridden by staffdef/clef if necessary. Seems to be much simpler
> to me, and <staffdef> already captures defaults like this one.
> >>>
> >>> Best,
> >>> Johannes
> >>>
> >>>
> >>> Am 31.05.2011 um 08:11 schrieb Maja Hartwig:
> >>>
> >>>> Hi Andrew!
> >>>> We think you are right, that a clefchange makes no sense within this
> context.
> >>>> Did you already tried this solution?
> >>>>
> >>>>                     <measure>
> >>>>                         <staff>
> >>>>                             <layer>
> >>>>                                 <note/>
> >>>>                               <sb/>
> >>>>                                 <staffgrp>
> >>>
> >>> <!-- what's the reason for the extra <staffgrp> here? As we're in
> <layer>already, it should be clear that only this one staff is affected -->
> >>>
> >>>>                                     <staffdef>
> >>>>                                         <clef line="2" shape="G"/>
> >>>>                                     </staffdef>
> >>>>                                 </staffgrp>
> >>>>                                 <note/>
> >>>>                             </layer>
> >>>>                         </staff>
> >>>>                     </measure>
> >>>>
> >>>> Nothing against crazy solutions ;-), but in our opinion, allowing
> <clef> within <sb>  is not the best way to encode this, because <sb>
>  applies only the layout as you said, but the <clef> should be  regarded as
> an independent element. If the clef appears in the second measure  after a
> systembreak e.g, you have to indicate that, too, but it has nothing to do
> with a <sb>.
> >>>>
> >>>>      <measure n="1"/>
> >>>>                      <sb/>
> >>>>                      <measure n="2"/>
> >>>>                      <measure n="3">
> >>>>                          <staffgrp>
> >>>>                              <staffdef n="1" clef.line="2"
> clef.shape="G"/>
> >>>>                          </staffgrp>
> >>>>                          <staff n="1">
> >>>>                              <layer>
> >>>>                                  <note/>
> >>>>                              </layer>
> >>>>                          </staff>
> >>>>                      </measure>
> >>>>
> >>>> We would prefer to keep it within <staffdef>.
> >>>>
> >>>> Best,
> >>>> Kristina and Maja
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Am 31.05.2011 um 01:18 schrieb Andrew Hankinson, Mr:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> tl;dr Should clefs be considered a milestone element?
> >>>>>
> >>>>> The <clef> element in MEI is currently only allowed within
> <clefchange> and <staffdef> elements. I can understand why, since <staff> is
> supposed to reflect musical linearity and not be affected by system breaks,
> which is more a physical artifact of page layout. So, a <clef> should only
> occur if a) it's part of the staff definition, or b) it's changing.
> >>>>>
> >>>>> *However*, an interesting question comes up when encoding clefs at
> the beginning of systems. Currently, the only way to encode this is to wrap
> a <clef> in a <clefchange>, but for most of the time, it's not actually
> changing; it's only a "courtesy" clef.
> >>>>>
> >>>>> So, to give an example. Suppose the following:
> >>>>>
> >>>>> <staff n="1">
> >>>>> <layer n="1">
> >>>>> <sb n="1"/>
> >>>>> <clef line="3" shape="F"/>
> >>>>> <note pname="f" oct="3"/>
> >>>>> <note pname="g" oct="3"/>
> >>>>> ...
> >>>>> <sb n="2" />
> >>>>> <clef line="3" shape="F"/>
> >>>>> <note pname="c" oct="3"/>
> >>>>> <note pname="d" oct="3"/>
> >>>>>
> >>>>> ...etc...
> >>>>>
> >>>>> This is currently invalid MEI, but I'm not really sure how to capture
> the clefs at the beginning of each system without a) incorporating them into
> a <clefchange> (semantically wrong), b) allowing <clef> directly within
> layer, or (really crazy) c) changing <sb> to include clef information (e.g.,
> allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on
> <sb>.
> >>>>>
> >>>>> What I'd like to suggest is option b), but I'm sure there's a very
> good reason why I'm wrong. :)
> >>>>>
> >>>>> -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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110531/a49f84a3/attachment.htm>

From andrew.hankinson at mail.mcgill.ca  Tue May 31 09:37:52 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 31 May 2011 07:37:52 +0000
Subject: [MEI-L] clef as milestone element
In-Reply-To: <23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
Message-ID: <43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>

Hi Thomas,

No, I think you got it right. The problem is that we need a minimal way of marking a system break within the flow of the music. We came up with the idea of using a @systemref on <sb /> to point to a <system> element in the separate layout tree. That's fine, and fairly unobtrusive. Parsers can ignore any <sb />s if they want to do their own layout, and thus ignore any of the information in the <layout /> tree.

The problem is that <clef> and <custos> occupy an uncomfortable middle ground between being a musical element and a purely layout element. We *could* store them on the <system/> element, and I might be able to be convinced of this, but that would seem to be placing musical structures outside of the flow of the music. I do recognize, however, that I just finished making a case that these were more layout than musical. I'm a study in opposites some days. :)

Because it helps me to visualize how this might look, you're saying:

<layout>
  ...
  <system id="1">
     <clef ... />
     <custos ... />
  </system>
  ...
</layout>

<staff>
   <layer>
     ... 
     <sb systemref="1" />
     ....


-Andrew

(Note: Here's a plug for the latest version of the layout module on the MEI Incubator. Freshly updated! https://gershwin.music.mcgill.ca/trac/mei-incubator/browser/mei-incubator/layout)

On 2011-05-31, at 3:13 AM, TW wrote:

> Hi Andrew,
> 
> do you want the clef element for rendering purposes?  As far as I
> understand, for storing rendering information you're developing a
> separate layout tree anyway, so can't you record the clef (and even
> the system break) there?  Then the musical data doesn't get cluttered
> with layout information.  When there are different readings of
> differing length, then different layouts are required anyway.  When
> generating performance material, different layouts for the score and
> each individual part are required as well (or would this be out of
> scope?).
> 
> I hope I didn't totally misunderstand the issue.
> 
> Thomas Weber
> 
> 
> 2011/5/31 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>> Hi all,
>> 
>> tl;dr Should clefs be considered a milestone element?
>> 
>> The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.
>> 
>> *However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.
>> 
>> So, to give an example. Suppose the following:
>> 
>> <staff n="1">
>>  <layer n="1">
>>    <sb n="1"/>
>>    <clef line="3" shape="F"/>
>>    <note pname="f" oct="3"/>
>>    <note pname="g" oct="3"/>
>>    ...
>>    <sb n="2" />
>>    <clef line="3" shape="F"/>
>>    <note pname="c" oct="3"/>
>>    <note pname="d" oct="3"/>
>> 
>>    ...etc...
>> 
>> This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.
>> 
>> What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)
>> 
>> -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



From laurent at music.mcgill.ca  Tue May 31 11:06:18 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Tue, 31 May 2011 11:06:18 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <22636_1306827545_4DE49B19_22636_363_1_43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<22636_1306827545_4DE49B19_22636_363_1_43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
Message-ID: <BANLkTi=tav_yfAYyykW0G6_n_A_K-6qrLA@mail.gmail.com>

Hi all,

I agree with Andrew that it would be much straightforward to allow
<clef> within <layer>. That does not mean that is has to be present.

Laurent


On Tue, May 31, 2011 at 9:37 AM, Andrew Hankinson, Mr
<andrew.hankinson at mail.mcgill.ca> wrote:
> Hi Thomas,
>
> No, I think you got it right. The problem is that we need a minimal way of marking a system break within the flow of the music. We came up with the idea of using a @systemref on <sb /> to point to a <system> element in the separate layout tree. That's fine, and fairly unobtrusive. Parsers can ignore any <sb />s if they want to do their own layout, and thus ignore any of the information in the <layout /> tree.
>
> The problem is that <clef> and <custos> occupy an uncomfortable middle ground between being a musical element and a purely layout element. We *could* store them on the <system/> element, and I might be able to be convinced of this, but that would seem to be placing musical structures outside of the flow of the music. I do recognize, however, that I just finished making a case that these were more layout than musical. I'm a study in opposites some days. :)
>
> Because it helps me to visualize how this might look, you're saying:
>
> <layout>
> ?...
> ?<system id="1">
> ? ? <clef ... />
> ? ? <custos ... />
> ?</system>
> ?...
> </layout>
>
> <staff>
> ? <layer>
> ? ? ...
> ? ? <sb systemref="1" />
> ? ? ....
>
>
> -Andrew
>
> (Note: Here's a plug for the latest version of the layout module on the MEI Incubator. Freshly updated! https://gershwin.music.mcgill.ca/trac/mei-incubator/browser/mei-incubator/layout)
>
> On 2011-05-31, at 3:13 AM, TW wrote:
>
>> Hi Andrew,
>>
>> do you want the clef element for rendering purposes? ?As far as I
>> understand, for storing rendering information you're developing a
>> separate layout tree anyway, so can't you record the clef (and even
>> the system break) there? ?Then the musical data doesn't get cluttered
>> with layout information. ?When there are different readings of
>> differing length, then different layouts are required anyway. ?When
>> generating performance material, different layouts for the score and
>> each individual part are required as well (or would this be out of
>> scope?).
>>
>> I hope I didn't totally misunderstand the issue.
>>
>> Thomas Weber
>>
>>
>> 2011/5/31 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>>> Hi all,
>>>
>>> tl;dr Should clefs be considered a milestone element?
>>>
>>> The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.
>>>
>>> *However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.
>>>
>>> So, to give an example. Suppose the following:
>>>
>>> <staff n="1">
>>> ?<layer n="1">
>>> ? ?<sb n="1"/>
>>> ? ?<clef line="3" shape="F"/>
>>> ? ?<note pname="f" oct="3"/>
>>> ? ?<note pname="g" oct="3"/>
>>> ? ?...
>>> ? ?<sb n="2" />
>>> ? ?<clef line="3" shape="F"/>
>>> ? ?<note pname="c" oct="3"/>
>>> ? ?<note pname="d" oct="3"/>
>>>
>>> ? ?...etc...
>>>
>>> This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.
>>>
>>> What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)
>>>
>>> -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
>
>


From zupftom at googlemail.com  Tue May 31 13:24:04 2011
From: zupftom at googlemail.com (TW)
Date: Tue, 31 May 2011 13:24:04 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
Message-ID: <BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>

2011/5/31 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>
> Because it helps me to visualize how this might look, you're saying:
>
> <layout>
> ?...
> ?<system id="1">
> ? ? <clef ... />
> ? ? <custos ... />
> ?</system>
> ?...
> </layout>
>
> <staff>
> ? <layer>
> ? ? ...
> ? ? <sb systemref="1" />
> ? ? ....
>

The question is how the layout tree will look like inside the system
element.  There will also have to be staffs, right?  As the <staff>
element is already taken, let me call them <systemstaff>s.  Would it
make sense to have something similar to <staffdef>, like:

<layout>
 ...
 <system id="1">
   <systemstaff staffref="staff1">
     <systemstaffdef clef.line= "2" clef.shape= "G">
     <custos ... />
   </systemstaff>
 </system>
 ...
</layout>

<staff n="staff1">
  <layer>
    ...
    <sb systemref="1" />
    ....


What I'm most interested in is: how will it be possible to define the
graphical properties of other elements?  How can e.g. the horizontal
position of notes and the vertical position of articulation marks be
defined, if desired?  How will elements that are split between
<system>s be represented, like split beams, slurs or brackets?  Do you
already have ideas for this?

>
> (Note: Here's a plug for the latest version of the layout module on the MEI Incubator. Freshly updated! https://gershwin.music.mcgill.ca/trac/mei-incubator/browser/mei-incubator/layout)
>

I think line 119 has to be:
  <desc>Points to a system element ID in the layout section.</desc>
or maybe something like
  <desc>Points to one or more system element IDs in the layout section.</desc>
as the type is IDREFS.

In line 2, quotes seem to be missing.

Thomas


From laurent at music.mcgill.ca  Tue May 31 14:26:28 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Tue, 31 May 2011 14:26:28 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
Message-ID: <BANLkTi=1J05JTquqC7uKAKG4TUS_HWdMgQ@mail.gmail.com>

>
>>
>> (Note: Here's a plug for the latest version of the layout module on the MEI Incubator. Freshly updated! https://gershwin.music.mcgill.ca/trac/mei-incubator/browser/mei-incubator/layout)
>>
>
> I think line 119 has to be:
> ?<desc>Points to a system element ID in the layout section.</desc>
> or maybe something like
> ?<desc>Points to one or more system element IDs in the layout section.</desc>
> as the type is IDREFS.
>
> In line 2, quotes seem to be missing.
>

And why do we have a mode="replace" (line 87) and also a mode="delete"
and mode="add" (lines 127/8) for ident="att.pb.vis" ? Do we need both?

Laurent

> Thomas
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>


From andrew.hankinson at mail.mcgill.ca  Tue May 31 15:48:38 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 31 May 2011 13:48:38 +0000
Subject: [MEI-L] clef as milestone element
In-Reply-To: <29000_1306844819_4DE4DE92_29000_1028_1_BANLkTi=1J05JTquqC7uKAKG4TUS_HWdMgQ@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<29000_1306844819_4DE4DE92_29000_1028_1_BANLkTi=1J05JTquqC7uKAKG4TUS_HWdMgQ@mail.gmail.com>
Message-ID: <7459965C-6363-46D5-96D0-68161DA53CD0@mail.mcgill.ca>

The best we can guess is that it's due to some bug in Roma, or some quirk of the transformation process. Sometimes things don't end up in the output unless you delete and re-add their new definition.


On 2011-05-31, at 8:26 AM, Laurent Pugin wrote:

>> 
>>> 
>>> (Note: Here's a plug for the latest version of the layout module on the MEI Incubator. Freshly updated! https://gershwin.music.mcgill.ca/trac/mei-incubator/browser/mei-incubator/layout)
>>> 
>> 
>> I think line 119 has to be:
>>  <desc>Points to a system element ID in the layout section.</desc>
>> or maybe something like
>>  <desc>Points to one or more system element IDs in the layout section.</desc>
>> as the type is IDREFS.
>> 
>> In line 2, quotes seem to be missing.
>> 
> 
> And why do we have a mode="replace" (line 87) and also a mode="delete"
> and mode="add" (lines 127/8) for ident="att.pb.vis" ? Do we need both?
> 
> Laurent
> 
>> Thomas
>> 
>> _______________________________________________
>> 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



From andrew.hankinson at mail.mcgill.ca  Tue May 31 16:26:55 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 31 May 2011 14:26:55 +0000
Subject: [MEI-L] clef as milestone element
In-Reply-To: <29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
Message-ID: <73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>

Hi Thomas,

I'll answer inline below:


<layout>
...
<system id="1">
  <systemstaff staffref="staff1">
    <systemstaffdef clef.line= "2" clef.shape= "G">
    <custos ... />
  </systemstaff>
</system>
...
</layout>

<staff n="staff1">
 <layer>
   ...
   <sb systemref="1" />
   ....

I'm not sure what this would actually give us that we don't already (mostly) have. <systemstaff /> seems to exist only so we could define <systemstaffdef />. Since there is already a relationship between from <sb /> to the <system />, having a pointer the other way is unecessary (also, since multiple <sb />s could refer to the same system, you want the reference going this way).

Actually, we could just put the clef information on <system /> itself; e.g.,

<system clef.line="3" clef.shape="C" />

or something like that. Any thoughts about this?


What I'm most interested in is: how will it be possible to define the
graphical properties of other elements?  How can e.g. the horizontal
position of notes and the vertical position of articulation marks be
defined, if desired?  How will elements that are split between
<system>s be represented, like split beams, slurs or brackets?  Do you
already have ideas for this?

We're not trying to replicate lilypond or any of the other notational drawing programs, so precise drawing information is "out of scope" for our purposes. We define the horizontal/vertical position of notes and anything else via the <facs /> system, where we draw bounding boxes around all the musical elements and then refer to them by ID. The bounding boxes give the absolute x/y coordinates (ulx uly), (lrx, lry). We're always doing it in reference to a page image, so we have a certain luxury there.

Since elements that are split between systems still belong to a staff, we don't have to worry about it. For example:

<staff>
   <layer>
     <note xml:id="n1" />
     <sb />
     <note xml:id="n2" />
   </layer>
   <slur startid="n1" endid="n2" />
</staff>


I think line 119 has to be:
 <desc>Points to a system element ID in the layout section.</desc>
or maybe something like
 <desc>Points to one or more system element IDs in the layout section.</desc>
as the type is IDREFS.

In line 2, quotes seem to be missing.

Thanks! I've fixed and committed. The power of community coding at its finest. :)

-A


Thomas

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From laurent at music.mcgill.ca  Tue May 31 17:14:58 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Tue, 31 May 2011 17:14:58 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <31249_1306852028_4DE4FABB_31249_201_1_73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<31249_1306852028_4DE4FABB_31249_201_1_73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
Message-ID: <BANLkTinpahiRW1WWUc16rfjiMkhueQkSEA@mail.gmail.com>

Hi all,

In my opinion, that layout tree should be used for encoding
information that cannot (or can very hardly) be represented in the
logical tree. We probably agree that page information and system
information are a good examples because of the approach taken to
encode the logical tree (i.e., pb and sb are milestones). Now, because
in music notation, there is no clear cutting point between what
belongs to the music itself and what belongs to the layout, we have to
have some flexibility because it is never going to be possible to
decide where to put things if they have to go only into one place. As
a provocation, we could say that measures could also belong to the
layout. It is possible to process the music data without knowing
anything about the measures (except maybe for the repetition bars, and
they could be milestones as well).

I have the impression that it is going to be simpler to avoid to use
the layout tree whenever it is possible. For example, if I have one
single source, and I want to encode x and y position, why shouldn't I
put them in the @x and @y in the logical tree? Now of course, if I
have several sources with different positions, then obviously I cannot
do that. In that case, an option could be to have several layout trees
(one per source), store the x and y position in the respective layout
tree, with its elements pointing to the logical tree. Does it make
sense?

It does not seems very different for me to have several options as we
already have, for example, for representing beams, that is <beam>,
@beam or <beamspan>. That is why I think having a little bit more
flexibility with <clef> would be useful in some uses of MEI.

All the best,
Laurent

On Tue, May 31, 2011 at 4:26 PM, Andrew Hankinson, Mr
<andrew.hankinson at mail.mcgill.ca> wrote:
> Hi Thomas,
>
> I'll answer inline below:
>
>
> <layout>
> ...
> <system id="1">
> ?<systemstaff staffref="staff1">
> ? ?<systemstaffdef clef.line= "2" clef.shape= "G">
> ? ?<custos ... />
> ?</systemstaff>
> </system>
> ...
> </layout>
>
> <staff n="staff1">
> ?<layer>
> ? ...
> ? <sb systemref="1" />
> ? ....
>
> I'm not sure what this would actually give us that we don't already (mostly) have. <systemstaff /> seems to exist only so we could define <systemstaffdef />. Since there is already a relationship between from <sb /> to the <system />, having a pointer the other way is unecessary (also, since multiple <sb />s could refer to the same system, you want the reference going this way).
>
> Actually, we could just put the clef information on <system /> itself; e.g.,
>
> <system clef.line="3" clef.shape="C" />
>
> or something like that. Any thoughts about this?
>
>
> What I'm most interested in is: how will it be possible to define the
> graphical properties of other elements? ?How can e.g. the horizontal
> position of notes and the vertical position of articulation marks be
> defined, if desired? ?How will elements that are split between
> <system>s be represented, like split beams, slurs or brackets? ?Do you
> already have ideas for this?
>
> We're not trying to replicate lilypond or any of the other notational drawing programs, so precise drawing information is "out of scope" for our purposes. We define the horizontal/vertical position of notes and anything else via the <facs /> system, where we draw bounding boxes around all the musical elements and then refer to them by ID. The bounding boxes give the absolute x/y coordinates (ulx uly), (lrx, lry). We're always doing it in reference to a page image, so we have a certain luxury there.
>
> Since elements that are split between systems still belong to a staff, we don't have to worry about it. For example:
>
> <staff>
> ? <layer>
> ? ? <note xml:id="n1" />
> ? ? <sb />
> ? ? <note xml:id="n2" />
> ? </layer>
> ? <slur startid="n1" endid="n2" />
> </staff>
>
>
> I think line 119 has to be:
> ?<desc>Points to a system element ID in the layout section.</desc>
> or maybe something like
> ?<desc>Points to one or more system element IDs in the layout section.</desc>
> as the type is IDREFS.
>
> In line 2, quotes seem to be missing.
>
> Thanks! I've fixed and committed. The power of community coding at its finest. :)
>
> -A
>
>
> Thomas
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de<mailto: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
>
>


From raffaeleviglianti at gmail.com  Tue May 31 18:02:49 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Tue, 31 May 2011 17:02:49 +0100
Subject: [MEI-L] clef as milestone element
In-Reply-To: <7459965C-6363-46D5-96D0-68161DA53CD0@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<29000_1306844819_4DE4DE92_29000_1028_1_BANLkTi=1J05JTquqC7uKAKG4TUS_HWdMgQ@mail.gmail.com>
	<7459965C-6363-46D5-96D0-68161DA53CD0@mail.mcgill.ca>
Message-ID: <BANLkTi=zCR3704a8YyOD7xKckKX4JWijmQ@mail.gmail.com>

On Tue, May 31, 2011 at 2:48 PM, Andrew Hankinson, Mr <
andrew.hankinson at mail.mcgill.ca> wrote:

> The best we can guess is that it's due to some bug in Roma, or some quirk
> of the transformation process. Sometimes things don't end up in the output
> unless you delete and re-add their new definition.
>
>
Hi Andrew, I replicated the error with replace on my machine... I'll bring
the issue to Sebastian Rahtz's attention and see if he may want to fix how
Roma handles replace vs delete/add.

Best,
Raffaele



>
> On 2011-05-31, at 8:26 AM, Laurent Pugin wrote:
>
> >>
> >>>
> >>> (Note: Here's a plug for the latest version of the layout module on the
> MEI Incubator. Freshly updated!
> https://gershwin.music.mcgill.ca/trac/mei-incubator/browser/mei-incubator/layout
> )
> >>>
> >>
> >> I think line 119 has to be:
> >>  <desc>Points to a system element ID in the layout section.</desc>
> >> or maybe something like
> >>  <desc>Points to one or more system element IDs in the layout
> section.</desc>
> >> as the type is IDREFS.
> >>
> >> In line 2, quotes seem to be missing.
> >>
> >
> > And why do we have a mode="replace" (line 87) and also a mode="delete"
> > and mode="add" (lines 127/8) for ident="att.pb.vis" ? Do we need both?
> >
> > Laurent
> >
> >> Thomas
> >>
> >> _______________________________________________
> >> 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/20110531/1ae27316/attachment.htm>

From zupftom at googlemail.com  Tue May 31 22:23:15 2011
From: zupftom at googlemail.com (TW)
Date: Tue, 31 May 2011 22:23:15 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
Message-ID: <BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>

2011/5/31 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>
> <layout>
> ...
> <system id="1">
> ?<systemstaff staffref="staff1">
> ? ?<systemstaffdef clef.line= "2" clef.shape= "G">
> ? ?<custos ... />
> ?</systemstaff>
> </system>
> ...
> </layout>
>
> <staff n="staff1">
> ?<layer>
> ? ...
> ? <sb systemref="1" />
> ? ....
>
> I'm not sure what this would actually give us that we don't already (mostly) have. <systemstaff /> seems to exist only so we could define <systemstaffdef />.

I don't understand how the staff's position can be recorded without
having some kind of staff element in the layout tree?

> Since there is already a relationship between from <sb /> to the <system />, having a pointer the other way is unecessary (also, since multiple <sb />s could refer to the same system, you want the reference going this way).
>

You mean @staffref?

> Actually, we could just put the clef information on <system /> itself; e.g.,
>
> <system clef.line="3" clef.shape="C" />
>

I'm confused.  A clef is on the staff level, not the system level, right?

>
> We're not trying to replicate lilypond or any of the other notational drawing programs, so precise drawing information is "out of scope" for our purposes. We define the horizontal/vertical position of notes and anything else via the <facs /> system, where we draw bounding boxes around all the musical elements and then refer to them by ID. The bounding boxes give the absolute x/y coordinates (ulx uly), (lrx, lry). We're always doing it in reference to a page image, so we have a certain luxury there.
>

Then I'm misunderstanding something.  I thought the layout element
would be for *generating* a rendition of the music notation, not to
describe some facsimile?

> Since elements that are split between systems still belong to a staff, we don't have to worry about it. For example:
>
> <staff>
> ? <layer>
> ? ? <note xml:id="n1" />
> ? ? <sb />
> ? ? <note xml:id="n2" />
> ? </layer>
> ? <slur startid="n1" endid="n2" />
> </staff>
>

I'm thinking of the layout information.  A split element consist of
two or more separate graphical elements.  If positioning information
shall be recorded, then a single set of positioning attributes is not
enough.

Are we talking past each other?

Thomas


From andrew.hankinson at mail.mcgill.ca  Tue May 31 23:17:30 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 31 May 2011 21:17:30 +0000
Subject: [MEI-L] clef as milestone element
In-Reply-To: <8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
Message-ID: <EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>


On 2011-05-31, at 4:23 PM, TW wrote:

> 2011/5/31 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>> 
>> <layout>
>> ...
>> <system id="1">
>>  <systemstaff staffref="staff1">
>>    <systemstaffdef clef.line= "2" clef.shape= "G">
>>    <custos ... />
>>  </systemstaff>
>> </system>
>> ...
>> </layout>
>> 
>> <staff n="staff1">
>>  <layer>
>>   ...
>>   <sb systemref="1" />
>>   ....
>> 
>> I'm not sure what this would actually give us that we don't already (mostly) have. <systemstaff /> seems to exist only so we could define <systemstaffdef />.
> 
> I don't understand how the staff's position can be recorded without
> having some kind of staff element in the layout tree?

The location of a staff doesn't have to be recorded, since it's not a "physical" thing -- it's really just a way of recording a continuous sequence of notes. A system, however, does have a physical location.

Using the facsimile references, you would record locations of systems by using pointers between elements to refer to a zone on an image. In a grossly truncated example:

<facs id="f1" ulx="1" uly="1" lrx="10" lry="10" />
...
<system facs="f1" />
...

This would define a 9px square box at (1,1) and (10,10) on the image that corresponds to a (very tiny) system on the image. The "f1" id on facs is the same as the value given in the @facs attribute on system.

> 
>> Since there is already a relationship between from <sb /> to the <system />, having a pointer the other way is unecessary (also, since multiple <sb />s could refer to the same system, you want the reference going this way).
>> 
> 
> You mean @staffref?

Yes. You wouldn't need to define a physical location to a *staff*, since a staff is really the concatenation of systems. It's a terminology thing. I like thinking about musicians in rehearsal to understand what nomenclature to use. I often hear things like "On the second page, first system, second measure...", which to me gives a fairly accurate coordinate system on where to find the item in question. 


> 
>> Actually, we could just put the clef information on <system /> itself; e.g.,
>> 
>> <system clef.line="3" clef.shape="C" />
>> 
> 
> I'm confused.  A clef is on the staff level, not the system level, right?

This was my original out-loud thinking. *Most* traditional uses of clef is staff-level, since the clef at the beginning of every *system* is a courtesy clef--an aid to the performer. HOWEVER, if you want to encode the location of <clef> on a system, it is not technically a new staff definition, but also not a clef change. So we end up with a courtesy clef that cannot be encoded.


> 
>> 
>> We're not trying to replicate lilypond or any of the other notational drawing programs, so precise drawing information is "out of scope" for our purposes. We define the horizontal/vertical position of notes and anything else via the <facs /> system, where we draw bounding boxes around all the musical elements and then refer to them by ID. The bounding boxes give the absolute x/y coordinates (ulx uly), (lrx, lry). We're always doing it in reference to a page image, so we have a certain luxury there.
>> 
> 
> Then I'm misunderstanding something.  I thought the layout element
> would be for *generating* a rendition of the music notation, not to
> describe some facsimile?

No, the layout element would be to separate the physical characteristics of a page image from the musical characteristics. The idea being that in most cases (should the MEI be imported into a notation editor) you would want to ignore this information and allow the notation editor to do the layout itself, but in some cases (Optical Music Recognition, for example) you would want to be able to define and correlate physical characteristics of the printed image with musical elements -- the location of systems, notes, rests, etc.

> 
>> Since elements that are split between systems still belong to a staff, we don't have to worry about it. For example:
>> 
>> <staff>
>>   <layer>
>>     <note xml:id="n1" />
>>     <sb />
>>     <note xml:id="n2" />
>>   </layer>
>>   <slur startid="n1" endid="n2" />
>> </staff>
>> 
> 
> I'm thinking of the layout information.  A split element consist of
> two or more separate graphical elements.  If positioning information
> shall be recorded, then a single set of positioning attributes is not
> enough.
> 
> Are we talking past each other?

I think maybe we are. The layout element is (currently) useful for our specific purpose in OMR. How musical shapes are drawn (e.g., vector graphics), and where they should be positioned are, in my opinion, already covered by formats like PostScript. 

We published a paper at last year's ISMIR that describes our use of the <facs> system for defining musical element positions on an image. If you're interested, you can read it here: http://transientstudent.net/sites/transientstudent.net/files/hankinson_ismir2010_paper.pdf

-Andrew


> 
> Thomas
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From laurent at music.mcgill.ca  Wed Jun  1 09:42:30 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Wed, 1 Jun 2011 09:42:30 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <9754_1306876659_4DE55AF3_9754_67_1_EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<9754_1306876659_4DE55AF3_9754_67_1_EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
Message-ID: <BANLkTinAzqYCH1JF=f9AnVyb2w6_EDm2OA@mail.gmail.com>

> Yes. You wouldn't need to define a physical location to a *staff*, since a staff is really the concatenation of systems. It's a terminology thing. I like thinking about musicians in rehearsal to understand what nomenclature to use. I often hear things like "On the second page, first system, second measure...", which to me gives a fairly accurate coordinate system on where to find the item in question.
>

That is just because you already know which staff to look at :)

Laurent


>
>>
>>> Actually, we could just put the clef information on <system /> itself; e.g.,
>>>
>>> <system clef.line="3" clef.shape="C" />
>>>
>>
>> I'm confused. ?A clef is on the staff level, not the system level, right?
>
> This was my original out-loud thinking. *Most* traditional uses of clef is staff-level, since the clef at the beginning of every *system* is a courtesy clef--an aid to the performer. HOWEVER, if you want to encode the location of <clef> on a system, it is not technically a new staff definition, but also not a clef change. So we end up with a courtesy clef that cannot be encoded.
>
>
>>
>>>
>>> We're not trying to replicate lilypond or any of the other notational drawing programs, so precise drawing information is "out of scope" for our purposes. We define the horizontal/vertical position of notes and anything else via the <facs /> system, where we draw bounding boxes around all the musical elements and then refer to them by ID. The bounding boxes give the absolute x/y coordinates (ulx uly), (lrx, lry). We're always doing it in reference to a page image, so we have a certain luxury there.
>>>
>>
>> Then I'm misunderstanding something. ?I thought the layout element
>> would be for *generating* a rendition of the music notation, not to
>> describe some facsimile?
>
> No, the layout element would be to separate the physical characteristics of a page image from the musical characteristics. The idea being that in most cases (should the MEI be imported into a notation editor) you would want to ignore this information and allow the notation editor to do the layout itself, but in some cases (Optical Music Recognition, for example) you would want to be able to define and correlate physical characteristics of the printed image with musical elements -- the location of systems, notes, rests, etc.
>
>>
>>> Since elements that are split between systems still belong to a staff, we don't have to worry about it. For example:
>>>
>>> <staff>
>>> ? <layer>
>>> ? ? <note xml:id="n1" />
>>> ? ? <sb />
>>> ? ? <note xml:id="n2" />
>>> ? </layer>
>>> ? <slur startid="n1" endid="n2" />
>>> </staff>
>>>
>>
>> I'm thinking of the layout information. ?A split element consist of
>> two or more separate graphical elements. ?If positioning information
>> shall be recorded, then a single set of positioning attributes is not
>> enough.
>>
>> Are we talking past each other?
>
> I think maybe we are. The layout element is (currently) useful for our specific purpose in OMR. How musical shapes are drawn (e.g., vector graphics), and where they should be positioned are, in my opinion, already covered by formats like PostScript.
>
> We published a paper at last year's ISMIR that describes our use of the <facs> system for defining musical element positions on an image. If you're interested, you can read it here: http://transientstudent.net/sites/transientstudent.net/files/hankinson_ismir2010_paper.pdf
>
> -Andrew
>
>
>>
>> Thomas
>>
>> _______________________________________________
>> 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
>
>


From zupftom at googlemail.com  Wed Jun  1 11:59:38 2011
From: zupftom at googlemail.com (TW)
Date: Wed, 1 Jun 2011 11:59:38 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
Message-ID: <BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>

2011/5/31 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>
> It's a terminology thing. I like thinking about musicians in rehearsal to understand what nomenclature to use. I often hear things like "On the second page, first system, second measure...",

According to my English music notation books, a system is the
"container" of staffs (in the layout sense, my "systemstaffs").  Like
Ted Ross, The Art of Music Engraving and Processing, p. 151: "A
'systemic' barline [,,,] is used for keyboard instruments with
two-stave systems [...]."  Or George Heussenstamm, The Norton Manual
of Music Notation, p. 87: "When two or more staves are connected in
this way they form a system."  In my understanding as a non-native
English speaker, this therefore makes no sense:

>>>
>>> <system clef.line="3" clef.shape="C" />
>>>

because every staff in the system might require a different clef.

>>
>> Then I'm misunderstanding something.  I thought the layout element
>> would be for *generating* a rendition of the music notation, not to
>> describe some facsimile?
>
> No,

This clarifies a lot.

> The idea being that in most cases (should the MEI be imported into a notation editor) you would want to ignore this information and allow the notation editor to do the layout itself, but in some cases (Optical Music Recognition, for example) you would want to be able to define and correlate physical characteristics of the printed image with musical elements -- the location of systems, notes, rests, etc.
>

I'm pretty new to MEI and don't know what MEI's envisaged spectrum of
uses is, but for decent digital editions, I don't think it's enough to
just run the music through a notation editor or a formatter.  It of
course depends on the complexity of the music, but in general, for a
certain level of quality it's necessary that some human editor revises
the notation program's decisions.  And if there are situations that
are maybe musically erroneous or incomplete but shall be presented in
this unedited form, then the notation program might produce garbage or
refuse to process the data.

Another problem I see is that when the MEI data is corrected or
otherwise edited, then you have to do the entire process of formatting
and manual cleanup again, or somehow synchronize with the formatted
data.  And I'm not only thinking about "dead" printouts or vector
graphics renditions.  What about interactive ones that might be able
to display additional information for certain elements, highlight and
(un-)hide elements or integrate with other sources and a special
interface? Can this be achieved without storing the "rendering hints"
and the semantic data in a form that makes the relationship between
graphics and actual data clear?

I thought this was what the layout tree would be about.  So...

>>
>> Are we talking past each other?
>
> I think maybe we are.

we definitely are.

Thomas


From andrew.hankinson at mail.mcgill.ca  Wed Jun  1 18:03:41 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Wed, 1 Jun 2011 16:03:41 +0000
Subject: [MEI-L] Layout module (WAS: clef as milestone element)
In-Reply-To: <26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
Message-ID: <0CFDCE2C-3101-4D7F-8CDD-4601279136F8@mail.mcgill.ca>

Hi all,

I've changed the subject of this discussion, since we seem to be getting more into the layout module.


It's a terminology thing. I like thinking about musicians in rehearsal to understand what nomenclature to use. I often hear things like "On the second page, first system, second measure...",

According to my English music notation books, a system is the
"container" of staffs (in the layout sense, my "systemstaffs").  Like
Ted Ross, The Art of Music Engraving and Processing, p. 151: "A
'systemic' barline [,,,] is used for keyboard instruments with
two-stave systems [...]."  Or George Heussenstamm, The Norton Manual
of Music Notation, p. 87: "When two or more staves are connected in
this way they form a system."  In my understanding as a non-native
English speaker, this therefore makes no sense:


<system clef.line="3" clef.shape="C" />


because every staff in the system might require a different clef.

You are, of course, right. This was a moment of mental weakness on my part, and I hadn't really though through that suggestion.

The "container" is correct, but I think that's really a "post-hoc" analysis of what a system is; that is, if you just have printed music to look at, everything is going to be in a system, because that's the way printed music works. However, for more abstract representations, like most music encoding languages use, there is no need for staves to be directly related to a system. This is usually taken care of by the rendering function of the notation editing software, so that it can dynamically re-arrange the notes into optimal spacings.



Then I'm misunderstanding something.  I thought the layout element
would be for *generating* a rendition of the music notation, not to
describe some facsimile?

No,

This clarifies a lot.

The idea being that in most cases (should the MEI be imported into a notation editor) you would want to ignore this information and allow the notation editor to do the layout itself, but in some cases (Optical Music Recognition, for example) you would want to be able to define and correlate physical characteristics of the printed image with musical elements -- the location of systems, notes, rests, etc.


I'm pretty new to MEI and don't know what MEI's envisaged spectrum of
uses is, but for decent digital editions, I don't think it's enough to
just run the music through a notation editor or a formatter.  It of
course depends on the complexity of the music, but in general, for a
certain level of quality it's necessary that some human editor revises
the notation program's decisions.  And if there are situations that
are maybe musically erroneous or incomplete but shall be presented in
this unedited form, then the notation program might produce garbage or
refuse to process the data.

Again, you're right. For decent digital editions you would want human oversight for producing printed music, since it can look like garbage. However, we're not producing printed music. We're using MEI to index collections of printed music using OMR: We scan the digital image, retrieve all the positions of all the musical elements, along with their "semantic" musical meaning, and encode it in MEI. We then use this encoding for searching and indexing the content of the book, and tie all of the elements on the page back to its physical location.

We never render the notation directly, but given this representation we can do other cool things, like automatic analysis of melody, harmony or rhythm. That's on top of making large amounts of printed music searchable. If you're just doing editions of a single composer, you have a certain luxury to take your time and get it right; if you're digitizing the print music collection of the British Library, or even any decent sized university library it's questionable whether one person could even get through all the sources in a lifetime to correct the mistakes of automatic recognition, let alone optimally edit it for layout.

We've had three people correcting the output of one book now for over three months, just correcting the shape recognition errors, and we're not quite done yet. Granted, this is a research project so we're not optimizing for speed and throughput, but it's definitely not a task that can be done quickly for any source of a given size.



Another problem I see is that when the MEI data is corrected or
otherwise edited, then you have to do the entire process of formatting
and manual cleanup again, or somehow synchronize with the formatted
data.  And I'm not only thinking about "dead" printouts or vector
graphics renditions.  What about interactive ones that might be able
to display additional information for certain elements, highlight and
(un-)hide elements or integrate with other sources and a special
interface? Can this be achieved without storing the "rendering hints"
and the semantic data in a form that makes the relationship between
graphics and actual data clear?

MEI currently does have functionality for this. For most musical elements (notes, rests, clefs, etc.), there is the @ho and @vo attributes that specify a horizontal and vertical offset, and @x and @y for encoding a placement. For any notation renderer, then, it is entirely possible to store exact locations for these elements.

However, as anyone who has had to deal with moving between Sibelius and Finale knows, different notation programs render the same file differently. One application could choose to render a system on a different page, or cram more measures into a line. It all depends on their layout engine, their font, and what their designers considered "optimal" layout. So, storing objects in reference to absolute points is problematic, since one renderer may render differently than another.

So, for the types of displays you are talking about, you can either a) design your score and store the information in reference to a single renderer, knowing that it won't be displayed using anything else, b) design your score with "hints" about the positioning of certain elements, but knowing that most of the others will be left to the renderer to figure out, or c) design it with absolutely no layout information and leave it up to the rendering and layout capabilities of any software that a user chooses to open it in. This is the same, regardless of if it is going for a "dead" rendering, or a "live" interactive rendering.

All three are currently very do-able in MEI *without* the layout module. You can choose to use the @x, at y, or @ho, at vo attributes, and then <sb /> for encoding explicit system breaks, @bezier, @bulge, @curvedir on slurs and ties, and so on.

The layout module is designed to provide very minimal layout information in reference to the layout of an existing page. Early on in the design of this, we realized that there were very few new elements that needed to be added to make it work, and that didn't duplicate existing functionality in MEI. This was the <page> and <system> elements; the <layout> element was added as a container for these two.

Currently, the <system> element is used as a linker between a system break and a <facs> element. When you encounter an <sb />, it will link to a <system> element via the @systemref attribute; <system> then has an @facs attribute that points to a <facs> element that defines a bounding box around a zone on a given page image.

Is this ideal? or complete? Probably not. But I guess that's the point of Incubator projects -- put something out there and discuss and critique it openly.



I thought this was what the layout tree would be about.  So...


Are we talking past each other?

I think maybe we are.

we definitely are.

And that's fine. :)


Thomas

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From andrew.hankinson at mail.mcgill.ca  Wed Jun  1 18:25:56 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Wed, 1 Jun 2011 16:25:56 +0000
Subject: [MEI-L] clef as milestone element
In-Reply-To: <26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
Message-ID: <A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>

Before moving on from the <clef /> discussion, I'd like to try and bring in a consensus. The way I've heard it there are a number of options:

1. <clef /> is allowed directly in <layer />;

2. <clef /> is allowed in <sb />, explicitly used as a "cautionary" clef.

3. Cautionary clefs should be removed from the "musical" flow and placed in the <layout /> section.

4. Keep the status quo and use <staffdef> inside <staff> to indicate a cautionary clef.

While I personally think 2 is the most semantically useful option, I understand that 1 is perhaps the easiest in the short term. I'm not really comfortable with 3, since it removes a musical element from the "flow" of the staff, and 4 seems a bit stilted to me, overloading <staffdef> to not really define anything new about a parent staff.

So, I will choose to implement #1 as it seems to solve our immediate issue for the time being.

How I propose to solve this is to create a new Incubator project ("clef-milestone") and create an ODD file that makes the change. This can then be reviewed by the Technical Group and, if it's found worthy, rolled into the mainline MEI standard at some point, likely with revisions.

Should anyone want to use this in another project they can then create their own customization based on the ODD file. That way they can at least have a reference back to the deviations from the MEI core.

In the comments of the ODD file I will reference this discussion so that there's a way to return to it to re-evaluate the positions put forward here when it comes time to review the revision.

Does this sound reasonable?

-Andrew

From bohl at edirom.de  Tue Jun  7 09:52:59 2011
From: bohl at edirom.de (Benjamin Wolff Bohl)
Date: Tue, 07 Jun 2011 09:52:59 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
	<A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
Message-ID: <4DEDD8DB.9090708@edirom.de>

Hi everybody,

first thanks for the interesting discussion bringing some clarification 
on what the "layout" module is all about, etc.
I'd like to give some inline comments on this summary:

Am 01.06.2011 18:25, schrieb Andrew Hankinson, Mr:
> Before moving on from the<clef />  discussion, I'd like to try and bring in a consensus. The way I've heard it there are a number of options:
>
> 1.<clef />  is allowed directly in<layer />;
As you say below, this,of course , would solve your immediate problem 
but what if thinking of multiple layers on one staff; a clef would also 
affect the other layers, or am I mistaken? If so it would make no 
logical sense as part on a layer; it should be a direct child of staff.
> 2.<clef />  is allowed in<sb />, explicitly used as a "cautionary" clef.
On this point I agree with Raffaele (31.05.2011):

>     I agree that using clefchange and staffdef for courtesy clef
>     repetitions is a bit cumbersome, but I would advise against
>     overweighting <pb/> and <sb/>. In my opinion they should only
>     signify the break and contain nothing. A custos should occur
>     *before* (or occasionally after) the system break and not within
>     the system break. If you think about it, that is what happens on
>     the page. In the same way, the clef repetition should not be
>     attached to sb or pb.


> 3. Cautionary clefs should be removed from the "musical" flow and placed in the<layout />  section.
Actually this would be THE solution if we stick to the opinion, that the 
staff should be a virtual "endless" representation of the musical flow. 
The cautionary clefs are a rendition phenomenon and do not belong to the 
logic of the music but to the layout. In doing so the layout module 
would somewhat encode the engraving quality of a specific published edition.
> 4. Keep the status quo and use<staffdef>  inside<staff>  to indicate a cautionary clef.
True, this seems a bit of an overkill...

> While I personally think 2 is the most semantically useful option, I understand that 1 is perhaps the easiest in the short term.
> I'm not really comfortable with 3, since it removes a musical element from the "flow" of the staff,
> and 4 seems a bit stilted to me, overloading<staffdef>  to not really define anything new about a parent staff.
>
> So, I will choose to implement #1 as it seems to solve our immediate issue for the time being.
> How I propose to solve this is to create a new Incubator project ("clef-milestone") and create an ODD file that makes the change. This can then be reviewed by the Technical Group and, if it's found worthy, rolled into the mainline MEI standard at some point, likely with revisions.
>
> Should anyone want to use this in another project they can then create their own customization based on the ODD file. That way they can at least have a reference back to the deviations from the MEI core.
>
> In the comments of the ODD file I will reference this discussion so that there's a way to return to it to re-evaluate the positions put forward here when it comes time to review the revision.
>
> Does this sound reasonable?
Sounds reasonable, all theoretical ideas are only theoretical, whichever 
solution we opt for it has to be tested practically (option 4 obviously 
failed, as it resulted in this discussion ;-)


Best,
Benjamin
-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110607/8e6ca7c7/attachment.htm>

From laurent at music.mcgill.ca  Tue Jun  7 11:03:30 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Tue, 7 Jun 2011 11:03:30 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <11864_1307433278_4DEDD93E_11864_142_1_4DEDD8DB.9090708@edirom.de>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
	<A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
	<11864_1307433278_4DEDD93E_11864_142_1_4DEDD8DB.9090708@edirom.de>
Message-ID: <BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>

On Tue, Jun 7, 2011 at 9:52 AM, Benjamin Wolff Bohl <bohl at edirom.de> wrote:
> Hi everybody,
>
> first thanks for the interesting discussion bringing some clarification on
> what the "layout" module is all about, etc.
> I'd like to give some inline comments on this summary:
>
> Am 01.06.2011 18:25, schrieb Andrew Hankinson, Mr:
>
> Before moving on from the <clef /> discussion, I'd like to try and bring in
> a consensus. The way I've heard it there are a number of options:
>
> 1. <clef /> is allowed directly in <layer />;
>
> As you say below, this,of course , would solve your immediate problem but
> what if thinking of multiple layers on one staff; a clef would also affect
> the other layers, or am I mistaken? If so it would make no logical sense as
> part on a layer; it should be a direct child of staff.
>

You are right, but that is not very different from <clefchange> that
is also allowed in a <layer>. When it occurs on all layers at the same
time, I guess you will put it on all layers. Am I wrong?

> 2. <clef /> is allowed in <sb />, explicitly used as a "cautionary" clef.
>
> On this point I agree with Raffaele (31.05.2011):
>
> I agree that using clefchange and staffdef for courtesy clef repetitions is
> a bit cumbersome, but I would advise against overweighting <pb/> and <sb/>.
> In my opinion they should only signify the break and contain nothing. A
> custos should occur *before* (or occasionally after) the system break and
> not within the system break. If you think about it, that is what happens on
> the page. In the same way, the clef repetition should not be attached to sb
> or pb.
>
> 3. Cautionary clefs should be removed from the "musical" flow and placed in
> the <layout /> section.
>
> Actually this would be THE solution if we stick to the opinion, that the
> staff should be a virtual "endless" representation of the musical flow. The
> cautionary clefs are a rendition phenomenon and do not belong to the logic
> of the music but to the layout. In doing so the layout module would somewhat
> encode the engraving quality of a specific published edition.

So do <custos> because they could be inferred easily. Would you remove
them from the logic tree?

We have cases where the clef is missing - that is very frequent with
typographic prints. How would you encode this? Or when the clef is
wrong?

>
> 4. Keep the status quo and use <staffdef> inside <staff> to indicate a
> cautionary clef.
>
> True, this seems a bit of an overkill...
>
> While I personally think 2 is the most semantically useful option, I
> understand that 1 is perhaps the easiest in the short term.
>
> I'm not really comfortable with 3, since it removes a musical element from
> the "flow" of the staff,
>
> and 4 seems a bit stilted to me, overloading <staffdef> to not really define
> anything new about a parent staff.
>
> So, I will choose to implement #1 as it seems to solve our immediate issue
> for the time being.
>
> How I propose to solve this is to create a new Incubator project
> ("clef-milestone") and create an ODD file that makes the change. This can
> then be reviewed by the Technical Group and, if it's found worthy, rolled
> into the mainline MEI standard at some point, likely with revisions.
>
> Should anyone want to use this in another project they can then create their
> own customization based on the ODD file. That way they can at least have a
> reference back to the deviations from the MEI core.
>
> In the comments of the ODD file I will reference this discussion so that
> there's a way to return to it to re-evaluate the positions put forward here
> when it comes time to review the revision.
>
> Does this sound reasonable?
>
> Sounds reasonable, all theoretical ideas are only theoretical, whichever
> solution we opt for it has to be tested practically (option 4 obviously
> failed, as it resulted in this discussion ;-)
>
>
> Best,
> Benjamin
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>


From kepper at edirom.de  Tue Jun  7 11:22:10 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Tue, 7 Jun 2011 11:22:10 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
	<A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
	<11864_1307433278_4DEDD93E_11864_142_1_4DEDD8DB.9090708@edirom.de>
	<BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>
Message-ID: <3F0F20D3-63E6-49E7-B7A5-1C3328809118@edirom.de>


Am 07.06.2011 um 11:03 schrieb Laurent Pugin:

> On Tue, Jun 7, 2011 at 9:52 AM, Benjamin Wolff Bohl <bohl at edirom.de> wrote:
>> Hi everybody,
>> 
>> first thanks for the interesting discussion bringing some clarification on
>> what the "layout" module is all about, etc.
>> I'd like to give some inline comments on this summary:
>> 
>> Am 01.06.2011 18:25, schrieb Andrew Hankinson, Mr:
>> 
>> Before moving on from the <clef /> discussion, I'd like to try and bring in
>> a consensus. The way I've heard it there are a number of options:
>> 
>> 1. <clef /> is allowed directly in <layer />;
>> 
>> As you say below, this,of course , would solve your immediate problem but
>> what if thinking of multiple layers on one staff; a clef would also affect
>> the other layers, or am I mistaken? If so it would make no logical sense as
>> part on a layer; it should be a direct child of staff.
>> 
> 
> You are right, but that is not very different from <clefchange> that
> is also allowed in a <layer>. When it occurs on all layers at the same
> time, I guess you will put it on all layers. Am I wrong?

Although I have no example in mind currently, I'm pretty sure that I've seen multiple clefs on one staff for different voices (that is, layers). 

> 
>> 2. <clef /> is allowed in <sb />, explicitly used as a "cautionary" clef.
>> 
>> On this point I agree with Raffaele (31.05.2011):
>> 
>> I agree that using clefchange and staffdef for courtesy clef repetitions is
>> a bit cumbersome, but I would advise against overweighting <pb/> and <sb/>.
>> In my opinion they should only signify the break and contain nothing. A
>> custos should occur *before* (or occasionally after) the system break and
>> not within the system break. If you think about it, that is what happens on
>> the page. In the same way, the clef repetition should not be attached to sb
>> or pb.
>> 
>> 3. Cautionary clefs should be removed from the "musical" flow and placed in
>> the <layout /> section.
>> 
>> Actually this would be THE solution if we stick to the opinion, that the
>> staff should be a virtual "endless" representation of the musical flow. The
>> cautionary clefs are a rendition phenomenon and do not belong to the logic
>> of the music but to the layout. In doing so the layout module would somewhat
>> encode the engraving quality of a specific published edition.
> 
> So do <custos> because they could be inferred easily. Would you remove
> them from the logic tree?
> 
> We have cases where the clef is missing - that is very frequent with
> typographic prints. How would you encode this? Or when the clef is
> wrong?

For me, the role for the layout module is not so much the description of an existing source (that's what facsimile and music is for), but instead to allow rendering hints for multiple possible interpretations of the data available in music. Of course it can be used to describe existing sources, but that wasn't my understanding of its intention. 

What I am wondering is if there isn't a solution 5. We could just rename clefchange to something less semantic (<clefIndication>?), and provide an attribute @reason with two default values 'cautionary' and 'change'. Actually, it could be merged with the existing <clef>, as both have almost the same set of attributes already. Doing so, <clef reason="cautionary" ? /> would be directly allowed within <layer>, without the need for an extra <clefChange>. Could that be a cleaner solution?

What we should make sure is that our changes ? if we agree on a solution ? are copied to the other corresponding staff features meter and key?

Best,
Johannes

> 
>> 
>> 4. Keep the status quo and use <staffdef> inside <staff> to indicate a
>> cautionary clef.
>> 
>> True, this seems a bit of an overkill...
>> 
>> While I personally think 2 is the most semantically useful option, I
>> understand that 1 is perhaps the easiest in the short term.
>> 
>> I'm not really comfortable with 3, since it removes a musical element from
>> the "flow" of the staff,
>> 
>> and 4 seems a bit stilted to me, overloading <staffdef> to not really define
>> anything new about a parent staff.
>> 
>> So, I will choose to implement #1 as it seems to solve our immediate issue
>> for the time being.
>> 
>> How I propose to solve this is to create a new Incubator project
>> ("clef-milestone") and create an ODD file that makes the change. This can
>> then be reviewed by the Technical Group and, if it's found worthy, rolled
>> into the mainline MEI standard at some point, likely with revisions.
>> 
>> Should anyone want to use this in another project they can then create their
>> own customization based on the ODD file. That way they can at least have a
>> reference back to the deviations from the MEI core.
>> 
>> In the comments of the ODD file I will reference this discussion so that
>> there's a way to return to it to re-evaluate the positions put forward here
>> when it comes time to review the revision.
>> 
>> Does this sound reasonable?
>> 
>> Sounds reasonable, all theoretical ideas are only theoretical, whichever
>> solution we opt for it has to be tested practically (option 4 obviously
>> failed, as it resulted in this discussion ;-)
>> 
>> 
>> Best,
>> Benjamin
>> 
>> _______________________________________________
>> 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



From d.lewis at gold.ac.uk  Tue Jun  7 11:22:13 2011
From: d.lewis at gold.ac.uk (David Lewis)
Date: Tue, 7 Jun 2011 10:22:13 +0100
Subject: [MEI-L] clef as milestone element
In-Reply-To: <BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
	<A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
	<11864_1307433278_4DEDD93E_11864_142_1_4DEDD8DB.9090708@edirom.de>
	<BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>
Message-ID: <537858BB-628F-4FD7-84A3-9DA695F219EE@gold.ac.uk>

>> 1. <clef /> is allowed directly in <layer />;
>>
>> As you say below, this,of course , would solve your immediate  
>> problem but
>> what if thinking of multiple layers on one staff; a clef would also  
>> affect
>> the other layers, or am I mistaken? If so it would make no logical  
>> sense as
>> part on a layer; it should be a direct child of staff.
>>
>
> You are right, but that is not very different from <clefchange> that
> is also allowed in a <layer>. When it occurs on all layers at the same
> time, I guess you will put it on all layers. Am I wrong?

I think that this is an important general point about how we read a  
lot of signs in music -- we may take the temporal position of a symbol  
from its position with respect to a single voice (or layer) but  
naturally assume it to apply for all the music found on its staff.  
This is represented as you propose in the music typesetting software I  
contribute to, and I assume in most others. It does require a  
combination of definition (what does it mean to have such a symbol in  
only one layer? what do conflicting symbols mean?) and trust (that the  
encoder has the same definitions and has good error checking), and it  
places some extra load on the interpreting software, but these are  
always the case.

D


From laurent at music.mcgill.ca  Tue Jun  7 14:55:11 2011
From: laurent at music.mcgill.ca (Laurent Pugin)
Date: Tue, 7 Jun 2011 14:55:11 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <12746_1307438538_4DEDEDCA_12746_464_1_3F0F20D3-63E6-49E7-B7A5-1C3328809118@edirom.de>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
	<A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
	<11864_1307433278_4DEDD93E_11864_142_1_4DEDD8DB.9090708@edirom.de>
	<BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>
	<12746_1307438538_4DEDEDCA_12746_464_1_3F0F20D3-63E6-49E7-B7A5-1C3328809118@edirom.de>
Message-ID: <BANLkTi=m=GprwZYbqHopgLUrkxoswrSRfQ@mail.gmail.com>

On Tue, Jun 7, 2011 at 11:22 AM, Johannes Kepper <kepper at edirom.de> wrote:
>
> Am 07.06.2011 um 11:03 schrieb Laurent Pugin:
>
>> On Tue, Jun 7, 2011 at 9:52 AM, Benjamin Wolff Bohl <bohl at edirom.de> wrote:
>>> Hi everybody,
>>>
>>> first thanks for the interesting discussion bringing some clarification on
>>> what the "layout" module is all about, etc.
>>> I'd like to give some inline comments on this summary:
>>>
>>> Am 01.06.2011 18:25, schrieb Andrew Hankinson, Mr:
>>>
>>> Before moving on from the <clef /> discussion, I'd like to try and bring in
>>> a consensus. The way I've heard it there are a number of options:
>>>
>>> 1. <clef /> is allowed directly in <layer />;
>>>
>>> As you say below, this,of course , would solve your immediate problem but
>>> what if thinking of multiple layers on one staff; a clef would also affect
>>> the other layers, or am I mistaken? If so it would make no logical sense as
>>> part on a layer; it should be a direct child of staff.
>>>
>>
>> You are right, but that is not very different from <clefchange> that
>> is also allowed in a <layer>. When it occurs on all layers at the same
>> time, I guess you will put it on all layers. Am I wrong?
>
> Although I have no example in mind currently, I'm pretty sure that I've seen multiple clefs on one staff for different voices (that is, layers).

Yes, I am aware of such cases.

>
>>
>>> 2. <clef /> is allowed in <sb />, explicitly used as a "cautionary" clef.
>>>
>>> On this point I agree with Raffaele (31.05.2011):
>>>
>>> I agree that using clefchange and staffdef for courtesy clef repetitions is
>>> a bit cumbersome, but I would advise against overweighting <pb/> and <sb/>.
>>> In my opinion they should only signify the break and contain nothing. A
>>> custos should occur *before* (or occasionally after) the system break and
>>> not within the system break. If you think about it, that is what happens on
>>> the page. In the same way, the clef repetition should not be attached to sb
>>> or pb.
>>>
>>> 3. Cautionary clefs should be removed from the "musical" flow and placed in
>>> the <layout /> section.
>>>
>>> Actually this would be THE solution if we stick to the opinion, that the
>>> staff should be a virtual "endless" representation of the musical flow. The
>>> cautionary clefs are a rendition phenomenon and do not belong to the logic
>>> of the music but to the layout. In doing so the layout module would somewhat
>>> encode the engraving quality of a specific published edition.
>>
>> So do <custos> because they could be inferred easily. Would you remove
>> them from the logic tree?
>>
>> We have cases where the clef is missing - that is very frequent with
>> typographic prints. How would you encode this? Or when the clef is
>> wrong?
>
> For me, the role for the layout module is not so much the description of an existing source (that's what facsimile and music is for), but instead to allow rendering hints for multiple possible interpretations of the data available in music. Of course it can be used to describe existing sources, but that wasn't my understanding of its intention.
>

It is my understanding too. That is why I am a bit reluctant to put
this in the layout.

> What I am wondering is if there isn't a solution 5. We could just rename clefchange to something less semantic (<clefIndication>?), and provide an attribute @reason with two default values 'cautionary' and 'change'. Actually, it could be merged with the existing <clef>, as both have almost the same set of attributes already. Doing so, <clef reason="cautionary" ? /> would be directly allowed within <layer>, without the need for an extra <clefChange>. Could that be a cleaner solution?
>
> What we should make sure is that our changes ? if we agree on a solution ? are copied to the other corresponding staff features meter and key?

It looks like a good solution to me. I would vote for <clef>, but
<clefIndication> would be fine too. Maybe we can think of another
@reason value. What about reason="sb"?

Laurent

>
> Best,
> Johannes
>
>>
>>>
>>> 4. Keep the status quo and use <staffdef> inside <staff> to indicate a
>>> cautionary clef.
>>>
>>> True, this seems a bit of an overkill...
>>>
>>> While I personally think 2 is the most semantically useful option, I
>>> understand that 1 is perhaps the easiest in the short term.
>>>
>>> I'm not really comfortable with 3, since it removes a musical element from
>>> the "flow" of the staff,
>>>
>>> and 4 seems a bit stilted to me, overloading <staffdef> to not really define
>>> anything new about a parent staff.
>>>
>>> So, I will choose to implement #1 as it seems to solve our immediate issue
>>> for the time being.
>>>
>>> How I propose to solve this is to create a new Incubator project
>>> ("clef-milestone") and create an ODD file that makes the change. This can
>>> then be reviewed by the Technical Group and, if it's found worthy, rolled
>>> into the mainline MEI standard at some point, likely with revisions.
>>>
>>> Should anyone want to use this in another project they can then create their
>>> own customization based on the ODD file. That way they can at least have a
>>> reference back to the deviations from the MEI core.
>>>
>>> In the comments of the ODD file I will reference this discussion so that
>>> there's a way to return to it to re-evaluate the positions put forward here
>>> when it comes time to review the revision.
>>>
>>> Does this sound reasonable?
>>>
>>> Sounds reasonable, all theoretical ideas are only theoretical, whichever
>>> solution we opt for it has to be tested practically (option 4 obviously
>>> failed, as it resulted in this discussion ;-)
>>>
>>>
>>> Best,
>>> Benjamin
>>>
>>> _______________________________________________
>>> 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
>
>


From zupftom at googlemail.com  Tue Jun  7 22:24:10 2011
From: zupftom at googlemail.com (TW)
Date: Tue, 7 Jun 2011 22:24:10 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <BANLkTi=m=GprwZYbqHopgLUrkxoswrSRfQ@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
	<A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
	<11864_1307433278_4DEDD93E_11864_142_1_4DEDD8DB.9090708@edirom.de>
	<BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>
	<12746_1307438538_4DEDEDCA_12746_464_1_3F0F20D3-63E6-49E7-B7A5-1C3328809118@edirom.de>
	<BANLkTi=m=GprwZYbqHopgLUrkxoswrSRfQ@mail.gmail.com>
Message-ID: <BANLkTimk9_AQ2VOf+erzx++kJre4CaGGMA@mail.gmail.com>

2011/6/7 Laurent Pugin <laurent at music.mcgill.ca>:
> On Tue, Jun 7, 2011 at 11:22 AM, Johannes Kepper <kepper at edirom.de> wrote:
>>
>> Am 07.06.2011 um 11:03 schrieb Laurent Pugin:
>>
>> Although I have no example in mind currently, I'm pretty sure that I've seen multiple clefs on one staff for different voices (that is, layers).
>
> Yes, I am aware of such cases.
>

I think I've seen something similar to this:

http://imageshack.us/photo/my-images/101/shiftedclef.png

(I made this up.)  I.e. strictly speaking wrong use of the F clef, but
the piano player immediately knows what's meant.  Should this be
covered?  If yes, should there be a clef/@line.ges attribute, and
should the restrictions on clef/@line be relaxed (i.e. integer instead
of positive integer in the range of the number of lines?

>
> It looks like a good solution to me. I would vote for <clef>, but
> <clefIndication> would be fine too. Maybe we can think of another
> @reason value. What about reason="sb"?
>

A fundamental question:  Why "sb" rather than "systembreak"?  I
personally prefer descriptive naming where you don't have to guess.
For example, I have no idea what note/@accid="tb" is meant to mean.
It's not documented either.  Of course one can add an explanation to
the documentation, but I find it much more accessible to have a
meaningful attribute or tag name in the first place.

Thomas


From andrew.hankinson at mail.mcgill.ca  Wed Jun  8 00:03:37 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 7 Jun 2011 22:03:37 +0000
Subject: [MEI-L] clef as milestone element
In-Reply-To: <760_1307478263_4DEE88F7_760_411_1_BANLkTimk9_AQ2VOf+erzx++kJre4CaGGMA@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
	<A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
	<11864_1307433278_4DEDD93E_11864_142_1_4DEDD8DB.9090708@edirom.de>
	<BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>
	<12746_1307438538_4DEDEDCA_12746_464_1_3F0F20D3-63E6-49E7-B7A5-1C3328809118@edirom.de>
	<BANLkTi=m=GprwZYbqHopgLUrkxoswrSRfQ@mail.gmail.com>
	<760_1307478263_4DEE88F7_760_411_1_BANLkTimk9_AQ2VOf+erzx++kJre4CaGGMA@mail.gmail.com>
Message-ID: <A1144168-2F80-4428-B235-2C025BCAAA80@mail.mcgill.ca>


On 2011-06-07, at 4:24 PM, TW wrote:

> 2011/6/7 Laurent Pugin <laurent at music.mcgill.ca>:
>> On Tue, Jun 7, 2011 at 11:22 AM, Johannes Kepper <kepper at edirom.de> wrote:
>>> 
>>> Am 07.06.2011 um 11:03 schrieb Laurent Pugin:
>>> 
>>> Although I have no example in mind currently, I'm pretty sure that I've seen multiple clefs on one staff for different voices (that is, layers).
>> 
>> Yes, I am aware of such cases.
>> 
> 
> I think I've seen something similar to this:
> 
> http://imageshack.us/photo/my-images/101/shiftedclef.png
> 
> (I made this up.)  I.e. strictly speaking wrong use of the F clef, but
> the piano player immediately knows what's meant.  Should this be
> covered?  If yes, should there be a clef/@line.ges attribute, and
> should the restrictions on clef/@line be relaxed (i.e. integer instead
> of positive integer in the range of the number of lines?

You will need to have some notion of ledger lines, so yes, you should be able to specify negative numbers as the line.


> 
>> 
>> It looks like a good solution to me. I would vote for <clef>, but
>> <clefIndication> would be fine too. Maybe we can think of another
>> @reason value. What about reason="sb"?
>> 
> 
> A fundamental question:  Why "sb" rather than "systembreak"?  I
> personally prefer descriptive naming where you don't have to guess.
> For example, I have no idea what note/@accid="tb" is meant to mean.
> It's not documented either.  Of course one can add an explanation to
> the documentation, but I find it much more accessible to have a
> meaningful attribute or tag name in the first place.

<sb /> follows the convention of the "b", or "breaking" indicators, like "<br />" and "<lb />" (for line breaks) and <pb /> for page breaks. This is largely started in HTML and inherited through TEI.

"tb" on accid stands for "Triple Flat" in MEI 2010. "tf" is now also allowed in the upcoming release for consistency with "f", "ff" and "nf".

Ultimately, and this is something that I think needs bearing in mind, XML is *not* supposed to be meant for human consumption first -- it's meant for computer consumption. I may be opening up a new can of worms, world of hurt, and pouring lemon juice in old wounds simultaneously, but my feeling is that if you want to create a system break, you (as a programmer) would call "createSystemBreak()" in some library and it will do all the necessary checking and insertion for you. Most people will then just need to click a button to insert a system break.

With MEI, though, we're at the stage where there are no real software libraries that will produce this, so we're left to hand encoding them. Frankly, I don't think this is a healthy position to maintain outside of a few specialized projects. My expectation is that we'll be producing software to automatically read and write MEI in the very near future.

All this is to say the difference between "<sb />" and "<systembreak />" is a human-oriented difference specifically for hand-encoders. I know that technically we could replace *everything* with numbers if all we're concerned with is computer readability, but I think it still needs to be somewhat legible for the early adopters and software implementers to get their heads around. After that, though, most people will be generating MEI through other means.

-Andrew

> 
> Thomas
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From donbyrd at indiana.edu  Wed Jun  8 02:16:41 2011
From: donbyrd at indiana.edu (Byrd,  Donald A.)
Date: Tue,  7 Jun 2011 20:16:41 -0400
Subject: [MEI-L] clef as milestone element; multiple clefs on a staff
In-Reply-To: <A1144168-2F80-4428-B235-2C025BCAAA80@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
	<A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
	<11864_1307433278_4DEDD93E_11864_142_1_4DEDD8DB.9090708@edirom.de>
	<BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>
	<12746_1307438538_4DEDEDCA_12746_464_1_3F0F20D3-63E6-49E7-B7A5-1C3328809118@edirom.de>
	<BANLkTi=m=GprwZYbqHopgLUrkxoswrSRfQ@mail.gmail.com>
	<760_1307478263_4DEE88F7_760_411_1_BANLkTimk9_AQ2VOf+erzx++kJre4CaGGMA@mail.gmail.com>
	<A1144168-2F80-4428-B235-2C025BCAAA80@mail.mcgill.ca>
Message-ID: <20110607201641.9395xis0sgk04sk8@webmail.iu.edu>

On Tue, 7 Jun 2011 22:03:37 +0000, "Andrew Hankinson, Mr" 
<andrew.hankinson at mail.mcgill.ca> wrote:

>
> On 2011-06-07, at 4:24 PM, TW wrote:
>
>> 2011/6/7 Laurent Pugin <laurent at music.mcgill.ca>:
>>> On Tue, Jun 7, 2011 at 11:22 AM, Johannes Kepper <kepper at edirom.de> wrote:
>>>>
>>>> Am 07.06.2011 um 11:03 schrieb Laurent Pugin:
>>>>
>>>> Although I have no example in mind currently, I'm pretty sure that
>>>> I've seen multiple clefs on one staff for different voices (that
>>>> is, layers).
>>>
>>> Yes, I am aware of such cases.

My "Gallery of Interesting Music Notation"

  http://www.informatics.indiana.edu/donbyrd/InterestingMusicNotation.html

shows a very obvious example (from Debussy) and a much more subtle one 
(Ravel). And the attached document, inelegantly titled "More 
Counterexamples in Conventional Music Notation", lists 10 more examples 
from music by Brahms, Dvorak, Rachmaninoff, etc. There are really a 
couple of fairly distinct cases, which it discusses briefly.

--Don


>>>
>>
>> I think I've seen something similar to this:
>>
>> http://imageshack.us/photo/my-images/101/shiftedclef.png
>>
>> (I made this up.)  I.e. strictly speaking wrong use of the F clef, but
>> the piano player immediately knows what's meant.  Should this be
>> covered?  If yes, should there be a clef/@line.ges attribute, and
>> should the restrictions on clef/@line be relaxed (i.e. integer instead
>> of positive integer in the range of the number of lines?
>
> You will need to have some notion of ledger lines, so yes, you should
> be able to specify negative numbers as the line.
>
>
>
>>
>>>
>>> It looks like a good solution to me. I would vote for <clef>, but
>>> <clefIndication> would be fine too. Maybe we can think of another
>>> @reason value. What about reason="sb"?
>>>
>>
>> A fundamental question:  Why "sb" rather than "systembreak"?  I
>> personally prefer descriptive naming where you don't have to guess.
>> For example, I have no idea what note/@accid="tb" is meant to mean.
>> It's not documented either.  Of course one can add an explanation to
>> the documentation, but I find it much more accessible to have a
>> meaningful attribute or tag name in the first place.
>
> <sb /> follows the convention of the "b", or "breaking" indicators,
> like "<br />" and "<lb />" (for line breaks) and <pb /> for page
> breaks. This is largely started in HTML and inherited through TEI.
>
> "tb" on accid stands for "Triple Flat" in MEI 2010. "tf" is now also
> allowed in the upcoming release for consistency with "f", "ff" and
> "nf".
>
> Ultimately, and this is something that I think needs bearing in mind,
> XML is *not* supposed to be meant for human consumption first -- it's
> meant for computer consumption. I may be opening up a new can of
> worms, world of hurt, and pouring lemon juice in old wounds
> simultaneously, but my feeling is that if you want to create a system
> break, you (as a programmer) would call "createSystemBreak()" in some
> library and it will do all the necessary checking and insertion for
> you. Most people will then just need to click a button to insert a
> system break.
>
> With MEI, though, we're at the stage where there are no real software
> libraries that will produce this, so we're left to hand encoding
> them. Frankly, I don't think this is a healthy position to maintain
> outside of a few specialized projects. My expectation is that we'll
> be producing software to automatically read and write MEI in the very
> near future.
>
> All this is to say the difference between "<sb />" and "<systembreak
> />" is a human-oriented difference specifically for hand-encoders. I
> know that technically we could replace *everything* with numbers if
> all we're concerned with is computer readability, but I think it
> still needs to be somewhat legible for the early adopters and
> software implementers to get their heads around. After that, though,
> most people will be generating MEI through other means.
>
> -Andrew
>
>>
>> Thomas
>>
>> _______________________________________________
>> 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
>



--
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics & Music
Indiana University, Bloomington
-------------- next part --------------
MORE COUNTEREXAMPLES IN CONVENTIONAL MUSIC NOTATION: a supplementary list
by Donald Byrd, Indiana University, Bloomington
Revised mid February 2011

This is a supplement to the list of "counterexamples" in Sec. 2.5 of my dissertation,
Music Notation by Computer (Byrd, 1984). (The term "counterexample" is borrowed from
mathematics and mathematical logic.) As that section states, these are "examples of
published music...intended to counter the view that CMN, while it may have many complex
details, is in principle easily mechanizable". I restrict CMN to the period from about
1700 to 1935. These examples are virtually all from music published by respectable
publishers, and the vast majority are by well-known, mainstream composers. They cast
doubt on the idea that CMN can be easily mechanized by breaking many of the supposed
rules of music notation, including some that (in my experience) few musicians would
expect to see _any_ exceptions to, at least in publications like these.

My dissertation comments that "this collection is far from exhaustive: it is based on an
examination of a minute fraction of the relevant musical literature." The same statement
applies to this supplement.

A handful of these counterexamples are discussed in Byrd (1994).

A related collection of examples of unusual music notation appears in Byrd (2007). That
collection concentrates not on rule-breaking notation but on extreme usage of notation
wtihin the rules, e.g., shortest note duration, most independent voices on a staff.
However, the dividing line between extremes and rule-breaking isn't always clear.

See also Byrd (2008a) and my list of Music Without Barlines (2008).

Thanks to Edward Auer, Lana Bode, Myke Cuthbert, Noam Elkies, Jay Hook, Thomas Loewenheim,
David Meredith, and Gabi Teodoru for their contributions (noted below).

Abbreviations:

Asterisk ("*") preceding an item indicates those I haven't seen personally.
"B&I 7.5" (and similar) means this notation is item 7.5 in Byrd & Isaacson (2005).
"B&M 1948" means the notation is visible in Barlow & Morgenstern (1948).
For edition, "Bo+H" = Boosey & Hawkes; "Br+H" = Breitkopf & Haertel.


(1) Collisions.

	Ravel: Gaspard de la Nuit (Durand ed.) (almost simultaneous intersections of two beams,
		two slurs, and hairpin)
	Scriabin: Piano Sonata no. 3 (Dover ed.), I, p. 49, top staff (double-dotted notes with
		a stem belonging to a note in another voice between the dots. I'm not sure if this
		is a perceptual collision as defined in my dissertation; it's more like a "perceptual
		interruption".)


(2) Linear Symbols Interrupted By Other Symbols.

	Bartok: 3 Burlesques, Op. 8C, I (barline and staff interrupted by clef)
	Chopin: Prelude in f, Op. 28 no. 18 (?? ed.) (beam interrupted by clef) (B&I 12.6?)
	Strauss: An Alpine Symphony, Op. 64, after RM 69 (barline and staff interrupted by clef)


(3) Symbols With Highly Nonstandard Shapes Or Positions (but minimal or no unusual semantics)

	Bartok: Two Rumanian Dances, Op. 8A no. 2 (compound beam)
	Berg: Violin Concerto (Universal ed.), p. 47 (one-to-many, many-to-one slurs jumping staves
		and parts, e.g., clarinet to bass clarinet or bassoon, celli to violins & violas(?))
		(B&I 17.6 EXTENDED)
	*Berio: Don{de} from Pli selon Pli, p. 15 (slur jumping from clarinet to bass clarinet,
		to play an out-of-range note) (NB: after 1935) (B&I 17.6 EXTENDED) [contrib. by Cuthbert]
	Brahms: Capriccio, Op. 76 no. 5 (International ed.), mm. 7-8 (stem only one space long)
	Chopin: Berceuse, Op. 57, p.1 (split-stem grace notes, for augmented unison??) (B&I 5.25)
	Chopin: Nocturne, Op. 27 no. 2 (augmented unison in 2-stem notation ??SPLIT STEM OR 2 VOICE?)
	Bizet: Jeux d'Enfants, p. ?? (slur with 5 inflection points) ??IS THIS REAL?
	Debussy: Prelude a l'apres-midi d'un faune, piano arrangement by Leonard Borwick, m. 100
		(in a 3-staff system, arpeggio sign with notes on the top & bottom staves but not the
		middle one)
	Haydn: Piano Sonata in E minor, Hoboken XVI, I (fermata over nothing, halfway between 2 rests)
	Verdi: Falstaff (publ.?), p. 203 (accents marks _obviously_ moved to avoid accessory numerals)
	Ravel: Gaspard de la Nuit (Durand ed.), Scarbo, p. 41 (slur with 3 inflection points)
		(B&I 17.17)
	Ravel: Gaspard de la Nuit (Durand ed.), Ondine, next-to-last page (slur backing up in the
		middle) (B&I 17.17)

Small notes with rhythmic values more-or-less like normal notes, excluding cadenza-like passages
entirely in small notes:
	Bartok: Dance in Bulgarian Rhythm no. 1, in Mikrokosmos (1926-39; Boosey & Hawkes ed.) Book 6,
		throughout, right hand (triplet of 3 16ths, the first full-size & the others small)
	Chopin: Prelude in f#, Op. 28 no. 8  (Br+H ed.), throughout, right hand (small 32nd notes
		regularly double-stemmed with longer normal notes when they coincide)
	Chopin: Prelude in d, Op. 28 no. 24  (Br+H, Paderewski eds.), several places (strings of
		beamed small eighth notes, sometimes starting with a full-size note)
	Chopin: Etude in A-flat, Op. 25 no. 1 ("Harp") (Paderewski ed.), throughout, right hand
		(beamed six-note groups of triplet 16th notes, the first full-size and the others small)
	Chopin: Scherzo in b-flat, Op. 31  (Br+H ed.), several places, right hand (passages of a couple
		of measures of all small notes)
	Debussy: Pour le Piano, I, mm. 148-156?? (small notes in a cadenza-like passage that seem
		to act like normal notes, interspersed with normal notes filling each measure's duration)
	Ives: Three Places in New England (Mercury Music ed.), I, p. 6, piano (psuedo-arpeggio of
		eighth-note dyads with upper note of each normal size, lower note small)
	Schumann: Carnaval (Kalmus/Clara Schumann ed.), Op. 9, no. 19 (Promenade), mm. 3-4, 11-12,
		etc. (small notes with simultaneous full-size rests on the same staff notes, but clearly
		intended to be played like normal notes, as if "cue" notes but for the same performer)
	Scriabin: Sonata no. 1, IV, beginning 52 mm. from the end (small notes that act just like
		normal notes)

(4) Rhythm Notation.

Chord with notes of different durations (B&I 4.28):
	Bartok: Sonata for Solo Violin (Boosey & Hawkes ed.), I (double-dotted quarters on same
		stem as undotted quarters)
	Brahms: Symphony no. 1 (Henle), I, 4th m. of Allegro, violin 1 (dotted quarters on same
		stem as undotted quarters)
	Brahms: Symphony no. 4 (Eulenberg ed.), IV, last chord, violins & violas (dotted halfs
		on same stem as undotted quarters)
	Chopin: Scherzo in B minor, Op. 20 (Br+H ed.) (half head on same stem as quarter; occurs
		several times)
	Chopin: Prelude in Db, Op. 28 no. 15 (Paderewski, Universal, Br+H eds.) (dotted-half head on
		same stem as dotted-8th)
	Mozart: Violin Concerto no. 3 in G, K.216 (Schirmer/Franko ed.), I, m.42, solo violin
		(half head on same stem as 2 quarters)
	Mozart: Piano Sonata no. 6 in D major, K. 284  (Alte Mozart-Ausgabe), III, variation 4
		(half head on same stem as quarter heads)
	Tchaikovsky: Symphony no. 2 (Eulenberg ed.), IV, mm. 3-4, violins, violas, celli (halfs
		on same stem as quarters)

Note with duration apparently extending across the following barline (cf. "impossible rhythm").
Many of these involve dotted notes where the dotted part of the duration is after the barline:
	Barber: Piano Sonata, I, p. 7 (notehead and double dots together before barline)  [contrib.
		by Meredith]
	Bartok: Violin Sonata no. 1 (Universal ed.), I (notehead before but dot after barline)
	Brahms: Symphony no. 1 (Eulenberg ed.), IV (notehead before but dot after barline)
	Chopin: Etude in A-flat, Op. 10 no. 10 (Paderewski, Henle eds.), beginning (it's in 12/8; the
		left hand plays continuous 8th notes, but the 4th and 10th of several mm. have half-note
		heads; in the Paderwski ed., they're also stemmed separately with augmentation dots)
		[contrib. by Hook]
	Chopin: Prelude in D, Op. 28 no. 5 (Paderewski, Universal, Br+H eds.), mm. 1-3, etc. (the last
		16th of the measure is double-stemmed as an 8th)
	Mozart: Piano Sonata in Eb, K.282 (Presser/Broder), III, mm. 48-54, right hand (notehead before
		but dot after barline)
	Mozart: String Quartet, K.465 (Br+H ed.), IV, last page (notehead before but dot after barline)
	
Note with duration arguably shorter than it appears. Usually this is because it otherwise extends
across the following barline but following events in the score indicate it should not be held for
the full notated duration (a type of "impossible rhythm"):
	Brahms: Variations on a Theme of Haydn, Op. 56, theme (breve in 2/4 time)
	Brahms: Capriccio, Op. 76 no. 1 (dotted half in 6/8 time starting a 16th after the downbeat,
		and tied to a note on the downbeat of the next measure; clearly it's intended to last only
		11 16ths instead of 12)
	Franck: Prelude, Chorale, & Fugue, Prelude, m. 48 (quarter notes overlapping with 32nd rests
		in the same voice; clearly they're intended to last only 7 32nds instead of 8) [contrib.
		by Hook]
	Verdi: Falstaff (Ricordi), last m. of Act I (breve in 6/8 time)
	Verdi: Falstaff (Ricordi), last m. of Act II (breve in 2/4 time)
	Verdi: Requiem (Dover), last page (breve in cut -- here unequivocally 2/2 -- time)
	
Time signature change in middle of measure (B&I 10.8):
	Beethoven: Piano Sonata, Op. 109, I & III 
	Beethoven: Piano Sonata, Op. 110, III (four times; the passage also has multiple mid-measure
		key changes)
	Beethoven: Piano Sonata, Op. 111, II (occurs at least twice)
	Handel: Keyboard suite no 5 in E major, last mvmt (a.k.a. "The Harmonious Blacksmith") (at
		join between Var. 2 and 3, right hand switches from C to 24/16 in mid-bar, left hand staying
		in C; between Var. 3 and 4, the hands switch time signatures in mid-bar; and between Var.
		4 and 5, left hand joins right hand's C in mid-bar) [contrib. by Elkies]
	Verdi: Falstaff (Ricordi), p. 71 (12/8 to C)
	Anonymous (folk song): Wassail Song (typically notated as 6/8 to 4/4)

Time signature with ambiguous measure duration
	Bach: Well-Tempered Clavier, Book II, Prelude in D ("C 12/8" for simple vs. compound
		equivalents)
	Brahms: Piano Trio, Op. 101, III ("3/4 2/4", meaning each measure is one or the other; later,
		"9/8 6/8", with the same meaning)
	Debussy: Preludes, Book 1: Les collines d'Anacapri (State Music Pub. House/Sorokin ed., Dover
		reprint) ("12/16 = 2/4" for simple vs. compound equivalents)
	Rimsky-Korsakov: Scheherazade, Op. 35 (Belaieff/Dover ed.), IV, m. 30ff. ("2/8 (6/16 3/8)")
	Ysaye: Solo Vn Sonata, Op. 27 No. 2 (Ysaye/Schirmer ed.), III ("3/4 = 5/4": the vast majority
		of measures are in 3/4, but a few are in 5/4, one in 4/4, and one, marked "-2-", in 2/4)
	Ysaye: Solo Vn Sonata, Op. 27 No. 2 (Ysaye/Schirmer ed.), IV ("2/4 3/4": each measures is one
		or the other)

One notehead for notes of different duration ending at the same time, and therefore beginning
at different times. This is the principal "impossible rhythm" situation of Hook (2008), which
gives dozens of examples besides those listed here:
	Brahms: Variations on an Original Theme, Op. 21 no. 1 (Br+H ed.), Variation 5 (one
		notehead for normal 16th and triplet 16th => 1/2 = 2/3; occurs many times) [contrib. by
		Hook]
	Brahms: Intermezzo, Op. 119 no. 1 (1893; International ed.), 12 m. before the end (one
		notehead for normal and triplet 8ths ending at the same time => 1/2 = 2/3)
	Chopin: Ballade in f, Op. 52 (Br+H ed.), mm.?? (one notehead for normal and triplet
		16ths ending at the same time => 1/2 = 2/3; occurs several times)
	Chopin: Concerto in F minor, Op. 21 (Br+H ed.), III, mm. 335-36 (one notehead for normal and
		triplet 8ths ending at the same time => 1/2 = 2/3) [contrib. by Hook]
	Chopin: Mazurka in A minor, Op. 17 no. 4.
	Chopin: Prelude in C, Op. 28 no. 1 (1836?; Paderewski ed.) (one notehead for normal and
		triplet 16ths ending at the same time; occurs >20 times) [contrib. by Hook]
	Chopin: Prelude in C, Op. 28 no. 1 (1836?; Paderewski ed.) (one notehead for normal and
		quintuplet 16ths ending at the same time; occurs 6 times) [contrib. by Hook]
	Chopin: Sonata no. 1 (1828?; Schirmer-Mikuli ed.), III (one notehead for normal and
		quintuplet 16ths ending at the same time; occurs 3 times)
	Ravel: Sonatine (1903-05; Durand/Dover ed.), III (one notehead for normal and triplet
		8ths ending at the same time; occurs 4 times)
	Schumann: Bunte Blatter, Op. 99 no. 2 ("St?cklein II") (one notehead for normal 32nd and
		triplet 8th => 1/3 = 3/8 & 2/3 = 5/8; occurs 4 times) [contrib. by Hook]
	Scriabin: Prelude in C, Op. 11 no. 1 (Izdatel'stvo Muzyka (State Music Publishing House) ed.)
		(various conflicts??) [contrib. by Hook]
	Scriabin: Sonata no. 7 (zdatel'stvo Muzyka (State Music Publishing House)/Dover ed.), p. 148
		(one notehead for normal 8th and triplet 8th ending at the same time)

Half notehead with beam(s):
	Brahms: Rhapsody in G minor, Op. 79 no. 1 (Peters/Sauer, International eds.) (dotted-half
		head; occurs many times)
	Chopin: Prelude in Db, Op. 28 no. 15 (Paderewski, Universal, Br+H eds.) (half head and
		dotted-half head in beamed group of 8th notes; each occurs several times, sometimes
		in the middle of the group)
	Debussy: Arabesque no. 1 (Durand ed.) (double-stemmed half head in beamed group of 8th
		notes; occurs many times)
 	Faur?: Dolly Suite, Op. 56 (Dover reprint of Hamelle et Cie ed.), Berceuse, Seconda part
		(half head beamed to 8th; occurs many times)

Non-aligned barlines (these seem to be less common than one would expect; but they're surely
		more common than these few examples suggest, even up to 1935!) (B&I 7.5):
	Bartok: String Quartet #2 (Boosey & Hawkes ed.), I, rehearsal mark 8 (polymeter: 6/8 vs.
	(3+4)/8, 9/8, etc. with 8th = 8th)
	Chopin: "Minute" Waltz, Op. 64 no. 1 (Paderewski ed.), last 3 measures (barlines omitted on
		one staff)
	Chopin: Ballade no. 1 in g, Op. 23 (Br+H ed.), last page (barlines omitted on one staff)
	Ives: The Unanswered Question (1908; Southern Music)
	Ives: Three Places in New England (1903-14; Mercury ed.), II. Putnam's Camp (polymeter)
	Ives: Symphony no. 4, I, p. 3 (1910-16) (polymeter)
	Mozart: Don Giovanni (1787; all eds.), Act I Finale (no. 13; ballroom scene) (polymeter:
		3/8, 2/4, 3/4. 2/4 quarter = 3/4 quarter; 3/8 dotted quarter = 2/4 or 3/4 quarter)
	*Wagner: Gotterdammerung (Eulenberg), end of Act III, pp. 1337-57 (3 mm. of 6/8 vs. one
		of 3/2; 2 mm. of 6/8 vs. one of 2/2)

Multibar rest not in a part of an ensemble piece:
	Beethoven: Piano Sonata no. 31, Op. 110, II (in music for a solo instrument)
	Kodaly: Hary Janos Suite (Universal ed.), I, m. 75 (in the score of an ensemble piece)
	Ravel: Gaspard de la Nuit (Durand ed.), Scarbo, mm. 30-31 (in music for a solo instrument)

Other:
	Chopin: Nocturne, Op. 15 no. 2, m.8 (ordinary notehead with one stem and beam to an
		ordinary note, and one stem and beam to grace -- not just small -- notes)
	Tchaikovsky: Piano Concerto no. 1 (Billaudot), I, p. 25 (measure of two duplet quarters
		followed by three triplet quarters in C time)

	Chopin: Nocturne, Op. 27 no. 2 (6:4 groupets in 6/8 meter) [??IS THIS INTERESTING ENOUGH
		TO BE WORTH MENTIONING?]
	Chopin: Prelude in Db, Op. 28 no. 15  (Paderewski, Universal, Br+H eds.) (7 8ths in the time of 2)
	
	F. Couperin: Passacaille from Pieces de Clavecin, Ordre VIII (pub. 1717) (numerous groups of
		three 128ths that should be triplet 32nds, and of two 64ths that should be 32nds)

	Bach: Brandenburg Concerto no. 4, III, solo violin ("tuplets" that are unambiguous but
		seem pointless because they're just ordinary notes: 8 16th notes in the time of 8, and
		16 16th notes in the time of 16)

	Bach: Jesu, Joy of Man's Desiring, arr. for piano by Myra Hess (Oxford) (single notes --
		not part of a chord -- on "wrong" side of stem, to show three voices on one staff)

	Elgar: Enigma Variations, no. 7 (Eulenberg ed.): time signature of "1", i.e., no denominator
		(NB: fairly common in early music, even Bach, but extremely rare since) (B&I 10.2)

	Debussy: Jardins sous la pluie from Estampes (Durand, 1903) (series of nine small-note 32nds
		marked "9": judging from the rhythmic context, apparently grace notes) (B&I 11.14)

	Hummel: Prelude in B major, Op. 67 no. 1 (Universal/Dover ed.) (tuplet of 8 16th notes in an
		amount of time that's part of a cadenza-like passage and impossible to define)
		
	Rachmaninoff: Prelude, Op. 32 no. 3 (Muzgiz ed.), mm. 23 & 24 (series of five small-note eighths
		marked "5": judging from the rhythmic context, apparently grace notes) (B&I 11.14)
	
	Schumann: Carnaval, Op. 9 (Kalmus/Clara Schumann ed. & an an unidentified edition on the Web,
		http://imslp.org/wiki/File:Schumann_-_Carnaval,_Op_9.pdf), no. 6 (Florestan), last 4 mm.
		(change of meter without notice: the movement has a time signature of 3/4, and it really
		is in 3/4 until the last 4 measures, each of which has a duration of 2/4)

	Schumann: Carnaval, Op. 9 (Dover ed.), no. 1, mm ??, right hand: "hugely ambiguous" double-
		stemmed double-dotted quarters [contrib. by Cuthbert]


(5) Miscellaneous.

Simultaneous notes in two clefs on one staff (B&I 8.4)**:
	Brahms: Piano Sonata, Op. 5 (Br+H ed.), I [contrib. by Auer]
	Debussy: Preludes, Book 1: La Cathedrale Engloutie (Durand ed., 1910); occurs 3 times
	Debussy: Preludes, Book 1: Voiles (State Music Pub. House/Sorokin ed., Dover reprint);
		occurs 3 times (with clef in mid-air in front of note on ledger lines)
	*Dvorak: Humoresque in F Major, Op. 101 no. 4 (Simrock ed., Dover reprint), near end
		[contrib. by Hook]
	Poulenc: Concert Champetre (orch. reduction, Editions Salabert, 1929), I, p.24 (in an
		extended passage)
	Puccini: Turandot (piano/vocal score, Ricordi), pp. 374, 375, 376, & 377
	Rachmaninoff: Prelude, Op. 23 no. 1, 2, 3, 7, 8 (International) (overlapping notes in two
		clefs on one staff)
	Rachmaninoff: Prelude, Op. 23 no. 3 (International ed.)
	Ravel: Gaspard de la Nuit (Durand ed.), Scarbo, several places (note(s) on downbeat in
		one clef, clef change, then note(s) that must also be on the downbeat)
	Szymanowski: Piesni Muezina Szalonego, Op. 42 (1918) (ex. in Hewlett & Selfridge-Field,
		1994), no. 4 (with clef in mid-air in front of notes on ledger lines)

One clef for two staves:
	Pozzoli: [solfeggio book; but NB probably published after 1935, and arguably not CMN]

Movement starting/ending with whole measures of rests:
	*Ligeti: Lux aeterna (movement ending with 7 measures of rest) (NB: after 1935) [contrib. by Hook]
	Liszt: Mephisto Waltz no. 1 (movement starting with a measure of rest) [contrib. by Auer]
	Messiaen: Oiseaux Exotiques, last movement (NB: after 1935) (movement ending with a measure of rest)
	Mozart: Piano Sonata in G, K. 283, last movement (movement ending with a measure of rest)

Non-numeric measure numbers (B&I 7.12) or page numbers:
	Schubert: Impromptu, Op. 142 #1 (non-numeric measure numbers. The last measure before the two
		one-measure endings of a repeated section is 81; in one edition, the 1st ending is
		labelled "81a", and in another, the 2nd ending is labelled "82b"; in both, the measure
		after the endings is 83.)
	R. Strauss: Ariadne auf Naxos (Fuerstner/Dover ed., 1916), pp. 88a, 88b, 88c (non-numeric
		page numbers. The next page, numbered 89, starts a new scene)
	Puccini: La fanciulla del West, vocal score (Well-Tempered Press), pp. 190a-190b
		(non-numeric page numbers)

Non-standard key signatures (B&I 9.1):
	Bach: Well-Tempered Clavier, Book I, Prelude in G (sharps or flats not in their usual octaves)
	Bartok: Mikrokosmos, nos. 76, 79, 82, 93 (sharps or flats not in their usual octaves)
	Bartok: Mikrokosmos, no. 99 (non-standard key signatures: unusual combinations of sharps
		or flats)
	
Tied notes with spelling change (B&I 17.1):
	Bartok: String Quartet #2 (Boosey & Hawkes ed.), I, mm. 3-4, violin 1 (B-flat tied to A-sharp)
		(in B & M, 1948).
	Beethoven: Piano Sonata in e (Dover/Schenker, *Henle, Ricordi/Casella eds.), Op. 90, II,
		m. 216 (tied notes in dyad with spelling change on each) [contrib. by Teodoru]. NB:
		in the Casella edition, this occurs a beat later than in the Schenker & Henle,
		probably to avoid a diminished 2nd in another voice. But how did Beethoven write it?
	Chopin: Sonata no. 3, Op. 58 (Mikuli, Paderewski eds.), mm. 95ff [contrib. by Hook]
	Chopin: Scherzo no. 4 in E, Op. 54 (Br+H ed.), m. ??  (chord of D#, Fx, C#, D# tied across key
		signature change to Eb, G, Db, Eb) [contrib. by Bode]
	Faur?: Dolly Suite, Op. 56 (Dover reprint of Hamelle et Cie ed.), III (Le jardin de Dolly),
		Seconda, mm. 14-15 (C-flat tied across barline to B)
	Faur?: song cycle "La Chanson d'Eve" (Heugel & Co. ed., Paris, 1907), Song 1, mm. 94-95
		(C-flat tied to B-natural, in piano RH) [contrib. by Hook]
	Faur?: " " , Song 10, m. 15 (C-flat tied to B-natural, in piano RH) [contrib. by Hook]
	*Franck: Piano Quintet in F Minor (Peters ed.), I, about midway between rehearsal letters K
		& L, piano (the left hand has octave D-sharp tied across a barline to octave E-flat. (At
		the same time, the cello has E-flat tied to E-flat.)) [contrib. by Hook]
	Ravel: String Quartet (International ed.), III, rehearsal mark K, viola (Gb tied across
		barline to F#)
	Ravel: Gaspard de la Nuit (Durand/Dover ed.), II (Le Gibet), mm. 27-31  (a series of A-sharp
		octaves is followed by one of B-flat octaves, then back to A-sharps, then to B-flats; the
		last of the 1st three series is tied to the first of the next series)
	Strauss: Also Sprach Zarathustra, in the fugue section titled "Von der Wissenschaft" (occurs
		at least four times at different pitch levels) [contrib. by Hook]

Multiply-augmented or -diminished melodic intervals:
	Brahms: Clarinet Sonata in E-flat, Op. 120, No. 2 (Wiener Urtext ed.), m. 97: doubly augmented
		unison (bass line moves directly from F-sharp to F-flat) [contrib. by Hook]
	Faur?: song cycle "La Chanson d'Eve" (Heugel & Co. ed., Paris, 1907), Song 1, mm. ??:
		doubly diminished third (Cx to Eb) in LH in second system [contrib. by Hook]
	" Song 8, mm. 15-16: doubly augmented unison (G# to Gb) in first measure, RH [contrib. by Hook]

Other:	
	Chopin: Nocturne, Op. 15 no. 1 (Durand ed./Debussy), near end (grace note on grace note) (B&I 5.36)
	Mendelssohn: Spring Song, no. 30 of Songs without Words (?? ed.), m. ?? (grace note on grace note)
			(B&I 5.36)
	Tchaikovsky: Piano Concerto no. 1 (Eulenberg, Billaudot eds.; Schirmer/Joseffy 2-piano
		reduction), I, m. 6 - at least 14 (simultaneous 8va and non-8va notes on one staff)
	Ravel: Gaspard de la Nuit (Durand ed.), Scarbo, last page (one 8va sign for both staves)
	Haydn: "Farewell" Symphony, IV, Coda (heavy double bars in some staves, single bars in others)

	Strauss: Also Sprach Zarathustra (Eulenberg ed.) (system spanning two pages, sideways)
	Wagner: Die Meistersinger (old Schott miniature score) (system spanning two pages, sideways)
	
	Nancarrow: Study no. 35 for Player Piano (metronome marks qtr = 283-1/3, 141-2/3, etc.)
		[NB: this is relatively recent music, and probably not from a respected publisher!]
	Schumann: "Susser Freund, du blickest" in Frauenliebe und Leben, Op. 42 (grace chord with
		arpeggio sign) (B&I 5.28)
	Ives: from "Lincoln, the Great Commoner", no. 11 in 114 Songs (grace-note beam whose last
		note is a normal note in the middle of a beamed group)
	Tchaikovsky: Symphony no. 2 (1873; Eulenberg ed.), I - II, timpani (invisible key signature,
		i.e., flats indicated by an accord only (in IV and perhaps III, accidentals appear on
		flatted notes); this is common in classical-period music, but not Tchaikovsky! B&I 3.1)

	
** My dissertation refers to "two clefs simultaneously active on one staff" instead of
"simultaneous notes in two clefs on one staff", but the former concept also includes the
much more common and _usually_ less interesting case of a long note written in one clef
continuing to sound as shorter notes, written on the same staff in a different clef, begin.
If a 2/4 measure on one staff begins in bass clef, with a half note in one voice and a
quarter rest in another, then changes to treble clef for some notes in the second voice,
that's not a big deal. But if the half note is replaced with two tied quarters, and the
second quarter appears in the same horizontal position as the first, it's much harder to
explain with conventional rules.

On the other hand, the "clef in mid-air" of La Danse de Puck and Voiles really _is_ "two clefs
simultaneously active" and not "simultaneous notes in two clefs"! It's interesting to
compare this bit of notation with a device that is not too unusual in cello music. E.g., in
the Kodaly Sonata for Solo Cello, Op. 8, there are several instances of a low note
appearing, preceded by a bass clef, on a very short staff segment below the (main) staff.
[contrib. by Loewenheim] This device is far easier to explain in terms of conventional
notation, but it does not save as much vertical space.


REFERENCES

Barlow, Harold & Morgenstern, Sam (1948). A Dictionary of Musical Themes. New York:
Crown Publishers.

Byrd, Donald (1984). Music Notation by Computer (doctoral dissertation, Computer Science
Dept., Indiana University). Ann Arbor, Michigan: UMI ProQuest (order no. 8506091); available
(in scanned form) at http://www.informatics.indiana.edu/donbyrd/DonDissPageImages.pdf .

Byrd, Donald (1994). Music-Notation Software and Intelligence. Computer Music Journal 18,
no. 1, pp. 17-20.

Byrd, Donald (2010). The Myth of Easy Time Signature Checking. Draft available at
http://www.informatics.indiana.edu/donbyrd/Papers/CheckMeasDurVsTimeSigNotEasy.doc .

Byrd, Donald (2009). Extremes of Conventional Music Notation. Retrieved July 20, 2009,
from the World Wide Web: http://www.informatics.indiana.edu/donbyrd/CMNExtremes.htm .

Byrd, Donald, & Isaacson, Eric (2009). A Music Representation Requirement Specification for
Academia. Computer Music Journal 27, no. 4 (2003), pp. 43-57; revised version retrieved June
20, 2009, from the World Wide Web: http://variations2.indiana.edu/system_design.html .

Hewlett, W., & Selfridge-Field, E. (Eds.) (1994). Music Notation Software. In Computing in
Musicology, vol. 9, pp. 167-230. 

Hook, Julian (2008). How to Perform Impossible Rhythms. Talk at Society for Music Theory
conference, Nashville, Tennesee, November 2008.

Rastall, Richard (1982). The Notation of Western Music. New York: St. Martin's Press.

From craigsapp at gmail.com  Wed Jun  8 03:22:48 2011
From: craigsapp at gmail.com (Craig Sapp)
Date: Tue, 7 Jun 2011 18:22:48 -0700
Subject: [MEI-L] Debussy La Danse de Puck clef
Message-ID: <BANLkTim6J2N0huLs2Z9SC2tYzBOP1PZ0Hg@mail.gmail.com>

Hi Don,

I would say that the clef in the notation example:
    http://www.informatics.indiana.edu/donbyrd/InterestingMusicNotation_files/Debussy_Danse.png
is not a clef but a pointer (in the C-programming sense) to a clef.
In other words, if it were a clef, then the pitch of that note would
be F3 since the F clef is aligned vertically with that note.
However, the pitch of the note is E1, with the bass-clef symbol
indicating that that particular note (and the note tied after it)
should be interpreted as being on a staff with an F-clef located
on the fourth line from the bottom of the staff.

Not that that would help clarify how to encode it too much, other
than that it is a clef-symbol and not actually a clef.

As a simple representational hack, perhaps something along the lines of:
   * logical/sounding pitch of note is E1
   * visual pitch of note is C3
   * clef symbol is an ornament attached to the left side of the note

If you were to transpose the music for some strange reason using
the above mechanism, things would get very complicated, since
you must suppress any visual accidentals (invisible visual accidentals),
and only display the logical/sounding accidentals....

Another better way of encoding the Debussy example and preserve
a reasonable representation after transposition might be to treat
it in a similar manner to cross-staff notes, which is closer to the
intended meaning of this notational shorthand.  In this case, there is
a cross-staff note with -1 staff displacement.  The staff below is
superimposed on top of the bottom of the grand staff, and the staff
below also has an implicit (hidden) clef (and implicit accidentals).

Or another variation is that the note is printed on an ossia-type staff
(with the same size) which superimposes on the main staff (with an
implicit bass clef).


-=+Craig


From donbyrd at indiana.edu  Wed Jun  8 04:33:58 2011
From: donbyrd at indiana.edu (Byrd,  Donald A.)
Date: Tue,  7 Jun 2011 22:33:58 -0400
Subject: [MEI-L] Debussy La Danse de Puck [vs. Ravel Scarbo] clef
In-Reply-To: <BANLkTim6J2N0huLs2Z9SC2tYzBOP1PZ0Hg@mail.gmail.com>
References: <BANLkTim6J2N0huLs2Z9SC2tYzBOP1PZ0Hg@mail.gmail.com>
Message-ID: <20110607223358.8kyfrolc3ocsk4s8@webmail.iu.edu>

I agree with almost everything you say, Craig. The "simple 
representational hack" really is a hack; much better to say, this note 
_really_ belongs to staff 3, which is in bass clef with a conventional 
key signature of three flats. The only odd thing is that staff 3 is 
superimposed on staff 2, etc., as you say. Just one thing: I don't see 
how saying the bass clef note's staff is "ossia type" makes any sense.

The situation in Scarbo is vastly different. The _only_ odd thing is 
the fact that, of the notes on the 2nd staff in m. 4 of the excerpt, 
the downstemmed notes on the downbeat are in bass clef, while the 
upstemmed notes -- which are also on the downbeat despite the red 
herring of being far to the right, after the clef change -- are in 
treble. Much harder to see what's going on, but easier to represent: 
just let a voice (or perhaps a chord, or just some notes) have 
its/their own clef, overriding the staff's current clef... Well, that's 
not completely satisfying, but it should do the job.

--Don


On Tue, 7 Jun 2011 18:22:48 -0700, Craig Sapp <craigsapp at gmail.com> wrote:
> Hi Don,
>
> I would say that the clef in the notation example:
>
> http://www.informatics.indiana.edu/donbyrd/InterestingMusicNotation_files/Debussy_Danse.png
> is not a clef but a pointer (in the C-programming sense) to a clef.
> In other words, if it were a clef, then the pitch of that note would
> be F3 since the F clef is aligned vertically with that note.
> However, the pitch of the note is E1, with the bass-clef symbol
> indicating that that particular note (and the note tied after it)
> should be interpreted as being on a staff with an F-clef located
> on the fourth line from the bottom of the staff.
>
> Not that that would help clarify how to encode it too much, other
> than that it is a clef-symbol and not actually a clef.
>
> As a simple representational hack, perhaps something along the lines of:
>   * logical/sounding pitch of note is E1
>   * visual pitch of note is C3
>   * clef symbol is an ornament attached to the left side of the note
>
> If you were to transpose the music for some strange reason using
> the above mechanism, things would get very complicated, since
> you must suppress any visual accidentals (invisible visual accidentals),
> and only display the logical/sounding accidentals....
>
> Another better way of encoding the Debussy example and preserve
> a reasonable representation after transposition might be to treat
> it in a similar manner to cross-staff notes, which is closer to the
> intended meaning of this notational shorthand.  In this case, there is
> a cross-staff note with -1 staff displacement.  The staff below is
> superimposed on top of the bottom of the grand staff, and the staff
> below also has an implicit (hidden) clef (and implicit accidentals).
>
> Or another variation is that the note is printed on an ossia-type staff
> (with the same size) which superimposes on the main staff (with an
> implicit bass clef).
>
>
> -=+Craig
>



--
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics & Music
Indiana University, Bloomington



From zupftom at googlemail.com  Wed Jun  8 07:48:07 2011
From: zupftom at googlemail.com (TW)
Date: Wed, 8 Jun 2011 07:48:07 +0200
Subject: [MEI-L] clef as milestone element
In-Reply-To: <A1144168-2F80-4428-B235-2C025BCAAA80@mail.mcgill.ca>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
	<A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
	<11864_1307433278_4DEDD93E_11864_142_1_4DEDD8DB.9090708@edirom.de>
	<BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>
	<12746_1307438538_4DEDEDCA_12746_464_1_3F0F20D3-63E6-49E7-B7A5-1C3328809118@edirom.de>
	<BANLkTi=m=GprwZYbqHopgLUrkxoswrSRfQ@mail.gmail.com>
	<760_1307478263_4DEE88F7_760_411_1_BANLkTimk9_AQ2VOf+erzx++kJre4CaGGMA@mail.gmail.com>
	<A1144168-2F80-4428-B235-2C025BCAAA80@mail.mcgill.ca>
Message-ID: <BANLkTi=X-+DOAC18v2ZA5x4XKmyg8i4mAw@mail.gmail.com>

2011/6/8 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>
> On 2011-06-07, at 4:24 PM, TW wrote:
>> For example, I have no idea what note/@accid="tb" is meant to mean.
>> It's not documented either.

I'm sorry, it *is* documented.  Where did I have my eyes?


From pdr4h at eservices.virginia.edu  Thu Jun  9 21:51:42 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Thu, 9 Jun 2011 19:51:42 +0000
Subject: [MEI-L] clef as milestone element
In-Reply-To: <BANLkTi=X-+DOAC18v2ZA5x4XKmyg8i4mAw@mail.gmail.com>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
	<A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
	<11864_1307433278_4DEDD93E_11864_142_1_4DEDD8DB.9090708@edirom.de>
	<BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>
	<12746_1307438538_4DEDEDCA_12746_464_1_3F0F20D3-63E6-49E7-B7A5-1C3328809118@edirom.de>
	<BANLkTi=m=GprwZYbqHopgLUrkxoswrSRfQ@mail.gmail.com>
	<760_1307478263_4DEE88F7_760_411_1_BANLkTimk9_AQ2VOf+erzx++kJre4CaGGMA@mail.gmail.com>
	<A1144168-2F80-4428-B235-2C025BCAAA80@mail.mcgill.ca>,
	<BANLkTi=X-+DOAC18v2ZA5x4XKmyg8i4mAw@mail.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D04B4AF@WILSON.eservices.virginia.edu>

In general, long names are preferred by inexperienced users, while short ones are preferred by experts.  This is analogous to menus for the uninitiated and keyboard shortcuts for gurus.  "systembreak" or "gesturalAccidental" seems like a great name until you realize it's going to happen over and over and over and over and over and ... 

So, in most markup schemes, short names are used for things that occur very frequently and long names are used for things that don't happen very often.  MEI follows this plan.

--
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 TW [zupftom at googlemail.com]
Sent: Wednesday, June 08, 2011 1:48 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] clef as milestone element

2011/6/8 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>
> On 2011-06-07, at 4:24 PM, TW wrote:
>> For example, I have no idea what note/@accid="tb" is meant to mean.
>> It's not documented either.

I'm sorry, it *is* documented.  Where did I have my eyes?

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

From pdr4h at eservices.virginia.edu  Thu Jun  9 22:41:35 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Thu, 9 Jun 2011 20:41:35 +0000
Subject: [MEI-L] Debussy La Danse de Puck clef
In-Reply-To: <BANLkTim6J2N0huLs2Z9SC2tYzBOP1PZ0Hg@mail.gmail.com>
References: <BANLkTim6J2N0huLs2Z9SC2tYzBOP1PZ0Hg@mail.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D04B4CB@WILSON.eservices.virginia.edu>


I like Craig's "C pointer" analogy, but for me it's still a clef that's been shifted downward in order to relieve some of the visual "clutter".  So, I would encode this clef just like any other standard F clef; that is, on the 4th line of the 2nd staff.  That's the position that makes "logical" sense.  This approach is completely transposable.

The visual shift could be dealt with in multiple ways, depending on the purpose of the encoding.  At present, the only solution is to use @facs to "point to" an image region, but if <clef> were made a member of att.visualoffset, then it would be possible to indicate its position relative to where it "should've been".  (Don't hold me to the attribute class name above -- it could be wrong.)

Of course, the problem with this approach is that a non-human reader of the notation (otherwise known as an OMR app) can't know that this is a standard clef with a strange visual placement.  It event takes expert human readers a little while to figure it out.


From bogus@does.not.exist.com  Thu May 19 10:25:27 2011
From: bogus@does.not.exist.com ()
Date: Thu, 19 May 2011 08:25:27 -0000
Subject: No subject
Message-ID: <mailman.43.1307652127.18762.mei-l@lists.uni-paderborn.de>

procedure I suggested above; that is, record the visual placement of the cl=
ef and then try to figure it what it means.  But, "that way lies madness", =
as they say, because we'd quickly find ourselves re-designing MEI as an ann=
otation mechanism for graphics files.  :)   I believe Donncha O'Maidin made=
 a proposal like this several years ago.  But that ain't MEI. :)


--
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-paderbo=
rn.de] on behalf of Craig Sapp [craigsapp at gmail.com]
Sent: Tuesday, June 07, 2011 9:22 PM
To: mei-l at lists.uni-paderborn.de
Subject: [MEI-L] Debussy La Danse de Puck clef

Hi Don,

I would say that the clef in the notation example:
    http://www.informatics.indiana.edu/donbyrd/InterestingMusicNotation_fil=
es/Debussy_Danse.png
is not a clef but a pointer (in the C-programming sense) to a clef.
In other words, if it were a clef, then the pitch of that note would
be F3 since the F clef is aligned vertically with that note.
However, the pitch of the note is E1, with the bass-clef symbol
indicating that that particular note (and the note tied after it)
should be interpreted as being on a staff with an F-clef located
on the fourth line from the bottom of the staff.

Not that that would help clarify how to encode it too much, other
than that it is a clef-symbol and not actually a clef.

As a simple representational hack, perhaps something along the lines of:
   * logical/sounding pitch of note is E1
   * visual pitch of note is C3
   * clef symbol is an ornament attached to the left side of the note

If you were to transpose the music for some strange reason using
the above mechanism, things would get very complicated, since
you must suppress any visual accidentals (invisible visual accidentals),
and only display the logical/sounding accidentals....

Another better way of encoding the Debussy example and preserve
a reasonable representation after transposition might be to treat
it in a similar manner to cross-staff notes, which is closer to the
intended meaning of this notational shorthand.  In this case, there is
a cross-staff note with -1 staff displacement.  The staff below is
superimposed on top of the bottom of the grand staff, and the staff
below also has an implicit (hidden) clef (and implicit accidentals).

Or another variation is that the note is printed on an ossia-type staff
(with the same size) which superimposes on the main staff (with an
implicit bass clef).


-=3D+Craig

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l=


From pdr4h at eservices.virginia.edu  Thu Jun  9 23:08:50 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Thu, 9 Jun 2011 21:08:50 +0000
Subject: [MEI-L] clef as milestone element
In-Reply-To: <3F0F20D3-63E6-49E7-B7A5-1C3328809118@edirom.de>
References: <56360484-56B0-44C7-A411-538913FD04EA@mail.mcgill.ca>
	<23966_1306826019_4DE49523_23966_20_1_BANLkTimbU41xdkJ4wDhzNn-iLSVQq0Uj-A@mail.gmail.com>
	<43B72634-8D65-4797-8A78-CAEEB355DFF5@mail.mcgill.ca>
	<29429_1306841059_4DE4CFE3_29429_357_1_BANLkTinNgXr2enb-NSSuk3hrV-0EkCCBtw@mail.gmail.com>
	<73C46286-BB2F-49C7-8E26-35D30E83126A@mail.mcgill.ca>
	<8567_1306873407_4DE54E3E_8567_1_6_BANLkTi=5eD1WFUKW6ycWcSmrroLVQ6uqJA@mail.gmail.com>
	<EB78B718-5A0D-4905-AF19-62A6EE43E1C7@mail.mcgill.ca>
	<26474_1306922390_4DE60D96_26474_495_1_BANLkTikZbhgcZTwLUryTVX9ztTP6sLsKfg@mail.gmail.com>
	<A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca>
	<11864_1307433278_4DEDD93E_11864_142_1_4DEDD8DB.9090708@edirom.de>
	<BANLkTim9VC6zGhLiGGehqXr7-1adbLutzA@mail.gmail.com>,
	<3F0F20D3-63E6-49E7-B7A5-1C3328809118@edirom.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D04B4E5@WILSON.eservices.virginia.edu>

<clef> could be allowed to occur (as Johannes suggests) directly within <layer>.  But as we've just witnessed, even in supposedly regular old, stiff, staid CMN there can be multiple clefs in operation on a single staff.  This is a common feature of pre-modern notation.  So, what does this mean? --

<note/><note/><clef/><clef/><note/><note/>

Is this two clef changes in a row?  Or are both clefs supposed to change simultaneously?

In order to avoid ambiguitry, something must be used to wrap the two <clef> elements when they're supposed to change simultaneously.  For example,

<note/><note/><clefchange><clef/><clef/></clefchange><note/><note/>

If clef changes are indicated this way when there's more than one clef, why not, for consistency's sake, use this method when there's only one?  However, in order to avoid --

<note/><clefchange><clef/></clefchange><note/>

clefchange carries the same attributes as clef, allowing --

<note/><clefchange/><note/>

Now, I will agree that perhaps "clefchange" is not the most appropriate name when this element is applied to the repeating clefs at the left side of every system.  But, the original assumption was the there was no need to record this information on every system, only in <scoredef> and/or <staffdef> elements, from which the repeating clefs/key signatures/etc. could be generated.  As I implied in an earlier message, MEI was not originally intended to record all the marks on a page and then secondarily their musical meanings.  If someone wants to suggest a new element for "statement of clef" or wants to suggest a name that can be applied to "statements of clef" and "changes of clef" equally well, then I'm all ears.

--
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 Johannes Kepper [kepper at edirom.de]
Sent: Tuesday, June 07, 2011 5:22 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] clef as milestone element

Am 07.06.2011 um 11:03 schrieb Laurent Pugin:

> On Tue, Jun 7, 2011 at 9:52 AM, Benjamin Wolff Bohl <bohl at edirom.de> wrote:
>> Hi everybody,
>>
>> first thanks for the interesting discussion bringing some clarification on
>> what the "layout" module is all about, etc.
>> I'd like to give some inline comments on this summary:
>>
>> Am 01.06.2011 18:25, schrieb Andrew Hankinson, Mr:
>>
>> Before moving on from the <clef /> discussion, I'd like to try and bring in
>> a consensus. The way I've heard it there are a number of options:
>>
>> 1. <clef /> is allowed directly in <layer />;
>>
>> As you say below, this,of course , would solve your immediate problem but
>> what if thinking of multiple layers on one staff; a clef would also affect
>> the other layers, or am I mistaken? If so it would make no logical sense as
>> part on a layer; it should be a direct child of staff.
>>
>
> You are right, but that is not very different from <clefchange> that
> is also allowed in a <layer>. When it occurs on all layers at the same
> time, I guess you will put it on all layers. Am I wrong?

Although I have no example in mind currently, I'm pretty sure that I've seen multiple clefs on one staff for different voices (that is, layers).

>
>> 2. <clef /> is allowed in <sb />, explicitly used as a "cautionary" clef.
>>
>> On this point I agree with Raffaele (31.05.2011):
>>
>> I agree that using clefchange and staffdef for courtesy clef repetitions is
>> a bit cumbersome, but I would advise against overweighting <pb/> and <sb/>.
>> In my opinion they should only signify the break and contain nothing. A
>> custos should occur *before* (or occasionally after) the system break and
>> not within the system break. If you think about it, that is what happens on
>> the page. In the same way, the clef repetition should not be attached to sb
>> or pb.
>>
>> 3. Cautionary clefs should be removed from the "musical" flow and placed in
>> the <layout /> section.
>>
>> Actually this would be THE solution if we stick to the opinion, that the
>> staff should be a virtual "endless" representation of the musical flow. The
>> cautionary clefs are a rendition phenomenon and do not belong to the logic
>> of the music but to the layout. In doing so the layout module would somewhat
>> encode the engraving quality of a specific published edition.
>
> So do <custos> because they could be inferred easily. Would you remove
> them from the logic tree?
>
> We have cases where the clef is missing - that is very frequent with
> typographic prints. How would you encode this? Or when the clef is
> wrong?

For me, the role for the layout module is not so much the description of an existing source (that's what facsimile and music is for), but instead to allow rendering hints for multiple possible interpretations of the data available in music. Of course it can be used to describe existing sources, but that wasn't my understanding of its intention.

What I am wondering is if there isn't a solution 5. We could just rename clefchange to something less semantic (<clefIndication>?), and provide an attribute @reason with two default values 'cautionary' and 'change'. Actually, it could be merged with the existing <clef>, as both have almost the same set of attributes already. Doing so, <clef reason="cautionary" ? /> would be directly allowed within <layer>, without the need for an extra <clefChange>. Could that be a cleaner solution?

What we should make sure is that our changes ? if we agree on a solution ? are copied to the other corresponding staff features meter and key?

Best,
Johannes

>
>>
>> 4. Keep the status quo and use <staffdef> inside <staff> to indicate a
>> cautionary clef.
>>
>> True, this seems a bit of an overkill...
>>
>> While I personally think 2 is the most semantically useful option, I
>> understand that 1 is perhaps the easiest in the short term.
>>
>> I'm not really comfortable with 3, since it removes a musical element from
>> the "flow" of the staff,
>>
>> and 4 seems a bit stilted to me, overloading <staffdef> to not really define
>> anything new about a parent staff.
>>
>> So, I will choose to implement #1 as it seems to solve our immediate issue
>> for the time being.
>>
>> How I propose to solve this is to create a new Incubator project
>> ("clef-milestone") and create an ODD file that makes the change. This can
>> then be reviewed by the Technical Group and, if it's found worthy, rolled
>> into the mainline MEI standard at some point, likely with revisions.
>>
>> Should anyone want to use this in another project they can then create their
>> own customization based on the ODD file. That way they can at least have a
>> reference back to the deviations from the MEI core.
>>
>> In the comments of the ODD file I will reference this discussion so that
>> there's a way to return to it to re-evaluate the positions put forward here
>> when it comes time to review the revision.
>>
>> Does this sound reasonable?
>>
>> Sounds reasonable, all theoretical ideas are only theoretical, whichever
>> solution we opt for it has to be tested practically (option 4 obviously
>> failed, as it resulted in this discussion ;-)
>>
>>
>> Best,
>> Benjamin
>>
>> _______________________________________________
>> 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

From craigsapp at gmail.com  Fri Jun 10 04:19:42 2011
From: craigsapp at gmail.com (Craig Sapp)
Date: Thu, 9 Jun 2011 19:19:42 -0700
Subject: [MEI-L] Debussy La Danse de Puck clef
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D04B4CB@WILSON.eservices.virginia.edu>
References: <BANLkTim6J2N0huLs2Z9SC2tYzBOP1PZ0Hg@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04B4CB@WILSON.eservices.virginia.edu>
Message-ID: <BANLkTi=Pq3p1idw4jqrFeHwoxviRULR0MA@mail.gmail.com>

Hi Perry,

Of course the Debussy/Ravel clef examples are outside of common music
notation syntax, so they should probably be ignored in that sense,
since graphical music notation is an open-ended representation and you
will never be able to fully subdue it :-)  Or in other words,
graphical escape mechanisms would be legitimate to apply in these
cases.

> but for me it's still a clef that's been shifted downward in order to relieve some of the visual "clutter".

In some sense that is how it is functioning, but it is not following
the proper clef syntax, and so it would be difficult to display
properly.  In other words, there is no cancellation of the bass clef
when the treble-clef notes in the next measure occur (yet there is a
repeat of the bass-clef sign in the next measure for the low E's).

In Humdrum, I would encoded the measure along the lines of what you
are thinking, with local layer/voice clefs which conflict with the
primary clef:

**kern
*staff2
*clefG2
32B- 32e- 32gn
8..e- 8..g 8..b-
*^
*                     *clefF4
2e- 2g 2b-        [4EE
.                       8EE]
.                       8r
*v                     *v
=
*-

With *^ being a spine split, and the secondary spine given a different
clef.  When the sub-spines merge again with *v, then presumably the
left-most subspine's clef state would be preserved.  If notation were
to be generated, then there would also need to be some command (as a
comment) in the data for the F-clef to move it down and make it cue
sized.

A useful encoding for this example (and the degenerate Ravel example)
is to have a sub-element (or attribute) for notes which can be used to
indicate with what contrary clef the note is to be displayed on the
staff with:
    clef = treble
    ...
    note
       ---> pitch = E1
       ---> staff-clef = bass
If a note contains such an internal clef, then that would be used to
reinterpret what line on the staff to place the note, since clefs are
coordinate systems for musical pitch placement on the staff.  The
printing of the clef should probably be decoupled from the indication
that the note has a internal clef specification, or there would need
to be an additional indication to suppress printing of the clefs as in
the Ravel Scarbo example.  If the staff-clef is printed, then
vertical, horizontal, and size parameters are needed.

Has the Musikalisches Opfer, BWV 1079 (Bach) been mentioned in the
clef thread?  How would things like table/mirror/crab canons be
encoded in MEI?
    http://www.youtube.com/watch?v=36ykl2tJwZM
Or more traditionally typeset:
    http://imslp.org/wiki/Musikalisches_Opfer,_BWV_1079_%28Bach,_Johann_Sebastian%29
    http://216.129.110.22/files/imglnks/usimg/5/55/IMSLP10042-BWV1079-b.pdf
(see page 8, Canones diversi super thema regium, No. 1).
Number 4 is an interesting one on page 9...

> Of course, the problem with this approach is that a non-human reader of the notation (otherwise known as an
> OMR app) can't know that this is a standard clef with a strange visual placement. ?It even takes expert human
> readers a little while to figure it out.

OMR programs have a lot of other things to get right before they can
tackle this example :-)

In SCORE, I would just encode the visual display literally as seen and
not care about non-visual interpretations of the data.  But if I
wanted the SCORE program to understand the pitches, I would encode as
shown in the attached PDF.  There would be three staves, with the
bottom staff using the bass clef (set to be very tiny, since there are
no invisible clefs in SCORE), and then the two offset bass-clef signs
would be encoded as "misc. objects" (code-9 objects) with offsets
based on the note following it (similar treatment to dynamic markings
in SCORE).  Then the bottom staff and the middle staff would be
superimposed as shown at the bottom of the attached PDF.  Encoding in
this way would allow for SCORE to correctly transpose the example.

-=+Craig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: puck.pdf
Type: application/pdf
Size: 131819 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110609/4a02104d/attachment.pdf>

From pdr4h at eservices.virginia.edu  Fri Jun 10 17:02:01 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Fri, 10 Jun 2011 15:02:01 +0000
Subject: [MEI-L] Debussy La Danse de Puck clef
In-Reply-To: <BANLkTi=Pq3p1idw4jqrFeHwoxviRULR0MA@mail.gmail.com>
References: <BANLkTim6J2N0huLs2Z9SC2tYzBOP1PZ0Hg@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04B4CB@WILSON.eservices.virginia.edu>,
	<BANLkTi=Pq3p1idw4jqrFeHwoxviRULR0MA@mail.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D04B59C@WILSON.eservices.virginia.edu>

Craig,

Your **kern encoding is similar to how I think of encoding this in MEI --

<staff n="2">
  <layer n="1">
  <!-- This layer "inherits" the clef set for this staff earlier. -->
    <chord dur="32">
      <note pname="b" oct="3"/>
      <note pname="e" oct="4"/>
      <note pname="g" oct="4" accid="n"/>
    </chord>
    <chord dur="8" dots="2">
      <note pname="e" oct="4"/>
      <note pname="g" oct="4"/>
      <note pname="b" oct="4"/>
    </chord>
    <chord dur="2">
      <note pname="e" oct="4"/>
      <note pname="g" oct="4"/>
      <note pname="b" oct="4"/>
    </chord>
  </layer>
  <layer n="2">
    <!-- This layer gets a "local" clef definition. -->
    <space dur="4"/>
    <clefChange shape="F" line="4"/>
    <note pname="e" oct="1" dur="4" tie="i"/>
    <note dur="8" tie="t"/>
    <rest dur="8"/>
  </layer>
</staff>

As you say, in the next measure it is assumed that the clef for this staff reverts to the clef.shape and clef.line values set by a preceding <staffDef>.  Or, more precisely, that the clef for layer 1 never actually changed, only the one in layer 2.  And, yes, there should be more attributes on <clefChange> and <clef> to better indicate the clef's relative size and position.  In MEI "geek-speak", it's a matter of making <clef> and <clefChange> members of existing attribute classes (att.relativesize, for example) or adding new attribute classes, if existing classes don't have the desired attributes.

I agree that, if you want to perform transposition or other operations on an encoding, then the encoding must represent the "logical" qualities of the notation first and make the visual qualities secondary.  That's the intention of MEI.  The SCORE "work around" you describe is only necessary because it appears that SCORE can't handle multiple clefs (potentially one for each voice) on a staff. MEI can deal with this multiple clef situation, so I don't see any reason to enshrine the SCORE methodology in MEI.

Adding a "staff-clef" attribute to every note seems like overkill to me.  Isn't this just a different version of what's already going on with <staffDef> and <clefChange>?  In other words, if you want to know what clef a note should be displayed with, you can look backwards to find the last <staffDef> or <clefChange> involving the staff the current note is on.  @staff-clef would be a way to put that information directly on the note without having to scan backwards, which could be helpful, I suppose, but the additional attribute might just add more confusion.  But I could be wrong.  It's happened before. :)  I also haven't looked at the Ravel example in detail.  Please enlighten me, if I've missed something important.

Eventually someone always gets around to mentioning Bach's canons as examples of "strange" notational practice.  My basic answer is that it's possible to encode the notation as presented, for example, in the Canones diversi super thema regium no. 1 on page 8 of a certain edition, or a solution (as given at http://www.youtube.com/watch?v=36ykl2tJwZM).  [I hesitate to say "THE" solution because there can often be more than one solution to a "riddle".]  BUT, I don't think you can encoded both simultaneously in a single encoding.  So, if we choose the first path, the question is how much notational "weirdness" can MEI tolerate before I devolves into chaos?  The visual quirks of the backwards clef and key signature can be represented well enough by adding attributes to elements that represent these things, I suppose, but the "crab-ness" of the performance process can't be encoded without making it explicit; in other words, without providing a "realization".

__________________________
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+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Craig Sapp [craigsapp at gmail.com]
Sent: Thursday, June 09, 2011 10:19 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Debussy La Danse de Puck clef

Hi Perry,

Of course the Debussy/Ravel clef examples are outside of common music
notation syntax, so they should probably be ignored in that sense,
since graphical music notation is an open-ended representation and you
will never be able to fully subdue it :-)  Or in other words,
graphical escape mechanisms would be legitimate to apply in these
cases.

> but for me it's still a clef that's been shifted downward in order to relieve some of the visual "clutter".

In some sense that is how it is functioning, but it is not following
the proper clef syntax, and so it would be difficult to display
properly.  In other words, there is no cancellation of the bass clef
when the treble-clef notes in the next measure occur (yet there is a
repeat of the bass-clef sign in the next measure for the low E's).

In Humdrum, I would encoded the measure along the lines of what you
are thinking, with local layer/voice clefs which conflict with the
primary clef:

**kern
*staff2
*clefG2
32B- 32e- 32gn
8..e- 8..g 8..b-
*^
*                     *clefF4
2e- 2g 2b-        [4EE
.                       8EE]
.                       8r
*v                     *v
=
*-

With *^ being a spine split, and the secondary spine given a different
clef.  When the sub-spines merge again with *v, then presumably the
left-most subspine's clef state would be preserved.  If notation were
to be generated, then there would also need to be some command (as a
comment) in the data for the F-clef to move it down and make it cue
sized.

A useful encoding for this example (and the degenerate Ravel example)
is to have a sub-element (or attribute) for notes which can be used to
indicate with what contrary clef the note is to be displayed on the
staff with:
    clef = treble
    ...
    note
       ---> pitch = E1
       ---> staff-clef = bass
If a note contains such an internal clef, then that would be used to
reinterpret what line on the staff to place the note, since clefs are
coordinate systems for musical pitch placement on the staff.  The
printing of the clef should probably be decoupled from the indication
that the note has a internal clef specification, or there would need
to be an additional indication to suppress printing of the clefs as in
the Ravel Scarbo example.  If the staff-clef is printed, then
vertical, horizontal, and size parameters are needed.

Has the Musikalisches Opfer, BWV 1079 (Bach) been mentioned in the
clef thread?  How would things like table/mirror/crab canons be
encoded in MEI?
    http://www.youtube.com/watch?v=36ykl2tJwZM
Or more traditionally typeset:
    http://imslp.org/wiki/Musikalisches_Opfer,_BWV_1079_%28Bach,_Johann_Sebastian%29
    http://216.129.110.22/files/imglnks/usimg/5/55/IMSLP10042-BWV1079-b.pdf
(see page 8, Canones diversi super thema regium, No. 1).
Number 4 is an interesting one on page 9...

> Of course, the problem with this approach is that a non-human reader of the notation (otherwise known as an
> OMR app) can't know that this is a standard clef with a strange visual placement.  It even takes expert human
> readers a little while to figure it out.

OMR programs have a lot of other things to get right before they can
tackle this example :-)

In SCORE, I would just encode the visual display literally as seen and
not care about non-visual interpretations of the data.  But if I
wanted the SCORE program to understand the pitches, I would encode as
shown in the attached PDF.  There would be three staves, with the
bottom staff using the bass clef (set to be very tiny, since there are
no invisible clefs in SCORE), and then the two offset bass-clef signs
would be encoded as "misc. objects" (code-9 objects) with offsets
based on the note following it (similar treatment to dynamic markings
in SCORE).  Then the bottom staff and the middle staff would be
superimposed as shown at the bottom of the attached PDF.  Encoding in
this way would allow for SCORE to correctly transpose the example.

-=+Craig

From andrew.hankinson at mail.mcgill.ca  Fri Jun 10 17:58:06 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Fri, 10 Jun 2011 15:58:06 +0000
Subject: [MEI-L] Debussy La Danse de Puck clef
In-Reply-To: <3090_1307718144_4DF231FF_3090_144_8_BBCC497C40D85642B90E9F94FC30343D04B59C@WILSON.eservices.virginia.edu>
References: <BANLkTim6J2N0huLs2Z9SC2tYzBOP1PZ0Hg@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04B4CB@WILSON.eservices.virginia.edu>, 
	<BANLkTi=Pq3p1idw4jqrFeHwoxviRULR0MA@mail.gmail.com>
	<3090_1307718144_4DF231FF_3090_144_8_BBCC497C40D85642B90E9F94FC30343D04B59C@WILSON.eservices.virginia.edu>
Message-ID: <8335C8A4-62F6-46E3-A939-86532A1B3FDF@mail.mcgill.ca>


On 2011-06-10, at 11:02 AM, Roland, Perry (pdr4h) wrote:

> As you say, in the next measure it is assumed that the clef for this staff reverts to the clef.shape and clef.line values set by a preceding <staffDef>.  Or, more precisely, that the clef for layer 1 never actually changed, only the one in layer 2.  And, yes, there should be more attributes on <clefChange> and <clef> to better indicate the clef's relative size and position.  In MEI "geek-speak", it's a matter of making <clef> and <clefChange> members of existing attribute classes (att.relativesize, for example) or adding new attribute classes, if existing classes don't have the desired attributes.

I always get a bit antsy when I see the word "assumed" in dealing with documents that are ultimately meant to be consumed by a computer, and not a human. In general, MEI makes extensive use of milestone elements to denote the beginnings of something, but this is at the expense of actually knowing when to end something. In this case, we have an explicit <clefChange /> as a child of layer 2, but no explicit "<endClefChange />" (which would be ridiculous, of course...).

This is fine in the local context, but should there need to be *another* layer 2 in the next measure (for a different reason), would it be safe to say that the new layer inherits from the previous layer 2? I suspect that in this case, the answer is "no," because in this case a layer is a layer in the graphic sense -- it's something that's outside of the base flow that when flattened makes sense, but needs to have some sort of separation from the underlying notation.

However, this stance immediately becomes problematic when you equate "layers" with "voices," as the current documentation for layer alludes. Layers seem to want to continue over measures in order to give some sense of continuity of the voice. If a clef change happened in a previous layer in a previous staff or measure when layer is functioning as a voice, I assume that it should hold until another clef change in the same voice. This gives us two conflicting cases where, in some instances the <clefChange /> is a local change that only holds until the end of the layer, and in others it holds until the next milestone is reached.



From zupftom at googlemail.com  Thu Jun 16 11:34:43 2011
From: zupftom at googlemail.com (TW)
Date: Thu, 16 Jun 2011 11:34:43 +0200
Subject: [MEI-L] How to use <ftrem>
Message-ID: <BANLkTi=bDDRMmi4A84wTcYT8tiG4sWGvSw@mail.gmail.com>

I'm not sure what's the proper way of using <ftrem>.  If I want to
encode the last <ftrem> from this image:

http://www.music-encoding.org/pix/tagLibrary/meiTagLibrary2010-05_html_25c82644.png

would I do it like this (assuming it's in treble clef):

<beam>
  <ftrem slash="1">
    <note pname="f" dur="32" oct="4"/>
    <note pname="a" dur="32" oct="4"/>
  </ftrem>
</beam>

i.e. this is a pair of properly beamed 32nd notes with an additional
stroke, or like this:

<ftrem slash="4">

  <note pname="f" dur="32" oct="4"/>

  <note pname="a" dur="32" oct="4"/>

</ftrem>


assuming that slash="4" and @dur="32" imply that we have three beams
and one slash?

Analogously, how would I encode the second <ftrem>:

<beam>

  <ftrem slash="2">

    <note pname="f" dur="2" oct="4"/>

    <note pname="a" dur="2" oct="4"/>

  </ftrem>

</beam>

i.e. a pair of "improperly" beamed half notes with an additional
slash?  I'm not sure, could there be half note heads with two or more
beams?  How do I tell how many beams?  Or like this:

<ftrem slash="3">

  <note pname="f" dur="2" oct="4"/>

  <note pname="a" dur="2" oct="4"/>

</ftrem>


and ftrem/@slash="3" and note/@dur="2" imply that I have one beam and
two slashes?  Could there be half notes without beam and only with
slashes?  And wouldn't it make sense to have an ftrem/@dur attribute,
analogously to chord/@dur?

It would be great if the images in the documentation could be
supplemented with code examples (did I understand correctly that this
is work in progress?)

Thanks!
Thomas Weber


From pdr4h at eservices.virginia.edu  Fri Jun 17 05:31:18 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Fri, 17 Jun 2011 03:31:18 +0000
Subject: [MEI-L] How to use <ftrem>
In-Reply-To: <BANLkTi=bDDRMmi4A84wTcYT8tiG4sWGvSw@mail.gmail.com>
References: <BANLkTi=bDDRMmi4A84wTcYT8tiG4sWGvSw@mail.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D04BB5E@WILSON.eservices.virginia.edu>

Hi Thomas,

One should never count beams separate from slashes -- count only slashes.  Treating tremolandi this way makes them uniform in the markup regardless of the note durations involved.  So, the way to encode your first example is

<ftrem slash="4">
  <note pname="f" dur="32" oct="4"/>
  <note pname="a" dur="32" oct="4"/>
</ftrem>

Your second example should be

<ftrem slash="3">
  <note pname="f" dur="2" oct="4"/>
  <note pname="a" dur="2" oct="4"/>
</ftrem>

In fact, all the tremolandi except the last are encoded exactly the same way (<ftrem slash="3">) except for the note durations.  Now, exactly *how* the slashes are drawn is left to the rendering process.

What you're calling a "beam" isn't really.  Depending on the rhythmic values involved, one or more of the "slashes" are drawn connecting the notes (making it/them look "beam-like"), the rest are disconnected from the note stems.  Therefore, none of the notes in the example are "properly" or "improperly" beamed -- they're not "beamed" at all.

I don't have access to Read at the moment, but the rules for tremolandi are covered there.  In fact, this example comes directly from Read, which is invaluable for answering notational questions.  I highly recommend that anyone working with CMN notation have a copy nearby.  And, no, I don't get any reward from the author or the publisher for the recommendation.

I suppose that somewhere out in the "wild" there are 2-beat tremolos with "no beam and 3 slashes" (especially in manuscript), but that notation would just be incorrect.  If we set ourselves the goal of representing incorrect notation, then we'll be back to describing "lines and circles"; in other words, nothing more than the marks on the page.  If it's important, one can include a facsimile image to show the incorrect notation, using something like

<ftrem slash="3" facs="idOfTheZoneContainingIncorrectNotation">.

I think adding @dur on ftrem makes sense because it would allow the omission of it on the individual notes, just as on chord.  Is that what you were thinking?

Yes, the documentation is an on-going effort.  Regrettably, I haven't had as much time to devote to it as it deserves. Any volunteers to mark up the notation in the Tag Library?

--
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 TW [zupftom at googlemail.com]
Sent: Thursday, June 16, 2011 5:34 AM
To: Music Encoding Initiative
Subject: [MEI-L] How to use <ftrem>

I'm not sure what's the proper way of using <ftrem>.  If I want to
encode the last <ftrem> from this image:

http://www.music-encoding.org/pix/tagLibrary/meiTagLibrary2010-05_html_25c82644.png

would I do it like this (assuming it's in treble clef):

<beam>
  <ftrem slash="1">
    <note pname="f" dur="32" oct="4"/>
    <note pname="a" dur="32" oct="4"/>
  </ftrem>
</beam>

i.e. this is a pair of properly beamed 32nd notes with an additional
stroke, or like this:

<ftrem slash="4">

  <note pname="f" dur="32" oct="4"/>

  <note pname="a" dur="32" oct="4"/>

</ftrem>


assuming that slash="4" and @dur="32" imply that we have three beams
and one slash?

Analogously, how would I encode the second <ftrem>:

<beam>

  <ftrem slash="2">

    <note pname="f" dur="2" oct="4"/>

    <note pname="a" dur="2" oct="4"/>

  </ftrem>

</beam>

i.e. a pair of "improperly" beamed half notes with an additional
slash?  I'm not sure, could there be half note heads with two or more
beams?  How do I tell how many beams?  Or like this:

<ftrem slash="3">

  <note pname="f" dur="2" oct="4"/>

  <note pname="a" dur="2" oct="4"/>

</ftrem>


and ftrem/@slash="3" and note/@dur="2" imply that I have one beam and
two slashes?  Could there be half notes without beam and only with
slashes?  And wouldn't it make sense to have an ftrem/@dur attribute,
analogously to chord/@dur?

It would be great if the images in the documentation could be
supplemented with code examples (did I understand correctly that this
is work in progress?)

Thanks!
Thomas Weber

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

From roewenstrunk at edirom.de  Fri Jun 17 09:49:20 2011
From: roewenstrunk at edirom.de (=?UTF-8?B?RGFuaWVsIFLDtndlbnN0cnVuaw==?=)
Date: Fri, 17 Jun 2011 09:49:20 +0200
Subject: [MEI-L] [ANN] Edirom Summer School 2011
Message-ID: <4DFB0700.1030901@edirom.de>

Hi all,
like last year we are going to have a summer school in mid September, where we will have five courses dealing with MEI, TEI, XML in general and digital editing with our Edirom tools. These courses will held in german at the University of Paderborn. Registration is now open and available at http://www.edirom.de/das-forschungsprojekt/veranstaltungen/aktuelle-veranstaltungen/edirom-summer-school-2011/. Like last year: there is no course fee.
You find the full announcement in german below.

Cheers, Daniel



**** Full announcement in german ****

Sehr geehrte Damen und Herren,

nach dem gro?en Erfolg der letztj?hrigen Summer School veranstaltet das am Musikwissenschaftlichen Seminar Detmold/Paderborn ans?ssige Edirom-Projekt dieses Jahr vom 12. bis 16. September am Campus der Universit?t Paderborn die "Edirom-Summer-School 2011".

In der Musikwissenschaft und den Geisteswissenschaften generell wird die Arbeit mit XML und den sogenannten XML-Technologien immer wichtiger. In den letzten Jahren haben sich in den Digital Humanities fast ausschlie?lich Dateiformate etabliert, die auf der eXtensible Markup
Language (XML) basieren.

Im Rahmen der Summer School bieten wir f?nf Workshops an, die sich den Technologien und Arbeitsweisen der Digitalen Edition aus geisteswissenschaftlicher Perspektive annehmen. Wir starten mit zwei parallelen XML Einf?hrungskursen zu MEI bzw. TEI, die als Neueinstieg oder Auffrischung gedacht sind; es schlie?t sich ein Kurs "Arbeiten mit XML" an, der sich mit gezielten Anfragen an bzw. ?nderungen in vorhandenen XML-Daten befasst; schlie?lich behandeln zwei gleichzeitig stattfindende Workshops die vom Edirom-Projekt entwickelten Software-Tools zur Erstellung Digitaler Musikeditionen bzw. das fortgeschrittene Auszeichnen philologischer Dokumente mit TEI.

Weitere Informationen sowie die M?glichkeit zur Anmeldung finden Sie auf unserer Website unter:
http://www.edirom.de/summerschool

Die Teilnahme an den Kursen ist kostenlos, wir bitten dennoch um eine vorherige Anmeldung um unsere Planung zu erleichtern; Anmeldeschluss ist der 15.08.2011.
Bei zu geringen Teilnehmerzahlen behalten wir uns vor, einzelne Kurse zusammenzulegen bzw. abzusagen.

Wir m?chten ausdr?cklich darauf hinweisen, dass sich die ersten beiden Workshops, sowie der zu den Edirom-Tools auch ohne Vorkenntnisse auf den genannten Gebieten besucht werden k?nnen, allerdings setzen die weiteren Kurse XML-Kenntnisse voraus (die ggf. in den Einf?hrungskursen erworben werden k?nnen).

Wir w?rden uns sehr freuen, Sie bei dieser Veranstaltung zu begr??en.
Mit freundlichen Gr??en,
Benjamin W. Bohl

**** Workshop-Beschreibungen ****

XML-Einf?hrung TEI
12.09. - 13.09.
Dozent: Peter Stadler

Eine Einf?hrung in die Grundlagen von XML anhand des Schemas der Text Encoding Initiative (TEI). Der Kurs ist konzeptionell f?r Einsteiger in beiden Bereichen angelegt. Sowohl XML-Einsteiger als auch TEI-Neulinge bekommen eine zielorientierte Einf?hrung in technische Grundlagen, Benutzung, Sinn und Zweck der Textauszeichnung. Auch fortgeschrittene Teilnehmer, die ihre XML oder TEI Kenntnisse auffrischen m?chten sind willkommen.


XML-Einf?hrung MEI
12.09. - 13.09.
Dozent: Johannes Kepper

Eine Einf?hrung in die Grundlagen von XML anhand des Schemas der Music Encoding Initiative (MEI). Der Kurs ist konzeptionell f?r Einsteiger in beiden Bereichen angelegt. Sowohl XML-Einsteiger als auch MEI-Neulinge bekommen eine zielorientierte Einf?hrung in technische Grundlagen, Benutzung, Sinn und Zweck der Textauszeichnung. Auch fortgeschrittene Teilnehmer, die ihre XML oder MEI Kenntnisse auffrischen m?chten sind willkommen.


Arbeiten mit XML
14.09.
Dozenten: Daniel R?wenstrunk und Benjamin W. Bohl

Ich habe eine XML-Datei ? was jetzt? Wie kann ich die Daten bearbeiten oder auswerten? Wie nehme ich ?nderungen an vielen Stellen oder in vielen Dateien gleichzeitig vor? Dies ist ein Auszug der Fragen, mit denen sich die Teilnehmer dieses Kurses besch?ftigen werden. Am Beispiel von TEI- und MEI-Dokumenten soll gezeigt werden, wie man:

    * mit XPath gezielte Knotenanfragen an eine XML-Datei stellt,
    * mit Hilfe Regul?rer Ausdr?cke Anfragen oder Modifikationen  innerhalb oder ?ber die Grenzen der XML-Strukturen hinaus formuliert,
    * mit XSLT die Daten in eine neue Struktur ?berf?hrt,
    * mit XQuery Anfragen an eine oder mehrere Dateien formuliert oder mit der Update-Erweiterung ?nderungen vornimmt.


Dieser Kurs richtet sich an Teilnehmer, die bereits Erfahrungen im Umgang mit XML gesammelt haben. Die Formulierung von eigenen Fragestellungen bzw. Problemstellungen und vorab eine  Zusendung von Fragen oder Problemstellungen via E-Mail (bohl[at]edirom.de) inklusive der n?tigen Dateien wird ausdr?cklich begr??t, damit wir auf Ihre Bed?rfnisse eingehen k?nnen.


Edirom-Tools
15.09. - 16.09.
Dozenten: Daniel R?wenstrunk und Benjamin W. Bohl

Das Edirom Projekt entwickelt Softwareprodukte zur Publikation und Erstellung von Digitalen Musikeditionen. Ziel der entwickelten Werkzeuge ist es, die wissenschaftlichen Herausgeber beim Erstellungsprozess insoweit zu unterst?tzen, dass ein weniger technisches, als vielmehr intuitives Arbeiten mit den in den anderen Kursen behandelten XML-Formaten m?glich wird. Im Mittelpunkt des Workshops werden die Arbeitsabl?ufe zur Erstellung einer Digitalen Edition stehen und die Art und Weise wie diese von unserer Software unterst?tzt werden. Aber auch die Anpassung der Software an die editionsspezifischen Anforderungen sowie die Erstellung und Integration von Inhalten, die nicht mit dem Edirom Editor erstellt werden k?nnen sollen Beachtung finden.

Dieser Workshop richtet sich insbesondere an Benutzer unserer Softwareprodukte, ?berdies sind nat?rlich auch Teilnehmer besonders willkommen, die sich grundlegend ?ber die Edirom-Tools informieren m?chten.

Arbeiten  mit TEI
15.09. - 16.09.
Dozent: Peter Stadler

Dieser Kurs soll einen vertiefenden Einblick in das Arbeiten mit TEI bieten. Anhand praxisbezogener Beispiele sollen u.a. eingef?hrt werden:

    * das inhaltliche Auszeichnen von Personen, Daten und Orten im Text sowie das Verwalten entsprechender Normdaten im Header (Modul namesdates)
    *  das Erfassen von mehreren Textzeugen im Header und das Auszeichnen von Lesarten im Text (Modul textcrit)
    * das Auszeichnen von textuellen Ersetzungen, Streichungen und Hinzuf?gungen sowie Sch?den des Textzeugen (Modul transcr)

 Im Vordergrund steht dabei immer das eigenst?ndige Arbeiten mit den TEI Guidelines, so dass darauf aufbauend auch andere TEI Module erarbeitet werden k?nnen.
***


Mit freundlichen Gr??en,
Benjamin Wolff Bohl

***********************************************************
Benjamin Wolff Bohl, M.A.
Wiss. Mitarbeiter
Projekt "Digitale Musikedition" (Edirom)

Musikwissenschaftliches Seminar Detmold/Paderborn
Gartenstra?e 20
D ? 32756 Detmold

Tel. +49 (0) 5231 / 975-669
Fax: +49 (0) 5231 / 975-668
E-Mail: bohl[at]edirom.de
URL: http://www.edirom.de
***********************************************************



From zupftom at googlemail.com  Fri Jun 17 10:45:38 2011
From: zupftom at googlemail.com (TW)
Date: Fri, 17 Jun 2011 10:45:38 +0200
Subject: [MEI-L] How to use <ftrem>
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D04BB5E@WILSON.eservices.virginia.edu>
References: <BANLkTi=bDDRMmi4A84wTcYT8tiG4sWGvSw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04BB5E@WILSON.eservices.virginia.edu>
Message-ID: <BANLkTi=o8m=SeHQeQcqRDm01GPxGWo2MuA@mail.gmail.com>

Hi Roland,

thanks for your reply.  I have a handful of notation books on the
shelf, among them Read.  The image that is reproduced in the
documentation is from page 395.  But on many other occurences of
fingered tremolos in his book (p. 235-236, p. 330, p. 371-372), using
either one beam+slashes or only beams on half notes.  Does he make a
distinction in notation between measured and unmeasured tremolo that I
don't quite get?

By the way, all of the books I checked seem to use the terminology
"beam" in the context of fingered tremolos.  (Helene Wanske even talks
about beams (Balken) if the slashes aren't fully connecting the
stems.)

Here's what my sources say:
- Helene Wanske: Musiknotation, p. 117: half notes connected with full
32nd beams; I didn't see an alternative in the book [on p. 167 she
says, quarter notes, although the "beam" doesn't entirely connect the
stems, are regarded as "beamed"]
- Brockhaus Riemann Musik-Lexikon: Abbreviaturen 4): half notes with
one, two and three full beams, no alternatives
- Herbert Chlapik: Die Praxis des Notengrafikers, p.46: there are half
notes with one, two and three full beams on this page, no other
notation with half notes
- George Heussenstamm: The Norton Manual of Music Notation, p. 55:
"Preferred Notation": half notes with one beam and two slashes,
"Traditional Notation": half notes with three full beams,  "Possible
Notation": half notes without full beams and three slashes.
Interestingly, on p. 56 he only uses "Traditional Notation" instead of
"Preferred Notation".
- Ted Ross: The Art of Music Engraving and Processing, p. 199: there
is an example of fully beamed half notes first, then "or" and the same
example notated with one beam and two slashes.  Later on he uses the
fully beamed notation for one example and the beams+slashes version
for another example so his use is pretty balanced between the two
notations.

So the "no slashes, all beams" solution is given six times, the "one
beam, rest slashes" solution is given three times (both numbers
including Read) and Heussenstamm's "Possible Notation" is given once.
Maybe someone can check what Faber Music's "Behind Bars" says - that's
not yet part of my collection (and also pretty expensive).

In my opinion there *should* be a convention for specifying the number
of beams.  There doesn't seem to be a single correct solution.  It's
probably best if the "repetition frequency" can directly be derived
from @slash.  But <beam> doesn't allow specifying the number of beams,
that's implicit.

And yes, I meant @dur on ftrem, just like with chords.

Thomas Weber


2011/6/17 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> Hi Thomas,
>
> One should never count beams separate from slashes -- count only slashes. ?Treating tremolandi this way makes them uniform in the markup regardless of the note durations involved. ?So, the way to encode your first example is
>
> <ftrem slash="4">
> ?<note pname="f" dur="32" oct="4"/>
> ?<note pname="a" dur="32" oct="4"/>
> </ftrem>
>
> Your second example should be
>
> <ftrem slash="3">
> ?<note pname="f" dur="2" oct="4"/>
> ?<note pname="a" dur="2" oct="4"/>
> </ftrem>
>
> In fact, all the tremolandi except the last are encoded exactly the same way (<ftrem slash="3">) except for the note durations. ?Now, exactly *how* the slashes are drawn is left to the rendering process.
>
> What you're calling a "beam" isn't really. ?Depending on the rhythmic values involved, one or more of the "slashes" are drawn connecting the notes (making it/them look "beam-like"), the rest are disconnected from the note stems. ?Therefore, none of the notes in the example are "properly" or "improperly" beamed -- they're not "beamed" at all.
>
> I don't have access to Read at the moment, but the rules for tremolandi are covered there. ?In fact, this example comes directly from Read, which is invaluable for answering notational questions. ?I highly recommend that anyone working with CMN notation have a copy nearby. ?And, no, I don't get any reward from the author or the publisher for the recommendation.
>
> I suppose that somewhere out in the "wild" there are 2-beat tremolos with "no beam and 3 slashes" (especially in manuscript), but that notation would just be incorrect. ?If we set ourselves the goal of representing incorrect notation, then we'll be back to describing "lines and circles"; in other words, nothing more than the marks on the page. ?If it's important, one can include a facsimile image to show the incorrect notation, using something like
>
> <ftrem slash="3" facs="idOfTheZoneContainingIncorrectNotation">.
>
> I think adding @dur on ftrem makes sense because it would allow the omission of it on the individual notes, just as on chord. ?Is that what you were thinking?
>
> Yes, the documentation is an on-going effort. ?Regrettably, I haven't had as much time to devote to it as it deserves. Any volunteers to mark up the notation in the Tag Library?
>
> --
> 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 TW [zupftom at googlemail.com]
> Sent: Thursday, June 16, 2011 5:34 AM
> To: Music Encoding Initiative
> Subject: [MEI-L] How to use <ftrem>
>
> I'm not sure what's the proper way of using <ftrem>. ?If I want to
> encode the last <ftrem> from this image:
>
> http://www.music-encoding.org/pix/tagLibrary/meiTagLibrary2010-05_html_25c82644.png
>
> would I do it like this (assuming it's in treble clef):
>
> <beam>
> ?<ftrem slash="1">
> ? ?<note pname="f" dur="32" oct="4"/>
> ? ?<note pname="a" dur="32" oct="4"/>
> ?</ftrem>
> </beam>
>
> i.e. this is a pair of properly beamed 32nd notes with an additional
> stroke, or like this:
>
> <ftrem slash="4">
>
> ?<note pname="f" dur="32" oct="4"/>
>
> ?<note pname="a" dur="32" oct="4"/>
>
> </ftrem>
>
>
> assuming that slash="4" and @dur="32" imply that we have three beams
> and one slash?
>
> Analogously, how would I encode the second <ftrem>:
>
> <beam>
>
> ?<ftrem slash="2">
>
> ? ?<note pname="f" dur="2" oct="4"/>
>
> ? ?<note pname="a" dur="2" oct="4"/>
>
> ?</ftrem>
>
> </beam>
>
> i.e. a pair of "improperly" beamed half notes with an additional
> slash? ?I'm not sure, could there be half note heads with two or more
> beams? ?How do I tell how many beams? ?Or like this:
>
> <ftrem slash="3">
>
> ?<note pname="f" dur="2" oct="4"/>
>
> ?<note pname="a" dur="2" oct="4"/>
>
> </ftrem>
>
>
> and ftrem/@slash="3" and note/@dur="2" imply that I have one beam and
> two slashes? ?Could there be half notes without beam and only with
> slashes? ?And wouldn't it make sense to have an ftrem/@dur attribute,
> analogously to chord/@dur?
>
> It would be great if the images in the documentation could be
> supplemented with code examples (did I understand correctly that this
> is work in progress?)
>
> Thanks!
> Thomas Weber
>
> _______________________________________________
> 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
>


From pdr4h at eservices.virginia.edu  Fri Jun 17 15:40:09 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Fri, 17 Jun 2011 13:40:09 +0000
Subject: [MEI-L] How to use <ftrem>
In-Reply-To: <BANLkTi=o8m=SeHQeQcqRDm01GPxGWo2MuA@mail.gmail.com>
References: <BANLkTi=bDDRMmi4A84wTcYT8tiG4sWGvSw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04BB5E@WILSON.eservices.virginia.edu>,
	<BANLkTi=o8m=SeHQeQcqRDm01GPxGWo2MuA@mail.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D04BC48@WILSON.eservices.virginia.edu>

To me, the inconsistency Thomas reports in the various ways of counting the number of beams vs. slashes indicates different rendering possibilities for the same semantic construct.  While it provides rendering "hints", in general, MEI leaves rendering to a down-stream process.  Perhaps, however, ftrem is a case where it would make sense to provide enhancements to the current hints; so, I'm not averse to adding a beam attribute on ftrem.

Adding @beam is easy, but it forces us to formulate a convention for what counts as a "beam" and what counts as a "slash".  Assuming that beams are the things that connect stems and slashes are those things that are between the stems (but don't touch them) is the simplest solution.  But, then @slash can't be used to accurately calculate the repetition frequency in a sounded rendition.  So this must lead us to another attribute that will carry this information.  This might be an improvement as this new attribute could be placed in the gestural domain, leaving the others in the logical/visual domain.

Another approach might be to count everything (whether it connects the stems or not) as a "slash", with @beams recording the subset of the slashes that actually connect the stems.  This will allow us to continue to calculate the repetition frequency based on the value of @slash.

I can see advantages and disadvantages in both these solutions.  I think the literalists among us (OMRers, Score devotees, perhaps?) will prefer the first one, while those who are interested more in semantics than visualization might prefer the second.  I'm not attached to either one, but I think Thomas' arguments are convincing, so I lean toward the first option above.  Anyway, now is the time to make a change if we need to.  Comments here will help in the decision, so please speak up.

BTW, I don't want to ignite a religious war over the terminology "beam" and "slash".  As always, if anyone has an idea for better names, I'm listening.

--
Perry

__________________________
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 TW [zupftom at googlemail.com]
Sent: Friday, June 17, 2011 4:45 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] How to use <ftrem>

Hi Roland,

thanks for your reply.  I have a handful of notation books on the
shelf, among them Read.  The image that is reproduced in the
documentation is from page 395.  But on many other occurences of
fingered tremolos in his book (p. 235-236, p. 330, p. 371-372), using
either one beam+slashes or only beams on half notes.  Does he make a
distinction in notation between measured and unmeasured tremolo that I
don't quite get?

By the way, all of the books I checked seem to use the terminology
"beam" in the context of fingered tremolos.  (Helene Wanske even talks
about beams (Balken) if the slashes aren't fully connecting the
stems.)

Here's what my sources say:
- Helene Wanske: Musiknotation, p. 117: half notes connected with full
32nd beams; I didn't see an alternative in the book [on p. 167 she
says, quarter notes, although the "beam" doesn't entirely connect the
stems, are regarded as "beamed"]
- Brockhaus Riemann Musik-Lexikon: Abbreviaturen 4): half notes with
one, two and three full beams, no alternatives
- Herbert Chlapik: Die Praxis des Notengrafikers, p.46: there are half
notes with one, two and three full beams on this page, no other
notation with half notes
- George Heussenstamm: The Norton Manual of Music Notation, p. 55:
"Preferred Notation": half notes with one beam and two slashes,
"Traditional Notation": half notes with three full beams,  "Possible
Notation": half notes without full beams and three slashes.
Interestingly, on p. 56 he only uses "Traditional Notation" instead of
"Preferred Notation".
- Ted Ross: The Art of Music Engraving and Processing, p. 199: there
is an example of fully beamed half notes first, then "or" and the same
example notated with one beam and two slashes.  Later on he uses the
fully beamed notation for one example and the beams+slashes version
for another example so his use is pretty balanced between the two
notations.

So the "no slashes, all beams" solution is given six times, the "one
beam, rest slashes" solution is given three times (both numbers
including Read) and Heussenstamm's "Possible Notation" is given once.
Maybe someone can check what Faber Music's "Behind Bars" says - that's
not yet part of my collection (and also pretty expensive).

In my opinion there *should* be a convention for specifying the number
of beams.  There doesn't seem to be a single correct solution.  It's
probably best if the "repetition frequency" can directly be derived
from @slash.  But <beam> doesn't allow specifying the number of beams,
that's implicit.

And yes, I meant @dur on ftrem, just like with chords.

Thomas Weber


2011/6/17 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> Hi Thomas,
>
> One should never count beams separate from slashes -- count only slashes.  Treating tremolandi this way makes them uniform in the markup regardless of the note durations involved.  So, the way to encode your first example is
>
> <ftrem slash="4">
>  <note pname="f" dur="32" oct="4"/>
>  <note pname="a" dur="32" oct="4"/>
> </ftrem>
>
> Your second example should be
>
> <ftrem slash="3">
>  <note pname="f" dur="2" oct="4"/>
>  <note pname="a" dur="2" oct="4"/>
> </ftrem>
>
> In fact, all the tremolandi except the last are encoded exactly the same way (<ftrem slash="3">) except for the note durations.  Now, exactly *how* the slashes are drawn is left to the rendering process.
>
> What you're calling a "beam" isn't really.  Depending on the rhythmic values involved, one or more of the "slashes" are drawn connecting the notes (making it/them look "beam-like"), the rest are disconnected from the note stems.  Therefore, none of the notes in the example are "properly" or "improperly" beamed -- they're not "beamed" at all.
>
> I don't have access to Read at the moment, but the rules for tremolandi are covered there.  In fact, this example comes directly from Read, which is invaluable for answering notational questions.  I highly recommend that anyone working with CMN notation have a copy nearby.  And, no, I don't get any reward from the author or the publisher for the recommendation.
>
> I suppose that somewhere out in the "wild" there are 2-beat tremolos with "no beam and 3 slashes" (especially in manuscript), but that notation would just be incorrect.  If we set ourselves the goal of representing incorrect notation, then we'll be back to describing "lines and circles"; in other words, nothing more than the marks on the page.  If it's important, one can include a facsimile image to show the incorrect notation, using something like
>
> <ftrem slash="3" facs="idOfTheZoneContainingIncorrectNotation">.
>
> I think adding @dur on ftrem makes sense because it would allow the omission of it on the individual notes, just as on chord.  Is that what you were thinking?
>
> Yes, the documentation is an on-going effort.  Regrettably, I haven't had as much time to devote to it as it deserves. Any volunteers to mark up the notation in the Tag Library?
>
> --
> 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 TW [zupftom at googlemail.com]
> Sent: Thursday, June 16, 2011 5:34 AM
> To: Music Encoding Initiative
> Subject: [MEI-L] How to use <ftrem>
>
> I'm not sure what's the proper way of using <ftrem>.  If I want to
> encode the last <ftrem> from this image:
>
> http://www.music-encoding.org/pix/tagLibrary/meiTagLibrary2010-05_html_25c82644.png
>
> would I do it like this (assuming it's in treble clef):
>
> <beam>
>  <ftrem slash="1">
>    <note pname="f" dur="32" oct="4"/>
>    <note pname="a" dur="32" oct="4"/>
>  </ftrem>
> </beam>
>
> i.e. this is a pair of properly beamed 32nd notes with an additional
> stroke, or like this:
>
> <ftrem slash="4">
>
>  <note pname="f" dur="32" oct="4"/>
>
>  <note pname="a" dur="32" oct="4"/>
>
> </ftrem>
>
>
> assuming that slash="4" and @dur="32" imply that we have three beams
> and one slash?
>
> Analogously, how would I encode the second <ftrem>:
>
> <beam>
>
>  <ftrem slash="2">
>
>    <note pname="f" dur="2" oct="4"/>
>
>    <note pname="a" dur="2" oct="4"/>
>
>  </ftrem>
>
> </beam>
>
> i.e. a pair of "improperly" beamed half notes with an additional
> slash?  I'm not sure, could there be half note heads with two or more
> beams?  How do I tell how many beams?  Or like this:
>
> <ftrem slash="3">
>
>  <note pname="f" dur="2" oct="4"/>
>
>  <note pname="a" dur="2" oct="4"/>
>
> </ftrem>
>
>
> and ftrem/@slash="3" and note/@dur="2" imply that I have one beam and
> two slashes?  Could there be half notes without beam and only with
> slashes?  And wouldn't it make sense to have an ftrem/@dur attribute,
> analogously to chord/@dur?
>
> It would be great if the images in the documentation could be
> supplemented with code examples (did I understand correctly that this
> is work in progress?)
>
> Thanks!
> Thomas Weber
>
> _______________________________________________
> 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

From zupftom at googlemail.com  Fri Jun 17 16:17:48 2011
From: zupftom at googlemail.com (TW)
Date: Fri, 17 Jun 2011 16:17:48 +0200
Subject: [MEI-L] How to use <ftrem>
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D04BC48@WILSON.eservices.virginia.edu>
References: <BANLkTi=bDDRMmi4A84wTcYT8tiG4sWGvSw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04BB5E@WILSON.eservices.virginia.edu>
	<BANLkTi=o8m=SeHQeQcqRDm01GPxGWo2MuA@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04BC48@WILSON.eservices.virginia.edu>
Message-ID: <BANLkTimuCThVEdjSHbqO8F7dDdjfb1vrvw@mail.gmail.com>

While I'm sort of a Score devotee, I think that the repetition
frequency should definitely be derivable from @slash.  But thinking
about it a bit longer, it's really tricky.  As the visual appearance
is only uncertain for half notes, what would using @beam on notes
other than half notes mean?  That wouldn't make a lot of sense.  For
@dur=16, it would look as if one should set @beam=2, but that would be
very inconsistent with the meaning of n=@beam "n of the slashes are
written as beams".

Thomas Weber


2011/6/17 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> To me, the inconsistency Thomas reports in the various ways of counting the number of beams vs. slashes indicates different rendering possibilities for the same semantic construct. ?While it provides rendering "hints", in general, MEI leaves rendering to a down-stream process. ?Perhaps, however, ftrem is a case where it would make sense to provide enhancements to the current hints; so, I'm not averse to adding a beam attribute on ftrem.
>
> Adding @beam is easy, but it forces us to formulate a convention for what counts as a "beam" and what counts as a "slash". ?Assuming that beams are the things that connect stems and slashes are those things that are between the stems (but don't touch them) is the simplest solution. ?But, then @slash can't be used to accurately calculate the repetition frequency in a sounded rendition. ?So this must lead us to another attribute that will carry this information. ?This might be an improvement as this new attribute could be placed in the gestural domain, leaving the others in the logical/visual domain.
>
> Another approach might be to count everything (whether it connects the stems or not) as a "slash", with @beams recording the subset of the slashes that actually connect the stems. ?This will allow us to continue to calculate the repetition frequency based on the value of @slash.
>
> I can see advantages and disadvantages in both these solutions. ?I think the literalists among us (OMRers, Score devotees, perhaps?) will prefer the first one, while those who are interested more in semantics than visualization might prefer the second. ?I'm not attached to either one, but I think Thomas' arguments are convincing, so I lean toward the first option above. ?Anyway, now is the time to make a change if we need to. ?Comments here will help in the decision, so please speak up.
>
> BTW, I don't want to ignite a religious war over the terminology "beam" and "slash". ?As always, if anyone has an idea for better names, I'm listening.
>
> --
> Perry
>
> __________________________
> 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 TW [zupftom at googlemail.com]
> Sent: Friday, June 17, 2011 4:45 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] How to use <ftrem>
>
> Hi Roland,
>
> thanks for your reply. ?I have a handful of notation books on the
> shelf, among them Read. ?The image that is reproduced in the
> documentation is from page 395. ?But on many other occurences of
> fingered tremolos in his book (p. 235-236, p. 330, p. 371-372), using
> either one beam+slashes or only beams on half notes. ?Does he make a
> distinction in notation between measured and unmeasured tremolo that I
> don't quite get?
>
> By the way, all of the books I checked seem to use the terminology
> "beam" in the context of fingered tremolos. ?(Helene Wanske even talks
> about beams (Balken) if the slashes aren't fully connecting the
> stems.)
>
> Here's what my sources say:
> - Helene Wanske: Musiknotation, p. 117: half notes connected with full
> 32nd beams; I didn't see an alternative in the book [on p. 167 she
> says, quarter notes, although the "beam" doesn't entirely connect the
> stems, are regarded as "beamed"]
> - Brockhaus Riemann Musik-Lexikon: Abbreviaturen 4): half notes with
> one, two and three full beams, no alternatives
> - Herbert Chlapik: Die Praxis des Notengrafikers, p.46: there are half
> notes with one, two and three full beams on this page, no other
> notation with half notes
> - George Heussenstamm: The Norton Manual of Music Notation, p. 55:
> "Preferred Notation": half notes with one beam and two slashes,
> "Traditional Notation": half notes with three full beams, ?"Possible
> Notation": half notes without full beams and three slashes.
> Interestingly, on p. 56 he only uses "Traditional Notation" instead of
> "Preferred Notation".
> - Ted Ross: The Art of Music Engraving and Processing, p. 199: there
> is an example of fully beamed half notes first, then "or" and the same
> example notated with one beam and two slashes. ?Later on he uses the
> fully beamed notation for one example and the beams+slashes version
> for another example so his use is pretty balanced between the two
> notations.
>
> So the "no slashes, all beams" solution is given six times, the "one
> beam, rest slashes" solution is given three times (both numbers
> including Read) and Heussenstamm's "Possible Notation" is given once.
> Maybe someone can check what Faber Music's "Behind Bars" says - that's
> not yet part of my collection (and also pretty expensive).
>
> In my opinion there *should* be a convention for specifying the number
> of beams. ?There doesn't seem to be a single correct solution. ?It's
> probably best if the "repetition frequency" can directly be derived
> from @slash. ?But <beam> doesn't allow specifying the number of beams,
> that's implicit.
>
> And yes, I meant @dur on ftrem, just like with chords.
>
> Thomas Weber
>
>
> 2011/6/17 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>> Hi Thomas,
>>
>> One should never count beams separate from slashes -- count only slashes. ?Treating tremolandi this way makes them uniform in the markup regardless of the note durations involved. ?So, the way to encode your first example is
>>
>> <ftrem slash="4">
>> ?<note pname="f" dur="32" oct="4"/>
>> ?<note pname="a" dur="32" oct="4"/>
>> </ftrem>
>>
>> Your second example should be
>>
>> <ftrem slash="3">
>> ?<note pname="f" dur="2" oct="4"/>
>> ?<note pname="a" dur="2" oct="4"/>
>> </ftrem>
>>
>> In fact, all the tremolandi except the last are encoded exactly the same way (<ftrem slash="3">) except for the note durations. ?Now, exactly *how* the slashes are drawn is left to the rendering process.
>>
>> What you're calling a "beam" isn't really. ?Depending on the rhythmic values involved, one or more of the "slashes" are drawn connecting the notes (making it/them look "beam-like"), the rest are disconnected from the note stems. ?Therefore, none of the notes in the example are "properly" or "improperly" beamed -- they're not "beamed" at all.
>>
>> I don't have access to Read at the moment, but the rules for tremolandi are covered there. ?In fact, this example comes directly from Read, which is invaluable for answering notational questions. ?I highly recommend that anyone working with CMN notation have a copy nearby. ?And, no, I don't get any reward from the author or the publisher for the recommendation.
>>
>> I suppose that somewhere out in the "wild" there are 2-beat tremolos with "no beam and 3 slashes" (especially in manuscript), but that notation would just be incorrect. ?If we set ourselves the goal of representing incorrect notation, then we'll be back to describing "lines and circles"; in other words, nothing more than the marks on the page. ?If it's important, one can include a facsimile image to show the incorrect notation, using something like
>>
>> <ftrem slash="3" facs="idOfTheZoneContainingIncorrectNotation">.
>>
>> I think adding @dur on ftrem makes sense because it would allow the omission of it on the individual notes, just as on chord. ?Is that what you were thinking?
>>
>> Yes, the documentation is an on-going effort. ?Regrettably, I haven't had as much time to devote to it as it deserves. Any volunteers to mark up the notation in the Tag Library?
>>
>> --
>> 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 TW [zupftom at googlemail.com]
>> Sent: Thursday, June 16, 2011 5:34 AM
>> To: Music Encoding Initiative
>> Subject: [MEI-L] How to use <ftrem>
>>
>> I'm not sure what's the proper way of using <ftrem>. ?If I want to
>> encode the last <ftrem> from this image:
>>
>> http://www.music-encoding.org/pix/tagLibrary/meiTagLibrary2010-05_html_25c82644.png
>>
>> would I do it like this (assuming it's in treble clef):
>>
>> <beam>
>> ?<ftrem slash="1">
>> ? ?<note pname="f" dur="32" oct="4"/>
>> ? ?<note pname="a" dur="32" oct="4"/>
>> ?</ftrem>
>> </beam>
>>
>> i.e. this is a pair of properly beamed 32nd notes with an additional
>> stroke, or like this:
>>
>> <ftrem slash="4">
>>
>> ?<note pname="f" dur="32" oct="4"/>
>>
>> ?<note pname="a" dur="32" oct="4"/>
>>
>> </ftrem>
>>
>>
>> assuming that slash="4" and @dur="32" imply that we have three beams
>> and one slash?
>>
>> Analogously, how would I encode the second <ftrem>:
>>
>> <beam>
>>
>> ?<ftrem slash="2">
>>
>> ? ?<note pname="f" dur="2" oct="4"/>
>>
>> ? ?<note pname="a" dur="2" oct="4"/>
>>
>> ?</ftrem>
>>
>> </beam>
>>
>> i.e. a pair of "improperly" beamed half notes with an additional
>> slash? ?I'm not sure, could there be half note heads with two or more
>> beams? ?How do I tell how many beams? ?Or like this:
>>
>> <ftrem slash="3">
>>
>> ?<note pname="f" dur="2" oct="4"/>
>>
>> ?<note pname="a" dur="2" oct="4"/>
>>
>> </ftrem>
>>
>>
>> and ftrem/@slash="3" and note/@dur="2" imply that I have one beam and
>> two slashes? ?Could there be half notes without beam and only with
>> slashes? ?And wouldn't it make sense to have an ftrem/@dur attribute,
>> analogously to chord/@dur?
>>
>> It would be great if the images in the documentation could be
>> supplemented with code examples (did I understand correctly that this
>> is work in progress?)
>>
>> Thanks!
>> Thomas Weber
>>
>> _______________________________________________
>> 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
>


From pdr4h at eservices.virginia.edu  Fri Jun 17 17:09:07 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Fri, 17 Jun 2011 15:09:07 +0000
Subject: [MEI-L] How to use <ftrem>
In-Reply-To: <BANLkTimuCThVEdjSHbqO8F7dDdjfb1vrvw@mail.gmail.com>
References: <BANLkTi=bDDRMmi4A84wTcYT8tiG4sWGvSw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04BB5E@WILSON.eservices.virginia.edu>
	<BANLkTi=o8m=SeHQeQcqRDm01GPxGWo2MuA@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04BC48@WILSON.eservices.virginia.edu>,
	<BANLkTimuCThVEdjSHbqO8F7dDdjfb1vrvw@mail.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D04BCA7@WILSON.eservices.virginia.edu>

I'm looking for a certain level of consistency in whatever approach is taken.  We can fit the solution to the half note situation where I presume one would like to explicit set the number of beams vs. slashes -- in which case the specification is redundant for other durations -- or we can fit the solution to the majority of cases and allow the half note "problem" to be solved in rendering.  But, what's very difficult is to allow a special case markup solution only for half notes.

If we explicitly set the number of beams and slashes, then for 16th notes it would be beam="2" slash="1", which is redundant.  But this would also allow for 16th-note tremolandi to have some other, "incorrect" number of slashes, just as half notes appear to frequenty have.  The repetition frquency can be derived from the combined values of @beam and @slash, but in order to provide complete independence it could be stored in another, new attribute.  This provides the greatest flexibility, but is redundant in most cases.

Yet another possibility is to assume beaming based on the durations of the notes and count only "non-beam" slashes in @slash.  Yes, this would reverse the definition I gave before for what goes in @slash, but this is not the first time I've reversed myself.  And I'm certain it won't be the last. :)

--
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 TW [zupftom at googlemail.com]
Sent: Friday, June 17, 2011 10:17 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] How to use <ftrem>

While I'm sort of a Score devotee, I think that the repetition
frequency should definitely be derivable from @slash.  But thinking
about it a bit longer, it's really tricky.  As the visual appearance
is only uncertain for half notes, what would using @beam on notes
other than half notes mean?  That wouldn't make a lot of sense.  For
@dur=16, it would look as if one should set @beam=2, but that would be
very inconsistent with the meaning of n=@beam "n of the slashes are
written as beams".

Thomas Weber


2011/6/17 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> To me, the inconsistency Thomas reports in the various ways of counting the number of beams vs. slashes indicates different rendering possibilities for the same semantic construct.  While it provides rendering "hints", in general, MEI leaves rendering to a down-stream process.  Perhaps, however, ftrem is a case where it would make sense to provide enhancements to the current hints; so, I'm not averse to adding a beam attribute on ftrem.
>
> Adding @beam is easy, but it forces us to formulate a convention for what counts as a "beam" and what counts as a "slash".  Assuming that beams are the things that connect stems and slashes are those things that are between the stems (but don't touch them) is the simplest solution.  But, then @slash can't be used to accurately calculate the repetition frequency in a sounded rendition.  So this must lead us to another attribute that will carry this information.  This might be an improvement as this new attribute could be placed in the gestural domain, leaving the others in the logical/visual domain.
>
> Another approach might be to count everything (whether it connects the stems or not) as a "slash", with @beams recording the subset of the slashes that actually connect the stems.  This will allow us to continue to calculate the repetition frequency based on the value of @slash.
>
> I can see advantages and disadvantages in both these solutions.  I think the literalists among us (OMRers, Score devotees, perhaps?) will prefer the first one, while those who are interested more in semantics than visualization might prefer the second.  I'm not attached to either one, but I think Thomas' arguments are convincing, so I lean toward the first option above.  Anyway, now is the time to make a change if we need to.  Comments here will help in the decision, so please speak up.
>
> BTW, I don't want to ignite a religious war over the terminology "beam" and "slash".  As always, if anyone has an idea for better names, I'm listening.
>
> --
> Perry
>
> __________________________
> 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 TW [zupftom at googlemail.com]
> Sent: Friday, June 17, 2011 4:45 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] How to use <ftrem>
>
> Hi Roland,
>
> thanks for your reply.  I have a handful of notation books on the
> shelf, among them Read.  The image that is reproduced in the
> documentation is from page 395.  But on many other occurences of
> fingered tremolos in his book (p. 235-236, p. 330, p. 371-372), using
> either one beam+slashes or only beams on half notes.  Does he make a
> distinction in notation between measured and unmeasured tremolo that I
> don't quite get?
>
> By the way, all of the books I checked seem to use the terminology
> "beam" in the context of fingered tremolos.  (Helene Wanske even talks
> about beams (Balken) if the slashes aren't fully connecting the
> stems.)
>
> Here's what my sources say:
> - Helene Wanske: Musiknotation, p. 117: half notes connected with full
> 32nd beams; I didn't see an alternative in the book [on p. 167 she
> says, quarter notes, although the "beam" doesn't entirely connect the
> stems, are regarded as "beamed"]
> - Brockhaus Riemann Musik-Lexikon: Abbreviaturen 4): half notes with
> one, two and three full beams, no alternatives
> - Herbert Chlapik: Die Praxis des Notengrafikers, p.46: there are half
> notes with one, two and three full beams on this page, no other
> notation with half notes
> - George Heussenstamm: The Norton Manual of Music Notation, p. 55:
> "Preferred Notation": half notes with one beam and two slashes,
> "Traditional Notation": half notes with three full beams,  "Possible
> Notation": half notes without full beams and three slashes.
> Interestingly, on p. 56 he only uses "Traditional Notation" instead of
> "Preferred Notation".
> - Ted Ross: The Art of Music Engraving and Processing, p. 199: there
> is an example of fully beamed half notes first, then "or" and the same
> example notated with one beam and two slashes.  Later on he uses the
> fully beamed notation for one example and the beams+slashes version
> for another example so his use is pretty balanced between the two
> notations.
>
> So the "no slashes, all beams" solution is given six times, the "one
> beam, rest slashes" solution is given three times (both numbers
> including Read) and Heussenstamm's "Possible Notation" is given once.
> Maybe someone can check what Faber Music's "Behind Bars" says - that's
> not yet part of my collection (and also pretty expensive).
>
> In my opinion there *should* be a convention for specifying the number
> of beams.  There doesn't seem to be a single correct solution.  It's
> probably best if the "repetition frequency" can directly be derived
> from @slash.  But <beam> doesn't allow specifying the number of beams,
> that's implicit.
>
> And yes, I meant @dur on ftrem, just like with chords.
>
> Thomas Weber
>
>
> 2011/6/17 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>> Hi Thomas,
>>
>> One should never count beams separate from slashes -- count only slashes.  Treating tremolandi this way makes them uniform in the markup regardless of the note durations involved.  So, the way to encode your first example is
>>
>> <ftrem slash="4">
>>  <note pname="f" dur="32" oct="4"/>
>>  <note pname="a" dur="32" oct="4"/>
>> </ftrem>
>>
>> Your second example should be
>>
>> <ftrem slash="3">
>>  <note pname="f" dur="2" oct="4"/>
>>  <note pname="a" dur="2" oct="4"/>
>> </ftrem>
>>
>> In fact, all the tremolandi except the last are encoded exactly the same way (<ftrem slash="3">) except for the note durations.  Now, exactly *how* the slashes are drawn is left to the rendering process.
>>
>> What you're calling a "beam" isn't really.  Depending on the rhythmic values involved, one or more of the "slashes" are drawn connecting the notes (making it/them look "beam-like"), the rest are disconnected from the note stems.  Therefore, none of the notes in the example are "properly" or "improperly" beamed -- they're not "beamed" at all.
>>
>> I don't have access to Read at the moment, but the rules for tremolandi are covered there.  In fact, this example comes directly from Read, which is invaluable for answering notational questions.  I highly recommend that anyone working with CMN notation have a copy nearby.  And, no, I don't get any reward from the author or the publisher for the recommendation.
>>
>> I suppose that somewhere out in the "wild" there are 2-beat tremolos with "no beam and 3 slashes" (especially in manuscript), but that notation would just be incorrect.  If we set ourselves the goal of representing incorrect notation, then we'll be back to describing "lines and circles"; in other words, nothing more than the marks on the page.  If it's important, one can include a facsimile image to show the incorrect notation, using something like
>>
>> <ftrem slash="3" facs="idOfTheZoneContainingIncorrectNotation">.
>>
>> I think adding @dur on ftrem makes sense because it would allow the omission of it on the individual notes, just as on chord.  Is that what you were thinking?
>>
>> Yes, the documentation is an on-going effort.  Regrettably, I haven't had as much time to devote to it as it deserves. Any volunteers to mark up the notation in the Tag Library?
>>
>> --
>> 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 TW [zupftom at googlemail.com]
>> Sent: Thursday, June 16, 2011 5:34 AM
>> To: Music Encoding Initiative
>> Subject: [MEI-L] How to use <ftrem>
>>
>> I'm not sure what's the proper way of using <ftrem>.  If I want to
>> encode the last <ftrem> from this image:
>>
>> http://www.music-encoding.org/pix/tagLibrary/meiTagLibrary2010-05_html_25c82644.png
>>
>> would I do it like this (assuming it's in treble clef):
>>
>> <beam>
>>  <ftrem slash="1">
>>    <note pname="f" dur="32" oct="4"/>
>>    <note pname="a" dur="32" oct="4"/>
>>  </ftrem>
>> </beam>
>>
>> i.e. this is a pair of properly beamed 32nd notes with an additional
>> stroke, or like this:
>>
>> <ftrem slash="4">
>>
>>  <note pname="f" dur="32" oct="4"/>
>>
>>  <note pname="a" dur="32" oct="4"/>
>>
>> </ftrem>
>>
>>
>> assuming that slash="4" and @dur="32" imply that we have three beams
>> and one slash?
>>
>> Analogously, how would I encode the second <ftrem>:
>>
>> <beam>
>>
>>  <ftrem slash="2">
>>
>>    <note pname="f" dur="2" oct="4"/>
>>
>>    <note pname="a" dur="2" oct="4"/>
>>
>>  </ftrem>
>>
>> </beam>
>>
>> i.e. a pair of "improperly" beamed half notes with an additional
>> slash?  I'm not sure, could there be half note heads with two or more
>> beams?  How do I tell how many beams?  Or like this:
>>
>> <ftrem slash="3">
>>
>>  <note pname="f" dur="2" oct="4"/>
>>
>>  <note pname="a" dur="2" oct="4"/>
>>
>> </ftrem>
>>
>>
>> and ftrem/@slash="3" and note/@dur="2" imply that I have one beam and
>> two slashes?  Could there be half notes without beam and only with
>> slashes?  And wouldn't it make sense to have an ftrem/@dur attribute,
>> analogously to chord/@dur?
>>
>> It would be great if the images in the documentation could be
>> supplemented with code examples (did I understand correctly that this
>> is work in progress?)
>>
>> Thanks!
>> Thomas Weber
>>
>> _______________________________________________
>> 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

From zupftom at googlemail.com  Mon Jun 20 08:48:52 2011
From: zupftom at googlemail.com (TW)
Date: Mon, 20 Jun 2011 08:48:52 +0200
Subject: [MEI-L] How to use <ftrem>
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D04BCA7@WILSON.eservices.virginia.edu>
References: <BANLkTi=bDDRMmi4A84wTcYT8tiG4sWGvSw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04BB5E@WILSON.eservices.virginia.edu>
	<BANLkTi=o8m=SeHQeQcqRDm01GPxGWo2MuA@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04BC48@WILSON.eservices.virginia.edu>
	<BANLkTimuCThVEdjSHbqO8F7dDdjfb1vrvw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D04BCA7@WILSON.eservices.virginia.edu>
Message-ID: <BANLkTik9=sc39wVNMadKYmW043GU6L6yXQ@mail.gmail.com>

2011/6/17 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>
> If we explicitly set the number of beams and slashes, then for 16th notes it would be beam="2" slash="1", which is redundant. ?But this would also allow for 16th-note tremolandi to have some other, "incorrect" number of slashes, just as half notes appear to frequenty have.

Mh, what's an incorrect number of slashes?  A consistent rule for
beams and slashes would be:  Beams+slashes represent the repetition
frequency (or more precisely the "stroke frequency").  Beams alone
represent the overall duration of the tremolo.  This would mean that
notes longer than an eighth would only get slashes.  But that's not
common practice (only Heussenstamm mentions this possibility).

>?The repetition frquency can be derived from the combined values of @beam and @slash, but in order to provide complete independence it could be stored in another, new attribute. ?This provides the greatest flexibility, but is redundant in most cases.
>

Maybe we have the cart before the horse.  Instead of specifying the
number of beams alias "connecting slashes", we could specify the
number of "hovering slashes", e.g. using an attribute @hover-slash.
If this attribute is not set, then it's up to the renderer to decide
how many beams/slashes are drawn on half notes.  For other durations
it's pretty much unambiguous anyway.  If it is set, then the number of
beams is @slash - @hover-slash.

Another question is whether we need to cover things like half notes
with two beams and one slash.  I didn't see that in the books.  I only
saw either a single beam with 0 or more slashes, or more beams and no
slashes.  If the answer is no, then a boolean attribute @hover-slash
could be used as well.  If not set, it's up to the renderer.  If it is
true, then there needs to be one beam and @slash - 1 hovering slashes
for half notes.  If false, there need to be "@slash" beams.  The
question is whether the attribute should have an effect if it's set on
notes with @dur != 2.

> Yet another possibility is to assume beaming based on the durations of the notes and count only "non-beam" slashes in @slash.

Maybe that's not so important because there's not much material using
<ftrem> yet, but that would be incompatible with the current practice,
right?

Thomas Weber


From zupftom at googlemail.com  Wed Jul  6 07:39:49 2011
From: zupftom at googlemail.com (TW)
Date: Wed, 6 Jul 2011 07:39:49 +0200
Subject: [MEI-L] @dur on tuplet/tupletspan
Message-ID: <CAEB1mApQ2UPz0SRebNKS-QsyvovGuYRHm02KMJJwT=4aL7GChw@mail.gmail.com>

Do I understand this correctly?  @dur of tuplet/tupletspan encodes the
overal duration of a tuplet so that a "standard" triplet with three
eighth notes would have dur="4".  I could also imagine that contained
notes and rests would inherit @dur from the containing tuplet, like
with chords, but that wouldn't make too much sense for tupletspans
where there are no contained notes and rests in the DOM sense.

Thomas Weber


From pdr4h at eservices.virginia.edu  Wed Jul  6 14:26:20 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Wed, 6 Jul 2011 12:26:20 +0000
Subject: [MEI-L] @dur on tuplet/tupletspan
In-Reply-To: <CAEB1mApQ2UPz0SRebNKS-QsyvovGuYRHm02KMJJwT=4aL7GChw@mail.gmail.com>
References: <CAEB1mApQ2UPz0SRebNKS-QsyvovGuYRHm02KMJJwT=4aL7GChw@mail.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D09251E@WILSON.eservices.virginia.edu>

Hi Thomas,

You understand it correctly.  @dur on tuplet/tupletSpan encodes the total duration of the tuplet.  Its value is *not* inherited by the contained notes/rests/etc.

--
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 TW [zupftom at googlemail.com]
Sent: Wednesday, July 06, 2011 1:39 AM
To: Music Encoding Initiative
Subject: [MEI-L] @dur on tuplet/tupletspan

Do I understand this correctly?  @dur of tuplet/tupletspan encodes the
overal duration of a tuplet so that a "standard" triplet with three
eighth notes would have dur="4".  I could also imagine that contained
notes and rests would inherit @dur from the containing tuplet, like
with chords, but that wouldn't make too much sense for tupletspans
where there are no contained notes and rests in the DOM sense.

Thomas Weber

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

From zupftom at googlemail.com  Wed Jul  6 20:34:05 2011
From: zupftom at googlemail.com (TW)
Date: Wed, 6 Jul 2011 20:34:05 +0200
Subject: [MEI-L] @dur on tuplet/tupletspan
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D09251E@WILSON.eservices.virginia.edu>
References: <CAEB1mApQ2UPz0SRebNKS-QsyvovGuYRHm02KMJJwT=4aL7GChw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D09251E@WILSON.eservices.virginia.edu>
Message-ID: <CAEB1mAo4Vg0+m4R-6j=UgdebE53GuXmp9U0VoD=R5CUpMj4P=A@mail.gmail.com>

Good, thanks.  Is there documentation in which context @dur, @pname,
@oct (anything else?) are inherited or propagated?


2011/7/6 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> Hi Thomas,
>
> You understand it correctly. ?@dur on tuplet/tupletSpan encodes the total duration of the tuplet. ?Its value is *not* inherited by the contained notes/rests/etc.
>
> --
> 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 TW [zupftom at googlemail.com]
> Sent: Wednesday, July 06, 2011 1:39 AM
> To: Music Encoding Initiative
> Subject: [MEI-L] @dur on tuplet/tupletspan
>
> Do I understand this correctly? ?@dur of tuplet/tupletspan encodes the
> overal duration of a tuplet so that a "standard" triplet with three
> eighth notes would have dur="4". ?I could also imagine that contained
> notes and rests would inherit @dur from the containing tuplet, like
> with chords, but that wouldn't make too much sense for tupletspans
> where there are no contained notes and rests in the DOM sense.
>
> Thomas Weber
>
> _______________________________________________
> 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
>


From pdr4h at eservices.virginia.edu  Wed Jul  6 21:21:42 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Wed, 6 Jul 2011 19:21:42 +0000
Subject: [MEI-L] @dur on tuplet/tupletspan
In-Reply-To: <CAEB1mAo4Vg0+m4R-6j=UgdebE53GuXmp9U0VoD=R5CUpMj4P=A@mail.gmail.com>
References: <CAEB1mApQ2UPz0SRebNKS-QsyvovGuYRHm02KMJJwT=4aL7GChw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D09251E@WILSON.eservices.virginia.edu>,
	<CAEB1mAo4Vg0+m4R-6j=UgdebE53GuXmp9U0VoD=R5CUpMj4P=A@mail.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D09267C@WILSON.eservices.virginia.edu>

Unfortunately, no.  That disappeared with the deprecation of the DTD expression of MEI.  But, the documentation was very meager anyway.

The last DTD for MEI contained the declaration -- 

<!ENTITY % PROPAGATED '#IMPLIED'><!-- if not supplied, the value should
  be obtained from a previous event in the *same measure* -->

but I don't think this still applies.  It certainly *does not* in mensural notation.  I believe the definition needs to be corrected to say that values should be obtained from a previous event in the same layer on the same staff.

Propagation was only applicable to the @pname (note), @oct (note), and @dur (chord, note, rest, and space).

The concept of propagation was intended to be used for assisting the manual input process; that is, one could type

<note pname="c" oct="4" dur="4"/>
<note/>
<note/>
<note/>

for four quarter notes of the same pitch and save some keystrokes.  This form should never be *exported* from MEI writing software.  The following output is better; that is, more explict --

<note pname="c" oct="4" dur="4"/>
<note pname="c" oct="4" dur="4"/>
<note pname="c" oct="4" dur="4"/>
<note pname="c" oct="4" dur="4"/>

Obviously, however, the short-hand form is important when *importing* MEI into something like, oh, say, MuseScore. :)

It becomes a question of when to regularize the input -- in a separate step prior to importing the file or as part of the import process.  But that would have to be determined by the importing program.  

The tech group has already discussed the creation of an MEI "canonizer" (sometimes referred to as "MEI-Iron") and I'm sure it will come up again at the next meeting.  Since this would be an MEI -> MEI transform, I believe an XSLT stylesheet would provide a good solution.

(Just in case you're wondering about the name, the canonizer would also have to "flatten out" the critical apparatus markup for applications that can't handle that kind of thing, hence the name "MEI-Iron".)

Does this help?

--
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 TW [zupftom at googlemail.com]
Sent: Wednesday, July 06, 2011 2:34 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] @dur on tuplet/tupletspan

Good, thanks.  Is there documentation in which context @dur, @pname,
@oct (anything else?) are inherited or propagated?


2011/7/6 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> Hi Thomas,
>
> You understand it correctly.  @dur on tuplet/tupletSpan encodes the total duration of the tuplet.  Its value is *not* inherited by the contained notes/rests/etc.
>
> --
> 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 TW [zupftom at googlemail.com]
> Sent: Wednesday, July 06, 2011 1:39 AM
> To: Music Encoding Initiative
> Subject: [MEI-L] @dur on tuplet/tupletspan
>
> Do I understand this correctly?  @dur of tuplet/tupletspan encodes the
> overal duration of a tuplet so that a "standard" triplet with three
> eighth notes would have dur="4".  I could also imagine that contained
> notes and rests would inherit @dur from the containing tuplet, like
> with chords, but that wouldn't make too much sense for tupletspans
> where there are no contained notes and rests in the DOM sense.
>
> Thomas Weber
>
> _______________________________________________
> 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

From pdr4h at eservices.virginia.edu  Wed Jul  6 21:45:05 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Wed, 6 Jul 2011 19:45:05 +0000
Subject: [MEI-L] default durations, WAS:  @dur on tuplet/tupletspan
Message-ID: <BBCC497C40D85642B90E9F94FC30343D0926A8@WILSON.eservices.virginia.edu>

I forgot to say in my earlier response that the phrase "in the same measure" was there because MEI provides a @dur.default attribute on <scoreDef>, <staffDef>, and <layerDef> elements to handle the case where the first note of the measure isn't specified.  So, the duration of the first note below

<measure>
  <staff n="1">
    <layer n="1">
      <note pname="c" oct="4"/>
      <note/>
      <note/>
      <note/>
    </layer>
  </staff>
</measure>

would default to the value specified in @dur.default given in the layer definition, or if @dur.default wasn't specified there, in @dur.default given in the staff definition, or if not there, in @dur.default stated in the score definition.

It was never stated (and I don't believe it can be absolutely determined) what the result should be if there was no @dur.default attribute at any of these locations.  Some applications might want to raise a fatal error, while others might want to attempt some automagical "recovery" process, such as defaulting to a quarter note duration.  The choice of which way to deal with this depends on the software; that is, whether its internal format requires the specification of duration, whether it forces measures to "add up" to the prevailing meter signature, etc.

--
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+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu]
Sent: Wednesday, July 06, 2011 3:21 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] @dur on tuplet/tupletspan

Unfortunately, no.  That disappeared with the deprecation of the DTD expression of MEI.  But, the documentation was very meager anyway.

The last DTD for MEI contained the declaration --

<!ENTITY % PROPAGATED '#IMPLIED'><!-- if not supplied, the value should
  be obtained from a previous event in the *same measure* -->

but I don't think this still applies.  It certainly *does not* in mensural notation.  I believe the definition needs to be corrected to say that values should be obtained from a previous event in the same layer on the same staff.

Propagation was only applicable to the @pname (note), @oct (note), and @dur (chord, note, rest, and space).

The concept of propagation was intended to be used for assisting the manual input process; that is, one could type

<note pname="c" oct="4" dur="4"/>
<note/>
<note/>
<note/>

for four quarter notes of the same pitch and save some keystrokes.  This form should never be *exported* from MEI writing software.  The following output is better; that is, more explict --

<note pname="c" oct="4" dur="4"/>
<note pname="c" oct="4" dur="4"/>
<note pname="c" oct="4" dur="4"/>
<note pname="c" oct="4" dur="4"/>

Obviously, however, the short-hand form is important when *importing* MEI into something like, oh, say, MuseScore. :)

It becomes a question of when to regularize the input -- in a separate step prior to importing the file or as part of the import process.  But that would have to be determined by the importing program.

The tech group has already discussed the creation of an MEI "canonizer" (sometimes referred to as "MEI-Iron") and I'm sure it will come up again at the next meeting.  Since this would be an MEI -> MEI transform, I believe an XSLT stylesheet would provide a good solution.

(Just in case you're wondering about the name, the canonizer would also have to "flatten out" the critical apparatus markup for applications that can't handle that kind of thing, hence the name "MEI-Iron".)

Does this help?

--
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 TW [zupftom at googlemail.com]
Sent: Wednesday, July 06, 2011 2:34 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] @dur on tuplet/tupletspan

Good, thanks.  Is there documentation in which context @dur, @pname,
@oct (anything else?) are inherited or propagated?


2011/7/6 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> Hi Thomas,
>
> You understand it correctly.  @dur on tuplet/tupletSpan encodes the total duration of the tuplet.  Its value is *not* inherited by the contained notes/rests/etc.
>
> --
> 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 TW [zupftom at googlemail.com]
> Sent: Wednesday, July 06, 2011 1:39 AM
> To: Music Encoding Initiative
> Subject: [MEI-L] @dur on tuplet/tupletspan
>
> Do I understand this correctly?  @dur of tuplet/tupletspan encodes the
> overal duration of a tuplet so that a "standard" triplet with three
> eighth notes would have dur="4".  I could also imagine that contained
> notes and rests would inherit @dur from the containing tuplet, like
> with chords, but that wouldn't make too much sense for tupletspans
> where there are no contained notes and rests in the DOM sense.
>
> Thomas Weber
>
> _______________________________________________
> 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

From zupftom at googlemail.com  Sun Jul 10 19:12:24 2011
From: zupftom at googlemail.com (TW)
Date: Sun, 10 Jul 2011 19:12:24 +0200
Subject: [MEI-L] tstamp.ges and tstamp.real documentation
Message-ID: <CAEB1mAoFR7trDc_E-mtXNtUi5mQHFUpq_Ow1d8=Rbu_KpmHbgg@mail.gmail.com>

There must be something wrong in the description of @tstamp.real.
It's the exact same description as for the @tstamp.ges, saying that
it's in pulses per quarter, but it's of type ISOTIME.

Thomas Weber


From zupftom at googlemail.com  Sun Jul 10 21:34:33 2011
From: zupftom at googlemail.com (TW)
Date: Sun, 10 Jul 2011 21:34:33 +0200
Subject: [MEI-L] @clef* inside scoredef
Message-ID: <CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>

I'm wondering why the @clef* family of attributes is allowed on
<scoredef>, but the <clef> element isn't.

Is it O.K. to just drop a message to the list when I believe there are
some inconsistencies in the specs?  I see that the tracker on
Sourceforge hasn't been used yet, but I feel that would be a better
place for posting such things.  Shall I take its virginity?

Thomas Weber


From andrew.hankinson at mail.mcgill.ca  Mon Jul 11 08:02:31 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Mon, 11 Jul 2011 06:02:31 +0000
Subject: [MEI-L] @clef* inside scoredef
In-Reply-To: <26523_1310326484_4E19FED3_26523_432_1_CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
References: <26523_1310326484_4E19FED3_26523_432_1_CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
Message-ID: <1F8B36CF-77A2-4219-9729-CB30DE32A6DE@mail.mcgill.ca>

I think you'll get a better response from the list. Someone might see your message on the bug tracker a couple months from now, but I don't think anyone really looks at it on a daily basis.

-Andrew

On 2011-07-10, at 3:34 PM, TW wrote:

> I'm wondering why the @clef* family of attributes is allowed on
> <scoredef>, but the <clef> element isn't.
> 
> Is it O.K. to just drop a message to the list when I believe there are
> some inconsistencies in the specs?  I see that the tracker on
> Sourceforge hasn't been used yet, but I feel that would be a better
> place for posting such things.  Shall I take its virginity?
> 
> Thomas Weber
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From stadler at edirom.de  Mon Jul 11 11:16:45 2011
From: stadler at edirom.de (Peter Stadler)
Date: Mon, 11 Jul 2011 11:16:45 +0200
Subject: [MEI-L] @clef* inside scoredef
In-Reply-To: <1F8B36CF-77A2-4219-9729-CB30DE32A6DE@mail.mcgill.ca>
References: <26523_1310326484_4E19FED3_26523_432_1_CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
	<1F8B36CF-77A2-4219-9729-CB30DE32A6DE@mail.mcgill.ca>
Message-ID: <1E033B39-849D-4F02-A486-1855297B131F@edirom.de>

There *must* be a way to automatically send an email when a new ticket is created and the recipient could be MEI-L.
I'd definitely opt for this approach rather than reporting bugs on the list (alone). Bug tracking is a great help for not forgetting bugs ;-) 
Secondly, in terms of public image it's always good to create some activity on sourceforge...

All the best
Peter

Am 11.07.2011 um 08:02 schrieb Andrew Hankinson, Mr:

> I think you'll get a better response from the list. Someone might see your message on the bug tracker a couple months from now, but I don't think anyone really looks at it on a daily basis.
> 
> -Andrew
> 
> On 2011-07-10, at 3:34 PM, TW wrote:
> 
>> I'm wondering why the @clef* family of attributes is allowed on
>> <scoredef>, but the <clef> element isn't.
>> 
>> Is it O.K. to just drop a message to the list when I believe there are
>> some inconsistencies in the specs?  I see that the tracker on
>> Sourceforge hasn't been used yet, but I feel that would be a better
>> place for posting such things.  Shall I take its virginity?
>> 
>> Thomas Weber
>> 
>> _______________________________________________
>> 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



From zupftom at googlemail.com  Mon Jul 11 11:22:34 2011
From: zupftom at googlemail.com (TW)
Date: Mon, 11 Jul 2011 11:22:34 +0200
Subject: [MEI-L] @clef* inside scoredef
In-Reply-To: <1E033B39-849D-4F02-A486-1855297B131F@edirom.de>
References: <26523_1310326484_4E19FED3_26523_432_1_CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
	<1F8B36CF-77A2-4219-9729-CB30DE32A6DE@mail.mcgill.ca>
	<1E033B39-849D-4F02-A486-1855297B131F@edirom.de>
Message-ID: <CAEB1mArZDO3Q5w35QiPaOuYpy=ii0Mq29Feic_mVKfVb8MOTZA@mail.gmail.com>

Sending notifications to the list sounds like a good idea to me.  How
are raised issues managed currently?


2011/7/11 Peter Stadler <stadler at edirom.de>:
> There *must* be a way to automatically send an email when a new ticket is created and the recipient could be MEI-L.
> I'd definitely opt for this approach rather than reporting bugs on the list (alone). Bug tracking is a great help for not forgetting bugs ;-)
> Secondly, in terms of public image it's always good to create some activity on sourceforge...
>
> All the best
> Peter
>
> Am 11.07.2011 um 08:02 schrieb Andrew Hankinson, Mr:
>
>> I think you'll get a better response from the list. Someone might see your message on the bug tracker a couple months from now, but I don't think anyone really looks at it on a daily basis.
>>
>> -Andrew
>>
>> On 2011-07-10, at 3:34 PM, TW wrote:
>>
>>> I'm wondering why the @clef* family of attributes is allowed on
>>> <scoredef>, but the <clef> element isn't.
>>>
>>> Is it O.K. to just drop a message to the list when I believe there are
>>> some inconsistencies in the specs? ?I see that the tracker on
>>> Sourceforge hasn't been used yet, but I feel that would be a better
>>> place for posting such things. ?Shall I take its virginity?
>>>
>>> Thomas Weber
>>>
>>> _______________________________________________
>>> 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
>


From raffaeleviglianti at gmail.com  Mon Jul 11 11:33:17 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Mon, 11 Jul 2011 10:33:17 +0100
Subject: [MEI-L] @clef* inside scoredef
In-Reply-To: <1E033B39-849D-4F02-A486-1855297B131F@edirom.de>
References: <26523_1310326484_4E19FED3_26523_432_1_CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
	<1F8B36CF-77A2-4219-9729-CB30DE32A6DE@mail.mcgill.ca>
	<1E033B39-849D-4F02-A486-1855297B131F@edirom.de>
Message-ID: <CAMyHAnPg3TkOrJ96QnzzgSHkqONn=C2yzW2bt=9EGyroBQQoWg@mail.gmail.com>

On Mon, Jul 11, 2011 at 10:16 AM, Peter Stadler <stadler at edirom.de> wrote:

> There *must* be a way to automatically send an email when a new ticket is
> created and the recipient could be MEI-L.
> I'd definitely opt for this approach rather than reporting bugs on the list
> (alone). Bug tracking is a great help for not forgetting bugs ;-)
>


My thoughts exactly. An email notification would definitely attract my
attention, for what it's worth.

Raffaele


> Secondly, in terms of public image it's always good to create some activity
> on sourceforge...
>
> All the best
> Peter
>
> Am 11.07.2011 um 08:02 schrieb Andrew Hankinson, Mr:
>
> > I think you'll get a better response from the list. Someone might see
> your message on the bug tracker a couple months from now, but I don't think
> anyone really looks at it on a daily basis.
> >
> > -Andrew
> >
> > On 2011-07-10, at 3:34 PM, TW wrote:
> >
> >> I'm wondering why the @clef* family of attributes is allowed on
> >> <scoredef>, but the <clef> element isn't.
> >>
> >> Is it O.K. to just drop a message to the list when I believe there are
> >> some inconsistencies in the specs?  I see that the tracker on
> >> Sourceforge hasn't been used yet, but I feel that would be a better
> >> place for posting such things.  Shall I take its virginity?
> >>
> >> Thomas Weber
> >>
> >> _______________________________________________
> >> 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/20110711/8e15dc69/attachment.htm>

From kepper at edirom.de  Mon Jul 11 14:08:21 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 11 Jul 2011 14:08:21 +0200
Subject: [MEI-L] @clef* inside scoredef
In-Reply-To: <CAMyHAnPg3TkOrJ96QnzzgSHkqONn=C2yzW2bt=9EGyroBQQoWg@mail.gmail.com>
References: <26523_1310326484_4E19FED3_26523_432_1_CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
	<1F8B36CF-77A2-4219-9729-CB30DE32A6DE@mail.mcgill.ca>
	<1E033B39-849D-4F02-A486-1855297B131F@edirom.de>
	<CAMyHAnPg3TkOrJ96QnzzgSHkqONn=C2yzW2bt=9EGyroBQQoWg@mail.gmail.com>
Message-ID: <620623FD-86F7-4132-B8A0-AE5FD398F78A@edirom.de>

Hi all,

I would argue against using the sf.net tracker as open bugtracker. I think the TEI model seems better: Discuss things on TEI-L first. If there is consent that it is a bug, someone commits it to sf.net. So basically, discussion goes first. And the list definitely has a wider range than sf.net. I wouldn't recommend to automatically send a mail to MEI-L when there is activity on sf.net: Not everyone might want to get this level of detail? But generally speaking, I think this is someone that could be discussed during the virtual conference next week?

Best,
Johannes


Am 11.07.2011 um 11:33 schrieb Raffaele Viglianti:

> 
> 
> On Mon, Jul 11, 2011 at 10:16 AM, Peter Stadler <stadler at edirom.de> wrote:
> There *must* be a way to automatically send an email when a new ticket is created and the recipient could be MEI-L.
> I'd definitely opt for this approach rather than reporting bugs on the list (alone). Bug tracking is a great help for not forgetting bugs ;-)
> 
> 
> My thoughts exactly. An email notification would definitely attract my attention, for what it's worth.
> 
> Raffaele
>  
> Secondly, in terms of public image it's always good to create some activity on sourceforge...
> 
> All the best
> Peter
> 
> Am 11.07.2011 um 08:02 schrieb Andrew Hankinson, Mr:
> 
> > I think you'll get a better response from the list. Someone might see your message on the bug tracker a couple months from now, but I don't think anyone really looks at it on a daily basis.
> >
> > -Andrew
> >
> > On 2011-07-10, at 3:34 PM, TW wrote:
> >
> >> I'm wondering why the @clef* family of attributes is allowed on
> >> <scoredef>, but the <clef> element isn't.
> >>
> >> Is it O.K. to just drop a message to the list when I believe there are
> >> some inconsistencies in the specs?  I see that the tracker on
> >> Sourceforge hasn't been used yet, but I feel that would be a better
> >> place for posting such things.  Shall I take its virginity?
> >>
> >> Thomas Weber
> >>
> >> _______________________________________________
> >> 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



From stadler at edirom.de  Mon Jul 11 17:36:32 2011
From: stadler at edirom.de (Peter Stadler)
Date: Mon, 11 Jul 2011 17:36:32 +0200
Subject: [MEI-L] More feature requests
Message-ID: <01271142-14F9-4E04-A88D-D7937F058DB5@edirom.de>

Dear all,

I'd like to propose two more "features":

1. make the mailing list MEI-L archives available through the more user-friendly interfaces www.nabble.com and/or markmail.org. Ron Van den Branden just recently did so for TEI-L and I think it's a great help. Cf. http://tei-l.970651.n3.nabble.com/mirroring-the-TEI-L-archive-td2346149.html

2. I'd like access to the MEI ODD files to be able to create my own customization. At present these are not stored at sourceforge - can they be made available there?

Many thanks
Peter

From stadler at edirom.de  Mon Jul 11 17:59:10 2011
From: stadler at edirom.de (Peter Stadler)
Date: Mon, 11 Jul 2011 17:59:10 +0200
Subject: [MEI-L] More feature requests
In-Reply-To: <01271142-14F9-4E04-A88D-D7937F058DB5@edirom.de>
References: <01271142-14F9-4E04-A88D-D7937F058DB5@edirom.de>
Message-ID: <D93342E0-7420-4E59-BF68-5BC1B2452DC3@edirom.de>

Sorry, forgot to mention that I'd voluntarily take care of it if requested ;-) 

> 1. make the mailing list MEI-L archives available through the more user-friendly interfaces www.nabble.com and/or markmail.org. Ron Van den Branden just recently did so for TEI-L and I think it's a great help. Cf. http://tei-l.970651.n3.nabble.com/mirroring-the-TEI-L-archive-td2346149.html
-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110711/9f16177e/attachment.htm>

From kepper at edirom.de  Mon Jul 11 18:12:28 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 11 Jul 2011 18:12:28 +0200
Subject: [MEI-L] More feature requests
In-Reply-To: <D93342E0-7420-4E59-BF68-5BC1B2452DC3@edirom.de>
References: <01271142-14F9-4E04-A88D-D7937F058DB5@edirom.de>
	<D93342E0-7420-4E59-BF68-5BC1B2452DC3@edirom.de>
Message-ID: <85A95D34-BC3E-41D7-92C3-6CCC1B903A68@edirom.de>

I'd say go for it?



Am 11.07.2011 um 17:59 schrieb Peter Stadler:

> Sorry, forgot to mention that I'd voluntarily take care of it if requested ;-) 
> 
>> 1. make the mailing list MEI-L archives available through the more user-friendly interfaces www.nabble.com and/or markmail.org. Ron Van den Branden just recently did so for TEI-L and I think it's a great help. Cf. http://tei-l.970651.n3.nabble.com/mirroring-the-TEI-L-archive-td2346149.html
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From andrew.hankinson at mail.mcgill.ca  Mon Jul 11 21:21:32 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Mon, 11 Jul 2011 19:21:32 +0000
Subject: [MEI-L] Issue tracker (was: @clef* inside scoredef)
In-Reply-To: <10500_1310386117_4E1AE7C5_10500_387_1_620623FD-86F7-4132-B8A0-AE5FD398F78A@edirom.de>
References: <26523_1310326484_4E19FED3_26523_432_1_CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
	<1F8B36CF-77A2-4219-9729-CB30DE32A6DE@mail.mcgill.ca>
	<1E033B39-849D-4F02-A486-1855297B131F@edirom.de>
	<CAMyHAnPg3TkOrJ96QnzzgSHkqONn=C2yzW2bt=9EGyroBQQoWg@mail.gmail.com>
	<10500_1310386117_4E1AE7C5_10500_387_1_620623FD-86F7-4132-B8A0-AE5FD398F78A@edirom.de>
Message-ID: <EC1AB72F-C5E2-4896-B8EE-9BFD5505E5BA@mail.mcgill.ca>

Yes, I think we should definitely try and sort this out, since the community is starting to grow. It's one of those "good problems to have."

I do agree that we should try and move away from Sourceforge. Their development tools are really sub-par when compared to newer code hosting sites like Google Code or GitHub. 

Usually communities set up three mailing lists to help direct discussion, e.g.,

-- MEI-L: General discussion and high-level community direction;
-- MEI-devel: Lower-level Developer discussion;
-- MEI-commits: A broadcast list that sends out the updates to the development repository as they are made.

I would, however, support the use of an issue tracker. It's extremely useful for "atomic" discussions about a single issue -- e-mail messages roll a couple things together, and so searching for decisions made or feature requests can be a bit tricky. Plus you can do useful things like track commits and issues, where you can automatically reference an issue in a commit message, e.g., "fixes bug reported in #32" or "adds support for feature x requested in issue #56".

-Andrew

On 2011-07-11, at 8:08 AM, Johannes Kepper wrote:

> Hi all,
> 
> I would argue against using the sf.net tracker as open bugtracker. I think the TEI model seems better: Discuss things on TEI-L first. If there is consent that it is a bug, someone commits it to sf.net. So basically, discussion goes first. And the list definitely has a wider range than sf.net. I wouldn't recommend to automatically send a mail to MEI-L when there is activity on sf.net: Not everyone might want to get this level of detail? But generally speaking, I think this is someone that could be discussed during the virtual conference next week?
> 
> Best,
> Johannes
> 
> 
> Am 11.07.2011 um 11:33 schrieb Raffaele Viglianti:
> 
>> 
>> 
>> On Mon, Jul 11, 2011 at 10:16 AM, Peter Stadler <stadler at edirom.de> wrote:
>> There *must* be a way to automatically send an email when a new ticket is created and the recipient could be MEI-L.
>> I'd definitely opt for this approach rather than reporting bugs on the list (alone). Bug tracking is a great help for not forgetting bugs ;-)
>> 
>> 
>> My thoughts exactly. An email notification would definitely attract my attention, for what it's worth.
>> 
>> Raffaele
>> 
>> Secondly, in terms of public image it's always good to create some activity on sourceforge...
>> 
>> All the best
>> Peter
>> 
>> Am 11.07.2011 um 08:02 schrieb Andrew Hankinson, Mr:
>> 
>>> I think you'll get a better response from the list. Someone might see your message on the bug tracker a couple months from now, but I don't think anyone really looks at it on a daily basis.
>>> 
>>> -Andrew
>>> 
>>> On 2011-07-10, at 3:34 PM, TW wrote:
>>> 
>>>> I'm wondering why the @clef* family of attributes is allowed on
>>>> <scoredef>, but the <clef> element isn't.
>>>> 
>>>> Is it O.K. to just drop a message to the list when I believe there are
>>>> some inconsistencies in the specs?  I see that the tracker on
>>>> Sourceforge hasn't been used yet, but I feel that would be a better
>>>> place for posting such things.  Shall I take its virginity?
>>>> 
>>>> Thomas Weber
>>>> 
>>>> _______________________________________________
>>>> 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



From zupftom at googlemail.com  Wed Jul 13 15:29:55 2011
From: zupftom at googlemail.com (TW)
Date: Wed, 13 Jul 2011 15:29:55 +0200
Subject: [MEI-L] tupletspan, @tuplet, @beam
Message-ID: <CAEB1mApcET3gh3F2QqCKuNTe9YRys64wfqE3W7-6F8p+i=t=xQ@mail.gmail.com>

Hi all,

it's me getting on your nerves again.  Working on a MEI-consuming
application, I encountered some difficulty especially with tupletspans
that I'd like to report.  Reading the specs I understand that the
starting point can be defined using @startid, @tstamp, @tstamp.ges and
@tstamp.real.  @startid is pretty clear, @tstamp is also fairly clear,
but requires more processing effort to find the first element.  For
@tstamp.ges it's probably similar to @tstamp.  To find the last
element, there needs to be an @endid, @dur or @dur.ges.  Again, @endid
is pretty clear, but @dur and @dur.ges are only reliable if both @num
and @numbase are set on the tupletspan, and the layer elements that
the tupletspan belongs to must be somehow identifiable.  I guess this
can be done by giving the layers the same @n attribute, pointing to
the next layer or note/rest/chord using @next on the previous layer or
it's last note/rest/chord.  Or if there is only one layer.  If @num
and @numbase weren't set, there is no way of telling at what
note/rest/chord the tupletspan is "full", because the durations are
given as if they weren't part of a tuplet and there is no
"time-modification" element or attribute on notes like in MusicXML.
@num and @numbase take the role of MusicXML's time-modification
element, but they are optional and can't be relied on.  I couldn't
find @tuplet attributes being mentioned in the tuplet and tupletspan
documentation, so I'm not sure what role they are meant to play.  They
can of course help to identify what elements belong to a tupletspan,
but if that's their purpose, I'm wondering why they aren't of type
IDREF, or IDREFS for the sake of nested tuplets.

On the other hand, if @endid is given, but no @num *and* @numbase,
then the actual duration of the notes/chords/rests can't be determined
with certainty.  If @endid and @dur are set however, this is possible.

Is it possible that stricter rules could be established to make sure
that a MEI consuming application will be able to make sense of what an
encoding application or a human have produced?  In the case of
tupletspans, even if all prerequisites are met, I find them
unnecessarily hard to process as there is a large number of sensible
combinations - and I'm not even sure whether I identified all of them.
 There is also a big chance of unintentionally encoding things
sloppily so that the data is fuzzy while it really needn't be.

Still being a "rookie" who doesn't have a sound overview concerning
MEI and all its fields of application, I might be approaching this a
bit too naive.  But what speaks against enforcing IDREF(S) @tuplet on
elements that are part of a tupletspan and make all the other
start/end attributes optional?  It would be easy as pie to identify
all elements that belong to the tupletspan.  The compression (in
seldom cases maybe expansion) ration would then be clear from either
@num and @basenum or @dur and the sum of "visual" durations of
elements associated with the tupletspans.  If the music is unclear,
then the encoding will of course be unclear, but if it's clear, I'd
expect the encoding to be clear as well.

Thomas Weber


From raffaeleviglianti at gmail.com  Wed Jul 20 17:27:01 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Wed, 20 Jul 2011 17:27:01 +0200
Subject: [MEI-L] Working towards MEIron tool set
Message-ID: <CAMyHAnNPv_e9VKCE_BG-OuUVkE+Yknz3Y6kuu0_ky4NODVn=2g@mail.gmail.com>

Dear list,

The technical team has been discussing the possibility of creating an XSLT
set of tools to address multiple encoding mechanisms in MEI.

The two main uses of these tools would be:

1. Flatten ambiguity/multiple-choice (hence the "iron"). For example:
- select readings from one source
- choose between components of choice (e.g. sic vs corr, abbr vs expan)
- choose between alternatives in ossia
- etc.

2. Convert between multiple encoding mechanisms. For example:
- ELEMENTspan to/from ELEMENT (e.g. beamSpan to/from beam)
- attribute forms to/from element forms (e.g. @tie to tie; @slur to slur;
etc.)
- @startid @endid to/from time stamp values
- etc.

Eventually, these tools could be wrapped up in a (web)application that,
given appropriate parameters, generates the emended MEI.  changeDesc and
appInfo can be used to record changes and settings.

Such a tool set would be of huge help for moving between different
implementations of MEI. We have already started creating some of these
tools, but we would like to hear suggestions on what encoding models you
think can be "ironed" and/or which models can be converted into each other.
Please contribute your insights!

We will start a fuller list of desirable transformations soon and make it
public.

Best,
Raffaele on behalf of the technical team gathered at Detmold.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110720/e320660c/attachment.htm>

From atge at kb.dk  Wed Jul 20 17:58:33 2011
From: atge at kb.dk (Axel Teich Geertinger)
Date: Wed, 20 Jul 2011 15:58:33 +0000
Subject: [MEI-L] instrumentation in header
In-Reply-To: <CAMyHAnNPv_e9VKCE_BG-OuUVkE+Yknz3Y6kuu0_ky4NODVn=2g@mail.gmail.com>
References: <CAMyHAnNPv_e9VKCE_BG-OuUVkE+Yknz3Y6kuu0_ky4NODVn=2g@mail.gmail.com>
Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D117B9153C@EXCHANGE-02.kb.dk>

Dear all,

first of all thank you for the excellent virtual meeting! I really enjoyed hearing you all and even seeing some of you :-)

I have a question to the tech team: Now that we will soon have elements like <incip>, <key> and <castList> in the header, why not also add something like <instrumentList>? What these metadata have in common is that they are actually also contained in the score, although in a more or less ?hidden? way, perhaps (as with key) requiring some analysis or interpretation.
Very much like the cast list, a list of instruments could in principle be harvested from a complete encoded score. In our cataloguing projects, however, the scores are not necessarily available, so we need to add that information either as a note somewhere in the header or in a staffDef, which does nothing but defining the instruments involved (a solution I would be happy to get rid of). The incipit will not do, as in many cases not all instruments will appear in it.
The same problem is true with choirs and vocal soloists, when they do not represent a named character and therefore will not fit into the castList.

Another question: why <incip>, and not <incipit>? We have quite long element names like <classification>, so why abbreviate incipit?

All the best,
Axel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110720/3a16c41d/attachment.htm>

From veit at weber-gesamtausgabe.de  Wed Jul 20 18:47:49 2011
From: veit at weber-gesamtausgabe.de (Joachim Veit)
Date: Wed, 20 Jul 2011 18:47:49 +0200
Subject: [MEI-L] instrumentation in header
In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D117B9153C@EXCHANGE-02.kb.dk>
References: <CAMyHAnNPv_e9VKCE_BG-OuUVkE+Yknz3Y6kuu0_ky4NODVn=2g@mail.gmail.com>
	<0B6F63F59F405E4C902DFE2C2329D0D117B9153C@EXCHANGE-02.kb.dk>
Message-ID: <4E2706B5.9000108@weber-gesamtausgabe.de>

Dear Axel and all,
I heavily agree with Axel concerning the wish for an <instrumentList> in 
the header which would make it much easier for us in doing a sort of 
"simple cataloguing" of works: When we try to list the instruments of an 
opera, for instance, we do that in the moment (following Axel's model) 
in the scoreDef with staffGroup(s) - but in an opera there are changing 
instrumentations in each number, so we misuse this scoreDef as a 
"collective" form of listing all the instruments ever playing somewhere 
in the work. This is clearly the task of such an "instrumentList" which 
besides would make it easier to use a more abridged way of 
catalogue-encoding in the header.
Concerning incip I too would prefer to add the "it" at the end because 
"it" would not make any weighing machine complain?
And many thanks to you, Axel, for taking part in our discussions in the 
Virtual Meeting!!!
Best greetings,
Joachim
P.S. In a few minutes we shall make "it" - that's to say: start to drink 
a bee(r)!


Am 20.07.11 17:58, schrieb Axel Teich Geertinger:
>
> Dear all,
>
> first of all thank you for the excellent virtual meeting! I really 
> enjoyed hearing you all and even seeing some of you :-)
>
> I have a question to the tech team: Now that we will soon have 
> elements like <incip>, <key> and <castList> in the header, why not 
> also add something like <instrumentList>? What these metadata have in 
> common is that they are actually also contained in the score, although 
> in a more or less "hidden" way, perhaps (as with key) requiring some 
> analysis or interpretation.
>
> Very much like the cast list, a list of instruments could in principle 
> be harvested from a complete encoded score. In our cataloguing 
> projects, however, the scores are not necessarily available, so we 
> need to add that information either as a note somewhere in the header 
> or in a staffDef, which does nothing but defining the instruments 
> involved (a solution I would be happy to get rid of). The incipit will 
> not do, as in many cases not all instruments will appear in it.
>
> The same problem is true with choirs and vocal soloists, when they do 
> not represent a named character and therefore will not fit into the 
> castList.
>
> Another question: why <incip>, and not <incipit>? We have quite long 
> element names like <classification>, so why abbreviate incipit?
>
> All the best,
>
> Axel
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110720/b4cee750/attachment.htm>
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : veit.vcf
Dateityp    : text/x-vcard
Dateigr??e  : 364 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110720/b4cee750/attachment.vcf>

From pdr4h at eservices.virginia.edu  Thu Jul 21 10:10:34 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Thu, 21 Jul 2011 08:10:34 +0000
Subject: [MEI-L] instrumentation in header
In-Reply-To: <4E2706B5.9000108@weber-gesamtausgabe.de>
References: <CAMyHAnNPv_e9VKCE_BG-OuUVkE+Yknz3Y6kuu0_ky4NODVn=2g@mail.gmail.com>
	<0B6F63F59F405E4C902DFE2C2329D0D117B9153C@EXCHANGE-02.kb.dk>,
	<4E2706B5.9000108@weber-gesamtausgabe.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D09EA35@WILSON.eservices.virginia.edu>

Hi Axel, Joachim, and all,

Thanks for the suggestion.  I agree that this kind of thing belongs in the header, not in the score definition.  So, anticipating the need, it's already there!

The <perfMedium> element can be used to describe the performing forces of a source, work, or relatedItem.  It is modelled after a MARC tag although I can't remember the exact one at the moment.  It contains <ensemble> and <performer> elements for describing soloists (performer) and ensembles (orchestra, string quartet, etc.)

--
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 Joachim Veit [veit at weber-gesamtausgabe.de]
Sent: Wednesday, July 20, 2011 12:47 PM
To: mei-l at lists.uni-paderborn.de
Subject: Re: [MEI-L] instrumentation in header

Dear Axel and all,
I heavily agree with Axel concerning the wish for an <instrumentList> in the header which would make it much easier for us in doing a sort of "simple cataloguing" of works: When we try to list the instruments of an opera, for instance, we do that in the moment (following Axel's model) in the scoreDef with staffGroup(s) - but in an opera there are changing instrumentations in each number, so we misuse this scoreDef as a "collective" form of listing all the instruments ever playing somewhere in the work. This is clearly the task of such an "instrumentList" which besides would make it easier to use a more abridged way of catalogue-encoding in the header.
Concerning incip I too would prefer to add the "it" at the end because "it" would not make any weighing machine complain?
And many thanks to you, Axel, for taking part in our discussions in the Virtual Meeting!!!
Best greetings,
Joachim
P.S. In a few minutes we shall make "it" - that's to say: start to drink a bee(r)!


Am 20.07.11 17:58, schrieb Axel Teich Geertinger:
Dear all,

first of all thank you for the excellent virtual meeting! I really enjoyed hearing you all and even seeing some of you :-)

I have a question to the tech team: Now that we will soon have elements like <incip>, <key> and <castList> in the header, why not also add something like <instrumentList>? What these metadata have in common is that they are actually also contained in the score, although in a more or less ?hidden? way, perhaps (as with key) requiring some analysis or interpretation.
Very much like the cast list, a list of instruments could in principle be harvested from a complete encoded score. In our cataloguing projects, however, the scores are not necessarily available, so we need to add that information either as a note somewhere in the header or in a staffDef, which does nothing but defining the instruments involved (a solution I would be happy to get rid of). The incipit will not do, as in many cases not all instruments will appear in it.
The same problem is true with choirs and vocal soloists, when they do not represent a named character and therefore will not fit into the castList.

Another question: why <incip>, and not <incipit>? We have quite long element names like <classification>, so why abbreviate incipit?

All the best,
Axel



_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto: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/20110721/7c4e0393/attachment.html>

From bohl at edirom.de  Thu Jul 21 14:37:03 2011
From: bohl at edirom.de (Benjamin Wolff Bohl)
Date: Thu, 21 Jul 2011 14:37:03 +0200
Subject: [MEI-L]  MEI-Guidelines
Message-ID: <4E281D6F.7040909@edirom.de>

  Dear List,

having been addressed during the virtual meeting and being part of the 
next aims of the MEI in particular in means of dissemination and 
tutoring, the technical team had a short discussion on the creation 
MEI-Guidelines. With the Tag Library being a documentation of the schema 
from a technical point of view, the Guidelines shall be designed in more 
"musicologist-appealing" manner, i.e. a prose text explaining how to use 
the elements and illustrated by examples. Of course there should be 
cross-referencing both from and to the Tag Library.
As an initial general structure we propose approaching this huge effort 
by module and there have already been a couple of volunteers for editing 
certain modules (see list below).
Perry Roland and Johannes Kepper will be editors in chief and give a 
head start on the shared module in order to deliver a first basis to 
build upon. Moreover Joachim Veit, Maja Hartwig and Christina Richts 
will try to map the "Requirements Specification List" to the modules in 
order to make use of the efforts that already went into creating that.
The CMN being fairly the largest module might be subdivided, but a 
strategy for that still has to be developed.
Nevertheless we invite all of you to join and roll up for a certain 
module or topic,  that you feel familiar with or even have expertise in, 
be it as contributor or responsible editor. Details on the workflow and 
on the means of submitting to the guidelines will be given later by our 
editors in chief.
Below you'll find the current list (promised above) giving an overview 
of the editors:

Module: Responsibilty
shared: Perry Roland and Johannes Kepper
header: Perry Roland
cmn:
mensural: Laurent Pugin
neumes: Andrew Hankinson
analysis:
cmnOrnaments: Raffaele Viglianti
corpus:
critapp: Johannes Kepper
edittrans: Johannes Kepper
facsimile: Johannes Kepper
figtable:
harmony:
linkalign:
lyrics: Raffaele Viglianti
midi: Craig Sapp
namesdates:
performance:
ptrref:
tablature:
text:
usersymbols: Thomas Weber
layout: Laurent Pugin


Best wishes,

Benjamin


From bohl at edirom.de  Thu Jul 21 16:26:20 2011
From: bohl at edirom.de (Benjamin Wolff Bohl)
Date: Thu, 21 Jul 2011 16:26:20 +0200
Subject: [MEI-L]  MEI-Guidelines
Message-ID: <4E28370C.2040005@edirom.de>


  Dear List,

having been addressed during the virtual meeting and being part of the
next aims of the MEI in particular in means of dissemination and
tutoring, the technical team had a short discussion on the creation
MEI-Guidelines. With the Tag Library being a documentation of the schema
from a technical point of view, the Guidelines shall be designed in more
"musicologist-appealing" manner, i.e. a prose text explaining how to use
the elements and illustrated by examples. Of course there should be
cross-referencing both from and to the Tag Library.
As an initial general structure we propose approaching this huge effort
by module and there have already been a couple of volunteers for editing
certain modules (see list below).
Perry Roland and Johannes Kepper will be editors in chief and give a
head start on the shared module in order to deliver a first basis to
build upon. Moreover Joachim Veit, Maja Hartwig and Christina Richts
will try to map the "Requirements Specification List" to the modules in
order to make use of the efforts that already went into creating that.
The CMN being fairly the largest module might be subdivided, but a
strategy for that still has to be developed.
Nevertheless we invite all of you to join and roll up for a certain
module or topic,  that you feel familiar with or even have expertise in,
be it as contributor or responsible editor. Details on the workflow and
on the means of submitting to the guidelines will be given later by our
editors in chief.
Below you'll find the current list (promised above) giving an overview
of the editors:

Module: Responsibilty
shared: Perry Roland and Johannes Kepper
header: Perry Roland
cmn:
mensural: Laurent Pugin
neumes: Andrew Hankinson
analysis:
cmnOrnaments: Raffaele Viglianti
corpus:
critapp: Johannes Kepper
edittrans: Johannes Kepper
facsimile: Johannes Kepper
figtable:
harmony:
linkalign:
lyrics: Raffaele Viglianti
midi: Craig Sapp
namesdates:
performance:
ptrref:
tablature:
text:
usersymbols: Thomas Weber
layout: Laurent Pugin


Best wishes,

Benjamin



From rfreedma at haverford.edu  Thu Jul 21 16:55:02 2011
From: rfreedma at haverford.edu (Richard Freedman)
Date: Thu, 21 Jul 2011 10:55:02 -0400
Subject: [MEI-L] MEI-Guidelines
In-Reply-To: <4E28370C.2040005@edirom.de>
References: <4E28370C.2040005@edirom.de>
Message-ID: <CA+zvZGfRmSwJUvgPWdJ_XXCuZk5FQ=ur-FX5rwKHQi1spTmBGA@mail.gmail.com>

These will be extremely helpful!  Thank you.

Richard

On Thu, Jul 21, 2011 at 10:26 AM, Benjamin Wolff Bohl <bohl at edirom.de>wrote:

>
>  Dear List,
>
> having been addressed during the virtual meeting and being part of the
> next aims of the MEI in particular in means of dissemination and
> tutoring, the technical team had a short discussion on the creation
> MEI-Guidelines. With the Tag Library being a documentation of the schema
> from a technical point of view, the Guidelines shall be designed in more
> "musicologist-appealing" manner, i.e. a prose text explaining how to use
> the elements and illustrated by examples. Of course there should be
> cross-referencing both from and to the Tag Library.
> As an initial general structure we propose approaching this huge effort
> by module and there have already been a couple of volunteers for editing
> certain modules (see list below).
> Perry Roland and Johannes Kepper will be editors in chief and give a
> head start on the shared module in order to deliver a first basis to
> build upon. Moreover Joachim Veit, Maja Hartwig and Christina Richts
> will try to map the "Requirements Specification List" to the modules in
> order to make use of the efforts that already went into creating that.
> The CMN being fairly the largest module might be subdivided, but a
> strategy for that still has to be developed.
> Nevertheless we invite all of you to join and roll up for a certain
> module or topic,  that you feel familiar with or even have expertise in,
> be it as contributor or responsible editor. Details on the workflow and
> on the means of submitting to the guidelines will be given later by our
> editors in chief.
> Below you'll find the current list (promised above) giving an overview
> of the editors:
>
> Module: Responsibilty
> shared: Perry Roland and Johannes Kepper
> header: Perry Roland
> cmn:
> mensural: Laurent Pugin
> neumes: Andrew Hankinson
> analysis:
> cmnOrnaments: Raffaele Viglianti
> corpus:
> critapp: Johannes Kepper
> edittrans: Johannes Kepper
> facsimile: Johannes Kepper
> figtable:
> harmony:
> linkalign:
> lyrics: Raffaele Viglianti
> midi: Craig Sapp
> namesdates:
> performance:
> ptrref:
> tablature:
> text:
> usersymbols: Thomas Weber
> layout: Laurent Pugin
>
>
> Best wishes,
>
> Benjamin
>
>
> ______________________________**_________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.**de/mailman/listinfo/mei-l<https://lists.uni-paderborn.de/mailman/listinfo/mei-l>
>



-- 
Richard Freedman
John C. Whitehead Professor of Music
Haverford College
Haverford, PA 19041

610-896-1007
610-896-4902 (fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110721/729086e8/attachment.html>

From kepper at edirom.de  Thu Jul 21 17:13:07 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Thu, 21 Jul 2011 17:13:07 +0200
Subject: [MEI-L] Problems
Message-ID: <74CEB152-9528-478F-A6EB-FC0A6B0B09CF@edirom.de>

Dear List,

it seems that the mailing list has some problems currently. I'll try to gather further information on this and will send a message as soon as resolved?

Best,
Johannes

From kepper at upb.de  Fri Jul 22 10:08:11 2011
From: kepper at upb.de (Johannes Kepper)
Date: Fri, 22 Jul 2011 10:08:11 +0200
Subject: [MEI-L] [Ticket#2011072110000711] Probleme mit Mailinglisten
In-Reply-To: <1311315318.458814.658679808.221756.9@otrs.uni-paderborn.de>
References: <6C3A7532-74F4-4A3D-9C2F-F23672331817@upb.de>
	<1311315318.458814.658679808.221756.9@otrs.uni-paderborn.de>
Message-ID: <1908A152-8899-471B-AD39-241EB60ADD72@upb.de>

Dear MEI-ers,

The mailing lists are behaving strange. This mail is just a test for the support in Paderborn. Everything fine now? (Don't need to answer?)

Johannes

(and thanks for a very productive meeting)



Am 22.07.2011 um 08:15 schrieb IMT Helpdesk:

> Hallo Johannes Kepper
> es gab bis gestern Morgen, Probleme mit den Maling-Listen. Nach dem Umstellen der Statusmeldungen sollte wieder alles ok sein. 
> In den Logfiles ist mir auch nichts besonderes aufgefallen. Vielleicht k?nnten sie mal eine Testmail schicken, damit ich zeitnah den Logfile ?berpr?fen kann.
> 
> 
> Mit freundlichen Gr??en
> 
> Norbert Huepping
> 
> HINWEIS: Den aktuellen Status unserer Dienste k?nnen Sie unter 
> http://statusmeldungen.uni-paderborn.de erfahren.
> 
> -- 
> Universit?t Paderborn
> Zentrum f?r Informations- und Medientechnologien
> Warburgerstr. 100
> 33098 Paderborn
> 
> 21.07.2011 17:28 - Johannes Kepper schrieb:



From pdr4h at eservices.virginia.edu  Fri Jul 22 15:40:11 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Fri, 22 Jul 2011 13:40:11 +0000
Subject: [MEI-L] instrumentation in header
In-Reply-To: <4E2706B5.9000108@weber-gesamtausgabe.de>
References: <CAMyHAnNPv_e9VKCE_BG-OuUVkE+Yknz3Y6kuu0_ky4NODVn=2g@mail.gmail.com>
	<0B6F63F59F405E4C902DFE2C2329D0D117B9153C@EXCHANGE-02.kb.dk>,
	<4E2706B5.9000108@weber-gesamtausgabe.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D09EB89@WILSON.eservices.virginia.edu>

Hi Axel, Joachim, everyone,

Sorry for the delay in answering -- I thought I hit the send button 2 days ago, but since my answer hasn't come through, I suppose I didn't.

Anticipating the need for such things, a <perfMedium> element has already been added.  This element is based on the MARC 048 tag (at least I think it was 048).  This element is allowed in <sourceDesc>, <work>, and <relatedItem>.

Hope this helps,

--
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 Joachim Veit [veit at weber-gesamtausgabe.de]
Sent: Wednesday, July 20, 2011 12:47 PM
To: mei-l at lists.uni-paderborn.de
Subject: Re: [MEI-L] instrumentation in header

Dear Axel and all,
I heavily agree with Axel concerning the wish for an <instrumentList> in the header which would make it much easier for us in doing a sort of "simple cataloguing" of works: When we try to list the instruments of an opera, for instance, we do that in the moment (following Axel's model) in the scoreDef with staffGroup(s) - but in an opera there are changing instrumentations in each number, so we misuse this scoreDef as a "collective" form of listing all the instruments ever playing somewhere in the work. This is clearly the task of such an "instrumentList" which besides would make it easier to use a more abridged way of catalogue-encoding in the header.
Concerning incip I too would prefer to add the "it" at the end because "it" would not make any weighing machine complain?
And many thanks to you, Axel, for taking part in our discussions in the Virtual Meeting!!!
Best greetings,
Joachim
P.S. In a few minutes we shall make "it" - that's to say: start to drink a bee(r)!


Am 20.07.11 17:58, schrieb Axel Teich Geertinger:
Dear all,

first of all thank you for the excellent virtual meeting! I really enjoyed hearing you all and even seeing some of you :-)

I have a question to the tech team: Now that we will soon have elements like <incip>, <key> and <castList> in the header, why not also add something like <instrumentList>? What these metadata have in common is that they are actually also contained in the score, although in a more or less ?hidden? way, perhaps (as with key) requiring some analysis or interpretation.
Very much like the cast list, a list of instruments could in principle be harvested from a complete encoded score. In our cataloguing projects, however, the scores are not necessarily available, so we need to add that information either as a note somewhere in the header or in a staffDef, which does nothing but defining the instruments involved (a solution I would be happy to get rid of). The incipit will not do, as in many cases not all instruments will appear in it.
The same problem is true with choirs and vocal soloists, when they do not represent a named character and therefore will not fit into the castList.

Another question: why <incip>, and not <incipit>? We have quite long element names like <classification>, so why abbreviate incipit?

All the best,
Axel



_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto: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/20110722/e7acdfa8/attachment.html>

From kepper at edirom.de  Mon Jul 25 13:32:50 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 25 Jul 2011 13:32:50 +0200
Subject: [MEI-L] [Ticket#2011072110000711] Probleme mit Mailinglisten
In-Reply-To: <1908A152-8899-471B-AD39-241EB60ADD72@upb.de>
References: <6C3A7532-74F4-4A3D-9C2F-F23672331817@upb.de>
	<1311315318.458814.658679808.221756.9@otrs.uni-paderborn.de>
	<1908A152-8899-471B-AD39-241EB60ADD72@upb.de>
Message-ID: <79B2E125-6869-4BB6-B327-C902DAE9BE52@edirom.de>

Dear MEI-ers,

the problem described in my previous mail seems to be solved: The mailserver did not deliver all mails during the last week. Now the support apparently has solved the problem: when comparing with the archive, it seems like all mails are delivered. If someone of you still misses a mail from last week, please let me know. 

Best regards,
Johannes





Am 22.07.2011 um 10:08 schrieb Johannes Kepper:

> Dear MEI-ers,
> 
> The mailing lists are behaving strange. This mail is just a test for the support in Paderborn. Everything fine now? (Don't need to answer?)
> 
> Johannes
> 
> (and thanks for a very productive meeting)
> 
> 
> 
> Am 22.07.2011 um 08:15 schrieb IMT Helpdesk:
> 
>> Hallo Johannes Kepper
>> es gab bis gestern Morgen, Probleme mit den Maling-Listen. Nach dem Umstellen der Statusmeldungen sollte wieder alles ok sein. 
>> In den Logfiles ist mir auch nichts besonderes aufgefallen. Vielleicht k?nnten sie mal eine Testmail schicken, damit ich zeitnah den Logfile ?berpr?fen kann.
>> 
>> 
>> Mit freundlichen Gr??en
>> 
>> Norbert Huepping
>> 
>> HINWEIS: Den aktuellen Status unserer Dienste k?nnen Sie unter 
>> http://statusmeldungen.uni-paderborn.de erfahren.
>> 
>> -- 
>> Universit?t Paderborn
>> Zentrum f?r Informations- und Medientechnologien
>> Warburgerstr. 100
>> 33098 Paderborn
>> 
>> 21.07.2011 17:28 - Johannes Kepper schrieb:
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From zupftom at googlemail.com  Mon Jul 25 14:29:38 2011
From: zupftom at googlemail.com (TW)
Date: Mon, 25 Jul 2011 14:29:38 +0200
Subject: [MEI-L] @copyof and @sameas
Message-ID: <CAEB1mArdxwV8--5U8B85nzX88gqaEx=zh6rpQxQsLXUutA+LgQ@mail.gmail.com>

We discussed the meaning of @copyof and @sameas during the meeting in
Detmold.  Just to reassure myself that my understanding of what we
finally agreed on is correct:

Elements with @copyof should not have content as the content is
replaced by the content of the referenced element.  (Virtually
replaced, or when "ironing", really replaced.)  The attributes are
also copied, but only those that weren't already set.  IDs have to be
changed or stripped to avoid duplicate IDs.

@sameas means that two elements are actually (musically?) the same,
but still have to be present twice (or more) in the MEI data.  Most
common example is a rest that is shared by two voices on a single
staff and has to be present in both layers.

Is that about correct?
Thomas Weber


From richard.lewis at gold.ac.uk  Mon Jul 25 16:58:39 2011
From: richard.lewis at gold.ac.uk (Richard Lewis)
Date: Mon, 25 Jul 2011 15:58:39 +0100
Subject: [MEI-L] [Ticket#2011072110000711] Probleme mit Mailinglisten
In-Reply-To: <79B2E125-6869-4BB6-B327-C902DAE9BE52@edirom.de>
References: <6C3A7532-74F4-4A3D-9C2F-F23672331817@upb.de>
	<1311315318.458814.658679808.221756.9@otrs.uni-paderborn.de>
	<1908A152-8899-471B-AD39-241EB60ADD72@upb.de>
	<79B2E125-6869-4BB6-B327-C902DAE9BE52@edirom.de>
Message-ID: <87mxg2h0f4.wl%richard.lewis@gold.ac.uk>

At Mon, 25 Jul 2011 13:32:50 +0200,
Johannes Kepper wrote:
> 
> If someone of you still misses a mail from last week, please let me
> know.

Raise your hand if you can't hear me at the back ;-)

Best,
Richard
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Richard Lewis
ISMS, Computing
Goldsmiths, University of London
Tel: +44 (0)20 7078 5134
Skype: richardjlewis
JID: ironchicken at jabber.earth.li
http://www.richardlewis.me.uk/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


From kepper at edirom.de  Mon Jul 25 17:09:46 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 25 Jul 2011 17:09:46 +0200
Subject: [MEI-L] [Ticket#2011072110000711] Probleme mit Mailinglisten
In-Reply-To: <87mxg2h0f4.wl%richard.lewis@gold.ac.uk>
References: <6C3A7532-74F4-4A3D-9C2F-F23672331817@upb.de>
	<1311315318.458814.658679808.221756.9@otrs.uni-paderborn.de>
	<1908A152-8899-471B-AD39-241EB60ADD72@upb.de>
	<79B2E125-6869-4BB6-B327-C902DAE9BE52@edirom.de>
	<87mxg2h0f4.wl%richard.lewis@gold.ac.uk>
Message-ID: <EA461B06-B26B-485A-9E8B-CECC64311BDD@edirom.de>


Am 25.07.2011 um 16:58 schrieb Richard Lewis:

> At Mon, 25 Jul 2011 13:32:50 +0200,
> Johannes Kepper wrote:
>> 
>> If someone of you still misses a mail from last week, please let me
>> know.
> 
> Raise your hand if you can't hear me at the back ;-)
> 

Got me. Obviously only in case you're the one sending that mail :-)

Or, if you just have the strong feeling that there have been other mails, please contact your local fortuneteller for further support?


Johannes

> Best,
> Richard
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Richard Lewis
> ISMS, Computing
> Goldsmiths, University of London
> Tel: +44 (0)20 7078 5134
> Skype: richardjlewis
> JID: ironchicken at jabber.earth.li
> http://www.richardlewis.me.uk/
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From zupftom at googlemail.com  Wed Jul 27 08:55:35 2011
From: zupftom at googlemail.com (TW)
Date: Wed, 27 Jul 2011 08:55:35 +0200
Subject: [MEI-L] @copyof and @sameas
In-Reply-To: <CAEB1mArdxwV8--5U8B85nzX88gqaEx=zh6rpQxQsLXUutA+LgQ@mail.gmail.com>
References: <CAEB1mArdxwV8--5U8B85nzX88gqaEx=zh6rpQxQsLXUutA+LgQ@mail.gmail.com>
Message-ID: <CAEB1mApkx=i+bZstpDhGCs+R75QyLsx73V9DLVhjk78bft-wUA@mail.gmail.com>

In other words:  Is this an appropriate resolution for elements with @copyof:



<?xml version="1.0"?>
<stylesheet version="1.0" xmlns="http://www.w3.org/1999/XSL/Transform"
xmlns:mei="http://www.music-encoding.org/ns/mei">
  <!-- Why doesn't the following work, at least not with all processors? -->
  <!--<key match="mei:*" name="id" use="@xml:id"/>-->
  <key match="mei:*" name="id" use="@*[local-name()='id' or
local-name()='xml:id']"/>


  <template match="/">
    <apply-templates select="*"/>
  </template>

  <template match="*">
    <copy>
      <apply-templates select="@*|node()"/>
    </copy>
  </template>

  <template match="@*">
    <copy-of select="."/>
  </template>

  <template match="mei:*[@copyof]">
    <copy>
      <apply-templates select="key('id', at copyof)/@*" mode="copy-without-ids"/>
      <!-- Attributes on the current node override those from referenced node.
           This stylesheet leaves the @copyof attribute in place as it does no
           harm and makes it possible to go back to the original
unresolved form -->
      <apply-templates select="@*"/>
      <apply-templates select="key('id', at copyof)/node()"
mode="copy-without-ids"/>
    </copy>
  </template>

  <template mode="copy-without-ids" match="*">
    <copy>
      <apply-templates select="@*|node()" mode="copy-without-ids"/>
    </copy>
  </template>

  <template match="@*" mode="copy-without-ids">
    <copy-of select="."/>
  </template>
  <template match="@xml:id" mode="copy-without-ids"/>

</stylesheet>



This could be a first small contribution to MEIron, but it doesn't
record anything in changedesc and appinfo.  What should be added to
those elements?  Shall we create a tools folder with an meiron
subfolder in the MEI_2011_dev branch to commit things like this?

Thomas Weber


2011/7/25 TW <zupftom at googlemail.com>:
> We discussed the meaning of @copyof and @sameas during the meeting in
> Detmold. ?Just to reassure myself that my understanding of what we
> finally agreed on is correct:
>
> Elements with @copyof should not have content as the content is
> replaced by the content of the referenced element. ?(Virtually
> replaced, or when "ironing", really replaced.) ?The attributes are
> also copied, but only those that weren't already set. ?IDs have to be
> changed or stripped to avoid duplicate IDs.
>
> @sameas means that two elements are actually (musically?) the same,
> but still have to be present twice (or more) in the MEI data. ?Most
> common example is a rest that is shared by two voices on a single
> staff and has to be present in both layers.
>
> Is that about correct?
> Thomas Weber
>


From raffaeleviglianti at gmail.com  Wed Jul 27 10:01:24 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Wed, 27 Jul 2011 09:01:24 +0100
Subject: [MEI-L] @copyof and @sameas
In-Reply-To: <CAEB1mApkx=i+bZstpDhGCs+R75QyLsx73V9DLVhjk78bft-wUA@mail.gmail.com>
References: <CAEB1mArdxwV8--5U8B85nzX88gqaEx=zh6rpQxQsLXUutA+LgQ@mail.gmail.com>
	<CAEB1mApkx=i+bZstpDhGCs+R75QyLsx73V9DLVhjk78bft-wUA@mail.gmail.com>
Message-ID: <CAMyHAnPHEs6X574uieiRSD=ZtbQg4jCY6QSwPHMQdZcfG1wtrA@mail.gmail.com>

Hi Thomas,

I think your definition of @copyof and @sameas from your first email is
accurate.

Your XSLT seems correct too (I haven't ran it, though), but removing ids
might not be ideal. If an entire measure is copied, for example, there could
be some elements (say, slur) with @startid and @endid pointing at @xml:ids
within the measure. Removing the ids would break these references.
A possible solution is to generate new ids for the elements being copied and
adjust references within the copied context.
Even in this case, some references might remain ambiguous. Think of a slur
with an @endid that points to an element in the following measure. If the
measure with the slur is copied, but not the following, also the copied slur
will refer to the same element as the original, surely creating an error.
Would it make sense to try to build some awareness of references that go
over the copied context? (the same problem applies to values expressed in
timestamp)

Creating a tools/MEIron directory in SVN for XSLTs like this is an excellent
idea. Are you already a committer on googlecode?

Best,
Raffaele
On Jul 27, 2011 7:56 AM, "TW" <zupftom at googlemail.com> wrote:
> In other words: Is this an appropriate resolution for elements with
@copyof:
>
>
>
> <?xml version="1.0"?>
> <stylesheet version="1.0" xmlns="http://www.w3.org/1999/XSL/Transform"
> xmlns:mei="http://www.music-encoding.org/ns/mei">
> <!-- Why doesn't the following work, at least not with all processors? -->
> <!--<key match="mei:*" name="id" use="@xml:id"/>-->
> <key match="mei:*" name="id" use="@*[local-name()='id' or
> local-name()='xml:id']"/>
>
>
> <template match="/">
> <apply-templates select="*"/>
> </template>
>
> <template match="*">
> <copy>
> <apply-templates select="@*|node()"/>
> </copy>
> </template>
>
> <template match="@*">
> <copy-of select="."/>
> </template>
>
> <template match="mei:*[@copyof]">
> <copy>
> <apply-templates select="key('id', at copyof)/@*" mode="copy-without-ids"/>
> <!-- Attributes on the current node override those from referenced node.
> This stylesheet leaves the @copyof attribute in place as it does no
> harm and makes it possible to go back to the original
> unresolved form -->
> <apply-templates select="@*"/>
> <apply-templates select="key('id', at copyof)/node()"
> mode="copy-without-ids"/>
> </copy>
> </template>
>
> <template mode="copy-without-ids" match="*">
> <copy>
> <apply-templates select="@*|node()" mode="copy-without-ids"/>
> </copy>
> </template>
>
> <template match="@*" mode="copy-without-ids">
> <copy-of select="."/>
> </template>
> <template match="@xml:id" mode="copy-without-ids"/>
>
> </stylesheet>
>
>
>
> This could be a first small contribution to MEIron, but it doesn't
> record anything in changedesc and appinfo. What should be added to
> those elements? Shall we create a tools folder with an meiron
> subfolder in the MEI_2011_dev branch to commit things like this?
>
> Thomas Weber
>
>
> 2011/7/25 TW <zupftom at googlemail.com>:
>> We discussed the meaning of @copyof and @sameas during the meeting in
>> Detmold.  Just to reassure myself that my understanding of what we
>> finally agreed on is correct:
>>
>> Elements with @copyof should not have content as the content is
>> replaced by the content of the referenced element.  (Virtually
>> replaced, or when "ironing", really replaced.)  The attributes are
>> also copied, but only those that weren't already set.  IDs have to be
>> changed or stripped to avoid duplicate IDs.
>>
>> @sameas means that two elements are actually (musically?) the same,
>> but still have to be present twice (or more) in the MEI data.  Most
>> common example is a rest that is shared by two voices on a single
>> staff and has to be present in both layers.
>>
>> Is that about correct?
>> Thomas Weber
>>
>
> _______________________________________________
> 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/20110727/f46e5901/attachment.html>

From zupftom at googlemail.com  Wed Jul 27 12:12:38 2011
From: zupftom at googlemail.com (TW)
Date: Wed, 27 Jul 2011 12:12:38 +0200
Subject: [MEI-L] @copyof and @sameas
In-Reply-To: <CAMyHAnPHEs6X574uieiRSD=ZtbQg4jCY6QSwPHMQdZcfG1wtrA@mail.gmail.com>
References: <CAEB1mArdxwV8--5U8B85nzX88gqaEx=zh6rpQxQsLXUutA+LgQ@mail.gmail.com>
	<CAEB1mApkx=i+bZstpDhGCs+R75QyLsx73V9DLVhjk78bft-wUA@mail.gmail.com>
	<CAMyHAnPHEs6X574uieiRSD=ZtbQg4jCY6QSwPHMQdZcfG1wtrA@mail.gmail.com>
Message-ID: <CAEB1mApQZTgj62GfyNBOtJkSaWoYgHci4EY+MbHapDhBYvwbnA@mail.gmail.com>

The issue of IDs is of course problematic.  With Johannes and Perry,
we didn't come up with a good solution other than leaving it up to the
application what to do with the IDs.  In this case, I'm simply
stripping them and can be sure to get a valid MEI document, as long as
an element of the same name is referenced by @copyof.  You're of
course right, it would be desirable to preserve pointers that remain
within the context and avoid unintentional pointers to elements of the
copied element.  Any good solution for this?

Thomas


2011/7/27 Raffaele Viglianti <raffaeleviglianti at gmail.com>:
> Hi Thomas,
>
> I think your definition of @copyof and @sameas from your first email is
> accurate.
>
> Your XSLT seems correct too (I haven't ran it, though), but removing ids
> might not be ideal. If an entire measure is copied, for example, there could
> be some elements (say, slur) with @startid and @endid pointing at @xml:ids
> within the measure. Removing the ids would break these references.
> A possible solution is to generate new ids for the elements being copied and
> adjust references within the copied context.
> Even in this case, some references might remain ambiguous. Think of a slur
> with an @endid that points to an element in the following measure. If the
> measure with the slur is copied, but not the following, also the copied slur
> will refer to the same element as the original, surely creating an error.
> Would it make sense to try to build some awareness of references that go
> over the copied context? (the same problem applies to values expressed in
> timestamp)
>
> Creating a tools/MEIron directory in SVN for XSLTs like this is an excellent
> idea. Are you already a committer on googlecode?
>
> Best,
> Raffaele
>
> On Jul 27, 2011 7:56 AM, "TW" <zupftom at googlemail.com> wrote:
>> In other words: Is this an appropriate resolution for elements with
>> @copyof:
>>
>>
>>
>> <?xml version="1.0"?>
>> <stylesheet version="1.0" xmlns="http://www.w3.org/1999/XSL/Transform"
>> xmlns:mei="http://www.music-encoding.org/ns/mei">
>> <!-- Why doesn't the following work, at least not with all processors? -->
>> <!--<key match="mei:*" name="id" use="@xml:id"/>-->
>> <key match="mei:*" name="id" use="@*[local-name()='id' or
>> local-name()='xml:id']"/>
>>
>>
>> <template match="/">
>> <apply-templates select="*"/>
>> </template>
>>
>> <template match="*">
>> <copy>
>> <apply-templates select="@*|node()"/>
>> </copy>
>> </template>
>>
>> <template match="@*">
>> <copy-of select="."/>
>> </template>
>>
>> <template match="mei:*[@copyof]">
>> <copy>
>> <apply-templates select="key('id', at copyof)/@*" mode="copy-without-ids"/>
>> <!-- Attributes on the current node override those from referenced node.
>> This stylesheet leaves the @copyof attribute in place as it does no
>> harm and makes it possible to go back to the original
>> unresolved form -->
>> <apply-templates select="@*"/>
>> <apply-templates select="key('id', at copyof)/node()"
>> mode="copy-without-ids"/>
>> </copy>
>> </template>
>>
>> <template mode="copy-without-ids" match="*">
>> <copy>
>> <apply-templates select="@*|node()" mode="copy-without-ids"/>
>> </copy>
>> </template>
>>
>> <template match="@*" mode="copy-without-ids">
>> <copy-of select="."/>
>> </template>
>> <template match="@xml:id" mode="copy-without-ids"/>
>>
>> </stylesheet>
>>
>>
>>
>> This could be a first small contribution to MEIron, but it doesn't
>> record anything in changedesc and appinfo. What should be added to
>> those elements? Shall we create a tools folder with an meiron
>> subfolder in the MEI_2011_dev branch to commit things like this?
>>
>> Thomas Weber
>>
>>
>> 2011/7/25 TW <zupftom at googlemail.com>:
>>> We discussed the meaning of @copyof and @sameas during the meeting in
>>> Detmold. ?Just to reassure myself that my understanding of what we
>>> finally agreed on is correct:
>>>
>>> Elements with @copyof should not have content as the content is
>>> replaced by the content of the referenced element. ?(Virtually
>>> replaced, or when "ironing", really replaced.) ?The attributes are
>>> also copied, but only those that weren't already set. ?IDs have to be
>>> changed or stripped to avoid duplicate IDs.
>>>
>>> @sameas means that two elements are actually (musically?) the same,
>>> but still have to be present twice (or more) in the MEI data. ?Most
>>> common example is a rest that is shared by two voices on a single
>>> staff and has to be present in both layers.
>>>
>>> Is that about correct?
>>> Thomas Weber
>>>
>>
>> _______________________________________________
>> 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
>
>


From rfreedma at haverford.edu  Thu Jul 28 16:49:45 2011
From: rfreedma at haverford.edu (Richard Freedman)
Date: Thu, 28 Jul 2011 10:49:45 -0400
Subject: [MEI-L] news about Du Chemin
Message-ID: <CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>

Friends,

News flash:

Just heard that my Du Chemin has been awarded $150,000 from the NEH
Scholarly Editions for 11-12 and 12-13.  This is great news, as it will
support TEI compatible editions of literary texts, a post doc to do
reconstructions and thesaurus, MEI compatibility, and much more, including
another year of travel for team members and participants.

avanti . .

richard
-- 
Richard Freedman
John C. Whitehead Professor of Music
Haverford College
Haverford, PA 19041

610-896-1007
610-896-4902 (fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110728/c75b9536/attachment.html>

From ich at music.mcgill.ca  Thu Jul 28 17:24:43 2011
From: ich at music.mcgill.ca (Ichiro Fujinaga)
Date: Thu, 28 Jul 2011 16:24:43 +0100
Subject: [MEI-L] news about Du Chemin
In-Reply-To: <4291_1311864599_4E317717_4291_124_1_CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>
References: <4291_1311864599_4E317717_4291_124_1_CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>
Message-ID: <BLU0-SMTP9129B530BFB6F2DF3B796FBE340@phx.gbl>

Great!!
Congratulations!!
Marenzio project was successful too!

Ich

On 2011-07-28, at 3:49 PM, Richard Freedman <rfreedma at haverford.edu> wrote:

> Friends,
> 
> News flash:
> 
> Just heard that my Du Chemin has been awarded $150,000 from the NEH Scholarly Editions for 11-12 and  12-13.  This is great news, as it will support TEI compatible editions of literary texts, a post doc to do reconstructions and thesaurus, MEI compatibility, and much more, including another year of travel for team members and participants.
> 
> avanti . . 
> 
> richard
> -- 
> Richard Freedman
> John C. Whitehead Professor of Music
> Haverford College
> Haverford, PA 19041
> 
> 610-896-1007
> 610-896-4902 (fax)
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l


From pdr4h at eservices.virginia.edu  Thu Jul 28 20:11:12 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Thu, 28 Jul 2011 18:11:12 +0000
Subject: [MEI-L] news about Du Chemin
In-Reply-To: <BLU0-SMTP9129B530BFB6F2DF3B796FBE340@phx.gbl>
References: <4291_1311864599_4E317717_4291_124_1_CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>,
	<BLU0-SMTP9129B530BFB6F2DF3B796FBE340@phx.gbl>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D09F452@WILSON.eservices.virginia.edu>

Fantastic news!  Congratulations!

--
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 Ichiro Fujinaga [ich at music.mcgill.ca]
Sent: Thursday, July 28, 2011 11:24 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] news about Du Chemin

Great!!
Congratulations!!
Marenzio project was successful too!

Ich

On 2011-07-28, at 3:49 PM, Richard Freedman <rfreedma at haverford.edu> wrote:

> Friends,
>
> News flash:
>
> Just heard that my Du Chemin has been awarded $150,000 from the NEH Scholarly Editions for 11-12 and  12-13.  This is great news, as it will support TEI compatible editions of literary texts, a post doc to do reconstructions and thesaurus, MEI compatibility, and much more, including another year of travel for team members and participants.
>
> avanti . .
>
> richard
> --
> Richard Freedman
> John C. Whitehead Professor of Music
> Haverford College
> Haverford, PA 19041
>
> 610-896-1007
> 610-896-4902 (fax)
>
> _______________________________________________
> 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


From jdownie at illinois.edu  Thu Jul 28 22:05:55 2011
From: jdownie at illinois.edu (J. Stephen Downie)
Date: Thu, 28 Jul 2011 13:05:55 -0700
Subject: [MEI-L] news about Du Chemin
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D09F452@WILSON.eservices.virginia.edu>
References: <4291_1311864599_4E317717_4291_124_1_CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>,
	<BLU0-SMTP9129B530BFB6F2DF3B796FBE340@phx.gbl>
	<BBCC497C40D85642B90E9F94FC30343D09F452@WILSON.eservices.virginia.edu>
Message-ID: <4E31C123.4090906@illinois.edu>

Let me add my congratulations!

On 7/28/2011 11:11 AM, Roland, Perry (pdr4h) wrote:
> Fantastic news!  Congratulations!
>
> --
> 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 Ichiro Fujinaga [ich at music.mcgill.ca]
> Sent: Thursday, July 28, 2011 11:24 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] news about Du Chemin
>
> Great!!
> Congratulations!!
> Marenzio project was successful too!
>
> Ich
>
> On 2011-07-28, at 3:49 PM, Richard Freedman<rfreedma at haverford.edu>  wrote:
>
>> Friends,
>>
>> News flash:
>>
>> Just heard that my Du Chemin has been awarded $150,000 from the NEH Scholarly Editions for 11-12 and  12-13.  This is great news, as it will support TEI compatible editions of literary texts, a post doc to do reconstructions and thesaurus, MEI compatibility, and much more, including another year of travel for team members and participants.
>>
>> avanti . .
>>
>> richard
>> --
>> Richard Freedman
>> John C. Whitehead Professor of Music
>> Haverford College
>> Haverford, PA 19041
>>
>> 610-896-1007
>> 610-896-4902 (fax)
>>
>> _______________________________________________
>> 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

-- 
**********************************************************
    "Research funding makes the world a better place"
**********************************************************
J. Stephen Downie, PhD
Associate Professor,
Graduate School of Library and Information Science; and,
Center Affiliate, National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
[Vox/Voicemail] (217) 649-3839
NEMA Project Home: http://nema.lis.uiuc.edu


From veit at weber-gesamtausgabe.de  Thu Jul 28 22:26:45 2011
From: veit at weber-gesamtausgabe.de (Joachim Veit)
Date: Thu, 28 Jul 2011 22:26:45 +0200
Subject: [MEI-L] news about Du Chemin
In-Reply-To: <CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>
References: <CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>
Message-ID: <4E31C605.6000805@weber-gesamtausgabe.de>

Dear Richard,
and still more gratulations from Detmold!!!
This sounds great (not only in terms of payment figures...), best wishes 
for your project
and best greetings from Detmold,
Joachim


Am 28.07.11 16:49, schrieb Richard Freedman:
> Friends,
>
> News flash:
>
> Just heard that my Du Chemin has been awarded $150,000 from the NEH 
> Scholarly Editions for 11-12 and 12-13.  This is great news, as it 
> will support TEI compatible editions of literary texts, a post doc to 
> do reconstructions and thesaurus, MEI compatibility, and much more, 
> including another year of travel for team members and participants.
>
> avanti . .
>
> richard
> -- 
> Richard Freedman
> John C. Whitehead Professor of Music
> Haverford College
> Haverford, PA 19041
>
> 610-896-1007
> 610-896-4902 (fax)
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110728/a2757e5a/attachment.html>
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : veit.vcf
Dateityp    : text/x-vcard
Dateigr??e  : 364 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110728/a2757e5a/attachment.vcf>

From roewenstrunk at edirom.de  Thu Jul 28 22:50:26 2011
From: roewenstrunk at edirom.de (=?ISO-8859-1?Q?Daniel_R=F6wenstrunk?=)
Date: Thu, 28 Jul 2011 22:50:26 +0200
Subject: [MEI-L] news about Du Chemin
In-Reply-To: <4E31C605.6000805@weber-gesamtausgabe.de>
References: <CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>
	<4E31C605.6000805@weber-gesamtausgabe.de>
Message-ID: <4E31CB92.10504@edirom.de>

Dear Richard,
let me add my congratulations, too. Sounds great.

Daniel

Am 28.07.11 22:26, schrieb Joachim Veit:
> Dear Richard,
> and still more gratulations from Detmold!!!
> This sounds great (not only in terms of payment figures...), best wishes
> for your project
> and best greetings from Detmold,
> Joachim
> 
> 
> Am 28.07.11 16:49, schrieb Richard Freedman:
>> Friends,
>>
>> News flash:
>>
>> Just heard that my Du Chemin has been awarded $150,000 from the NEH
>> Scholarly Editions for 11-12 and 12-13.  This is great news, as it
>> will support TEI compatible editions of literary texts, a post doc to
>> do reconstructions and thesaurus, MEI compatibility, and much more,
>> including another year of travel for team members and participants.
>>
>> avanti . .
>>
>> richard
>> -- 
>> Richard Freedman
>> John C. Whitehead Professor of Music
>> Haverford College
>> Haverford, PA 19041
>>
>> 610-896-1007
>> 610-896-4902 (fax)
>>
>>
>>
>> _______________________________________________
>> 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



From raffaeleviglianti at gmail.com  Fri Jul 29 12:20:48 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Fri, 29 Jul 2011 11:20:48 +0100
Subject: [MEI-L] news about Du Chemin
In-Reply-To: <4E31CB92.10504@edirom.de>
References: <CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>
	<4E31C605.6000805@weber-gesamtausgabe.de> <4E31CB92.10504@edirom.de>
Message-ID: <CAMyHAnNLob7xjeiDX9EiWVvy9RcDRTjqPixvabo7vaD3iggjRA@mail.gmail.com>

Dear Richard,

Congratulations, that's fantastic news!

Best wishes,
Raffaele

On Thu, Jul 28, 2011 at 9:50 PM, Daniel R?wenstrunk
<roewenstrunk at edirom.de>wrote:

> Dear Richard,
> let me add my congratulations, too. Sounds great.
>
> Daniel
>
> Am 28.07.11 22:26, schrieb Joachim Veit:
> > Dear Richard,
> > and still more gratulations from Detmold!!!
> > This sounds great (not only in terms of payment figures...), best wishes
> > for your project
> > and best greetings from Detmold,
> > Joachim
> >
> >
> > Am 28.07.11 16:49, schrieb Richard Freedman:
> >> Friends,
> >>
> >> News flash:
> >>
> >> Just heard that my Du Chemin has been awarded $150,000 from the NEH
> >> Scholarly Editions for 11-12 and 12-13.  This is great news, as it
> >> will support TEI compatible editions of literary texts, a post doc to
> >> do reconstructions and thesaurus, MEI compatibility, and much more,
> >> including another year of travel for team members and participants.
> >>
> >> avanti . .
> >>
> >> richard
> >> --
> >> Richard Freedman
> >> John C. Whitehead Professor of Music
> >> Haverford College
> >> Haverford, PA 19041
> >>
> >> 610-896-1007
> >> 610-896-4902 (fax)
> >>
> >>
> >>
> >> _______________________________________________
> >> 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/20110729/8e167744/attachment.html>

From elm8s at eservices.virginia.edu  Fri Jul 29 15:16:09 2011
From: elm8s at eservices.virginia.edu (Mayhood, Erin (elm8s))
Date: Fri, 29 Jul 2011 13:16:09 +0000
Subject: [MEI-L] news about Du Chemin
In-Reply-To: <CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>
References: <CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>
Message-ID: <F4F8F84C-4CFB-4C0C-97A2-321F46388E7C@eservices.virginia.edu>

Congratulations Richard! The MEI crew in Dublin had a drink for you last night!

Erin




On Jul 28, 2011, at 3:49 PM, "Richard Freedman" <rfreedma at haverford.edu> wrote:

> Friends,
> 
> News flash:
> 
> Just heard that my Du Chemin has been awarded $150,000 from the NEH Scholarly Editions for 11-12 and 12-13.  This is great news, as it will support TEI compatible editions of literary texts, a post doc to do reconstructions and thesaurus, MEI compatibility, and much more, including another year of travel for team members and participants.
> 
> avanti . . 
> 
> richard
> -- 
> Richard Freedman
> John C. Whitehead Professor of Music
> Haverford College
> Haverford, PA 19041
> 
> 610-896-1007
> 610-896-4902 (fax)
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l


From rfreedma at haverford.edu  Mon Aug  1 19:57:17 2011
From: rfreedma at haverford.edu (Richard Freedman)
Date: Mon, 1 Aug 2011 13:57:17 -0400
Subject: [MEI-L] Sibelius and MusicXML
Message-ID: <CA+zvZGfmjbMSJdPSmw8CYUOj_C3MHjS8ou5neZcm_1i1-N31nw@mail.gmail.com>

Friends:

Just learned from talking with folks at Sibelius that the new Sibelius 7
supports export/import with MusicXML.  No need for the third-part Dolet
application.  This is good.

Richard

-- 
Richard Freedman
John C. Whitehead Professor of Music
Haverford College
Haverford, PA 19041

610-896-1007
610-896-4902 (fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110801/69e003d3/attachment.html>

From bohl at edirom.de  Wed Aug  3 09:45:00 2011
From: bohl at edirom.de (Benjamin Wolff Bohl)
Date: Wed, 3 Aug 2011 09:45:00 +0200
Subject: [MEI-L] news about Du Chemin
In-Reply-To: <F4F8F84C-4CFB-4C0C-97A2-321F46388E7C@eservices.virginia.edu>
References: <CA+zvZGc_+x-BVoL1tJawsf8+cTvtz1n1hRyoZ4=LRpJya0hVdQ@mail.gmail.com>
	<F4F8F84C-4CFB-4C0C-97A2-321F46388E7C@eservices.virginia.edu>
Message-ID: <1AF0AC3F-FE59-4C07-8A67-428B03B23F34@edirom.de>

Congrats to Du Chemin and Marenzio projects!!

Benjamin


Am 29.07.2011 um 15:16 schrieb Mayhood, Erin (elm8s):

> Congratulations Richard! The MEI crew in Dublin had a drink for you last night!
> 
> Erin
> 
> 
> 
> 
> On Jul 28, 2011, at 3:49 PM, "Richard Freedman" <rfreedma at haverford.edu> wrote:
> 
>> Friends,
>> 
>> News flash:
>> 
>> Just heard that my Du Chemin has been awarded $150,000 from the NEH Scholarly Editions for 11-12 and 12-13.  This is great news, as it will support TEI compatible editions of literary texts, a post doc to do reconstructions and thesaurus, MEI compatibility, and much more, including another year of travel for team members and participants.
>> 
>> avanti . . 
>> 
>> richard
>> -- 
>> Richard Freedman
>> John C. Whitehead Professor of Music
>> Haverford College
>> Haverford, PA 19041
>> 
>> 610-896-1007
>> 610-896-4902 (fax)
>> 
>> _______________________________________________
>> 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



From atge at kb.dk  Thu Aug 11 11:32:26 2011
From: atge at kb.dk (Axel Teich Geertinger)
Date: Thu, 11 Aug 2011 09:32:26 +0000
Subject: [MEI-L] <work> metadata questions
Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D117B93B8C@EXCHANGE-02.kb.dk>

Hi Perry & all

I am trying to translate our existing metadata model to the new MEI header elements within <workDesc>. Huge improvements, thank you!!
Still, however, I cannot figure out how to completely avoid using <score> for some metadata, especially when getting down to movement level. And I have some other questions too (see below).

This is a first shot at outlining the first movements of a piece for orchestra, chorus and vocal soloists:

        <work>
            <key pname="a" mode="minor"/> <!-- @accid missing? Only @accid.ges seems to be available -->
            <perfMedium>
                <ensemble>
                    <instrVoice>Orchestra</instrVoice>
                </ensemble>
                <ensemble>
                    <instrVoice>Choir SSATTBB</instrVoice>
                </ensemble>
                <performer> <!-- How does <perfomer> relate to <castItem>? -->
                    <instrVoice>S</instrVoice>
                    <role>Comala</role>
                </performer>
                <performer>
                    <instrVoice>Bar</instrVoice>
                    <role>Fingal</role>
                </performer>
            </perfMedium>
            <castList>
                <castItem>
                    <role>Comala</role>
                    <roleDesc xml:lang="de">Fingals Geliebte</roleDesc>
                    <roleDesc xml:lang="da">Fingals elskede</roleDesc>
                </castItem>
                <castItem>
                    <role>Fingal</role>
                    <roleDesc xml:lang="de">K?nig von Morwen</roleDesc>
                    <roleDesc xml:lang="da">Konge af Morven</roleDesc>
                </castItem>
            </castList>
            <contents>
                <head>
                    <title xml:lang="de">Akt 1</title>
                    <title xml:lang="da">Akt 1</title>
                </head> <!-- Only one <head> allowed, i.e. no way to add "Akt 2" heading, etc.? -->
                <contentItem> <!-- How are these items linked to their respective elements in <music>? Using @analog? -->
                    <title xml:lang="de">No. 1. Chor der Krieger und Barden [TTBB]</title>
                    <title xml:lang="da">No. 1. Fingals Krigere</title>
                    <!-- No way to use <key> and <tempo> anywhere here? -->
                    <!-- And how about a <meter> element? -->
                    <incip>
                        <p xml:lang="de">Auf, auf, auf, laut schallt das Horn</p>
                        <p xml:lang="da">Frem, frem, frem, fremad til Kamp</p>
                        <p label="graphics"> <!-- container for links to incipit graphics -->
                            <extptr targettype="lowres" mimetype="image/png" xl:href="http://img.kb.dk/..."/>
                            <extptr targettype="hires" mimetype="image/png" xl:href="http://img.kb.dk/..."/>
                        </p>
                        <score>
                            <app>
                                <rdg type="metadata">
                                    <!-- Declared in a "metadata" reading in order to avoid conflict with an actual encoding of the incipit -->
                                    <scoreDef key.pname="a" key.accid="n" key.mode="minor" meter.sym="common"/> <!-- key and meter at movement level -->
                                    <staff><layer><tempo>Andante - Allegro non troppo</tempo></layer></staff> <!-- tempo indications in this movement -->
                                </rdg>
                            </app>
                        </score>
                    </incip>
                </contentItem>
                <contentItem>
                    <title xml:lang="de">No. 2 [Comala, Fingal]</title>
                    <title xml:lang="da">No. 2 [Comala, Fingal]</title>
                    <incip>
                        <p xml:lang="de">Heute noch brech' ich des stolzen K?nigs Macht</p>
                        <p xml:lang="da">Alt i Kv?ld slaar jeg den stolte Konges H?r</p>
                        <p label="graphics">
                            <extptr targettype="lowres" mimetype="image/png" xl:href="http://img.kb.dk/..."/>
                            <extptr targettype="hires" mimetype="image/png" xl:href="http://img.kb.dk/..."/>
                        </p>
                        <score>
                            <app>
                                <rdg type="metadata">
                                    <scoreDef key.pname="e" key.accid="n" key.mode="major" meter.sym="common"/>
                                    <staff><layer><tempo>Andante - Pi? lento - Andante con moto</tempo></layer></staff>
                                </rdg>
                            </app>
                        </score>
                    </incip>
                </contentItem>
            </contents>
        </work>

As you can see, I have marked some questions in the example:


1)     Isn't the accid attribute missing in the definition of <key>? I only see @accid.ges.

2)     Some of the <performer> and <castItem> elements should be linked somehow to indicate that they refer to the same role. How?

3)     Would it be possible to allow more than one <head>, so that it could be used as headings for subsequent acts, for instance? Or am I doing something wrong? (Actually the piece in the example does not have any acts, I just included the heading for testing purposes)

4)     How do I indicate the relation between <contentItem> elements and their corresponding sections in <music>?

5)     Could <key> be available in <contentItem> to indicate key at movement level? Both for key and for tempo, I still need to define <scoreDef> and <staff> elements, don't I? As I want key and tempo to actually record information about the entire movement, not just the incipit, they should not be placed within the <incipit> at all, but rather directly under <contentItem>. And how about a <meter> element too? I would like to see <key>, <tempo> and perhaps <meter> to be available as children of both <work> and <contentItem> - or are there good reasons not to have them? There probably are :-) I am aware that "key" may refer both to an indication of key at some particular point in the score as well as the more abstract conception of key for an entire movement or piece. The same may not be true with meter, or at least not completely in the same sense. Tempo however, like key, may also indicate a change of tempo at some point or informing about the sequence of tempos in the piece ("Andante - Pi? lento - Andante con moto"). And since <key> _will_ be implemented in this "metadata" manner, I think it could would be acceptable to do the same with tempo and meter.

6)     Is there a more elegant way of linking to incipit graphic files than using <extptr> within a <p>?

Sorry for asking all these questions. But in case some of them may actually turn out to have any influence on the next release, I thought it would be all right to bother you with them now :-)

All the best,
Axel


[http://support.kb.dk/images/kb_logo.jpg]

Det Kongelige Bibliotek
Nationalbibliotek og K?benhavns Universitetsbibliotek

Axel Teich Geertinger
Forsker | Researcher

Det Kongelige Bibliotek | The Royal Library
Dansk Center for Musikudgivelse | Danish Centre for Music Publication
P.O. Box 2149 | DK-1016 K?benhavn K
tel +45 3347 4706 | Fax +45 3393 2218 | atge at kb.dk<mailto:atge at kb.dk> | www.kb.dk<http://www.kb.dk>

Bes?gsadresse | Visiting address | S?ren Kierkegaards Plads 1
Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 K?benhavn K

EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42
IBAN DK2002164069032583 | Swiftcode DABADKKK


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110811/60ba0480/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14433 bytes
Desc: image001.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110811/60ba0480/attachment.jpg>

From raffaeleviglianti at gmail.com  Mon Aug 22 18:03:17 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Mon, 22 Aug 2011 17:03:17 +0100
Subject: [MEI-L] Lessons from the turmoil in the TEI community
Message-ID: <CAMyHAnPpo62xwjx9AofdykrxQdSw6+jsvpqgyJa5HoLNqTdjog@mail.gmail.com>

Dear all,

As you may or may not know, the TEI has been going through some political
turmoil over the past two weeks. A political "incident" created some furore
in the community, which is now entering a phase of self-reflection on how
things work at the TEI consortium and on the standard itself. If you are not
following the events, I would invite you to do so because there can be some
important potential lessons to be learned so that MEI does not incur in
similar problems.
Discussion is happening mainly on TEI-L (archive:
http://listserv.brown.edu/archives/cgi-bin/wa?A0=tei-l ), though it started
on Twitter under the hashtag #teiputsch (now abandoned) and continues under
#teifuture.

I would like to bring your attention to the topic of interchange and
interoperability, which is being discussed in these days (this recent email
by David Birnbaum gives a good summary of the problem:
http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1108&L=tei-l&T=0&F=&S=&P=15117
).
What is surfacing is what I usually call "the pride and doom of the TEI",
that is the struggle between flexibility of encoding and interchange;
between encoding as art form and tool. In other words, the TEI offers many
different ways of encoding the same data, with often only subtle semantic
differences between the different methods. I think that this is a strong
value of TEI, as it makes it able to capture complex textual phenomena as
the encoder sees them. On the other hand, there clearly is the risk of
making TEI too much of a personal tool, thus isolating projects from one
another. Quite a few people commented strongly on this, saying that it
undermines the role of TEI for interchange and why should they bother using
it in the first place (I was rather surprised to hear this from long-time
users of TEI - just another indication that this problem has been lingering
for long).

As you know, MEI is a similar beast and, by design, there are alternative
encodings for the same phenomena. I believe that this is an essential
feature that should not be abandoned; however I'd like to bring the issue of
interchange to your attention. I am confident that it is an issue on top of
the agenda already, but the recent events at the TEI may call for a
revision, or confirmation, of our work in that sense. Investing in tools
like MEIron and libraries like pyMEI since the early stages is, in my
opinion, the best way to tackle this issue without loosing flexibility in
MEI. Another, perhaps less attractive, solution is to always specify which
of alternative encoding mechanisms is the one recommended for the majority
of cases.

Any thoughts?

Regards,
Raffaele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110822/7457e624/attachment.html>

From kepper at edirom.de  Mon Aug 22 20:28:35 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 22 Aug 2011 20:28:35 +0200
Subject: [MEI-L] Lessons from the turmoil in the TEI community
In-Reply-To: <CAMyHAnPpo62xwjx9AofdykrxQdSw6+jsvpqgyJa5HoLNqTdjog@mail.gmail.com>
References: <CAMyHAnPpo62xwjx9AofdykrxQdSw6+jsvpqgyJa5HoLNqTdjog@mail.gmail.com>
Message-ID: <BC1896D1-2FA5-4615-B03F-5C9305234535@edirom.de>

Hi Raffaele,

this discussion on TEI-L is indeed very interesting to follow, and I'm almost sure that the TEI will be something different after this incident. Regarding the situation for MEI, I think we're in a completely different position. In this context, MEI is much more straightforward than TEI. There are significantly less choices when building your encoding model ? you will not discuss whether to encode a note as <note> or something else like a <fermata>. Terminology is on our side here. It is true that MEI offers lots of choices, for instance regarding articulations. But are they semantically that different? Choosing attributes gives you a quick (but not necessarily dirty) solution. When using the <artic> element, you have to decide if you want to attach it to a timestamp / beat or a note, which admittedly is a semantic difference, but other than that, I would argue that all three solutions address the same issue. They allow a different level of complexity, but there is no semantic difference between them. In my opinion, all differences of this kind can be addressed by what we're calling MEIron*, so I guess MEI can claim to be ready for interchange of music notation, at least from the CMN period. 
Interoperability, as defined in those mails you cite, is surely a harder target to shoot at, but under certain conditions, I would say that MEI also solves that issue. I see bigger problems in MEI in those parts of the specification which are less strict defined / demand a higher level of modelling: The whole critapp and editorial modules are probably more project-specific, as is the header. For those areas, we will want to make sure to provide good documentation in the Guidelines, combined with a set of examples from our current projects as best-practice recommendations. 

All in all, I don't see the same problems in the schema that TEI currently discusses. From an MEI perspective, I would say we may learn more from the policital / organizational debate there. But that's just my rather unreflected first impression. I guess you're right that we all should follow this more closely and think about the consequences for MEI. 

Best,
Johannes





Am 22.08.2011 um 18:03 schrieb Raffaele Viglianti:

> Dear all,
> 
> As you may or may not know, the TEI has been going through some political turmoil over the past two weeks. A political "incident" created some furore in the community, which is now entering a phase of self-reflection on how things work at the TEI consortium and on the standard itself. If you are not following the events, I would invite you to do so because there can be some important potential lessons to be learned so that MEI does not incur in similar problems.
> Discussion is happening mainly on TEI-L (archive: http://listserv.brown.edu/archives/cgi-bin/wa?A0=tei-l ), though it started on Twitter under the hashtag #teiputsch (now abandoned) and continues under #teifuture.
> 
> I would like to bring your attention to the topic of interchange and interoperability, which is being discussed in these days (this recent email by David Birnbaum gives a good summary of the problem: http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1108&L=tei-l&T=0&F=&S=&P=15117 ). What is surfacing is what I usually call "the pride and doom of the TEI", that is the struggle between flexibility of encoding and interchange; between encoding as art form and tool. In other words, the TEI offers many different ways of encoding the same data, with often only subtle semantic differences between the different methods. I think that this is a strong value of TEI, as it makes it able to capture complex textual phenomena as the encoder sees them. On the other hand, there clearly is the risk of making TEI too much of a personal tool, thus isolating projects from one another. Quite a few people commented strongly on this, saying that it undermines the role of TEI for interchange and why should they bother using it in the first place (I was rather surprised to hear this from long-time users of TEI - just another indication that this problem has been lingering for long).
> 
> As you know, MEI is a similar beast and, by design, there are alternative encodings for the same phenomena. I believe that this is an essential feature that should not be abandoned; however I'd like to bring the issue of interchange to your attention. I am confident that it is an issue on top of the agenda already, but the recent events at the TEI may call for a revision, or confirmation, of our work in that sense. Investing in tools like MEIron and libraries like pyMEI since the early stages is, in my opinion, the best way to tackle this issue without loosing flexibility in MEI. Another, perhaps less attractive, solution is to always specify which of alternative encoding mechanisms is the one recommended for the majority of cases.
> 
> Any thoughts?
> 
> Regards,
> Raffaele
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From kepper at edirom.de  Mon Aug 29 10:41:03 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 29 Aug 2011 10:41:03 +0200
Subject: [MEI-L] order of elements
Message-ID: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>

Dear MEIers,

this is a somewhat technical question, but I guess of interest to nearly everyone who's producing MEI, either by hand or by software. The current schema of MEI enforces a certain order of child elements for large parts of the header. For instance, you may write 

<source>
	<titleStmt>?</titleStmt>
	<notesStmt>?</notesStmt>
	<relatedItem>?</relatedItem>
</source>

but not 

<source>	
	<notesStmt>?</notesStmt>
	<titleStmt>?</titleStmt>
	<relatedItem>?</relatedItem>
</source>

or any other order like

<source>
	<titleStmt>?</titleStmt>
	<relatedItem>?</relatedItem>
	<notesStmt>?</notesStmt>
</source>

This is somewhat cumbersome when adding header elements on the fly, as you always have to check for the correct place for insertion. This is surely a technical issue without any semantic reason behind, so I'm wondering if there is a way around that. Could someone with more experience in ODD and the other schema languages provide some more background on this? Raffaele?

Thanks,
Johannes

From pdr4h at eservices.virginia.edu  Mon Aug 29 16:43:41 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Mon, 29 Aug 2011 14:43:41 +0000
Subject: [MEI-L] order of elements
In-Reply-To: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D3C0B41@WILSON.eservices.virginia.edu>

Hi Johannes,

In all of the schema languages I'm aware of, if a group of sub-elements are unordered, then it's impossible to control their number.  Stated the other way around, if you want to control the number of sub-element occurrences, then you must also control for their order.

Using your <source> example, the following model (in "DTD speak" for brevity) --

<!ELEMENT source (identifier | titleStmt | editionStmt | pubStmt | physDesc | seriesStmt | notesStmt | langUsage | classification | relatedItem)* >

permits any order but also *any number*.

However, aside from <identifier> and <relatedItem>, which may occur 0 or more times, each of the children of <source> should only occur once, leading to --

<!ELEMENT source (identifer*, titleStmt?, editionStmt?, pubStmt?, physDesc?, seriesStmt?, notesStmt?, langUsage?, classification?, relatedItem*)>

So, for example, we can make sure there is only one publication statement and accept that the elements must be in order OR we can make the sub-elements unordered and live with the possibility that someone might use pubStmt multiple times.  I chose the first of these two options, thinking that the trouble it caused would be less than the headache caused by the second.

There are many other places in the schema where the "any number, any order" model is used.  We've often referred to this as the rope that users may hang themselves by.  We could adopt that policy here as well, BUT I believe the ordered model is best within the header because this is the area where users need the most guidance; that is, more restrictive models.  This choice is also similar to TEI practice, where <biblFull> (which holds bibliographic details within <sourceDesc>) follows the model --

titleStmt, editionStmt?, extent?, publicationStmt, seriesStmt?, notesStmt?

--
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 Johannes Kepper [kepper at edirom.de]
Sent: Monday, August 29, 2011 4:41 AM
To: Music Encoding Initiative
Subject: [MEI-L] order of elements

Dear MEIers,

this is a somewhat technical question, but I guess of interest to nearly everyone who's producing MEI, either by hand or by software. The current schema of MEI enforces a certain order of child elements for large parts of the header. For instance, you may write

<source>
        <titleStmt>?</titleStmt>
        <notesStmt>?</notesStmt>
        <relatedItem>?</relatedItem>
</source>

but not

<source>
        <notesStmt>?</notesStmt>
        <titleStmt>?</titleStmt>
        <relatedItem>?</relatedItem>
</source>

or any other order like

<source>
        <titleStmt>?</titleStmt>
        <relatedItem>?</relatedItem>
        <notesStmt>?</notesStmt>
</source>

This is somewhat cumbersome when adding header elements on the fly, as you always have to check for the correct place for insertion. This is surely a technical issue without any semantic reason behind, so I'm wondering if there is a way around that. Could someone with more experience in ODD and the other schema languages provide some more background on this? Raffaele?

Thanks,
Johannes
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

From pdr4h at eservices.virginia.edu  Mon Aug 29 16:47:31 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Mon, 29 Aug 2011 14:47:31 +0000
Subject: [MEI-L] order of elements
In-Reply-To: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D3C1B60@WILSON.eservices.virginia.edu>

Hi Johannes,

In all of the schema languages I'm aware of, if a group of sub-elements are unordered, then it's impossible to control their number.  Stated the other way around, if you want to control the number of sub-element occurrences, then you must also control for their order.
Using your <source> example, the following model (in "DTD speak" for brevity) --

<!ELEMENT source (identifier | titleStmt | editionStmt | pubStmt | physDesc | seriesStmt | notesStmt | langUsage | classification | relatedItem)* >

permits any order but also *any number*.

However, aside from <identifier> and <relatedItem>, which may occur 0 or more times, each of the children of <source> should only occur once, leading to --

<!ELEMENT source (identifer*, titleStmt?, editionStmt?, pubStmt?, physDesc?, seriesStmt?, notesStmt?, langUsage?, classification?, relatedItem*)>

So, for example, we can make sure there is only one publication statement and accept that the elements must be in order OR we can make the sub-elements unordered and live with the possibility that someone might use pubStmt multiple times.  I chose the first of these two options, thinking that the trouble it caused would be less than the headache caused by the second.

There are many other places in the schema where the "any number, any order" model is used.  We've often referred to this as the rope that users may hang themselves by.  We could adopt that policy here as well, BUT I believe the ordered model is best within the header because this is the area where users need the most guidance; that is, more restrictive models.  This choice is also similar to TEI practice, where <biblFull> (which holds bibliographic details within <sourceDesc>) follows the model --

titleStmt, editionStmt?, extent?, publicationStmt, seriesStmt?, notesStmt?

--
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 Johannes Kepper [kepper at edirom.de]
Sent: Monday, August 29, 2011 4:41 AM
To: Music Encoding Initiative
Subject: [MEI-L] order of elements

Dear MEIers,

this is a somewhat technical question, but I guess of interest to nearly everyone who's producing MEI, either by hand or by software. The current schema of MEI enforces a certain order of child elements for large parts of the header. For instance, you may write

<source>
        <titleStmt>?</titleStmt>
        <notesStmt>?</notesStmt>
        <relatedItem>?</relatedItem>
</source>

but not

<source>
        <notesStmt>?</notesStmt>
        <titleStmt>?</titleStmt>
        <relatedItem>?</relatedItem>
</source>

or any other order like

<source>
        <titleStmt>?</titleStmt>
        <relatedItem>?</relatedItem>
        <notesStmt>?</notesStmt>
</source>

This is somewhat cumbersome when adding header elements on the fly, as you always have to check for the correct place for insertion. This is surely a technical issue without any semantic reason behind, so I'm wondering if there is a way around that. Could someone with more experience in ODD and the other schema languages provide some more background on this? Raffaele?

Thanks,
Johannes
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

From pdr4h at eservices.virginia.edu  Mon Aug 29 17:10:30 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Mon, 29 Aug 2011 15:10:30 +0000
Subject: [MEI-L] <work> metadata questions
In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D117B93B8C@EXCHANGE-02.kb.dk>
References: <0B6F63F59F405E4C902DFE2C2329D0D117B93B8C@EXCHANGE-02.kb.dk>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D3C2B81@WILSON.eservices.virginia.edu>

Hi Axel,



Thanks for testing this out and providing feedback. It's a huge help.



I don't think you should ever have to use <scoredef> to record metadata so I'll make additions to the descriptive elements allowed in <source>, <relatedItem> and <work>.  I'll also try to clarify the relationships between <castList> and <perfMedium> and between <contents> and <relatedItem>, and tweak <incip> a bit to make it, as you say, "more elegant".



I think these changes are minor and can be accomplished for the next release. I'm working on something else right now, but I should be able to get something out for testing in the next couple of weeks.



--

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 Axel Teich Geertinger [atge at kb.dk]
Sent: Thursday, August 11, 2011 5:32 AM
To: Music Encoding Initiative
Subject: [MEI-L] <work> metadata questions

Hi Perry & all

I am trying to translate our existing metadata model to the new MEI header elements within <workDesc>. Huge improvements, thank you!!
Still, however, I cannot figure out how to completely avoid using <score> for some metadata, especially when getting down to movement level. And I have some other questions too (see below).

This is a first shot at outlining the first movements of a piece for orchestra, chorus and vocal soloists:

        <work>
            <key pname="a" mode="minor"/> <!-- @accid missing? Only @accid.ges seems to be available -->
            <perfMedium>
                <ensemble>
                    <instrVoice>Orchestra</instrVoice>
                </ensemble>
                <ensemble>
                    <instrVoice>Choir SSATTBB</instrVoice>
                </ensemble>
                <performer> <!-- How does <perfomer> relate to <castItem>? -->
                    <instrVoice>S</instrVoice>
                    <role>Comala</role>
                </performer>
                <performer>
                    <instrVoice>Bar</instrVoice>
                    <role>Fingal</role>
                </performer>
            </perfMedium>
            <castList>
                <castItem>
                    <role>Comala</role>
                    <roleDesc xml:lang="de">Fingals Geliebte</roleDesc>
                    <roleDesc xml:lang="da">Fingals elskede</roleDesc>
                </castItem>
                <castItem>
                    <role>Fingal</role>
                    <roleDesc xml:lang="de">K?nig von Morwen</roleDesc>
                    <roleDesc xml:lang="da">Konge af Morven</roleDesc>
                </castItem>
            </castList>
            <contents>
                <head>
                    <title xml:lang="de">Akt 1</title>
                    <title xml:lang="da">Akt 1</title>
                </head> <!-- Only one <head> allowed, i.e. no way to add "Akt 2" heading, etc.? -->
                <contentItem> <!-- How are these items linked to their respective elements in <music>? Using @analog? -->
                    <title xml:lang="de">No. 1. Chor der Krieger und Barden [TTBB]</title>
                    <title xml:lang="da">No. 1. Fingals Krigere</title>
                    <!-- No way to use <key> and <tempo> anywhere here? -->
                    <!-- And how about a <meter> element? -->
                    <incip>
                        <p xml:lang="de">Auf, auf, auf, laut schallt das Horn</p>
                        <p xml:lang="da">Frem, frem, frem, fremad til Kamp</p>
                        <p label="graphics"> <!-- container for links to incipit graphics -->
                            <extptr targettype="lowres" mimetype="image/png" xl:href="http://img.kb.dk/..."/>
                            <extptr targettype="hires" mimetype="image/png" xl:href="http://img.kb.dk/..."/>
                        </p>
                        <score>
                            <app>
                                <rdg type="metadata">
                                    <!-- Declared in a "metadata" reading in order to avoid conflict with an actual encoding of the incipit -->
                                    <scoreDef key.pname="a" key.accid="n" key.mode="minor" meter.sym="common"/> <!-- key and meter at movement level -->
                                    <staff><layer><tempo>Andante ? Allegro non troppo</tempo></layer></staff> <!-- tempo indications in this movement -->
                                </rdg>
                            </app>
                        </score>
                    </incip>
                </contentItem>
                <contentItem>
                    <title xml:lang="de">No. 2 [Comala, Fingal]</title>
                    <title xml:lang="da">No. 2 [Comala, Fingal]</title>
                    <incip>
                        <p xml:lang="de">Heute noch brech' ich des stolzen K?nigs Macht</p>
                        <p xml:lang="da">Alt i Kv?ld slaar jeg den stolte Konges H?r</p>
                        <p label="graphics">
                            <extptr targettype="lowres" mimetype="image/png" xl:href="http://img.kb.dk/..."/>
                            <extptr targettype="hires" mimetype="image/png" xl:href="http://img.kb.dk/..."/>
                        </p>
                        <score>
                            <app>
                                <rdg type="metadata">
                                    <scoreDef key.pname="e" key.accid="n" key.mode="major" meter.sym="common"/>
                                    <staff><layer><tempo>Andante ? Pi? lento ? Andante con moto</tempo></layer></staff>
                                </rdg>
                            </app>
                        </score>
                    </incip>
                </contentItem>
            </contents>
        </work>

As you can see, I have marked some questions in the example:


1)     Isn?t the accid attribute missing in the definition of <key>? I only see @accid.ges.

2)     Some of the <performer> and <castItem> elements should be linked somehow to indicate that they refer to the same role. How?

3)     Would it be possible to allow more than one <head>, so that it could be used as headings for subsequent acts, for instance? Or am I doing something wrong? (Actually the piece in the example does not have any acts, I just included the heading for testing purposes)

4)     How do I indicate the relation between <contentItem> elements and their corresponding sections in <music>?

5)     Could <key> be available in <contentItem> to indicate key at movement level? Both for key and for tempo, I still need to define <scoreDef> and <staff> elements, don?t I? As I want key and tempo to actually record information about the entire movement, not just the incipit, they should not be placed within the <incipit> at all, but rather directly under <contentItem>. And how about a <meter> element too? I would like to see <key>, <tempo> and perhaps <meter> to be available as children of both <work> and <contentItem> - or are there good reasons not to have them? There probably are :-) I am aware that ?key? may refer both to an indication of key at some particular point in the score as well as the more abstract conception of key for an entire movement or piece. The same may not be true with meter, or at least not completely in the same sense. Tempo however, like key, may also indicate a change of tempo at some point or informing about the sequence of tempos in the piece (?Andante ? Pi? lento ? Andante con moto?). And since <key> _will_ be implemented in this ?metadata? manner, I think it could would be acceptable to do the same with tempo and meter.

6)     Is there a more elegant way of linking to incipit graphic files than using <extptr> within a <p>?

Sorry for asking all these questions. But in case some of them may actually turn out to have any influence on the next release, I thought it would be all right to bother you with them now :-)

All the best,
Axel


[http://support.kb.dk/images/kb_logo.jpg]

Det Kongelige Bibliotek
Nationalbibliotek og K?benhavns Universitetsbibliotek

Axel Teich Geertinger
Forsker | Researcher

Det Kongelige Bibliotek | The Royal Library
Dansk Center for Musikudgivelse | Danish Centre for Music Publication
P.O. Box 2149 | DK-1016 K?benhavn K
tel +45 3347 4706 | Fax +45 3393 2218 | atge at kb.dk<mailto:atge at kb.dk> | www.kb.dk<http://www.kb.dk>

Bes?gsadresse | Visiting address | S?ren Kierkegaards Plads 1
Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 K?benhavn K

EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42
IBAN DK2002164069032583 | Swiftcode DABADKKK


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110829/dbc7703c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14433 bytes
Desc: image001.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110829/dbc7703c/attachment.jpg>

From veit at weber-gesamtausgabe.de  Mon Aug 29 22:47:16 2011
From: veit at weber-gesamtausgabe.de (Joachim Veit)
Date: Mon, 29 Aug 2011 22:47:16 +0200
Subject: [MEI-L] order of elements
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D3C1B60@WILSON.eservices.virginia.edu>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
	<BBCC497C40D85642B90E9F94FC30343D3C1B60@WILSON.eservices.virginia.edu>
Message-ID: <4E5BFAD4.4070600@weber-gesamtausgabe.de>

Hi Perry,
thanks for your explicit answer! For my part, I fully consent with your 
proposal (at least 98,9 %...): There is no real advantage for a user 
having the possibility of ordering elements in the header in this way or 
the next three ways in the next two projects .... But perhaps this leads 
to processing efforts which are really unnecessary.
I prefer to have a guidance in putting down my metadata and I am always 
happy when I am (only after several daily examples) familiar with the 
given order in the TEI header - because I don't have to think about: 
which details I have forgotten / what is the best element to join next 
etc...
So I plead for the DTD-order with comma und only beg you to think about 
some more asterisks, if repetitions of data really occur. But I am a bit 
uncertain where this might be the case - notesStmt??
Best greetings, I hope that Charlottesville had no problems with the storm!?
Joachim


Am 29.08.11 16:47, schrieb Roland, Perry (pdr4h):
> Hi Johannes,
>
> In all of the schema languages I'm aware of, if a group of sub-elements are unordered, then it's impossible to control their number.  Stated the other way around, if you want to control the number of sub-element occurrences, then you must also control for their order.
> Using your<source>  example, the following model (in "DTD speak" for brevity) --
>
> <!ELEMENT source (identifier | titleStmt | editionStmt | pubStmt | physDesc | seriesStmt | notesStmt | langUsage | classification | relatedItem)*>
>
> permits any order but also *any number*.
>
> However, aside from<identifier>  and<relatedItem>, which may occur 0 or more times, each of the children of<source>  should only occur once, leading to --
>
> <!ELEMENT source (identifer*, titleStmt?, editionStmt?, pubStmt?, physDesc?, seriesStmt?, notesStmt?, langUsage?, classification?, relatedItem*)>
>
> So, for example, we can make sure there is only one publication statement and accept that the elements must be in order OR we can make the sub-elements unordered and live with the possibility that someone might use pubStmt multiple times.  I chose the first of these two options, thinking that the trouble it caused would be less than the headache caused by the second.
>
> There are many other places in the schema where the "any number, any order" model is used.  We've often referred to this as the rope that users may hang themselves by.  We could adopt that policy here as well, BUT I believe the ordered model is best within the header because this is the area where users need the most guidance; that is, more restrictive models.  This choice is also similar to TEI practice, where<biblFull>  (which holds bibliographic details within<sourceDesc>) follows the model --
>
> titleStmt, editionStmt?, extent?, publicationStmt, seriesStmt?, notesStmt?
>
> --
> 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 Johannes Kepper [kepper at edirom.de]
> Sent: Monday, August 29, 2011 4:41 AM
> To: Music Encoding Initiative
> Subject: [MEI-L] order of elements
>
> Dear MEIers,
>
> this is a somewhat technical question, but I guess of interest to nearly everyone who's producing MEI, either by hand or by software. The current schema of MEI enforces a certain order of child elements for large parts of the header. For instance, you may write
>
> <source>
>          <titleStmt>?</titleStmt>
>          <notesStmt>?</notesStmt>
>          <relatedItem>?</relatedItem>
> </source>
>
> but not
>
> <source>
>          <notesStmt>?</notesStmt>
>          <titleStmt>?</titleStmt>
>          <relatedItem>?</relatedItem>
> </source>
>
> or any other order like
>
> <source>
>          <titleStmt>?</titleStmt>
>          <relatedItem>?</relatedItem>
>          <notesStmt>?</notesStmt>
> </source>
>
> This is somewhat cumbersome when adding header elements on the fly, as you always have to check for the correct place for insertion. This is surely a technical issue without any semantic reason behind, so I'm wondering if there is a way around that. Could someone with more experience in ODD and the other schema languages provide some more background on this? Raffaele?
>
> Thanks,
> Johannes
> _______________________________________________
> 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

-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : veit.vcf
Dateityp    : text/x-vcard
Dateigr??e  : 364 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110829/6884d359/attachment.vcf>

From pdr4h at eservices.virginia.edu  Tue Aug 30 00:00:20 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Mon, 29 Aug 2011 22:00:20 +0000
Subject: [MEI-L] order of elements
In-Reply-To: <4E5BFAD4.4070600@weber-gesamtausgabe.de>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
	<BBCC497C40D85642B90E9F94FC30343D3C1B60@WILSON.eservices.virginia.edu>,
	<4E5BFAD4.4070600@weber-gesamtausgabe.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D3C3C39@WILSON.eservices.virginia.edu>


Hi Joachim,

Thanks for the vote of confidence.  No allusion to recent events intended!  :)

It's not immediately obvious, but repetition of certain elements is handled one more level down from where we're talking about now.  For example, multiple <annot> elements are allowed within <notesStmt> and multiple <title> elements are allowed in <titleStmt>.  In other words, <notesStmt> functions as a grouping mechanism for multiple <annot> elements, so <notesStmt> only occurs once.  I suppose one could argue for allowing multiple occurrences of <notesStmt> in order to arrange similar annotations in each group.  However, since this kind of grouping can be accomplished using @type on each <annot> element, there's no need to introduce a second method of grouping.

I'm interested to find out the effects of the hurrican on C'ville myself as I'm currently in central Tennessee, nearly 1000 miles away!

--
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 Joachim Veit [veit at weber-gesamtausgabe.de]
Sent: Monday, August 29, 2011 4:47 PM
To: mei-l at lists.uni-paderborn.de
Subject: Re: [MEI-L] order of elements

Hi Perry,
thanks for your explicit answer! For my part, I fully consent with your
proposal (at least 98,9 %...): There is no real advantage for a user
having the possibility of ordering elements in the header in this way or
the next three ways in the next two projects .... But perhaps this leads
to processing efforts which are really unnecessary.
I prefer to have a guidance in putting down my metadata and I am always
happy when I am (only after several daily examples) familiar with the
given order in the TEI header - because I don't have to think about:
which details I have forgotten / what is the best element to join next
etc...
So I plead for the DTD-order with comma und only beg you to think about
some more asterisks, if repetitions of data really occur. But I am a bit
uncertain where this might be the case - notesStmt??
Best greetings, I hope that Charlottesville had no problems with the storm!?
Joachim


Am 29.08.11 16:47, schrieb Roland, Perry (pdr4h):
> Hi Johannes,
>
> In all of the schema languages I'm aware of, if a group of sub-elements are unordered, then it's impossible to control their number.  Stated the other way around, if you want to control the number of sub-element occurrences, then you must also control for their order.
> Using your<source>  example, the following model (in "DTD speak" for brevity) --
>
> <!ELEMENT source (identifier | titleStmt | editionStmt | pubStmt | physDesc | seriesStmt | notesStmt | langUsage | classification | relatedItem)*>
>
> permits any order but also *any number*.
>
> However, aside from<identifier>  and<relatedItem>, which may occur 0 or more times, each of the children of<source>  should only occur once, leading to --
>
> <!ELEMENT source (identifer*, titleStmt?, editionStmt?, pubStmt?, physDesc?, seriesStmt?, notesStmt?, langUsage?, classification?, relatedItem*)>
>
> So, for example, we can make sure there is only one publication statement and accept that the elements must be in order OR we can make the sub-elements unordered and live with the possibility that someone might use pubStmt multiple times.  I chose the first of these two options, thinking that the trouble it caused would be less than the headache caused by the second.
>
> There are many other places in the schema where the "any number, any order" model is used.  We've often referred to this as the rope that users may hang themselves by.  We could adopt that policy here as well, BUT I believe the ordered model is best within the header because this is the area where users need the most guidance; that is, more restrictive models.  This choice is also similar to TEI practice, where<biblFull>  (which holds bibliographic details within<sourceDesc>) follows the model --
>
> titleStmt, editionStmt?, extent?, publicationStmt, seriesStmt?, notesStmt?
>
> --
> 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 Johannes Kepper [kepper at edirom.de]
> Sent: Monday, August 29, 2011 4:41 AM
> To: Music Encoding Initiative
> Subject: [MEI-L] order of elements
>
> Dear MEIers,
>
> this is a somewhat technical question, but I guess of interest to nearly everyone who's producing MEI, either by hand or by software. The current schema of MEI enforces a certain order of child elements for large parts of the header. For instance, you may write
>
> <source>
>          <titleStmt>?</titleStmt>
>          <notesStmt>?</notesStmt>
>          <relatedItem>?</relatedItem>
> </source>
>
> but not
>
> <source>
>          <notesStmt>?</notesStmt>
>          <titleStmt>?</titleStmt>
>          <relatedItem>?</relatedItem>
> </source>
>
> or any other order like
>
> <source>
>          <titleStmt>?</titleStmt>
>          <relatedItem>?</relatedItem>
>          <notesStmt>?</notesStmt>
> </source>
>
> This is somewhat cumbersome when adding header elements on the fly, as you always have to check for the correct place for insertion. This is surely a technical issue without any semantic reason behind, so I'm wondering if there is a way around that. Could someone with more experience in ODD and the other schema languages provide some more background on this? Raffaele?
>
> Thanks,
> Johannes
> _______________________________________________
> 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

From christof.schoech at uni-wuerzburg.de  Wed Aug 31 17:53:37 2011
From: christof.schoech at uni-wuerzburg.de (=?UTF-8?Q?Christof_Sch=C3=B6ch?=)
Date: Wed, 31 Aug 2011 17:53:37 +0200
Subject: [MEI-L] Compatibility and roadmap
Message-ID: <CABsQSYQg9VSRZsKTyTARtWNfeMTof27nQxwdPEpU9QG=eJ_3pw@mail.gmail.com>

Dear MEI-List,

I'm entirely new to the MEI and this list, but am interested in MEI as
someone working with TEI in the DARIAH project in Germany, a project in
which some music scholars from Detmold are also involved. In recent
discussions about MEI, two questions have come up for which we did not
really find a good answer:

1. We suppose there is some experience with compatibility and transformation
of MEI to/from MusicXML, but is this also true for MEI to/from TEI, or to
which extent does this seem feasible?

2. Is there a roadmap for MEI development? Some people in DARIAH are
beginning to work on a Metadata Crosswalk and would like to include MEI in
this, but we would obviously need a somewhat stable version at least of the
"meiHead" for this to make sense.

Any cues on these issues would be very welcome!
Best,
Christof

---
http://www.kurzlink.de/schoech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110831/06f5f419/attachment.html>

From kepper at edirom.de  Wed Aug 31 21:44:32 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Wed, 31 Aug 2011 21:44:32 +0200
Subject: [MEI-L] Compatibility and roadmap
In-Reply-To: <CABsQSYQg9VSRZsKTyTARtWNfeMTof27nQxwdPEpU9QG=eJ_3pw@mail.gmail.com>
References: <CABsQSYQg9VSRZsKTyTARtWNfeMTof27nQxwdPEpU9QG=eJ_3pw@mail.gmail.com>
Message-ID: <436E08B0-F5F1-44EB-A896-57AB53CF864C@edirom.de>

Dear Christopf,

welcome to the list. 

> Dear MEI-List, 
> 
> I'm entirely new to the MEI and this list, but am interested in MEI as someone working with TEI in the DARIAH project in Germany, a project in which some music scholars from Detmold are also involved. In recent discussions about MEI, two questions have come up for which we did not really find a good answer: 
> 
> 1. We suppose there is some experience with compatibility and transformation of MEI to/from MusicXML, but is this also true for MEI to/from TEI, or to which extent does this seem feasible?

MusicXML can be transformed into MEI (though I'm not sure if the XSLT already covers the freshly released MusicXML 3.0 and the current state of MEI). As of yet, there is no way back to MusicXML, as MEI offers a couple of features not covered by MusicXML. For instance, MEI offers ways to encode ambiguity and multiple versions of a piece of music, whereas MusicXML is suited only for "linear" musical texts. We're already planning some tools to "flatten" an MEI file into something that can be converted to MusicXML (or any other format). The first part of this is certainly more tricky than the second. But in any case, you will loose information when converting from MEI to something else. MEI is certainly the format that allows the most verbose encoding of notational features.
A conversion to or from TEI makes no sense in my opinion. MEI is for musical documents, TEI is for textual documents. There are situations where you're facing a mixture of both kinds of  text, in which case you will want to include MEI in TEI (or vice versa). Together with the TEI SIG Music, the MEI community has proposed a model for this, and it seems that it will be incorporated into the next release of TEI P5 (see http://www.tei-c.org/SIG/Music/twm/index.html). This proposal also includes the possibility to use a TEI header together with an MEI body. When comparing the headers of TEI and MEI you will notice a couple of differences, most of which are justified by the different content models of TEI and MEI (a TEI header certainly needs no incipit element?). 

>  
> 2. Is there a roadmap for MEI development? Some people in DARIAH are beginning to work on a Metadata Crosswalk and would like to include MEI in this, but we would obviously need a somewhat stable version at least of the "meiHead" for this to make sense. 
> 

I know that the MEI website is somewhat outdated (which we hope to address rather soon). last year, we published a first stable version of MEI called 2010-05, which is available on the website. We're currently working on the next release, which will hopefully be available late this year, but maybe not before early next year. This release will bring MEI closer to TEI P5. Most changes to 2010-05 deal with the header, whereas the encoding of music does not change significantly. Most of the work necessary for the next release has to do with accompanying Guidelines etc., whereas the schema itself is already quite mature. We already announced a feature freeze, but some minor changes might still make it into the next release eventually. You will find the current ODD development version of the schema at http://code.google.com/p/music-encoding/source/browse/#svn%2Fbranches%2FMEI_2011_dev. 




> Any cues on these issues would be very welcome!
> Best, 
> Christof 
> 

I hope this gives you a good start on MEI. If you have any further questions on this or other issues, I'm sure that the list is happy to help you where possible. 

Best regards,
Johannes




> ---
> http://www.kurzlink.de/schoech
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l





From veit at weber-gesamtausgabe.de  Fri Sep  2 21:43:40 2011
From: veit at weber-gesamtausgabe.de (Joachim Veit)
Date: Fri, 02 Sep 2011 21:43:40 +0200
Subject: [MEI-L] Colla parte
In-Reply-To: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
Message-ID: <4E6131EC.1060508@weber-gesamtausgabe.de>

Dear MEI-L-Readers,

when encoding manuscripts MEI has the possibility to encode 
measure-repeats or half-measure-repeats which are found in the original 
manuscripts in a form similar to: // or .//.  (two strokes through the 
barlines or something similar) with <mrpt> or <halfmrpt>. This has 
always a clear reference to the bar (or half-bar) before.

The same symbols are used in manuscripts in combination with the "col 
Basso" or other "colla-parte"-instructions.
Again in Weber's Freischuetz-Overture (we never do something other...) 
we have a contrabbasso with <staff n="16"> and above this the 
violoncello with <staff n="15>. Weber notates the contrabbasso in a 
normal way and in the cello-staff we find only "c. B." (= bar 1) and 
afterwards //   //    // etc.
For a modern edition we could label the layer of the contrabbasso with 
an xml:id="2011" and put in the layer of staff 15: <layer n="1" 
copyof="2011"/>.

But in this case we want to encode the "original" situation! So we first 
have to define in the scoredef:
<scoredef>....
<symboltable>
<symboldef xml:id="symCollaParte"/> <!-- here we describe the symbol(s) 
Weber and others use in this case -->
</symboltable>
</scoredef>

and within our staff 15:
<staff n="15">
<layer n="1">
<symbol ref="symCollaParte"/>
</layer>
</staff>
In this case the reference is not always clear: it might go to the staff 
below (as in this case) or the staff above (if the cello is written out 
and the cb-staff is pointing to the cello) or even from a flute to the 
first violin 5 systems below. So there should be some mechanism to make 
clear where the model is situated. And second: We should have the 
possibility to use "c. B." (or something similar) as a symbol-phrase 
(which at the same time "defines" the model) and for the following bars 
simply use "//" (or something similar) (maybe even one symbol for 2-3 
bars together??).
Is this case already considered in the future guidelines?

Best greetings and a happy weekend,
Joachim


-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : veit.vcf
Dateityp    : text/x-vcard
Dateigr??e  : 364 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110902/e337bd4f/attachment.vcf>

From pdr4h at eservices.virginia.edu  Sat Sep  3 00:58:15 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Fri, 2 Sep 2011 22:58:15 +0000
Subject: [MEI-L] Colla parte
In-Reply-To: <4E6131EC.1060508@weber-gesamtausgabe.de>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>,
	<4E6131EC.1060508@weber-gesamtausgabe.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D74F84C@GRANT.eservices.virginia.edu>

Hi Joachim,

Let me re-state the issue to see if I understand it correctly --

1. Weber (is there any other composer worth talking about?) draws some version of a slash-symbol-thing to indicate that the current measure should be filled in with material from another instrument.

2. You want to record the original version (with the slash symbol) and give its "expansion" (as it were)?

First, are you sure this problem can't be resolved using <orig> and <supplied> (or perhaps <reg>)?  For example, each measure of the flute part might be encoded --

<measure>
  <staff n="1">
    <layer>
      <choice>
        <orig> <!-- some repetition sign(s) here --> </orig>
        <supplied> <!-- a copy of the content of the vln. part --> </supplied>
      </choice>
    </layer>
  </staff>
<dir staff="1" tstamp="1">colla parte ...</dir>
<!-- instead of the words there might be a <line> -->
</measure>

This seems like a good solution to me because it is explict.

I'm using <supplied> because the actual substitution doesn't take place in the score, there's only an indication that it "ought" to happen. Actually making it happen is up to the editor -- the human being, not the software.

Of course, what's missing is a link between the <supplied> element and the words "colla ..." (or a "wiggly" line), which I presume is in the flute part). At present, the editorial intervention can only be explained in the editorialDecl.  But, if we put our heads together, we might be able to think of another method of linking these.  (Perhaps with an <annotation>, which has pointers to the "participants"; that is, the <supplied> and <dir> elements, and a type attribute value of "collaparte"?)

I don't know if you remember, but MEI originally had a different definition for <mRpt>.  It didn't necessarily indicate the repetition of the preceding measure, but rather the repetition *of any other measure*, "repetition" being defined somewhat loosely, of course.  This definition went the way of the dodo bird when the editorial elements (add, del, orig, reg, etc.) were added since the attribute (don't remember what it was called off the top of my head) pointing to the source measure duplicated these editorial elements' function.

However, I recognize that there's currently no good way of implementing a reference to content given elsewhere in the document.  So, perhaps we should consider adding such a specialized element.  In the example above, the content of <supplied> would be the <colla> (or some such name) element.

<measure n="1">
  <staff>
    <layer>
      <choice>
        <orig> <!-- some repetition sign(s) here --> </orig>
        <supplied> <colla/> </supplied>
      </choice>
    </layer>
  </staff>
</measure>

Of course, it would need an attribute pointing to the content of the vln. part.  In a way, this element would be similar to <ref>, although  <ref> is intended for navigation, while <colla> indicates "go get the content and put it here."  This is also not unlike internal parsed entities. This element would also need to be related to the <dir> or <line> elements. We could think about using its generic corresp attribute or give it a new, specialized attribute.

(I can already hear some noises in the back of the room about some attribute or attributes for describing whatever transformation must be applied to the source, such as "transposed up a 5th", "inverted and retrograde", etc.  I'm not ready to go there yet!  There be dragons!)

It might also need a more generic name than "colla".  Then it could be used for other situations where content given in one location needs to be referenced in some other.  Can't think of a good name off the top of my head, too late in the day.

Just in case someone asks, I don't think XInclude can point to a location in the current document.

Enough to think about for the weekend?  :)

--
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 Joachim Veit [veit at weber-gesamtausgabe.de]
Sent: Friday, September 02, 2011 3:43 PM
To: mei-l at lists.uni-paderborn.de
Subject: [MEI-L] Colla parte

Dear MEI-L-Readers,

when encoding manuscripts MEI has the possibility to encode
measure-repeats or half-measure-repeats which are found in the original
manuscripts in a form similar to: // or .//.  (two strokes through the
barlines or something similar) with <mrpt> or <halfmrpt>. This has
always a clear reference to the bar (or half-bar) before.

The same symbols are used in manuscripts in combination with the "col
Basso" or other "colla-parte"-instructions.
Again in Weber's Freischuetz-Overture (we never do something other...)
we have a contrabbasso with <staff n="16"> and above this the
violoncello with <staff n="15>. Weber notates the contrabbasso in a
normal way and in the cello-staff we find only "c. B." (= bar 1) and
afterwards //   //    // etc.
For a modern edition we could label the layer of the contrabbasso with
an xml:id="2011" and put in the layer of staff 15: <layer n="1"
copyof="2011"/>.

But in this case we want to encode the "original" situation! So we first
have to define in the scoredef:
<scoredef>....
<symboltable>
<symboldef xml:id="symCollaParte"/> <!-- here we describe the symbol(s)
Weber and others use in this case -->
</symboltable>
</scoredef>

and within our staff 15:
<staff n="15">
<layer n="1">
<symbol ref="symCollaParte"/>
</layer>
</staff>
In this case the reference is not always clear: it might go to the staff
below (as in this case) or the staff above (if the cello is written out
and the cb-staff is pointing to the cello) or even from a flute to the
first violin 5 systems below. So there should be some mechanism to make
clear where the model is situated. And second: We should have the
possibility to use "c. B." (or something similar) as a symbol-phrase
(which at the same time "defines" the model) and for the following bars
simply use "//" (or something similar) (maybe even one symbol for 2-3
bars together??).
Is this case already considered in the future guidelines?

Best greetings and a happy weekend,
Joachim

From esfield at stanford.edu  Sat Sep  3 01:38:42 2011
From: esfield at stanford.edu (Eleanor Selfridge-Field)
Date: Fri, 2 Sep 2011 16:38:42 -0700 (PDT)
Subject: [MEI-L] half-measure repeats; Colla parte
Message-ID: <00be01cc69c9$48e9b300$dabd1900$@stanford.edu>

Dear Joachim, Perry, et al.,

In our experience with other composers, it is best not to predict how much
of a measure/measures a repeat will pertain to. We too try to encode
exactly what is in the visual source, reserving alterations for separate
"edition" files. 

In slightly earlier music, the "da capo" starting point (that is, the
point to which one returns from later in the movement) can be affected by
the metrical position of the main material, but it can also be influenced
by individual scribal and/or print styles. If, for example, the first note
of the original is a pick-up beat, the "da capo point" will in some cases
be at the first note, in others at the first barline, and in still others
elsewhere in the movement. That usually depends on whether there is
another section after the second repeat (which in turn often allows for
divergent numbers of beats in first endings). 

Too often, This all becomes a case of circular logic: if the first ending
consists of a complete measure, and the opening of the movement begins on
a downbeat, there is no problem. But that seems to be more the exception
than the usual situation. 

Half-measure repeats, on the other hand, may give a foretaste of some of
the notations that may occur as one moves into the late nineteenth and
early twentieth centuries. Perhaps there are repertories where a
systematic approach on this particular point will work. 

"<supplied>" retains some flexibility. Does MEI preclude the discrete use
of both?

==

"colla parte" seems straightforward as an annotation, but in the
realization phase, there can be choices, ambiguity, and uncertainty. In
the case of Vivaldi manuscripts, for example, "colla parte" found
simultaneously in second violin, viola, and sometimes violoncello parts
can mean "play notes with the same pitch names in whatever range [octave]
suits your instrument." Equally common are passages with a single violin
part and blank staves for second violin, viola, and cello/basso continuo.
This does not necessarily mean that colla parte realization is intended to
ALL the parts, but [to judge from fully scripted works] it is likely that
one or more of them should be providing some kind of accompaniment to the
violin. 

To interface these situations to MEI may only require a clear
differentiation of source-content from modern interpretation, but it is
important to realize that these kinds of passages can go on for entire
movements and can occur an every movement of the work, so there is no
incontrovertible clue to exactly what the composer had in mind for this
work.



Eleanor


Eleanor Selfridge-Field
Consulting Professor
Stanford University
Stanford, CA 94305-3076, USA
http://www.stanford.edu/~esfield/
http://www.ccarh.org







-----Original Message-----
From: mei-l-bounces at lists.uni-paderborn.de
[mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Joachim Veit
Sent: Friday, September 02, 2011 12:44 PM
To: mei-l at lists.uni-paderborn.de
Subject: [MEI-L] Colla parte

Dear MEI-L-Readers,

when encoding manuscripts MEI has the possibility to encode
measure-repeats or half-measure-repeats which are found in the original
manuscripts in a form similar to: // or .//.  (two strokes through the
barlines or something similar) with <mrpt> or <halfmrpt>. This has always
a clear reference to the bar (or half-bar) before.

The same symbols are used in manuscripts in combination with the "col
Basso" or other "colla-parte"-instructions.
Again in Weber's Freischuetz-Overture (we never do something other...) we
have a contrabbasso with <staff n="16"> and above this the violoncello
with <staff n="15>. Weber notates the contrabbasso in a normal way and in
the cello-staff we find only "c. B." (= bar 1) and 
afterwards //   //    // etc.
For a modern edition we could label the layer of the contrabbasso with an
xml:id="2011" and put in the layer of staff 15: <layer n="1" 
copyof="2011"/>.

But in this case we want to encode the "original" situation! So we first
have to define in the scoredef:
<scoredef>....
<symboltable>
<symboldef xml:id="symCollaParte"/> <!-- here we describe the symbol(s)
Weber and others use in this case --> </symboltable> </scoredef>

and within our staff 15:
<staff n="15">
<layer n="1">
<symbol ref="symCollaParte"/>
</layer>
</staff>
In this case the reference is not always clear: it might go to the staff
below (as in this case) or the staff above (if the cello is written out
and the cb-staff is pointing to the cello) or even from a flute to the
first violin 5 systems below. So there should be some mechanism to make
clear where the model is situated. And second: We should have the
possibility to use "c. B." (or something similar) as a symbol-phrase
(which at the same time "defines" the model) and for the following bars
simply use "//" (or something similar) (maybe even one symbol for 2-3 bars
together??).
Is this case already considered in the future guidelines?

Best greetings and a happy weekend,
Joachim




From raffaeleviglianti at gmail.com  Sat Sep  3 12:58:11 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Sat, 3 Sep 2011 11:58:11 +0100
Subject: [MEI-L] Colla parte
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D74F84C@GRANT.eservices.virginia.edu>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
	<4E6131EC.1060508@weber-gesamtausgabe.de>
	<BBCC497C40D85642B90E9F94FC30343D74F84C@GRANT.eservices.virginia.edu>
Message-ID: <CAMyHAnNn1zS4BUdd=UMoB0zSCgvLE2bjX4x8P6V4PcPOiyEfNw@mail.gmail.com>

Dear Joachim and all,

Having had the opportunity to look at other parts of der Freischuetz
manuscript, I think one might look at this situation in another way: the
symbols  // or .//., etc. actually indicate to look back at the previous
measure.
Also in the case that described, I am inclined to think that // actually
means a repetition of the instruction col basso to be found in the previous
measure.

Given this interpretation, it is sufficient to define what "col Basso" does,
and the repetition symbols will just copy over the same meaning.
Basically, if col Basso in this context means "play the current measure at
the Basso staff" (which is different from "play the measure with
xml:id='foo'"), the same meaning will be repeated by // in the following
measure.

To define what col Basso does, an element like the one suggested by Perry
might be useful. Perhaps <colla target="#STAFFid">col Basso</colla> or
similar.

Regarding <supplied>, I think we need to clarify better its role and align
it with TEI as much as possible. Perry's use seems a bit incorrect to me,
because the element should be used to supply text that cannot be read or is
not there at all and should be. In this case the symbol is there, the editor
makes its meaning explicit. An element like <colla> that would somehow
include the objections of the people at the back of the room, might be
sufficient to make explicit the meaning of the symbol in question.

Using sic / corr or orig / reg or abbr / expan seems a bit odd to me as
well, because it's not a matter of replacing one (or many) symbol(s) with
another (or many others) for the purpose of correcting, regularizing or
expanding, but it's a matter of making more explicit the meaning of a
less-standard sign.

Hope this helps!

Raffaele

On Fri, Sep 2, 2011 at 11:58 PM, Roland, Perry (pdr4h) <
pdr4h at eservices.virginia.edu> wrote:

> Hi Joachim,
>
> Let me re-state the issue to see if I understand it correctly --
>
> 1. Weber (is there any other composer worth talking about?) draws some
> version of a slash-symbol-thing to indicate that the current measure should
> be filled in with material from another instrument.
>
> 2. You want to record the original version (with the slash symbol) and give
> its "expansion" (as it were)?
>
> First, are you sure this problem can't be resolved using <orig> and
> <supplied> (or perhaps <reg>)?  For example, each measure of the flute part
> might be encoded --
>
> <measure>
>  <staff n="1">
>    <layer>
>      <choice>
>        <orig> <!-- some repetition sign(s) here --> </orig>
>        <supplied> <!-- a copy of the content of the vln. part -->
> </supplied>
>      </choice>
>    </layer>
>  </staff>
> <dir staff="1" tstamp="1">colla parte ...</dir>
> <!-- instead of the words there might be a <line> -->
> </measure>
>
> This seems like a good solution to me because it is explict.
>
> I'm using <supplied> because the actual substitution doesn't take place in
> the score, there's only an indication that it "ought" to happen. Actually
> making it happen is up to the editor -- the human being, not the software.
>
> Of course, what's missing is a link between the <supplied> element and the
> words "colla ..." (or a "wiggly" line), which I presume is in the flute
> part). At present, the editorial intervention can only be explained in the
> editorialDecl.  But, if we put our heads together, we might be able to think
> of another method of linking these.  (Perhaps with an <annotation>, which
> has pointers to the "participants"; that is, the <supplied> and <dir>
> elements, and a type attribute value of "collaparte"?)
>
> I don't know if you remember, but MEI originally had a different definition
> for <mRpt>.  It didn't necessarily indicate the repetition of the preceding
> measure, but rather the repetition *of any other measure*, "repetition"
> being defined somewhat loosely, of course.  This definition went the way of
> the dodo bird when the editorial elements (add, del, orig, reg, etc.) were
> added since the attribute (don't remember what it was called off the top of
> my head) pointing to the source measure duplicated these editorial elements'
> function.
>
> However, I recognize that there's currently no good way of implementing a
> reference to content given elsewhere in the document.  So, perhaps we should
> consider adding such a specialized element.  In the example above, the
> content of <supplied> would be the <colla> (or some such name) element.
>
> <measure n="1">
>  <staff>
>    <layer>
>      <choice>
>        <orig> <!-- some repetition sign(s) here --> </orig>
>        <supplied> <colla/> </supplied>
>      </choice>
>    </layer>
>  </staff>
> </measure>
>
> Of course, it would need an attribute pointing to the content of the vln.
> part.  In a way, this element would be similar to <ref>, although  <ref> is
> intended for navigation, while <colla> indicates "go get the content and put
> it here."  This is also not unlike internal parsed entities. This element
> would also need to be related to the <dir> or <line> elements. We could
> think about using its generic corresp attribute or give it a new,
> specialized attribute.
>
> (I can already hear some noises in the back of the room about some
> attribute or attributes for describing whatever transformation must be
> applied to the source, such as "transposed up a 5th", "inverted and
> retrograde", etc.  I'm not ready to go there yet!  There be dragons!)
>
> It might also need a more generic name than "colla".  Then it could be used
> for other situations where content given in one location needs to be
> referenced in some other.  Can't think of a good name off the top of my
> head, too late in the day.
>
> Just in case someone asks, I don't think XInclude can point to a location
> in the current document.
>
> Enough to think about for the weekend?  :)
>
> --
> 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 Joachim Veit [
> veit at weber-gesamtausgabe.de]
> Sent: Friday, September 02, 2011 3:43 PM
> To: mei-l at lists.uni-paderborn.de
> Subject: [MEI-L] Colla parte
>
> Dear MEI-L-Readers,
>
> when encoding manuscripts MEI has the possibility to encode
> measure-repeats or half-measure-repeats which are found in the original
> manuscripts in a form similar to: // or .//.  (two strokes through the
> barlines or something similar) with <mrpt> or <halfmrpt>. This has
> always a clear reference to the bar (or half-bar) before.
>
> The same symbols are used in manuscripts in combination with the "col
> Basso" or other "colla-parte"-instructions.
> Again in Weber's Freischuetz-Overture (we never do something other...)
> we have a contrabbasso with <staff n="16"> and above this the
> violoncello with <staff n="15>. Weber notates the contrabbasso in a
> normal way and in the cello-staff we find only "c. B." (= bar 1) and
> afterwards //   //    // etc.
> For a modern edition we could label the layer of the contrabbasso with
> an xml:id="2011" and put in the layer of staff 15: <layer n="1"
> copyof="2011"/>.
>
> But in this case we want to encode the "original" situation! So we first
> have to define in the scoredef:
> <scoredef>....
> <symboltable>
> <symboldef xml:id="symCollaParte"/> <!-- here we describe the symbol(s)
> Weber and others use in this case -->
> </symboltable>
> </scoredef>
>
> and within our staff 15:
> <staff n="15">
> <layer n="1">
> <symbol ref="symCollaParte"/>
> </layer>
> </staff>
> In this case the reference is not always clear: it might go to the staff
> below (as in this case) or the staff above (if the cello is written out
> and the cb-staff is pointing to the cello) or even from a flute to the
> first violin 5 systems below. So there should be some mechanism to make
> clear where the model is situated. And second: We should have the
> possibility to use "c. B." (or something similar) as a symbol-phrase
> (which at the same time "defines" the model) and for the following bars
> simply use "//" (or something similar) (maybe even one symbol for 2-3
> bars together??).
> Is this case already considered in the future guidelines?
>
> Best greetings and a happy weekend,
> Joachim
> _______________________________________________
> 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/20110903/96ca2d26/attachment.html>

From pdr4h at eservices.virginia.edu  Sat Sep  3 17:43:01 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Sat, 3 Sep 2011 15:43:01 +0000
Subject: [MEI-L] Colla parte
In-Reply-To: <CAMyHAnNn1zS4BUdd=UMoB0zSCgvLE2bjX4x8P6V4PcPOiyEfNw@mail.gmail.com>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
	<4E6131EC.1060508@weber-gesamtausgabe.de>
	<BBCC497C40D85642B90E9F94FC30343D74F84C@GRANT.eservices.virginia.edu>,
	<CAMyHAnNn1zS4BUdd=UMoB0zSCgvLE2bjX4x8P6V4PcPOiyEfNw@mail.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D75293D@GRANT.eservices.virginia.edu>

Raffaele said --

"Using sic / corr or orig / reg or abbr / expan seems a bit odd to me as well, because it's not a matter of replacing one (or many) symbol(s) with another (or many others) for the purpose of correcting, regularizing or expanding, but it's a matter of making more explicit the meaning of a less-standard sign."

I could be convinced that <supplied> doesn't exactly match this particular case; however, isn't "making more explicit" the meaning of something exactly what correcting, regularizing and expanding do?  For instance, if I mark "P.R." as an abbreviation and "Perry Roland" as its expansion, am I not making the meaning of "P.R." more explicit?

I think a case could be made that Weber's slash is an abbreviation which is expanded in another instrumental part, i.e.,

<measure>
 <staff n="1">
   <layer>
     <choice>
       <abbr> <!-- some repetition sign(s) here --> </abbr>
       <expan> <!-- a copy of the content of the bass part --> </expan>
     </choice>
   </layer>
 </staff>
 <dir staff="1" tstamp="1">col Basso</dir>
 <!-- instead of the words there might be a <line> -->
</measure>

I also think the combination of <orig> and <reg> works.  TEI says <reg> contains "a reading which has been regularized or normalized in some sense." The Guidelines say "When the source text makes extensive use of variant forms or non-standard spellings, it may be desirable for a number of reasons to regularize it: that is, to provide ?standard? or ?regularized? forms equivalent to the non-standard forms." The question is, is the "fleshing-out" of Weber's slash (a "non-standard" symbol by your own admission) a regularization / normalization?  If not, why?  What's wrong with --

<measure>
 <staff n="1">
   <layer>
     <choice>
       <orig> <!-- some repetition sign(s) here --> </orig>
       <reg> <!-- a copy of the content of the bass part --> </reg>
     </choice>
   </layer>
 </staff>
 <dir staff="1" tstamp="1">col Basso</dir>
 <!-- instead of the words there might be a <line> -->
</measure>

I believe either of these solutions works, especially with some good explanation in the MEI guidelines.

NOTE: It's especially important to note that in either case, unlike Raffaele's <colla> example -- 
      <colla target="#STAFFid">col Basso</colla>
the words "col Basso" (or the wiggly line, whatever) remain separate from the realization encoding.  To do otherwise, would wreak havoc upon the distinction between events and control events that's built into MEI.  Unless someone WANTS to start over from scratch. :)

BUT, what the content of <expan> or <reg> should be is a different question.  In the examples above and in the examples in the TEI guidelines, the content is explicitly stated; that is, every misspelling of the same word carries the same regularization.

For those situations where the regularization exists elsewhere in the encoding, we could create a generic, "go-get-something-and-put-it-here" element.  I only suggested the name "colla" as a discussion-starter.  I believe it probably needs a more generic name, perhaps "copyOf", that would allow it to function in cases other than just colla parte.  Eleanor's point about references occuring just about anywhere is correct, although there's only so far we can go and maintain explicit markup.  Followed to the extreme, the markup becomes entirely procedural, not a good thing.  Already, the <copyOf> element introduces the same problems @copyof, namely, which parts of the target should actually be copied -- certainly not the target's @xml:id and probably not it's @n either.

For the time being, I'd prefer solutions such as those above that use existing elements / attributes in order not to delay the next release.  We can take up the question of a "copyOf" element and the philosophical issues related to what a regularization "really" is 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 Raffaele Viglianti [raffaeleviglianti at gmail.com]
Sent: Saturday, September 03, 2011 6:58 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Colla parte


Dear Joachim and all, 


Having had the opportunity to look at other parts of der Freischuetz manuscript, I think one might look at this situation in another way: the symbols  // or .//., etc. actually indicate to look back at the previous measure. 
Also in the case that described, I am inclined to think that // actually means a repetition of the instruction col basso to be found in the previous measure.


Given this interpretation, it is sufficient to define what "col Basso" does, and the repetition symbols will just copy over the same meaning.
Basically, if col Basso in this context means "play the current measure at the Basso staff" (which is different from "play the measure with xml:id='foo'"), the same meaning will be repeated by // in the following measure.


To define what col Basso does, an element like the one suggested by Perry might be useful. Perhaps <colla target="#STAFFid">col Basso</colla> or similar.


Regarding <supplied>, I think we need to clarify better its role and align it with TEI as much as possible. Perry's use seems a bit incorrect to me, because the element should be used to supply text that cannot be read or is not there at all and should be. In this case the symbol is there, the editor makes its meaning explicit. An element like <colla> that would somehow include the objections of the people at the back of the room, might be sufficient to make explicit the meaning of the symbol in question. 


Using sic / corr or orig / reg or abbr / expan seems a bit odd to me as well, because it's not a matter of replacing one (or many) symbol(s) with another (or many others) for the purpose of correcting, regularizing or expanding, but it's a matter of making more explicit the meaning of a less-standard sign.


Hope this helps!


Raffaele


On Fri, Sep 2, 2011 at 11:58 PM, Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu> wrote:

Hi Joachim,

Let me re-state the issue to see if I understand it correctly --

1. Weber (is there any other composer worth talking about?) draws some version of a slash-symbol-thing to indicate that the current measure should be filled in with material from another instrument.

2. You want to record the original version (with the slash symbol) and give its "expansion" (as it were)?

First, are you sure this problem can't be resolved using <orig> and <supplied> (or perhaps <reg>)?  For example, each measure of the flute part might be encoded --

<measure>
 <staff n="1">
   <layer>
     <choice>
       <orig> <!-- some repetition sign(s) here --> </orig>
       <supplied> <!-- a copy of the content of the vln. part --> </supplied>
     </choice>
   </layer>
 </staff>
<dir staff="1" tstamp="1">colla parte ...</dir>
<!-- instead of the words there might be a <line> -->
</measure>

This seems like a good solution to me because it is explict.

I'm using <supplied> because the actual substitution doesn't take place in the score, there's only an indication that it "ought" to happen. Actually making it happen is up to the editor -- the human being, not the software.

Of course, what's missing is a link between the <supplied> element and the words "colla ..." (or a "wiggly" line), which I presume is in the flute part). At present, the editorial intervention can only be explained in the editorialDecl.  But, if we put our heads together, we might be able to think of another method of linking these.  (Perhaps with an <annotation>, which has pointers to the "participants"; that is, the <supplied> and <dir> elements, and a type attribute value of "collaparte"?)

I don't know if you remember, but MEI originally had a different definition for <mRpt>.  It didn't necessarily indicate the repetition of the preceding measure, but rather the repetition *of any other measure*, "repetition" being defined somewhat loosely, of course.  This definition went the way of the dodo bird when the editorial elements (add, del, orig, reg, etc.) were added since the attribute (don't remember what it was called off the top of my head) pointing to the source measure duplicated these editorial elements' function.

However, I recognize that there's currently no good way of implementing a reference to content given elsewhere in the document.  So, perhaps we should consider adding such a specialized element.  In the example above, the content of <supplied> would be the <colla> (or some such name) element.

<measure n="1">
 <staff>
   <layer>
     <choice>
       <orig> <!-- some repetition sign(s) here --> </orig>
       <supplied> <colla/> </supplied>
     </choice>
   </layer>
 </staff>
</measure>

Of course, it would need an attribute pointing to the content of the vln. part.  In a way, this element would be similar to <ref>, although  <ref> is intended for navigation, while <colla> indicates "go get the content and put it here."  This is also not unlike internal parsed entities. This element would also need to be related to the <dir> or <line> elements. We could think about using its generic corresp attribute or give it a new, specialized attribute.

(I can already hear some noises in the back of the room about some attribute or attributes for describing whatever transformation must be applied to the source, such as "transposed up a 5th", "inverted and retrograde", etc.  I'm not ready to go there yet!  There be dragons!)

It might also need a more generic name than "colla".  Then it could be used for other situations where content given in one location needs to be referenced in some other.  Can't think of a good name off the top of my head, too late in the day.

Just in case someone asks, I don't think XInclude can point to a location in the current document.

Enough to think about for the weekend?  :)

--
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 Joachim Veit [veit at weber-gesamtausgabe.de]
Sent: Friday, September 02, 2011 3:43 PM
To: mei-l at lists.uni-paderborn.de
Subject: [MEI-L] Colla parte


Dear MEI-L-Readers,

when encoding manuscripts MEI has the possibility to encode
measure-repeats or half-measure-repeats which are found in the original
manuscripts in a form similar to: // or .//.  (two strokes through the
barlines or something similar) with <mrpt> or <halfmrpt>. This has
always a clear reference to the bar (or half-bar) before.

The same symbols are used in manuscripts in combination with the "col
Basso" or other "colla-parte"-instructions.
Again in Weber's Freischuetz-Overture (we never do something other...)
we have a contrabbasso with <staff n="16"> and above this the
violoncello with <staff n="15>. Weber notates the contrabbasso in a
normal way and in the cello-staff we find only "c. B." (= bar 1) and
afterwards //   //    // etc.
For a modern edition we could label the layer of the contrabbasso with
an xml:id="2011" and put in the layer of staff 15: <layer n="1"
copyof="2011"/>.

But in this case we want to encode the "original" situation! So we first
have to define in the scoredef:
<scoredef>....
<symboltable>
<symboldef xml:id="symCollaParte"/> <!-- here we describe the symbol(s)
Weber and others use in this case -->
</symboltable>
</scoredef>

and within our staff 15:
<staff n="15">
<layer n="1">
<symbol ref="symCollaParte"/>
</layer>
</staff>
In this case the reference is not always clear: it might go to the staff
below (as in this case) or the staff above (if the cello is written out
and the cb-staff is pointing to the cello) or even from a flute to the
first violin 5 systems below. So there should be some mechanism to make
clear where the model is situated. And second: We should have the
possibility to use "c. B." (or something similar) as a symbol-phrase
(which at the same time "defines" the model) and for the following bars
simply use "//" (or something similar) (maybe even one symbol for 2-3
bars together??).
Is this case already considered in the future guidelines?

Best greetings and a happy weekend,
Joachim

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

From raffaeleviglianti at gmail.com  Sat Sep  3 18:56:19 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Sat, 3 Sep 2011 17:56:19 +0100
Subject: [MEI-L] Colla parte
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D75293D@GRANT.eservices.virginia.edu>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
	<4E6131EC.1060508@weber-gesamtausgabe.de>
	<BBCC497C40D85642B90E9F94FC30343D74F84C@GRANT.eservices.virginia.edu>
	<CAMyHAnNn1zS4BUdd=UMoB0zSCgvLE2bjX4x8P6V4PcPOiyEfNw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D75293D@GRANT.eservices.virginia.edu>
Message-ID: <CAMyHAnP+GNa+-UeoBTTCEcjLN2p22cBCvStMqTzuR2q_6J57NQ@mail.gmail.com>

Hi Perry,


>  isn't "making more explicit" the meaning of something exactly what
> correcting, regularizing and expanding do?  For instance, if I mark "P.R."
> as an abbreviation and "Perry Roland" as its expansion, am I not making the
> meaning of "P.R." more explicit?
>
>
I think that in this case, the act of "making explicit" is suggesting a
textual replacement:
P.R. --> Perry Roland

and this is true for all the paired choices of sic/corr, orig/reg, etc. This
is an editorial intervention that directly influences the symbols that make
the text.

In the case of col Basso, the act of "making explicit" is defining a
function:
"col Basso" --> go and copy the measure below

This is why I don't think that there is any editorial intervention here, it
is a matter of explaining what this symbol "is". (Let's set aside the fact
that arguably, when doing a transcription, everything is editorial
interpretation; even using <note>)


> the words "col Basso" (or the wiggly line, whatever) remain separate from
> the realization encoding.  To do otherwise, would wreak havoc upon the
> distinction between events and control events that's built into MEI.  Unless
> someone WANTS to start over from scratch. :)
>

Ok, I understand and agree, sorry if I jumped to suggesting a new element
too fast! :) Still, I think that the direction "col Basso" itself is
functioning as a hypothetical "copyOf" element rather than its editorial
expansion. But if the direction and its function must be kept separated to
follow the event / control event distinction, then fine. What I think should
be evident from the encoding, though, is that this falls out of editorial
interventions, and falls into the category of saying what some text "is",
which is what happens with a lot of MEI elements (this is a note, this is a
direction, ...).

Best,
Raffaele


>
> BUT, what the content of <expan> or <reg> should be is a different
> question.  In the examples above and in the examples in the TEI guidelines,
> the content is explicitly stated; that is, every misspelling of the same
> word carries the same regularization.
>
> For those situations where the regularization exists elsewhere in the
> encoding, we could create a generic, "go-get-something-and-put-it-here"
> element.  I only suggested the name "colla" as a discussion-starter.  I
> believe it probably needs a more generic name, perhaps "copyOf", that would
> allow it to function in cases other than just colla parte.  Eleanor's point
> about references occuring just about anywhere is correct, although there's
> only so far we can go and maintain explicit markup.  Followed to the
> extreme, the markup becomes entirely procedural, not a good thing.  Already,
> the <copyOf> element introduces the same problems @copyof, namely, which
> parts of the target should actually be copied -- certainly not the target's
> @xml:id and probably not it's @n either.
>
> For the time being, I'd prefer solutions such as those above that use
> existing elements / attributes in order not to delay the next release.  We
> can take up the question of a "copyOf" element and the philosophical issues
> related to what a regularization "really" is 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 Raffaele Viglianti [
> raffaeleviglianti at gmail.com]
> Sent: Saturday, September 03, 2011 6:58 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Colla parte
>
>
> Dear Joachim and all,
>
>
> Having had the opportunity to look at other parts of der Freischuetz
> manuscript, I think one might look at this situation in another way: the
> symbols  // or .//., etc. actually indicate to look back at the previous
> measure.
> Also in the case that described, I am inclined to think that // actually
> means a repetition of the instruction col basso to be found in the previous
> measure.
>
>
> Given this interpretation, it is sufficient to define what "col Basso"
> does, and the repetition symbols will just copy over the same meaning.
> Basically, if col Basso in this context means "play the current measure at
> the Basso staff" (which is different from "play the measure with
> xml:id='foo'"), the same meaning will be repeated by // in the following
> measure.
>
>
> To define what col Basso does, an element like the one suggested by Perry
> might be useful. Perhaps <colla target="#STAFFid">col Basso</colla> or
> similar.
>
>
> Regarding <supplied>, I think we need to clarify better its role and align
> it with TEI as much as possible. Perry's use seems a bit incorrect to me,
> because the element should be used to supply text that cannot be read or is
> not there at all and should be. In this case the symbol is there, the editor
> makes its meaning explicit. An element like <colla> that would somehow
> include the objections of the people at the back of the room, might be
> sufficient to make explicit the meaning of the symbol in question.
>
>
> Using sic / corr or orig / reg or abbr / expan seems a bit odd to me as
> well, because it's not a matter of replacing one (or many) symbol(s) with
> another (or many others) for the purpose of correcting, regularizing or
> expanding, but it's a matter of making more explicit the meaning of a
> less-standard sign.
>
>
> Hope this helps!
>
>
> Raffaele
>
>
> On Fri, Sep 2, 2011 at 11:58 PM, Roland, Perry (pdr4h) <
> pdr4h at eservices.virginia.edu> wrote:
>
> Hi Joachim,
>
> Let me re-state the issue to see if I understand it correctly --
>
> 1. Weber (is there any other composer worth talking about?) draws some
> version of a slash-symbol-thing to indicate that the current measure should
> be filled in with material from another instrument.
>
> 2. You want to record the original version (with the slash symbol) and give
> its "expansion" (as it were)?
>
> First, are you sure this problem can't be resolved using <orig> and
> <supplied> (or perhaps <reg>)?  For example, each measure of the flute part
> might be encoded --
>
> <measure>
>  <staff n="1">
>   <layer>
>     <choice>
>       <orig> <!-- some repetition sign(s) here --> </orig>
>       <supplied> <!-- a copy of the content of the vln. part -->
> </supplied>
>     </choice>
>   </layer>
>  </staff>
> <dir staff="1" tstamp="1">colla parte ...</dir>
> <!-- instead of the words there might be a <line> -->
> </measure>
>
> This seems like a good solution to me because it is explict.
>
> I'm using <supplied> because the actual substitution doesn't take place in
> the score, there's only an indication that it "ought" to happen. Actually
> making it happen is up to the editor -- the human being, not the software.
>
> Of course, what's missing is a link between the <supplied> element and the
> words "colla ..." (or a "wiggly" line), which I presume is in the flute
> part). At present, the editorial intervention can only be explained in the
> editorialDecl.  But, if we put our heads together, we might be able to think
> of another method of linking these.  (Perhaps with an <annotation>, which
> has pointers to the "participants"; that is, the <supplied> and <dir>
> elements, and a type attribute value of "collaparte"?)
>
> I don't know if you remember, but MEI originally had a different definition
> for <mRpt>.  It didn't necessarily indicate the repetition of the preceding
> measure, but rather the repetition *of any other measure*, "repetition"
> being defined somewhat loosely, of course.  This definition went the way of
> the dodo bird when the editorial elements (add, del, orig, reg, etc.) were
> added since the attribute (don't remember what it was called off the top of
> my head) pointing to the source measure duplicated these editorial elements'
> function.
>
> However, I recognize that there's currently no good way of implementing a
> reference to content given elsewhere in the document.  So, perhaps we should
> consider adding such a specialized element.  In the example above, the
> content of <supplied> would be the <colla> (or some such name) element.
>
> <measure n="1">
>  <staff>
>   <layer>
>     <choice>
>       <orig> <!-- some repetition sign(s) here --> </orig>
>       <supplied> <colla/> </supplied>
>     </choice>
>   </layer>
>  </staff>
> </measure>
>
> Of course, it would need an attribute pointing to the content of the vln.
> part.  In a way, this element would be similar to <ref>, although  <ref> is
> intended for navigation, while <colla> indicates "go get the content and put
> it here."  This is also not unlike internal parsed entities. This element
> would also need to be related to the <dir> or <line> elements. We could
> think about using its generic corresp attribute or give it a new,
> specialized attribute.
>
> (I can already hear some noises in the back of the room about some
> attribute or attributes for describing whatever transformation must be
> applied to the source, such as "transposed up a 5th", "inverted and
> retrograde", etc.  I'm not ready to go there yet!  There be dragons!)
>
> It might also need a more generic name than "colla".  Then it could be used
> for other situations where content given in one location needs to be
> referenced in some other.  Can't think of a good name off the top of my
> head, too late in the day.
>
> Just in case someone asks, I don't think XInclude can point to a location
> in the current document.
>
> Enough to think about for the weekend?  :)
>
> --
> 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 Joachim Veit [
> veit at weber-gesamtausgabe.de]
> Sent: Friday, September 02, 2011 3:43 PM
> To: mei-l at lists.uni-paderborn.de
> Subject: [MEI-L] Colla parte
>
>
> Dear MEI-L-Readers,
>
> when encoding manuscripts MEI has the possibility to encode
> measure-repeats or half-measure-repeats which are found in the original
> manuscripts in a form similar to: // or .//.  (two strokes through the
> barlines or something similar) with <mrpt> or <halfmrpt>. This has
> always a clear reference to the bar (or half-bar) before.
>
> The same symbols are used in manuscripts in combination with the "col
> Basso" or other "colla-parte"-instructions.
> Again in Weber's Freischuetz-Overture (we never do something other...)
> we have a contrabbasso with <staff n="16"> and above this the
> violoncello with <staff n="15>. Weber notates the contrabbasso in a
> normal way and in the cello-staff we find only "c. B." (= bar 1) and
> afterwards //   //    // etc.
> For a modern edition we could label the layer of the contrabbasso with
> an xml:id="2011" and put in the layer of staff 15: <layer n="1"
> copyof="2011"/>.
>
> But in this case we want to encode the "original" situation! So we first
> have to define in the scoredef:
> <scoredef>....
> <symboltable>
> <symboldef xml:id="symCollaParte"/> <!-- here we describe the symbol(s)
> Weber and others use in this case -->
> </symboltable>
> </scoredef>
>
> and within our staff 15:
> <staff n="15">
> <layer n="1">
> <symbol ref="symCollaParte"/>
> </layer>
> </staff>
> In this case the reference is not always clear: it might go to the staff
> below (as in this case) or the staff above (if the cello is written out
> and the cb-staff is pointing to the cello) or even from a flute to the
> first violin 5 systems below. So there should be some mechanism to make
> clear where the model is situated. And second: We should have the
> possibility to use "c. B." (or something similar) as a symbol-phrase
> (which at the same time "defines" the model) and for the following bars
> simply use "//" (or something similar) (maybe even one symbol for 2-3
> bars together??).
> Is this case already considered in the future guidelines?
>
> Best greetings and a happy weekend,
> Joachim
>
> _______________________________________________
> 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/20110903/fa1e62d6/attachment.html>

From veit at weber-gesamtausgabe.de  Tue Sep  6 22:38:59 2011
From: veit at weber-gesamtausgabe.de (Joachim Veit)
Date: Tue, 06 Sep 2011 22:38:59 +0200
Subject: [MEI-L] Colla parte
In-Reply-To: <CAMyHAnP+GNa+-UeoBTTCEcjLN2p22cBCvStMqTzuR2q_6J57NQ@mail.gmail.com>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
	<4E6131EC.1060508@weber-gesamtausgabe.de>
	<BBCC497C40D85642B90E9F94FC30343D74F84C@GRANT.eservices.virginia.edu>
	<CAMyHAnNn1zS4BUdd=UMoB0zSCgvLE2bjX4x8P6V4PcPOiyEfNw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D75293D@GRANT.eservices.virginia.edu>
	<CAMyHAnP+GNa+-UeoBTTCEcjLN2p22cBCvStMqTzuR2q_6J57NQ@mail.gmail.com>
Message-ID: <4E6684E3.4080200@weber-gesamtausgabe.de>

Dear Eleanor, Perry and Raffaele,
thanks a lot for this helpful discussion (or the beginning of a 
discussion for release 2013/05 ?)
<quote resp="Perry">"Enough to think about for the weekend?"</quote>
Perry, you see that this was for more than one weekend ;-) , and please 
excuse the late answer.

1. First I think that for the first we can live with your proposal of 
using <choice> together with orig/reg or abbr/expan.
For a longer term we should, maybe, prefer to have your <ggsapih> 
("go-get-something-and-put-it-here") or something generic - not <copyOf> 
but something in Raffaele's sense: <goCopy> (go and copy the measure below).
Concerning <reg> and <expan> I normally understand them as giving the 
"resolved abbreviation" in the form a "today's user" is used to, e.g. a 
fully expanded form of a half note with a stroke through the stem (as a 
mark for repetition of four eighth-notes). But in the context of the 
manuscript "//" as a colla-parte-sign may signal that you "go and copy 
the measure below" and that measure may consist of two half notes with 
strokes through the stem - and this has nothing to do with expansion or 
regularization. Thus I think that the solution is ok for the next 
release but not a fully satisfying one?

2. Concerning Raffaele's hint that the double lines // (or something 
similar) have to be seen in conjunction with the "c.B." <quote 
resp:"Raffaele">"if col Basso ... means 'play the current measure at the 
Basso staff' ..., the same meaning will be repeated by // in the 
following measure</quote> struck me at the first reading as a totally 
convincing interpretation of the "//" signs. But returning to the 
manuscript I begin to be a doubting Thomas again. Please haave a lookt 
at: 
http://digital.staatsbibliothek-berlin.de/dms/werkansicht/?PPN=PPN65499935X&PHYSID=PHYS_0064
There you find "col Tenore" and "col Basso" (bottom-middle) and the 
strokes // are beneath these words - so they are not a repetition sign 
here. And differing from the measure-repeats in the last bars of this 
page in violins and violas (staff 7-9 from top) we find the next hints 
in the chorus staffs (no. 2-3 from bottom) as double lines // crossing 
the bar line (that is continued on the next page). And as a further 
motive we have the "unis:[ono] in line 5 from top (middle)", again with 
a //-sign. (Besides: the // in b. 3/4 of the flute - staff 1 from top - 
are a repetition sign for bars 1/2 on this page) - so the "//" has very 
different meanings here, but always have something to to with "repetion".
In the case of "colla parte", "in 8va", "col Basso", "unisono" etc. it 
is not necessary that this verbal "prescription" is explicit: Look at:
bibliothek-berlin.de/dms/werkansicht/?PPN=PPN65499935X&PHYSID=PHYS_0025&USE=800
In the cello-staff there is only "//" without any "c.B." (and I think 
that Eleanor hinted at the fact that this form is often to be found with 
other composers - but you know that I am only acquainted with this 
strange Weber.... :-[ ). So we really have to be careful what we define 
in the header as the symbols used combined with their "meaning".

3. As soon as we connect "//" with any form of meaning we are 
interpreting the signs (and behave as editors - even if we add "col 
Basso" where we only find //). And Eleanor's examples show that in many 
cases there is a lot of  wiggle-room here! But if we continue the work 
of encoding the manuscript of the Freischuetz-overture I think we should 
differentiate at least between a <symboldef> of "//" that denotes pure 
measure (or half-measure) repeats (and are normally used quite strictly: 
as repetition signs in each measure or at least on the bar-lines if 
meant for a 2-measure-unit) and those which show a "freer distribution", 
but at least in Weber's case are preferably used as sign "on a bar-line" 
for the <goCopy>-mechanism?

Nevertheless a generic element with the function of "go and bring 
something from another bar here in this place" would really be of some 
advantage!?

I hope that this makes the discussion not too confusing - but that seems 
to be my special part at the moment ;-) .
Best greetings,
Joachim










Am 03.09.11 18:56, schrieb Raffaele Viglianti:
> Hi Perry,
>
>
>      isn't "making more explicit" the meaning of something exactly
>     what correcting, regularizing and expanding do?  For instance, if
>     I mark "P.R." as an abbreviation and "Perry Roland" as its
>     expansion, am I not making the meaning of "P.R." more explicit?
>
>
> I think that in this case, the act of "making explicit" is suggesting 
> a textual replacement:
> P.R. --> Perry Roland
>
> and this is true for all the paired choices of sic/corr, orig/reg, 
> etc. This is an editorial intervention that directly influences the 
> symbols that make the text.
>
> In the case of col Basso, the act of "making explicit" is defining a 
> function:
> "col Basso" --> go and copy the measure below
>
> This is why I don't think that there is any editorial intervention 
> here, it is a matter of explaining what this symbol "is". (Let's set 
> aside the fact that arguably, when doing a transcription, everything 
> is editorial interpretation; even using <note>)
>
>     the words "col Basso" (or the wiggly line, whatever) remain
>     separate from the realization encoding.  To do otherwise, would
>     wreak havoc upon the distinction between events and control events
>     that's built into MEI.  Unless someone WANTS to start over from
>     scratch. :)
>
>
> Ok, I understand and agree, sorry if I jumped to suggesting a new 
> element too fast! :) Still, I think that the direction "col Basso" 
> itself is functioning as a hypothetical "copyOf" element rather than 
> its editorial expansion. But if the direction and its function must be 
> kept separated to follow the event / control event distinction, then 
> fine. What I think should be evident from the encoding, though, is 
> that this falls out of editorial interventions, and falls into the 
> category of saying what some text "is", which is what happens with a 
> lot of MEI elements (this is a note, this is a direction, ...).
>
> Best,
> Raffaele
>
>
>     BUT, what the content of <expan> or <reg> should be is a different
>     question.  In the examples above and in the examples in the TEI
>     guidelines, the content is explicitly stated; that is, every
>     misspelling of the same word carries the same regularization.
>
>     For those situations where the regularization exists elsewhere in
>     the encoding, we could create a generic,
>     "go-get-something-and-put-it-here" element.  I only suggested the
>     name "colla" as a discussion-starter.  I believe it probably needs
>     a more generic name, perhaps "copyOf", that would allow it to
>     function in cases other than just colla parte.  Eleanor's point
>     about references occuring just about anywhere is correct, although
>     there's only so far we can go and maintain explicit markup.
>      Followed to the extreme, the markup becomes entirely procedural,
>     not a good thing.  Already, the <copyOf> element introduces the
>     same problems @copyof, namely, which parts of the target should
>     actually be copied -- certainly not the target's @xml:id and
>     probably not it's @n either.
>
>     For the time being, I'd prefer solutions such as those above that
>     use existing elements / attributes in order not to delay the next
>     release.  We can take up the question of a "copyOf" element and
>     the philosophical issues related to what a regularization "really"
>     is later.
>
>     --
>     p.
>
>     __________________________
>     Perry Roland
>     Music Library
>     University of Virginia
>     P. O. Box 400175
>     Charlottesville, VA 22904
>     434-982-2702 <tel:434-982-2702> (w)
>     pdr4h (at) virginia (dot) edu
>
>
>
>     From: mei-l-bounces at lists.uni-paderborn.de
>     <mailto:mei-l-bounces at lists.uni-paderborn.de>
>     [mei-l-bounces at lists.uni-paderborn.de
>     <mailto:mei-l-bounces at lists.uni-paderborn.de>] on behalf of
>     Raffaele Viglianti [raffaeleviglianti at gmail.com
>     <mailto:raffaeleviglianti at gmail.com>]
>     Sent: Saturday, September 03, 2011 6:58 AM
>     To: Music Encoding Initiative
>     Subject: Re: [MEI-L] Colla parte
>
>
>     Dear Joachim and all,
>
>
>     Having had the opportunity to look at other parts of der
>     Freischuetz manuscript, I think one might look at this situation
>     in another way: the symbols  // or .//., etc. actually indicate to
>     look back at the previous measure.
>     Also in the case that described, I am inclined to think that //
>     actually means a repetition of the instruction col basso to be
>     found in the previous measure.
>
>
>     Given this interpretation, it is sufficient to define what "col
>     Basso" does, and the repetition symbols will just copy over the
>     same meaning.
>     Basically, if col Basso in this context means "play the current
>     measure at the Basso staff" (which is different from "play the
>     measure with xml:id='foo'"), the same meaning will be repeated by
>     // in the following measure.
>
>
>     To define what col Basso does, an element like the one suggested
>     by Perry might be useful. Perhaps <colla target="#STAFFid">col
>     Basso</colla> or similar.
>
>
>     Regarding <supplied>, I think we need to clarify better its role
>     and align it with TEI as much as possible. Perry's use seems a bit
>     incorrect to me, because the element should be used to supply text
>     that cannot be read or is not there at all and should be. In this
>     case the symbol is there, the editor makes its meaning explicit.
>     An element like <colla> that would somehow include the objections
>     of the people at the back of the room, might be sufficient to make
>     explicit the meaning of the symbol in question.
>
>
>     Using sic / corr or orig / reg or abbr / expan seems a bit odd to
>     me as well, because it's not a matter of replacing one (or many)
>     symbol(s) with another (or many others) for the purpose of
>     correcting, regularizing or expanding, but it's a matter of making
>     more explicit the meaning of a less-standard sign.
>
>
>     Hope this helps!
>
>
>     Raffaele
>
>
>     On Fri, Sep 2, 2011 at 11:58 PM, Roland, Perry (pdr4h)
>     <pdr4h at eservices.virginia.edu
>     <mailto:pdr4h at eservices.virginia.edu>> wrote:
>
>     Hi Joachim,
>
>     Let me re-state the issue to see if I understand it correctly --
>
>     1. Weber (is there any other composer worth talking about?) draws
>     some version of a slash-symbol-thing to indicate that the current
>     measure should be filled in with material from another instrument.
>
>     2. You want to record the original version (with the slash symbol)
>     and give its "expansion" (as it were)?
>
>     First, are you sure this problem can't be resolved using <orig>
>     and <supplied> (or perhaps <reg>)?  For example, each measure of
>     the flute part might be encoded --
>
>     <measure>
>     <staff n="1">
>     <layer>
>     <choice>
>     <orig> <!-- some repetition sign(s) here --> </orig>
>     <supplied> <!-- a copy of the content of the vln. part --> </supplied>
>     </choice>
>     </layer>
>     </staff>
>     <dir staff="1" tstamp="1">colla parte ...</dir>
>     <!-- instead of the words there might be a <line> -->
>     </measure>
>
>     This seems like a good solution to me because it is explict.
>
>     I'm using <supplied> because the actual substitution doesn't take
>     place in the score, there's only an indication that it "ought" to
>     happen. Actually making it happen is up to the editor -- the human
>     being, not the software.
>
>     Of course, what's missing is a link between the <supplied> element
>     and the words "colla ..." (or a "wiggly" line), which I presume is
>     in the flute part). At present, the editorial intervention can
>     only be explained in the editorialDecl.  But, if we put our heads
>     together, we might be able to think of another method of linking
>     these.  (Perhaps with an <annotation>, which has pointers to the
>     "participants"; that is, the <supplied> and <dir> elements, and a
>     type attribute value of "collaparte"?)
>
>     I don't know if you remember, but MEI originally had a different
>     definition for <mRpt>.  It didn't necessarily indicate the
>     repetition of the preceding measure, but rather the repetition *of
>     any other measure*, "repetition" being defined somewhat loosely,
>     of course.  This definition went the way of the dodo bird when the
>     editorial elements (add, del, orig, reg, etc.) were added since
>     the attribute (don't remember what it was called off the top of my
>     head) pointing to the source measure duplicated these editorial
>     elements' function.
>
>     However, I recognize that there's currently no good way of
>     implementing a reference to content given elsewhere in the
>     document.  So, perhaps we should consider adding such a
>     specialized element.  In the example above, the content of
>     <supplied> would be the <colla> (or some such name) element.
>
>     <measure n="1">
>     <staff>
>     <layer>
>     <choice>
>     <orig> <!-- some repetition sign(s) here --> </orig>
>     <supplied> <colla/> </supplied>
>     </choice>
>     </layer>
>     </staff>
>     </measure>
>
>     Of course, it would need an attribute pointing to the content of
>     the vln. part.  In a way, this element would be similar to <ref>,
>     although <ref> is intended for navigation, while <colla> indicates
>     "go get the content and put it here."  This is also not unlike
>     internal parsed entities. This element would also need to be
>     related to the <dir> or <line> elements. We could think about
>     using its generic corresp attribute or give it a new, specialized
>     attribute.
>
>     (I can already hear some noises in the back of the room about some
>     attribute or attributes for describing whatever transformation
>     must be applied to the source, such as "transposed up a 5th",
>     "inverted and retrograde", etc.  I'm not ready to go there yet!
>      There be dragons!)
>
>     It might also need a more generic name than "colla".  Then it
>     could be used for other situations where content given in one
>     location needs to be referenced in some other.  Can't think of a
>     good name off the top of my head, too late in the day.
>
>     Just in case someone asks, I don't think XInclude can point to a
>     location in the current document.
>
>     Enough to think about for the weekend?  :)
>
>     --
>     p.
>
>     __________________________
>     Perry Roland
>     Music Library
>     University of Virginia
>     P. O. Box 400175
>     Charlottesville, VA 22904
>     434-982-2702 <tel:434-982-2702> (w)
>     pdr4h (at) virginia (dot) edu
>     ________________________________________
>     From: mei-l-bounces at lists.uni-paderborn.de
>     <mailto:mei-l-bounces at lists.uni-paderborn.de>
>     [mei-l-bounces at lists.uni-paderborn.de
>     <mailto:mei-l-bounces at lists.uni-paderborn.de>] on behalf of
>     Joachim Veit [veit at weber-gesamtausgabe.de
>     <mailto:veit at weber-gesamtausgabe.de>]
>     Sent: Friday, September 02, 2011 3:43 PM
>     To: mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de>
>     Subject: [MEI-L] Colla parte
>
>
>     Dear MEI-L-Readers,
>
>     when encoding manuscripts MEI has the possibility to encode
>     measure-repeats or half-measure-repeats which are found in the
>     original
>     manuscripts in a form similar to: // or .//.  (two strokes through the
>     barlines or something similar) with <mrpt> or <halfmrpt>. This has
>     always a clear reference to the bar (or half-bar) before.
>
>     The same symbols are used in manuscripts in combination with the "col
>     Basso" or other "colla-parte"-instructions.
>     Again in Weber's Freischuetz-Overture (we never do something other...)
>     we have a contrabbasso with <staff n="16"> and above this the
>     violoncello with <staff n="15>. Weber notates the contrabbasso in a
>     normal way and in the cello-staff we find only "c. B." (= bar 1) and
>     afterwards //   //    // etc.
>     For a modern edition we could label the layer of the contrabbasso with
>     an xml:id="2011" and put in the layer of staff 15: <layer n="1"
>     copyof="2011"/>.
>
>     But in this case we want to encode the "original" situation! So we
>     first
>     have to define in the scoredef:
>     <scoredef>....
>     <symboltable>
>     <symboldef xml:id="symCollaParte"/> <!-- here we describe the
>     symbol(s)
>     Weber and others use in this case -->
>     </symboltable>
>     </scoredef>
>
>     and within our staff 15:
>     <staff n="15">
>     <layer n="1">
>     <symbol ref="symCollaParte"/>
>     </layer>
>     </staff>
>     In this case the reference is not always clear: it might go to the
>     staff
>     below (as in this case) or the staff above (if the cello is
>     written out
>     and the cb-staff is pointing to the cello) or even from a flute to the
>     first violin 5 systems below. So there should be some mechanism to
>     make
>     clear where the model is situated. And second: We should have the
>     possibility to use "c. B." (or something similar) as a symbol-phrase
>     (which at the same time "defines" the model) and for the following
>     bars
>     simply use "//" (or something similar) (maybe even one symbol for 2-3
>     bars together??).
>     Is this case already considered in the future guidelines?
>
>     Best greetings and a happy weekend,
>     Joachim
>
>     _______________________________________________
>     mei-l mailing list
>     mei-l at lists.uni-paderborn.de <mailto: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 <mailto: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

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110906/4b0a7850/attachment.html>
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : veit.vcf
Dateityp    : text/x-vcard
Dateigr??e  : 364 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110906/4b0a7850/attachment.vcf>

From pdr4h at eservices.virginia.edu  Wed Sep  7 00:30:26 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Tue, 6 Sep 2011 22:30:26 +0000
Subject: [MEI-L] Colla parte
In-Reply-To: <4E6684E3.4080200@weber-gesamtausgabe.de>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
	<4E6131EC.1060508@weber-gesamtausgabe.de>
	<BBCC497C40D85642B90E9F94FC30343D74F84C@GRANT.eservices.virginia.edu>
	<CAMyHAnNn1zS4BUdd=UMoB0zSCgvLE2bjX4x8P6V4PcPOiyEfNw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D75293D@GRANT.eservices.virginia.edu>
	<CAMyHAnP+GNa+-UeoBTTCEcjLN2p22cBCvStMqTzuR2q_6J57NQ@mail.gmail.com>,
	<4E6684E3.4080200@weber-gesamtausgabe.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D755E95@GRANT.eservices.virginia.edu>

Hi Joachim,

After some thinking about it, I don't believe we need a new element to describe the "go-get-something-and-put-it-here" behavior.  The xlink attributes available on <ref> and <ptr> will do the job.  

In the following example, the 1st staff contains a symbol that indicates the contents of the 2nd staff should be inserted.  This can be indicated using the actuate and show attributes on <ptr> -- @show says what to do (embed=put the content here) and @actuate says when to do it (onLoad=when I load the document). 

<measure>
  <staff>
    <layer>
      <!-- Colla parte -->
      <choice>
        <abbr>
          <symbol ref="#p1"/>
        </abbr>
        <expan>
          <!-- reference to the contents of the bass part -->
          <ptr target="#basso" xlink:actuate="onLoad" xlink:show="embed"/>
        </expan>
      </choice>
    </layer>
  </staff>
  <staff>
    <layer xml:id="basso">
      <note/>
      <note/>
      <rest/>
      <note/>
    </layer>
  </staff>
</measure>

A means for identifying the content of the target that should be processed is not available, but an @xpointer attribute could be added for this purpose.  Using xpointer syntax one could say "get the contents (or some of the contents) of the element called "basso", NOT the element itself. For example, 

<ptr target="#basso"  xlink:actuate="onLoad" xlink:show="embed" xpointer="element(basso/note)"/> 

would retrieve and embed the note children of "basso", but not the rest.  If @xpointer was not present, either the element identified as "basso" or its contents could be retrieved, depending on the behavior we want to define. However, the first behavior would be a re-implementation of @copyOf, so the second seems like a more logical default.

--
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 Joachim Veit [veit at weber-gesamtausgabe.de]
Sent: Tuesday, September 06, 2011 4:38 PM
To: mei-l at lists.uni-paderborn.de
Subject: Re: [MEI-L] Colla parte


Dear Eleanor, Perry and Raffaele,
thanks a lot for this helpful discussion (or the beginning of a discussion for release 2013/05 ?)
<quote resp="Perry">"Enough to think about for the weekend?"</quote>
Perry, you see that this was for more than one weekend ;-)  , and please excuse the late answer. 

1. First I think that for the first we can live with your proposal of using <choice> together with orig/reg or abbr/expan.
For a longer term we should, maybe, prefer to have your <ggsapih> ("go-get-something-and-put-it-here") or something generic - not <copyOf> but something in Raffaele's sense: <goCopy> (go and copy the measure below).
Concerning <reg> and <expan> I normally understand them as giving the "resolved abbreviation" in the form a "today's user" is used to, e.g. a fully expanded form of a half note with a stroke through the stem (as a mark for repetition of four eighth-notes). But in the context of the manuscript "//" as a colla-parte-sign may signal that you "go and copy the measure below" and that measure may consist of two half notes with strokes through the stem - and this has nothing to do with expansion or regularization. Thus I think that the solution is ok for the next release but not a fully satisfying one?

2. Concerning Raffaele's hint that the double lines // (or something similar) have to be seen in conjunction with the "c.B." <quote resp:"Raffaele">"if col Basso ... means 'play the current measure at the Basso staff' ..., the same meaning will be repeated by // in the following measure</quote> struck me at the first reading as a totally convincing interpretation of the "//" signs. But returning to the manuscript I begin to be a doubting Thomas again. Please haave a lookt at: http://digital.staatsbibliothek-berlin.de/dms/werkansicht/?PPN=PPN65499935X&PHYSID=PHYS_0064
There you find "col Tenore" and "col Basso" (bottom-middle) and the strokes // are beneath these words - so they are not a repetition sign here. And differing from the measure-repeats in the last bars of this page in violins and violas (staff 7-9 from top) we find the next hints in the chorus staffs (no. 2-3 from bottom) as double lines // crossing the bar line (that is continued on the next page). And as a further motive we have the "unis:[ono] in line 5 from top (middle)", again with a //-sign. (Besides: the // in b. 3/4 of the flute - staff 1 from top - are a repetition sign for bars 1/2 on this page) - so the "//" has very different meanings here, but always have something to to with "repetion".
In the case of "colla parte", "in 8va", "col Basso", "unisono" etc. it is not necessary that this verbal "prescription" is explicit: Look at:
bibliothek-berlin.de/dms/werkansicht/?PPN=PPN65499935X&PHYSID=PHYS_0025&USE=800
In the cello-staff there is only "//" without any "c.B." (and I think that Eleanor hinted at the fact that this form is often to be found with other composers - but you know that I am only acquainted with this strange Weber.... :-[ ). So we really have to be careful what we define in the header as the symbols used combined with their "meaning". 

3. As soon as we connect "//" with any form of meaning we are interpreting the signs (and behave as editors - even if we add "col Basso" where we only find //). And Eleanor's examples show that in many cases there is a lot of  wiggle-room here! But if we continue the work of encoding the manuscript of the Freischuetz-overture I think we should differentiate at least between a <symboldef> of "//" that denotes pure measure (or half-measure) repeats (and are normally used quite strictly: as repetition signs in each measure or at least on the bar-lines if meant for a 2-measure-unit) and those which show a "freer distribution", but at least in Weber's case are preferably used as sign "on a bar-line" for the <goCopy>-mechanism?

Nevertheless a generic element with the function of "go and bring something from another bar here in this place" would really be of some advantage!?

I hope that this makes the discussion not too confusing - but that seems to be my special part at the moment ;-) .
Best greetings,
Joachim
 









Am 03.09.11 18:56, schrieb Raffaele Viglianti: 
Hi Perry, 




 isn't "making more explicit" the meaning of something exactly what correcting, regularizing and expanding do?  For instance, if I mark "P.R." as an abbreviation and "Perry Roland" as its expansion, am I not making the meaning of "P.R." more explicit?




I think that in this case, the act of "making explicit" is suggesting a textual replacement:
P.R. --> Perry Roland


and this is true for all the paired choices of sic/corr, orig/reg, etc. This is an editorial intervention that directly influences the symbols that make the text.


In the case of col Basso, the act of "making explicit" is defining a function:
"col Basso" --> go and copy the measure below


This is why I don't think that there is any editorial intervention here, it is a matter of explaining what this symbol "is". (Let's set aside the fact that arguably, when doing a transcription, everything is editorial interpretation; even using <note>) 

the words "col Basso" (or the wiggly line, whatever) remain separate from the realization encoding.  To do otherwise, would wreak havoc upon the distinction between events and control events that's built into MEI.  Unless someone WANTS to start over from scratch. :)



Ok, I understand and agree, sorry if I jumped to suggesting a new element too fast! :) Still, I think that the direction "col Basso" itself is functioning as a hypothetical "copyOf" element rather than its editorial expansion. But if the direction and its function must be kept separated to follow the event / control event distinction, then fine. What I think should be evident from the encoding, though, is that this falls out of editorial interventions, and falls into the category of saying what some text "is", which is what happens with a lot of MEI elements (this is a note, this is a direction, ...).


Best,
Raffaele
  

BUT, what the content of <expan> or <reg> should be is a different question.  In the examples above and in the examples in the TEI guidelines, the content is explicitly stated; that is, every misspelling of the same word carries the same regularization.

For those situations where the regularization exists elsewhere in the encoding, we could create a generic, "go-get-something-and-put-it-here" element.  I only suggested the name "colla" as a discussion-starter.  I believe it probably needs a more generic name, perhaps "copyOf", that would allow it to function in cases other than just colla parte.  Eleanor's point about references occuring just about anywhere is correct, although there's only so far we can go and maintain explicit markup.  Followed to the extreme, the markup becomes entirely procedural, not a good thing.  Already, the <copyOf> element introduces the same problems @copyof, namely, which parts of the target should actually be copied -- certainly not the target's @xml:id and probably not it's @n either.

For the time being, I'd prefer solutions such as those above that use existing elements / attributes in order not to delay the next release.  We can take up the question of a "copyOf" element and the philosophical issues related to what a regularization "really" is 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 Raffaele Viglianti [raffaeleviglianti at gmail.com]
Sent: Saturday, September 03, 2011 6:58 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Colla parte



Dear Joachim and all,


Having had the opportunity to look at other parts of der Freischuetz manuscript, I think one might look at this situation in another way: the symbols  // or .//., etc. actually indicate to look back at the previous measure.
Also in the case that described, I am inclined to think that // actually means a repetition of the instruction col basso to be found in the previous measure.


Given this interpretation, it is sufficient to define what "col Basso" does, and the repetition symbols will just copy over the same meaning.
Basically, if col Basso in this context means "play the current measure at the Basso staff" (which is different from "play the measure with xml:id='foo'"), the same meaning will be repeated by // in the following measure.


To define what col Basso does, an element like the one suggested by Perry might be useful. Perhaps <colla target="#STAFFid">col Basso</colla> or similar.


Regarding <supplied>, I think we need to clarify better its role and align it with TEI as much as possible. Perry's use seems a bit incorrect to me, because the element should be used to supply text that cannot be read or is not there at all and should be. In this case the symbol is there, the editor makes its meaning explicit. An element like <colla> that would somehow include the objections of the people at the back of the room, might be sufficient to make explicit the meaning of the symbol in question.


Using sic / corr or orig / reg or abbr / expan seems a bit odd to me as well, because it's not a matter of replacing one (or many) symbol(s) with another (or many others) for the purpose of correcting, regularizing or expanding, but it's a matter of making more explicit the meaning of a less-standard sign.


Hope this helps!


Raffaele


On Fri, Sep 2, 2011 at 11:58 PM, Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu> wrote:

Hi Joachim,

Let me re-state the issue to see if I understand it correctly --

1. Weber (is there any other composer worth talking about?) draws some version of a slash-symbol-thing to indicate that the current measure should be filled in with material from another instrument.

2. You want to record the original version (with the slash symbol) and give its "expansion" (as it were)?

First, are you sure this problem can't be resolved using <orig> and <supplied> (or perhaps <reg>)?  For example, each measure of the flute part might be encoded --

<measure>
 <staff n="1">
  <layer>
    <choice>
      <orig> <!-- some repetition sign(s) here --> </orig>
      <supplied> <!-- a copy of the content of the vln. part --> </supplied>
    </choice>
  </layer>
 </staff>
<dir staff="1" tstamp="1">colla parte ...</dir>
<!-- instead of the words there might be a <line> -->
</measure>

This seems like a good solution to me because it is explict.

I'm using <supplied> because the actual substitution doesn't take place in the score, there's only an indication that it "ought" to happen. Actually making it happen is up to the editor -- the human being, not the software.

Of course, what's missing is a link between the <supplied> element and the words "colla ..." (or a "wiggly" line), which I presume is in the flute part). At present, the editorial intervention can only be explained in the editorialDecl.  But, if we put our heads together, we might be able to think of another method of linking these.  (Perhaps with an <annotation>, which has pointers to the "participants"; that is, the <supplied> and <dir> elements, and a type attribute value of "collaparte"?)

I don't know if you remember, but MEI originally had a different definition for <mRpt>.  It didn't necessarily indicate the repetition of the preceding measure, but rather the repetition *of any other measure*, "repetition" being defined somewhat loosely, of course.  This definition went the way of the dodo bird when the editorial elements (add, del, orig, reg, etc.) were added since the attribute (don't remember what it was called off the top of my head) pointing to the source measure duplicated these editorial elements' function.

However, I recognize that there's currently no good way of implementing a reference to content given elsewhere in the document.  So, perhaps we should consider adding such a specialized element.  In the example above, the content of <supplied> would be the <colla> (or some such name) element.

<measure n="1">
 <staff>
  <layer>
    <choice>
      <orig> <!-- some repetition sign(s) here --> </orig>
      <supplied> <colla/> </supplied>
    </choice>
  </layer>
 </staff>
</measure>

Of course, it would need an attribute pointing to the content of the vln. part.  In a way, this element would be similar to <ref>, although  <ref> is intended for navigation, while <colla> indicates "go get the content and put it here."  This is also not unlike internal parsed entities. This element would also need to be related to the <dir> or <line> elements. We could think about using its generic corresp attribute or give it a new, specialized attribute.

(I can already hear some noises in the back of the room about some attribute or attributes for describing whatever transformation must be applied to the source, such as "transposed up a 5th", "inverted and retrograde", etc.  I'm not ready to go there yet!  There be dragons!)

It might also need a more generic name than "colla".  Then it could be used for other situations where content given in one location needs to be referenced in some other.  Can't think of a good name off the top of my head, too late in the day.

Just in case someone asks, I don't think XInclude can point to a location in the current document.

Enough to think about for the weekend?  :)

--
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 Joachim Veit [veit at weber-gesamtausgabe.de]
Sent: Friday, September 02, 2011 3:43 PM
To: mei-l at lists.uni-paderborn.de
Subject: [MEI-L] Colla parte


Dear MEI-L-Readers,

when encoding manuscripts MEI has the possibility to encode
measure-repeats or half-measure-repeats which are found in the original
manuscripts in a form similar to: // or .//.  (two strokes through the
barlines or something similar) with <mrpt> or <halfmrpt>. This has
always a clear reference to the bar (or half-bar) before.

The same symbols are used in manuscripts in combination with the "col
Basso" or other "colla-parte"-instructions.
Again in Weber's Freischuetz-Overture (we never do something other...)
we have a contrabbasso with <staff n="16"> and above this the
violoncello with <staff n="15>. Weber notates the contrabbasso in a
normal way and in the cello-staff we find only "c. B." (= bar 1) and
afterwards //   //    // etc.
For a modern edition we could label the layer of the contrabbasso with
an xml:id="2011" and put in the layer of staff 15: <layer n="1"
copyof="2011"/>.

But in this case we want to encode the "original" situation! So we first
have to define in the scoredef:
<scoredef>....
<symboltable>
<symboldef xml:id="symCollaParte"/> <!-- here we describe the symbol(s)
Weber and others use in this case -->
</symboltable>
</scoredef>

and within our staff 15:
<staff n="15">
<layer n="1">
<symbol ref="symCollaParte"/>
</layer>
</staff>
In this case the reference is not always clear: it might go to the staff
below (as in this case) or the staff above (if the cello is written out
and the cb-staff is pointing to the cello) or even from a flute to the
first violin 5 systems below. So there should be some mechanism to make
clear where the model is situated. And second: We should have the
possibility to use "c. B." (or something similar) as a symbol-phrase
(which at the same time "defines" the model) and for the following bars
simply use "//" (or something similar) (maybe even one symbol for 2-3
bars together??).
Is this case already considered in the future guidelines?

Best greetings and a happy weekend,
Joachim

_______________________________________________
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

From veit at weber-gesamtausgabe.de  Wed Sep  7 10:06:56 2011
From: veit at weber-gesamtausgabe.de (Joachim Veit)
Date: Wed, 07 Sep 2011 10:06:56 +0200
Subject: [MEI-L] Colla parte
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D755E95@GRANT.eservices.virginia.edu>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
	<4E6131EC.1060508@weber-gesamtausgabe.de>
	<BBCC497C40D85642B90E9F94FC30343D74F84C@GRANT.eservices.virginia.edu>
	<CAMyHAnNn1zS4BUdd=UMoB0zSCgvLE2bjX4x8P6V4PcPOiyEfNw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D75293D@GRANT.eservices.virginia.edu>
	<CAMyHAnP+GNa+-UeoBTTCEcjLN2p22cBCvStMqTzuR2q_6J57NQ@mail.gmail.com>,
	<4E6684E3.4080200@weber-gesamtausgabe.de>
	<BBCC497C40D85642B90E9F94FC30343D755E95@GRANT.eservices.virginia.edu>
Message-ID: <4E672620.8080707@weber-gesamtausgabe.de>

Hi Perry,
that sounds perfectly reasonable - many thanks!! The huge advantage of 
this procedure is the possibility to separate the stuff which has to be 
embedded, e.g. we could embed only the notes but also the dynamics and 
not the articulation or something vice versa or double vice versa...
And the semantics of pointer is really the thing which Raffaele meant 
too, I think?
In so far I am really happy with this solution - and we shall be 
experimenting until we find the dragon which maybe is hidden behind the 
next corner (>:o ...). But for the moment we stay absolutely 8-) !
Best greetings, while we again are spending our time for our most 
esteemed work: writing a new grant proposal....
Joachim


Am 07.09.11 00:30, schrieb Roland, Perry (pdr4h):
> Hi Joachim,
>
> After some thinking about it, I don't believe we need a new element to describe the "go-get-something-and-put-it-here" behavior.  The xlink attributes available on<ref>  and<ptr>  will do the job.
>
> In the following example, the 1st staff contains a symbol that indicates the contents of the 2nd staff should be inserted.  This can be indicated using the actuate and show attributes on<ptr>  -- @show says what to do (embed=put the content here) and @actuate says when to do it (onLoad=when I load the document).
>
> <measure>
>    <staff>
>      <layer>
>        <!-- Colla parte -->
>        <choice>
>          <abbr>
>            <symbol ref="#p1"/>
>          </abbr>
>          <expan>
>            <!-- reference to the contents of the bass part -->
>            <ptr target="#basso" xlink:actuate="onLoad" xlink:show="embed"/>
>          </expan>
>        </choice>
>      </layer>
>    </staff>
>    <staff>
>      <layer xml:id="basso">
>        <note/>
>        <note/>
>        <rest/>
>        <note/>
>      </layer>
>    </staff>
> </measure>
>
> A means for identifying the content of the target that should be processed is not available, but an @xpointer attribute could be added for this purpose.  Using xpointer syntax one could say "get the contents (or some of the contents) of the element called "basso", NOT the element itself. For example,
>
> <ptr target="#basso"  xlink:actuate="onLoad" xlink:show="embed" xpointer="element(basso/note)"/>
>
> would retrieve and embed the note children of "basso", but not the rest.  If @xpointer was not present, either the element identified as "basso" or its contents could be retrieved, depending on the behavior we want to define. However, the first behavior would be a re-implementation of @copyOf, so the second seems like a more logical default.
>
> --
> 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 Joachim Veit [veit at weber-gesamtausgabe.de]
> Sent: Tuesday, September 06, 2011 4:38 PM
> To: mei-l at lists.uni-paderborn.de
> Subject: Re: [MEI-L] Colla parte
>
>
> Dear Eleanor, Perry and Raffaele,
> thanks a lot for this helpful discussion (or the beginning of a discussion for release 2013/05 ?)
> <quote resp="Perry">"Enough to think about for the weekend?"</quote>
> Perry, you see that this was for more than one weekend ;-)  , and please excuse the late answer.
>
> 1. First I think that for the first we can live with your proposal of using<choice>  together with orig/reg or abbr/expan.
> For a longer term we should, maybe, prefer to have your<ggsapih>  ("go-get-something-and-put-it-here") or something generic - not<copyOf>  but something in Raffaele's sense:<goCopy>  (go and copy the measure below).
> Concerning<reg>  and<expan>  I normally understand them as giving the "resolved abbreviation" in the form a "today's user" is used to, e.g. a fully expanded form of a half note with a stroke through the stem (as a mark for repetition of four eighth-notes). But in the context of the manuscript "//" as a colla-parte-sign may signal that you "go and copy the measure below" and that measure may consist of two half notes with strokes through the stem - and this has nothing to do with expansion or regularization. Thus I think that the solution is ok for the next release but not a fully satisfying one?
>
> 2. Concerning Raffaele's hint that the double lines // (or something similar) have to be seen in conjunction with the "c.B."<quote resp:"Raffaele">"if col Basso ... means 'play the current measure at the Basso staff' ..., the same meaning will be repeated by // in the following measure</quote>  struck me at the first reading as a totally convincing interpretation of the "//" signs. But returning to the manuscript I begin to be a doubting Thomas again. Please haave a lookt at: http://digital.staatsbibliothek-berlin.de/dms/werkansicht/?PPN=PPN65499935X&PHYSID=PHYS_0064
> There you find "col Tenore" and "col Basso" (bottom-middle) and the strokes // are beneath these words - so they are not a repetition sign here. And differing from the measure-repeats in the last bars of this page in violins and violas (staff 7-9 from top) we find the next hints in the chorus staffs (no. 2-3 from bottom) as double lines // crossing the bar line (that is continued on the next page). And as a further motive we have the "unis:[ono] in line 5 from top (middle)", again with a //-sign. (Besides: the // in b. 3/4 of the flute - staff 1 from top - are a repetition sign for bars 1/2 on this page) - so the "//" has very different meanings here, but always have something to to with "repetion".
> In the case of "colla parte", "in 8va", "col Basso", "unisono" etc. it is not necessary that this verbal "prescription" is explicit: Look at:
> bibliothek-berlin.de/dms/werkansicht/?PPN=PPN65499935X&PHYSID=PHYS_0025&USE=800
> In the cello-staff there is only "//" without any "c.B." (and I think that Eleanor hinted at the fact that this form is often to be found with other composers - but you know that I am only acquainted with this strange Weber.... :-[ ). So we really have to be careful what we define in the header as the symbols used combined with their "meaning".
>
> 3. As soon as we connect "//" with any form of meaning we are interpreting the signs (and behave as editors - even if we add "col Basso" where we only find //). And Eleanor's examples show that in many cases there is a lot of  wiggle-room here! But if we continue the work of encoding the manuscript of the Freischuetz-overture I think we should differentiate at least between a<symboldef>  of "//" that denotes pure measure (or half-measure) repeats (and are normally used quite strictly: as repetition signs in each measure or at least on the bar-lines if meant for a 2-measure-unit) and those which show a "freer distribution", but at least in Weber's case are preferably used as sign "on a bar-line" for the<goCopy>-mechanism?
>
> Nevertheless a generic element with the function of "go and bring something from another bar here in this place" would really be of some advantage!?
>
> I hope that this makes the discussion not too confusing - but that seems to be my special part at the moment ;-) .
> Best greetings,
> Joachim
>
>
>
>
>
>
>
>
>
>
> Am 03.09.11 18:56, schrieb Raffaele Viglianti:
> Hi Perry,
>
>
>
>
>   isn't "making more explicit" the meaning of something exactly what correcting, regularizing and expanding do?  For instance, if I mark "P.R." as an abbreviation and "Perry Roland" as its expansion, am I not making the meaning of "P.R." more explicit?
>
>
>
>
> I think that in this case, the act of "making explicit" is suggesting a textual replacement:
> P.R. -->  Perry Roland
>
>
> and this is true for all the paired choices of sic/corr, orig/reg, etc. This is an editorial intervention that directly influences the symbols that make the text.
>
>
> In the case of col Basso, the act of "making explicit" is defining a function:
> "col Basso" -->  go and copy the measure below
>
>
> This is why I don't think that there is any editorial intervention here, it is a matter of explaining what this symbol "is". (Let's set aside the fact that arguably, when doing a transcription, everything is editorial interpretation; even using<note>)
>
> the words "col Basso" (or the wiggly line, whatever) remain separate from the realization encoding.  To do otherwise, would wreak havoc upon the distinction between events and control events that's built into MEI.  Unless someone WANTS to start over from scratch. :)
>
>
>
> Ok, I understand and agree, sorry if I jumped to suggesting a new element too fast! :) Still, I think that the direction "col Basso" itself is functioning as a hypothetical "copyOf" element rather than its editorial expansion. But if the direction and its function must be kept separated to follow the event / control event distinction, then fine. What I think should be evident from the encoding, though, is that this falls out of editorial interventions, and falls into the category of saying what some text "is", which is what happens with a lot of MEI elements (this is a note, this is a direction, ...).
>
>
> Best,
> Raffaele
>
>
> BUT, what the content of<expan>  or<reg>  should be is a different question.  In the examples above and in the examples in the TEI guidelines, the content is explicitly stated; that is, every misspelling of the same word carries the same regularization.
>
> For those situations where the regularization exists elsewhere in the encoding, we could create a generic, "go-get-something-and-put-it-here" element.  I only suggested the name "colla" as a discussion-starter.  I believe it probably needs a more generic name, perhaps "copyOf", that would allow it to function in cases other than just colla parte.  Eleanor's point about references occuring just about anywhere is correct, although there's only so far we can go and maintain explicit markup.  Followed to the extreme, the markup becomes entirely procedural, not a good thing.  Already, the<copyOf>  element introduces the same problems @copyof, namely, which parts of the target should actually be copied -- certainly not the target's @xml:id and probably not it's @n either.
>
> For the time being, I'd prefer solutions such as those above that use existing elements / attributes in order not to delay the next release.  We can take up the question of a "copyOf" element and the philosophical issues related to what a regularization "really" is 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 Raffaele Viglianti [raffaeleviglianti at gmail.com]
> Sent: Saturday, September 03, 2011 6:58 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Colla parte
>
>
>
> Dear Joachim and all,
>
>
> Having had the opportunity to look at other parts of der Freischuetz manuscript, I think one might look at this situation in another way: the symbols  // or .//., etc. actually indicate to look back at the previous measure.
> Also in the case that described, I am inclined to think that // actually means a repetition of the instruction col basso to be found in the previous measure.
>
>
> Given this interpretation, it is sufficient to define what "col Basso" does, and the repetition symbols will just copy over the same meaning.
> Basically, if col Basso in this context means "play the current measure at the Basso staff" (which is different from "play the measure with xml:id='foo'"), the same meaning will be repeated by // in the following measure.
>
>
> To define what col Basso does, an element like the one suggested by Perry might be useful. Perhaps<colla target="#STAFFid">col Basso</colla>  or similar.
>
>
> Regarding<supplied>, I think we need to clarify better its role and align it with TEI as much as possible. Perry's use seems a bit incorrect to me, because the element should be used to supply text that cannot be read or is not there at all and should be. In this case the symbol is there, the editor makes its meaning explicit. An element like<colla>  that would somehow include the objections of the people at the back of the room, might be sufficient to make explicit the meaning of the symbol in question.
>
>
> Using sic / corr or orig / reg or abbr / expan seems a bit odd to me as well, because it's not a matter of replacing one (or many) symbol(s) with another (or many others) for the purpose of correcting, regularizing or expanding, but it's a matter of making more explicit the meaning of a less-standard sign.
>
>
> Hope this helps!
>
>
> Raffaele
>
>
> On Fri, Sep 2, 2011 at 11:58 PM, Roland, Perry (pdr4h)<pdr4h at eservices.virginia.edu>  wrote:
>
> Hi Joachim,
>
> Let me re-state the issue to see if I understand it correctly --
>
> 1. Weber (is there any other composer worth talking about?) draws some version of a slash-symbol-thing to indicate that the current measure should be filled in with material from another instrument.
>
> 2. You want to record the original version (with the slash symbol) and give its "expansion" (as it were)?
>
> First, are you sure this problem can't be resolved using<orig>  and<supplied>  (or perhaps<reg>)?  For example, each measure of the flute part might be encoded --
>
> <measure>
>   <staff n="1">
>    <layer>
>      <choice>
>        <orig>  <!-- some repetition sign(s) here -->  </orig>
>        <supplied>  <!-- a copy of the content of the vln. part -->  </supplied>
>      </choice>
>    </layer>
>   </staff>
> <dir staff="1" tstamp="1">colla parte ...</dir>
> <!-- instead of the words there might be a<line>  -->
> </measure>
>
> This seems like a good solution to me because it is explict.
>
> I'm using<supplied>  because the actual substitution doesn't take place in the score, there's only an indication that it "ought" to happen. Actually making it happen is up to the editor -- the human being, not the software.
>
> Of course, what's missing is a link between the<supplied>  element and the words "colla ..." (or a "wiggly" line), which I presume is in the flute part). At present, the editorial intervention can only be explained in the editorialDecl.  But, if we put our heads together, we might be able to think of another method of linking these.  (Perhaps with an<annotation>, which has pointers to the "participants"; that is, the<supplied>  and<dir>  elements, and a type attribute value of "collaparte"?)
>
> I don't know if you remember, but MEI originally had a different definition for<mRpt>.  It didn't necessarily indicate the repetition of the preceding measure, but rather the repetition *of any other measure*, "repetition" being defined somewhat loosely, of course.  This definition went the way of the dodo bird when the editorial elements (add, del, orig, reg, etc.) were added since the attribute (don't remember what it was called off the top of my head) pointing to the source measure duplicated these editorial elements' function.
>
> However, I recognize that there's currently no good way of implementing a reference to content given elsewhere in the document.  So, perhaps we should consider adding such a specialized element.  In the example above, the content of<supplied>  would be the<colla>  (or some such name) element.
>
> <measure n="1">
>   <staff>
>    <layer>
>      <choice>
>        <orig>  <!-- some repetition sign(s) here -->  </orig>
>        <supplied>  <colla/>  </supplied>
>      </choice>
>    </layer>
>   </staff>
> </measure>
>
> Of course, it would need an attribute pointing to the content of the vln. part.  In a way, this element would be similar to<ref>, although<ref>  is intended for navigation, while<colla>  indicates "go get the content and put it here."  This is also not unlike internal parsed entities. This element would also need to be related to the<dir>  or<line>  elements. We could think about using its generic corresp attribute or give it a new, specialized attribute.
>
> (I can already hear some noises in the back of the room about some attribute or attributes for describing whatever transformation must be applied to the source, such as "transposed up a 5th", "inverted and retrograde", etc.  I'm not ready to go there yet!  There be dragons!)
>
> It might also need a more generic name than "colla".  Then it could be used for other situations where content given in one location needs to be referenced in some other.  Can't think of a good name off the top of my head, too late in the day.
>
> Just in case someone asks, I don't think XInclude can point to a location in the current document.
>
> Enough to think about for the weekend?  :)
>
> --
> 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 Joachim Veit [veit at weber-gesamtausgabe.de]
> Sent: Friday, September 02, 2011 3:43 PM
> To: mei-l at lists.uni-paderborn.de
> Subject: [MEI-L] Colla parte
>
>
> Dear MEI-L-Readers,
>
> when encoding manuscripts MEI has the possibility to encode
> measure-repeats or half-measure-repeats which are found in the original
> manuscripts in a form similar to: // or .//.  (two strokes through the
> barlines or something similar) with<mrpt>  or<halfmrpt>. This has
> always a clear reference to the bar (or half-bar) before.
>
> The same symbols are used in manuscripts in combination with the "col
> Basso" or other "colla-parte"-instructions.
> Again in Weber's Freischuetz-Overture (we never do something other...)
> we have a contrabbasso with<staff n="16">  and above this the
> violoncello with<staff n="15>. Weber notates the contrabbasso in a
> normal way and in the cello-staff we find only "c. B." (= bar 1) and
> afterwards //   //    // etc.
> For a modern edition we could label the layer of the contrabbasso with
> an xml:id="2011" and put in the layer of staff 15:<layer n="1"
> copyof="2011"/>.
>
> But in this case we want to encode the "original" situation! So we first
> have to define in the scoredef:
> <scoredef>....
> <symboltable>
> <symboldef xml:id="symCollaParte"/>  <!-- here we describe the symbol(s)
> Weber and others use in this case -->
> </symboltable>
> </scoredef>
>
> and within our staff 15:
> <staff n="15">
> <layer n="1">
> <symbol ref="symCollaParte"/>
> </layer>
> </staff>
> In this case the reference is not always clear: it might go to the staff
> below (as in this case) or the staff above (if the cello is written out
> and the cb-staff is pointing to the cello) or even from a flute to the
> first violin 5 systems below. So there should be some mechanism to make
> clear where the model is situated. And second: We should have the
> possibility to use "c. B." (or something similar) as a symbol-phrase
> (which at the same time "defines" the model) and for the following bars
> simply use "//" (or something similar) (maybe even one symbol for 2-3
> bars together??).
> Is this case already considered in the future guidelines?
>
> Best greetings and a happy weekend,
> Joachim
>
> _______________________________________________
> 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

-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : veit.vcf
Dateityp    : text/x-vcard
Dateigr??e  : 364 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110907/11ea919d/attachment.vcf>

From pdr4h at eservices.virginia.edu  Wed Sep  7 15:15:38 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Wed, 7 Sep 2011 13:15:38 +0000
Subject: [MEI-L] Colla parte
In-Reply-To: <4E672620.8080707@weber-gesamtausgabe.de>
References: <EA33CE5D-36C7-4CFE-87B3-E5A103CE5664@edirom.de>
	<4E6131EC.1060508@weber-gesamtausgabe.de>
	<BBCC497C40D85642B90E9F94FC30343D74F84C@GRANT.eservices.virginia.edu>
	<CAMyHAnNn1zS4BUdd=UMoB0zSCgvLE2bjX4x8P6V4PcPOiyEfNw@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D75293D@GRANT.eservices.virginia.edu>
	<CAMyHAnP+GNa+-UeoBTTCEcjLN2p22cBCvStMqTzuR2q_6J57NQ@mail.gmail.com>,
	<4E6684E3.4080200@weber-gesamtausgabe.de>
	<BBCC497C40D85642B90E9F94FC30343D755E95@GRANT.eservices.virginia.edu>,
	<4E672620.8080707@weber-gesamtausgabe.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D75634A@GRANT.eservices.virginia.edu>

Joachim,

Of course, this solution, like any other, has a hidden dragon or two or three:

1. It's a general solution for a specific problem and therefore runs the risk of overloading the semantics of <ref>.

2. It won't be possible to add that transformational stuff I alluded to in an earlier message (if we ever want to), such as "go get that stuff and transpose it up a 4th."

3. There are technical issues with actually implementing it.  It requires implementing some kind of "look ahead" procedure if the data is being processed as a stream or getting the entire file into memory and then resolving the reference. In other words, it requires multiple passes through the data.  It might be best to encourage the resolution of these references via MEIron.

Even so, these are the documents we have to represent.  I'm not 100% certain, but I'm pretty sure that Weber wasn't intentionally trying to confound our markup scheme. :)

--
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 Joachim Veit [veit at weber-gesamtausgabe.de]
Sent: Wednesday, September 07, 2011 4:06 AM
To: mei-l at lists.uni-paderborn.de
Subject: Re: [MEI-L] Colla parte

Hi Perry,
that sounds perfectly reasonable - many thanks!! The huge advantage of
this procedure is the possibility to separate the stuff which has to be
embedded, e.g. we could embed only the notes but also the dynamics and
not the articulation or something vice versa or double vice versa...
And the semantics of pointer is really the thing which Raffaele meant
too, I think?
In so far I am really happy with this solution - and we shall be
experimenting until we find the dragon which maybe is hidden behind the
next corner (>:o ...). But for the moment we stay absolutely 8-) !
Best greetings, while we again are spending our time for our most
esteemed work: writing a new grant proposal....
Joachim


Am 07.09.11 00:30, schrieb Roland, Perry (pdr4h):
> Hi Joachim,
>
> After some thinking about it, I don't believe we need a new element to describe the "go-get-something-and-put-it-here" behavior.  The xlink attributes available on<ref>  and<ptr>  will do the job.
>
> In the following example, the 1st staff contains a symbol that indicates the contents of the 2nd staff should be inserted.  This can be indicated using the actuate and show attributes on<ptr>  -- @show says what to do (embed=put the content here) and @actuate says when to do it (onLoad=when I load the document).
>
> <measure>
>    <staff>
>      <layer>
>        <!-- Colla parte -->
>        <choice>
>          <abbr>
>            <symbol ref="#p1"/>
>          </abbr>
>          <expan>
>            <!-- reference to the contents of the bass part -->
>            <ptr target="#basso" xlink:actuate="onLoad" xlink:show="embed"/>
>          </expan>
>        </choice>
>      </layer>
>    </staff>
>    <staff>
>      <layer xml:id="basso">
>        <note/>
>        <note/>
>        <rest/>
>        <note/>
>      </layer>
>    </staff>
> </measure>
>
> A means for identifying the content of the target that should be processed is not available, but an @xpointer attribute could be added for this purpose.  Using xpointer syntax one could say "get the contents (or some of the contents) of the element called "basso", NOT the element itself. For example,
>
> <ptr target="#basso"  xlink:actuate="onLoad" xlink:show="embed" xpointer="element(basso/note)"/>
>
> would retrieve and embed the note children of "basso", but not the rest.  If @xpointer was not present, either the element identified as "basso" or its contents could be retrieved, depending on the behavior we want to define. However, the first behavior would be a re-implementation of @copyOf, so the second seems like a more logical default.
>
> --
> 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 Joachim Veit [veit at weber-gesamtausgabe.de]
> Sent: Tuesday, September 06, 2011 4:38 PM
> To: mei-l at lists.uni-paderborn.de
> Subject: Re: [MEI-L] Colla parte
>
>
> Dear Eleanor, Perry and Raffaele,
> thanks a lot for this helpful discussion (or the beginning of a discussion for release 2013/05 ?)
> <quote resp="Perry">"Enough to think about for the weekend?"</quote>
> Perry, you see that this was for more than one weekend ;-)  , and please excuse the late answer.
>
> 1. First I think that for the first we can live with your proposal of using<choice>  together with orig/reg or abbr/expan.
> For a longer term we should, maybe, prefer to have your<ggsapih>  ("go-get-something-and-put-it-here") or something generic - not<copyOf>  but something in Raffaele's sense:<goCopy>  (go and copy the measure below).
> Concerning<reg>  and<expan>  I normally understand them as giving the "resolved abbreviation" in the form a "today's user" is used to, e.g. a fully expanded form of a half note with a stroke through the stem (as a mark for repetition of four eighth-notes). But in the context of the manuscript "//" as a colla-parte-sign may signal that you "go and copy the measure below" and that measure may consist of two half notes with strokes through the stem - and this has nothing to do with expansion or regularization. Thus I think that the solution is ok for the next release but not a fully satisfying one?
>
> 2. Concerning Raffaele's hint that the double lines // (or something similar) have to be seen in conjunction with the "c.B."<quote resp:"Raffaele">"if col Basso ... means 'play the current measure at the Basso staff' ..., the same meaning will be repeated by // in the following measure</quote>  struck me at the first reading as a totally convincing interpretation of the "//" signs. But returning to the manuscript I begin to be a doubting Thomas again. Please haave a lookt at: http://digital.staatsbibliothek-berlin.de/dms/werkansicht/?PPN=PPN65499935X&PHYSID=PHYS_0064
> There you find "col Tenore" and "col Basso" (bottom-middle) and the strokes // are beneath these words - so they are not a repetition sign here. And differing from the measure-repeats in the last bars of this page in violins and violas (staff 7-9 from top) we find the next hints in the chorus staffs (no. 2-3 from bottom) as double lines // crossing the bar line (that is continued on the next page). And as a further motive we have the "unis:[ono] in line 5 from top (middle)", again with a //-sign. (Besides: the // in b. 3/4 of the flute - staff 1 from top - are a repetition sign for bars 1/2 on this page) - so the "//" has very different meanings here, but always have something to to with "repetion".
> In the case of "colla parte", "in 8va", "col Basso", "unisono" etc. it is not necessary that this verbal "prescription" is explicit: Look at:
> bibliothek-berlin.de/dms/werkansicht/?PPN=PPN65499935X&PHYSID=PHYS_0025&USE=800
> In the cello-staff there is only "//" without any "c.B." (and I think that Eleanor hinted at the fact that this form is often to be found with other composers - but you know that I am only acquainted with this strange Weber.... :-[ ). So we really have to be careful what we define in the header as the symbols used combined with their "meaning".
>
> 3. As soon as we connect "//" with any form of meaning we are interpreting the signs (and behave as editors - even if we add "col Basso" where we only find //). And Eleanor's examples show that in many cases there is a lot of  wiggle-room here! But if we continue the work of encoding the manuscript of the Freischuetz-overture I think we should differentiate at least between a<symboldef>  of "//" that denotes pure measure (or half-measure) repeats (and are normally used quite strictly: as repetition signs in each measure or at least on the bar-lines if meant for a 2-measure-unit) and those which show a "freer distribution", but at least in Weber's case are preferably used as sign "on a bar-line" for the<goCopy>-mechanism?
>
> Nevertheless a generic element with the function of "go and bring something from another bar here in this place" would really be of some advantage!?
>
> I hope that this makes the discussion not too confusing - but that seems to be my special part at the moment ;-) .
> Best greetings,
> Joachim
>
>
>
>
>
>
>
>
>
>
> Am 03.09.11 18:56, schrieb Raffaele Viglianti:
> Hi Perry,
>
>
>
>
>   isn't "making more explicit" the meaning of something exactly what correcting, regularizing and expanding do?  For instance, if I mark "P.R." as an abbreviation and "Perry Roland" as its expansion, am I not making the meaning of "P.R." more explicit?
>
>
>
>
> I think that in this case, the act of "making explicit" is suggesting a textual replacement:
> P.R. -->  Perry Roland
>
>
> and this is true for all the paired choices of sic/corr, orig/reg, etc. This is an editorial intervention that directly influences the symbols that make the text.
>
>
> In the case of col Basso, the act of "making explicit" is defining a function:
> "col Basso" -->  go and copy the measure below
>
>
> This is why I don't think that there is any editorial intervention here, it is a matter of explaining what this symbol "is". (Let's set aside the fact that arguably, when doing a transcription, everything is editorial interpretation; even using<note>)
>
> the words "col Basso" (or the wiggly line, whatever) remain separate from the realization encoding.  To do otherwise, would wreak havoc upon the distinction between events and control events that's built into MEI.  Unless someone WANTS to start over from scratch. :)
>
>
>
> Ok, I understand and agree, sorry if I jumped to suggesting a new element too fast! :) Still, I think that the direction "col Basso" itself is functioning as a hypothetical "copyOf" element rather than its editorial expansion. But if the direction and its function must be kept separated to follow the event / control event distinction, then fine. What I think should be evident from the encoding, though, is that this falls out of editorial interventions, and falls into the category of saying what some text "is", which is what happens with a lot of MEI elements (this is a note, this is a direction, ...).
>
>
> Best,
> Raffaele
>
>
> BUT, what the content of<expan>  or<reg>  should be is a different question.  In the examples above and in the examples in the TEI guidelines, the content is explicitly stated; that is, every misspelling of the same word carries the same regularization.
>
> For those situations where the regularization exists elsewhere in the encoding, we could create a generic, "go-get-something-and-put-it-here" element.  I only suggested the name "colla" as a discussion-starter.  I believe it probably needs a more generic name, perhaps "copyOf", that would allow it to function in cases other than just colla parte.  Eleanor's point about references occuring just about anywhere is correct, although there's only so far we can go and maintain explicit markup.  Followed to the extreme, the markup becomes entirely procedural, not a good thing.  Already, the<copyOf>  element introduces the same problems @copyof, namely, which parts of the target should actually be copied -- certainly not the target's @xml:id and probably not it's @n either.
>
> For the time being, I'd prefer solutions such as those above that use existing elements / attributes in order not to delay the next release.  We can take up the question of a "copyOf" element and the philosophical issues related to what a regularization "really" is 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 Raffaele Viglianti [raffaeleviglianti at gmail.com]
> Sent: Saturday, September 03, 2011 6:58 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Colla parte
>
>
>
> Dear Joachim and all,
>
>
> Having had the opportunity to look at other parts of der Freischuetz manuscript, I think one might look at this situation in another way: the symbols  // or .//., etc. actually indicate to look back at the previous measure.
> Also in the case that described, I am inclined to think that // actually means a repetition of the instruction col basso to be found in the previous measure.
>
>
> Given this interpretation, it is sufficient to define what "col Basso" does, and the repetition symbols will just copy over the same meaning.
> Basically, if col Basso in this context means "play the current measure at the Basso staff" (which is different from "play the measure with xml:id='foo'"), the same meaning will be repeated by // in the following measure.
>
>
> To define what col Basso does, an element like the one suggested by Perry might be useful. Perhaps<colla target="#STAFFid">col Basso</colla>  or similar.
>
>
> Regarding<supplied>, I think we need to clarify better its role and align it with TEI as much as possible. Perry's use seems a bit incorrect to me, because the element should be used to supply text that cannot be read or is not there at all and should be. In this case the symbol is there, the editor makes its meaning explicit. An element like<colla>  that would somehow include the objections of the people at the back of the room, might be sufficient to make explicit the meaning of the symbol in question.
>
>
> Using sic / corr or orig / reg or abbr / expan seems a bit odd to me as well, because it's not a matter of replacing one (or many) symbol(s) with another (or many others) for the purpose of correcting, regularizing or expanding, but it's a matter of making more explicit the meaning of a less-standard sign.
>
>
> Hope this helps!
>
>
> Raffaele
>
>
> On Fri, Sep 2, 2011 at 11:58 PM, Roland, Perry (pdr4h)<pdr4h at eservices.virginia.edu>  wrote:
>
> Hi Joachim,
>
> Let me re-state the issue to see if I understand it correctly --
>
> 1. Weber (is there any other composer worth talking about?) draws some version of a slash-symbol-thing to indicate that the current measure should be filled in with material from another instrument.
>
> 2. You want to record the original version (with the slash symbol) and give its "expansion" (as it were)?
>
> First, are you sure this problem can't be resolved using<orig>  and<supplied>  (or perhaps<reg>)?  For example, each measure of the flute part might be encoded --
>
> <measure>
>   <staff n="1">
>    <layer>
>      <choice>
>        <orig>  <!-- some repetition sign(s) here -->  </orig>
>        <supplied>  <!-- a copy of the content of the vln. part -->  </supplied>
>      </choice>
>    </layer>
>   </staff>
> <dir staff="1" tstamp="1">colla parte ...</dir>
> <!-- instead of the words there might be a<line>  -->
> </measure>
>
> This seems like a good solution to me because it is explict.
>
> I'm using<supplied>  because the actual substitution doesn't take place in the score, there's only an indication that it "ought" to happen. Actually making it happen is up to the editor -- the human being, not the software.
>
> Of course, what's missing is a link between the<supplied>  element and the words "colla ..." (or a "wiggly" line), which I presume is in the flute part). At present, the editorial intervention can only be explained in the editorialDecl.  But, if we put our heads together, we might be able to think of another method of linking these.  (Perhaps with an<annotation>, which has pointers to the "participants"; that is, the<supplied>  and<dir>  elements, and a type attribute value of "collaparte"?)
>
> I don't know if you remember, but MEI originally had a different definition for<mRpt>.  It didn't necessarily indicate the repetition of the preceding measure, but rather the repetition *of any other measure*, "repetition" being defined somewhat loosely, of course.  This definition went the way of the dodo bird when the editorial elements (add, del, orig, reg, etc.) were added since the attribute (don't remember what it was called off the top of my head) pointing to the source measure duplicated these editorial elements' function.
>
> However, I recognize that there's currently no good way of implementing a reference to content given elsewhere in the document.  So, perhaps we should consider adding such a specialized element.  In the example above, the content of<supplied>  would be the<colla>  (or some such name) element.
>
> <measure n="1">
>   <staff>
>    <layer>
>      <choice>
>        <orig>  <!-- some repetition sign(s) here -->  </orig>
>        <supplied>  <colla/>  </supplied>
>      </choice>
>    </layer>
>   </staff>
> </measure>
>
> Of course, it would need an attribute pointing to the content of the vln. part.  In a way, this element would be similar to<ref>, although<ref>  is intended for navigation, while<colla>  indicates "go get the content and put it here."  This is also not unlike internal parsed entities. This element would also need to be related to the<dir>  or<line>  elements. We could think about using its generic corresp attribute or give it a new, specialized attribute.
>
> (I can already hear some noises in the back of the room about some attribute or attributes for describing whatever transformation must be applied to the source, such as "transposed up a 5th", "inverted and retrograde", etc.  I'm not ready to go there yet!  There be dragons!)
>
> It might also need a more generic name than "colla".  Then it could be used for other situations where content given in one location needs to be referenced in some other.  Can't think of a good name off the top of my head, too late in the day.
>
> Just in case someone asks, I don't think XInclude can point to a location in the current document.
>
> Enough to think about for the weekend?  :)
>
> --
> 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 Joachim Veit [veit at weber-gesamtausgabe.de]
> Sent: Friday, September 02, 2011 3:43 PM
> To: mei-l at lists.uni-paderborn.de
> Subject: [MEI-L] Colla parte
>
>
> Dear MEI-L-Readers,
>
> when encoding manuscripts MEI has the possibility to encode
> measure-repeats or half-measure-repeats which are found in the original
> manuscripts in a form similar to: // or .//.  (two strokes through the
> barlines or something similar) with<mrpt>  or<halfmrpt>. This has
> always a clear reference to the bar (or half-bar) before.
>
> The same symbols are used in manuscripts in combination with the "col
> Basso" or other "colla-parte"-instructions.
> Again in Weber's Freischuetz-Overture (we never do something other...)
> we have a contrabbasso with<staff n="16">  and above this the
> violoncello with<staff n="15>. Weber notates the contrabbasso in a
> normal way and in the cello-staff we find only "c. B." (= bar 1) and
> afterwards //   //    // etc.
> For a modern edition we could label the layer of the contrabbasso with
> an xml:id="2011" and put in the layer of staff 15:<layer n="1"
> copyof="2011"/>.
>
> But in this case we want to encode the "original" situation! So we first
> have to define in the scoredef:
> <scoredef>....
> <symboltable>
> <symboldef xml:id="symCollaParte"/>  <!-- here we describe the symbol(s)
> Weber and others use in this case -->
> </symboltable>
> </scoredef>
>
> and within our staff 15:
> <staff n="15">
> <layer n="1">
> <symbol ref="symCollaParte"/>
> </layer>
> </staff>
> In this case the reference is not always clear: it might go to the staff
> below (as in this case) or the staff above (if the cello is written out
> and the cb-staff is pointing to the cello) or even from a flute to the
> first violin 5 systems below. So there should be some mechanism to make
> clear where the model is situated. And second: We should have the
> possibility to use "c. B." (or something similar) as a symbol-phrase
> (which at the same time "defines" the model) and for the following bars
> simply use "//" (or something similar) (maybe even one symbol for 2-3
> bars together??).
> Is this case already considered in the future guidelines?
>
> Best greetings and a happy weekend,
> Joachim
>
> _______________________________________________
> 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

From kristina.richts at gmx.de  Mon Sep 12 11:44:48 2011
From: kristina.richts at gmx.de (Kristina Richts)
Date: Mon, 12 Sep 2011 11:44:48 +0200
Subject: [MEI-L] Update MEI-website
Message-ID: <D3D510B3-5D23-4A2C-9EE7-B075476F8A31@gmx.de>

Dear all,

to make music-encoding.org/ a little bit more up to date, I have a small request: 
The menu item "Projects" on the website provides the opportunity to introduce all ongoing projects on MEI.
As the number of projects working on and with MEI highly increased within the last years, this development
should be visualized on the website. For this aim, I would be very glad, if all of you, who work on MEI-projects,
could send me the following project details:
- official name of the project,
- person(s) responsible,
- short description of the project.

The same applies for any change requests concerning details given on the website. Please tell me and I will
update this for you as soon as possible.

Thank you very much and best regards from Detmold,
Kristina



From kepper at edirom.de  Mon Sep 19 10:57:20 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 19 Sep 2011 10:57:20 +0200
Subject: [MEI-L] Report of the Council Meeting 2011
Message-ID: <F42F9B13-B356-4DD3-AA42-733307832E61@edirom.de>

Dear list-members,

although many of you have been part of this, we believe that a detailed report on this year's Council meeting is of interest for the whole community. I'm very sorry for the long delay ? we've been busy disseminating MEI on several conferences, a summer school etc. I you think we've missed anything, or in case you have other questions regarding the meeting, feel free to comment on this. 

On behalf of the Charlottesville / Detmold Team,
Johannes Kepper

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

Report of the annual meeting of the MEI Council and the Technical Team Meeting in Detmold, 18?21 July 2011

This year?s annual meeting of the MEI Council was a virtual conference held on 18 and 19 July 2011. Participants were Richard Freedman, Axel Teich Geertinger, Erin Mayhood, Daniel Pitti, Eleanor Selfridge-Field, Christine Siegert and Frans Wiering. At the same time, the so-called Technical Team and other participants from Detmold (Benjamin W. Bohl, Julian Dabbert, Maja Hartwig, Johannes Kepper, Laurent Pugin, Kristina Richts, Perry Roland, Daniel R?wenstrunk, Craig Stuart Sapp, Joachim Veit and Raffaele Viglianti) met in Detmold for this conference. They were joined by Thomas Weber, developer of a MEI-based SVG-renderer for CMN, and Ichiro Fujinaga and Andrew Hankinson from McGill University.

The agenda of the meeting included short updates on recent developments in MEI-related projects, discussion of organizational issues, and a status report on preparations for the next release of the schema.

The project updates were given by Andrew Hankinson (use of MEI for an online version of the Liber usualis), Christine Siegert (issues of encoding canons in MEI), Raffaele Viglianti (combining MEI and TEI for source transcriptions), Richard Freedman (update on the Du Chemin project), Craig Sapp (transformation from MEI to SCORE) and Julian Dabbert (update on the MEI Score Editor). The presentations demonstrated a wide range of possible use cases for MEI and showed the success of MEI's dissemination efforts.

Afterwards, a number of significant changes to the schema proposed for the next release were presented and discussed under the guidance of the Technical Team. Although many of the changes discussed will break compatibility between the current 2010-05 release and its successor, the participants consented that they are useful contributions to MEI and should be adopted sooner rather than later. Changes to the schema, especially ?non-conforming? ones, will be documented and a program to make MEI files encoded using the 2010 release valid against the next release will be provided.

In the last part of the virtual meeting, the current structure of the MEI Council was discussed. It was generally agreed to stay with the current model and to accept new members by consent of the current membership. At this point, all participants that were not officially enrolled were welcomed as new Council members. Likewise, the Technical Team was commissioned to select its members on its own. The project website at http://music-encoding.org will reflect current memberships as soon as possible. Another organizational issue was the possibility of joining forces with other organizations, such as the International Association of Music Libraries (IAML). Although this would offer benefits such as annual meetings, membership and financial services, etc., it was agreed that MEI should remain independent for the time being. Further discussion on these issues was deferred to a scheduled face-to-face meeting in 2013 at the end of the current DFG/NEH grant.

After the virtual meeting, the Technical Team met for two more days to work on important details of the next release of MEI. In addition to other topics such as treatment of ossias, figured bass, etc., the two most important issues were the creation of MEI Guidelines and a set of tools called MEIron.

Whereas the Schema and Tag Library address the needs of developers, corresponding documentation focused on the needs of scholars / encoders is still missing. This gap will be filled by the MEI Guidelines, which will be structured following the current module structure of the schema. It is envisioned that this document will cover the complete specification of MEI, and will combine verbal descriptions with examples of how to use certain features. It was consented that the Guidelines should be written collaboratively following instructions given by Perry Roland and Johannes Kepper. First assignments to specific chapters have been made already, but the size of this project requires voluntary support of Council members and non-members alike. It is currently planned to offer a first, albeit incomplete version of the Guidelines together with the next release of MEI.

The other main topic of the Technical Team meeting was the preparation for a toolset called MEIron. This toolset will serve different purposes. First, it will offer a way to ?flatten out? (hence the name) multiple reading paths in MEI files, which is a technical requirement for many use cases of MEI files (conversion to other formats, rendering etc.), even though this alteration is ?lossy?. Since few, if any, other formats offer the capability of capturing alternative paths at the same level as MEI, nearly all developers of transforming applications must implement some form of this ?reduction?. By providing MEIron, we hope to relieve developers of the burden of creating code for this procedure for every new transformation target and to standardize the transformation itself. Second, since MEI allows one to encode certain features in multiple ways, e.g., ties can be encoded as attributes on notes or as separate elements that refer to notes either by timestamp or by pointing to IDs, MEIron will provide a method for creating ?canonical? encodings. This will allow applications to support only one of the encoding alternatives for a given feature. MEIron will be parameterized to allow selection of the appropriate alternative for the application.

The Technical Team does not currently have the resources to develop such a tool as a stand-alone application. Instead, it is planned to offer the MEIron as a set of XSLT files that serve as model for implementations. All implementations will then have to conform to the transformation exemplified in the Council's XSLT. Several components offering parts of this are already in use; the Technical Team will collect and review these components, will embed them in a plan for further developments and make everything accessible on the website.

Also, it was agreed that the Technical Team should meet quarterly using the virtual meeting software provided by UVa. The next meeting is scheduled for the late October / early November 2011.



From Maja.Hartwig at gmx.de  Mon Sep 19 13:13:37 2011
From: Maja.Hartwig at gmx.de (Maja Hartwig)
Date: Mon, 19 Sep 2011 13:13:37 +0200
Subject: [MEI-L] MEIron
Message-ID: <20110919111337.257320@gmx.net>

Dear MEI-List!
As you have noticed in the report Johannes sent earlier, the MEIron was a main topic of the Technical Team meeting. A lot of work has already been done on this, and Detmold has offered to coordinate the next steps on this. Therefore, I would like to ask you all for information about tools falling under this category that you might have already developed. I'm interested in everything that normalizes, simplifies, or in any other way modifies MEI files. Even non-working or planned code is relevant for this, so please don't hesitate to contact me, either on the list or off-list. The Technical Team will then try to bring up a plan on how to merge these tools into something generally useful for all MEI users.

Thanks for your help, and best regards from the Detmoldians,

Maja
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zur?ck-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone


From andrew.hankinson at mail.mcgill.ca  Tue Sep 20 07:05:51 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 20 Sep 2011 05:05:51 +0000
Subject: [MEI-L] Notation type
Message-ID: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>

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

From pdr4h at eservices.virginia.edu  Tue Sep 20 15:12:46 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Tue, 20 Sep 2011 13:12:46 +0000
Subject: [MEI-L] Notation type
In-Reply-To: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>

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

From raffaeleviglianti at gmail.com  Tue Sep 20 16:11:57 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Tue, 20 Sep 2011 15:11:57 +0100
Subject: [MEI-L] Notation type
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>
Message-ID: <CAMyHAnMPkfwnZp2AoDMiVtG4rL-O+a-oA8uBbFM49a=75Oa04Q@mail.gmail.com>

Hello,


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

As far as I know, TEI's guidelines keep agnostic on the typology of document
being encoded, or the script used, etc.

Let alone the fact that TEI's <text> structure roughly mimes a book (front,
body, back), I think they didn't provide a closed list of types of documents
to avoid the abuse that you see in LaTeX, where "article", "report", etc.
have become a setting for formatting behaviour, rather than indicate that a
document really is an article or a report.

The manuscript description component of the TEI header could function as
example for this specific situation. There is <scriptDesc> and
*cough*<musicNotation>*ack* that both contain a prosaic description of
scripts or the music notation found in the manuscript. <scriptDesc>, having
been thought out better than <musicNotation>, also contains <scriptNote>,
which surrounds the specific type of script (e.g. <scriptNote
xml:id="CM">carolingian minuscule</scriptNote>) that can be referred within
the text (e.g. <handShift script="#CM" />.

Following this example, describing a music text's notation would be the
encoder's responsibility and there'd be no restriction on how it'd be
expressed, only "where". Which means, of course, that for non-standard
notation you'd need a human to figure out exactly what notation the document
uses. MEI could provide an element where to do put this sort of description
in the header. The TEI examples above come from sourceDesc/msDesc, but in
our case one may want to specify the typology of notation regardless of
whether the MEI has a physical source or not...

I think that looking at the modules used can give a good hint to an
application trying to determine the notation(s) used in the MEI document.
For a more detailed classification, the application can at least locate a
<musicNotationDesc> (or equivalent, especially if we can repurpose an
existing element) and return it to a human reader who should be able to make
sense of it. Finally, being able to point to descriptions of different
notating styles (equivalent to <tei:scriptNote>) could be helpful to
describe changes in notating styles within one document (e.g. if a choir
book switches from neumatic to mensural -not sure if this makes historical
sense, but I imagine it could?).

Hope this helps!

Best,
Raffaele



> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110920/bf1883f8/attachment.html>

From andrew.hankinson at mail.mcgill.ca  Tue Sep 20 17:17:12 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 20 Sep 2011 15:17:12 +0000
Subject: [MEI-L] Notation type
In-Reply-To: <7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>
Message-ID: <BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>

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



From pdr4h at eservices.virginia.edu  Tue Sep 20 19:26:54 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Tue, 20 Sep 2011 17:26:54 +0000
Subject: [MEI-L] Notation type
In-Reply-To: <BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>,
	<BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D011044D2@GRANT.eservices.virginia.edu>

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

From andrew.hankinson at mail.mcgill.ca  Wed Sep 21 02:40:14 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Wed, 21 Sep 2011 00:40:14 +0000
Subject: [MEI-L] Notation type
In-Reply-To: <15465_1316539628_4E78CCEB_15465_306_1_BBCC497C40D85642B90E9F94FC30343D011044D2@GRANT.eservices.virginia.edu>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>,
	<BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>
	<15465_1316539628_4E78CCEB_15465_306_1_BBCC497C40D85642B90E9F94FC30343D011044D2@GRANT.eservices.virginia.edu>
Message-ID: <CE73D41D-E877-488C-B467-27B13470EB97@mail.mcgill.ca>

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



From stadler at edirom.de  Wed Sep 21 13:37:09 2011
From: stadler at edirom.de (Peter Stadler)
Date: Wed, 21 Sep 2011 13:37:09 +0200
Subject: [MEI-L] Notation type
In-Reply-To: <CE73D41D-E877-488C-B467-27B13470EB97@mail.mcgill.ca>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>,
	<BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>
	<15465_1316539628_4E78CCEB_15465_306_1_BBCC497C40D85642B90E9F94FC30343D011044D2@GRANT.eservices.virginia.edu>
	<CE73D41D-E877-488C-B467-27B13470EB97@mail.mcgill.ca>
Message-ID: <5BE9B46C-EB89-4C60-80A1-81859ACDA4CA@edirom.de>

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



From andrew.hankinson at mail.mcgill.ca  Wed Sep 21 15:29:01 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Wed, 21 Sep 2011 13:29:01 +0000
Subject: [MEI-L] Notation type
In-Reply-To: <1966_1316605043_4E79CC72_1966_152_1_5BE9B46C-EB89-4C60-80A1-81859ACDA4CA@edirom.de>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>,
	<BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>
	<15465_1316539628_4E78CCEB_15465_306_1_BBCC497C40D85642B90E9F94FC30343D011044D2@GRANT.eservices.virginia.edu>
	<CE73D41D-E877-488C-B467-27B13470EB97@mail.mcgill.ca>
	<1966_1316605043_4E79CC72_1966_152_1_5BE9B46C-EB89-4C60-80A1-81859ACDA4CA@edirom.de>
Message-ID: <8A20E550-E5B3-4B92-AA2A-0F2B0FE5D955@mail.mcgill.ca>

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



From raffaeleviglianti at gmail.com  Wed Sep 21 15:51:52 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Wed, 21 Sep 2011 14:51:52 +0100
Subject: [MEI-L] Notation type
In-Reply-To: <8A20E550-E5B3-4B92-AA2A-0F2B0FE5D955@mail.mcgill.ca>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>
	<BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>
	<15465_1316539628_4E78CCEB_15465_306_1_BBCC497C40D85642B90E9F94FC30343D011044D2@GRANT.eservices.virginia.edu>
	<CE73D41D-E877-488C-B467-27B13470EB97@mail.mcgill.ca>
	<1966_1316605043_4E79CC72_1966_152_1_5BE9B46C-EB89-4C60-80A1-81859ACDA4CA@edirom.de>
	<8A20E550-E5B3-4B92-AA2A-0F2B0FE5D955@mail.mcgill.ca>
Message-ID: <CAMyHAnMDvohEmarZB2gHOw8BPPMFpFQ-Gmm_AhXv+vLrq8GZBA@mail.gmail.com>

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>

From kepper at edirom.de  Wed Sep 21 16:18:00 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Wed, 21 Sep 2011 16:18:00 +0200
Subject: [MEI-L] Notation type
In-Reply-To: <CAMyHAnMDvohEmarZB2gHOw8BPPMFpFQ-Gmm_AhXv+vLrq8GZBA@mail.gmail.com>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>
	<BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>
	<15465_1316539628_4E78CCEB_15465_306_1_BBCC497C40D85642B90E9F94FC30343D011044D2@GRANT.eservices.virginia.edu>
	<CE73D41D-E877-488C-B467-27B13470EB97@mail.mcgill.ca>
	<1966_1316605043_4E79CC72_1966_152_1_5BE9B46C-EB89-4C60-80A1-81859ACDA4CA@edirom.de>
	<8A20E550-E5B3-4B92-AA2A-0F2B0FE5D955@mail.mcgill.ca>
	<CAMyHAnMDvohEmarZB2gHOw8BPPMFpFQ-Gmm_AhXv+vLrq8GZBA@mail.gmail.com>
Message-ID: <1B685347-82F1-48CA-87C2-9043CE09DD12@edirom.de>


Am 21.09.2011 um 15:51 schrieb Raffaele Viglianti:

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

But isn't this exactly what @decls offers already? We just need to agree on where to put this in the header. I see Perry's point about classification already offering everything for vocabularies (either uncontrolled or controlled elsewhere). As classification is allowed within sourceDesc, I think this is already the right place. Maybe all this can be addressed by offering exemplary classifications for CMN, mensural and neume notation families in the Guidelines?

I also like the idea to have a defined pointer to the ODD, although the schema referenced by the XML instance is probably the better place for this. Roma already outputs a comment on when the schema was generated, maybe we could request to include a pointer to the source and modification files as well?

Johannes

> 
> 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
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From stadler at edirom.de  Wed Sep 21 17:50:38 2011
From: stadler at edirom.de (Peter Stadler)
Date: Wed, 21 Sep 2011 17:50:38 +0200
Subject: [MEI-L] Notation type
In-Reply-To: <CAMyHAnMDvohEmarZB2gHOw8BPPMFpFQ-Gmm_AhXv+vLrq8GZBA@mail.gmail.com>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>
	<BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>
	<15465_1316539628_4E78CCEB_15465_306_1_BBCC497C40D85642B90E9F94FC30343D011044D2@GRANT.eservices.virginia.edu>
	<CE73D41D-E877-488C-B467-27B13470EB97@mail.mcgill.ca>
	<1966_1316605043_4E79CC72_1966_152_1_5BE9B46C-EB89-4C60-80A1-81859ACDA4CA@edirom.de>
	<8A20E550-E5B3-4B92-AA2A-0F2B0FE5D955@mail.mcgill.ca>
	<CAMyHAnMDvohEmarZB2gHOw8BPPMFpFQ-Gmm_AhXv+vLrq8GZBA@mail.gmail.com>
Message-ID: <0E9C927C-E3EA-4475-862D-D152F3794387@edirom.de>


Am 21.09.2011 um 15:51 schrieb Raffaele Viglianti:

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

I think we are in total agreement. My only concern was where exactly in the header to put that information -- and I confess that I'm a bit wary with the tei:msDesc because I think there is way too much information collected there that doesn't belong there (when you are not a historian working (solely) with the description of manuscripts). 
So, thanks for mentioning born digital documents which offer a good criterion for where to put this information. In my opinion, sourcedesc stays empty for born digital documents (except an appropriate statement "born digital ...") but all the bibliographic information is recorded in the other descendants of filedesc. Ergo, the type of notation should not (solely) be recorded under source/classification.

All the best
Peter

PS: I'm still not convinced that the notation style is a bibliographic feature. Anyhow, isn't that an anachronistic cataloguers view? Shouldn't we try to see the texts behind the bibliographic items? ;-)

From pdr4h at eservices.virginia.edu  Wed Sep 21 17:58:18 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Wed, 21 Sep 2011 15:58:18 +0000
Subject: [MEI-L] Notation type
In-Reply-To: <1B685347-82F1-48CA-87C2-9043CE09DD12@edirom.de>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>
	<BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>
	<15465_1316539628_4E78CCEB_15465_306_1_BBCC497C40D85642B90E9F94FC30343D011044D2@GRANT.eservices.virginia.edu>
	<CE73D41D-E877-488C-B467-27B13470EB97@mail.mcgill.ca>
	<1966_1316605043_4E79CC72_1966_152_1_5BE9B46C-EB89-4C60-80A1-81859ACDA4CA@edirom.de>
	<8A20E550-E5B3-4B92-AA2A-0F2B0FE5D955@mail.mcgill.ca>
	<CAMyHAnMDvohEmarZB2gHOw8BPPMFpFQ-Gmm_AhXv+vLrq8GZBA@mail.gmail.com>,
	<1B685347-82F1-48CA-87C2-9043CE09DD12@edirom.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D0110468A@GRANT.eservices.virginia.edu>

Since this discussion is becoming increasingly technical, could we take it to the mei-devel list?

--
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 Johannes Kepper [kepper at edirom.de]
Sent: Wednesday, September 21, 2011 10:18 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Notation type

Am 21.09.2011 um 15:51 schrieb Raffaele Viglianti:

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

But isn't this exactly what @decls offers already? We just need to agree on where to put this in the header. I see Perry's point about classification already offering everything for vocabularies (either uncontrolled or controlled elsewhere). As classification is allowed within sourceDesc, I think this is already the right place. Maybe all this can be addressed by offering exemplary classifications for CMN, mensural and neume notation families in the Guidelines?

I also like the idea to have a defined pointer to the ODD, although the schema referenced by the XML instance is probably the better place for this. Roma already outputs a comment on when the schema was generated, maybe we could request to include a pointer to the source and modification files as well?

Johannes

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

From stadler at edirom.de  Wed Sep 21 18:07:10 2011
From: stadler at edirom.de (Peter Stadler)
Date: Wed, 21 Sep 2011 18:07:10 +0200
Subject: [MEI-L] Notation type
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D0110468A@GRANT.eservices.virginia.edu>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>
	<BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>
	<15465_1316539628_4E78CCEB_15465_306_1_BBCC497C40D85642B90E9F94FC30343D011044D2@GRANT.eservices.virginia.edu>
	<CE73D41D-E877-488C-B467-27B13470EB97@mail.mcgill.ca>
	<1966_1316605043_4E79CC72_1966_152_1_5BE9B46C-EB89-4C60-80A1-81859ACDA4CA@edirom.de>
	<8A20E550-E5B3-4B92-AA2A-0F2B0FE5D955@mail.mcgill.ca>
	<CAMyHAnMDvohEmarZB2gHOw8BPPMFpFQ-Gmm_AhXv+vLrq8GZBA@mail.gmail.com>,
	<1B685347-82F1-48CA-87C2-9043CE09DD12@edirom.de>
	<BBCC497C40D85642B90E9F94FC30343D0110468A@GRANT.eservices.virginia.edu>
Message-ID: <000D7153-F5F5-4737-AEC4-7A21EFC08285@edirom.de>

I don't think it's *too* technical.
For me it's about basic categories -- the technical solutions are easy and mostly already established.

But maybe I missed the point?
Peter


Am 21.09.2011 um 17:58 schrieb Roland, Perry (pdr4h):

> Since this discussion is becoming increasingly technical, could we take it to the mei-devel list?
> 
> --
> 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 Johannes Kepper [kepper at edirom.de]
> Sent: Wednesday, September 21, 2011 10:18 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Notation type
> 
> Am 21.09.2011 um 15:51 schrieb Raffaele Viglianti:
> 
>> 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.
> 
> But isn't this exactly what @decls offers already? We just need to agree on where to put this in the header. I see Perry's point about classification already offering everything for vocabularies (either uncontrolled or controlled elsewhere). As classification is allowed within sourceDesc, I think this is already the right place. Maybe all this can be addressed by offering exemplary classifications for CMN, mensural and neume notation families in the Guidelines?
> 
> I also like the idea to have a defined pointer to the ODD, although the schema referenced by the XML instance is probably the better place for this. Roma already outputs a comment on when the schema was generated, maybe we could request to include a pointer to the source and modification files as well?
> 
> Johannes
> 
>> 
>> 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
>> 
>> _______________________________________________
>> 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



From andrew.hankinson at mail.mcgill.ca  Wed Sep 21 18:45:22 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Wed, 21 Sep 2011 16:45:22 +0000
Subject: [MEI-L] Notation type
In-Reply-To: <14332_1316620249_4E7A07D9_14332_116_1_0E9C927C-E3EA-4475-862D-D152F3794387@edirom.de>
References: <774DB49B-7ABB-446D-A9FE-2E0DA124752D@mail.mcgill.ca>
	<7900_1316524380_4E78915B_7900_55_1_BBCC497C40D85642B90E9F94FC30343D0110445A@GRANT.eservices.virginia.edu>
	<BE85AB3D-9E62-4589-B61A-24B3585029B4@mail.mcgill.ca>
	<15465_1316539628_4E78CCEB_15465_306_1_BBCC497C40D85642B90E9F94FC30343D011044D2@GRANT.eservices.virginia.edu>
	<CE73D41D-E877-488C-B467-27B13470EB97@mail.mcgill.ca>
	<1966_1316605043_4E79CC72_1966_152_1_5BE9B46C-EB89-4C60-80A1-81859ACDA4CA@edirom.de>
	<8A20E550-E5B3-4B92-AA2A-0F2B0FE5D955@mail.mcgill.ca>
	<CAMyHAnMDvohEmarZB2gHOw8BPPMFpFQ-Gmm_AhXv+vLrq8GZBA@mail.gmail.com>
	<14332_1316620249_4E7A07D9_14332_116_1_0E9C927C-E3EA-4475-862D-D152F3794387@edirom.de>
Message-ID: <107510A4-963E-4A3C-AA1F-CFE06BB36500@mail.mcgill.ca>

I agree with Peter & Raffaele that notation type is not a Bibliographical classification ("metadata"), but rather actual "data" present in the music itself. 

To take this argument to an absurd level, we could also classify documents by their use of G, C, or F clefs and add the terms "G Clef", "C Clef" or "F Clef" in <classification /> without actually giving an @clef.shape in the music data of the document. Then we could just use @decls to "point" to the term in the classification on <staffDef />. But we don't, because we recognize that @clef.shape has implications for the data being encoded and not just a category for organizing and grouping documents.

Without an explicit notation definition in the document are we actually assuming that one notation style (cmn?) is the "default" for MEI? I know that this has historically been the case, but since we're now trying to expand beyond CMN, then I think we need an explicit declaration of notation style(s) being used.

Like Raffaele, I think we should pre-declare the different notation types, either in <profileDesc /> or (what I might prefer) in a <notationDef /> section directly in the music body, similar to <scoreDef />, <staffDef />, <layerDef />, etc.

Since we're now talking about possible new features for MEI and not the current state of the spec, I'm OK with moving this to the development list. If you're not on the development list but want to stay on top of this conversation, e-mail me and I'll make sure you get copied on any further discussion.

On 2011-09-21, at 11:50 AM, Peter Stadler wrote:

> 
> Am 21.09.2011 um 15:51 schrieb Raffaele Viglianti:
> 
>> 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.
> 
> I think we are in total agreement. My only concern was where exactly in the header to put that information -- and I confess that I'm a bit wary with the tei:msDesc because I think there is way too much information collected there that doesn't belong there (when you are not a historian working (solely) with the description of manuscripts). 
> So, thanks for mentioning born digital documents which offer a good criterion for where to put this information. In my opinion, sourcedesc stays empty for born digital documents (except an appropriate statement "born digital ...") but all the bibliographic information is recorded in the other descendants of filedesc. Ergo, the type of notation should not (solely) be recorded under source/classification.
> 
> All the best
> Peter
> 
> PS: I'm still not convinced that the notation style is a bibliographic feature. Anyhow, isn't that an anachronistic cataloguers view? Shouldn't we try to see the texts behind the bibliographic items? ;-)
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From andrew.hankinson at mail.mcgill.ca  Wed Oct 26 00:26:42 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Tue, 25 Oct 2011 22:26:42 +0000
Subject: [MEI-L] LibMEI 1.0 Beta released
Message-ID: <4C593565-6767-45CB-BFF6-0B88333BE283@mail.mcgill.ca>

We are pleased to announce the 1.0 beta release of LibMEI, a C++ library for reading, writing, and manipulating MEI-encoded music notation. This software will be useful for developers who wish to integrate support for MEI in their applications. 

Compiling instructions, API documentation, and more is available on the LibMEI website,http://ddmal.music.mcgill.ca/libmei.

LibMEI has been developed at the Distributed Digital Music Archives and Libraries Lab, McGill University.

For more information, please contact Andrew Hankinson (andrew.hankinson at mail.mcgill.ca).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20111025/349fe23d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1054 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20111025/349fe23d/attachment.bin>

From kepper at edirom.de  Wed Oct 26 13:44:05 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Wed, 26 Oct 2011 13:44:05 +0200
Subject: [MEI-L] ensemble
Message-ID: <587A9783-2220-4738-8C14-FE45065AF8FB@edirom.de>

Hi list,

Axel and Detmold are working on the perfMedium model. We're wondering about the use of <instrVoice> as required first child of <ensemble>, especially since there is the common attribute @label available on <ensemble>. Anyone out there who knows about this?

Thanks,
Johannes

From kepper at edirom.de  Wed Oct 26 13:46:32 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Wed, 26 Oct 2011 13:46:32 +0200
Subject: [MEI-L] ensemble
Message-ID: <A7A70855-289E-4AF5-8B6A-4151523A9638@edirom.de>

Hi list,

Axel and Detmold are working on the perfMedium model. We're wondering about the use of <instrVoice> as required first child of <ensemble>, especially since there is the common attribute @label available on <ensemble>. Anyone out there who knows about this?

Thanks,
Johannes

From pdr4h at eservices.virginia.edu  Wed Oct 26 16:02:07 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Wed, 26 Oct 2011 14:02:07 +0000
Subject: [MEI-L] ensemble
In-Reply-To: <587A9783-2220-4738-8C14-FE45065AF8FB@edirom.de>
References: <587A9783-2220-4738-8C14-FE45065AF8FB@edirom.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D0110ED59@GRANT.eservices.virginia.edu>

Johannes,

<instrVoice> is required here in order to avoid a mixed content model in <ensemble> and to make the conversion from MARC to MEI easier.  

It is true that one could use @label on <ensemble> to hold the name of the ensemble, however, this would disallow the possibility of using markup in the name and would be an abuse of @label, since it should not be used to capture "content", but rather a string that identifies the content.

For example, a document may contain "My name: Perry".  In this case, "My name:" is the label for the content "Perry".  The proper markup for this construct is

  <name label="My name:">Perry</name>
  NOT
  <name label="Perry"/>

By analogy, the markup for ensemble is

  <ensemble label="Ensemble">
    <instrVoice>Orchestra</instrVoice>
  </ensemble>

   NOT

  <ensemble label="Orchestra"/>

--
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 Johannes Kepper [kepper at edirom.de]
Sent: Wednesday, October 26, 2011 7:44 AM
To: Music Encoding Initiative
Subject: [MEI-L] ensemble

Hi list,

Axel and Detmold are working on the perfMedium model. We're wondering about the use of <instrVoice> as required first child of <ensemble>, especially since there is the common attribute @label available on <ensemble>. Anyone out there who knows about this?

Thanks,
Johannes
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

From kepper at edirom.de  Wed Oct 26 16:16:40 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Wed, 26 Oct 2011 16:16:40 +0200
Subject: [MEI-L] ensemble
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D0110ED59@GRANT.eservices.virginia.edu>
References: <587A9783-2220-4738-8C14-FE45065AF8FB@edirom.de>
	<BBCC497C40D85642B90E9F94FC30343D0110ED59@GRANT.eservices.virginia.edu>
Message-ID: <85D0561C-97B0-4C8F-877A-E7A9F5D99126@edirom.de>

Ok, understood. But that does not answer my question (or, the question behind the ill-posed words I said?). Why do I have to have an <instrVoice> within <ensemble/> when I'm going to specify it's <performer> childs, but don't want to provide a name / label / xxx for the ensemble as group?

Thanks so far,
Johannes

Am 26.10.2011 um 16:02 schrieb Roland, Perry (pdr4h):

> Johannes,
> 
> <instrVoice> is required here in order to avoid a mixed content model in <ensemble> and to make the conversion from MARC to MEI easier.  
> 
> It is true that one could use @label on <ensemble> to hold the name of the ensemble, however, this would disallow the possibility of using markup in the name and would be an abuse of @label, since it should not be used to capture "content", but rather a string that identifies the content.
> 
> For example, a document may contain "My name: Perry".  In this case, "My name:" is the label for the content "Perry".  The proper markup for this construct is
> 
>  <name label="My name:">Perry</name>
>  NOT
>  <name label="Perry"/>
> 
> By analogy, the markup for ensemble is
> 
>  <ensemble label="Ensemble">
>    <instrVoice>Orchestra</instrVoice>
>  </ensemble>
> 
>   NOT
> 
>  <ensemble label="Orchestra"/>
> 
> --
> 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 Johannes Kepper [kepper at edirom.de]
> Sent: Wednesday, October 26, 2011 7:44 AM
> To: Music Encoding Initiative
> Subject: [MEI-L] ensemble
> 
> Hi list,
> 
> Axel and Detmold are working on the perfMedium model. We're wondering about the use of <instrVoice> as required first child of <ensemble>, especially since there is the common attribute @label available on <ensemble>. Anyone out there who knows about this?
> 
> Thanks,
> Johannes
> _______________________________________________
> 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



From pdr4h at eservices.virginia.edu  Wed Oct 26 16:47:55 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Wed, 26 Oct 2011 14:47:55 +0000
Subject: [MEI-L] ensemble
In-Reply-To: <85D0561C-97B0-4C8F-877A-E7A9F5D99126@edirom.de>
References: <587A9783-2220-4738-8C14-FE45065AF8FB@edirom.de>
	<BBCC497C40D85642B90E9F94FC30343D0110ED59@GRANT.eservices.virginia.edu>,
	<85D0561C-97B0-4C8F-877A-E7A9F5D99126@edirom.de>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D0110ED99@GRANT.eservices.virginia.edu>

Patient, raising arm:  "Doctor, it hurts when I go like this."
Doctor: "Don't do that!"

In the case you describe, you shouldn't use <ensemble>.  To enumerate the performing forces without naming the ensemble, use the following instead --

<perfMedium>
  <performer>
    <instrVoice>violin</instrVoice>
  </performer>
  <performer>
    <instrVoice>viola</instrVoice>
  </performer>
  <performer>
    <instrVoice>violoncello</instrVoice>
  </performer>
</perfMedium>

If you want to name the ensemble, use --

<perfMedium>
  <ensemble>String trio</ensemble>
</perfMedium>

<ensemble> and <performer> can be combined within <perfMedium> when the work is for an ensemble and soloists --

<perfMedium>
  <ensemble>
    <instrVoice>Orchestra</instrVoice>
  </ensemble>
  <performer>
    <instrVoice>Soprano</instrVoice>
  </performer>
  <performer>
    <instrVoice>Tenor</instrVoice>
  </performer>
</performer>

or within <ensemble> when capture of the exact make-up of the ensemble is desired --

<perfMedium>
  <ensemble>
    <instrVoice>Chamber orchestra</instrVoice>
    <performer>
      <instrVoice>Flute</instrVoice>
    </performer>
    <performer>
      <instrVoice>Oboe</instrVoice>
    </performer>
    <performer>
      <instrVoice>Bassoon</instrVoice>
    </performer>
    <performer>
      <instrVoice>Horn</instrVoice>
    </performer>
    <performer>
      <instrVoice>Violin I</instrVoice>
    </performer>
    <performer>
      <instrVoice>Violin II</instrVoice>
    </performer>
    <performer>
      <instrVoice>Violin III</instrVoice>
    </performer>
    <performer>
      <instrVoice>Violincello</instrVoice>
    </performer>
    <performer>
      <instrVoice>Bass</instrVoice>
    </performer>
  </ensemble>

<instrVoice> is always required within <ensemble>, but <performer> within ensemble is optional.

--
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 Johannes Kepper [kepper at edirom.de]
Sent: Wednesday, October 26, 2011 10:16 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] ensemble

Ok, understood. But that does not answer my question (or, the question behind the ill-posed words I said?). Why do I have to have an <instrVoice> within <ensemble/> when I'm going to specify it's <performer> childs, but don't want to provide a name / label / xxx for the ensemble as group?

Thanks so far,
Johannes

Am 26.10.2011 um 16:02 schrieb Roland, Perry (pdr4h):

> Johannes,
>
> <instrVoice> is required here in order to avoid a mixed content model in <ensemble> and to make the conversion from MARC to MEI easier.
>
> It is true that one could use @label on <ensemble> to hold the name of the ensemble, however, this would disallow the possibility of using markup in the name and would be an abuse of @label, since it should not be used to capture "content", but rather a string that identifies the content.
>
> For example, a document may contain "My name: Perry".  In this case, "My name:" is the label for the content "Perry".  The proper markup for this construct is
>
>  <name label="My name:">Perry</name>
>  NOT
>  <name label="Perry"/>
>
> By analogy, the markup for ensemble is
>
>  <ensemble label="Ensemble">
>    <instrVoice>Orchestra</instrVoice>
>  </ensemble>
>
>   NOT
>
>  <ensemble label="Orchestra"/>
>
> --
> 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 Johannes Kepper [kepper at edirom.de]
> Sent: Wednesday, October 26, 2011 7:44 AM
> To: Music Encoding Initiative
> Subject: [MEI-L] ensemble
>
> Hi list,
>
> Axel and Detmold are working on the perfMedium model. We're wondering about the use of <instrVoice> as required first child of <ensemble>, especially since there is the common attribute @label available on <ensemble>. Anyone out there who knows about this?
>
> Thanks,
> Johannes
> _______________________________________________
> 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

From craigsapp at gmail.com  Fri Nov  4 23:07:58 2011
From: craigsapp at gmail.com (Craig Sapp)
Date: Fri, 4 Nov 2011 15:07:58 -0700
Subject: [MEI-L] Fwd: MakeMusic Purchases Recordare Assets
Message-ID: <CAPcjuFdX=QFmMEuZYrJ9=hhz5_8RUu4PmYmyWyWdTkuJAoZfOA@mail.gmail.com>

Hi MEIers,

In case you haven't heard, Finale bought MusicXML this week (see
initial announcement below).

-=+Craig

---------- Forwarded message ----------
From: Recordare Information <info at recordare.com>
Date: Wed, Nov 2, 2011 at 1:28 PM
Subject: [MusicXML] MakeMusic, Inc. Enhances Technology Leadership By
Purchasing Recordare Assets
To: musicxml at recordare.com


MAKEMUSIC, INC. ENHANCES TECHNOLOGY LEADERSHIP BY PURCHASING RECORDARE
ASSETS

Recordare Founder Michael Good to join MakeMusic Team as Director of
Digital Sheet Music

Minneapolis - November 2, 2011 - MakeMusic, Inc. (NASDAQ: MMUS)
announced it has entered into an agreement to acquire selected assets
of Recordare LLC, the Internet music publishing and software company.
Closing is expected to occur during the fourth quarter.

Under the terms of the agreement, MakeMusic is purchasing the MusicXML
open format and Dolet software technology, including copyrights,
source code, and trademarks. MakeMusic also announced that the founder
of Recordare and inventor of MusicXML, Michael Good, will be joining
MakeMusic as the Director of Digital Sheet Music.

"This acquisition demonstrates our commitment to the ongoing
development and support of an open notation format to the entire music
community," said Karen van Lith, MakeMusic CEO. "The synergy between
MusicXML and Dolet software enhances MakeMusic's renowned family of
music products, further establishing us as the technology leader, and
I am thrilled to have the creative talents of Michael Good to help us
drive innovation in the music industry."

"Today is a momentous day for Recordare and MusicXML," said Michael
Good, Recordare founder and CEO. ?"MakeMusic has been MusicXML's
earliest and most significant supporter. It's the world's largest
company devoted to music notation, practice, and digital sheet music
technology. In considering the sale of Recordare's intellectual
property, I was looking for a company committed to creating new
advances in the world of interactive digital music notation. MakeMusic
was clearly the best fit."

MusicXML has become the standard for musical notation interchange and
is an Internet-friendly way to publish musical scores. The technology
enables musicians to distribute interactive sheet music online and to
use sheet music files with a wide variety of musical applications.
MusicXML will continue to be available under the same open and
royalty-free license as before and is supported by more than 150
applications.

Recordare's Dolet software for Finale and Sibelius uses the MusicXML
format to provide a universal translator. Just as word-processing and
spreadsheet programs have been sharing formats for years, with
MusicXML, musicians can write in one program and share their creations
with people who prefer to use another program. Upon closing, MakeMusic
will provide the Dolet software at no charge.

Dozens of companies and organizations support MusicXML, including Avid
Technology Inc., Noteflight, LLC, Microsoft Research, Steinberg Media
Technologies GmbH, Cakewalk Inc., Notion Music Inc., Musitek
Corporation and the Massachusetts Institute of Technology Music
Program.

About MakeMusic, Inc.

MakeMusic, Inc. is a world leader in music technology whose mission is
to develop and market solutions that transform how music is composed,
taught, learned and performed. For more than 20 years, Finale has been
the industry standard in music notation software, enabling composers,
arrangers, musicians, teachers, students and publishers to create,
edit, audition, print and publish musical scores. MakeMusic is also
the creator of SmartMusic interactive software that is transforming
the way students practice. With SmartMusic, students and teachers have
access to thousands of band, orchestra and vocal pieces allowing
students to practice with background accompaniment and get immediate
feedback on their performance. SmartMusic allows teachers to
individualize instruction and document the progress of every student.
The SmartMusic Inbox, an Android and Apple mobile application,
provides additional access for teachers to review, grade, and comment
on student assignments. MusicXML is an Internet-friendly way to
publish musical scores, enabling musicians to distribute interactive
sheet music online and to use sheet music files with a wide variety of
musical applications. Additional information about this Minnesota
company can be found at www.makemusic.com.

[Cautionary Statements]

SOURCE: MakeMusic, Inc.

Company Contact:

MakeMusic, Inc.
Karen VanDerBosch
Chief Operating Officer and Chief Financial Officer
MakeMusic, Inc.
(952) 906-3690
kvanderbosch at makemusic.com


From esfield at stanford.edu  Fri Nov  4 23:17:38 2011
From: esfield at stanford.edu (Eleanor Selfridge-Field)
Date: Fri, 4 Nov 2011 15:17:38 -0700 (PDT)
Subject: [MEI-L] Fwd: MakeMusic Purchases Recordare Assets
In-Reply-To: <CAPcjuFdX=QFmMEuZYrJ9=hhz5_8RUu4PmYmyWyWdTkuJAoZfOA@mail.gmail.com>
References: <CAPcjuFdX=QFmMEuZYrJ9=hhz5_8RUu4PmYmyWyWdTkuJAoZfOA@mail.gmail.com>
Message-ID: <00d701cc9b3f$8bf97c50$a3ec74f0$@stanford.edu>

Thanks for sending this out. MEI was my particular concern.

Eleanor


-----Original Message-----
From: mei-l-bounces at lists.uni-paderborn.de
[mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Craig Sapp
Sent: Friday, November 04, 2011 3:08 PM
To: Music Encoding Initiative
Subject: [MEI-L] Fwd: MakeMusic Purchases Recordare Assets

Hi MEIers,

In case you haven't heard, Finale bought MusicXML this week (see initial
announcement below).

-=+Craig

---------- Forwarded message ----------
From: Recordare Information <info at recordare.com>
Date: Wed, Nov 2, 2011 at 1:28 PM
Subject: [MusicXML] MakeMusic, Inc. Enhances Technology Leadership By
Purchasing Recordare Assets
To: musicxml at recordare.com


MAKEMUSIC, INC. ENHANCES TECHNOLOGY LEADERSHIP BY PURCHASING RECORDARE
ASSETS

Recordare Founder Michael Good to join MakeMusic Team as Director of
Digital Sheet Music

Minneapolis - November 2, 2011 - MakeMusic, Inc. (NASDAQ: MMUS) announced
it has entered into an agreement to acquire selected assets of Recordare
LLC, the Internet music publishing and software company.
Closing is expected to occur during the fourth quarter.

Under the terms of the agreement, MakeMusic is purchasing the MusicXML
open format and Dolet software technology, including copyrights, source
code, and trademarks. MakeMusic also announced that the founder of
Recordare and inventor of MusicXML, Michael Good, will be joining
MakeMusic as the Director of Digital Sheet Music.

"This acquisition demonstrates our commitment to the ongoing development
and support of an open notation format to the entire music community,"
said Karen van Lith, MakeMusic CEO. "The synergy between MusicXML and
Dolet software enhances MakeMusic's renowned family of music products,
further establishing us as the technology leader, and I am thrilled to
have the creative talents of Michael Good to help us drive innovation in
the music industry."

"Today is a momentous day for Recordare and MusicXML," said Michael Good,
Recordare founder and CEO. ?"MakeMusic has been MusicXML's earliest and
most significant supporter. It's the world's largest company devoted to
music notation, practice, and digital sheet music technology. In
considering the sale of Recordare's intellectual property, I was looking
for a company committed to creating new advances in the world of
interactive digital music notation. MakeMusic was clearly the best fit."

MusicXML has become the standard for musical notation interchange and is
an Internet-friendly way to publish musical scores. The technology enables
musicians to distribute interactive sheet music online and to use sheet
music files with a wide variety of musical applications.
MusicXML will continue to be available under the same open and
royalty-free license as before and is supported by more than 150
applications.

Recordare's Dolet software for Finale and Sibelius uses the MusicXML
format to provide a universal translator. Just as word-processing and
spreadsheet programs have been sharing formats for years, with MusicXML,
musicians can write in one program and share their creations with people
who prefer to use another program. Upon closing, MakeMusic will provide
the Dolet software at no charge.

Dozens of companies and organizations support MusicXML, including Avid
Technology Inc., Noteflight, LLC, Microsoft Research, Steinberg Media
Technologies GmbH, Cakewalk Inc., Notion Music Inc., Musitek Corporation
and the Massachusetts Institute of Technology Music Program.

About MakeMusic, Inc.

MakeMusic, Inc. is a world leader in music technology whose mission is to
develop and market solutions that transform how music is composed, taught,
learned and performed. For more than 20 years, Finale has been the
industry standard in music notation software, enabling composers,
arrangers, musicians, teachers, students and publishers to create, edit,
audition, print and publish musical scores. MakeMusic is also the creator
of SmartMusic interactive software that is transforming the way students
practice. With SmartMusic, students and teachers have access to thousands
of band, orchestra and vocal pieces allowing students to practice with
background accompaniment and get immediate feedback on their performance.
SmartMusic allows teachers to individualize instruction and document the
progress of every student.
The SmartMusic Inbox, an Android and Apple mobile application, provides
additional access for teachers to review, grade, and comment on student
assignments. MusicXML is an Internet-friendly way to publish musical
scores, enabling musicians to distribute interactive sheet music online
and to use sheet music files with a wide variety of musical applications.
Additional information about this Minnesota company can be found at
www.makemusic.com.

[Cautionary Statements]

SOURCE: MakeMusic, Inc.

Company Contact:

MakeMusic, Inc.
Karen VanDerBosch
Chief Operating Officer and Chief Financial Officer MakeMusic, Inc.
(952) 906-3690
kvanderbosch at makemusic.com

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l


From kepper at edirom.de  Mon Nov 14 15:27:00 2011
From: kepper at edirom.de (Johannes Kepper)
Date: Mon, 14 Nov 2011 15:27:00 +0100
Subject: [MEI-L] Technical Team Meeting Report
Message-ID: <63D4D616-D3D6-4D6A-AEB9-F827A49B83A9@edirom.de>

Dear MEIers,

one and a half weeks ago, the Technical Team has met for another virtual meeting using UVa's Elluminate. In this very productive meeting, we discussed mainly the next release of MEI. In the name of this group, I would like to report back to the Council and the wider audience on this list about our proposals. If you would like to learn more about any of these things, if you have further questions, opinions etc., the Technical Team will be happy to answer and / or discuss them on this list.

RELEASE
The Technical Team came to the conclusion that it might be good compromise to split up the next release into several pieces in order to accomodate different needs. We propose to freeze the code of the schema itself right now. This means that no changes to the schema specification will be included in the release to come, but instead will go into the development branch for the following release. This allows the software developers amongst us to adjust their applications to the next release without having to hit a moving target due to ongoing changes in the schema. 
At the same time, we agreed that it would be helpful to provide a first version of the Guidelines for the wider audience. Although the work on the Guidelines has already started, this will take some more time, probably until early next year.* The third component we would like to see ready for the next release is a small collection of sample encodings. A first draft of this collection is already in place, but there is still a lot of work to be done here as well. 
The consequence of this is that we propose to offer the schema under the name "MEI 2012" and as first part of the next release on our website, but without too much "public noise". As soon as we have the other parts in place, we will bundle everything and announce it to appropriate listservs etc. This will probably happen early next year (hence the preliminary name "MEI 2012"). 

FEATURES: FRBR
In the last week of October, Axel Teich Geertinger was in Detmold to discuss  ? among other things ? a potential integration of FRBR into MEI. These "Functional Requirements for Bibliographic Records" propose a way of organizing bibliographic records, but they are also very suitable to organize the relationships between works (including different versions) and sources. Although this looks very promising, implementing FRBR has some implications that would certainly delay the release (at least of the schema) significantly. The Technical Team therefore proposes to put that into the development branch for the following release. In the meantime, Axel's merMEId and Detmold's Edirom will implement these features in order to get more experience with them and to mature a really convincing solution for this.

FEATURES: Ossia
During the last (Technical Team) meeting in July 2011, some confusion about the model for encoding Ossias was left. During this meeting, we discussed it again and reassured, that the current model is well suited for MEI with only some minor additions to the tag library. Basically, an <ossia> element will be allowed within <measure> (where it contains alternating <staff> elements) and within <staff> (where it contains <layer>s). What needs to be specified then is the order in which these elements appear in a score. Here we agreed that the encoding order is significant: The first <staff> in an <ossia> will always describe the topmost alternative, the last will describe the lowest etc. Will the information gathered from there will be valid for all staves, only the <staff> that fits the surrounding measures (the original-sized alternative) will point to a <staffDef> using its @def-attribute. In combination, this clearly specifies which <staff> goes in line, and which is an alternative provided above or below the staff.

MEIron
The toolbox introduced under the name "MEIron" should not be part of the next release. Although we constantly work on this, it is unlikely that it will be ready when the other parts of the MEI 2012 release are. Maybe parts of this toolbox will be published together with the release, but we suggest to not delay this release for the complete MEIron, as its functionality will probably increase continuously. 
Regarding the MEIron itself, we made clear that this should by no means encourage any "canonical MEI", but instead provide means on how to convert from one solution in MEI to another (for instance: ties encoded as attributes converted to elements) without prioritizing any of them. Concerning the eponymous "flattening" part of the MEIron, we will provide an XSLT script that will reduce an encoding to a "flat" MEI file following simple rules ("always pick the variant from source A"). As soon as the user wants to make individual decisions an each of the branchings, we recommend to use Julian's MEISE (MEI Score Editor) instead, which offers a graphical user interface and is already capable of making these decisions. 

-----

Another virtual meeting for the Technical Team is scheduled in three months from now, with no precise date set yet. If a Council Member or someone else wants to participate in parts of this meeting, please contact me. If you have questions about this report and the meeting we had, we'd be happy to answer them. In case the Council agrees with our proposals, we will proceed as described here. 


In the last time, we had several discussions about MEI by other means, so that on this list it seemed like there was no activity. This was absolutely not true, and I apologize for the impression. Most of the stuff was purely technical, but we shall try to use this list more frequently in order to keep everyone up to date. 


In the name of the Technical Team, and with best regards,
Johannes Kepper





* There are still chapters in the Guidelines that are not assigned to someone yet. We are always looking for volunteers to take a lead on those. This does not mean that you have to write everything by yourself, but you are responsible of completing this chapter. Perry Roland and Johannes Kepper, and the Technical Team in general, will be happy to help you with technical or other issues by any means. If you would like to contribute some more time to MEI, this is a great opportunity for non-programmers! See the list of chapters and their current assignments online at http://tinyurl.com/dyhsyu6.

From craigsapp at gmail.com  Thu Dec  1 17:16:25 2011
From: craigsapp at gmail.com (Craig Sapp)
Date: Thu, 1 Dec 2011 08:16:25 -0800
Subject: [MEI-L] Dolet plugins for Finale/Sibelius now availble for free
Message-ID: <CAPcjuFfBgrt4aKBb-n+E7ek8wJig+X4ft1_VA27OyGa-DoFYKA@mail.gmail.com>

Hi MEI List,

Here is an announcement about MusicXML which was released today.  The
Dolet plugins for Finale/Sibelius are available for free download from
the Finale website:

http://www.makemusic.com/Products/MusicXML.aspx

(You will have to create/have an account on the website to get to the
download page).

Dolet plugs are used to import/export MusicXML from Finale/Sibelius.
Finale has had free import/export since 2006 (probably called "Dolet
Lite").  Sibelius 7 (newest version) has a built in import/export for
MusicXML, but that is written by the Sibelius programmers. Michael
Good sold the full version of the plugin separately for Sibelius.

-=+Craig


---------- Forwarded message ----------
From: Recordare Information <info at recordare.com>
Date: Thu, Dec 1, 2011 at 7:42 AM
Subject: [MusicXML] Recordare is closing
To: musicxml at recordare.com


Dear MusicXML friends,

MakeMusic has now closed its acquisition of selected Recordare assets,
including the MusicXML format and Dolet software. The Dolet for
Sibelius and Dolet for Finale plug-ins are now available for free from
MakeMusic. You can download the plug-ins from:

?http://www.makemusic.com/Products/MusicXML.aspx

The MusicXML information and this mailing list will stay on the
Recordare site for the time being, until it moves to the MakeMusic
site.

With the closing of the acquisition, I have started my new role as
Director of Digital Sheet Music at MakeMusic. The Recordare Online
Store has now closed, and we are in the process of winding up the
company.

Thank you for all your support over the years to create a standard
music notation interchange format. There's lots more work ahead to
make digital sheet music work better for everyone. I look forward to
our continued collaboration on improving the MusicXML format in the
future!

Best regards,

Michael Good
Recordare LLC

To unsubscribe, switch to/from digest, get on/off vacation, or change
your email address, click here.
http://cgi.mail-list.com/u?ln=musicxml&nm=craig%40ccrma.stanford.edu


From zupftom at googlemail.com  Fri Dec  2 00:00:50 2011
From: zupftom at googlemail.com (TW)
Date: Fri, 2 Dec 2011 00:00:50 +0100
Subject: [MEI-L] Converting specs to schema
Message-ID: <CAEB1mAoGaP=Z8UHGT2sfgPj=Topw5JbxzSu_re5Qj9S=0iqd5g@mail.gmail.com>

How do I convert the big specifications source file
(mei-2011-05-source.xml) to RNG or XSD?  I easily get lost in HTML
documentation I generated from the full RNG.  I'd like to strip some
modules to simplify things.  As the module information is lost in the
RNG, I want to modify the original, then go via RNG and XSD to HTML.
(Is there a more straightforward way?)

Thanks!
Thomas


From raffaeleviglianti at gmail.com  Fri Dec  2 09:18:51 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Fri, 2 Dec 2011 08:18:51 +0000
Subject: [MEI-L] Converting specs to schema
In-Reply-To: <CAEB1mAoGaP=Z8UHGT2sfgPj=Topw5JbxzSu_re5Qj9S=0iqd5g@mail.gmail.com>
References: <CAEB1mAoGaP=Z8UHGT2sfgPj=Topw5JbxzSu_re5Qj9S=0iqd5g@mail.gmail.com>
Message-ID: <CAMyHAnOevkcXuWt9wh9HsOY8v+C1VmosdQu2EdV91k3ru-dz_Q@mail.gmail.com>

Hi Thomas,

If I understand your problem correctly, you should create an ODD
customization. Look at /MEI_dev/customizations/mei-all.xml as an example.
That file selects all the modules. You can make a copy and comment out the
modules that you want to exclude.

At this point you have a few options to generate an RNG and XSD from the
source + customization. This is what I usually do on a Unix system:

1. checkout TEI's trunk from sourceforge if you don't have it already
2. make sure you have all the dependecies (trang, saxon, xmllint)
3. go to /Roma
4. run the command:

./roma2 --xsl=../Stylesheets
--localsource=fullPathTo_mei-2011-05-source.xml fullPathToYourCustomization

5. Under RomaResults you'll find the resulting RNG and XSD.

It goes without saying that once Roma is installed and working on you
system, it's just a matter or running the command.

Hope this helps,
Raffaele

On Thu, Dec 1, 2011 at 11:00 PM, TW <zupftom at googlemail.com> wrote:

> How do I convert the big specifications source file
> (mei-2011-05-source.xml) to RNG or XSD?  I easily get lost in HTML
> documentation I generated from the full RNG.  I'd like to strip some
> modules to simplify things.  As the module information is lost in the
> RNG, I want to modify the original, then go via RNG and XSD to HTML.
> (Is there a more straightforward way?)
>
> Thanks!
> Thomas
>
> _______________________________________________
> 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/20111202/94e8ddb0/attachment.html>

From zupftom at googlemail.com  Fri Dec  2 09:24:49 2011
From: zupftom at googlemail.com (TW)
Date: Fri, 2 Dec 2011 09:24:49 +0100
Subject: [MEI-L] Converting specs to schema
In-Reply-To: <CAMyHAnOevkcXuWt9wh9HsOY8v+C1VmosdQu2EdV91k3ru-dz_Q@mail.gmail.com>
References: <CAEB1mAoGaP=Z8UHGT2sfgPj=Topw5JbxzSu_re5Qj9S=0iqd5g@mail.gmail.com>
	<CAMyHAnOevkcXuWt9wh9HsOY8v+C1VmosdQu2EdV91k3ru-dz_Q@mail.gmail.com>
Message-ID: <CAEB1mAqP1yY7z0Yui_91UV=uGcH6+etz9+mnWzFUncj4Wsb7Ew@mail.gmail.com>

2011/12/2 Raffaele Viglianti <raffaeleviglianti at gmail.com>:
> If I understand your problem correctly, you should create an ODD
> customization. Look at /MEI_dev/customizations/mei-all.xml as an example.
> That file selects all the modules. You can make a copy and comment out the
> modules that you want to exclude.
>
> At this point you have a few options to generate an RNG and XSD from the
> source + customization. This is what I usually do on a Unix system:
>
> 1. checkout TEI's trunk from sourceforge if you don't have it already
> 2. make sure you have all the dependecies (trang, saxon, xmllint)
> 3. go to /Roma
> 4. run the command:
>
> ./roma2 --xsl=../Stylesheets --localsource=fullPathTo_mei-2011-05-source.xml
> fullPathToYourCustomization
>
> 5. Under RomaResults you'll find the resulting RNG and XSD.
>
> It goes without saying that once Roma is installed and working on you
> system, it's just a matter or running the command.
>

Great, thanks.  I'll try that.

Thomas


From zupftom at googlemail.com  Sat Dec  3 12:20:25 2011
From: zupftom at googlemail.com (TW)
Date: Sat, 3 Dec 2011 12:20:25 +0100
Subject: [MEI-L] Converting specs to schema
In-Reply-To: <CAMyHAnOevkcXuWt9wh9HsOY8v+C1VmosdQu2EdV91k3ru-dz_Q@mail.gmail.com>
References: <CAEB1mAoGaP=Z8UHGT2sfgPj=Topw5JbxzSu_re5Qj9S=0iqd5g@mail.gmail.com>
	<CAMyHAnOevkcXuWt9wh9HsOY8v+C1VmosdQu2EdV91k3ru-dz_Q@mail.gmail.com>
Message-ID: <CAEB1mAoUrO5Wn1gXRVkD5LKOpH7B3YO8Omqa-9H0FrDhAbie=Q@mail.gmail.com>

Hi Raffaele,

2011/12/2 Raffaele Viglianti <raffaeleviglianti at gmail.com>:
> If I understand your problem correctly, you should create an ODD
> customization. Look at /MEI_dev/customizations/mei-all.xml as an example.
> That file selects all the modules. You can make a copy and comment out the
> modules that you want to exclude.
>
> At this point you have a few options to generate an RNG and XSD from the
> source + customization. This is what I usually do on a Unix system:
>
> 1. checkout TEI's trunk from sourceforge if you don't have it already
> 2. make sure you have all the dependecies (trang, saxon, xmllint)
> 3. go to /Roma
> 4. run the command:
>
> ./roma2 --xsl=../Stylesheets --localsource=fullPathTo_mei-2011-05-source.xml
> fullPathToYourCustomization
>
> 5. Under RomaResults you'll find the resulting RNG and XSD.
>

I need some more assistance.

Problem 1:  /trunk/Roma/roma2.sh relies on command "saxon".  On my
Ubuntu Natty system I have the packages libsaxon-java, libsaxonb-java
and libsaxon-java-gcj installed, but they don't come with this
command.  So I changed "saxon" to "saxonb-xslt".  But then I get

Error at xsl:result-document on line 1851 of
file:/home/tom/tei/trunk/Stylesheets/odds2/teiodds.xsl:
  xsl:result-document is disabled when extension functions are disabled

So I inserted -ext:on, which *seemed* to get me somewhere (after I
created some directory that Roma wanted to put the results).

Problem 2:  I did the following, using the unmodified mei-all.xml for testing:


tom at desktop:~$ tei/trunk/Roma/roma2.sh --xsl=tei/trunk/Stylesheets
--localsource=music-encoding/trunk/source/specs/mei-2011-05-source.xml
music-encoding/trunk/customizations/mei-all.xml
========= Roma starts at 2011-12-03 12:05:09 ===========
TEI stylesheet tree: tei/trunk/Stylesheets
Results to: RomaResults
Process music-encoding/trunk/customizations/mei-all.xml to create
mei{.dtd|.xsd|.doc.xml|.rng|.rnc} in RomaResults
========= Roma version VVVERSION starts execution at 2011-12-03
12:05:10.208637972 ===========
using /home/tom/music-encoding/trunk/source/specs/mei-2011-05-source.xml
as default source
1. expand and simplify ODD
2. make RELAX NG from compiled ODD
3. make RELAX NG compact from XML
4. make XSD from RELAX NG
/home/tom/RomaResults/mei.rng:11:13: error: restriction violation:
"start" contains "empty"


ERROR:  trang fails.
This was a fatal error. 2011-12-03 12:05:14
5. make DTD from compiled ODD
========= 2011-12-03 12:05:16.785145931 Roma ends


The generated RNG looks like:


<?xml version="1.0" encoding="utf-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
ns="http://www.music-encoding.org/ns/mei">
  <!--
Schema generated from ODD source 2011-12-03T12:05:14Z.
Edition:
Edition Location: http://www.tei-c.org/Vault/P5//

-->
  <!---->
  <start>
    <empty/>
  </start>
</grammar>


Something tells me this is flawed.

I saw there are Debian packages available[1] and added them to my
software sources.  I installed the packages tei-roma, saxon and
tei-p5-xsl2.  The result was pretty much the same:


tom at desktop:~/music-encoding/trunk/customizations$ roma mei-all.xml mei-all
========= Roma starts at 2011-12-03 12:13:48 ===========
TEI stylesheet tree: /usr/share/xml/tei/stylesheet
Results to: mei-all
Process mei-all.xml to create mei{.dtd|.xsd|.doc.xml|.rng|.rnc} in mei-all
========= Roma version 4.7 starts execution at 2011-12-03
12:13:49.646907172 ===========
1. expand and simplify ODD
2. make RELAX NG from compiled ODD
3. make RELAX NG compact from XML
4. make XSD from RELAX NG
/home/tom/music-encoding/trunk/customizations/mei-all/mei.rng:11:13:
error: restriction violation: "start" contains "empty"


ERROR:  trang fails.
This was a fatal error. 2011-12-03 12:14:00
5. make DTD from compiled ODD
========= 2011-12-03 12:14:03.531732571 Roma ends


What can I do?

Thanks!
Thomas


[1] http://tei.oucs.ox.ac.uk/teideb/


From andrew.hankinson at mail.mcgill.ca  Sat Dec  3 23:24:53 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Sat, 3 Dec 2011 22:24:53 +0000
Subject: [MEI-L] Converting specs to schema
In-Reply-To: <23626_1322911241_4EDA0608_23626_11_1_CAEB1mAoUrO5Wn1gXRVkD5LKOpH7B3YO8Omqa-9H0FrDhAbie=Q@mail.gmail.com>
References: <CAEB1mAoGaP=Z8UHGT2sfgPj=Topw5JbxzSu_re5Qj9S=0iqd5g@mail.gmail.com>
	<CAMyHAnOevkcXuWt9wh9HsOY8v+C1VmosdQu2EdV91k3ru-dz_Q@mail.gmail.com>
	<23626_1322911241_4EDA0608_23626_11_1_CAEB1mAoUrO5Wn1gXRVkD5LKOpH7B3YO8Omqa-9H0FrDhAbie=Q@mail.gmail.com>
Message-ID: <CEE647BA-B3CB-4E95-8610-138DF5134B4A@mail.mcgill.ca>

Hi Thomas,

I usually follow these instructions:

http://www.wwp.brown.edu/outreach/seminars/_current/handouts/roma_CLI_MacOS_X.html

They say they're for OS X, but I don't see any real reason why they can't be used for Ubuntu too.

There are a couple caveats, though:

-- The Makefile for tei-roma is a bit weird for use on OSX, so it may also be for Ubuntu too if you want to store everything in /usr/local. I filed a bug about it*, but it still does weird things. If you want to keep the Roma configuration stuff in /usr/local/etc (instead of /etc) you will have to edit it. I can send more details about this if you like.

-- You may also have to reverse the order for the "Roma itself" and "Build TEI P5" steps. If you don't do the Build TEI P5 step first, the p5subset.xml file will not exist in your odd/ directory, and the roma build script will fail when it tests for it. If you do the `make oddschema` step first, though, it should produce one. Be careful, though -- if the process fails it will likely produce a file, but it will be empty. On my machine, a compiled p5subset.xml file is about 3.3MB.

I usually then alias the roma command in the shell like this (put this in .bashrc or .zshrc):


export MEI_LOCATION="/path/to/svn/mei/trunk/source/driver.xml"
export TEI_STYLESHEETS="/usr/local/share/xml/tei/stylesheet"

alias mei="/usr/local/bin/roma --localsource=$MEI_LOCATION --xsl=$TEI_STYLESHEETS --nodtd --noxsd $*"


Then I can just pass the customization in on the command line, e.g.,:

$> mei mei-all.xml

and it will create a "RomaResults" directory in the current working directory with the RNG file. (You should also be able to pass in an output directory if you don't want to put it in the CWD, e.g., mei mei-all.xml [outputdir])

Hope this helps!
-Andrew

* http://sourceforge.net/tracker/index.php?func=detail&aid=3304677&group_id=106328&atid=644062

On 2011-12-03, at 6:20 AM, TW wrote:

> Hi Raffaele,
> 
> 2011/12/2 Raffaele Viglianti <raffaeleviglianti at gmail.com>:
>> If I understand your problem correctly, you should create an ODD
>> customization. Look at /MEI_dev/customizations/mei-all.xml as an example.
>> That file selects all the modules. You can make a copy and comment out the
>> modules that you want to exclude.
>> 
>> At this point you have a few options to generate an RNG and XSD from the
>> source + customization. This is what I usually do on a Unix system:
>> 
>> 1. checkout TEI's trunk from sourceforge if you don't have it already
>> 2. make sure you have all the dependecies (trang, saxon, xmllint)
>> 3. go to /Roma
>> 4. run the command:
>> 
>> ./roma2 --xsl=../Stylesheets --localsource=fullPathTo_mei-2011-05-source.xml
>> fullPathToYourCustomization
>> 
>> 5. Under RomaResults you'll find the resulting RNG and XSD.
>> 
> 
> I need some more assistance.
> 
> Problem 1:  /trunk/Roma/roma2.sh relies on command "saxon".  On my
> Ubuntu Natty system I have the packages libsaxon-java, libsaxonb-java
> and libsaxon-java-gcj installed, but they don't come with this
> command.  So I changed "saxon" to "saxonb-xslt".  But then I get
> 
> Error at xsl:result-document on line 1851 of
> file:/home/tom/tei/trunk/Stylesheets/odds2/teiodds.xsl:
>  xsl:result-document is disabled when extension functions are disabled
> 
> So I inserted -ext:on, which *seemed* to get me somewhere (after I
> created some directory that Roma wanted to put the results).
> 
> Problem 2:  I did the following, using the unmodified mei-all.xml for testing:
> 
> 
> tom at desktop:~$ tei/trunk/Roma/roma2.sh --xsl=tei/trunk/Stylesheets
> --localsource=music-encoding/trunk/source/specs/mei-2011-05-source.xml
> music-encoding/trunk/customizations/mei-all.xml
> ========= Roma starts at 2011-12-03 12:05:09 ===========
> TEI stylesheet tree: tei/trunk/Stylesheets
> Results to: RomaResults
> Process music-encoding/trunk/customizations/mei-all.xml to create
> mei{.dtd|.xsd|.doc.xml|.rng|.rnc} in RomaResults
> ========= Roma version VVVERSION starts execution at 2011-12-03
> 12:05:10.208637972 ===========
> using /home/tom/music-encoding/trunk/source/specs/mei-2011-05-source.xml
> as default source
> 1. expand and simplify ODD
> 2. make RELAX NG from compiled ODD
> 3. make RELAX NG compact from XML
> 4. make XSD from RELAX NG
> /home/tom/RomaResults/mei.rng:11:13: error: restriction violation:
> "start" contains "empty"
> 
> 
> ERROR:  trang fails.
> This was a fatal error. 2011-12-03 12:05:14
> 5. make DTD from compiled ODD
> ========= 2011-12-03 12:05:16.785145931 Roma ends
> 
> 
> The generated RNG looks like:
> 
> 
> <?xml version="1.0" encoding="utf-8"?>
> <grammar xmlns="http://relaxng.org/ns/structure/1.0"
> xmlns:xlink="http://www.w3.org/1999/xlink"
> datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
> ns="http://www.music-encoding.org/ns/mei">
>  <!--
> Schema generated from ODD source 2011-12-03T12:05:14Z.
> Edition:
> Edition Location: http://www.tei-c.org/Vault/P5//
> 
> -->
>  <!---->
>  <start>
>    <empty/>
>  </start>
> </grammar>
> 
> 
> Something tells me this is flawed.
> 
> I saw there are Debian packages available[1] and added them to my
> software sources.  I installed the packages tei-roma, saxon and
> tei-p5-xsl2.  The result was pretty much the same:
> 
> 
> tom at desktop:~/music-encoding/trunk/customizations$ roma mei-all.xml mei-all
> ========= Roma starts at 2011-12-03 12:13:48 ===========
> TEI stylesheet tree: /usr/share/xml/tei/stylesheet
> Results to: mei-all
> Process mei-all.xml to create mei{.dtd|.xsd|.doc.xml|.rng|.rnc} in mei-all
> ========= Roma version 4.7 starts execution at 2011-12-03
> 12:13:49.646907172 ===========
> 1. expand and simplify ODD
> 2. make RELAX NG from compiled ODD
> 3. make RELAX NG compact from XML
> 4. make XSD from RELAX NG
> /home/tom/music-encoding/trunk/customizations/mei-all/mei.rng:11:13:
> error: restriction violation: "start" contains "empty"
> 
> 
> ERROR:  trang fails.
> This was a fatal error. 2011-12-03 12:14:00
> 5. make DTD from compiled ODD
> ========= 2011-12-03 12:14:03.531732571 Roma ends
> 
> 
> What can I do?
> 
> Thanks!
> Thomas
> 
> 
> [1] http://tei.oucs.ox.ac.uk/teideb/
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From raffaeleviglianti at gmail.com  Sun Dec  4 09:33:28 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Sun, 4 Dec 2011 08:33:28 +0000
Subject: [MEI-L] Converting specs to schema
In-Reply-To: <CEE647BA-B3CB-4E95-8610-138DF5134B4A@mail.mcgill.ca>
References: <CAEB1mAoGaP=Z8UHGT2sfgPj=Topw5JbxzSu_re5Qj9S=0iqd5g@mail.gmail.com>
	<CAMyHAnOevkcXuWt9wh9HsOY8v+C1VmosdQu2EdV91k3ru-dz_Q@mail.gmail.com>
	<23626_1322911241_4EDA0608_23626_11_1_CAEB1mAoUrO5Wn1gXRVkD5LKOpH7B3YO8Omqa-9H0FrDhAbie=Q@mail.gmail.com>
	<CEE647BA-B3CB-4E95-8610-138DF5134B4A@mail.mcgill.ca>
Message-ID: <CAMyHAnOdjBe_O=4U+tPBn0rQfDMYE0QObfWzy4PmCeNJdMCYMQ@mail.gmail.com>

Hi Thomas and Andrew,

I usually don't build TEI, since you can use --xsl=../Stylesheet to simply
point to the XSLTs in the svn trunk.
For saxon, I also avoid packages and get the latest version from the saxon
website (usually I use the home edition). I write a shell script like this:

java -jar saxon(version).jar $*

and link to it from /usr/bin/saxon

I think saxonb-xslt may be the problem here, so try to get saxon9HE from
their website instead.

Best,
Raffaele

On Sat, Dec 3, 2011 at 10:24 PM, Andrew Hankinson, Mr <
andrew.hankinson at mail.mcgill.ca> wrote:

> Hi Thomas,
>
> I usually follow these instructions:
>
>
> http://www.wwp.brown.edu/outreach/seminars/_current/handouts/roma_CLI_MacOS_X.html
>
> They say they're for OS X, but I don't see any real reason why they can't
> be used for Ubuntu too.
>
> There are a couple caveats, though:
>
> -- The Makefile for tei-roma is a bit weird for use on OSX, so it may also
> be for Ubuntu too if you want to store everything in /usr/local. I filed a
> bug about it*, but it still does weird things. If you want to keep the Roma
> configuration stuff in /usr/local/etc (instead of /etc) you will have to
> edit it. I can send more details about this if you like.
>
> -- You may also have to reverse the order for the "Roma itself" and "Build
> TEI P5" steps. If you don't do the Build TEI P5 step first, the
> p5subset.xml file will not exist in your odd/ directory, and the roma build
> script will fail when it tests for it. If you do the `make oddschema` step
> first, though, it should produce one. Be careful, though -- if the process
> fails it will likely produce a file, but it will be empty. On my machine, a
> compiled p5subset.xml file is about 3.3MB.
>
> I usually then alias the roma command in the shell like this (put this in
> .bashrc or .zshrc):
>
>
> export MEI_LOCATION="/path/to/svn/mei/trunk/source/driver.xml"
> export TEI_STYLESHEETS="/usr/local/share/xml/tei/stylesheet"
>
> alias mei="/usr/local/bin/roma --localsource=$MEI_LOCATION
> --xsl=$TEI_STYLESHEETS --nodtd --noxsd $*"
>
>
> Then I can just pass the customization in on the command line, e.g.,:
>
> $> mei mei-all.xml
>
> and it will create a "RomaResults" directory in the current working
> directory with the RNG file. (You should also be able to pass in an output
> directory if you don't want to put it in the CWD, e.g., mei mei-all.xml
> [outputdir])
>
> Hope this helps!
> -Andrew
>
> *
> http://sourceforge.net/tracker/index.php?func=detail&aid=3304677&group_id=106328&atid=644062
>
> On 2011-12-03, at 6:20 AM, TW wrote:
>
> > Hi Raffaele,
> >
> > 2011/12/2 Raffaele Viglianti <raffaeleviglianti at gmail.com>:
> >> If I understand your problem correctly, you should create an ODD
> >> customization. Look at /MEI_dev/customizations/mei-all.xml as an
> example.
> >> That file selects all the modules. You can make a copy and comment out
> the
> >> modules that you want to exclude.
> >>
> >> At this point you have a few options to generate an RNG and XSD from the
> >> source + customization. This is what I usually do on a Unix system:
> >>
> >> 1. checkout TEI's trunk from sourceforge if you don't have it already
> >> 2. make sure you have all the dependecies (trang, saxon, xmllint)
> >> 3. go to /Roma
> >> 4. run the command:
> >>
> >> ./roma2 --xsl=../Stylesheets
> --localsource=fullPathTo_mei-2011-05-source.xml
> >> fullPathToYourCustomization
> >>
> >> 5. Under RomaResults you'll find the resulting RNG and XSD.
> >>
> >
> > I need some more assistance.
> >
> > Problem 1:  /trunk/Roma/roma2.sh relies on command "saxon".  On my
> > Ubuntu Natty system I have the packages libsaxon-java, libsaxonb-java
> > and libsaxon-java-gcj installed, but they don't come with this
> > command.  So I changed "saxon" to "saxonb-xslt".  But then I get
> >
> > Error at xsl:result-document on line 1851 of
> > file:/home/tom/tei/trunk/Stylesheets/odds2/teiodds.xsl:
> >  xsl:result-document is disabled when extension functions are disabled
> >
> > So I inserted -ext:on, which *seemed* to get me somewhere (after I
> > created some directory that Roma wanted to put the results).
> >
> > Problem 2:  I did the following, using the unmodified mei-all.xml for
> testing:
> >
> >
> > tom at desktop:~$ tei/trunk/Roma/roma2.sh --xsl=tei/trunk/Stylesheets
> > --localsource=music-encoding/trunk/source/specs/mei-2011-05-source.xml
> > music-encoding/trunk/customizations/mei-all.xml
> > ========= Roma starts at 2011-12-03 12:05:09 ===========
> > TEI stylesheet tree: tei/trunk/Stylesheets
> > Results to: RomaResults
> > Process music-encoding/trunk/customizations/mei-all.xml to create
> > mei{.dtd|.xsd|.doc.xml|.rng|.rnc} in RomaResults
> > ========= Roma version VVVERSION starts execution at 2011-12-03
> > 12:05:10.208637972 ===========
> > using /home/tom/music-encoding/trunk/source/specs/mei-2011-05-source.xml
> > as default source
> > 1. expand and simplify ODD
> > 2. make RELAX NG from compiled ODD
> > 3. make RELAX NG compact from XML
> > 4. make XSD from RELAX NG
> > /home/tom/RomaResults/mei.rng:11:13: error: restriction violation:
> > "start" contains "empty"
> >
> >
> > ERROR:  trang fails.
> > This was a fatal error. 2011-12-03 12:05:14
> > 5. make DTD from compiled ODD
> > ========= 2011-12-03 12:05:16.785145931 Roma ends
> >
> >
> > The generated RNG looks like:
> >
> >
> > <?xml version="1.0" encoding="utf-8"?>
> > <grammar xmlns="http://relaxng.org/ns/structure/1.0"
> > xmlns:xlink="http://www.w3.org/1999/xlink"
> > datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
> > ns="http://www.music-encoding.org/ns/mei">
> >  <!--
> > Schema generated from ODD source 2011-12-03T12:05:14Z.
> > Edition:
> > Edition Location: http://www.tei-c.org/Vault/P5//
> >
> > -->
> >  <!---->
> >  <start>
> >    <empty/>
> >  </start>
> > </grammar>
> >
> >
> > Something tells me this is flawed.
> >
> > I saw there are Debian packages available[1] and added them to my
> > software sources.  I installed the packages tei-roma, saxon and
> > tei-p5-xsl2.  The result was pretty much the same:
> >
> >
> > tom at desktop:~/music-encoding/trunk/customizations$ roma mei-all.xml
> mei-all
> > ========= Roma starts at 2011-12-03 12:13:48 ===========
> > TEI stylesheet tree: /usr/share/xml/tei/stylesheet
> > Results to: mei-all
> > Process mei-all.xml to create mei{.dtd|.xsd|.doc.xml|.rng|.rnc} in
> mei-all
> > ========= Roma version 4.7 starts execution at 2011-12-03
> > 12:13:49.646907172 ===========
> > 1. expand and simplify ODD
> > 2. make RELAX NG from compiled ODD
> > 3. make RELAX NG compact from XML
> > 4. make XSD from RELAX NG
> > /home/tom/music-encoding/trunk/customizations/mei-all/mei.rng:11:13:
> > error: restriction violation: "start" contains "empty"
> >
> >
> > ERROR:  trang fails.
> > This was a fatal error. 2011-12-03 12:14:00
> > 5. make DTD from compiled ODD
> > ========= 2011-12-03 12:14:03.531732571 Roma ends
> >
> >
> > What can I do?
> >
> > Thanks!
> > Thomas
> >
> >
> > [1] http://tei.oucs.ox.ac.uk/teideb/
> >
> > _______________________________________________
> > 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/20111204/10fadf58/attachment.html>

From zupftom at googlemail.com  Sun Dec  4 12:46:02 2011
From: zupftom at googlemail.com (TW)
Date: Sun, 4 Dec 2011 12:46:02 +0100
Subject: [MEI-L] Converting specs to schema
In-Reply-To: <CAMyHAnOevkcXuWt9wh9HsOY8v+C1VmosdQu2EdV91k3ru-dz_Q@mail.gmail.com>
References: <CAEB1mAoGaP=Z8UHGT2sfgPj=Topw5JbxzSu_re5Qj9S=0iqd5g@mail.gmail.com>
	<CAMyHAnOevkcXuWt9wh9HsOY8v+C1VmosdQu2EdV91k3ru-dz_Q@mail.gmail.com>
Message-ID: <CAEB1mApR4oyomrcfn+661fHB-Nt87MSCtET8dmO3OGybyiuPFQ@mail.gmail.com>

2011/12/2 Raffaele Viglianti <raffaeleviglianti at gmail.com>:
>
> 1. checkout TEI's trunk from sourceforge if you don't have it already
> 2. make sure you have all the dependecies (trang, saxon, xmllint)
> 3. go to /Roma
> 4. run the command:
>
> ./roma2 --xsl=../Stylesheets --localsource=fullPathTo_mei-2011-05-source.xml
> fullPathToYourCustomization
>

As it turns out, mei-2011-05-source.xml isn't the file to use as
--localsource.  With the following commands I was successful:

xmllint --noent music-encoding/trunk/source/driver.xml >
music-encoding/trunk/source/source.xml
tei/trunk/Roma/roma2.sh --xsl=tei/trunk/Stylesheets
--localsource=music-encoding/trunk/source/source.xml
music-encoding/trunk/customizations/mei-all.xml

(Thanks to Daniel for helping me offlist.)

Thomas


From raffaeleviglianti at gmail.com  Sun Dec  4 13:13:51 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Sun, 4 Dec 2011 12:13:51 +0000
Subject: [MEI-L] Converting specs to schema
In-Reply-To: <CAEB1mApR4oyomrcfn+661fHB-Nt87MSCtET8dmO3OGybyiuPFQ@mail.gmail.com>
References: <CAEB1mAoGaP=Z8UHGT2sfgPj=Topw5JbxzSu_re5Qj9S=0iqd5g@mail.gmail.com>
	<CAMyHAnOevkcXuWt9wh9HsOY8v+C1VmosdQu2EdV91k3ru-dz_Q@mail.gmail.com>
	<CAEB1mApR4oyomrcfn+661fHB-Nt87MSCtET8dmO3OGybyiuPFQ@mail.gmail.com>
Message-ID: <CAMyHAnMmvB_6M79KOB5rX-w+tosOonMeD6tyrCi=d5ckmhw51A@mail.gmail.com>

Hello,

driver.xml loads in the different bits (i.e. guidelines + schema
specifications), but roma operates directly on //tei:schemaSpec to generate
the RNG. The element is located in mei-2011-05-source.xml. I run roma on it
without problems.

The new roma also runs xmllint before expanding the ODD, so there should be
no need to run it before hand.

A bit confused, but happy that it ended up working,
Raffaele

On Sun, Dec 4, 2011 at 11:46 AM, TW <zupftom at googlemail.com> wrote:

> 2011/12/2 Raffaele Viglianti <raffaeleviglianti at gmail.com>:
> >
> > 1. checkout TEI's trunk from sourceforge if you don't have it already
> > 2. make sure you have all the dependecies (trang, saxon, xmllint)
> > 3. go to /Roma
> > 4. run the command:
> >
> > ./roma2 --xsl=../Stylesheets
> --localsource=fullPathTo_mei-2011-05-source.xml
> > fullPathToYourCustomization
> >
>
> As it turns out, mei-2011-05-source.xml isn't the file to use as
> --localsource.  With the following commands I was successful:
>
> xmllint --noent music-encoding/trunk/source/driver.xml >
> music-encoding/trunk/source/source.xml
> tei/trunk/Roma/roma2.sh --xsl=tei/trunk/Stylesheets
> --localsource=music-encoding/trunk/source/source.xml
> music-encoding/trunk/customizations/mei-all.xml
>
> (Thanks to Daniel for helping me offlist.)
>
> Thomas
>
> _______________________________________________
> 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/20111204/a957d13b/attachment.html>

From zupftom at googlemail.com  Thu Dec  8 20:53:47 2011
From: zupftom at googlemail.com (TW)
Date: Thu, 8 Dec 2011 20:53:47 +0100
Subject: [MEI-L] neumes samples anywhere?
Message-ID: <CAEB1mApZzMfrbSqfCNVvKCCPMbzoX7Ve+hYbqrs419VeMPJKug@mail.gmail.com>

Hi all,

I'd like to have a look at neumes in MEI and wondered whether anyone
has some examples to share.  Up to now the samples on Google Code are
lacking neumes.

Thanks!
Thomas Weber


From andrew.hankinson at mail.mcgill.ca  Thu Dec  8 21:14:57 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Thu, 8 Dec 2011 20:14:57 +0000
Subject: [MEI-L] neumes samples anywhere?
In-Reply-To: <27254_1323374041_4EE115D9_27254_320_1_CAEB1mApZzMfrbSqfCNVvKCCPMbzoX7Ve+hYbqrs419VeMPJKug@mail.gmail.com>
References: <27254_1323374041_4EE115D9_27254_320_1_CAEB1mApZzMfrbSqfCNVvKCCPMbzoX7Ve+hYbqrs419VeMPJKug@mail.gmail.com>
Message-ID: <1CA32E60-A5EB-40CB-8B59-408E5DD24040@mail.mcgill.ca>

Hi Thomas,

There are a couple examples in the old sample directory at tags/MEI_development_2011-07-22/trunk/Documents. 

O Splendissima Gemma
O vos Imitatores

They are originally in MEI 2010 (so non camel-case tags). I can send you updated versions of them off-list if you like.

-Andrew

On 2011-12-08, at 2:53 PM, TW wrote:

> Hi all,
> 
> I'd like to have a look at neumes in MEI and wondered whether anyone
> has some examples to share.  Up to now the samples on Google Code are
> lacking neumes.
> 
> Thanks!
> Thomas Weber
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l



From stefan.morent at uni-tuebingen.de  Thu Dec  8 21:17:23 2011
From: stefan.morent at uni-tuebingen.de (Prof. Dr. Morent)
Date: Thu, 08 Dec 2011 21:17:23 +0100
Subject: [MEI-L] neumes samples anywhere?
In-Reply-To: <CAEB1mApZzMfrbSqfCNVvKCCPMbzoX7Ve+hYbqrs419VeMPJKug@mail.gmail.com>
References: <CAEB1mApZzMfrbSqfCNVvKCCPMbzoX7Ve+hYbqrs419VeMPJKug@mail.gmail.com>
Message-ID: <20111208211723.10884rlel3kxsbpv@webmail.uni-tuebingen.de>

Hi Thomas,

within the T?Bingen project we developed the MEI neumes module for  
encoding neumes written on a stave.

We used it for encoding several of the compositions of Hildegard von  
Bingen and also for the MEI neumes viewer which creates an online  
transcription of the MEI file within the browser.

You might have a look at

www.dimused.info

and

http://www.dimused.uni-tuebingen.de/hildegard

Please feel free to contact me if there are any questions ...

Best regards
Stefan

*********
Prof. Dr. Stefan Morent
Musikwissenschaftliches Seminar
Universit?t Heidelberg
www.dimused.info



Zitat von TW <zupftom at googlemail.com>:

> Hi all,
>
> I'd like to have a look at neumes in MEI and wondered whether anyone
> has some examples to share.  Up to now the samples on Google Code are
> lacking neumes.
>
> Thanks!
> Thomas Weber
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>



From zupftom at googlemail.com  Thu Dec  8 22:18:19 2011
From: zupftom at googlemail.com (TW)
Date: Thu, 8 Dec 2011 22:18:19 +0100
Subject: [MEI-L] @clef* inside scoredef
In-Reply-To: <CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
References: <CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
Message-ID: <CAEB1mApwLab-usFmovH5zHOCMkp_Q_B6e5UAKCVJPCAqpTWVXA@mail.gmail.com>

I'm grave digging an old thread because I noticed that this is still
in MEI 2012:

2011/7/10 TW <zupftom at googlemail.com>:
> I'm wondering why the @clef* family of attributes is allowed on
> <scoredef>, but the <clef> element isn't.
>

(only with camelCase <scoreDef>).  Is there a specific reason?

Thomas


From zupftom at googlemail.com  Thu Dec  8 22:23:38 2011
From: zupftom at googlemail.com (TW)
Date: Thu, 8 Dec 2011 22:23:38 +0100
Subject: [MEI-L] neumes samples anywhere?
In-Reply-To: <20111208211723.10884rlel3kxsbpv@webmail.uni-tuebingen.de>
References: <CAEB1mApZzMfrbSqfCNVvKCCPMbzoX7Ve+hYbqrs419VeMPJKug@mail.gmail.com>
	<20111208211723.10884rlel3kxsbpv@webmail.uni-tuebingen.de>
Message-ID: <CAEB1mAqHop-5e_M4f+mQZVGDpYwu8w4ZqAPynqGydwRuKT3kRg@mail.gmail.com>

2011/12/8 Prof. Dr. Morent <stefan.morent at uni-tuebingen.de>:
> within the T?Bingen project we developed the MEI neumes module for encoding
> neumes written on a stave.
>
> We used it for encoding several of the compositions of Hildegard von Bingen
> and also for the MEI neumes viewer which creates an online transcription of
> the MEI file within the browser.
>
> You might have a look at
>
> www.dimused.info
>
> and
>
> http://www.dimused.uni-tuebingen.de/hildegard
>

Why didn't I know about this earlier?  I like it very much.

> Please feel free to contact me if there are any questions ...
>

I'll certainly make use of this offer.  But first I'll have a closer look.

Thomas


From zupftom at googlemail.com  Thu Dec  8 22:23:54 2011
From: zupftom at googlemail.com (TW)
Date: Thu, 8 Dec 2011 22:23:54 +0100
Subject: [MEI-L] neumes samples anywhere?
In-Reply-To: <1CA32E60-A5EB-40CB-8B59-408E5DD24040@mail.mcgill.ca>
References: <27254_1323374041_4EE115D9_27254_320_1_CAEB1mApZzMfrbSqfCNVvKCCPMbzoX7Ve+hYbqrs419VeMPJKug@mail.gmail.com>
	<1CA32E60-A5EB-40CB-8B59-408E5DD24040@mail.mcgill.ca>
Message-ID: <CAEB1mAoknyZP0uPXeiOYaZYRt5k66UwrUnrkzX89A2sjcXXp_w@mail.gmail.com>

2011/12/8 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
> There are a couple examples in the old sample directory at tags/MEI_development_2011-07-22/trunk/Documents.
>
> O Splendissima Gemma
> O vos Imitatores
>
> They are originally in MEI 2010 (so non camel-case tags). I can send you updated versions of them off-list if you like.
>

Thanks, Andrew!  Does anything speak against adding them to the
current samples?  I see those two can be viewed in the MEI Neumes
Viewer from T?bingen.

Thomas


From pdr4h at eservices.virginia.edu  Thu Dec  8 23:42:47 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Thu, 8 Dec 2011 22:42:47 +0000
Subject: [MEI-L] @clef* inside scoredef
In-Reply-To: <CAEB1mApwLab-usFmovH5zHOCMkp_Q_B6e5UAKCVJPCAqpTWVXA@mail.gmail.com>
References: <CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>,
	<CAEB1mApwLab-usFmovH5zHOCMkp_Q_B6e5UAKCVJPCAqpTWVXA@mail.gmail.com>
Message-ID: <950B1ACF-9A1C-48A3-AFF3-3395F028003F@mimectl>

Hi, Thomas,



I think you're asking -- Why are the clef* attributes allowed on <scoreDef> but the <clef> element isn't allowed as a child of <scoreDef>?  Is that right?



I've been waiting for someone else to notice this before I brought it up myself :) because I anticipated that the next request would be for <clef> and <meter> elements and so on until all the attributes on <scoreDef> were duplicated by element children.  I was hoping to limit these requests to those that couldn't be fulfilled by an attribute -- in other words, where more than one value might be needed or where more detailed data was needed, such as explicit placement information on the accidentals in a key signature.



But, the tech group could/should discuss adding <clef> (and perhaps <clefGrp>) as well -- these are members of model.staffDefPart. Next, maybe <meter>.  These can all be proposed for the next, next MEI revision (2013?).  But, we must be careful because if the list of new elements for <scoreDef> goes much beyond these, then it will have ripple effects throughout the schema that will require much more discussion / work.



Does this help?



--

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 TW [zupftom at googlemail.com]
Sent: Thursday, December 08, 2011 4:18 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] @clef* inside scoredef

I'm grave digging an old thread because I noticed that this is still
in MEI 2012:

2011/7/10 TW <zupftom at googlemail.com>:
> I'm wondering why the @clef* family of attributes is allowed on
> <scoredef>, but the <clef> element isn't.
>

(only with camelCase <scoreDef>).  Is there a specific reason?

Thomas

_______________________________________________
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/20111208/6c700ae1/attachment.html>

From zupftom at googlemail.com  Fri Dec  9 09:01:14 2011
From: zupftom at googlemail.com (TW)
Date: Fri, 9 Dec 2011 09:01:14 +0100
Subject: [MEI-L] @clef* inside scoredef
In-Reply-To: <950B1ACF-9A1C-48A3-AFF3-3395F028003F@mimectl>
References: <CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
	<CAEB1mApwLab-usFmovH5zHOCMkp_Q_B6e5UAKCVJPCAqpTWVXA@mail.gmail.com>
	<950B1ACF-9A1C-48A3-AFF3-3395F028003F@mimectl>
Message-ID: <CAEB1mAqgk15O1mV=iJgNYthXADdr0Z2AeACLBY4mhLafhWg-LQ@mail.gmail.com>

2011/12/8 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> I think you're asking --?Why are the clef* attributes allowed on
> <scoreDef>?but the <clef> element isn't allowed as a child of <scoreDef>?
> Is that right?
>

Right.

>
> I've been waiting for someone else to notice this before I brought it up
> myself :) because I anticipated that the next request would be for?<clef>
> and?<meter> elements and so on until all the attributes on <scoreDef>?were
> duplicated by element children.? I was hoping to limit these requests to
> those that couldn't be fulfilled by an attribute -- in other words, where
> more than one value might be needed or where more detailed data was needed,
> such as explicit placement information on the accidentals in a key
> signature.
>
>
>
> But,?the tech group?could/should?discuss adding <clef> (and perhaps
> <clefGrp>) as well -- these are members of model.staffDefPart. Next, maybe
> <meter>.? These can all be proposed for the next, next MEI revision
> (2013?).? But, we must be careful?because if the list of new elements for
> <scoreDef> goes much beyond these, then it will have ripple effects
> throughout the schema that will require much more discussion / work.
>

Maybe less is more?  Couldn't the clef attributes be removed from
<scoreDef>?  I might be missing the reason why they were allowed there
in the first place.  A clef doesn't make sense without a staff, and
where there's a staff, there is a <staffDef> where the clef attributes
and elements can go.  What do clef attributes inside the <scoreDef> of
a multi-staff score mean anyway?

Thomas


From pdr4h at eservices.virginia.edu  Fri Dec  9 15:34:04 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Fri, 9 Dec 2011 14:34:04 +0000
Subject: [MEI-L] @clef* inside scoredef
In-Reply-To: <CAEB1mAqgk15O1mV=iJgNYthXADdr0Z2AeACLBY4mhLafhWg-LQ@mail.gmail.com>
References: <CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
	<CAEB1mApwLab-usFmovH5zHOCMkp_Q_B6e5UAKCVJPCAqpTWVXA@mail.gmail.com>
	<950B1ACF-9A1C-48A3-AFF3-3395F028003F@mimectl>,
	<CAEB1mAqgk15O1mV=iJgNYthXADdr0Z2AeACLBY4mhLafhWg-LQ@mail.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D01121DAE@reagan.eservices.virginia.edu>

> What do clef attributes inside the <scoreDef> of a multi-staff score mean anyway?

Ahh, I'm so glad you asked. I was wondering whether I shouldn't have added this to my response yesterday. ;)

The attributes on <scoreDef> were originally intended to carry *software default* values; that is, they would be a place to store values that could be used to 1) supply inheritable values when a following element, say, a <staffDef> or <staff> somewhere down in the document, lacked a clef and 2) to supply default values when programmatically creating new elements.

As an example of point 2 above, if the value of @clef.shape and @clef.line on <scoreDef> were set to "C" and "3", respectively, then a score editor could put an alto clef on every newly created staff.  This also works at the staff and layer levels -- @clef.shape and @clef.line on <staffDef> "over-ride" the values given at the score-level and these attributes on <layerDef> supercede those at the staff-level.

So, "def" in the original sense, meant "default"; it was only later than "def" came to mean "definition".  But reframing <scoreDef> this way is useful because it means that the element can be used throughout the document to indicate changes.

Even so, when using MEI to *describe existing notation*, you're right -- some attributes on <scoreDef> aren't particularly useful.  Or put a different, hopefully better way, it's better to use those attributes on <staffDef> and <layerDef>.  It's a good thing they're optional.  :)

Helpful?

--
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 TW [zupftom at googlemail.com]
Sent: Friday, December 09, 2011 3:01 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] @clef* inside scoredef

2011/12/8 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> I think you're asking -- Why are the clef* attributes allowed on
> <scoreDef> but the <clef> element isn't allowed as a child of <scoreDef>?
> Is that right?
>

Right.

>
> I've been waiting for someone else to notice this before I brought it up
> myself :) because I anticipated that the next request would be for <clef>
> and <meter> elements and so on until all the attributes on <scoreDef> were
> duplicated by element children.  I was hoping to limit these requests to
> those that couldn't be fulfilled by an attribute -- in other words, where
> more than one value might be needed or where more detailed data was needed,
> such as explicit placement information on the accidentals in a key
> signature.
>
>
>
> But, the tech group could/should discuss adding <clef> (and perhaps
> <clefGrp>) as well -- these are members of model.staffDefPart. Next, maybe
> <meter>.  These can all be proposed for the next, next MEI revision
> (2013?).  But, we must be careful because if the list of new elements for
> <scoreDef> goes much beyond these, then it will have ripple effects
> throughout the schema that will require much more discussion / work.
>

Maybe less is more?  Couldn't the clef attributes be removed from
<scoreDef>?  I might be missing the reason why they were allowed there
in the first place.  A clef doesn't make sense without a staff, and
where there's a staff, there is a <staffDef> where the clef attributes
and elements can go.  What do clef attributes inside the <scoreDef> of
a multi-staff score mean anyway?

Thomas

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

From zupftom at googlemail.com  Fri Dec  9 16:20:20 2011
From: zupftom at googlemail.com (TW)
Date: Fri, 9 Dec 2011 16:20:20 +0100
Subject: [MEI-L] @clef* inside scoredef
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D01121DAE@reagan.eservices.virginia.edu>
References: <CAEB1mAp9Bo-otnSLdU0bCx5dcP5T2FZ_=DP12CdqF+wz_QNzuQ@mail.gmail.com>
	<CAEB1mApwLab-usFmovH5zHOCMkp_Q_B6e5UAKCVJPCAqpTWVXA@mail.gmail.com>
	<950B1ACF-9A1C-48A3-AFF3-3395F028003F@mimectl>
	<CAEB1mAqgk15O1mV=iJgNYthXADdr0Z2AeACLBY4mhLafhWg-LQ@mail.gmail.com>
	<BBCC497C40D85642B90E9F94FC30343D01121DAE@reagan.eservices.virginia.edu>
Message-ID: <CAEB1mAozCoZ-G63QwhLvqtXqucc847t=u2jWGmrChX8wYSACzA@mail.gmail.com>

2011/12/9 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>> What do clef attributes inside the <scoreDef> of a multi-staff score mean anyway?
>
> Ahh, I'm so glad you asked. I was wondering whether I shouldn't have added this to my response yesterday. ;)
>
> The attributes on <scoreDef> were originally intended to carry *software default* values; that is, they would be a place to store values that could be used to 1) supply inheritable values when a following element, say, a <staffDef> or <staff> somewhere down in the document, lacked a clef and 2) to supply default values when programmatically creating new elements.
>
> As an example of point 2 above, if the value of @clef.shape and @clef.line on <scoreDef> were set to "C" and "3", respectively, then a score editor could put an alto clef on every newly created staff. ?This also works at the staff and layer levels -- @clef.shape and @clef.line on <staffDef> "over-ride" the values given at the score-level and these attributes on <layerDef> supercede those at the staff-level.
>
> So, "def" in the original sense, meant "default"; it was only later than "def" came to mean "definition". ?But reframing <scoreDef> this way is useful because it means that the element can be used throughout the document to indicate changes.
>
> Even so, when using MEI to *describe existing notation*, you're right -- some attributes on <scoreDef> aren't particularly useful. ?Or put a different, hopefully better way, it's better to use those attributes on <staffDef> and <layerDef>. ?It's a good thing they're optional. ?:)
>
> Helpful?

Yes, that makes the reasoning clear.  (Hey, I have a *great* idea:
Let's introduce yet another domain, the processing domain!!  ...
Cough, O.K., I'll go back to my corner and remain quiet.)

Thomas


From zupftom at googlemail.com  Thu Dec 15 17:48:13 2011
From: zupftom at googlemail.com (TW)
Date: Thu, 15 Dec 2011 17:48:13 +0100
Subject: [MEI-L] neumes samples anywhere?
In-Reply-To: <1CA32E60-A5EB-40CB-8B59-408E5DD24040@mail.mcgill.ca>
References: <27254_1323374041_4EE115D9_27254_320_1_CAEB1mApZzMfrbSqfCNVvKCCPMbzoX7Ve+hYbqrs419VeMPJKug@mail.gmail.com>
	<1CA32E60-A5EB-40CB-8B59-408E5DD24040@mail.mcgill.ca>
Message-ID: <CAEB1mApF4ExDA4ja46q11PLjk8N=iPGCduNumhrgNTR6vC9WUw@mail.gmail.com>

2011/12/8 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
> There are a couple examples in the old sample directory at tags/MEI_development_2011-07-22/trunk/Documents.
>
> O Splendissima Gemma
> O vos Imitatores
>

I noticed those examples don't record on which "scale step" the neumes
are positioned.  AFAIKS there's only the att.xy class of attributes
that would be suited to record the position.  It seems a bit odd to
use those visual domain attributes to describe something logical.  I'd
expect something along the lines of @line on <clef>s.

Thomas


From andrew.hankinson at mail.mcgill.ca  Thu Dec 15 18:27:53 2011
From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr)
Date: Thu, 15 Dec 2011 17:27:53 +0000
Subject: [MEI-L] neumes samples anywhere?
In-Reply-To: <21489_1323967708_4EEA24DB_21489_57_1_CAEB1mApF4ExDA4ja46q11PLjk8N=iPGCduNumhrgNTR6vC9WUw@mail.gmail.com>
References: <27254_1323374041_4EE115D9_27254_320_1_CAEB1mApZzMfrbSqfCNVvKCCPMbzoX7Ve+hYbqrs419VeMPJKug@mail.gmail.com>
	<1CA32E60-A5EB-40CB-8B59-408E5DD24040@mail.mcgill.ca>
	<21489_1323967708_4EEA24DB_21489_57_1_CAEB1mApF4ExDA4ja46q11PLjk8N=iPGCduNumhrgNTR6vC9WUw@mail.gmail.com>
Message-ID: <7BCFAF77-C8F5-46D5-A725-DA360507619F@mail.mcgill.ca>

Hi Thomas,

There are a couple things to note about these examples:

1. The originals (and Stefan Morent can correct me if I'm wrong) were not on a staff. Any explicit pitches are actually supplied, since there are no absolute scale degrees given in this type of notation -- just relative directions for each neume. I don't have a link to the original images, but you can see an example of what this might look like here: http://www.cs.bham.ac.uk/~aps/research/projects/neumes/neumes.php (scroll down...)

2. A neume functions like a standardized ligature; in other words, neumes are identified and distinguished by their shapes and how many notes they connect together into one grouping. This is determined by which direction the note components are going: e.g., if you have three notes ascending, the neume is likely a scandicus; an alternating up-down for three notes produces a torculus. So, in that sense neumes are actually just grouping functions for the notes themselves. They don't directly encode pitch information, but rather function as a "container" for pitch information.

If you look at the O splendissima example, you'll see that there are two clefs defined on staff 1 (two clefs on one staff is very common in early notation). Putting aside the fact that this is likely supplied in the encoding and not in the original, it is entirely possible to determine the neume position based on the clef, since the note/octave information would give the line position. But, like I said, it's entirely possible to have a neume with no pitches supplied, in which case you would simply have the shape.

To complicate matters even further, different styles of neume notation are interpreted in different ways; some forms of neume notation carry implicit (or even explicit) rhythmic instructions, or some carry implicit (or explicit) interval information, depending on the context of the neume and the practices of the community that originally wrote it (practices that are largely lost in time, since they were very rarely written). It would then be up to some form of processing--software or human--to determine how to interpret these shapes into some form of pitch information.

Are you sorry you asked now? :)

-Andrew

On 2011-12-15, at 11:48 AM, TW wrote:

> 2011/12/8 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>> There are a couple examples in the old sample directory at tags/MEI_development_2011-07-22/trunk/Documents.
>> 
>> O Splendissima Gemma
>> O vos Imitatores
>> 
> 
> I noticed those examples don't record on which "scale step" the neumes
> are positioned.  AFAIKS there's only the att.xy class of attributes
> that would be suited to record the position.  It seems a bit odd to
> use those visual domain attributes to describe something logical.  I'd
> expect something along the lines of @line on <clef>s.
> 
> Thomas
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1054 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20111215/5024bf71/attachment.bin>

From stefan.morent at uni-tuebingen.de  Thu Dec 15 19:49:05 2011
From: stefan.morent at uni-tuebingen.de (Prof. Dr. Morent)
Date: Thu, 15 Dec 2011 19:49:05 +0100
Subject: [MEI-L] neumes samples anywhere?
In-Reply-To: <7BCFAF77-C8F5-46D5-A725-DA360507619F@mail.mcgill.ca>
References: <27254_1323374041_4EE115D9_27254_320_1_CAEB1mApZzMfrbSqfCNVvKCCPMbzoX7Ve+hYbqrs419VeMPJKug@mail.gmail.com>
	<1CA32E60-A5EB-40CB-8B59-408E5DD24040@mail.mcgill.ca>
	<21489_1323967708_4EEA24DB_21489_57_1_CAEB1mApF4ExDA4ja46q11PLjk8N=iPGCduNumhrgNTR6vC9WUw@mail.gmail.com>
	<7BCFAF77-C8F5-46D5-A725-DA360507619F@mail.mcgill.ca>
Message-ID: <20111215194905.14063nupohoisftt@webmail.uni-tuebingen.de>

Hi Andrew, Thomas,

1. The scribes that notated the music of Hildegard von Bingen in the  
scriptorium of her monastery (probably some fellow sisters or monks  
from monasteries nearby) were rather advanced and already wrote neumes  
on a stave.
Typically this notation uses 4 to 5 lines with c- and f-clef (the  
c-line in yellow, the f-line in red ink). The neumes are transferred  
to the stave with only slight changes to the shapes of so called  
adiastematic neumes which are not written on lines at all (there only  
survives a single example of such adiastematic writing of Hildegard's  
scriptorium).
So the pitch information for these neumes is more or less perfectly  
readable (although there remain many open questions for performance:  
e.g. which was the tuning system andd which absolute pitch was meant  
with the note "e" f. ex.).

An example of the original notation can be found here:
http://www.dimused.uni-tuebingen.de/hildegard_notation.php


This pitch information is encoded within the MEI-files of "O  
splendidissima" or "O vos imitatores".
In fact the MEI neumes viewer uses this pitch information to position  
the notes in the transcription within in the browser.

2. What Andrew was describing is in fact the complexity (and only a  
part) of adiastematic neumes.
For their additional information we are pereparing to enlarge and to  
modify the MEI neumes module, so that it will be able to cover neumes  
written on lines and adiastematic neumes.

They only can be made readable as far as pitches are concerned if a  
(mostly later) source is found with the same melody written on lines.

In some rare cases also certain patterns of neumes which stand for  
modal formulas can be "translated" into pitch information without  
having such a parallel source.

Alas, in some cases, such a source was never found - and thus the  
music written in neumes will forever hide its exact pitch contour  
(this is the case f.ex. for the repetory of "Old Hispanic" chant).

Stefan


Zitat von "Andrew Hankinson, Mr" <andrew.hankinson at mail.mcgill.ca>:

> Hi Thomas,
>
> There are a couple things to note about these examples:
>
> 1. The originals (and Stefan Morent can correct me if I'm wrong)  
> were not on a staff. Any explicit pitches are actually supplied,  
> since there are no absolute scale degrees given in this type of  
> notation -- just relative directions for each neume. I don't have a  
> link to the original images, but you can see an example of what this  
> might look like here:  
> http://www.cs.bham.ac.uk/~aps/research/projects/neumes/neumes.php  
> (scroll down...)
>
> 2. A neume functions like a standardized ligature; in other words,  
> neumes are identified and distinguished by their shapes and how many  
> notes they connect together into one grouping. This is determined by  
> which direction the note components are going: e.g., if you have  
> three notes ascending, the neume is likely a scandicus; an  
> alternating up-down for three notes produces a torculus. So, in that  
> sense neumes are actually just grouping functions for the notes  
> themselves. They don't directly encode pitch information, but rather  
> function as a "container" for pitch information.
>
> If you look at the O splendissima example, you'll see that there are  
> two clefs defined on staff 1 (two clefs on one staff is very common  
> in early notation). Putting aside the fact that this is likely  
> supplied in the encoding and not in the original, it is entirely  
> possible to determine the neume position based on the clef, since  
> the note/octave information would give the line position. But, like  
> I said, it's entirely possible to have a neume with no pitches  
> supplied, in which case you would simply have the shape.
>
> To complicate matters even further, different styles of neume  
> notation are interpreted in different ways; some forms of neume  
> notation carry implicit (or even explicit) rhythmic instructions, or  
> some carry implicit (or explicit) interval information, depending on  
> the context of the neume and the practices of the community that  
> originally wrote it (practices that are largely lost in time, since  
> they were very rarely written). It would then be up to some form of  
> processing--software or human--to determine how to interpret these  
> shapes into some form of pitch information.
>
> Are you sorry you asked now? :)
>
> -Andrew
>
> On 2011-12-15, at 11:48 AM, TW wrote:
>
>> 2011/12/8 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>>> There are a couple examples in the old sample directory at  
>>> tags/MEI_development_2011-07-22/trunk/Documents.
>>>
>>> O Splendissima Gemma
>>> O vos Imitatores
>>>
>>
>> I noticed those examples don't record on which "scale step" the neumes
>> are positioned.  AFAIKS there's only the att.xy class of attributes
>> that would be suited to record the position.  It seems a bit odd to
>> use those visual domain attributes to describe something logical.  I'd
>> expect something along the lines of @line on <clef>s.
>>
>> Thomas
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>




From zupftom at googlemail.com  Thu Dec 15 20:31:48 2011
From: zupftom at googlemail.com (TW)
Date: Thu, 15 Dec 2011 20:31:48 +0100
Subject: [MEI-L] neumes samples anywhere?
In-Reply-To: <20111215194905.14063nupohoisftt@webmail.uni-tuebingen.de>
References: <27254_1323374041_4EE115D9_27254_320_1_CAEB1mApZzMfrbSqfCNVvKCCPMbzoX7Ve+hYbqrs419VeMPJKug@mail.gmail.com>
	<1CA32E60-A5EB-40CB-8B59-408E5DD24040@mail.mcgill.ca>
	<21489_1323967708_4EEA24DB_21489_57_1_CAEB1mApF4ExDA4ja46q11PLjk8N=iPGCduNumhrgNTR6vC9WUw@mail.gmail.com>
	<7BCFAF77-C8F5-46D5-A725-DA360507619F@mail.mcgill.ca>
	<20111215194905.14063nupohoisftt@webmail.uni-tuebingen.de>
Message-ID: <CAEB1mAqaU7dRLMBS=FAtDoCXVU9C7cEmdPjTZcaa1=PV7rd0Gg@mail.gmail.com>

Thanks for your very detailed responses, Stefan and Andrew.

I'm aware that neumes originally don't record the exact pitch, but I
already saw that the neumes in this example were on lines[1].  That's
why I asked, and no, I don't regret it at all :-).

To sum it up, if I want to find out where the neumes were positioned,
I currently would have to derive this from the <note>s inside the
<uneume> elements.  (If we have diastematic neumes.)  But we can
expect to hear more from what's being developed in T?bingen.

Thomas


[1] http://www.ccarh.org/publications/cm/12/02/


2011/12/15 Prof. Dr. Morent <stefan.morent at uni-tuebingen.de>:
> Hi Andrew, Thomas,
>
> 1. The scribes that notated the music of Hildegard von Bingen in the
> scriptorium of her monastery (probably some fellow sisters or monks from
> monasteries nearby) were rather advanced and already wrote neumes on a
> stave.
> Typically this notation uses 4 to 5 lines with c- and f-clef (the c-line in
> yellow, the f-line in red ink). The neumes are transferred to the stave with
> only slight changes to the shapes of so called adiastematic neumes which are
> not written on lines at all (there only survives a single example of such
> adiastematic writing of Hildegard's scriptorium).
> So the pitch information for these neumes is more or less perfectly readable
> (although there remain many open questions for performance: e.g. which was
> the tuning system andd which absolute pitch was meant with the note "e" f.
> ex.).
>
> An example of the original notation can be found here:
> http://www.dimused.uni-tuebingen.de/hildegard_notation.php
>
>
> This pitch information is encoded within the MEI-files of "O splendidissima"
> or "O vos imitatores".
> In fact the MEI neumes viewer uses this pitch information to position the
> notes in the transcription within in the browser.
>
> 2. What Andrew was describing is in fact the complexity (and only a part) of
> adiastematic neumes.
> For their additional information we are pereparing to enlarge and to modify
> the MEI neumes module, so that it will be able to cover neumes written on
> lines and adiastematic neumes.
>
> They only can be made readable as far as pitches are concerned if a (mostly
> later) source is found with the same melody written on lines.
>
> In some rare cases also certain patterns of neumes which stand for modal
> formulas can be "translated" into pitch information without having such a
> parallel source.
>
> Alas, in some cases, such a source was never found - and thus the music
> written in neumes will forever hide its exact pitch contour (this is the
> case f.ex. for the repetory of "Old Hispanic" chant).
>
> Stefan
>
>
> Zitat von "Andrew Hankinson, Mr" <andrew.hankinson at mail.mcgill.ca>:
>
>
>> Hi Thomas,
>>
>> There are a couple things to note about these examples:
>>
>> 1. The originals (and Stefan Morent can correct me if I'm wrong) were not
>> on a staff. Any explicit pitches are actually supplied, since there are no
>> absolute scale degrees given in this type of notation -- just relative
>> directions for each neume. I don't have a link to the original images, but
>> you can see an example of what this might look like here:
>> http://www.cs.bham.ac.uk/~aps/research/projects/neumes/neumes.php (scroll
>> down...)
>>
>> 2. A neume functions like a standardized ligature; in other words, neumes
>> are identified and distinguished by their shapes and how many notes they
>> connect together into one grouping. This is determined by which direction
>> the note components are going: e.g., if you have three notes ascending, the
>> neume is likely a scandicus; an alternating up-down for three notes produces
>> a torculus. So, in that sense neumes are actually just grouping functions
>> for the notes themselves. They don't directly encode pitch information, but
>> rather function as a "container" for pitch information.
>>
>> If you look at the O splendissima example, you'll see that there are two
>> clefs defined on staff 1 (two clefs on one staff is very common in early
>> notation). Putting aside the fact that this is likely supplied in the
>> encoding and not in the original, it is entirely possible to determine the
>> neume position based on the clef, since the note/octave information would
>> give the line position. But, like I said, it's entirely possible to have a
>> neume with no pitches supplied, in which case you would simply have the
>> shape.
>>
>> To complicate matters even further, different styles of neume notation are
>> interpreted in different ways; some forms of neume notation carry implicit
>> (or even explicit) rhythmic instructions, or some carry implicit (or
>> explicit) interval information, depending on the context of the neume and
>> the practices of the community that originally wrote it (practices that are
>> largely lost in time, since they were very rarely written). It would then be
>> up to some form of processing--software or human--to determine how to
>> interpret these shapes into some form of pitch information.
>>
>> Are you sorry you asked now? :)
>>
>> -Andrew
>>
>> On 2011-12-15, at 11:48 AM, TW wrote:
>>
>>> 2011/12/8 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>>>>
>>>> There are a couple examples in the old sample directory at
>>>> tags/MEI_development_2011-07-22/trunk/Documents.
>>>>
>>>> O Splendissima Gemma
>>>> O vos Imitatores
>>>>
>>>
>>> I noticed those examples don't record on which "scale step" the neumes
>>> are positioned. ?AFAIKS there's only the att.xy class of attributes
>>> that would be suited to record the position. ?It seems a bit odd to
>>> use those visual domain attributes to describe something logical. ?I'd
>>> expect something along the lines of @line on <clef>s.
>>>
>>> Thomas
>>>
>>> _______________________________________________
>>> 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


From pdr4h at eservices.virginia.edu  Mon Dec 19 16:28:14 2011
From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h))
Date: Mon, 19 Dec 2011 15:28:14 +0000
Subject: [MEI-L] TEI-L Digest - 15 Dec 2011 to 16 Dec 2011 (#2011-278)
In-Reply-To: <TEI-L%201112170001153012.6CBD@LISTSERV.BROWN.EDU>
References: <TEI-L%201112170001153012.6CBD@LISTSERV.BROWN.EDU>
Message-ID: <BBCC497C40D85642B90E9F94FC30343D0112EB66@KENNEDY.eservices.virginia.edu>

Hello, everyone,

You'll be very glad to hear that, quoting from Laurent Romary's message of 16 Dec 2011 to TEI-L,

? A new <notatedMusic> element was added to support representation of musical notation within texts in a way compatible with the *existing Music XML standard*.  (emphasis mine)

There's no mention of MEI in the message.

--
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 raffaeleviglianti at gmail.com  Mon Dec 19 17:38:44 2011
From: raffaeleviglianti at gmail.com (Raffaele Viglianti)
Date: Mon, 19 Dec 2011 11:38:44 -0500
Subject: [MEI-L] TEI-L Digest - 15 Dec 2011 to 16 Dec 2011 (#2011-278)
In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D0112EB66@KENNEDY.eservices.virginia.edu>
References: <TEI-L%201112170001153012.6CBD@LISTSERV.BROWN.EDU>
	<BBCC497C40D85642B90E9F94FC30343D0112EB66@KENNEDY.eservices.virginia.edu>
Message-ID: <CAMyHAnM3tTrDJ2362k6NO2HE6c+pzX7iY9ZUtOtYELRkoKT3gQ@mail.gmail.com>

Hi Perry,

Thanks for spotting that. I've sent a rectifying email.

Happy holidays!
Raffaele

On Mon, Dec 19, 2011 at 10:28 AM, Roland, Perry (pdr4h) <
pdr4h at eservices.virginia.edu> wrote:

> Hello, everyone,
>
> You'll be very glad to hear that, quoting from Laurent Romary's message of
> 16 Dec 2011 to TEI-L,
>
> ? A new <notatedMusic> element was added to support representation of
> musical notation within texts in a way compatible with the *existing Music
> XML standard*.  (emphasis mine)
>
> There's no mention of MEI in the message.
>
> --
> p.
>
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> _______________________________________________
> 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/20111219/9553683c/attachment.html>

From alastair at porter.net.nz  Sat Dec 31 22:05:50 2011
From: alastair at porter.net.nz (Alastair Porter)
Date: Sat, 31 Dec 2011 16:05:50 -0500
Subject: [MEI-L] <graphic> and external references
Message-ID: <CAMB=jE-JSO+MEeL+3ySNXYM5PfjcACCw6SS94jC1JdzjsMhhRA@mail.gmail.com>

Hi,

I've been working on revalidating some old files against the latest version
of the MEI schema (I've generated an RNG file from branches/MEI_dev)
and have a question about the attributes to the <graphic> element.
The att.pointing attribute list contains definitions for attributes
pointing to external sources. @actuate, @role, @show, and @title are
defined in the xlink schema, however @target and @targettype are not. Old
versions of the schema (e.g the tag library at
http://music-encoding.org/documentation/tagLibrary/graphic) appear to use
xlink:href for external sources instead.
Is there a reason that these target attributes are not the xlink ones (e.g.
xlink:href)?

Thanks,
Alastair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20111231/6db10b70/attachment.html>