From siegert at udk-berlin.de Fri Jan 4 21:49:05 2013 From: siegert at udk-berlin.de (Christine Siegert) Date: Fri, 4 Jan 2013 21:49:05 +0100 Subject: [MEI-L] MEI project Berlin In-Reply-To: References: , <0A35C69B-FBBC-4338-A08F-75FEC017D936@edirom.de><0B6F63F59F405E4C902DFE2C2329D0D168609622@EXCHANGE-01.kb.dk> Message-ID: Dear colleagues, for our MEI Sarti project at the University of the Arts Berlin, we are looking for two post doc researchers (see below). If you have any questions, please don't hesitate to contact me. With best wishes, Christine Siegert Fakult?t Musik | Institut f?r Musikwissenschaft | Kennziffer 3/1372/13 2 Wissenschaftliche/r Mitarbeiter/in - Entgeltgruppe 13 TV-L Berliner Hochschulen, befristet auf 3 Jahre An der Universit?t der K?nste Berlin sind in der Fakult?t Musik ? Institut f?r Musikwissenschaft ? folgende Stellen zu besetzen: 2 Wissenschaftliche/r Mitarbeiter/in - Entgeltgruppe 13 TV-L Berliner Hochschulen, befristet auf 3 Jahre Besetzbar: 1. Februar 2013 Kennziffer: 3/1372/13 Aufgabengebiet: Erstellen einer MEI-basierten Edirom-Edition von Giuseppe Sartis Giulio Sabino bzw. Fra i due litiganti il terzo gode im Rahmen des von der Einstein Stiftung Berlin finanzierten Forschungsprojekts A Cosmopolitan Composer in Pre-Revolutionary Europe - Giuseppe Sarti, das in Kooperation mit der Hebrew University Jerusalem durchgef?hrt wird. Anforderungen: Abgeschlossenes Studium in Musikwissenschaft (Master/Magister) oder Staatsexamen im Fach Musik und vorzugsweise Promotion. Sehr gute Sprachkenntnisse in mind. einer der folgenden Sprachen: Italienisch, Englisch, Franz?sisch, D?nisch. Daneben ist das Vorhandensein von einer oder beiden der folgenden Qualifikationen w?nschenswert: Editionst?tigkeiten, Kenntnisse in der digitalen Aufbereitung historischer Quellen. Die Universit?t der K?nste Berlin ist besonders um die Einstellung und F?rderung von Frauen bem?ht; sie verfolgt die Strategie des Gender Mainstreaming. Anerkannte Schwerbehinderte werden bei gleicher Eignung bevorzugt ber?cksichtigt. Bitte weisen Sie auf Ihre Schwerbehinderung ggf. bereits in der Bewerbung hin. Bewerbungen von Menschen mit Migrationshintergrund, die die Einstellungsvoraussetzungen erf?llen, sind ausdr?cklich erw?nscht. Bewerbungen sind mit aussagef?higen Bewerbungsunterlagen unter Angabe der Kennziffer bis zum 18. Januar 2013 an die Universit?t der K?nste Berlin - ZSD 1 -, Postfach 12 05 44, 10595 Berlin, zu richten. Die Bewerbungsunterlagen k?nnen aus Kostengr?nden nur mit beigef?gtem und ausreichend frankiertem R?ckumschlag zur?ckgesandt werden. From zupftom at googlemail.com Mon Jan 7 16:54:55 2013 From: zupftom at googlemail.com (TW) Date: Mon, 7 Jan 2013 16:54:55 +0100 Subject: [MEI-L] Header data for Corpus monodicum Message-ID: Dear MEI community, finally, after a longer preparation period, at the end of last year Corpus monodicum and notengrafik berlin took the last hurdles to officially partner in developing mono:di, an MEI based editor software for creating transcriptions of neumatic notation. Corpus monodicum is a scholarly edition of the historically significant, sacred and secular monophonic repertories of the European Middle Ages with Latin texts, headed by Prof. Dr. Andreas Haug and produced by the University of W?rzburg and the Akademie der Wissenschaften und der Literatur Mainz. notengrafik berlin is a music typesetting firm with longstanding experience working with major publishers and a special focus on unusual notation. Corpus monodicum?s publications will include both a series of printed volumes as well as a digital edition. mono:di's primary motivation is to serve both publication channels from a common data basis, giving editors an efficient interface that is tailored to the kind of music they are dealing with. The encoding we chose for the body of the music was based on the work done by the T?Bingen project and the SIMSSA sub-project Encoding the Liber usualis. Prof. Dr. Stefan Morent already took the initiative and set the course for starting a dialogue about unifying the approaches for encoding neumatic notation using MEI. I'd like to ask you for some advice concerning the encoding of header data. I am not familiar enough with this area of MEI to decide how to classify the different aspects of header data that we need to store for a chant. Each chant will be stored in a single file and needs its own set of header data. * section (edition is divided into sections; section the chant belongs to is recorded as roman numeral) * volume (number of the printed volume the chant belongs to) * genre * source: - location (country, city, institution) - shelfmark * incipit (textual) * number in the edition (for internal use) * number in textual edition (there is a text-only edition that has differing numbers) * catalog number (number that was established by other publications) * feast (of the liturgical year, e.g. Christmas, i.e. "nativitate", short "nat") * service (Office hour or Mass, roman numeral for Mass) * base chant genre * element number While I can identify the right spot for a few items, like for the textual incipit, I'm not sure how to encode the more exotic ones like "feast" and "service". I'm also not clear about how the FRBR approach has an impact on some of the items. My questions are: - Is it advisable to stick to "old" MEI when encoding information about the source, or shall I go forward and adopt the FRBR way? - How can we sensibly record all those different numbers and genre titles? - Would it be useful--or is there any interest--to standardize how to record header data specific to liturgical music, considering the tremendous amount of sacred music in existence? We are grateful for any help Thomas Weber From pdr4h at eservices.virginia.edu Mon Jan 7 23:14:40 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 7 Jan 2013 22:14:40 +0000 Subject: [MEI-L] Header data for Corpus monodicum In-Reply-To: References: Message-ID: Hi, Thomas, > - Is it advisable to stick to "old" MEI when encoding information > about the source, or shall I go forward and adopt the FRBR way? There's no single, "correct" answer to this question. It depends on the level of detail you want to capture and the complexity of the relationships you expect to find in the source materials. The so-called "old" MEI will continue to work for bibliographic and physical description of source material. The use of will still provide the capability of capturing basic bibliographic data, such as creator, title, physical description, language usage, inscriptions, watermarks, and so on. What you don't get with the former method is the ability to -- - clearly express the fact that a manuscript has been broken into multiple pieces that are now housed in widely-separated locations (because using only you can't formally separate the pieces of locational information from each other) and - group multiple sources (usually by score format or performance medium) into something FRBR calls an "expression". I think you might want to start by supporting only (and , of course). Adding , , and the other elements that facilitate the markup of FRBR relationships, can come later. > - How can we sensibly record all those different numbers and genre titles? Again, it depends. Here your choice depends on what you decide those numbers are describing. Your own "number in the edition" identifier would be best encoded using either mei/@xml:id or mei/altId depending on whether the identifier conforms to the rules of XML names. But, the "number in textual edition (there is a text-only edition that has differing numbers)" and the "catalog number (number that was established by other publications)" belong in work/identifier or source/identifier or item/identifier depending on what the numbers refer to. If a catalog is work-based that's one thing, but if it's assigning identifiers to individual sources (more like an auction catalog), it's another. For classification (by genre or other means), MEI offers the element. Where the element occurs in the markup hierarchy depends on what's being classified. The section and volume numbers may exemplify some kind of classification (I presume all the chants in a particular section or volume have something in common.) and therefore belong in described below. Or they may be thought of as (non-unique?) identifiers and go into one or more additional mei/altID elements. (To uniquely identify a chant based on its section and volume number, you could create a single, concatenated identifier.) Where you ultimately choose to put them depends on the material and the traditions of the scholars of the material. > - Would it be useful--or is there any interest--to standardize how to > record header data specific to liturgical music, considering the > tremendous amount of sacred music in existence? It's tempting to provide special markup for the description of liturgical music, but where does that line of thought end? If liturgical music, then why not chamber music or any number of other genres, sub-genres, sub-sub-genres, ad infinitum? I think it's better to provide a single, general mechanism that applies across a wide range of situations, which can be made specific through the use of specialized controlled vocabularies. For example, liturgical music and chamber music can use the same general markup -- The [Liturgical | Metal] Ontology Term 1 Term 2 where the element names the controlled vocabulary (and its @authURI attribute points to its online version) and contains the classifying term, such as "Feast of X" in the case of liturgical music or "Megadeath Shiny Black Minutiae Metal" for pop music. I'm not sure what you mean by "element number" so I can't address that item at the moment. One last piece of advice, if I may -- Please remember that there are professionals who are trained in the dirty details of these kinds of systems and decisions. Kindly support your local librarian. :-) 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 zupftom at googlemail.com Tue Jan 8 16:54:18 2013 From: zupftom at googlemail.com (TW) Date: Tue, 8 Jan 2013 16:54:18 +0100 Subject: [MEI-L] Header data for Corpus monodicum In-Reply-To: References: Message-ID: Hi Perry, thanks for your advice. It's really valuable for me to get started. 2013/1/7 Roland, Perry (pdr4h) : > >> - Is it advisable to stick to "old" MEI when encoding information >> about the source, or shall I go forward and adopt the FRBR way? > > There's no single, "correct" answer to this question. It depends on the level of detail you want to capture and the complexity of the relationships you expect to find in the source materials. > > The so-called "old" MEI will continue to work for bibliographic and physical description of source material. The use of will still provide the capability of capturing basic bibliographic data, such as creator, title, physical description, language usage, inscriptions, watermarks, and so on. What you don't get with the former method is the ability to -- > > - clearly express the fact that a manuscript has been broken into multiple pieces that are now housed in widely-separated locations (because using only you can't formally separate the pieces of locational information from each other) and > > - group multiple sources (usually by score format or performance medium) into something FRBR calls an "expression". > > I think you might want to start by supporting only (and , of course). Adding , , and the other elements that facilitate the markup of FRBR relationships, can come later. > That sounds like a good plan to follow. As we'll usually describe one source only, referring to the original manuscript and no other expressions, this doesn't force us to use FRBR functionality. Also, the individual files will only contain rather short chants, and I don't expect we'll have to deal with chants where the first few words are found in Paris and the rest in Madrid. >> - How can we sensibly record all those different numbers and genre titles? > > [... lot's of useful information about classification] >> - Would it be useful--or is there any interest--to standardize how to >> record header data specific to liturgical music, considering the >> tremendous amount of sacred music in existence? > > It's tempting to provide special markup for the description of liturgical music, but where does that line of thought end? If liturgical music, then why not chamber music or any number of other genres, sub-genres, sub-sub-genres, ad infinitum? I think it's better to provide a single, general mechanism that applies across a wide range of situations, which can be made specific through the use of specialized controlled vocabularies. Yes, I was more thinking of such a controlled vocabulary rather than specialized markup (maybe things like this are already in existence; I guess that's a question for librarians...). > I'm not sure what you mean by "element number" so I can't address that item at the moment. > This is just kind of a running number that, among other things, determines the order of appearance in the printed edition. > One last piece of advice, if I may -- Please remember that there are professionals who are trained in the dirty details of these kinds of systems and decisions. Kindly support your local librarian. :-) > We should indeed do that. I blame the fact that I'm too far away from where the librarians local to the project reside that I didn't consider this earlier. > Hope this helps, > Yes, it does. Herzlichen Dank! Thomas From atge at kb.dk Tue Jan 8 17:29:36 2013 From: atge at kb.dk (Axel Teich Geertinger) Date: Tue, 8 Jan 2013 16:29:36 +0000 Subject: [MEI-L] Header data for Corpus monodicum In-Reply-To: References: Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D173D39879@EXCHANGE-01.kb.dk> Dear Thomas, I could add that you can use in to provide the name of your digital edition series and within it for any number or other identifier in that series - for instance, the section number. All the best, Axel -----Oprindelig meddelelse----- Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af TW Sendt: 8. januar 2013 16:54 Til: Music Encoding Initiative Emne: Re: [MEI-L] Header data for Corpus monodicum Hi Perry, thanks for your advice. It's really valuable for me to get started. 2013/1/7 Roland, Perry (pdr4h) : > >> - Is it advisable to stick to "old" MEI when encoding information >> about the source, or shall I go forward and adopt the FRBR way? > > There's no single, "correct" answer to this question. It depends on the level of detail you want to capture and the complexity of the relationships you expect to find in the source materials. > > The so-called "old" MEI will continue to work for bibliographic and > physical description of source material. The use of will > still provide the capability of capturing basic bibliographic data, > such as creator, title, physical description, language usage, > inscriptions, watermarks, and so on. What you don't get with the > former method is the ability to -- > > - clearly express the fact that a manuscript has been broken into > multiple pieces that are now housed in widely-separated locations > (because using only you can't formally separate the pieces of > locational information from each other) and > > - group multiple sources (usually by score format or performance medium) into something FRBR calls an "expression". > > I think you might want to start by supporting only (and , of course). Adding , , and the other elements that facilitate the markup of FRBR relationships, can come later. > That sounds like a good plan to follow. As we'll usually describe one source only, referring to the original manuscript and no other expressions, this doesn't force us to use FRBR functionality. Also, the individual files will only contain rather short chants, and I don't expect we'll have to deal with chants where the first few words are found in Paris and the rest in Madrid. >> - How can we sensibly record all those different numbers and genre titles? > > [... lot's of useful information about classification] >> - Would it be useful--or is there any interest--to standardize how to >> record header data specific to liturgical music, considering the >> tremendous amount of sacred music in existence? > > It's tempting to provide special markup for the description of liturgical music, but where does that line of thought end? If liturgical music, then why not chamber music or any number of other genres, sub-genres, sub-sub-genres, ad infinitum? I think it's better to provide a single, general mechanism that applies across a wide range of situations, which can be made specific through the use of specialized controlled vocabularies. Yes, I was more thinking of such a controlled vocabulary rather than specialized markup (maybe things like this are already in existence; I guess that's a question for librarians...). > I'm not sure what you mean by "element number" so I can't address that item at the moment. > This is just kind of a running number that, among other things, determines the order of appearance in the printed edition. > One last piece of advice, if I may -- Please remember that there are > professionals who are trained in the dirty details of these kinds of > systems and decisions. Kindly support your local librarian. :-) > We should indeed do that. I blame the fact that I'm too far away from where the librarians local to the project reside that I didn't consider this earlier. > Hope this helps, > Yes, it does. Herzlichen Dank! Thomas _______________________________________________ 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 Wed Jan 9 19:54:38 2013 From: kristina.richts at gmx.de (Kristina Richts) Date: Wed, 09 Jan 2013 19:54:38 +0100 Subject: [MEI-L] MEI 1st tutorials Message-ID: <50EDBCEE.9020803@gmx.de> Dear colleagues, I am happy to inform you about some new training materials being available on the MEI website from today. They are grouped under the heading "MEI 1st" and can be found at http://music-encoding.org/support/MEI1st. MEI 1st is a set of tutorials, that has been developed as part of the DFG/NEH project. It will help you to learn about different aspects of the encoding scheme of the Music Encoding Initiative (MEI), and acts as a guideline from the first steps into MEI through more advanced aspects of music encoding. The tutorials cover the following aspects: ? General MEI Document Structure ? Creating a new MEI Document ? Encoding Music Notation ? Exploring the Header Some tutorials, such as "Encoding Music Notation" and "Exploring the Header", are divided into different chapters and ordered according to increasing complexity. Each tutorial begins with an overview of the corresponding features of MEI and concludes with a test of the principles addressed in that section. We hope you enjoy learning more about MEI with MEI 1st ? your feedback is more than welcome. I would also like to thank Maja, Rya Martin, Irmlind Capelle, Kristin Herold, Benjamin, Joachim, Johannes, Perry and others for their substantial support of MEI 1st. Best wishes, Kristina From zupftom at googlemail.com Fri Jan 11 07:13:32 2013 From: zupftom at googlemail.com (TW) Date: Fri, 11 Jan 2013 07:13:32 +0100 Subject: [MEI-L] Header data for Corpus monodicum In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D173D39879@EXCHANGE-01.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D173D39879@EXCHANGE-01.kb.dk> Message-ID: 2013/1/8 Axel Teich Geertinger : > I could add that you can use in to provide the name of your digital edition series and within it for any number or other identifier in that series - for instance, the section number. > Yes, that's a good idea. I'll try and figure out how those elements best fit our various numberings. Thank you for your kind help Thomas From bohl at edirom.de Wed Jan 16 09:33:11 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Wed, 16 Jan 2013 09:33:11 +0100 Subject: [MEI-L] MEI 1st tutorials In-Reply-To: <50EDBCEE.9020803@gmx.de> References: <50EDBCEE.9020803@gmx.de> Message-ID: <50F665C7.7000908@edirom.de> Hi Kristina, almost forgot... This is very good news and will help MEI to spread and get accepted in musicological spheres. Congratualtions!! Benjamin *********************************************************** Benjamin W. Bohl BMBF-Projekt "Freisch?tz Digital" Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D ? 32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 *********************************************************** Am 09.01.2013 19:54, schrieb Kristina Richts: > Dear colleagues, > > I am happy to inform you about some new training materials being > available on the MEI website from today. > They are grouped under the heading "MEI 1st" and can be found at > http://music-encoding.org/support/MEI1st. > > MEI 1st is a set of tutorials, that has been developed as part of the > DFG/NEH project. It will help you to learn about different aspects of > the encoding scheme of the Music Encoding Initiative (MEI), and acts > as a guideline from the first steps into MEI through more advanced > aspects of music encoding. The tutorials cover the following aspects: > ? General MEI Document Structure > ? Creating a new MEI Document > ? Encoding Music Notation > ? Exploring the Header > > Some tutorials, such as "Encoding Music Notation" and "Exploring the > Header", are divided into different chapters and ordered according to > increasing complexity. Each tutorial begins with an overview of the > corresponding features of MEI and concludes with a test of the > principles addressed in that section. > We hope you enjoy learning more about MEI with MEI 1st ? your feedback > is more than welcome. > > I would also like to thank Maja, Rya Martin, Irmlind Capelle, Kristin > Herold, Benjamin, Joachim, Johannes, Perry and others for their > substantial support of MEI 1st. > > Best wishes, > Kristina > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From siegert at udk-berlin.de Wed Jan 16 18:35:22 2013 From: siegert at udk-berlin.de (Christine Siegert) Date: Wed, 16 Jan 2013 18:35:22 +0100 Subject: [MEI-L] MEI 1st tutorials References: <50EDBCEE.9020803@gmx.de> <50F665C7.7000908@edirom.de> Message-ID: Hi Kristina, I completely agree. And it's also very useful for students. Excellent work! Christine Prof. Dr. Christine Siegert Universit?t der K?nste Berlin Musikwissenschaft, Fakult?t Musik Fasanenstr. 1B, D-10623 Berlin Postanschrift: Postfach 12 05 44, D-10595 Berlin Tel.: +49 (0)30-3185-2318 ----- Original Message ----- From: "Benjamin Wolff Bohl" To: "Music Encoding Initiative" Sent: Wednesday, January 16, 2013 9:33 AM Subject: Re: [MEI-L] MEI 1st tutorials > Hi Kristina, > almost forgot... > This is very good news and will help MEI to spread and get accepted in > musicological spheres. > > Congratualtions!! > > Benjamin > > *********************************************************** > Benjamin W. Bohl > BMBF-Projekt "Freisch?tz Digital" > Musikwissenschaftliches Seminar Detmold/Paderborn > Gartenstra?e 20 > D ? 32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > *********************************************************** > > Am 09.01.2013 19:54, schrieb Kristina Richts: >> Dear colleagues, >> >> I am happy to inform you about some new training materials being >> available on the MEI website from today. >> They are grouped under the heading "MEI 1st" and can be found at >> http://music-encoding.org/support/MEI1st. >> >> MEI 1st is a set of tutorials, that has been developed as part of the >> DFG/NEH project. It will help you to learn about different aspects of the >> encoding scheme of the Music Encoding Initiative (MEI), and acts as a >> guideline from the first steps into MEI through more advanced aspects of >> music encoding. The tutorials cover the following aspects: >> ? General MEI Document Structure >> ? Creating a new MEI Document >> ? Encoding Music Notation >> ? Exploring the Header >> >> Some tutorials, such as "Encoding Music Notation" and "Exploring the >> Header", are divided into different chapters and ordered according to >> increasing complexity. Each tutorial begins with an overview of the >> corresponding features of MEI and concludes with a test of the principles >> addressed in that section. >> We hope you enjoy learning more about MEI with MEI 1st ? your feedback is >> more than welcome. >> >> I would also like to thank Maja, Rya Martin, Irmlind Capelle, Kristin >> Herold, Benjamin, Joachim, Johannes, Perry and others for their >> substantial support of MEI 1st. >> >> Best wishes, >> Kristina >> >> _______________________________________________ >> 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 Jan 16 19:51:39 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 16 Jan 2013 18:51:39 +0000 Subject: [MEI-L] MEI 1st tutorials In-Reply-To: References: <50EDBCEE.9020803@gmx.de> <50F665C7.7000908@edirom.de>, Message-ID: Hi Kristina, Let me add my voice to those already praising your work on MEI1st. I'm especially pleased with your efforts to explicate the header. :-) Thanks for your diligent work, -- 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 Christine Siegert [siegert at udk-berlin.de] Sent: Wednesday, January 16, 2013 12:35 PM To: Music Encoding Initiative Subject: Re: [MEI-L] MEI 1st tutorials Hi Kristina, I completely agree. And it's also very useful for students. Excellent work! Christine Prof. Dr. Christine Siegert Universit?t der K?nste Berlin Musikwissenschaft, Fakult?t Musik Fasanenstr. 1B, D-10623 Berlin Postanschrift: Postfach 12 05 44, D-10595 Berlin Tel.: +49 (0)30-3185-2318 ----- Original Message ----- From: "Benjamin Wolff Bohl" To: "Music Encoding Initiative" Sent: Wednesday, January 16, 2013 9:33 AM Subject: Re: [MEI-L] MEI 1st tutorials > Hi Kristina, > almost forgot... > This is very good news and will help MEI to spread and get accepted in > musicological spheres. > > Congratualtions!! > > Benjamin > > *********************************************************** > Benjamin W. Bohl > BMBF-Projekt "Freisch?tz Digital" > Musikwissenschaftliches Seminar Detmold/Paderborn > Gartenstra?e 20 > D ? 32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > *********************************************************** > > Am 09.01.2013 19:54, schrieb Kristina Richts: >> Dear colleagues, >> >> I am happy to inform you about some new training materials being >> available on the MEI website from today. >> They are grouped under the heading "MEI 1st" and can be found at >> http://music-encoding.org/support/MEI1st. >> >> MEI 1st is a set of tutorials, that has been developed as part of the >> DFG/NEH project. It will help you to learn about different aspects of the >> encoding scheme of the Music Encoding Initiative (MEI), and acts as a >> guideline from the first steps into MEI through more advanced aspects of >> music encoding. The tutorials cover the following aspects: >> ? General MEI Document Structure >> ? Creating a new MEI Document >> ? Encoding Music Notation >> ? Exploring the Header >> >> Some tutorials, such as "Encoding Music Notation" and "Exploring the >> Header", are divided into different chapters and ordered according to >> increasing complexity. Each tutorial begins with an overview of the >> corresponding features of MEI and concludes with a test of the principles >> addressed in that section. >> We hope you enjoy learning more about MEI with MEI 1st ? your feedback is >> more than welcome. >> >> I would also like to thank Maja, Rya Martin, Irmlind Capelle, Kristin >> Herold, Benjamin, Joachim, Johannes, Perry and others for their >> substantial support of MEI 1st. >> >> Best wishes, >> Kristina >> >> _______________________________________________ >> 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 slu at kb.dk Wed Jan 30 13:38:15 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Wed, 30 Jan 2013 12:38:15 +0000 Subject: [MEI-L] How to encode the content of a beam as being "grace notes" Message-ID: <0C090608704AF04E898055296C932B1273DA8BCE@EXCHANGE-01.kb.dk> Dear all, I want to encode a measure in a waltz somewhat like this. I.e., I want all the content first beam appear as grace notes to the first note in the second beam. The problem is that this doesn't validate with mei 2010-05 (which I need to use, since I need mup support). And I just cannot find out how to do this in a way understood by mei2mup Please explain, someone. Yours Sigfrid From pdr4h at eservices.virginia.edu Wed Jan 30 15:16:32 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 30 Jan 2013 14:16:32 +0000 Subject: [MEI-L] How to encode the content of a beam as being "grace notes" In-Reply-To: <0C090608704AF04E898055296C932B1273DA8BCE@EXCHANGE-01.kb.dk> References: <0C090608704AF04E898055296C932B1273DA8BCE@EXCHANGE-01.kb.dk> Message-ID: Hi Sigfrid, First, the validation issue -- Because the notes are "graces", not the beam, each note must carry the grace attribute, i.e., Second, the mei2mup question -- As I recall, the mei2mup stylesheet doesn't beam grace notes. I think you'll have to further process the resulting .mup file to get this behavior. It's important to keep in mind that mei2mup wasn't intended to function in a "production" environment, it was a proof-of-concept prototype. I'd suggest that you - adopt MEI 2013 (I can send you a schema, just let me know) and - adapt/re-write mei2mup so that it matches the later schema If you don't have the resources for the 2nd of these suggestions, you might consider partnering with someone who does. Alternatively, you could wait until someone else takes up this task -- which I expect will happen sooner or later as both MEI and Mup become more widely known. (I hear that the creators of Mup, Arkkra Enterprises, are attempting to get Mup distributed with various *nix operating systems.) 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 Sigfrid Lundberg [slu at kb.dk] Sent: Wednesday, January 30, 2013 7:38 AM To: Music Encoding Initiative Subject: [MEI-L] How to encode the content of a beam as being "grace notes" Dear all, I want to encode a measure in a waltz somewhat like this. I.e., I want all the content first beam appear as grace notes to the first note in the second beam. The problem is that this doesn't validate with mei 2010-05 (which I need to use, since I need mup support). And I just cannot find out how to do this in a way understood by mei2mup Please explain, someone. Yours Sigfrid _______________________________________________ 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 Feb 4 18:54:57 2013 From: kristina.richts at gmx.de (Kristina Richts) Date: Mon, 04 Feb 2013 18:54:57 +0100 Subject: [MEI-L] Encoding of personal names Message-ID: <510FF5F1.4080806@gmx.de> Dear all, during the work on the MEI sample collection, questions appeared on how to encode the creators of each electronic file correctly. In MEI2012 the normal path (or better said: the way, we first chose to encode it) was to encode several -elements within the statement of responsibilty. A differentiation between several involved persons only became apparent through additional @role-attributes, i.e. Anton Webern John Doe In a second step we decided not to encode ourselves as "creators" of the file (although we are), but as "encoders" and to assign the composer of the encoded work as creator, i.e. Anton Webern John Doe The decision is based on the fact, that we encode the _intellectual creation_ of a composer's work. We tried to keep up the distinction between the composer and the encoder. MEI2013 will offer some new elements to specify the role of persons, organizations etc. a bit more: , , , and . In this regard it is now the question how to encode this best: Anton Webern John Doe or Anton Webern John Doe ? We first thought, it would be a good idea, to add a element to the list. But that alone would not be sufficient, as the creative aspect regarding musical works is difficult to manage. In this case, we would rather have to extend the list by adding some more elements like , , etc. But this can soon become very unwieldy. I have to admit that I don't prefer to encode detailed specifications only within child elements. However, if we choose to maintain the 'more detailed elements', I would at least like to see some mandatory child elements, such as , , etc., in there. When thinking about all this, I came to the conclusion, that it might be enough to allow a and a element (with some mandatory child elements). I am not even sure, if we should offer a separate element or if an editor should be considered as a contributor as well. What is to be said against a specification of the role on the or element? Wouldn't this make things easier to handle for the encoder, who might not know as much about the encoding of persNames with MEI? Any comments on this? Best, Kristina -------------- next part -------------- An HTML attachment was scrubbed... URL: From esfield at stanford.edu Mon Feb 4 22:39:18 2013 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Mon, 4 Feb 2013 13:39:18 -0800 (PST) Subject: [MEI-L] Encoding of personal names In-Reply-To: <510FF5F1.4080806@gmx.de> References: <510FF5F1.4080806@gmx.de> Message-ID: Kristina poses interesting questions. Instinctively I would go for "composer", "encoder," etc and err on the side of being verbose and explicit. With electronic data, being able to track who encoded what (with version number and date) can be very valuable. I find labels such as "creator" and "corporate name" very unwieldy, particularly when working in a second language (in my case usually Italian). Italian bibliographical databases a full of these kinds of terms, but there is something subtly cultural about the misunderstandings they can create. The various instantiations of a single work can have many creators-a composer, an arranger, and editor, a translator of the text, and in the case of recording a conductor, performer, performing group, etc. Because they can all pertain to a single work, a general label deprives the user of knowing what the role of each one was. A much messier area is dating. A single work can have an almost endless number of "year"s-of composition, publication, first performance, revision <1..n>, arrangement, recording, text translation, etc. There too being more specific saves time for those searching. Best regards, Eleanor Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kristina Richts Sent: Monday, February 04, 2013 9:55 AM To: mei-l at lists.uni-paderborn.de Subject: [MEI-L] Encoding of personal names Dear all, during the work on the MEI sample collection, questions appeared on how to encode the creators of each electronic file correctly. In MEI2012 the normal path (or better said: the way, we first chose to encode it) was to encode several -elements within the statement of responsibilty. A differentiation between several involved persons only became apparent through additional @role-attributes, i.e. Anton Webern John Doe In a second step we decided not to encode ourselves as "creators" of the file (although we are), but as "encoders" and to assign the composer of the encoded work as creator, i.e. Anton Webern John Doe The decision is based on the fact, that we encode the intellectual creation of a composer's work. We tried to keep up the distinction between the composer and the encoder. MEI2013 will offer some new elements to specify the role of persons, organizations etc. a bit more: , , , and . In this regard it is now the question how to encode this best: Anton Webern John Doe or Anton Webern John Doe ? We first thought, it would be a good idea, to add a element to the list. But that alone would not be sufficient, as the creative aspect regarding musical works is difficult to manage. In this case, we would rather have to extend the list by adding some more elements like , , etc. But this can soon become very unwieldy. I have to admit that I don't prefer to encode detailed specifications only within child elements. However, if we choose to maintain the 'more detailed elements', I would at least like to see some mandatory child elements, such as , , etc., in there. When thinking about all this, I came to the conclusion, that it might be enough to allow a and a element (with some mandatory child elements). I am not even sure, if we should offer a separate element or if an editor should be considered as a contributor as well. What is to be said against a specification of the role on the or element? Wouldn't this make things easier to handle for the encoder, who might not know as much about the encoding of persNames with MEI? Any comments on this? Best, Kristina -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Tue Feb 5 18:23:27 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 5 Feb 2013 17:23:27 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: References: <510FF5F1.4080806@gmx.de>, Message-ID: Hello everyone, I can see now that my plan to provide and as replacements for TEI's element isn't defensible because it's causing more confusion than it alleviates. So, I suggest that we 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, 2. but drop meeting and principal, and 3. add arranger, composer, librettist, and lyricist. As in TEI, any roles not specifically provided for by this list, such as conductor, encoder, and so on, belong in , for example -- My Music, Op. 1 Composer de Jure Johann Collaborator Bach Arranger Extraordinaire Encoders [encoder 1] [encoder 2] In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. MARC relator code list (http://www.loc.gov/marc/relators/relaterm.html) provides more than 200 codes/terms for roles, several of which apply to music and musical performances. There's no way we can accommodate them all. So, it makes sense to continue the TEI method of recording those responsible for the *intellectual content* of the work in special elements and relegating other roles to . (I think this actually stems from ISBD and AACR2, not TEI.) The addition of these elements *does not* mandate their use; that is, can be used for all responsibilities. The following markup is a valid alternative to the example above: My Music, Op. 1 Composer Composer de Jure Lyricist Johann Collaborator Bach Arranger Arranger Man Encoders [encoder 1] [encoder 2] This form can be easier to produce mechanistically from other encoding schemes and is conformant with forms of cataloging that don't require a "main entry" approach, meaning that it would be easier to transform into one of those systems, such as MODS. Also, it's necessary to keep in mind that since is a kind of bibliographic citation, elements used here are also available in (and must also fit within the purpose of) other elements, such as and . Best wishes, -- 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 Eleanor Selfridge-Field [esfield at stanford.edu] Sent: Monday, February 04, 2013 4:39 PM To: 'Music Encoding Initiative' Subject: Re: [MEI-L] Encoding of personal names Kristina poses interesting questions. Instinctively I would go for ?composer?, ?encoder,? etc and err on the side of being verbose and explicit. With electronic data, being able to track who encoded what (with version number and date) can be very valuable. I find labels such as ?creator? and ?corporate name? very unwieldy, particularly when working in a second language (in my case usually Italian). Italian bibliographical databases a full of these kinds of terms, but there is something subtly cultural about the misunderstandings they can create. The various instantiations of a single work can have many creators?a composer, an arranger, and editor, a translator of the text, and in the case of recording a conductor, performer, performing group, etc. Because they can all pertain to a single work, a general label deprives the user of knowing what the role of each one was. A much messier area is dating. A single work can have an almost endless number of ?year?s?of composition, publication, first performance, revision <1..n>, arrangement, recording, text translation, etc. There too being more specific saves time for those searching. Best regards, Eleanor Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kristina Richts Sent: Monday, February 04, 2013 9:55 AM To: mei-l at lists.uni-paderborn.de Subject: [MEI-L] Encoding of personal names Dear all, during the work on the MEI sample collection, questions appeared on how to encode the creators of each electronic file correctly. In MEI2012 the normal path (or better said: the way, we first chose to encode it) was to encode several -elements within the statement of responsibilty. A differentiation between several involved persons only became apparent through additional @role-attributes, i.e. Anton Webern John Doe In a second step we decided not to encode ourselves as "creators" of the file (although we are), but as "encoders" and to assign the composer of the encoded work as creator, i.e. Anton Webern John Doe The decision is based on the fact, that we encode the intellectual creation of a composer's work. We tried to keep up the distinction between the composer and the encoder. MEI2013 will offer some new elements to specify the role of persons, organizations etc. a bit more: , , , and . In this regard it is now the question how to encode this best: Anton Webern John Doe or Anton Webern John Doe ? We first thought, it would be a good idea, to add a element to the list. But that alone would not be sufficient, as the creative aspect regarding musical works is difficult to manage. In this case, we would rather have to extend the list by adding some more elements like , , etc. But this can soon become very unwieldy. I have to admit that I don't prefer to encode detailed specifications only within child elements. However, if we choose to maintain the 'more detailed elements', I would at least like to see some mandatory child elements, such as , , etc., in there. When thinking about all this, I came to the conclusion, that it might be enough to allow a and a element (with some mandatory child elements). I am not even sure, if we should offer a separate element or if an editor should be considered as a contributor as well. What is to be said against a specification of the role on the or element? Wouldn't this make things easier to handle for the encoder, who might not know as much about the encoding of persNames with MEI? Any comments on this? Best, Kristina -------------- next part -------------- An HTML attachment was scrubbed... URL: From bohl at edirom.de Thu Feb 7 09:36:39 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 07 Feb 2013 09:36:39 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: References: <510FF5F1.4080806@gmx.de>, Message-ID: <51136797.7020407@edirom.de> Hi Kristina and List:eners! In the past few months I've been dealing with the idea of capuring the metadata of published records in MEI and to start out I decided for the harest part ;-) A recording was made publicized and later re-issued on a differnet sound carrier, additional work done by technicians and additional text parts completed this re-issue. As you might imagine, I came across quite a lot of responsibility statements and I find it very convnient to stitch to the MARC code list for Relators. Thus I can understand Perry's idea and might even support to > 1. return to the list provided by TEI -- author, editor, funder, > meeting, principal (as in principal investigator), sponsor, and respStmt, > > 2. but drop meeting and principal, and > > 3. add arranger, composer, librettist, and lyricist. > > In this scheme, , , , and > for musical compositions are equivalent to for > textual material. The element *should not* be used for > lyricists or librettists. Though making a decision here always weans to draw a line. But where to draw the line? Arranger could still be dropped as his activity might be secondary or even tertiary use of the work. Then on the other hand when moving forward in the publication process more and more persons fill different and nevertheless very important roles. For example, when talking modern times an editor has extensive influence on the gestalt of the publicized/published work. And another very important role is that of the engraver (or typesetter however to call the function in digital times). Now going this road a bit we are very fast to come across someone being the encoder, as depending on workflow and technologies used, encoding and setting the music might overlap at some point. And for me this is an essential question that can be drawn from Kristina's post. Oe could even discuss of putting the encoder as or in as is not about the music but about the encoded data (although opening another question with this...). And this is where the encoder has primary and extensive influence. And, if I'm not mistaken, there is no MARC code for this! **Thus I would propose of having such an element to compensate this!** Another thing that has come to me - opening yet another bottle - is the encoding that Perry's second example shows, as I came across this in my metadata. > titleStmt> > My Music, Op. 1 > > > Composer > > Composer de Jure > > Lyricist > > Johann Collaborator Bach > > Arranger > > Arranger Man > Encoders > [encoder 1] > [encoder 2] > > > Although straightforward the content of leaves me with a shudder, as no explicit mapping of and is to be observed. I would very much prefer to see something like this: Composer Composer de Jure Lyricist Johann Collaborator Bach Arranger Arranger Man Encoders [encoder 1] [encoder 2] Adding some MARC relator code either in @role on or in with the corresponding @authURI would be helpful since providing a mapping to a controlled vocabulary. Although even here the setup could be discussed: 1) Why to supply if I can provide @role and @authURI on ? Composer de Jure Johann Collaborator Bach ... 2) How to supply the laguage-specific role description that Eleanor pointed out in the discussion? Is the right place? Komponist Composer de Jure Apparently not, as it only may have attributes to relate the included string to a controlled vocabulary. maybe: ... This would make necessary a for each role to be supplied. Which even is a good idea to group multiple names (as seen in preceeding examples by Kristina and Perry ). The again this would miss someting like @xml:lang which could allowed on if used for a label. Then if detailed description is not of primary interest, one could come up with a flat hierarchy: Composer de Jure Johann Collaborator Bach ... or: Komponist Composer de Jure That's it for now. Sorry for getting lengthy and raising even more questions. As I'm no metadata expert I see that at some points I might have been too focused on transcription instead of metadata, please excuse ;-) In expectation of a nice discussion, Benjamin Am 05.02.2013 18:23, schrieb Roland, Perry (pdr4h): > > Hello everyone, > > I can see now that my plan to provide and as > replacements for TEI's element isn't defensible because it's > causing more confusion than it alleviates. So, I suggest that we > > 1. return to the list provided by TEI -- author, editor, funder, > meeting, principal (as in principal investigator), sponsor, and respStmt, > > 2. but drop meeting and principal, and > > 3. add arranger, composer, librettist, and lyricist. > > As in TEI, any roles not specifically provided for by this list, such > as conductor, encoder, and so on, belong in , for example -- > > > My Music, Op. 1 > Composer de Jure > > Johann Collaborator Bach > > Arranger Extraordinaire > > Encoders > [encoder 1] > [encoder 2] > > > > In this scheme, , , , and > for musical compositions are equivalent to for > textual material. The element *should not* be used for > lyricists or librettists. > > MARC relator code list > (http://www.loc.gov/marc/relators/relaterm.html) provides more than > 200 codes/terms for roles, several of which apply to music and musical > performances. There's no way we can accommodate them all. So, it > makes sense to continue the TEI method of recording those responsible > for the *intellectual content* of the work in special elements and > relegating other roles to . (I think this actually stems > from ISBD and AACR2, not TEI.) > > The addition of these elements *does not* mandate their use; that is, > can be used for all responsibilities. The following markup > is a valid alternative to the example above: > > > My Music, Op. 1 > > > Composer > > Composer de Jure > > Lyricist > > Johann Collaborator Bach > > Arranger > > Arranger Man > Encoders > [encoder 1] > [encoder 2] > > > > This form can be easier to produce mechanistically from other encoding > schemes and is conformant with forms of cataloging that don't require > a "main entry" approach, meaning that it would be easier to transform > into one of those systems, such as MODS. > > Also, it's necessary to keep in mind that since is a kind > of bibliographic citation, elements used here are also available in > (and must also fit within the purpose of) other elements, such as > and . > > Best wishes, > > -- > > 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 Eleanor > Selfridge-Field [esfield at stanford.edu] > *Sent:* Monday, February 04, 2013 4:39 PM > *To:* 'Music Encoding Initiative' > *Subject:* Re: [MEI-L] Encoding of personal names > > Kristina poses interesting questions. Instinctively I would go for > "composer", "encoder," etc and err on the side of being verbose and > explicit. With electronic data, being able to track who encoded what > (with version number and date) can be very valuable. > > I find labels such as "creator" and "corporate name" very unwieldy, > particularly when working in a second language (in my case usually > Italian). Italian bibliographical databases a full of these kinds of > terms, but there is something subtly cultural about the > misunderstandings they can create. The various instantiations of a > single work can have many creators---a composer, an arranger, and > editor, a translator of the text, and in the case of recording a > conductor, performer, performing group, etc. Because they can all > pertain to a single work, a general label deprives the user of knowing > what the role of each one was. > > A much messier area is dating. A single work can have an almost > endless number of "year"s---of composition, publication, first > performance, revision <1..n>, arrangement, recording, text > translation, etc. There too being more specific saves time for those > searching. > > Best regards, > > Eleanor > > Eleanor Selfridge-Field > Consulting Professor, Music (and, by courtesy, Symbolic Systems) > Braun Music Center #129 > Stanford University > Stanford, CA 94305-3076, USA > http://www.stanford.edu/~esfield/ > > *From:*mei-l-bounces at lists.uni-paderborn.de > [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of *Kristina > Richts > *Sent:* Monday, February 04, 2013 9:55 AM > *To:* mei-l at lists.uni-paderborn.de > *Subject:* [MEI-L] Encoding of personal names > > Dear all, > > during the work on the MEI sample collection, questions appeared on > how to encode the creators of each electronic file correctly. > In MEI2012 the normal path (or better said: the way, we first chose to > encode it) was to encode several -elements within the > statement of responsibilty. A differentiation between several involved > persons only became apparent through additional @role-attributes, i.e. > > Anton Webern > John Doe > > > In a second step we decided not to encode ourselves as "creators" of > the file (although we are), but as "encoders" and to assign the > composer of the encoded work as creator, i.e. > > > Anton Webern > John Doe > > > The decision is based on the fact, that we encode the _intellectual > creation_ of a composer's work. We tried to keep up the distinction > between the composer and the encoder. > > MEI2013 will offer some new elements to specify the role of persons, > organizations etc. a bit more: , , , > and . > In this regard it is now the question how to encode this best: > > > > Anton Webern > > > John Doe > > > > or > > > > Anton Webern > > > John Doe > > > ? > > We first thought, it would be a good idea, to add a element > to the list. But that alone would not be sufficient, as the creative > aspect regarding musical works is difficult to manage. In this case, > we would rather have to extend the list by adding some more elements > like , , etc. But this can soon become very unwieldy. > > I have to admit that I don't prefer to encode detailed specifications > only within child elements. However, if we choose to maintain the > 'more detailed elements', I would at least like to see some mandatory > child elements, such as , , etc., in there. > > When thinking about all this, I came to the conclusion, that it might > be enough to allow a and a element (with some > mandatory child elements). I am not even sure, if we should offer a > separate element or if an editor should be considered as a > contributor as well. > What is to be said against a specification of the role on the > or element? Wouldn't this make things easier > to handle for the encoder, who might not know as much about the > encoding of persNames with MEI? > > > Any comments on this? > > Best, > Kristina > > > > _______________________________________________ > 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: From kepper at edirom.de Thu Feb 7 10:44:29 2013 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 7 Feb 2013 10:44:29 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: <51136797.7020407@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> Message-ID: Hi all, I would really like to get around this can of worms, but I can't resist any longer ;-) All these elements are syntactic sugar ? author, editor, funder, sponsor, arranger, composer, librettist and lyricist. Benjamin's posting showcases that it is not absolutely clear why we have exactly this selection of sugar drops. I for myself feel equally inconvenient with it, as does Kristina (if I got her right in a recent discussion in Detmold). It seems like drawing a line is easy, but agreeing on and justifying that line is less easy. Therefore, my question is whether we really need to draw that line. MEI existed without that syntactic sugar for quite some time, and I don't remember major complains about this as a missing feature. Wouldn't it be much better to delegate that to individual projects, which could add their own flavor of sugar, and document what they did in their own ODD? (Yes, we need better resources for explaining how to actually do that?). Regarding the mixed use of and , please note the current guidelines, which read on page 25 (chapter 2.1.1: Title Statement): "While accommodates capturing the wide variety of text that may occur in responsibility statements, use of the @role attribute provides the possibility of recording a controlled value independently of the textual content of . The use of @role is required for improved data processability and interchange." Basically, is used to transcribe the wording in a source, whereas @role on the name itself is better suited (and therefore recommended) for processing the data. On the following page, there is also a reference to the MARC list Benjamin mentioned: "Values from the MARC relator code list (http://www.loc.gov/marc/relators/relacode.html) or term list (http://www.loc.gov/marc/relators/relaterm.html) are recommended for @role, where applicable." Of course, this does not solve the starting question, but it illustrates that it may occasionally help to read the friendly manual ;-) Best, Johannes Am 07.02.2013 um 09:36 schrieb Benjamin Wolff Bohl: > Hi Kristina and List:eners! > In the past few months I've been dealing with the idea of capuring the metadata of published records in MEI and to start out I decided for the harest part ;-) A recording was made publicized and later re-issued on a differnet sound carrier, additional work done by technicians and additional text parts completed this re-issue. > As you might imagine, I came across quite a lot of responsibility statements and I find it very convnient to stitch to the MARC code list for Relators. > Thus I can understand Perry's idea and might even support to > >> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >> 2. but drop meeting and principal, and >> 3. add arranger, composer, librettist, and lyricist. > >> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. > > Though making a decision here always weans to draw a line. But where to draw the line? > Arranger could still be dropped as his activity might be secondary or even tertiary use of the work. > > Then on the other hand when moving forward in the publication process more and more persons fill different and nevertheless very important roles. For example, when talking modern times an editor has extensive influence on the gestalt of the publicized/published work. And another very important role is that of the engraver (or typesetter however to call the function in digital times). Now going this road a bit we are very fast to come across someone being the encoder, as depending on workflow and technologies used, encoding and setting the music might overlap at some point. > > And for me this is an essential question that can be drawn from Kristina's post. Oe could even discuss of putting the encoder as or in as is not about the music but about the encoded data (although opening another question with this...). And this is where the encoder has primary and extensive influence. And, if I'm not mistaken, there is no MARC code for this! > **Thus I would propose of having such an element to compensate this!** > > Another thing that has come to me - opening yet another bottle - is the encoding that Perry's second example shows, as I came across this in my metadata. > >> titleStmt> >> My Music, Op. 1 >> >> Composer >> Composer de Jure >> Lyricist >> Johann Collaborator Bach >> Arranger >> Arranger Man >> Encoders >> [encoder 1] >> [encoder 2] >> >> > > Although straightforward the content of leaves me with a shudder, as no explicit mapping of and is to be observed. I would very much prefer to see something like this: > > > Composer > Composer de Jure > > > Lyricist > Johann Collaborator Bach > > > Arranger > Arranger Man > > > Encoders > [encoder 1] > [encoder 2] > > > Adding some MARC relator code either in @role on or in with the corresponding @authURI would be helpful since providing a mapping to a controlled vocabulary. Although even here the setup could be discussed: > > 1) Why to supply if I can provide @role and @authURI on ? > > > Composer de Jure > Johann Collaborator Bach > ... > > > 2) How to supply the laguage-specific role description that Eleanor pointed out in the discussion? > Is the right place? > > > Komponist > Composer de Jure > > > Apparently not, as it only may have attributes to relate the included string to a controlled vocabulary. > maybe: > > > ... > > > This would make necessary a for each role to be supplied. Which even is a good idea to group multiple names (as seen in preceeding examples by Kristina and Perry ). > The again this would miss someting like @xml:lang which could allowed on if used for a label. > > Then if detailed description is not of primary interest, one could come up with a flat hierarchy: > > > Composer de Jure > Johann Collaborator Bach > ... > > > or: > > > Komponist > Composer de Jure > > > > That's it for now. Sorry for getting lengthy and raising even more questions. > As I'm no metadata expert I see that at some points I might have been too focused on transcription instead of metadata, please excuse ;-) > In expectation of a nice discussion, > > Benjamin > > > Am 05.02.2013 18:23, schrieb Roland, Perry (pdr4h): >> Hello everyone, >> >> I can see now that my plan to provide and as replacements for TEI's element isn't defensible because it's causing more confusion than it alleviates. So, I suggest that we >> >> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >> 2. but drop meeting and principal, and >> 3. add arranger, composer, librettist, and lyricist. >> >> As in TEI, any roles not specifically provided for by this list, such as conductor, encoder, and so on, belong in , for example -- >> >> >> My Music, Op. 1 >> Composer de Jure >> Johann Collaborator Bach >> Arranger Extraordinaire >> >> Encoders >> [encoder 1] >> [encoder 2] >> >> >> >> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. >> >> MARC relator code list (http://www.loc.gov/marc/relators/relaterm.html) provides more than 200 codes/terms for roles, several of which apply to music and musical performances. There's no way we can accommodate them all. So, it makes sense to continue the TEI method of recording those responsible for the *intellectual content* of the work in special elements and relegating other roles to . (I think this actually stems from ISBD and AACR2, not TEI.) >> >> The addition of these elements *does not* mandate their use; that is, can be used for all responsibilities. The following markup is a valid alternative to the example above: >> >> >> My Music, Op. 1 >> >> Composer >> Composer de Jure >> Lyricist >> Johann Collaborator Bach >> Arranger >> Arranger Man >> Encoders >> [encoder 1] >> [encoder 2] >> >> >> >> This form can be easier to produce mechanistically from other encoding schemes and is conformant with forms of cataloging that don't require a "main entry" approach, meaning that it would be easier to transform into one of those systems, such as MODS. >> >> Also, it's necessary to keep in mind that since is a kind of bibliographic citation, elements used here are also available in (and must also fit within the purpose of) other elements, such as and . >> >> Best wishes, >> >> -- >> 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 Eleanor Selfridge-Field [esfield at stanford.edu] >> Sent: Monday, February 04, 2013 4:39 PM >> To: 'Music Encoding Initiative' >> Subject: Re: [MEI-L] Encoding of personal names >> >> Kristina poses interesting questions. Instinctively I would go for ?composer?, ?encoder,? etc and err on the side of being verbose and explicit. With electronic data, being able to track who encoded what (with version number and date) can be very valuable. >> >> I find labels such as ?creator? and ?corporate name? very unwieldy, particularly when working in a second language (in my case usually Italian). Italian bibliographical databases a full of these kinds of terms, but there is something subtly cultural about the misunderstandings they can create. The various instantiations of a single work can have many creators?a composer, an arranger, and editor, a translator of the text, and in the case of recording a conductor, performer, performing group, etc. Because they can all pertain to a single work, a general label deprives the user of knowing what the role of each one was. >> >> A much messier area is dating. A single work can have an almost endless number of ?year?s?of composition, publication, first performance, revision <1..n>, arrangement, recording, text translation, etc. There too being more specific saves time for those searching. >> >> Best regards, >> >> Eleanor >> >> >> Eleanor Selfridge-Field >> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >> Braun Music Center #129 >> Stanford University >> Stanford, CA 94305-3076, USA >> http://www.stanford.edu/~esfield/ >> >> >> >> From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kristina Richts >> Sent: Monday, February 04, 2013 9:55 AM >> To: mei-l at lists.uni-paderborn.de >> Subject: [MEI-L] Encoding of personal names >> >> Dear all, >> >> during the work on the MEI sample collection, questions appeared on how to encode the creators of each electronic file correctly. >> In MEI2012 the normal path (or better said: the way, we first chose to encode it) was to encode several -elements within the statement of responsibilty. A differentiation between several involved persons only became apparent through additional @role-attributes, i.e. >> >> Anton Webern >> John Doe >> >> >> In a second step we decided not to encode ourselves as "creators" of the file (although we are), but as "encoders" and to assign the composer of the encoded work as creator, i.e. >> >> >> Anton Webern >> John Doe >> >> >> The decision is based on the fact, that we encode the intellectual creation of a composer's work. We tried to keep up the distinction between the composer and the encoder. >> >> MEI2013 will offer some new elements to specify the role of persons, organizations etc. a bit more: , , , and . >> In this regard it is now the question how to encode this best: >> >> >> >> Anton Webern >> >> >> John Doe >> >> >> >> or >> >> >> >> Anton Webern >> >> >> John Doe >> >> >> ? >> >> We first thought, it would be a good idea, to add a element to the list. But that alone would not be sufficient, as the creative aspect regarding musical works is difficult to manage. In this case, we would rather have to extend the list by adding some more elements like , , etc. But this can soon become very unwieldy. >> >> I have to admit that I don't prefer to encode detailed specifications only within child elements. However, if we choose to maintain the 'more detailed elements', I would at least like to see some mandatory child elements, such as , , etc., in there. >> >> When thinking about all this, I came to the conclusion, that it might be enough to allow a and a element (with some mandatory child elements). I am not even sure, if we should offer a separate element or if an editor should be considered as a contributor as well. >> What is to be said against a specification of the role on the or element? Wouldn't this make things easier to handle for the encoder, who might not know as much about the encoding of persNames with MEI? >> >> >> Any comments on this? >> >> Best, >> Kristina >> >> >> _______________________________________________ >> 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 bohl at edirom.de Thu Feb 7 12:05:20 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 07 Feb 2013 12:05:20 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> Message-ID: <51138A70.9070402@edirom.de> Only a quick follow up question and response (see inline) Am 07.02.2013 10:44, schrieb Johannes Kepper: > Hi all, > > I would really like to get around this can of worms, but I can't resist any longer ;-) > > All these elements are syntactic sugar ? author, editor, funder, sponsor, arranger, composer, librettist and lyricist. Benjamin's posting showcases that it is not absolutely clear why we have exactly this selection of sugar drops. I for myself feel equally inconvenient with it, as does Kristina (if I got her right in a recent discussion in Detmold). It seems like drawing a line is easy, but agreeing on and justifying that line is less easy. Therefore, my question is whether we really need to draw that line. MEI existed without that syntactic sugar for quite some time, and I don't remember major complains about this as a missing feature. Wouldn't it be much better to delegate that to individual projects, which could add their own flavor of sugar, and document what they did in their own ODD? (Yes, we need better resources for explaining how to actually do that?). If I understand this right, you propose not to have these syntactic sugar elements in the schema but to stick to with and either or and suggest to add sugar by referencing corresponding authority codes. As mentioned before there might be cases where no corresponding authority code exists (as with encoder in MARC). The I could either find a different autority or just not supply the authority @s. Fine with me - does make processing easier! Any other opinions on that? Now to the next point of discussion: > > Regarding the mixed use of and , please note the current guidelines, which read on page 25 (chapter 2.1.1: Title Statement): > > "While accommodates capturing the wide variety of text that may occur in responsibility statements, use of the @role attribute provides the possibility of recording a controlled value independently of the textual content of . The use of @role is required for improved data processability and interchange." > > Basically, is used to transcribe the wording in a source, whereas @role on the name itself is better suited (and therefore recommended) for processing the data. On the following page, there is also a reference to the MARC list Benjamin mentioned: > > "Values from the MARC relator code list (http://www.loc.gov/marc/relators/relacode.html) or term list (http://www.loc.gov/marc/relators/relaterm.html) are recommended for @role, where applicable." > > Of course, this does not solve the starting question, but it illustrates that it may occasionally help to read the friendly manual ;-) > Best, > Johannes I completely understand what the guidelines state here but regarding the schema design for implies that it is meant differently: When transcribing the wording of the source in what use do @authority and @authURI have as I cannot supply this info with the authorities code for that certain type of responsibility, ergo something similar to @role in would be required, maybe @dbkey or comparable could fill this gap? cheers, benni > > > > > Am 07.02.2013 um 09:36 schrieb Benjamin Wolff Bohl: > >> Hi Kristina and List:eners! >> In the past few months I've been dealing with the idea of capuring the metadata of published records in MEI and to start out I decided for the harest part ;-) A recording was made publicized and later re-issued on a differnet sound carrier, additional work done by technicians and additional text parts completed this re-issue. >> As you might imagine, I came across quite a lot of responsibility statements and I find it very convnient to stitch to the MARC code list for Relators. >> Thus I can understand Perry's idea and might even support to >> >>> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >>> 2. but drop meeting and principal, and >>> 3. add arranger, composer, librettist, and lyricist. >>> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. >> Though making a decision here always weans to draw a line. But where to draw the line? >> Arranger could still be dropped as his activity might be secondary or even tertiary use of the work. >> >> Then on the other hand when moving forward in the publication process more and more persons fill different and nevertheless very important roles. For example, when talking modern times an editor has extensive influence on the gestalt of the publicized/published work. And another very important role is that of the engraver (or typesetter however to call the function in digital times). Now going this road a bit we are very fast to come across someone being the encoder, as depending on workflow and technologies used, encoding and setting the music might overlap at some point. >> >> And for me this is an essential question that can be drawn from Kristina's post. Oe could even discuss of putting the encoder as or in as is not about the music but about the encoded data (although opening another question with this...). And this is where the encoder has primary and extensive influence. And, if I'm not mistaken, there is no MARC code for this! >> **Thus I would propose of having such an element to compensate this!** >> >> Another thing that has come to me - opening yet another bottle - is the encoding that Perry's second example shows, as I came across this in my metadata. >> >>> titleStmt> >>> My Music, Op. 1 >>> >>> Composer >>> Composer de Jure >>> Lyricist >>> Johann Collaborator Bach >>> Arranger >>> Arranger Man >>> Encoders >>> [encoder 1] >>> [encoder 2] >>> >>> >> Although straightforward the content of leaves me with a shudder, as no explicit mapping of and is to be observed. I would very much prefer to see something like this: >> >> >> Composer >> Composer de Jure >> >> >> Lyricist >> Johann Collaborator Bach >> >> >> Arranger >> Arranger Man >> >> >> Encoders >> [encoder 1] >> [encoder 2] >> >> >> Adding some MARC relator code either in @role on or in with the corresponding @authURI would be helpful since providing a mapping to a controlled vocabulary. Although even here the setup could be discussed: >> >> 1) Why to supply if I can provide @role and @authURI on ? >> >> >> Composer de Jure >> Johann Collaborator Bach >> ... >> >> >> 2) How to supply the laguage-specific role description that Eleanor pointed out in the discussion? >> Is the right place? >> >> >> Komponist >> Composer de Jure >> >> >> Apparently not, as it only may have attributes to relate the included string to a controlled vocabulary. >> maybe: >> >> >> ... >> >> >> This would make necessary a for each role to be supplied. Which even is a good idea to group multiple names (as seen in preceeding examples by Kristina and Perry ). >> The again this would miss someting like @xml:lang which could allowed on if used for a label. >> >> Then if detailed description is not of primary interest, one could come up with a flat hierarchy: >> >> >> Composer de Jure >> Johann Collaborator Bach >> ... >> >> >> or: >> >> >> Komponist >> Composer de Jure >> >> >> >> That's it for now. Sorry for getting lengthy and raising even more questions. >> As I'm no metadata expert I see that at some points I might have been too focused on transcription instead of metadata, please excuse ;-) >> In expectation of a nice discussion, >> >> Benjamin >> >> >> Am 05.02.2013 18:23, schrieb Roland, Perry (pdr4h): >>> Hello everyone, >>> >>> I can see now that my plan to provide and as replacements for TEI's element isn't defensible because it's causing more confusion than it alleviates. So, I suggest that we >>> >>> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >>> 2. but drop meeting and principal, and >>> 3. add arranger, composer, librettist, and lyricist. >>> >>> As in TEI, any roles not specifically provided for by this list, such as conductor, encoder, and so on, belong in , for example -- >>> >>> >>> My Music, Op. 1 >>> Composer de Jure >>> Johann Collaborator Bach >>> Arranger Extraordinaire >>> >>> Encoders >>> [encoder 1] >>> [encoder 2] >>> >>> >>> >>> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. >>> >>> MARC relator code list (http://www.loc.gov/marc/relators/relaterm.html) provides more than 200 codes/terms for roles, several of which apply to music and musical performances. There's no way we can accommodate them all. So, it makes sense to continue the TEI method of recording those responsible for the *intellectual content* of the work in special elements and relegating other roles to . (I think this actually stems from ISBD and AACR2, not TEI.) >>> >>> The addition of these elements *does not* mandate their use; that is, can be used for all responsibilities. The following markup is a valid alternative to the example above: >>> >>> >>> My Music, Op. 1 >>> >>> Composer >>> Composer de Jure >>> Lyricist >>> Johann Collaborator Bach >>> Arranger >>> Arranger Man >>> Encoders >>> [encoder 1] >>> [encoder 2] >>> >>> >>> >>> This form can be easier to produce mechanistically from other encoding schemes and is conformant with forms of cataloging that don't require a "main entry" approach, meaning that it would be easier to transform into one of those systems, such as MODS. >>> >>> Also, it's necessary to keep in mind that since is a kind of bibliographic citation, elements used here are also available in (and must also fit within the purpose of) other elements, such as and . >>> >>> Best wishes, >>> >>> -- >>> 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 Eleanor Selfridge-Field [esfield at stanford.edu] >>> Sent: Monday, February 04, 2013 4:39 PM >>> To: 'Music Encoding Initiative' >>> Subject: Re: [MEI-L] Encoding of personal names >>> >>> Kristina poses interesting questions. Instinctively I would go for ?composer?, ?encoder,? etc and err on the side of being verbose and explicit. With electronic data, being able to track who encoded what (with version number and date) can be very valuable. >>> >>> I find labels such as ?creator? and ?corporate name? very unwieldy, particularly when working in a second language (in my case usually Italian). Italian bibliographical databases a full of these kinds of terms, but there is something subtly cultural about the misunderstandings they can create. The various instantiations of a single work can have many creators?a composer, an arranger, and editor, a translator of the text, and in the case of recording a conductor, performer, performing group, etc. Because they can all pertain to a single work, a general label deprives the user of knowing what the role of each one was. >>> >>> A much messier area is dating. A single work can have an almost endless number of ?year?s?of composition, publication, first performance, revision <1..n>, arrangement, recording, text translation, etc. There too being more specific saves time for those searching. >>> >>> Best regards, >>> >>> Eleanor >>> >>> >>> Eleanor Selfridge-Field >>> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >>> Braun Music Center #129 >>> Stanford University >>> Stanford, CA 94305-3076, USA >>> http://www.stanford.edu/~esfield/ >>> >>> >>> >>> From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kristina Richts >>> Sent: Monday, February 04, 2013 9:55 AM >>> To: mei-l at lists.uni-paderborn.de >>> Subject: [MEI-L] Encoding of personal names >>> >>> Dear all, >>> >>> during the work on the MEI sample collection, questions appeared on how to encode the creators of each electronic file correctly. >>> In MEI2012 the normal path (or better said: the way, we first chose to encode it) was to encode several -elements within the statement of responsibilty. A differentiation between several involved persons only became apparent through additional @role-attributes, i.e. >>> >>> Anton Webern >>> John Doe >>> >>> >>> In a second step we decided not to encode ourselves as "creators" of the file (although we are), but as "encoders" and to assign the composer of the encoded work as creator, i.e. >>> >>> >>> Anton Webern >>> John Doe >>> >>> >>> The decision is based on the fact, that we encode the intellectual creation of a composer's work. We tried to keep up the distinction between the composer and the encoder. >>> >>> MEI2013 will offer some new elements to specify the role of persons, organizations etc. a bit more: , , , and . >>> In this regard it is now the question how to encode this best: >>> >>> >>> >>> Anton Webern >>> >>> >>> John Doe >>> >>> >>> >>> or >>> >>> >>> >>> Anton Webern >>> >>> >>> John Doe >>> >>> >>> ? >>> >>> We first thought, it would be a good idea, to add a element to the list. But that alone would not be sufficient, as the creative aspect regarding musical works is difficult to manage. In this case, we would rather have to extend the list by adding some more elements like , , etc. But this can soon become very unwieldy. >>> >>> I have to admit that I don't prefer to encode detailed specifications only within child elements. However, if we choose to maintain the 'more detailed elements', I would at least like to see some mandatory child elements, such as , , etc., in there. >>> >>> When thinking about all this, I came to the conclusion, that it might be enough to allow a and a element (with some mandatory child elements). I am not even sure, if we should offer a separate element or if an editor should be considered as a contributor as well. >>> What is to be said against a specification of the role on the or element? Wouldn't this make things easier to handle for the encoder, who might not know as much about the encoding of persNames with MEI? >>> >>> >>> Any comments on this? >>> >>> Best, >>> Kristina >>> >>> >>> _______________________________________________ >>> 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 Thu Feb 7 14:03:14 2013 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 7 Feb 2013 14:03:14 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: <51138A70.9070402@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de> Message-ID: <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> Am 07.02.2013 um 12:05 schrieb Benjamin Wolff Bohl: > Only a quick follow up question and response (see inline) > > Am 07.02.2013 10:44, schrieb Johannes Kepper: >> Hi all, >> >> I would really like to get around this can of worms, but I can't resist any longer ;-) >> >> All these elements are syntactic sugar ? author, editor, funder, sponsor, arranger, composer, librettist and lyricist. Benjamin's posting showcases that it is not absolutely clear why we have exactly this selection of sugar drops. I for myself feel equally inconvenient with it, as does Kristina (if I got her right in a recent discussion in Detmold). It seems like drawing a line is easy, but agreeing on and justifying that line is less easy. Therefore, my question is whether we really need to draw that line. MEI existed without that syntactic sugar for quite some time, and I don't remember major complains about this as a missing feature. Wouldn't it be much better to delegate that to individual projects, which could add their own flavor of sugar, and document what they did in their own ODD? (Yes, we need better resources for explaining how to actually do that?). > > If I understand this right, you propose not to have these syntactic sugar elements in the schema but to stick to with and either or and suggest to add sugar by referencing corresponding authority codes. > As mentioned before there might be cases where no corresponding authority code exists (as with encoder in MARC). The I could either find a different autority or just not supply the authority @s. Taken from the MARC list: Markup editor [mrk] Use for a person or organization performing the coding of SGML, HTML, or XML markup of metadata, text, etc. Metadata contact [mdc] Use for a person or organization primarily responsible for compiling and maintaining the original description of a metadata set (e.g., geospatial metadata set). Data contributor [dtc] Use for a person or organization that submits data for inclusion in a database or other collection of data. Data manager [dtm] Use for a person or organization responsible for managing databases or other data sources. Analyst [anl] Use for a person or organization that reviews, examines and interprets data or information in a specific area. ---- Not all of them are useful all the time, but it's actually hard to find something not taken care of by the MARC list. You sometimes have to twist it's arm, as everything is focussed on physical media, but you're likely to find something. > > Fine with me - does make processing easier! > Any other opinions on that? > > Now to the next point of discussion: >> >> Regarding the mixed use of and , please note the current guidelines, which read on page 25 (chapter 2.1.1: Title Statement): >> >> "While accommodates capturing the wide variety of text that may occur in responsibility statements, use of the @role attribute provides the possibility of recording a controlled value independently of the textual content of . The use of @role is required for improved data processability and interchange." >> >> Basically, is used to transcribe the wording in a source, whereas @role on the name itself is better suited (and therefore recommended) for processing the data. On the following page, there is also a reference to the MARC list Benjamin mentioned: >> >> "Values from the MARC relator code list (http://www.loc.gov/marc/relators/relacode.html) or term list (http://www.loc.gov/marc/relators/relaterm.html) are recommended for @role, where applicable." >> >> Of course, this does not solve the starting question, but it illustrates that it may occasionally help to read the friendly manual ;-) >> Best, >> Johannes > > I completely understand what the guidelines state here but regarding the schema design for implies that it is meant differently: > When transcribing the wording of the source in what use do @authority and @authURI have as I cannot supply this info with the authorities code for that certain type of responsibility, ergo something similar to @role in would be required, maybe @dbkey or comparable could fill this gap? I am not sure about the use of @authURI and @authority on , as this is clearly meant for plain text. But you're right, we should either add @code or @dbkey, or remove the other attributes as well. Best, Johannes > > cheers, > benni > >> >> >> >> >> Am 07.02.2013 um 09:36 schrieb Benjamin Wolff Bohl: >> >>> Hi Kristina and List:eners! >>> In the past few months I've been dealing with the idea of capuring the metadata of published records in MEI and to start out I decided for the harest part ;-) A recording was made publicized and later re-issued on a differnet sound carrier, additional work done by technicians and additional text parts completed this re-issue. >>> As you might imagine, I came across quite a lot of responsibility statements and I find it very convnient to stitch to the MARC code list for Relators. >>> Thus I can understand Perry's idea and might even support to >>> >>>> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >>>> 2. but drop meeting and principal, and >>>> 3. add arranger, composer, librettist, and lyricist. >>>> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. >>> Though making a decision here always weans to draw a line. But where to draw the line? >>> Arranger could still be dropped as his activity might be secondary or even tertiary use of the work. >>> >>> Then on the other hand when moving forward in the publication process more and more persons fill different and nevertheless very important roles. For example, when talking modern times an editor has extensive influence on the gestalt of the publicized/published work. And another very important role is that of the engraver (or typesetter however to call the function in digital times). Now going this road a bit we are very fast to come across someone being the encoder, as depending on workflow and technologies used, encoding and setting the music might overlap at some point. >>> >>> And for me this is an essential question that can be drawn from Kristina's post. Oe could even discuss of putting the encoder as or in as is not about the music but about the encoded data (although opening another question with this...). And this is where the encoder has primary and extensive influence. And, if I'm not mistaken, there is no MARC code for this! >>> **Thus I would propose of having such an element to compensate this!** >>> >>> Another thing that has come to me - opening yet another bottle - is the encoding that Perry's second example shows, as I came across this in my metadata. >>> >>>> titleStmt> >>>> My Music, Op. 1 >>>> >>>> Composer >>>> Composer de Jure >>>> Lyricist >>>> Johann Collaborator Bach >>>> Arranger >>>> Arranger Man >>>> Encoders >>>> [encoder 1] >>>> [encoder 2] >>>> >>>> >>> Although straightforward the content of leaves me with a shudder, as no explicit mapping of and is to be observed. I would very much prefer to see something like this: >>> >>> >>> Composer >>> Composer de Jure >>> >>> >>> Lyricist >>> Johann Collaborator Bach >>> >>> >>> Arranger >>> Arranger Man >>> >>> >>> Encoders >>> [encoder 1] >>> [encoder 2] >>> >>> >>> Adding some MARC relator code either in @role on or in with the corresponding @authURI would be helpful since providing a mapping to a controlled vocabulary. Although even here the setup could be discussed: >>> >>> 1) Why to supply if I can provide @role and @authURI on ? >>> >>> >>> Composer de Jure >>> Johann Collaborator Bach >>> ... >>> >>> >>> 2) How to supply the laguage-specific role description that Eleanor pointed out in the discussion? >>> Is the right place? >>> >>> >>> Komponist >>> Composer de Jure >>> >>> >>> Apparently not, as it only may have attributes to relate the included string to a controlled vocabulary. >>> maybe: >>> >>> >>> ... >>> >>> >>> This would make necessary a for each role to be supplied. Which even is a good idea to group multiple names (as seen in preceeding examples by Kristina and Perry ). >>> The again this would miss someting like @xml:lang which could allowed on if used for a label. >>> >>> Then if detailed description is not of primary interest, one could come up with a flat hierarchy: >>> >>> >>> Composer de Jure >>> Johann Collaborator Bach >>> ... >>> >>> >>> or: >>> >>> >>> Komponist >>> Composer de Jure >>> >>> >>> >>> That's it for now. Sorry for getting lengthy and raising even more questions. >>> As I'm no metadata expert I see that at some points I might have been too focused on transcription instead of metadata, please excuse ;-) >>> In expectation of a nice discussion, >>> >>> Benjamin >>> >>> >>> Am 05.02.2013 18:23, schrieb Roland, Perry (pdr4h): >>>> Hello everyone, >>>> I can see now that my plan to provide and as replacements for TEI's element isn't defensible because it's causing more confusion than it alleviates. So, I suggest that we >>>> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >>>> 2. but drop meeting and principal, and >>>> 3. add arranger, composer, librettist, and lyricist. >>>> As in TEI, any roles not specifically provided for by this list, such as conductor, encoder, and so on, belong in , for example -- >>>> >>>> My Music, Op. 1 >>>> Composer de Jure >>>> Johann Collaborator Bach >>>> Arranger Extraordinaire >>>> >>>> Encoders >>>> [encoder 1] >>>> [encoder 2] >>>> >>>> >>>> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. >>>> MARC relator code list (http://www.loc.gov/marc/relators/relaterm.html) provides more than 200 codes/terms for roles, several of which apply to music and musical performances. There's no way we can accommodate them all. So, it makes sense to continue the TEI method of recording those responsible for the *intellectual content* of the work in special elements and relegating other roles to . (I think this actually stems from ISBD and AACR2, not TEI.) >>>> The addition of these elements *does not* mandate their use; that is, can be used for all responsibilities. The following markup is a valid alternative to the example above: >>>> >>>> My Music, Op. 1 >>>> >>>> Composer >>>> Composer de Jure >>>> Lyricist >>>> Johann Collaborator Bach >>>> Arranger >>>> Arranger Man >>>> Encoders >>>> [encoder 1] >>>> [encoder 2] >>>> >>>> >>>> This form can be easier to produce mechanistically from other encoding schemes and is conformant with forms of cataloging that don't require a "main entry" approach, meaning that it would be easier to transform into one of those systems, such as MODS. >>>> Also, it's necessary to keep in mind that since is a kind of bibliographic citation, elements used here are also available in (and must also fit within the purpose of) other elements, such as and . >>>> Best wishes, >>>> -- >>>> 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 Eleanor Selfridge-Field [esfield at stanford.edu] >>>> Sent: Monday, February 04, 2013 4:39 PM >>>> To: 'Music Encoding Initiative' >>>> Subject: Re: [MEI-L] Encoding of personal names >>>> >>>> Kristina poses interesting questions. Instinctively I would go for ?composer?, ?encoder,? etc and err on the side of being verbose and explicit. With electronic data, being able to track who encoded what (with version number and date) can be very valuable. >>>> I find labels such as ?creator? and ?corporate name? very unwieldy, particularly when working in a second language (in my case usually Italian). Italian bibliographical databases a full of these kinds of terms, but there is something subtly cultural about the misunderstandings they can create. The various instantiations of a single work can have many creators?a composer, an arranger, and editor, a translator of the text, and in the case of recording a conductor, performer, performing group, etc. Because they can all pertain to a single work, a general label deprives the user of knowing what the role of each one was. >>>> A much messier area is dating. A single work can have an almost endless number of ?year?s?of composition, publication, first performance, revision <1..n>, arrangement, recording, text translation, etc. There too being more specific saves time for those searching. >>>> Best regards, >>>> Eleanor >>>> Eleanor Selfridge-Field >>>> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >>>> Braun Music Center #129 >>>> Stanford University >>>> Stanford, CA 94305-3076, USA >>>> http://www.stanford.edu/~esfield/ >>>> From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kristina Richts >>>> Sent: Monday, February 04, 2013 9:55 AM >>>> To: mei-l at lists.uni-paderborn.de >>>> Subject: [MEI-L] Encoding of personal names >>>> Dear all, >>>> >>>> during the work on the MEI sample collection, questions appeared on how to encode the creators of each electronic file correctly. >>>> In MEI2012 the normal path (or better said: the way, we first chose to encode it) was to encode several -elements within the statement of responsibilty. A differentiation between several involved persons only became apparent through additional @role-attributes, i.e. >>>> >>>> Anton Webern >>>> John Doe >>>> >>>> >>>> In a second step we decided not to encode ourselves as "creators" of the file (although we are), but as "encoders" and to assign the composer of the encoded work as creator, i.e. >>>> >>>> >>>> Anton Webern >>>> John Doe >>>> >>>> >>>> The decision is based on the fact, that we encode the intellectual creation of a composer's work. We tried to keep up the distinction between the composer and the encoder. >>>> >>>> MEI2013 will offer some new elements to specify the role of persons, organizations etc. a bit more: , , , and . >>>> In this regard it is now the question how to encode this best: >>>> >>>> >>>> Anton Webern >>>> >>>> >>>> John Doe >>>> >>>> >>>> >>>> or >>>> >>>> >>>> >>>> Anton Webern >>>> >>>> >>>> John Doe >>>> >>>> >>>> ? >>>> >>>> We first thought, it would be a good idea, to add a element to the list. But that alone would not be sufficient, as the creative aspect regarding musical works is difficult to manage. In this case, we would rather have to extend the list by adding some more elements like , , etc. But this can soon become very unwieldy. >>>> >>>> I have to admit that I don't prefer to encode detailed specifications only within child elements. However, if we choose to maintain the 'more detailed elements', I would at least like to see some mandatory child elements, such as , , etc., in there. >>>> >>>> When thinking about all this, I came to the conclusion, that it might be enough to allow a and a element (with some mandatory child elements). I am not even sure, if we should offer a separate element or if an editor should be considered as a contributor as well. >>>> What is to be said against a specification of the role on the or element? Wouldn't this make things easier to handle for the encoder, who might not know as much about the encoding of persNames with MEI? >>>> >>>> Any comments on this? >>>> >>>> Best, >>>> Kristina >>>> >>>> >>>> _______________________________________________ >>>> 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 bohl at edirom.de Thu Feb 7 14:48:00 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 07 Feb 2013 14:48:00 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de> <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> Message-ID: <5113B090.5050906@edirom.de> Hi Johannes, thanks for pointing out the MARC codes especialy for "Markup editor", which had slipped my attention ;-) With that one clear, how's general opinion or feelings concerning the "syntactic sugar" elements dicssed in this thread? cheers, Benni Am 07.02.2013 14:03, schrieb Johannes Kepper: > Am 07.02.2013 um 12:05 schrieb Benjamin Wolff Bohl: > >> Only a quick follow up question and response (see inline) >> >> Am 07.02.2013 10:44, schrieb Johannes Kepper: >>> Hi all, >>> >>> I would really like to get around this can of worms, but I can't resist any longer ;-) >>> >>> All these elements are syntactic sugar ? author, editor, funder, sponsor, arranger, composer, librettist and lyricist. Benjamin's posting showcases that it is not absolutely clear why we have exactly this selection of sugar drops. I for myself feel equally inconvenient with it, as does Kristina (if I got her right in a recent discussion in Detmold). It seems like drawing a line is easy, but agreeing on and justifying that line is less easy. Therefore, my question is whether we really need to draw that line. MEI existed without that syntactic sugar for quite some time, and I don't remember major complains about this as a missing feature. Wouldn't it be much better to delegate that to individual projects, which could add their own flavor of sugar, and document what they did in their own ODD? (Yes, we need better resources for explaining how to actually do that?). >> If I understand this right, you propose not to have these syntactic sugar elements in the schema but to stick to with and either or and suggest to add sugar by referencing corresponding authority codes. >> As mentioned before there might be cases where no corresponding authority code exists (as with encoder in MARC). The I could either find a different autority or just not supply the authority @s. > Taken from the MARC list: > > Markup editor [mrk] > Use for a person or organization performing the coding of SGML, HTML, or XML markup of metadata, text, etc. > > Metadata contact [mdc] > Use for a person or organization primarily responsible for compiling and maintaining the original description of a metadata set (e.g., geospatial metadata set). > > Data contributor [dtc] > Use for a person or organization that submits data for inclusion in a database or other collection of data. > > Data manager [dtm] > Use for a person or organization responsible for managing databases or other data sources. > > Analyst [anl] > Use for a person or organization that reviews, examines and interprets data or information in a specific area. > > ---- > > Not all of them are useful all the time, but it's actually hard to find something not taken care of by the MARC list. You sometimes have to twist it's arm, as everything is focussed on physical media, but you're likely to find something. > >> Fine with me - does make processing easier! >> Any other opinions on that? >> >> Now to the next point of discussion: >>> Regarding the mixed use of and , please note the current guidelines, which read on page 25 (chapter 2.1.1: Title Statement): >>> >>> "While accommodates capturing the wide variety of text that may occur in responsibility statements, use of the @role attribute provides the possibility of recording a controlled value independently of the textual content of . The use of @role is required for improved data processability and interchange." >>> >>> Basically, is used to transcribe the wording in a source, whereas @role on the name itself is better suited (and therefore recommended) for processing the data. On the following page, there is also a reference to the MARC list Benjamin mentioned: >>> >>> "Values from the MARC relator code list (http://www.loc.gov/marc/relators/relacode.html) or term list (http://www.loc.gov/marc/relators/relaterm.html) are recommended for @role, where applicable." >>> >>> Of course, this does not solve the starting question, but it illustrates that it may occasionally help to read the friendly manual ;-) >>> Best, >>> Johannes >> I completely understand what the guidelines state here but regarding the schema design for implies that it is meant differently: >> When transcribing the wording of the source in what use do @authority and @authURI have as I cannot supply this info with the authorities code for that certain type of responsibility, ergo something similar to @role in would be required, maybe @dbkey or comparable could fill this gap? > I am not sure about the use of @authURI and @authority on , as this is clearly meant for plain text. But you're right, we should either add @code or @dbkey, or remove the other attributes as well. > > Best, > Johannes > >> cheers, >> benni >> >>> >>> >>> >>> Am 07.02.2013 um 09:36 schrieb Benjamin Wolff Bohl: >>> >>>> Hi Kristina and List:eners! >>>> In the past few months I've been dealing with the idea of capuring the metadata of published records in MEI and to start out I decided for the harest part ;-) A recording was made publicized and later re-issued on a differnet sound carrier, additional work done by technicians and additional text parts completed this re-issue. >>>> As you might imagine, I came across quite a lot of responsibility statements and I find it very convnient to stitch to the MARC code list for Relators. >>>> Thus I can understand Perry's idea and might even support to >>>> >>>>> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >>>>> 2. but drop meeting and principal, and >>>>> 3. add arranger, composer, librettist, and lyricist. >>>>> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. >>>> Though making a decision here always weans to draw a line. But where to draw the line? >>>> Arranger could still be dropped as his activity might be secondary or even tertiary use of the work. >>>> >>>> Then on the other hand when moving forward in the publication process more and more persons fill different and nevertheless very important roles. For example, when talking modern times an editor has extensive influence on the gestalt of the publicized/published work. And another very important role is that of the engraver (or typesetter however to call the function in digital times). Now going this road a bit we are very fast to come across someone being the encoder, as depending on workflow and technologies used, encoding and setting the music might overlap at some point. >>>> >>>> And for me this is an essential question that can be drawn from Kristina's post. Oe could even discuss of putting the encoder as or in as is not about the music but about the encoded data (although opening another question with this...). And this is where the encoder has primary and extensive influence. And, if I'm not mistaken, there is no MARC code for this! >>>> **Thus I would propose of having such an element to compensate this!** >>>> >>>> Another thing that has come to me - opening yet another bottle - is the encoding that Perry's second example shows, as I came across this in my metadata. >>>> >>>>> titleStmt> >>>>> My Music, Op. 1 >>>>> >>>>> Composer >>>>> Composer de Jure >>>>> Lyricist >>>>> Johann Collaborator Bach >>>>> Arranger >>>>> Arranger Man >>>>> Encoders >>>>> [encoder 1] >>>>> [encoder 2] >>>>> >>>>> >>>> Although straightforward the content of leaves me with a shudder, as no explicit mapping of and is to be observed. I would very much prefer to see something like this: >>>> >>>> >>>> Composer >>>> Composer de Jure >>>> >>>> >>>> Lyricist >>>> Johann Collaborator Bach >>>> >>>> >>>> Arranger >>>> Arranger Man >>>> >>>> >>>> Encoders >>>> [encoder 1] >>>> [encoder 2] >>>> >>>> >>>> Adding some MARC relator code either in @role on or in with the corresponding @authURI would be helpful since providing a mapping to a controlled vocabulary. Although even here the setup could be discussed: >>>> >>>> 1) Why to supply if I can provide @role and @authURI on ? >>>> >>>> >>>> Composer de Jure >>>> Johann Collaborator Bach >>>> ... >>>> >>>> >>>> 2) How to supply the laguage-specific role description that Eleanor pointed out in the discussion? >>>> Is the right place? >>>> >>>> >>>> Komponist >>>> Composer de Jure >>>> >>>> >>>> Apparently not, as it only may have attributes to relate the included string to a controlled vocabulary. >>>> maybe: >>>> >>>> >>>> ... >>>> >>>> >>>> This would make necessary a for each role to be supplied. Which even is a good idea to group multiple names (as seen in preceeding examples by Kristina and Perry ). >>>> The again this would miss someting like @xml:lang which could allowed on if used for a label. >>>> >>>> Then if detailed description is not of primary interest, one could come up with a flat hierarchy: >>>> >>>> >>>> Composer de Jure >>>> Johann Collaborator Bach >>>> ... >>>> >>>> >>>> or: >>>> >>>> >>>> Komponist >>>> Composer de Jure >>>> >>>> >>>> >>>> That's it for now. Sorry for getting lengthy and raising even more questions. >>>> As I'm no metadata expert I see that at some points I might have been too focused on transcription instead of metadata, please excuse ;-) >>>> In expectation of a nice discussion, >>>> >>>> Benjamin >>>> >>>> >>>> Am 05.02.2013 18:23, schrieb Roland, Perry (pdr4h): >>>>> Hello everyone, >>>>> I can see now that my plan to provide and as replacements for TEI's element isn't defensible because it's causing more confusion than it alleviates. So, I suggest that we >>>>> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >>>>> 2. but drop meeting and principal, and >>>>> 3. add arranger, composer, librettist, and lyricist. >>>>> As in TEI, any roles not specifically provided for by this list, such as conductor, encoder, and so on, belong in , for example -- >>>>> >>>>> My Music, Op. 1 >>>>> Composer de Jure >>>>> Johann Collaborator Bach >>>>> Arranger Extraordinaire >>>>> >>>>> Encoders >>>>> [encoder 1] >>>>> [encoder 2] >>>>> >>>>> >>>>> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. >>>>> MARC relator code list (http://www.loc.gov/marc/relators/relaterm.html) provides more than 200 codes/terms for roles, several of which apply to music and musical performances. There's no way we can accommodate them all. So, it makes sense to continue the TEI method of recording those responsible for the *intellectual content* of the work in special elements and relegating other roles to . (I think this actually stems from ISBD and AACR2, not TEI.) >>>>> The addition of these elements *does not* mandate their use; that is, can be used for all responsibilities. The following markup is a valid alternative to the example above: >>>>> >>>>> My Music, Op. 1 >>>>> >>>>> Composer >>>>> Composer de Jure >>>>> Lyricist >>>>> Johann Collaborator Bach >>>>> Arranger >>>>> Arranger Man >>>>> Encoders >>>>> [encoder 1] >>>>> [encoder 2] >>>>> >>>>> >>>>> This form can be easier to produce mechanistically from other encoding schemes and is conformant with forms of cataloging that don't require a "main entry" approach, meaning that it would be easier to transform into one of those systems, such as MODS. >>>>> Also, it's necessary to keep in mind that since is a kind of bibliographic citation, elements used here are also available in (and must also fit within the purpose of) other elements, such as and . >>>>> Best wishes, >>>>> -- >>>>> 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 Eleanor Selfridge-Field [esfield at stanford.edu] >>>>> Sent: Monday, February 04, 2013 4:39 PM >>>>> To: 'Music Encoding Initiative' >>>>> Subject: Re: [MEI-L] Encoding of personal names >>>>> >>>>> Kristina poses interesting questions. Instinctively I would go for ?composer?, ?encoder,? etc and err on the side of being verbose and explicit. With electronic data, being able to track who encoded what (with version number and date) can be very valuable. >>>>> I find labels such as ?creator? and ?corporate name? very unwieldy, particularly when working in a second language (in my case usually Italian). Italian bibliographical databases a full of these kinds of terms, but there is something subtly cultural about the misunderstandings they can create. The various instantiations of a single work can have many creators?a composer, an arranger, and editor, a translator of the text, and in the case of recording a conductor, performer, performing group, etc. Because they can all pertain to a single work, a general label deprives the user of knowing what the role of each one was. >>>>> A much messier area is dating. A single work can have an almost endless number of ?year?s?of composition, publication, first performance, revision <1..n>, arrangement, recording, text translation, etc. There too being more specific saves time for those searching. >>>>> Best regards, >>>>> Eleanor >>>>> Eleanor Selfridge-Field >>>>> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >>>>> Braun Music Center #129 >>>>> Stanford University >>>>> Stanford, CA 94305-3076, USA >>>>> http://www.stanford.edu/~esfield/ >>>>> From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kristina Richts >>>>> Sent: Monday, February 04, 2013 9:55 AM >>>>> To: mei-l at lists.uni-paderborn.de >>>>> Subject: [MEI-L] Encoding of personal names >>>>> Dear all, >>>>> >>>>> during the work on the MEI sample collection, questions appeared on how to encode the creators of each electronic file correctly. >>>>> In MEI2012 the normal path (or better said: the way, we first chose to encode it) was to encode several -elements within the statement of responsibilty. A differentiation between several involved persons only became apparent through additional @role-attributes, i.e. >>>>> >>>>> Anton Webern >>>>> John Doe >>>>> >>>>> >>>>> In a second step we decided not to encode ourselves as "creators" of the file (although we are), but as "encoders" and to assign the composer of the encoded work as creator, i.e. >>>>> >>>>> >>>>> Anton Webern >>>>> John Doe >>>>> >>>>> >>>>> The decision is based on the fact, that we encode the intellectual creation of a composer's work. We tried to keep up the distinction between the composer and the encoder. >>>>> >>>>> MEI2013 will offer some new elements to specify the role of persons, organizations etc. a bit more: , , , and . >>>>> In this regard it is now the question how to encode this best: >>>>> >>>>> >>>>> Anton Webern >>>>> >>>>> >>>>> John Doe >>>>> >>>>> >>>>> >>>>> or >>>>> >>>>> >>>>> >>>>> Anton Webern >>>>> >>>>> >>>>> John Doe >>>>> >>>>> >>>>> ? >>>>> >>>>> We first thought, it would be a good idea, to add a element to the list. But that alone would not be sufficient, as the creative aspect regarding musical works is difficult to manage. In this case, we would rather have to extend the list by adding some more elements like , , etc. But this can soon become very unwieldy. >>>>> >>>>> I have to admit that I don't prefer to encode detailed specifications only within child elements. However, if we choose to maintain the 'more detailed elements', I would at least like to see some mandatory child elements, such as , , etc., in there. >>>>> >>>>> When thinking about all this, I came to the conclusion, that it might be enough to allow a and a element (with some mandatory child elements). I am not even sure, if we should offer a separate element or if an editor should be considered as a contributor as well. >>>>> What is to be said against a specification of the role on the or element? Wouldn't this make things easier to handle for the encoder, who might not know as much about the encoding of persNames with MEI? >>>>> >>>>> Any comments on this? >>>>> >>>>> Best, >>>>> Kristina >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 kristina.richts at gmx.de Thu Feb 7 15:27:40 2013 From: kristina.richts at gmx.de (Kristina Richts) Date: Thu, 07 Feb 2013 15:27:40 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: <51138A70.9070402@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de> Message-ID: <5113B9DB.4040904@gmx.de> Hello, well, I think, this discussion for itself shows the different needs of encoding responsibilities and even one thing more: We can't find a solution for all these needs. So, I vote to keep things as general as possible. Johannes is right that we don't have to draw the line. This is better than drawing it just "somewhere". I can understand Perry's approach to provide and as replacements for . Regarding the FRBR stuff I have worked myself through different cataloguing rules (international as well as national) these days and you can find the separation into these two big groups of responsibilities almost everywhere. It is the question if we want to jump up or just leave it. All in all, the "syntactic sugar" (to speak in your language ;-) ) won't help to make the decision, if someone is "author" or "creator" or whatever, easier. Regarding this, it would be fine to maintain single , etc. elements within the statement of responsibility. The 200 MARC relator terms should provide enough specification (as long as they are used). So, I would support to remove , , , and . By the way: Thanks for the hint, that there is no "encoder" term in the MARC term list for relators ;-) I totally forgot about that, but remember now, this was the reason, why we chose "creator" (instead of "encoder") first... The "markup editor" term is fine. Or "transcriber" (as it is an electronic transcription)? Best, Kristina Am 07.02.2013 12:05, schrieb Benjamin Wolff Bohl: > Only a quick follow up question and response (see inline) > > Am 07.02.2013 10:44, schrieb Johannes Kepper: >> Hi all, >> >> I would really like to get around this can of worms, but I can't >> resist any longer ;-) >> >> All these elements are syntactic sugar ? author, editor, funder, >> sponsor, arranger, composer, librettist and lyricist. Benjamin's >> posting showcases that it is not absolutely clear why we have exactly >> this selection of sugar drops. I for myself feel equally inconvenient >> with it, as does Kristina (if I got her right in a recent discussion >> in Detmold). It seems like drawing a line is easy, but agreeing on >> and justifying that line is less easy. Therefore, my question is >> whether we really need to draw that line. MEI existed without that >> syntactic sugar for quite some time, and I don't remember major >> complains about this as a missing feature. Wouldn't it be much better >> to delegate that to individual projects, which could add their own >> flavor of sugar, and document what they did in their own ODD? (Yes, >> we need better resources for explaining how to actually do that?). > > If I understand this right, you propose not to have these syntactic > sugar elements in the schema but to stick to with > and either or and suggest to add sugar by > referencing corresponding authority codes. > As mentioned before there might be cases where no corresponding > authority code exists (as with encoder in MARC). The I could either > find a different autority or just not supply the authority @s. > > Fine with me - does make processing easier! > Any other opinions on that? > > Now to the next point of discussion: >> >> Regarding the mixed use of and , please note the current >> guidelines, which read on page 25 (chapter 2.1.1: Title Statement): >> >> "While accommodates capturing the wide variety of text that >> may occur in responsibility statements, use of the @role attribute >> provides the possibility of recording a controlled value >> independently of the textual content of . The use of @role is >> required for improved data processability and interchange." >> >> Basically, is used to transcribe the wording in a source, >> whereas @role on the name itself is better suited (and therefore >> recommended) for processing the data. On the following page, there is >> also a reference to the MARC list Benjamin mentioned: >> >> "Values from the MARC relator code list >> (http://www.loc.gov/marc/relators/relacode.html) or term list >> (http://www.loc.gov/marc/relators/relaterm.html) are recommended for >> @role, where applicable." >> >> Of course, this does not solve the starting question, but it >> illustrates that it may occasionally help to read the friendly manual >> ;-) >> Best, >> Johannes > > I completely understand what the guidelines state here but regarding > the schema design for implies that it is meant differently: > When transcribing the wording of the source in what use do > @authority and @authURI have as I cannot supply this info with the > authorities code for that certain type of responsibility, ergo > something similar to @role in would be required, maybe > @dbkey or comparable could fill this gap? > > cheers, > benni > >> >> >> >> >> Am 07.02.2013 um 09:36 schrieb Benjamin Wolff Bohl: >> >>> Hi Kristina and List:eners! >>> In the past few months I've been dealing with the idea of capuring >>> the metadata of published records in MEI and to start out I decided >>> for the harest part ;-) A recording was made publicized and later >>> re-issued on a differnet sound carrier, additional work done by >>> technicians and additional text parts completed this re-issue. >>> As you might imagine, I came across quite a lot of responsibility >>> statements and I find it very convnient to stitch to the MARC code >>> list for Relators. >>> Thus I can understand Perry's idea and might even support to >>> >>>> 1. return to the list provided by TEI -- author, editor, funder, >>>> meeting, principal (as in principal investigator), sponsor, and >>>> respStmt, >>>> 2. but drop meeting and principal, and >>>> 3. add arranger, composer, librettist, and lyricist. >>>> In this scheme, , , , and >>>> for musical compositions are equivalent to for >>>> textual material. The element *should not* be used for >>>> lyricists or librettists. >>> Though making a decision here always weans to draw a line. But where >>> to draw the line? >>> Arranger could still be dropped as his activity might be secondary >>> or even tertiary use of the work. >>> >>> Then on the other hand when moving forward in the publication >>> process more and more persons fill different and nevertheless very >>> important roles. For example, when talking modern times an editor >>> has extensive influence on the gestalt of the publicized/published >>> work. And another very important role is that of the engraver (or >>> typesetter however to call the function in digital times). Now going >>> this road a bit we are very fast to come across someone being the >>> encoder, as depending on workflow and technologies used, encoding >>> and setting the music might overlap at some point. >>> >>> And for me this is an essential question that can be drawn from >>> Kristina's post. Oe could even discuss of putting the encoder as >>> or in as is not about the >>> music but about the encoded data (although opening another question >>> with this...). And this is where the encoder has primary and >>> extensive influence. And, if I'm not mistaken, there is no MARC code >>> for this! >>> **Thus I would propose of having such an element to compensate this!** >>> >>> Another thing that has come to me - opening yet another bottle - is >>> the encoding that Perry's second example shows, as I came across >>> this in my metadata. >>> >>>> titleStmt> >>>> My Music, Op. 1 >>>> >>>> Composer >>>> Composer de Jure >>>> Lyricist >>>> Johann Collaborator Bach >>>> Arranger >>>> Arranger Man >>>> Encoders >>>> [encoder 1] >>>> [encoder 2] >>>> >>>> >>> Although straightforward the content of leaves me with a >>> shudder, as no explicit mapping of and is to be >>> observed. I would very much prefer to see something like this: >>> >>> >>> Composer >>> Composer de Jure >>> >>> >>> Lyricist >>> Johann Collaborator Bach >>> >>> >>> Arranger >>> Arranger Man >>> >>> >>> Encoders >>> [encoder 1] >>> [encoder 2] >>> >>> >>> Adding some MARC relator code either in @role on or in >>> with the corresponding @authURI would be helpful since >>> providing a mapping to a controlled vocabulary. Although even here >>> the setup could be discussed: >>> >>> 1) Why to supply if I can provide @role and @authURI on >>> ? >>> >>> >>> Composer de >>> Jure >>> Johann Collaborator >>> Bach >>> ... >>> >>> >>> 2) How to supply the laguage-specific role description that Eleanor >>> pointed out in the discussion? >>> Is the right place? >>> >>> >>> Komponist >>> Composer de Jure >>> >>> >>> Apparently not, as it only may have attributes to relate the >>> included string to a controlled vocabulary. >>> maybe: >>> >>> >>> ... >>> >>> >>> This would make necessary a for each role to be supplied. >>> Which even is a good idea to group multiple names (as seen in >>> preceeding examples by Kristina and Perry ). >>> The again this would miss someting like @xml:lang which could >>> allowed on if used for a label. >>> >>> Then if detailed description is not of primary interest, one could >>> come up with a flat hierarchy: >>> >>> >>> Composer de >>> Jure >>> Johann Collaborator >>> Bach >>> ... >>> >>> >>> or: >>> >>> >>> Komponist >>> Composer de Jure >>> >>> >>> >>> That's it for now. Sorry for getting lengthy and raising even more >>> questions. >>> As I'm no metadata expert I see that at some points I might have >>> been too focused on transcription instead of metadata, please excuse >>> ;-) >>> In expectation of a nice discussion, >>> >>> Benjamin >>> >>> >>> Am 05.02.2013 18:23, schrieb Roland, Perry (pdr4h): >>>> Hello everyone, >>>> I can see now that my plan to provide and >>>> as replacements for TEI's element isn't defensible because >>>> it's causing more confusion than it alleviates. So, I suggest that we >>>> 1. return to the list provided by TEI -- author, editor, funder, >>>> meeting, principal (as in principal investigator), sponsor, and >>>> respStmt, >>>> 2. but drop meeting and principal, and >>>> 3. add arranger, composer, librettist, and lyricist. >>>> As in TEI, any roles not specifically provided for by this list, >>>> such as conductor, encoder, and so on, belong in , for >>>> example -- >>>> >>>> My Music, Op. 1 >>>> Composer de Jure >>>> Johann Collaborator Bach >>>> Arranger Extraordinaire >>>> >>>> Encoders >>>> [encoder 1] >>>> [encoder 2] >>>> >>>> >>>> In this scheme, , , , and >>>> for musical compositions are equivalent to for >>>> textual material. The element *should not* be used for >>>> lyricists or librettists. >>>> MARC relator code list >>>> (http://www.loc.gov/marc/relators/relaterm.html) provides more than >>>> 200 codes/terms for roles, several of which apply to music and >>>> musical performances. There's no way we can accommodate them all. >>>> So, it makes sense to continue the TEI method of recording those >>>> responsible for the *intellectual content* of the work in special >>>> elements and relegating other roles to . (I think this >>>> actually stems from ISBD and AACR2, not TEI.) >>>> The addition of these elements *does not* mandate their use; that >>>> is, can be used for all responsibilities. The following >>>> markup is a valid alternative to the example above: >>>> >>>> My Music, Op. 1 >>>> >>>> Composer >>>> Composer de Jure >>>> Lyricist >>>> Johann Collaborator Bach >>>> Arranger >>>> Arranger Man >>>> Encoders >>>> [encoder 1] >>>> [encoder 2] >>>> >>>> >>>> This form can be easier to produce mechanistically from other >>>> encoding schemes and is conformant with forms of cataloging that >>>> don't require a "main entry" approach, meaning that it would be >>>> easier to transform into one of those systems, such as MODS. >>>> Also, it's necessary to keep in mind that since is a >>>> kind of bibliographic citation, elements used here are also >>>> available in (and must also fit within the purpose of) other >>>> elements, such as and . >>>> Best wishes, >>>> -- >>>> 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 Eleanor >>>> Selfridge-Field [esfield at stanford.edu] >>>> Sent: Monday, February 04, 2013 4:39 PM >>>> To: 'Music Encoding Initiative' >>>> Subject: Re: [MEI-L] Encoding of personal names >>>> >>>> Kristina poses interesting questions. Instinctively I would go for >>>> ?composer?, ?encoder,? etc and err on the side of being verbose and >>>> explicit. With electronic data, being able to track who encoded >>>> what (with version number and date) can be very valuable. >>>> I find labels such as ?creator? and ?corporate name? very >>>> unwieldy, particularly when working in a second language (in my >>>> case usually Italian). Italian bibliographical databases a full of >>>> these kinds of terms, but there is something subtly cultural about >>>> the misunderstandings they can create. The various instantiations >>>> of a single work can have many creators?a composer, an arranger, >>>> and editor, a translator of the text, and in the case of recording >>>> a conductor, performer, performing group, etc. Because they can all >>>> pertain to a single work, a general label deprives the user of >>>> knowing what the role of each one was. >>>> A much messier area is dating. A single work can have an almost >>>> endless number of ?year?s?of composition, publication, first >>>> performance, revision <1..n>, arrangement, recording, text >>>> translation, etc. There too being more specific saves time for >>>> those searching. >>>> Best regards, >>>> Eleanor >>>> Eleanor Selfridge-Field >>>> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >>>> Braun Music Center #129 >>>> Stanford University >>>> Stanford, CA 94305-3076, USA >>>> http://www.stanford.edu/~esfield/ >>>> From: mei-l-bounces at lists.uni-paderborn.de >>>> [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kristina >>>> Richts >>>> Sent: Monday, February 04, 2013 9:55 AM >>>> To: mei-l at lists.uni-paderborn.de >>>> Subject: [MEI-L] Encoding of personal names >>>> Dear all, >>>> >>>> during the work on the MEI sample collection, questions appeared on >>>> how to encode the creators of each electronic file correctly. >>>> In MEI2012 the normal path (or better said: the way, we first chose >>>> to encode it) was to encode several -elements within the >>>> statement of responsibilty. A differentiation between several >>>> involved persons only became apparent through additional >>>> @role-attributes, i.e. >>>> >>>> Anton Webern >>>> John Doe >>>> >>>> >>>> In a second step we decided not to encode ourselves as "creators" >>>> of the file (although we are), but as "encoders" and to assign the >>>> composer of the encoded work as creator, i.e. >>>> >>>> >>>> Anton Webern >>>> John Doe >>>> >>>> >>>> The decision is based on the fact, that we encode the intellectual >>>> creation of a composer's work. We tried to keep up the distinction >>>> between the composer and the encoder. >>>> >>>> MEI2013 will offer some new elements to specify the role of >>>> persons, organizations etc. a bit more: , , >>>> , and . >>>> In this regard it is now the question how to encode this best: >>>> >>>> >>>> Anton Webern >>>> >>>> >>>> John Doe >>>> >>>> >>>> >>>> or >>>> >>>> >>>> >>>> Anton Webern >>>> >>>> >>>> John Doe >>>> >>>> >>>> ? >>>> >>>> We first thought, it would be a good idea, to add a >>>> element to the list. But that alone would not be sufficient, as the >>>> creative aspect regarding musical works is difficult to manage. In >>>> this case, we would rather have to extend the list by adding some >>>> more elements like , , etc. But this can soon >>>> become very unwieldy. >>>> >>>> I have to admit that I don't prefer to encode detailed >>>> specifications only within child elements. However, if we choose to >>>> maintain the 'more detailed elements', I would at least like to see >>>> some mandatory child elements, such as , , >>>> etc., in there. >>>> >>>> When thinking about all this, I came to the conclusion, that it >>>> might be enough to allow a and a element >>>> (with some mandatory child elements). I am not even sure, if we >>>> should offer a separate element or if an editor should be >>>> considered as a contributor as well. >>>> What is to be said against a specification of the role on the >>>> or element? Wouldn't this make things >>>> easier to handle for the encoder, who might not know as much about >>>> the encoding of persNames with MEI? >>>> >>>> Any comments on this? >>>> >>>> Best, >>>> Kristina >>>> >>>> >>>> _______________________________________________ >>>> 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: From pdr4h at eservices.virginia.edu Thu Feb 7 17:08:07 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 7 Feb 2013 16:08:07 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: <5113B090.5050906@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de> <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de>, <5113B090.5050906@edirom.de> Message-ID: Greetings, MEI-ers! (Or are we all collectively "MEI-onaisse"?) A bit o' history first: The addition of these so-called "syntactic sugar" elements to came about as a result of revision of the element. In they're not sugary, but meaty. :-) In other words, they provide for marking the component parts of bibliographic citations. Using exclusively in bibliographic citations would require re-ordering the citation's components, which is not acceptable if you're trying to capture the original citation. But making them available in raises the question of allowing them in . Following TEI's lead, I chose to allow them. There's nothing technically wrong with choosing not to use them in fileDesc/titleStmt, although in keeping with the traditional method of bibliographic description discussed below, I recommend their use. They're not just sugar; they permit (encourage, even) traditional bibliographic description. While there's no way to enforce it (and I don't think we want to), Benni's preference for explicit grouping of and name-like elements -- My Composition Composer Composer de Jure Lyricist Johann Collaborator Bach Arranger Arranger Man Encoders [encoder 1] [encoder 2] is allowed. In fact, this is the only way to achieve grouping of and one or more names. In addition, as I said before, this method "leans toward" cataloging schemes, such as MODS, that don't privilege one role (say, composer) over another (like encoder). However, the more traditional way to encode this example is -- My Composition Composer de Jure Johann Collaborator Bach Arranger Man Encoders [encoder 1] [encoder 2] This creates an explicit mapping between certain common roles and names, but relegates others to a secondary position (within respStmt). >And for me this is an essential question that can be drawn from Kristina's post. Oe could even discuss of putting the encoder as or > in as is not about the music but about the encoded data (although opening another question with this...). > And this is where the encoder has primary and extensive influence. And, if I'm not mistaken, there is no MARC code for this! > **Thus I would propose of having such an element to compensate this!** For better or worse, the traditional method of describing edited (and by extension encoded) publications is to keep the original creator as the creator of the new publication and add descriptions for contributing authors. For example, Principles of orchestration, with musical examples drawn from his own works [by] Nikolay Rimsky-Korsakov. Edited by Maximilian Steinberg. English translation by Edward Agate. While an encoder "creates" the encoding, just as Steinberg was presumably the "creator" of a notebook full of revisions, he/she is not the creator of the work. One could argue that this approach is "old-fashioned", but it's the one most people have come to expect. If the encoder has "primary and extensive influence", then I would argue that makes him an "editor", not merely an "encoder". So, I would capture this as -- My Composition Composer de Jure Johann Collaborator Bach Arranger Man Kristina Richts and Maja Hartwig or, in order to capture the all-important "edited by" string, -- My Composition Composer de Jure Johann Collaborator Bach Arranger Man Edited by Kristina Richts Maja Hartwig Though I think it would cause other problems that I won't discuss now (and therefore I don't recommend it), one could even go as far as -- My Composition Edited by Kristina Richts Maja Hartwig leaving the description of the work to . > 1) Why to supply if I can provide @role and @authURI on ? > > > Composer de Jure > Johann Collaborator Bach > ... > While strictly legal according to the schema, is nonsensical without . It's legal because it's impossible to control both order and number of the child and name-like elements. To accommodate the widest range of order and number, all the children of have to be allowed to occur zero or more times, but that doesn't mean that can ever be left out. A schematron rule should probably be added to require at least one . This makes @role on respStmt/persName unnecessary. @authURI is intended to capture a reference to an authorized value *for the content of the element*, in this case "Composer de Jure", not the value of @role. If it's necessary to capture a reference to the source of the value of @role, use instead -- Composer Composer de Jure Currently, there's no way to put an un-authorized value in and then point to an authority for what the value "ought to be". The following isn't kosher because "Komponist" doesn't exist in the MARC relator list -- Komponist Composer de Jure > 2) How to supply the laguage-specific role description that Eleanor pointed out in the discussion? > Is the right place? I'm not sure I understand what you're getting at here. But, I agree that xml:lang should be added to . And to so that one could write -- Komponist Martin Luther Composerus Martinus Lutheraneuns and choose the desired language later. While I'm all for MEI doing something different when it's necessary, I also think it's important to employ those things (in this case, traditional bibliographic description principals and the markup of such things in TEI) which have a long history of usefulness. Best wishes, -- 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 pdr4h at eservices.virginia.edu Thu Feb 7 17:48:51 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 7 Feb 2013 16:48:51 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> Message-ID: Dear MEI-oneers, Johannes asked: > Wouldn't it be much better to delegate that to individual projects, which could add their own flavor of sugar, and document what they did in > their own ODD? In this particular case, I do not believe it would be better to abandon individual projects to their own devices. It's good to provide as much guidance as possible, even when there's more than one way of doing something. It's better to say "you can do X, Y, or Z" than to say "you can do X or you can make up something entirely different from everyone else". In that case, every project would add to the Babel we created by not allowing enough flexibility. >> If I understand this right, you propose not to have these syntactic sugar elements in the schema but to stick to with and >> either or and suggest to add sugar by referencing corresponding authority codes. I addressed this in my earlier message -- you can choose not to use the explicit elements within , but others will prefer the opposite course and so the elements should be left in. I object to authority references as "sugar", but your suggestion to use is correct. :-) As I suggested before, at least one should be required (by a schematron rule) when is employed. > I am not sure about the use of @authURI and @authority on , as this is clearly meant for plain text. But you're right, we should > either add @code or @dbkey, or remove the other attributes as well. The @authURI and @authority attributes are meant for text, which the value of is, correct? Allowing @code on is a good plan, I think. But, it is intended to provide one or more standard values *that correspond to the content of the element*. I'm less sure about its use when it contradicts/augments the element content, as in -- Komponist because, as I said earlier, "Komponist" doesn't exist in the MARC relator code list. And there might be better ways of expressing the relationship between "Komponist" and "composer" than we're thinking of just now. I'm even less sure about the usefullness of @dbkey, but willing to be convinced. :-) Cheers, -- 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: Thursday, February 07, 2013 8:03 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names Am 07.02.2013 um 12:05 schrieb Benjamin Wolff Bohl: > Only a quick follow up question and response (see inline) > > Am 07.02.2013 10:44, schrieb Johannes Kepper: >> Hi all, >> >> I would really like to get around this can of worms, but I can't resist any longer ;-) >> >> All these elements are syntactic sugar ? author, editor, funder, sponsor, arranger, composer, librettist and lyricist. Benjamin's posting showcases that it is not absolutely clear why we have exactly this selection of sugar drops. I for myself feel equally inconvenient with it, as does Kristina (if I got her right in a recent discussion in Detmold). It seems like drawing a line is easy, but agreeing on and justifying that line is less easy. Therefore, my question is whether we really need to draw that line. MEI existed without that syntactic sugar for quite some time, and I don't remember major complains about this as a missing feature. Wouldn't it be much better to delegate that to individual projects, which could add their own flavor of sugar, and document what they did in their own ODD? (Yes, we need better resources for explaining how to actually do that?). > > If I understand this right, you propose not to have these syntactic sugar elements in the schema but to stick to with and either or and suggest to add sugar by referencing corresponding authority codes. > As mentioned before there might be cases where no corresponding authority code exists (as with encoder in MARC). The I could either find a different autority or just not supply the authority @s. Taken from the MARC list: Markup editor [mrk] Use for a person or organization performing the coding of SGML, HTML, or XML markup of metadata, text, etc. Metadata contact [mdc] Use for a person or organization primarily responsible for compiling and maintaining the original description of a metadata set (e.g., geospatial metadata set). Data contributor [dtc] Use for a person or organization that submits data for inclusion in a database or other collection of data. Data manager [dtm] Use for a person or organization responsible for managing databases or other data sources. Analyst [anl] Use for a person or organization that reviews, examines and interprets data or information in a specific area. ---- Not all of them are useful all the time, but it's actually hard to find something not taken care of by the MARC list. You sometimes have to twist it's arm, as everything is focussed on physical media, but you're likely to find something. > > Fine with me - does make processing easier! > Any other opinions on that? > > Now to the next point of discussion: >> >> Regarding the mixed use of and , please note the current guidelines, which read on page 25 (chapter 2.1.1: Title Statement): >> >> "While accommodates capturing the wide variety of text that may occur in responsibility statements, use of the @role attribute provides the possibility of recording a controlled value independently of the textual content of . The use of @role is required for improved data processability and interchange." >> >> Basically, is used to transcribe the wording in a source, whereas @role on the name itself is better suited (and therefore recommended) for processing the data. On the following page, there is also a reference to the MARC list Benjamin mentioned: >> >> "Values from the MARC relator code list (http://www.loc.gov/marc/relators/relacode.html) or term list (http://www.loc.gov/marc/relators/relaterm.html) are recommended for @role, where applicable." >> >> Of course, this does not solve the starting question, but it illustrates that it may occasionally help to read the friendly manual ;-) >> Best, >> Johannes > > I completely understand what the guidelines state here but regarding the schema design for implies that it is meant differently: > When transcribing the wording of the source in what use do @authority and @authURI have as I cannot supply this info with the authorities code for that certain type of responsibility, ergo something similar to @role in would be required, maybe @dbkey or comparable could fill this gap? I am not sure about the use of @authURI and @authority on , as this is clearly meant for plain text. But you're right, we should either add @code or @dbkey, or remove the other attributes as well. Best, Johannes > > cheers, > benni > >> >> >> >> >> Am 07.02.2013 um 09:36 schrieb Benjamin Wolff Bohl: >> >>> Hi Kristina and List:eners! >>> In the past few months I've been dealing with the idea of capuring the metadata of published records in MEI and to start out I decided for the harest part ;-) A recording was made publicized and later re-issued on a differnet sound carrier, additional work done by technicians and additional text parts completed this re-issue. >>> As you might imagine, I came across quite a lot of responsibility statements and I find it very convnient to stitch to the MARC code list for Relators. >>> Thus I can understand Perry's idea and might even support to >>> >>>> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >>>> 2. but drop meeting and principal, and >>>> 3. add arranger, composer, librettist, and lyricist. >>>> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. >>> Though making a decision here always weans to draw a line. But where to draw the line? >>> Arranger could still be dropped as his activity might be secondary or even tertiary use of the work. >>> >>> Then on the other hand when moving forward in the publication process more and more persons fill different and nevertheless very important roles. For example, when talking modern times an editor has extensive influence on the gestalt of the publicized/published work. And another very important role is that of the engraver (or typesetter however to call the function in digital times). Now going this road a bit we are very fast to come across someone being the encoder, as depending on workflow and technologies used, encoding and setting the music might overlap at some point. >>> >>> And for me this is an essential question that can be drawn from Kristina's post. Oe could even discuss of putting the encoder as or in as is not about the music but about the encoded data (although opening another question with this...). And this is where the encoder has primary and extensive influence. And, if I'm not mistaken, there is no MARC code for this! >>> **Thus I would propose of having such an element to compensate this!** >>> >>> Another thing that has come to me - opening yet another bottle - is the encoding that Perry's second example shows, as I came across this in my metadata. >>> >>>> titleStmt> >>>> My Music, Op. 1 >>>> >>>> Composer >>>> Composer de Jure >>>> Lyricist >>>> Johann Collaborator Bach >>>> Arranger >>>> Arranger Man >>>> Encoders >>>> [encoder 1] >>>> [encoder 2] >>>> >>>> >>> Although straightforward the content of leaves me with a shudder, as no explicit mapping of and is to be observed. I would very much prefer to see something like this: >>> >>> >>> Composer >>> Composer de Jure >>> >>> >>> Lyricist >>> Johann Collaborator Bach >>> >>> >>> Arranger >>> Arranger Man >>> >>> >>> Encoders >>> [encoder 1] >>> [encoder 2] >>> >>> >>> Adding some MARC relator code either in @role on or in with the corresponding @authURI would be helpful since providing a mapping to a controlled vocabulary. Although even here the setup could be discussed: >>> >>> 1) Why to supply if I can provide @role and @authURI on ? >>> >>> >>> Composer de Jure >>> Johann Collaborator Bach >>> ... >>> >>> >>> 2) How to supply the laguage-specific role description that Eleanor pointed out in the discussion? >>> Is the right place? >>> >>> >>> Komponist >>> Composer de Jure >>> >>> >>> Apparently not, as it only may have attributes to relate the included string to a controlled vocabulary. >>> maybe: >>> >>> >>> ... >>> >>> >>> This would make necessary a for each role to be supplied. Which even is a good idea to group multiple names (as seen in preceeding examples by Kristina and Perry ). >>> The again this would miss someting like @xml:lang which could allowed on if used for a label. >>> >>> Then if detailed description is not of primary interest, one could come up with a flat hierarchy: >>> >>> >>> Composer de Jure >>> Johann Collaborator Bach >>> ... >>> >>> >>> or: >>> >>> >>> Komponist >>> Composer de Jure >>> >>> >>> >>> That's it for now. Sorry for getting lengthy and raising even more questions. >>> As I'm no metadata expert I see that at some points I might have been too focused on transcription instead of metadata, please excuse ;-) >>> In expectation of a nice discussion, >>> >>> Benjamin >>> >>> >>> Am 05.02.2013 18:23, schrieb Roland, Perry (pdr4h): >>>> Hello everyone, >>>> I can see now that my plan to provide and as replacements for TEI's element isn't defensible because it's causing more confusion than it alleviates. So, I suggest that we >>>> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >>>> 2. but drop meeting and principal, and >>>> 3. add arranger, composer, librettist, and lyricist. >>>> As in TEI, any roles not specifically provided for by this list, such as conductor, encoder, and so on, belong in , for example -- >>>> >>>> My Music, Op. 1 >>>> Composer de Jure >>>> Johann Collaborator Bach >>>> Arranger Extraordinaire >>>> >>>> Encoders >>>> [encoder 1] >>>> [encoder 2] >>>> >>>> >>>> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. >>>> MARC relator code list (http://www.loc.gov/marc/relators/relaterm.html) provides more than 200 codes/terms for roles, several of which apply to music and musical performances. There's no way we can accommodate them all. So, it makes sense to continue the TEI method of recording those responsible for the *intellectual content* of the work in special elements and relegating other roles to . (I think this actually stems from ISBD and AACR2, not TEI.) >>>> The addition of these elements *does not* mandate their use; that is, can be used for all responsibilities. The following markup is a valid alternative to the example above: >>>> >>>> My Music, Op. 1 >>>> >>>> Composer >>>> Composer de Jure >>>> Lyricist >>>> Johann Collaborator Bach >>>> Arranger >>>> Arranger Man >>>> Encoders >>>> [encoder 1] >>>> [encoder 2] >>>> >>>> >>>> This form can be easier to produce mechanistically from other encoding schemes and is conformant with forms of cataloging that don't require a "main entry" approach, meaning that it would be easier to transform into one of those systems, such as MODS. >>>> Also, it's necessary to keep in mind that since is a kind of bibliographic citation, elements used here are also available in (and must also fit within the purpose of) other elements, such as and . >>>> Best wishes, >>>> -- >>>> 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 Eleanor Selfridge-Field [esfield at stanford.edu] >>>> Sent: Monday, February 04, 2013 4:39 PM >>>> To: 'Music Encoding Initiative' >>>> Subject: Re: [MEI-L] Encoding of personal names >>>> >>>> Kristina poses interesting questions. Instinctively I would go for ?composer?, ?encoder,? etc and err on the side of being verbose and explicit. With electronic data, being able to track who encoded what (with version number and date) can be very valuable. >>>> I find labels such as ?creator? and ?corporate name? very unwieldy, particularly when working in a second language (in my case usually Italian). Italian bibliographical databases a full of these kinds of terms, but there is something subtly cultural about the misunderstandings they can create. The various instantiations of a single work can have many creators?a composer, an arranger, and editor, a translator of the text, and in the case of recording a conductor, performer, performing group, etc. Because they can all pertain to a single work, a general label deprives the user of knowing what the role of each one was. >>>> A much messier area is dating. A single work can have an almost endless number of ?year?s?of composition, publication, first performance, revision <1..n>, arrangement, recording, text translation, etc. There too being more specific saves time for those searching. >>>> Best regards, >>>> Eleanor >>>> Eleanor Selfridge-Field >>>> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >>>> Braun Music Center #129 >>>> Stanford University >>>> Stanford, CA 94305-3076, USA >>>> http://www.stanford.edu/~esfield/ >>>> From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kristina Richts >>>> Sent: Monday, February 04, 2013 9:55 AM >>>> To: mei-l at lists.uni-paderborn.de >>>> Subject: [MEI-L] Encoding of personal names >>>> Dear all, >>>> >>>> during the work on the MEI sample collection, questions appeared on how to encode the creators of each electronic file correctly. >>>> In MEI2012 the normal path (or better said: the way, we first chose to encode it) was to encode several -elements within the statement of responsibilty. A differentiation between several involved persons only became apparent through additional @role-attributes, i.e. >>>> >>>> Anton Webern >>>> John Doe >>>> >>>> >>>> In a second step we decided not to encode ourselves as "creators" of the file (although we are), but as "encoders" and to assign the composer of the encoded work as creator, i.e. >>>> >>>> >>>> Anton Webern >>>> John Doe >>>> >>>> >>>> The decision is based on the fact, that we encode the intellectual creation of a composer's work. We tried to keep up the distinction between the composer and the encoder. >>>> >>>> MEI2013 will offer some new elements to specify the role of persons, organizations etc. a bit more: , , , and . >>>> In this regard it is now the question how to encode this best: >>>> >>>> >>>> Anton Webern >>>> >>>> >>>> John Doe >>>> >>>> >>>> >>>> or >>>> >>>> >>>> >>>> Anton Webern >>>> >>>> >>>> John Doe >>>> >>>> >>>> ? >>>> >>>> We first thought, it would be a good idea, to add a element to the list. But that alone would not be sufficient, as the creative aspect regarding musical works is difficult to manage. In this case, we would rather have to extend the list by adding some more elements like , , etc. But this can soon become very unwieldy. >>>> >>>> I have to admit that I don't prefer to encode detailed specifications only within child elements. However, if we choose to maintain the 'more detailed elements', I would at least like to see some mandatory child elements, such as , , etc., in there. >>>> >>>> When thinking about all this, I came to the conclusion, that it might be enough to allow a and a element (with some mandatory child elements). I am not even sure, if we should offer a separate element or if an editor should be considered as a contributor as well. >>>> What is to be said against a specification of the role on the or element? Wouldn't this make things easier to handle for the encoder, who might not know as much about the encoding of persNames with MEI? >>>> >>>> Any comments on this? >>>> >>>> Best, >>>> Kristina >>>> >>>> >>>> _______________________________________________ >>>> 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 Thu Feb 7 18:05:42 2013 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 7 Feb 2013 18:05:42 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> Message-ID: <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> Ah, here are the worms, freshly served from the foothills of the blue ridge mountains ;-) Perry, honestly, I remember myriads of discussions about this, and you still have this tendency of relapsing. First, what I miss in your post is an example of these elements in the context of . You mention this is the meatful part, but only telling us about the food makes us hungry, not well-fed (and convinced). It's not that I don't see the usefulness of these elements, it's just that I don't see a clear line where to stop when adding these elements. I also totally agree that is useful (for transcribing sources), although I see no difference about this in and . I think the distinction we made (after passing the long and wormy road of discussion?) is pretty useful: for the texty part of a description, @code on names for processing. Requiring may be useful for certain , like inside a , but what do you plan to transcribe in the fileDesc/titleStmt/respStmt? This about an electronic resource, and it is by definition the file your operating in. You're about to transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. The benefit of Komponist comes into play when you add @xml:lang to this. But the current Guidelines recommend to use komponiert von, not the proper noun. As I said, I see a benefit in etc., but I would really like to restrict these elements as much as possible. There is some risk down that road ? I see MEI having to deal with the same philosophical questions TEI has stumbled over, namely the discussion about the distinction between persNames and persons. Don't you see a chance for s to stay ignorant about this? Only because they have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? Yes, it uses a slightly different model, but it actually contains the same information. If you really feel a need for those elements, I would like to draw the shortest possible line, allowing only the most convincing elements. But who should identify them? I would like to hear Axel's take on all this? Best, Johannes Am 07.02.2013 um 17:48 schrieb Roland, Perry (pdr4h): > Dear MEI-oneers, > > Johannes asked: > >> Wouldn't it be much better to delegate that to individual projects, which could add their own flavor of sugar, and document what they did in > their own ODD? > > In this particular case, I do not believe it would be better to abandon individual projects to their own devices. It's good to provide as much guidance as possible, even when there's more than one way of doing something. It's better to say "you can do X, Y, or Z" than to say "you can do X or you can make up something entirely different from everyone else". In that case, every project would add to the Babel we created by not allowing enough flexibility. > >>> If I understand this right, you propose not to have these syntactic sugar elements in the schema but to stick to with and >>> either or and suggest to add sugar by referencing corresponding authority codes. > > I addressed this in my earlier message -- you can choose not to use the explicit elements within , but others will prefer the opposite course and so the elements should be left in. I object to authority references as "sugar", but your suggestion to use is correct. :-) As I suggested before, at least one should be required (by a schematron rule) when is employed. > >> I am not sure about the use of @authURI and @authority on , as this is clearly meant for plain text. But you're right, we should >> either add @code or @dbkey, or remove the other attributes as well. > > The @authURI and @authority attributes are meant for text, which the value of is, correct? Allowing @code on is a good plan, I think. But, it is intended to provide one or more standard values *that correspond to the content of the element*. I'm less sure about its use when it contradicts/augments the element content, as in -- > > Komponist > > because, as I said earlier, "Komponist" doesn't exist in the MARC relator code list. And there might be better ways of expressing the relationship between "Komponist" and "composer" than we're thinking of just now. > > I'm even less sure about the usefullness of @dbkey, but willing to be convinced. :-) > > Cheers, > > -- > 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: Thursday, February 07, 2013 8:03 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Am 07.02.2013 um 12:05 schrieb Benjamin Wolff Bohl: > >> Only a quick follow up question and response (see inline) >> >> Am 07.02.2013 10:44, schrieb Johannes Kepper: >>> Hi all, >>> >>> I would really like to get around this can of worms, but I can't resist any longer ;-) >>> >>> All these elements are syntactic sugar ? author, editor, funder, sponsor, arranger, composer, librettist and lyricist. Benjamin's posting showcases that it is not absolutely clear why we have exactly this selection of sugar drops. I for myself feel equally inconvenient with it, as does Kristina (if I got her right in a recent discussion in Detmold). It seems like drawing a line is easy, but agreeing on and justifying that line is less easy. Therefore, my question is whether we really need to draw that line. MEI existed without that syntactic sugar for quite some time, and I don't remember major complains about this as a missing feature. Wouldn't it be much better to delegate that to individual projects, which could add their own flavor of sugar, and document what they did in their own ODD? (Yes, we need better resources for explaining how to actually do that?). >> >> If I understand this right, you propose not to have these syntactic sugar elements in the schema but to stick to with and either or and suggest to add sugar by referencing corresponding authority codes. >> As mentioned before there might be cases where no corresponding authority code exists (as with encoder in MARC). The I could either find a different autority or just not supply the authority @s. > > Taken from the MARC list: > > Markup editor [mrk] > Use for a person or organization performing the coding of SGML, HTML, or XML markup of metadata, text, etc. > > Metadata contact [mdc] > Use for a person or organization primarily responsible for compiling and maintaining the original description of a metadata set (e.g., geospatial metadata set). > > Data contributor [dtc] > Use for a person or organization that submits data for inclusion in a database or other collection of data. > > Data manager [dtm] > Use for a person or organization responsible for managing databases or other data sources. > > Analyst [anl] > Use for a person or organization that reviews, examines and interprets data or information in a specific area. > > ---- > > Not all of them are useful all the time, but it's actually hard to find something not taken care of by the MARC list. You sometimes have to twist it's arm, as everything is focussed on physical media, but you're likely to find something. > >> >> Fine with me - does make processing easier! >> Any other opinions on that? >> >> Now to the next point of discussion: >>> >>> Regarding the mixed use of and , please note the current guidelines, which read on page 25 (chapter 2.1.1: Title Statement): >>> >>> "While accommodates capturing the wide variety of text that may occur in responsibility statements, use of the @role attribute provides the possibility of recording a controlled value independently of the textual content of . The use of @role is required for improved data processability and interchange." >>> >>> Basically, is used to transcribe the wording in a source, whereas @role on the name itself is better suited (and therefore recommended) for processing the data. On the following page, there is also a reference to the MARC list Benjamin mentioned: >>> >>> "Values from the MARC relator code list (http://www.loc.gov/marc/relators/relacode.html) or term list (http://www.loc.gov/marc/relators/relaterm.html) are recommended for @role, where applicable." >>> >>> Of course, this does not solve the starting question, but it illustrates that it may occasionally help to read the friendly manual ;-) >>> Best, >>> Johannes >> >> I completely understand what the guidelines state here but regarding the schema design for implies that it is meant differently: >> When transcribing the wording of the source in what use do @authority and @authURI have as I cannot supply this info with the authorities code for that certain type of responsibility, ergo something similar to @role in would be required, maybe @dbkey or comparable could fill this gap? > > I am not sure about the use of @authURI and @authority on , as this is clearly meant for plain text. But you're right, we should either add @code or @dbkey, or remove the other attributes as well. > > Best, > Johannes > >> >> cheers, >> benni >> >>> >>> >>> >>> >>> Am 07.02.2013 um 09:36 schrieb Benjamin Wolff Bohl: >>> >>>> Hi Kristina and List:eners! >>>> In the past few months I've been dealing with the idea of capuring the metadata of published records in MEI and to start out I decided for the harest part ;-) A recording was made publicized and later re-issued on a differnet sound carrier, additional work done by technicians and additional text parts completed this re-issue. >>>> As you might imagine, I came across quite a lot of responsibility statements and I find it very convnient to stitch to the MARC code list for Relators. >>>> Thus I can understand Perry's idea and might even support to >>>> >>>>> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >>>>> 2. but drop meeting and principal, and >>>>> 3. add arranger, composer, librettist, and lyricist. >>>>> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. >>>> Though making a decision here always weans to draw a line. But where to draw the line? >>>> Arranger could still be dropped as his activity might be secondary or even tertiary use of the work. >>>> >>>> Then on the other hand when moving forward in the publication process more and more persons fill different and nevertheless very important roles. For example, when talking modern times an editor has extensive influence on the gestalt of the publicized/published work. And another very important role is that of the engraver (or typesetter however to call the function in digital times). Now going this road a bit we are very fast to come across someone being the encoder, as depending on workflow and technologies used, encoding and setting the music might overlap at some point. >>>> >>>> And for me this is an essential question that can be drawn from Kristina's post. Oe could even discuss of putting the encoder as or in as is not about the music but about the encoded data (although opening another question with this...). And this is where the encoder has primary and extensive influence. And, if I'm not mistaken, there is no MARC code for this! >>>> **Thus I would propose of having such an element to compensate this!** >>>> >>>> Another thing that has come to me - opening yet another bottle - is the encoding that Perry's second example shows, as I came across this in my metadata. >>>> >>>>> titleStmt> >>>>> My Music, Op. 1 >>>>> >>>>> Composer >>>>> Composer de Jure >>>>> Lyricist >>>>> Johann Collaborator Bach >>>>> Arranger >>>>> Arranger Man >>>>> Encoders >>>>> [encoder 1] >>>>> [encoder 2] >>>>> >>>>> >>>> Although straightforward the content of leaves me with a shudder, as no explicit mapping of and is to be observed. I would very much prefer to see something like this: >>>> >>>> >>>> Composer >>>> Composer de Jure >>>> >>>> >>>> Lyricist >>>> Johann Collaborator Bach >>>> >>>> >>>> Arranger >>>> Arranger Man >>>> >>>> >>>> Encoders >>>> [encoder 1] >>>> [encoder 2] >>>> >>>> >>>> Adding some MARC relator code either in @role on or in with the corresponding @authURI would be helpful since providing a mapping to a controlled vocabulary. Although even here the setup could be discussed: >>>> >>>> 1) Why to supply if I can provide @role and @authURI on ? >>>> >>>> >>>> Composer de Jure >>>> Johann Collaborator Bach >>>> ... >>>> >>>> >>>> 2) How to supply the laguage-specific role description that Eleanor pointed out in the discussion? >>>> Is the right place? >>>> >>>> >>>> Komponist >>>> Composer de Jure >>>> >>>> >>>> Apparently not, as it only may have attributes to relate the included string to a controlled vocabulary. >>>> maybe: >>>> >>>> >>>> ... >>>> >>>> >>>> This would make necessary a for each role to be supplied. Which even is a good idea to group multiple names (as seen in preceeding examples by Kristina and Perry ). >>>> The again this would miss someting like @xml:lang which could allowed on if used for a label. >>>> >>>> Then if detailed description is not of primary interest, one could come up with a flat hierarchy: >>>> >>>> >>>> Composer de Jure >>>> Johann Collaborator Bach >>>> ... >>>> >>>> >>>> or: >>>> >>>> >>>> Komponist >>>> Composer de Jure >>>> >>>> >>>> >>>> That's it for now. Sorry for getting lengthy and raising even more questions. >>>> As I'm no metadata expert I see that at some points I might have been too focused on transcription instead of metadata, please excuse ;-) >>>> In expectation of a nice discussion, >>>> >>>> Benjamin >>>> >>>> >>>> Am 05.02.2013 18:23, schrieb Roland, Perry (pdr4h): >>>>> Hello everyone, >>>>> I can see now that my plan to provide and as replacements for TEI's element isn't defensible because it's causing more confusion than it alleviates. So, I suggest that we >>>>> 1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt, >>>>> 2. but drop meeting and principal, and >>>>> 3. add arranger, composer, librettist, and lyricist. >>>>> As in TEI, any roles not specifically provided for by this list, such as conductor, encoder, and so on, belong in , for example -- >>>>> >>>>> My Music, Op. 1 >>>>> Composer de Jure >>>>> Johann Collaborator Bach >>>>> Arranger Extraordinaire >>>>> >>>>> Encoders >>>>> [encoder 1] >>>>> [encoder 2] >>>>> >>>>> >>>>> In this scheme, , , , and for musical compositions are equivalent to for textual material. The element *should not* be used for lyricists or librettists. >>>>> MARC relator code list (http://www.loc.gov/marc/relators/relaterm.html) provides more than 200 codes/terms for roles, several of which apply to music and musical performances. There's no way we can accommodate them all. So, it makes sense to continue the TEI method of recording those responsible for the *intellectual content* of the work in special elements and relegating other roles to . (I think this actually stems from ISBD and AACR2, not TEI.) >>>>> The addition of these elements *does not* mandate their use; that is, can be used for all responsibilities. The following markup is a valid alternative to the example above: >>>>> >>>>> My Music, Op. 1 >>>>> >>>>> Composer >>>>> Composer de Jure >>>>> Lyricist >>>>> Johann Collaborator Bach >>>>> Arranger >>>>> Arranger Man >>>>> Encoders >>>>> [encoder 1] >>>>> [encoder 2] >>>>> >>>>> >>>>> This form can be easier to produce mechanistically from other encoding schemes and is conformant with forms of cataloging that don't require a "main entry" approach, meaning that it would be easier to transform into one of those systems, such as MODS. >>>>> Also, it's necessary to keep in mind that since is a kind of bibliographic citation, elements used here are also available in (and must also fit within the purpose of) other elements, such as and . >>>>> Best wishes, >>>>> -- >>>>> 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 Eleanor Selfridge-Field [esfield at stanford.edu] >>>>> Sent: Monday, February 04, 2013 4:39 PM >>>>> To: 'Music Encoding Initiative' >>>>> Subject: Re: [MEI-L] Encoding of personal names >>>>> >>>>> Kristina poses interesting questions. Instinctively I would go for ?composer?, ?encoder,? etc and err on the side of being verbose and explicit. With electronic data, being able to track who encoded what (with version number and date) can be very valuable. >>>>> I find labels such as ?creator? and ?corporate name? very unwieldy, particularly when working in a second language (in my case usually Italian). Italian bibliographical databases a full of these kinds of terms, but there is something subtly cultural about the misunderstandings they can create. The various instantiations of a single work can have many creators?a composer, an arranger, and editor, a translator of the text, and in the case of recording a conductor, performer, performing group, etc. Because they can all pertain to a single work, a general label deprives the user of knowing what the role of each one was. >>>>> A much messier area is dating. A single work can have an almost endless number of ?year?s?of composition, publication, first performance, revision <1..n>, arrangement, recording, text translation, etc. There too being more specific saves time for those searching. >>>>> Best regards, >>>>> Eleanor >>>>> Eleanor Selfridge-Field >>>>> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >>>>> Braun Music Center #129 >>>>> Stanford University >>>>> Stanford, CA 94305-3076, USA >>>>> http://www.stanford.edu/~esfield/ >>>>> From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kristina Richts >>>>> Sent: Monday, February 04, 2013 9:55 AM >>>>> To: mei-l at lists.uni-paderborn.de >>>>> Subject: [MEI-L] Encoding of personal names >>>>> Dear all, >>>>> >>>>> during the work on the MEI sample collection, questions appeared on how to encode the creators of each electronic file correctly. >>>>> In MEI2012 the normal path (or better said: the way, we first chose to encode it) was to encode several -elements within the statement of responsibilty. A differentiation between several involved persons only became apparent through additional @role-attributes, i.e. >>>>> >>>>> Anton Webern >>>>> John Doe >>>>> >>>>> >>>>> In a second step we decided not to encode ourselves as "creators" of the file (although we are), but as "encoders" and to assign the composer of the encoded work as creator, i.e. >>>>> >>>>> >>>>> Anton Webern >>>>> John Doe >>>>> >>>>> >>>>> The decision is based on the fact, that we encode the intellectual creation of a composer's work. We tried to keep up the distinction between the composer and the encoder. >>>>> >>>>> MEI2013 will offer some new elements to specify the role of persons, organizations etc. a bit more: , , , and . >>>>> In this regard it is now the question how to encode this best: >>>>> >>>>> >>>>> Anton Webern >>>>> >>>>> >>>>> John Doe >>>>> >>>>> >>>>> >>>>> or >>>>> >>>>> >>>>> >>>>> Anton Webern >>>>> >>>>> >>>>> John Doe >>>>> >>>>> >>>>> ? >>>>> >>>>> We first thought, it would be a good idea, to add a element to the list. But that alone would not be sufficient, as the creative aspect regarding musical works is difficult to manage. In this case, we would rather have to extend the list by adding some more elements like , , etc. But this can soon become very unwieldy. >>>>> >>>>> I have to admit that I don't prefer to encode detailed specifications only within child elements. However, if we choose to maintain the 'more detailed elements', I would at least like to see some mandatory child elements, such as , , etc., in there. >>>>> >>>>> When thinking about all this, I came to the conclusion, that it might be enough to allow a and a element (with some mandatory child elements). I am not even sure, if we should offer a separate element or if an editor should be considered as a contributor as well. >>>>> What is to be said against a specification of the role on the or element? Wouldn't this make things easier to handle for the encoder, who might not know as much about the encoding of persNames with MEI? >>>>> >>>>> Any comments on this? >>>>> >>>>> Best, >>>>> Kristina >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 pdr4h at eservices.virginia.edu Thu Feb 7 20:18:59 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 7 Feb 2013 19:18:59 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> Message-ID: > Ah, here are the worms, freshly served from the foothills of the blue ridge mountains ;-) It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! > Perry, honestly, I remember myriads of discussions about this, and you still have this > tendency of relapsing. Is this a subtle way of saying I'm old? :-) In any case, what you call "relapsing", I call "reconsideration" or "refinement". But to paraphrase Ronald Reagan, I won't hold your youth and inexperience against you. ;-) >First, what I miss in your post is an example of these elements in the context of . > You mention this is the meatful part, but only telling us about the food makes us > hungry, not well-fed (and convinced). The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... In text, a bibliographic entity might be described using the bibliographic components allowed in inline text (as in the 1st paragraph) or with more detail using the element --

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

But it's more formally described as Beethoven, Ludwig van, 1770-1827. Symphonies, no. 7, op. 92, A major <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. . Kassel ; New York Ba?renreiter c2001 .

[Unfortunately, this example doesn't allow , but it should. It's just an oversight in the ODD revision.] With only slight modification, mostly by eliminating separating punctuation, this publication can be described as the source of an MEI encoding using -- Symphonies, no. 7, op. 92, A major <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 Beethoven, Ludwig van, 1770-1827 Urtext herausgegeben von Jonathan Del Mar Kassel ; New York Ba?renreiter c2001 and the MEI encoding itself can be described by -- Symphonies, no. 7, op. 92, A major <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 Beethoven, Ludwig van, 1770-1827 Encoded by Maja Hartwig Kristina Richts or, if composer and encoder are thought to be of equal importance -- Symphonies, no. 7, op. 92, A major <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 Composed by Beethoven, Ludwig van, 1770-1827 Encoded by Maja Hartwig Kristina Richts The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. With the addition of @code on , the preceding example could be enhanced -- Composed by Beethoven, Ludwig van, 1770-1827 > It's not that I don't see the usefulness of these elements, it's just that I don't see a > clear line where to stop when adding these elements. I also totally agree that is > useful (for transcribing sources), although I see no difference about this in > and . I think the distinction we made (after passing the long and wormy > road of discussion?) is pretty useful: for the texty part of a description, @code > on names for processing. Requiring may be useful for certain , > like inside a , but what do you plan to transcribe in the > fileDesc/titleStmt/respStmt? This about an electronic resource, and it is by definition > the file your operating in. You're about to transcribe yourself here, starting into > recursion mode. I think in fileDesc may be useful if you want to add additional > text, but technically, there is no benefit compared to or the > like. I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. > The benefit of Komponist comes into play when you > add @xml:lang to this. But the current Guidelines recommend to use komponiert > von, not the proper noun. > As I said, I see a benefit in etc., but I would really like to restrict these > elements as much as possible. > > There is some risk down that road ? I see MEI having to deal with the same > philosophical questions TEI has stumbled over, namely the discussion about the > distinction between persNames and persons. Don't you see a chance for s to stay > ignorant about this? Only because they have jumped out of the window, do we really > have to follow? Also, what does MODS allow that isn't possible with the current set? > Yes, it uses a slightly different model, but it actually contains the same information. > >If you really feel a need for those elements, I would like to draw the shortest possible > line, allowing only the most convincing elements. But who should identify them? As far as I am concerned, consider the list of new elements limited to list given above. I don't think this discussion has anything to do with personal names versus persons. I think we can avoid that topic for now. But I don't endorse self-imposed ignorance of any kind. :-) The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. -- p. From bohl at edirom.de Fri Feb 8 09:46:42 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 08 Feb 2013 09:46:42 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> Message-ID: <5114BB72.9090109@edirom.de> On a scond try of replying to this mail... 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. 3) should definitely be allowed in 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: Beethoven, Ludwig van1770-1827 The date is not part of the person's name, although it's additional info for identifying purposes etc. Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. composed by Beethoven, Ludwig van 1811-1812 similar to ! But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). cheers, benni Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >> Ah, here are the worms, freshly served from the foothills of the blue ridge mountains ;-) > It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! > >> Perry, honestly, I remember myriads of discussions about this, and you still have this >> tendency of relapsing. > Is this a subtle way of saying I'm old? :-) In any case, what you call "relapsing", I call "reconsideration" or "refinement". But to paraphrase Ronald Reagan, I won't hold your youth and inexperience against you. ;-) > >> First, what I miss in your post is an example of these elements in the context of . >> You mention this is the meatful part, but only telling us about the food makes us >> hungry, not well-fed (and convinced). > The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... > > In text, a bibliographic entity might be described using the bibliographic components allowed in inline text (as in the 1st paragraph) or with more detail using the element -- > >
>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>

But it's more formally described as > > Beethoven, Ludwig van, 1770-1827. > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. > . > > Kassel ; New York > Ba?renreiter > c2001 > . > >

>
> > [Unfortunately, this example doesn't allow , but it should. It's just an oversight in the ODD revision.] > > With only slight modification, mostly by eliminating separating punctuation, this publication can be described as the source of an MEI encoding using -- > > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 > Beethoven, Ludwig van, 1770-1827 > > Urtext herausgegeben von > Jonathan Del Mar > > > > Kassel ; New York > Ba?renreiter > c2001 > > > > and the MEI encoding itself can be described by -- > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony > no. 7 in A major: op. 92 > Beethoven, Ludwig van, 1770-1827 > > Encoded by > Maja Hartwig > Kristina Richts > > > > > > > or, if composer and encoder are thought to be of equal importance -- > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony > no. 7 in A major: op. 92 > > Composed by > Beethoven, Ludwig van, 1770-1827 > Encoded by > Maja Hartwig > Kristina Richts > > > > The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. > > The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. > > With the addition of @code on , the preceding example could be enhanced -- > > Composed by > Beethoven, Ludwig van, 1770-1827 > >> It's not that I don't see the usefulness of these elements, it's just that I don't see a >> clear line where to stop when adding these elements. I also totally agree that is >> useful (for transcribing sources), although I see no difference about this in >> and . I think the distinction we made (after passing the long and wormy >> road of discussion?) is pretty useful: for the texty part of a description, @code >> on names for processing. Requiring may be useful for certain , >> like inside a , but what do you plan to transcribe in the >> fileDesc/titleStmt/respStmt? This about an electronic resource, and it is by definition >> the file your operating in. You're about to transcribe yourself here, starting into >> recursion mode. I think in fileDesc may be useful if you want to add additional >> text, but technically, there is no benefit compared to or the >> like. > I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. > >> The benefit of Komponist comes into play when you >> add @xml:lang to this. But the current Guidelines recommend to use komponiert >> von, not the proper noun. >> As I said, I see a benefit in etc., but I would really like to restrict these >> elements as much as possible. >> >> There is some risk down that road ? I see MEI having to deal with the same >> philosophical questions TEI has stumbled over, namely the discussion about the >> distinction between persNames and persons. Don't you see a chance for s to stay >> ignorant about this? Only because they have jumped out of the window, do we really >> have to follow? Also, what does MODS allow that isn't possible with the current set? >> Yes, it uses a slightly different model, but it actually contains the same information. >> >> If you really feel a need for those elements, I would like to draw the shortest possible >> line, allowing only the most convincing elements. But who should identify them? > As far as I am concerned, consider the list of new elements limited to list given above. > > I don't think this discussion has anything to do with personal names versus persons. I think we can avoid that topic for now. But I don't endorse self-imposed ignorance of any kind. :-) > > The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. > > By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. > > > -- > p. > _______________________________________________ > 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 Fri Feb 8 11:06:15 2013 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 8 Feb 2013 10:06:15 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: <5114BB72.9090109@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk> Hi all, I guess I was just hoping somehow to stay out of this... sorry :-) I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. I see another conceptual problem concerning @authority or @authURI as used in Perry's example: Composed by Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have cmp or composer but not Komponiert von ? or am I mistaking? Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: Beethoven That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to fl. Any thoughts on how to solve this? /axel -----Oprindelig meddelelse----- Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl Sendt: 8. februar 2013 09:47 Til: Music Encoding Initiative Emne: Re: [MEI-L] Encoding of personal names On a scond try of replying to this mail... 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. 3) should definitely be allowed in 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: Beethoven, Ludwig van1770-1827 The date is not part of the person's name, although it's additional info for identifying purposes etc. Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. composed by Beethoven, Ludwig van 1811-1812 similar to ! But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). cheers, benni Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >> Ah, here are the worms, freshly served from the foothills of the blue >> ridge mountains ;-) > It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! > >> Perry, honestly, I remember myriads of discussions about this, and >> you still have this tendency of relapsing. > Is this a subtle way of saying I'm old? :-) In any case, what you > call "relapsing", I call "reconsideration" or "refinement". But to > paraphrase Ronald Reagan, I won't hold your youth and inexperience > against you. ;-) > >> First, what I miss in your post is an example of these elements in the context of . >> You mention this is the meatful part, but only telling us about the >> food makes us hungry, not well-fed (and convinced). > The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... > > In text, a bibliographic entity might be described using the > bibliographic components allowed in inline text (as in the 1st > paragraph) or with more detail using the element -- > >
>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>

But it's more formally described as > > Beethoven, Ludwig van, 1770-1827. > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. > . > > Kassel ; New York > Ba?renreiter > c2001 > . > >

>
> > [Unfortunately, this example doesn't allow , but it should. > It's just an oversight in the ODD revision.] > > With only slight modification, mostly by eliminating separating > punctuation, this publication can be described as the source of an MEI > encoding using -- > > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 > Beethoven, Ludwig van, 1770-1827 > > Urtext herausgegeben von > Jonathan Del Mar > > > > Kassel ; New York > Ba?renreiter > c2001 > > > > and the MEI encoding itself can be described by -- > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony > no. 7 in A major: op. 92 > Beethoven, Ludwig van, 1770-1827 > > Encoded by > Maja Hartwig > Kristina Richts > > > > > > or, if composer and encoder are thought to be of equal importance -- > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony > no. 7 in A major: op. 92 > > Composed by > Beethoven, Ludwig van, 1770-1827 > Encoded by > Maja Hartwig > Kristina Richts > > > > The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. > > The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. > > With the addition of @code on , the preceding example could be > enhanced -- > > code="cmp">Composed by Beethoven, Ludwig van, > 1770-1827 > >> It's not that I don't see the usefulness of these elements, it's just >> that I don't see a clear line where to stop when adding these >> elements. I also totally agree that is useful (for >> transcribing sources), although I see no difference about this in >> and . I think the distinction we made (after passing >> the long and wormy road of discussion?) is pretty useful: for >> the texty part of a description, @code on names for processing. >> Requiring may be useful for certain , like inside a >> , but what do you plan to transcribe in the >> fileDesc/titleStmt/respStmt? This about an electronic resource, and >> it is by definition the file your operating in. You're about to >> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. > I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. > >> The benefit of Komponist comes into play when >> you add @xml:lang to this. But the current Guidelines recommend to >> use komponiert von, not the proper noun. >> As I said, I see a benefit in etc., but I would really >> like to restrict these elements as much as possible. >> >> There is some risk down that road ? I see MEI having to deal with the >> same philosophical questions TEI has stumbled over, namely the >> discussion about the distinction between persNames and persons. Don't >> you see a chance for s to stay ignorant about this? Only because they >> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >> Yes, it uses a slightly different model, but it actually contains the same information. >> >> If you really feel a need for those elements, I would like to draw >> the shortest possible line, allowing only the most convincing elements. But who should identify them? > As far as I am concerned, consider the list of new elements limited to list given above. > > I don't think this discussion has anything to do with personal names > versus persons. I think we can avoid that topic for now. But I don't > endorse self-imposed ignorance of any kind. :-) > > The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. > > By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. > > > -- > p. > _______________________________________________ > 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 Fri Feb 8 11:32:07 2013 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 8 Feb 2013 11:32:07 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk> Message-ID: <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : > Hi all, > > I guess I was just hoping somehow to stay out of this... sorry :-) > > I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. > > I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. > > I see another conceptual problem concerning @authority or @authURI as used in Perry's example: > Composed by > > Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have > cmp > or > composer > but not > Komponiert von > ? or am I mistaking? Again, let's have a look at the friendly manual. We have an example on page 217, which reads Wolfgang Amadeus Mozart This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." This can be understood as a default specification of the values of @role. The Guidelines continue: "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. Best, Johannes > > Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: > > Beethoven > > That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to > fl. > > Any thoughts on how to solve this? > > /axel > > -----Oprindelig meddelelse----- > Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl > Sendt: 8. februar 2013 09:47 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] Encoding of personal names > > On a scond try of replying to this mail... > > 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. > > 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. > > 3) should definitely be allowed in > > 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: > > Beethoven, Ludwig > van1770-1827 > > The date is not part of the person's name, although it's additional info for identifying purposes etc. > Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. > > > composed by > Beethoven, Ludwig van > 1811-1812 > > similar to ! > But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. > Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" > (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? > > 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. > > 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? > It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). > > > cheers, > benni > > Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>> Ah, here are the worms, freshly served from the foothills of the blue >>> ridge mountains ;-) >> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >> >>> Perry, honestly, I remember myriads of discussions about this, and >>> you still have this tendency of relapsing. >> Is this a subtle way of saying I'm old? :-) In any case, what you >> call "relapsing", I call "reconsideration" or "refinement". But to >> paraphrase Ronald Reagan, I won't hold your youth and inexperience >> against you. ;-) >> >>> First, what I miss in your post is an example of these elements in the context of . >>> You mention this is the meatful part, but only telling us about the >>> food makes us hungry, not well-fed (and convinced). >> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >> >> In text, a bibliographic entity might be described using the >> bibliographic components allowed in inline text (as in the 1st >> paragraph) or with more detail using the element -- >> >>
>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>

But it's more formally described as >> >> Beethoven, Ludwig van, 1770-1827. >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >> . >> >> Kassel ; New York >> B?renreiter >> c2001 >> . >> >>

>>
>> >> [Unfortunately, this example doesn't allow , but it should. >> It's just an oversight in the ODD revision.] >> >> With only slight modification, mostly by eliminating separating >> punctuation, this publication can be described as the source of an MEI >> encoding using -- >> >> >> >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >> Beethoven, Ludwig van, 1770-1827 >> >> Urtext herausgegeben von >> Jonathan Del Mar >> >> >> >> Kassel ; New York >> B?renreiter >> c2001 >> >> >> >> and the MEI encoding itself can be described by -- >> >> >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >> no. 7 in A major: op. 92 >> Beethoven, Ludwig van, 1770-1827 >> >> Encoded by >> Maja Hartwig >> Kristina Richts >> >> >> >> >> >> or, if composer and encoder are thought to be of equal importance -- >> >> >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >> no. 7 in A major: op. 92 >> >> Composed by >> Beethoven, Ludwig van, 1770-1827 >> Encoded by >> Maja Hartwig >> Kristina Richts >> >> >> >> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >> >> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >> >> With the addition of @code on , the preceding example could be >> enhanced -- >> >> > code="cmp">Composed by Beethoven, Ludwig van, >> 1770-1827 >> >>> It's not that I don't see the usefulness of these elements, it's just >>> that I don't see a clear line where to stop when adding these >>> elements. I also totally agree that is useful (for >>> transcribing sources), although I see no difference about this in >>> and . I think the distinction we made (after passing >>> the long and wormy road of discussion?) is pretty useful: for >>> the texty part of a description, @code on names for processing. >>> Requiring may be useful for certain , like inside a >>> , but what do you plan to transcribe in the >>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>> it is by definition the file your operating in. You're about to >>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >> >>> The benefit of Komponist comes into play when >>> you add @xml:lang to this. But the current Guidelines recommend to >>> use komponiert von, not the proper noun. >>> As I said, I see a benefit in etc., but I would really >>> like to restrict these elements as much as possible. >>> >>> There is some risk down that road ? I see MEI having to deal with the >>> same philosophical questions TEI has stumbled over, namely the >>> discussion about the distinction between persNames and persons. Don't >>> you see a chance for s to stay ignorant about this? Only because they >>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>> Yes, it uses a slightly different model, but it actually contains the same information. >>> >>> If you really feel a need for those elements, I would like to draw >>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >> As far as I am concerned, consider the list of new elements limited to list given above. >> >> I don't think this discussion has anything to do with personal names >> versus persons. I think we can avoid that topic for now. But I don't >> endorse self-imposed ignorance of any kind. :-) >> >> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >> >> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >> >> >> -- >> p. >> _______________________________________________ >> 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 bohl at edirom.de Fri Feb 8 11:48:26 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 08 Feb 2013 11:48:26 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk> Message-ID: <5114D7FA.5000002@edirom.de> Hi Axel, thanks for joining the discussion! Am 08.02.2013 11:06, schrieb Axel Teich Geertinger: > Hi all, > > I guess I was just hoping somehow to stay out of this... sorry :-) > > I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. > > I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. Linking to an authority resource sounds like a very good idea, for example: Carl Maria von Weber Nevertheless my spelling of the name is not the same as in the GND resource. Should it be? > > I see another conceptual problem concerning @authority or @authURI as used in Perry's example: > Composed by > > Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have > cmp > or > composer > but not > Komponiert von > ? or am I mistaking? I understand it the same way you do. > > Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: > > Beethoven > > That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to > fl. > > Any thoughts on how to solve this? > > /axel In spelling out the role you avoid the problem only as long as you can assign a definitive role. I just went through all the responsibilities I had in one of my recording data sets and instantly ran into problems when a team of persons were responsible and one would be the team leader. This would require me to insert "Lead" into @role as well and when it comes to composite terms I would have something like @role="Recording engineer Lead" making it hard to separate the different terms by other means than capital letters. What I could think of is to treat the @code on as in the above example with the association of to an authority. Aufnahmeleitung It's qustionable whether the association of another attribute (@code) with @authority and @authURI is/should be the same as with @dbkey or whehter the MARC list or similar controlled vocabularies should be denominated as "authority". One could actually allow @dbkey on instead of @code, no? cheers, benni > -----Oprindelig meddelelse----- > Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl > Sendt: 8. februar 2013 09:47 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] Encoding of personal names > > On a scond try of replying to this mail... > > 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. > > 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. > > 3) should definitely be allowed in > > 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: > > Beethoven, Ludwig > van1770-1827 > > The date is not part of the person's name, although it's additional info for identifying purposes etc. > Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. > > > composed by > Beethoven, Ludwig van > 1811-1812 > > similar to ! > But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. > Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" > (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? > > 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. > > 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? > It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). > > > cheers, > benni > > Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>> Ah, here are the worms, freshly served from the foothills of the blue >>> ridge mountains ;-) >> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >> >>> Perry, honestly, I remember myriads of discussions about this, and >>> you still have this tendency of relapsing. >> Is this a subtle way of saying I'm old? :-) In any case, what you >> call "relapsing", I call "reconsideration" or "refinement". But to >> paraphrase Ronald Reagan, I won't hold your youth and inexperience >> against you. ;-) >> >>> First, what I miss in your post is an example of these elements in the context of . >>> You mention this is the meatful part, but only telling us about the >>> food makes us hungry, not well-fed (and convinced). >> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >> >> In text, a bibliographic entity might be described using the >> bibliographic components allowed in inline text (as in the 1st >> paragraph) or with more detail using the element -- >> >>
>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>

But it's more formally described as >> >> Beethoven, Ludwig van, 1770-1827. >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >> . >> >> Kassel ; New York >> Ba?renreiter >> c2001 >> . >> >>

>>
>> >> [Unfortunately, this example doesn't allow , but it should. >> It's just an oversight in the ODD revision.] >> >> With only slight modification, mostly by eliminating separating >> punctuation, this publication can be described as the source of an MEI >> encoding using -- >> >> >> >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >> Beethoven, Ludwig van, 1770-1827 >> >> Urtext herausgegeben von >> Jonathan Del Mar >> >> >> >> Kassel ; New York >> Ba?renreiter >> c2001 >> >> >> >> and the MEI encoding itself can be described by -- >> >> >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >> no. 7 in A major: op. 92 >> Beethoven, Ludwig van, 1770-1827 >> >> Encoded by >> Maja Hartwig >> Kristina Richts >> >> >> >> >> >> or, if composer and encoder are thought to be of equal importance -- >> >> >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >> no. 7 in A major: op. 92 >> >> Composed by >> Beethoven, Ludwig van, 1770-1827 >> Encoded by >> Maja Hartwig >> Kristina Richts >> >> >> >> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >> >> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >> >> With the addition of @code on , the preceding example could be >> enhanced -- >> >> > code="cmp">Composed by Beethoven, Ludwig van, >> 1770-1827 >> >>> It's not that I don't see the usefulness of these elements, it's just >>> that I don't see a clear line where to stop when adding these >>> elements. I also totally agree that is useful (for >>> transcribing sources), although I see no difference about this in >>> and . I think the distinction we made (after passing >>> the long and wormy road of discussion?) is pretty useful: for >>> the texty part of a description, @code on names for processing. >>> Requiring may be useful for certain , like inside a >>> , but what do you plan to transcribe in the >>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>> it is by definition the file your operating in. You're about to >>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >> >>> The benefit of Komponist comes into play when >>> you add @xml:lang to this. But the current Guidelines recommend to >>> use komponiert von, not the proper noun. >>> As I said, I see a benefit in etc., but I would really >>> like to restrict these elements as much as possible. >>> >>> There is some risk down that road ? I see MEI having to deal with the >>> same philosophical questions TEI has stumbled over, namely the >>> discussion about the distinction between persNames and persons. Don't >>> you see a chance for s to stay ignorant about this? Only because they >>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>> Yes, it uses a slightly different model, but it actually contains the same information. >>> >>> If you really feel a need for those elements, I would like to draw >>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >> As far as I am concerned, consider the list of new elements limited to list given above. >> >> I don't think this discussion has anything to do with personal names >> versus persons. I think we can avoid that topic for now. But I don't >> endorse self-imposed ignorance of any kind. :-) >> >> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >> >> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >> >> >> -- >> p. >> _______________________________________________ >> 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 Feb 8 14:40:42 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 8 Feb 2013 13:40:42 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: <5114BB72.9090109@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> , <5114BB72.9090109@edirom.de> Message-ID: Sorry for the short answers, but I'm only one guy trying to field questions from what sometimes seems like an army of questioners. I'm supposed to be working on MusicXML <-> MEI transforms and several other things too. > 3) should definitely be allowed in added to /branches/MEI_dev/customizations/mei2013.xml > 4) Although being yet another poblem, the person-vs-persName problem > Johannes mentioned is at the brink of bothering us. Seein as > child of makes me feel uncomfortable. I'd prefer: My example was a literal copy of the data in a MARC record. If you prefer not to put the dates inside , then don't! And don't worry so much about a problem that hasn't happened yet. How do you think I got all these gray hairs? :-) > 5) I think we should dissalow multiple s in the same or > is there any other grouping mechanism for the children of > other than xml-order? Making it more feasible to process. Revision of is not on the table. I'm fine with following TEI's lead on this one. > 6) Still an open question for me is the @code on which is not > allowed in the current mei-all.rng in trunk (or at least not in my > working copy). Neither could I find an issue on google code referring to > it. Did I miss anything? > It's definitely good to have such an attribute (as e.g. in > ), but does this attribute by any means correlate with > @authority and @authURI (which I had expected so far but Perry if I got > him right discouraged such attribute-correlation). Also added in mei2013.xml. -- 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 Benjamin Wolff Bohl [bohl at edirom.de] Sent: Friday, February 08, 2013 3:46 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names On a scond try of replying to this mail... 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. 3) should definitely be allowed in 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: Beethoven, Ludwig van1770-1827 The date is not part of the person's name, although it's additional info for identifying purposes etc. Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. composed by Beethoven, Ludwig van 1811-1812 similar to ! But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). cheers, benni Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >> Ah, here are the worms, freshly served from the foothills of the blue ridge mountains ;-) > It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! > >> Perry, honestly, I remember myriads of discussions about this, and you still have this >> tendency of relapsing. > Is this a subtle way of saying I'm old? :-) In any case, what you call "relapsing", I call "reconsideration" or "refinement". But to paraphrase Ronald Reagan, I won't hold your youth and inexperience against you. ;-) > >> First, what I miss in your post is an example of these elements in the context of . >> You mention this is the meatful part, but only telling us about the food makes us >> hungry, not well-fed (and convinced). > The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... > > In text, a bibliographic entity might be described using the bibliographic components allowed in inline text (as in the 1st paragraph) or with more detail using the element -- > >
>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>

But it's more formally described as > > Beethoven, Ludwig van, 1770-1827. > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. > . > > Kassel ; New York > Ba?renreiter > c2001 > . > >

>
> > [Unfortunately, this example doesn't allow , but it should. It's just an oversight in the ODD revision.] > > With only slight modification, mostly by eliminating separating punctuation, this publication can be described as the source of an MEI encoding using -- > > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 > Beethoven, Ludwig van, 1770-1827 > > Urtext herausgegeben von > Jonathan Del Mar > > > > Kassel ; New York > Ba?renreiter > c2001 > > > > and the MEI encoding itself can be described by -- > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony > no. 7 in A major: op. 92 > Beethoven, Ludwig van, 1770-1827 > > Encoded by > Maja Hartwig > Kristina Richts > > > > > > > or, if composer and encoder are thought to be of equal importance -- > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony > no. 7 in A major: op. 92 > > Composed by > Beethoven, Ludwig van, 1770-1827 > Encoded by > Maja Hartwig > Kristina Richts > > > > The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. > > The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. > > With the addition of @code on , the preceding example could be enhanced -- > > Composed by > Beethoven, Ludwig van, 1770-1827 > >> It's not that I don't see the usefulness of these elements, it's just that I don't see a >> clear line where to stop when adding these elements. I also totally agree that is >> useful (for transcribing sources), although I see no difference about this in >> and . I think the distinction we made (after passing the long and wormy >> road of discussion?) is pretty useful: for the texty part of a description, @code >> on names for processing. Requiring may be useful for certain , >> like inside a , but what do you plan to transcribe in the >> fileDesc/titleStmt/respStmt? This about an electronic resource, and it is by definition >> the file your operating in. You're about to transcribe yourself here, starting into >> recursion mode. I think in fileDesc may be useful if you want to add additional >> text, but technically, there is no benefit compared to or the >> like. > I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. > >> The benefit of Komponist comes into play when you >> add @xml:lang to this. But the current Guidelines recommend to use komponiert >> von, not the proper noun. >> As I said, I see a benefit in etc., but I would really like to restrict these >> elements as much as possible. >> >> There is some risk down that road ? I see MEI having to deal with the same >> philosophical questions TEI has stumbled over, namely the discussion about the >> distinction between persNames and persons. Don't you see a chance for s to stay >> ignorant about this? Only because they have jumped out of the window, do we really >> have to follow? Also, what does MODS allow that isn't possible with the current set? >> Yes, it uses a slightly different model, but it actually contains the same information. >> >> If you really feel a need for those elements, I would like to draw the shortest possible >> line, allowing only the most convincing elements. But who should identify them? > As far as I am concerned, consider the list of new elements limited to list given above. > > I don't think this discussion has anything to do with personal names versus persons. I think we can avoid that topic for now. But I don't endorse self-imposed ignorance of any kind. :-) > > The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. > > By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. > > > -- > p. > _______________________________________________ > 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 Feb 8 14:54:23 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 8 Feb 2013 13:54:23 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de>, <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk> Message-ID: Apologies again for short answers. > I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? > would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all > persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could > process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except > that in some cases we may have to choose instead of , if the role is not associated with a single person. Same answer as I gave to Benni -- if you prefer this method, then use it. But "maximum flexibility and expandability" dictates that we accommodate other approaches too. Using or are equivalent means to accomplish the same thing. One is not better than the other. One cannot be jettisoned in favor of the other. > I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the > person's name, I would try to link the name to some authority resource for disambiguation and further information. See my answer to Benni. > I see another conceptual problem concerning @authority or @authURI as used in Perry's example: > Composed by > Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. > How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? > If I understand it right, we can have > cmp > or > composer > but not > Komponiert von > ? or am I mistaking? This is what I was talking about yesterday. The answer is: attributes cannot explicitly refer to another attribute. So, most of the time, this situation should be avoided. HOWEVER, sometimes there is no other solution than to allow it. So, go ahead and use the last one too. The medicine for it will be much worse than the injury. > That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to > fl. > Any thoughts on how to solve this? See above. Go ahead and add @authURI, don't worry, be happy. :-) -- 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: Friday, February 08, 2013 5:06 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names Hi all, I guess I was just hoping somehow to stay out of this... sorry :-) I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. I see another conceptual problem concerning @authority or @authURI as used in Perry's example: Composed by Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have cmp or composer but not Komponiert von ? or am I mistaking? Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: Beethoven That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to fl. Any thoughts on how to solve this? /axel -----Oprindelig meddelelse----- Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl Sendt: 8. februar 2013 09:47 Til: Music Encoding Initiative Emne: Re: [MEI-L] Encoding of personal names On a scond try of replying to this mail... 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. 3) should definitely be allowed in 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: Beethoven, Ludwig van1770-1827 The date is not part of the person's name, although it's additional info for identifying purposes etc. Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. composed by Beethoven, Ludwig van 1811-1812 similar to ! But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). cheers, benni Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >> Ah, here are the worms, freshly served from the foothills of the blue >> ridge mountains ;-) > It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! > >> Perry, honestly, I remember myriads of discussions about this, and >> you still have this tendency of relapsing. > Is this a subtle way of saying I'm old? :-) In any case, what you > call "relapsing", I call "reconsideration" or "refinement". But to > paraphrase Ronald Reagan, I won't hold your youth and inexperience > against you. ;-) > >> First, what I miss in your post is an example of these elements in the context of . >> You mention this is the meatful part, but only telling us about the >> food makes us hungry, not well-fed (and convinced). > The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... > > In text, a bibliographic entity might be described using the > bibliographic components allowed in inline text (as in the 1st > paragraph) or with more detail using the element -- > >
>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>

But it's more formally described as > > Beethoven, Ludwig van, 1770-1827. > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. > . > > Kassel ; New York > Ba?renreiter > c2001 > . > >

>
> > [Unfortunately, this example doesn't allow , but it should. > It's just an oversight in the ODD revision.] > > With only slight modification, mostly by eliminating separating > punctuation, this publication can be described as the source of an MEI > encoding using -- > > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 > Beethoven, Ludwig van, 1770-1827 > > Urtext herausgegeben von > Jonathan Del Mar > > > > Kassel ; New York > Ba?renreiter > c2001 > > > > and the MEI encoding itself can be described by -- > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony > no. 7 in A major: op. 92 > Beethoven, Ludwig van, 1770-1827 > > Encoded by > Maja Hartwig > Kristina Richts > > > > > > or, if composer and encoder are thought to be of equal importance -- > > > Symphonies, no. 7, op. 92, A major > <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony > no. 7 in A major: op. 92 > > Composed by > Beethoven, Ludwig van, 1770-1827 > Encoded by > Maja Hartwig > Kristina Richts > > > > The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. > > The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. > > With the addition of @code on , the preceding example could be > enhanced -- > > code="cmp">Composed by Beethoven, Ludwig van, > 1770-1827 > >> It's not that I don't see the usefulness of these elements, it's just >> that I don't see a clear line where to stop when adding these >> elements. I also totally agree that is useful (for >> transcribing sources), although I see no difference about this in >> and . I think the distinction we made (after passing >> the long and wormy road of discussion?) is pretty useful: for >> the texty part of a description, @code on names for processing. >> Requiring may be useful for certain , like inside a >> , but what do you plan to transcribe in the >> fileDesc/titleStmt/respStmt? This about an electronic resource, and >> it is by definition the file your operating in. You're about to >> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. > I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. > >> The benefit of Komponist comes into play when >> you add @xml:lang to this. But the current Guidelines recommend to >> use komponiert von, not the proper noun. >> As I said, I see a benefit in etc., but I would really >> like to restrict these elements as much as possible. >> >> There is some risk down that road ? I see MEI having to deal with the >> same philosophical questions TEI has stumbled over, namely the >> discussion about the distinction between persNames and persons. Don't >> you see a chance for s to stay ignorant about this? Only because they >> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >> Yes, it uses a slightly different model, but it actually contains the same information. >> >> If you really feel a need for those elements, I would like to draw >> the shortest possible line, allowing only the most convincing elements. But who should identify them? > As far as I am concerned, consider the list of new elements limited to list given above. > > I don't think this discussion has anything to do with personal names > versus persons. I think we can avoid that topic for now. But I don't > endorse self-imposed ignorance of any kind. :-) > > The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. > > By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. > > > -- > p. > _______________________________________________ > 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 Feb 8 15:03:43 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 8 Feb 2013 14:03:43 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk>, <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> Message-ID: Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them! The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good. > This example illustrates the problem of attributes referring to each other. Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me. > These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values > for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for > other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're > quite safe _by following a convention as expressed in the Guidelines_. Ok, so don't sue me. Just go with it. > So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is > the case, I would probably argue to follow TEI in the the land of , etc. The s would > then point to s, which in turn may have multiple references to authorities (probably using or > some such as child elements). There would be no direct linking from the individual names anymore. Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious. -- 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: Friday, February 08, 2013 5:32 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : > Hi all, > > I guess I was just hoping somehow to stay out of this... sorry :-) > > I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. > > I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. > > I see another conceptual problem concerning @authority or @authURI as used in Perry's example: > Composed by > > Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have > cmp > or > composer > but not > Komponiert von > ? or am I mistaking? Again, let's have a look at the friendly manual. We have an example on page 217, which reads Wolfgang Amadeus Mozart This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." This can be understood as a default specification of the values of @role. The Guidelines continue: "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. Best, Johannes > > Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: > > Beethoven > > That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to > fl. > > Any thoughts on how to solve this? > > /axel > > -----Oprindelig meddelelse----- > Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl > Sendt: 8. februar 2013 09:47 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] Encoding of personal names > > On a scond try of replying to this mail... > > 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. > > 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. > > 3) should definitely be allowed in > > 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: > > Beethoven, Ludwig > van1770-1827 > > The date is not part of the person's name, although it's additional info for identifying purposes etc. > Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. > > > composed by > Beethoven, Ludwig van > 1811-1812 > > similar to ! > But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. > Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" > (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? > > 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. > > 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? > It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). > > > cheers, > benni > > Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>> Ah, here are the worms, freshly served from the foothills of the blue >>> ridge mountains ;-) >> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >> >>> Perry, honestly, I remember myriads of discussions about this, and >>> you still have this tendency of relapsing. >> Is this a subtle way of saying I'm old? :-) In any case, what you >> call "relapsing", I call "reconsideration" or "refinement". But to >> paraphrase Ronald Reagan, I won't hold your youth and inexperience >> against you. ;-) >> >>> First, what I miss in your post is an example of these elements in the context of . >>> You mention this is the meatful part, but only telling us about the >>> food makes us hungry, not well-fed (and convinced). >> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >> >> In text, a bibliographic entity might be described using the >> bibliographic components allowed in inline text (as in the 1st >> paragraph) or with more detail using the element -- >> >>
>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>

But it's more formally described as >> >> Beethoven, Ludwig van, 1770-1827. >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >> . >> >> Kassel ; New York >> B?renreiter >> c2001 >> . >> >>

>>
>> >> [Unfortunately, this example doesn't allow , but it should. >> It's just an oversight in the ODD revision.] >> >> With only slight modification, mostly by eliminating separating >> punctuation, this publication can be described as the source of an MEI >> encoding using -- >> >> >> >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >> Beethoven, Ludwig van, 1770-1827 >> >> Urtext herausgegeben von >> Jonathan Del Mar >> >> >> >> Kassel ; New York >> B?renreiter >> c2001 >> >> >> >> and the MEI encoding itself can be described by -- >> >> >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >> no. 7 in A major: op. 92 >> Beethoven, Ludwig van, 1770-1827 >> >> Encoded by >> Maja Hartwig >> Kristina Richts >> >> >> >> >> >> or, if composer and encoder are thought to be of equal importance -- >> >> >> Symphonies, no. 7, op. 92, A major >> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >> no. 7 in A major: op. 92 >> >> Composed by >> Beethoven, Ludwig van, 1770-1827 >> Encoded by >> Maja Hartwig >> Kristina Richts >> >> >> >> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >> >> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >> >> With the addition of @code on , the preceding example could be >> enhanced -- >> >> > code="cmp">Composed by Beethoven, Ludwig van, >> 1770-1827 >> >>> It's not that I don't see the usefulness of these elements, it's just >>> that I don't see a clear line where to stop when adding these >>> elements. I also totally agree that is useful (for >>> transcribing sources), although I see no difference about this in >>> and . I think the distinction we made (after passing >>> the long and wormy road of discussion?) is pretty useful: for >>> the texty part of a description, @code on names for processing. >>> Requiring may be useful for certain , like inside a >>> , but what do you plan to transcribe in the >>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>> it is by definition the file your operating in. You're about to >>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >> >>> The benefit of Komponist comes into play when >>> you add @xml:lang to this. But the current Guidelines recommend to >>> use komponiert von, not the proper noun. >>> As I said, I see a benefit in etc., but I would really >>> like to restrict these elements as much as possible. >>> >>> There is some risk down that road ? I see MEI having to deal with the >>> same philosophical questions TEI has stumbled over, namely the >>> discussion about the distinction between persNames and persons. Don't >>> you see a chance for s to stay ignorant about this? Only because they >>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>> Yes, it uses a slightly different model, but it actually contains the same information. >>> >>> If you really feel a need for those elements, I would like to draw >>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >> As far as I am concerned, consider the list of new elements limited to list given above. >> >> I don't think this discussion has anything to do with personal names >> versus persons. I think we can avoid that topic for now. But I don't >> endorse self-imposed ignorance of any kind. :-) >> >> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >> >> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >> >> >> -- >> p. >> _______________________________________________ >> 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 Fri Feb 8 15:22:22 2013 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 8 Feb 2013 15:22:22 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk>, <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> Message-ID: <81BA2560-7460-4566-A361-1F7681E19B4C@edirom.de> Am 08.02.2013 um 15:03 schrieb "Roland, Perry (pdr4h)" : > Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them! > Yes, but we arrived there after some very intense discussions. This was probably not the best solution, but it was a solution that everyone could agree on. To paraphrase you, we managed to upset everyone to the same degree. If you start the discussion over and over again, you don't accept this balance. > The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good. > >> This example illustrates the problem of attributes referring to each other. > > Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me. > >> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values >> for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for >> other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're >> quite safe _by following a convention as expressed in the Guidelines_. > > Ok, so don't sue me. Just go with it. It's not about blaming someone. We all agree that this isn't simple, that there is no perfect solution, and that one has to be conscious about the model he uses. There is nothing wrong in discussing the benefits and drawbacks of certain models. I'm just reluctant to add yet another possibility getting confused. > >> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is >> the case, I would probably argue to follow TEI in the the land of , etc. The s would >> then point to s, which in turn may have multiple references to authorities (probably using or >> some such as child elements). There would be no direct linking from the individual names anymore. > > Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious. > But if I overlook the discussion correctly, it seems like you're the only one insisting on introducing and the like. If we'd leave that out and stick with the situation we had in 2.0.0, there is no issue. And to be honest, up to the level we discuss here, there is not much of a difference between and . I hardly see a war between different standards at this basic level? I don't want to kill the discussion here, but if you have so many other obligations (and I know you have), do we really need to add this? Or wouldn't it be easier to remove it from the dev version? Is there someone else sufficiently attracted by the proposed elements to keep the discussion going? Best, jo > -- > 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: Friday, February 08, 2013 5:32 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : > >> Hi all, >> >> I guess I was just hoping somehow to stay out of this... sorry :-) >> >> I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. >> >> I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. >> >> I see another conceptual problem concerning @authority or @authURI as used in Perry's example: >> Composed by >> >> Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have >> cmp >> or >> composer >> but not >> Komponiert von >> ? or am I mistaking? > > Again, let's have a look at the friendly manual. We have an example on page 217, which reads > > authURI="http://d-nb.info/gnd" > authority="GND" > dbkey="118584596" > role="composer">Wolfgang Amadeus Mozart > > This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: > > "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." > > This can be understood as a default specification of the values of @role. The Guidelines continue: > > "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." > > These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. > > So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. > > Best, > Johannes > > > > >> >> Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: >> >> Beethoven >> >> That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to >> fl. >> >> Any thoughts on how to solve this? >> >> /axel >> >> -----Oprindelig meddelelse----- >> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl >> Sendt: 8. februar 2013 09:47 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] Encoding of personal names >> >> On a scond try of replying to this mail... >> >> 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. >> >> 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. >> >> 3) should definitely be allowed in >> >> 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: >> >> Beethoven, Ludwig >> van1770-1827 >> >> The date is not part of the person's name, although it's additional info for identifying purposes etc. >> Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. >> >> >> composed by >> Beethoven, Ludwig van >> 1811-1812 >> >> similar to ! >> But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. >> Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" >> (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? >> >> 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. >> >> 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? >> It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). >> >> >> cheers, >> benni >> >> Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>>> Ah, here are the worms, freshly served from the foothills of the blue >>>> ridge mountains ;-) >>> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >>> >>>> Perry, honestly, I remember myriads of discussions about this, and >>>> you still have this tendency of relapsing. >>> Is this a subtle way of saying I'm old? :-) In any case, what you >>> call "relapsing", I call "reconsideration" or "refinement". But to >>> paraphrase Ronald Reagan, I won't hold your youth and inexperience >>> against you. ;-) >>> >>>> First, what I miss in your post is an example of these elements in the context of . >>>> You mention this is the meatful part, but only telling us about the >>>> food makes us hungry, not well-fed (and convinced). >>> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >>> >>> In text, a bibliographic entity might be described using the >>> bibliographic components allowed in inline text (as in the 1st >>> paragraph) or with more detail using the element -- >>> >>>
>>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>>

But it's more formally described as >>> >>> Beethoven, Ludwig van, 1770-1827. >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >>> . >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> . >>> >>>

>>>
>>> >>> [Unfortunately, this example doesn't allow , but it should. >>> It's just an oversight in the ODD revision.] >>> >>> With only slight modification, mostly by eliminating separating >>> punctuation, this publication can be described as the source of an MEI >>> encoding using -- >>> >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Urtext herausgegeben von >>> Jonathan Del Mar >>> >>> >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> >>> >>> >>> and the MEI encoding itself can be described by -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> >>> >>> or, if composer and encoder are thought to be of equal importance -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> >>> Composed by >>> Beethoven, Ludwig van, 1770-1827 >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >>> >>> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >>> >>> With the addition of @code on , the preceding example could be >>> enhanced -- >>> >>> >> code="cmp">Composed by Beethoven, Ludwig van, >>> 1770-1827 >>> >>>> It's not that I don't see the usefulness of these elements, it's just >>>> that I don't see a clear line where to stop when adding these >>>> elements. I also totally agree that is useful (for >>>> transcribing sources), although I see no difference about this in >>>> and . I think the distinction we made (after passing >>>> the long and wormy road of discussion?) is pretty useful: for >>>> the texty part of a description, @code on names for processing. >>>> Requiring may be useful for certain , like inside a >>>> , but what do you plan to transcribe in the >>>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>>> it is by definition the file your operating in. You're about to >>>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >>> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >>> >>>> The benefit of Komponist comes into play when >>>> you add @xml:lang to this. But the current Guidelines recommend to >>>> use komponiert von, not the proper noun. >>>> As I said, I see a benefit in etc., but I would really >>>> like to restrict these elements as much as possible. >>>> >>>> There is some risk down that road ? I see MEI having to deal with the >>>> same philosophical questions TEI has stumbled over, namely the >>>> discussion about the distinction between persNames and persons. Don't >>>> you see a chance for s to stay ignorant about this? Only because they >>>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>>> Yes, it uses a slightly different model, but it actually contains the same information. >>>> >>>> If you really feel a need for those elements, I would like to draw >>>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >>> As far as I am concerned, consider the list of new elements limited to list given above. >>> >>> I don't think this discussion has anything to do with personal names >>> versus persons. I think we can avoid that topic for now. But I don't >>> endorse self-imposed ignorance of any kind. :-) >>> >>> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >>> >>> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >>> >>> >>> -- >>> p. >>> _______________________________________________ >>> 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 pdr4h at eservices.virginia.edu Fri Feb 8 15:48:06 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 8 Feb 2013 14:48:06 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: <81BA2560-7460-4566-A361-1F7681E19B4C@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk>, <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> , <81BA2560-7460-4566-A361-1F7681E19B4C@edirom.de> Message-ID: > there is not much of a difference between and . > I hardly see a war between different standards at this basic level? Precisely! That's why I don't understand the tempest their addition has created. But since you all object so strongly, I will remove them. But someone will have to explain why simple and elegant markup like the following An die ferne Geliebte (Page 1), Op. 98 Ludwig van Beethoven Aloys Jeitteles isn't possible in fileDesc and why it's not possible to capture creator-like information for musical works in without abusing . Should I also remove membership in att.coded from ? -- 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: Friday, February 08, 2013 9:22 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names Am 08.02.2013 um 15:03 schrieb "Roland, Perry (pdr4h)" : > Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them! > Yes, but we arrived there after some very intense discussions. This was probably not the best solution, but it was a solution that everyone could agree on. To paraphrase you, we managed to upset everyone to the same degree. If you start the discussion over and over again, you don't accept this balance. > The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good. > >> This example illustrates the problem of attributes referring to each other. > > Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me. > >> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values >> for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for >> other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're >> quite safe _by following a convention as expressed in the Guidelines_. > > Ok, so don't sue me. Just go with it. It's not about blaming someone. We all agree that this isn't simple, that there is no perfect solution, and that one has to be conscious about the model he uses. There is nothing wrong in discussing the benefits and drawbacks of certain models. I'm just reluctant to add yet another possibility getting confused. > >> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is >> the case, I would probably argue to follow TEI in the the land of , etc. The s would >> then point to s, which in turn may have multiple references to authorities (probably using or >> some such as child elements). There would be no direct linking from the individual names anymore. > > Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious. > But if I overlook the discussion correctly, it seems like you're the only one insisting on introducing and the like. If we'd leave that out and stick with the situation we had in 2.0.0, there is no issue. And to be honest, up to the level we discuss here, there is not much of a difference between and . I hardly see a war between different standards at this basic level? I don't want to kill the discussion here, but if you have so many other obligations (and I know you have), do we really need to add this? Or wouldn't it be easier to remove it from the dev version? Is there someone else sufficiently attracted by the proposed elements to keep the discussion going? Best, jo > -- > 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: Friday, February 08, 2013 5:32 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : > >> Hi all, >> >> I guess I was just hoping somehow to stay out of this... sorry :-) >> >> I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. >> >> I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. >> >> I see another conceptual problem concerning @authority or @authURI as used in Perry's example: >> Composed by >> >> Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have >> cmp >> or >> composer >> but not >> Komponiert von >> ? or am I mistaking? > > Again, let's have a look at the friendly manual. We have an example on page 217, which reads > > authURI="http://d-nb.info/gnd" > authority="GND" > dbkey="118584596" > role="composer">Wolfgang Amadeus Mozart > > This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: > > "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." > > This can be understood as a default specification of the values of @role. The Guidelines continue: > > "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." > > These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. > > So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. > > Best, > Johannes > > > > >> >> Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: >> >> Beethoven >> >> That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to >> fl. >> >> Any thoughts on how to solve this? >> >> /axel >> >> -----Oprindelig meddelelse----- >> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl >> Sendt: 8. februar 2013 09:47 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] Encoding of personal names >> >> On a scond try of replying to this mail... >> >> 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. >> >> 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. >> >> 3) should definitely be allowed in >> >> 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: >> >> Beethoven, Ludwig >> van1770-1827 >> >> The date is not part of the person's name, although it's additional info for identifying purposes etc. >> Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. >> >> >> composed by >> Beethoven, Ludwig van >> 1811-1812 >> >> similar to ! >> But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. >> Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" >> (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? >> >> 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. >> >> 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? >> It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). >> >> >> cheers, >> benni >> >> Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>>> Ah, here are the worms, freshly served from the foothills of the blue >>>> ridge mountains ;-) >>> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >>> >>>> Perry, honestly, I remember myriads of discussions about this, and >>>> you still have this tendency of relapsing. >>> Is this a subtle way of saying I'm old? :-) In any case, what you >>> call "relapsing", I call "reconsideration" or "refinement". But to >>> paraphrase Ronald Reagan, I won't hold your youth and inexperience >>> against you. ;-) >>> >>>> First, what I miss in your post is an example of these elements in the context of . >>>> You mention this is the meatful part, but only telling us about the >>>> food makes us hungry, not well-fed (and convinced). >>> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >>> >>> In text, a bibliographic entity might be described using the >>> bibliographic components allowed in inline text (as in the 1st >>> paragraph) or with more detail using the element -- >>> >>>
>>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>>

But it's more formally described as >>> >>> Beethoven, Ludwig van, 1770-1827. >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >>> . >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> . >>> >>>

>>>
>>> >>> [Unfortunately, this example doesn't allow , but it should. >>> It's just an oversight in the ODD revision.] >>> >>> With only slight modification, mostly by eliminating separating >>> punctuation, this publication can be described as the source of an MEI >>> encoding using -- >>> >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Urtext herausgegeben von >>> Jonathan Del Mar >>> >>> >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> >>> >>> >>> and the MEI encoding itself can be described by -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> >>> >>> or, if composer and encoder are thought to be of equal importance -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> >>> Composed by >>> Beethoven, Ludwig van, 1770-1827 >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >>> >>> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >>> >>> With the addition of @code on , the preceding example could be >>> enhanced -- >>> >>> >> code="cmp">Composed by Beethoven, Ludwig van, >>> 1770-1827 >>> >>>> It's not that I don't see the usefulness of these elements, it's just >>>> that I don't see a clear line where to stop when adding these >>>> elements. I also totally agree that is useful (for >>>> transcribing sources), although I see no difference about this in >>>> and . I think the distinction we made (after passing >>>> the long and wormy road of discussion?) is pretty useful: for >>>> the texty part of a description, @code on names for processing. >>>> Requiring may be useful for certain , like inside a >>>> , but what do you plan to transcribe in the >>>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>>> it is by definition the file your operating in. You're about to >>>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >>> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >>> >>>> The benefit of Komponist comes into play when >>>> you add @xml:lang to this. But the current Guidelines recommend to >>>> use komponiert von, not the proper noun. >>>> As I said, I see a benefit in etc., but I would really >>>> like to restrict these elements as much as possible. >>>> >>>> There is some risk down that road ? I see MEI having to deal with the >>>> same philosophical questions TEI has stumbled over, namely the >>>> discussion about the distinction between persNames and persons. Don't >>>> you see a chance for s to stay ignorant about this? Only because they >>>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>>> Yes, it uses a slightly different model, but it actually contains the same information. >>>> >>>> If you really feel a need for those elements, I would like to draw >>>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >>> As far as I am concerned, consider the list of new elements limited to list given above. >>> >>> I don't think this discussion has anything to do with personal names >>> versus persons. I think we can avoid that topic for now. But I don't >>> endorse self-imposed ignorance of any kind. :-) >>> >>> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >>> >>> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >>> >>> >>> -- >>> p. >>> _______________________________________________ >>> 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 pdr4h at eservices.virginia.edu Fri Feb 8 16:06:14 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 8 Feb 2013 15:06:14 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk>, <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> , <81BA2560-7460-4566-A361-1F7681E19B4C@edirom.de>, Message-ID: It just occurred to me that you probably meant you want and removed as well. -- 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 Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] Sent: Friday, February 08, 2013 9:48 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names > there is not much of a difference between and . > I hardly see a war between different standards at this basic level? Precisely! That's why I don't understand the tempest their addition has created. But since you all object so strongly, I will remove them. But someone will have to explain why simple and elegant markup like the following An die ferne Geliebte (Page 1), Op. 98 Ludwig van Beethoven Aloys Jeitteles isn't possible in fileDesc and why it's not possible to capture creator-like information for musical works in without abusing . Should I also remove membership in att.coded from ? -- 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: Friday, February 08, 2013 9:22 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names Am 08.02.2013 um 15:03 schrieb "Roland, Perry (pdr4h)" : > Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them! > Yes, but we arrived there after some very intense discussions. This was probably not the best solution, but it was a solution that everyone could agree on. To paraphrase you, we managed to upset everyone to the same degree. If you start the discussion over and over again, you don't accept this balance. > The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good. > >> This example illustrates the problem of attributes referring to each other. > > Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me. > >> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values >> for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for >> other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're >> quite safe _by following a convention as expressed in the Guidelines_. > > Ok, so don't sue me. Just go with it. It's not about blaming someone. We all agree that this isn't simple, that there is no perfect solution, and that one has to be conscious about the model he uses. There is nothing wrong in discussing the benefits and drawbacks of certain models. I'm just reluctant to add yet another possibility getting confused. > >> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is >> the case, I would probably argue to follow TEI in the the land of , etc. The s would >> then point to s, which in turn may have multiple references to authorities (probably using or >> some such as child elements). There would be no direct linking from the individual names anymore. > > Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious. > But if I overlook the discussion correctly, it seems like you're the only one insisting on introducing and the like. If we'd leave that out and stick with the situation we had in 2.0.0, there is no issue. And to be honest, up to the level we discuss here, there is not much of a difference between and . I hardly see a war between different standards at this basic level? I don't want to kill the discussion here, but if you have so many other obligations (and I know you have), do we really need to add this? Or wouldn't it be easier to remove it from the dev version? Is there someone else sufficiently attracted by the proposed elements to keep the discussion going? Best, jo > -- > 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: Friday, February 08, 2013 5:32 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : > >> Hi all, >> >> I guess I was just hoping somehow to stay out of this... sorry :-) >> >> I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. >> >> I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. >> >> I see another conceptual problem concerning @authority or @authURI as used in Perry's example: >> Composed by >> >> Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have >> cmp >> or >> composer >> but not >> Komponiert von >> ? or am I mistaking? > > Again, let's have a look at the friendly manual. We have an example on page 217, which reads > > authURI="http://d-nb.info/gnd" > authority="GND" > dbkey="118584596" > role="composer">Wolfgang Amadeus Mozart > > This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: > > "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." > > This can be understood as a default specification of the values of @role. The Guidelines continue: > > "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." > > These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. > > So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. > > Best, > Johannes > > > > >> >> Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: >> >> Beethoven >> >> That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to >> fl. >> >> Any thoughts on how to solve this? >> >> /axel >> >> -----Oprindelig meddelelse----- >> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl >> Sendt: 8. februar 2013 09:47 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] Encoding of personal names >> >> On a scond try of replying to this mail... >> >> 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. >> >> 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. >> >> 3) should definitely be allowed in >> >> 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: >> >> Beethoven, Ludwig >> van1770-1827 >> >> The date is not part of the person's name, although it's additional info for identifying purposes etc. >> Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. >> >> >> composed by >> Beethoven, Ludwig van >> 1811-1812 >> >> similar to ! >> But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. >> Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" >> (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? >> >> 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. >> >> 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? >> It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). >> >> >> cheers, >> benni >> >> Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>>> Ah, here are the worms, freshly served from the foothills of the blue >>>> ridge mountains ;-) >>> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >>> >>>> Perry, honestly, I remember myriads of discussions about this, and >>>> you still have this tendency of relapsing. >>> Is this a subtle way of saying I'm old? :-) In any case, what you >>> call "relapsing", I call "reconsideration" or "refinement". But to >>> paraphrase Ronald Reagan, I won't hold your youth and inexperience >>> against you. ;-) >>> >>>> First, what I miss in your post is an example of these elements in the context of . >>>> You mention this is the meatful part, but only telling us about the >>>> food makes us hungry, not well-fed (and convinced). >>> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >>> >>> In text, a bibliographic entity might be described using the >>> bibliographic components allowed in inline text (as in the 1st >>> paragraph) or with more detail using the element -- >>> >>>
>>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>>

But it's more formally described as >>> >>> Beethoven, Ludwig van, 1770-1827. >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >>> . >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> . >>> >>>

>>>
>>> >>> [Unfortunately, this example doesn't allow , but it should. >>> It's just an oversight in the ODD revision.] >>> >>> With only slight modification, mostly by eliminating separating >>> punctuation, this publication can be described as the source of an MEI >>> encoding using -- >>> >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Urtext herausgegeben von >>> Jonathan Del Mar >>> >>> >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> >>> >>> >>> and the MEI encoding itself can be described by -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> >>> >>> or, if composer and encoder are thought to be of equal importance -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> >>> Composed by >>> Beethoven, Ludwig van, 1770-1827 >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >>> >>> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >>> >>> With the addition of @code on , the preceding example could be >>> enhanced -- >>> >>> >> code="cmp">Composed by Beethoven, Ludwig van, >>> 1770-1827 >>> >>>> It's not that I don't see the usefulness of these elements, it's just >>>> that I don't see a clear line where to stop when adding these >>>> elements. I also totally agree that is useful (for >>>> transcribing sources), although I see no difference about this in >>>> and . I think the distinction we made (after passing >>>> the long and wormy road of discussion?) is pretty useful: for >>>> the texty part of a description, @code on names for processing. >>>> Requiring may be useful for certain , like inside a >>>> , but what do you plan to transcribe in the >>>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>>> it is by definition the file your operating in. You're about to >>>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >>> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >>> >>>> The benefit of Komponist comes into play when >>>> you add @xml:lang to this. But the current Guidelines recommend to >>>> use komponiert von, not the proper noun. >>>> As I said, I see a benefit in etc., but I would really >>>> like to restrict these elements as much as possible. >>>> >>>> There is some risk down that road ? I see MEI having to deal with the >>>> same philosophical questions TEI has stumbled over, namely the >>>> discussion about the distinction between persNames and persons. Don't >>>> you see a chance for s to stay ignorant about this? Only because they >>>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>>> Yes, it uses a slightly different model, but it actually contains the same information. >>>> >>>> If you really feel a need for those elements, I would like to draw >>>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >>> As far as I am concerned, consider the list of new elements limited to list given above. >>> >>> I don't think this discussion has anything to do with personal names >>> versus persons. I think we can avoid that topic for now. But I don't >>> endorse self-imposed ignorance of any kind. :-) >>> >>> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >>> >>> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >>> >>> >>> -- >>> p. >>> _______________________________________________ >>> 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 kepper at edirom.de Fri Feb 8 16:09:32 2013 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 8 Feb 2013 16:09:32 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk>, <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> , <81BA2560-7460-4566-A361-1F7681E19B4C@edirom.de> Message-ID: <12748906-58AF-443E-B3BB-BD9C048BD5DA@edirom.de> Am 08.02.2013 um 15:48 schrieb "Roland, Perry (pdr4h)" : >> there is not much of a difference between and . >> I hardly see a war between different standards at this basic level? > > Precisely! That's why I don't understand the tempest their addition has created. But since you all object so strongly, I will remove them. But someone will have to explain why simple and elegant markup like the following > > > An die ferne Geliebte (Page 1), Op. 98 > Ludwig van Beethoven > Aloys Jeitteles > > > isn't possible in fileDesc and why it's not possible to capture creator-like information for musical works in without abusing . > I think no one would complain about this in the first place. But we always mixed this with the respective elements inside a respStmt. And we all had problems to justify a clear line of acceptable elements. As long as we feel uncomfortable with adding elements for all the values in the MARC relator list (and possibly beyond), and we can't establish a defensible line, it seems preferable to don't go there _right now_. I totally agree that the above markup has it's appeal, but I for myself can't find a reasonable end for this syntactic sugar (and yes, I still call it like this) which is valid for MEI *in general*. I like to go back to square one, think over the whole thing, and as soon as we all have a new balance, equally displeasing ourselves, we can move there. There is no need to rush, especially since we're not adding a feature currently missing with all this. > Should I also remove membership in att.coded from ? > Which attributes do you have in att.coded? Have you moved the various @code's in there? If so, what should it do at in the first place? Best, jo > -- > 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: Friday, February 08, 2013 9:22 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Am 08.02.2013 um 15:03 schrieb "Roland, Perry (pdr4h)" : > >> Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them! >> > > Yes, but we arrived there after some very intense discussions. This was probably not the best solution, but it was a solution that everyone could agree on. To paraphrase you, we managed to upset everyone to the same degree. If you start the discussion over and over again, you don't accept this balance. > >> The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good. >> >>> This example illustrates the problem of attributes referring to each other. >> >> Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me. >> >>> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values >>> for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for >>> other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're >>> quite safe _by following a convention as expressed in the Guidelines_. >> >> Ok, so don't sue me. Just go with it. > > It's not about blaming someone. We all agree that this isn't simple, that there is no perfect solution, and that one has to be conscious about the model he uses. There is nothing wrong in discussing the benefits and drawbacks of certain models. I'm just reluctant to add yet another possibility getting confused. > >> >>> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is >>> the case, I would probably argue to follow TEI in the the land of , etc. The s would >>> then point to s, which in turn may have multiple references to authorities (probably using or >>> some such as child elements). There would be no direct linking from the individual names anymore. >> >> Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious. >> > > But if I overlook the discussion correctly, it seems like you're the only one insisting on introducing and the like. If we'd leave that out and stick with the situation we had in 2.0.0, there is no issue. And to be honest, up to the level we discuss here, there is not much of a difference between and . I hardly see a war between different standards at this basic level? > > > I don't want to kill the discussion here, but if you have so many other obligations (and I know you have), do we really need to add this? Or wouldn't it be easier to remove it from the dev version? Is there someone else sufficiently attracted by the proposed elements to keep the discussion going? > > Best, > jo > > > >> -- >> 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: Friday, February 08, 2013 5:32 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Encoding of personal names >> >> Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : >> >>> Hi all, >>> >>> I guess I was just hoping somehow to stay out of this... sorry :-) >>> >>> I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. >>> >>> I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. >>> >>> I see another conceptual problem concerning @authority or @authURI as used in Perry's example: >>> Composed by >>> >>> Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have >>> cmp >>> or >>> composer >>> but not >>> Komponiert von >>> ? or am I mistaking? >> >> Again, let's have a look at the friendly manual. We have an example on page 217, which reads >> >> > authURI="http://d-nb.info/gnd" >> authority="GND" >> dbkey="118584596" >> role="composer">Wolfgang Amadeus Mozart >> >> This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: >> >> "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." >> >> This can be understood as a default specification of the values of @role. The Guidelines continue: >> >> "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." >> >> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. >> >> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. >> >> Best, >> Johannes >> >> >> >> >>> >>> Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: >>> >>> Beethoven >>> >>> That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to >>> fl. >>> >>> Any thoughts on how to solve this? >>> >>> /axel >>> >>> -----Oprindelig meddelelse----- >>> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl >>> Sendt: 8. februar 2013 09:47 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] Encoding of personal names >>> >>> On a scond try of replying to this mail... >>> >>> 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. >>> >>> 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. >>> >>> 3) should definitely be allowed in >>> >>> 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: >>> >>> Beethoven, Ludwig >>> van1770-1827 >>> >>> The date is not part of the person's name, although it's additional info for identifying purposes etc. >>> Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. >>> >>> >>> composed by >>> Beethoven, Ludwig van >>> 1811-1812 >>> >>> similar to ! >>> But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. >>> Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" >>> (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? >>> >>> 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. >>> >>> 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? >>> It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). >>> >>> >>> cheers, >>> benni >>> >>> Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>>>> Ah, here are the worms, freshly served from the foothills of the blue >>>>> ridge mountains ;-) >>>> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >>>> >>>>> Perry, honestly, I remember myriads of discussions about this, and >>>>> you still have this tendency of relapsing. >>>> Is this a subtle way of saying I'm old? :-) In any case, what you >>>> call "relapsing", I call "reconsideration" or "refinement". But to >>>> paraphrase Ronald Reagan, I won't hold your youth and inexperience >>>> against you. ;-) >>>> >>>>> First, what I miss in your post is an example of these elements in the context of . >>>>> You mention this is the meatful part, but only telling us about the >>>>> food makes us hungry, not well-fed (and convinced). >>>> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >>>> >>>> In text, a bibliographic entity might be described using the >>>> bibliographic components allowed in inline text (as in the 1st >>>> paragraph) or with more detail using the element -- >>>> >>>>
>>>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>>>

But it's more formally described as >>>> >>>> Beethoven, Ludwig van, 1770-1827. >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >>>> . >>>> >>>> Kassel ; New York >>>> B?renreiter >>>> c2001 >>>> . >>>> >>>>

>>>>
>>>> >>>> [Unfortunately, this example doesn't allow , but it should. >>>> It's just an oversight in the ODD revision.] >>>> >>>> With only slight modification, mostly by eliminating separating >>>> punctuation, this publication can be described as the source of an MEI >>>> encoding using -- >>>> >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >>>> Beethoven, Ludwig van, 1770-1827 >>>> >>>> Urtext herausgegeben von >>>> Jonathan Del Mar >>>> >>>> >>>> >>>> Kassel ; New York >>>> B?renreiter >>>> c2001 >>>> >>>> >>>> >>>> and the MEI encoding itself can be described by -- >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>>> no. 7 in A major: op. 92 >>>> Beethoven, Ludwig van, 1770-1827 >>>> >>>> Encoded by >>>> Maja Hartwig >>>> Kristina Richts >>>> >>>> >>>> >>>> >>>> >>>> or, if composer and encoder are thought to be of equal importance -- >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>>> no. 7 in A major: op. 92 >>>> >>>> Composed by >>>> Beethoven, Ludwig van, 1770-1827 >>>> Encoded by >>>> Maja Hartwig >>>> Kristina Richts >>>> >>>> >>>> >>>> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >>>> >>>> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >>>> >>>> With the addition of @code on , the preceding example could be >>>> enhanced -- >>>> >>>> >>> code="cmp">Composed by Beethoven, Ludwig van, >>>> 1770-1827 >>>> >>>>> It's not that I don't see the usefulness of these elements, it's just >>>>> that I don't see a clear line where to stop when adding these >>>>> elements. I also totally agree that is useful (for >>>>> transcribing sources), although I see no difference about this in >>>>> and . I think the distinction we made (after passing >>>>> the long and wormy road of discussion?) is pretty useful: for >>>>> the texty part of a description, @code on names for processing. >>>>> Requiring may be useful for certain , like inside a >>>>> , but what do you plan to transcribe in the >>>>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>>>> it is by definition the file your operating in. You're about to >>>>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >>>> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >>>> >>>>> The benefit of Komponist comes into play when >>>>> you add @xml:lang to this. But the current Guidelines recommend to >>>>> use komponiert von, not the proper noun. >>>>> As I said, I see a benefit in etc., but I would really >>>>> like to restrict these elements as much as possible. >>>>> >>>>> There is some risk down that road ? I see MEI having to deal with the >>>>> same philosophical questions TEI has stumbled over, namely the >>>>> discussion about the distinction between persNames and persons. Don't >>>>> you see a chance for s to stay ignorant about this? Only because they >>>>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>>>> Yes, it uses a slightly different model, but it actually contains the same information. >>>>> >>>>> If you really feel a need for those elements, I would like to draw >>>>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >>>> As far as I am concerned, consider the list of new elements limited to list given above. >>>> >>>> I don't think this discussion has anything to do with personal names >>>> versus persons. I think we can avoid that topic for now. But I don't >>>> endorse self-imposed ignorance of any kind. :-) >>>> >>>> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >>>> >>>> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >>>> >>>> >>>> -- >>>> p. >>>> _______________________________________________ >>>> 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 atge at kb.dk Fri Feb 8 16:13:17 2013 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 8 Feb 2013 15:13:17 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk>, <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> , <81BA2560-7460-4566-A361-1F7681E19B4C@edirom.de>, Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D173D49538@EXCHANGE-01.kb.dk> >Precisely! That's why I don't understand the tempest their addition has created. But since you all object so >strongly, I will remove them. [...] >isn't possible in fileDesc and why it's not possible to capture creator-like information for musical works in without abusing . Theoretically, I agree it's best not add these elements. From a pragmatic point of view... well, following the recent discussion we had just implemented and for letter references in MerMEId. So now I would have to remove them again. Anyway, I am not going to postpone (again) the opening of the MerMEId demo version we have scheduled for next week. Instead, we'll offer a transformation to whatever we will agree on when MEI2013 is released. It's hard to follow a target moving as fast as MEI :-) Best, Axel __________________________ 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: Friday, February 08, 2013 9:22 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names Am 08.02.2013 um 15:03 schrieb "Roland, Perry (pdr4h)" : > Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them! > Yes, but we arrived there after some very intense discussions. This was probably not the best solution, but it was a solution that everyone could agree on. To paraphrase you, we managed to upset everyone to the same degree. If you start the discussion over and over again, you don't accept this balance. > The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good. > >> This example illustrates the problem of attributes referring to each other. > > Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me. > >> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values >> for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for >> other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're >> quite safe _by following a convention as expressed in the Guidelines_. > > Ok, so don't sue me. Just go with it. It's not about blaming someone. We all agree that this isn't simple, that there is no perfect solution, and that one has to be conscious about the model he uses. There is nothing wrong in discussing the benefits and drawbacks of certain models. I'm just reluctant to add yet another possibility getting confused. > >> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is >> the case, I would probably argue to follow TEI in the the land of , etc. The s would >> then point to s, which in turn may have multiple references to authorities (probably using or >> some such as child elements). There would be no direct linking from the individual names anymore. > > Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious. > But if I overlook the discussion correctly, it seems like you're the only one insisting on introducing and the like. If we'd leave that out and stick with the situation we had in 2.0.0, there is no issue. And to be honest, up to the level we discuss here, there is not much of a difference between and . I hardly see a war between different standards at this basic level? I don't want to kill the discussion here, but if you have so many other obligations (and I know you have), do we really need to add this? Or wouldn't it be easier to remove it from the dev version? Is there someone else sufficiently attracted by the proposed elements to keep the discussion going? Best, jo > -- > 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: Friday, February 08, 2013 5:32 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : > >> Hi all, >> >> I guess I was just hoping somehow to stay out of this... sorry :-) >> >> I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. >> >> I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. >> >> I see another conceptual problem concerning @authority or @authURI as used in Perry's example: >> Composed by >> >> Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have >> cmp >> or >> composer >> but not >> Komponiert von >> ? or am I mistaking? > > Again, let's have a look at the friendly manual. We have an example on page 217, which reads > > authURI="http://d-nb.info/gnd" > authority="GND" > dbkey="118584596" > role="composer">Wolfgang Amadeus Mozart > > This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: > > "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." > > This can be understood as a default specification of the values of @role. The Guidelines continue: > > "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." > > These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. > > So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. > > Best, > Johannes > > > > >> >> Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: >> >> Beethoven >> >> That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to >> fl. >> >> Any thoughts on how to solve this? >> >> /axel >> >> -----Oprindelig meddelelse----- >> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl >> Sendt: 8. februar 2013 09:47 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] Encoding of personal names >> >> On a scond try of replying to this mail... >> >> 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. >> >> 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. >> >> 3) should definitely be allowed in >> >> 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: >> >> Beethoven, Ludwig >> van1770-1827 >> >> The date is not part of the person's name, although it's additional info for identifying purposes etc. >> Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. >> >> >> composed by >> Beethoven, Ludwig van >> 1811-1812 >> >> similar to ! >> But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. >> Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" >> (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? >> >> 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. >> >> 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? >> It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). >> >> >> cheers, >> benni >> >> Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>>> Ah, here are the worms, freshly served from the foothills of the blue >>>> ridge mountains ;-) >>> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >>> >>>> Perry, honestly, I remember myriads of discussions about this, and >>>> you still have this tendency of relapsing. >>> Is this a subtle way of saying I'm old? :-) In any case, what you >>> call "relapsing", I call "reconsideration" or "refinement". But to >>> paraphrase Ronald Reagan, I won't hold your youth and inexperience >>> against you. ;-) >>> >>>> First, what I miss in your post is an example of these elements in the context of . >>>> You mention this is the meatful part, but only telling us about the >>>> food makes us hungry, not well-fed (and convinced). >>> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >>> >>> In text, a bibliographic entity might be described using the >>> bibliographic components allowed in inline text (as in the 1st >>> paragraph) or with more detail using the element -- >>> >>>
>>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>>

But it's more formally described as >>> >>> Beethoven, Ludwig van, 1770-1827. >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >>> . >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> . >>> >>>

>>>
>>> >>> [Unfortunately, this example doesn't allow , but it should. >>> It's just an oversight in the ODD revision.] >>> >>> With only slight modification, mostly by eliminating separating >>> punctuation, this publication can be described as the source of an MEI >>> encoding using -- >>> >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Urtext herausgegeben von >>> Jonathan Del Mar >>> >>> >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> >>> >>> >>> and the MEI encoding itself can be described by -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> >>> >>> or, if composer and encoder are thought to be of equal importance -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> >>> Composed by >>> Beethoven, Ludwig van, 1770-1827 >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >>> >>> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >>> >>> With the addition of @code on , the preceding example could be >>> enhanced -- >>> >>> >> code="cmp">Composed by Beethoven, Ludwig van, >>> 1770-1827 >>> >>>> It's not that I don't see the usefulness of these elements, it's just >>>> that I don't see a clear line where to stop when adding these >>>> elements. I also totally agree that is useful (for >>>> transcribing sources), although I see no difference about this in >>>> and . I think the distinction we made (after passing >>>> the long and wormy road of discussion?) is pretty useful: for >>>> the texty part of a description, @code on names for processing. >>>> Requiring may be useful for certain , like inside a >>>> , but what do you plan to transcribe in the >>>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>>> it is by definition the file your operating in. You're about to >>>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >>> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >>> >>>> The benefit of Komponist comes into play when >>>> you add @xml:lang to this. But the current Guidelines recommend to >>>> use komponiert von, not the proper noun. >>>> As I said, I see a benefit in etc., but I would really >>>> like to restrict these elements as much as possible. >>>> >>>> There is some risk down that road ? I see MEI having to deal with the >>>> same philosophical questions TEI has stumbled over, namely the >>>> discussion about the distinction between persNames and persons. Don't >>>> you see a chance for s to stay ignorant about this? Only because they >>>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>>> Yes, it uses a slightly different model, but it actually contains the same information. >>>> >>>> If you really feel a need for those elements, I would like to draw >>>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >>> As far as I am concerned, consider the list of new elements limited to list given above. >>> >>> I don't think this discussion has anything to do with personal names >>> versus persons. I think we can avoid that topic for now. But I don't >>> endorse self-imposed ignorance of any kind. :-) >>> >>> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >>> >>> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >>> >>> >>> -- >>> p. >>> _______________________________________________ >>> 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 pdr4h at eservices.virginia.edu Fri Feb 8 16:19:18 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 8 Feb 2013 15:19:18 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: <12748906-58AF-443E-B3BB-BD9C048BD5DA@edirom.de> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk>, <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> , <81BA2560-7460-4566-A361-1F7681E19B4C@edirom.de> , <12748906-58AF-443E-B3BB-BD9C048BD5DA@edirom.de> Message-ID: > Which attributes do you have in att.coded? Check mei2013.xml and decide what it should do and whether you want to keep it. I will comply. -- 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: Friday, February 08, 2013 10:09 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names Am 08.02.2013 um 15:48 schrieb "Roland, Perry (pdr4h)" : >> there is not much of a difference between and . >> I hardly see a war between different standards at this basic level? > > Precisely! That's why I don't understand the tempest their addition has created. But since you all object so strongly, I will remove them. But someone will have to explain why simple and elegant markup like the following > > > An die ferne Geliebte (Page 1), Op. 98 > Ludwig van Beethoven > Aloys Jeitteles > > > isn't possible in fileDesc and why it's not possible to capture creator-like information for musical works in without abusing . > I think no one would complain about this in the first place. But we always mixed this with the respective elements inside a respStmt. And we all had problems to justify a clear line of acceptable elements. As long as we feel uncomfortable with adding elements for all the values in the MARC relator list (and possibly beyond), and we can't establish a defensible line, it seems preferable to don't go there _right now_. I totally agree that the above markup has it's appeal, but I for myself can't find a reasonable end for this syntactic sugar (and yes, I still call it like this) which is valid for MEI *in general*. I like to go back to square one, think over the whole thing, and as soon as we all have a new balance, equally displeasing ourselves, we can move there. There is no need to rush, especially since we're not adding a feature currently missing with all this. > Should I also remove membership in att.coded from ? > Which attributes do you have in att.coded? Have you moved the various @code's in there? If so, what should it do at in the first place? Best, jo > -- > 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: Friday, February 08, 2013 9:22 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Am 08.02.2013 um 15:03 schrieb "Roland, Perry (pdr4h)" : > >> Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them! >> > > Yes, but we arrived there after some very intense discussions. This was probably not the best solution, but it was a solution that everyone could agree on. To paraphrase you, we managed to upset everyone to the same degree. If you start the discussion over and over again, you don't accept this balance. > >> The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good. >> >>> This example illustrates the problem of attributes referring to each other. >> >> Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me. >> >>> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values >>> for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for >>> other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're >>> quite safe _by following a convention as expressed in the Guidelines_. >> >> Ok, so don't sue me. Just go with it. > > It's not about blaming someone. We all agree that this isn't simple, that there is no perfect solution, and that one has to be conscious about the model he uses. There is nothing wrong in discussing the benefits and drawbacks of certain models. I'm just reluctant to add yet another possibility getting confused. > >> >>> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is >>> the case, I would probably argue to follow TEI in the the land of , etc. The s would >>> then point to s, which in turn may have multiple references to authorities (probably using or >>> some such as child elements). There would be no direct linking from the individual names anymore. >> >> Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious. >> > > But if I overlook the discussion correctly, it seems like you're the only one insisting on introducing and the like. If we'd leave that out and stick with the situation we had in 2.0.0, there is no issue. And to be honest, up to the level we discuss here, there is not much of a difference between and . I hardly see a war between different standards at this basic level? > > > I don't want to kill the discussion here, but if you have so many other obligations (and I know you have), do we really need to add this? Or wouldn't it be easier to remove it from the dev version? Is there someone else sufficiently attracted by the proposed elements to keep the discussion going? > > Best, > jo > > > >> -- >> 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: Friday, February 08, 2013 5:32 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Encoding of personal names >> >> Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : >> >>> Hi all, >>> >>> I guess I was just hoping somehow to stay out of this... sorry :-) >>> >>> I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. >>> >>> I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. >>> >>> I see another conceptual problem concerning @authority or @authURI as used in Perry's example: >>> Composed by >>> >>> Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have >>> cmp >>> or >>> composer >>> but not >>> Komponiert von >>> ? or am I mistaking? >> >> Again, let's have a look at the friendly manual. We have an example on page 217, which reads >> >> > authURI="http://d-nb.info/gnd" >> authority="GND" >> dbkey="118584596" >> role="composer">Wolfgang Amadeus Mozart >> >> This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: >> >> "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." >> >> This can be understood as a default specification of the values of @role. The Guidelines continue: >> >> "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." >> >> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. >> >> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. >> >> Best, >> Johannes >> >> >> >> >>> >>> Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: >>> >>> Beethoven >>> >>> That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to >>> fl. >>> >>> Any thoughts on how to solve this? >>> >>> /axel >>> >>> -----Oprindelig meddelelse----- >>> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl >>> Sendt: 8. februar 2013 09:47 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] Encoding of personal names >>> >>> On a scond try of replying to this mail... >>> >>> 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. >>> >>> 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. >>> >>> 3) should definitely be allowed in >>> >>> 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: >>> >>> Beethoven, Ludwig >>> van1770-1827 >>> >>> The date is not part of the person's name, although it's additional info for identifying purposes etc. >>> Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. >>> >>> >>> composed by >>> Beethoven, Ludwig van >>> 1811-1812 >>> >>> similar to ! >>> But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. >>> Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" >>> (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? >>> >>> 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. >>> >>> 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? >>> It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). >>> >>> >>> cheers, >>> benni >>> >>> Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>>>> Ah, here are the worms, freshly served from the foothills of the blue >>>>> ridge mountains ;-) >>>> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >>>> >>>>> Perry, honestly, I remember myriads of discussions about this, and >>>>> you still have this tendency of relapsing. >>>> Is this a subtle way of saying I'm old? :-) In any case, what you >>>> call "relapsing", I call "reconsideration" or "refinement". But to >>>> paraphrase Ronald Reagan, I won't hold your youth and inexperience >>>> against you. ;-) >>>> >>>>> First, what I miss in your post is an example of these elements in the context of . >>>>> You mention this is the meatful part, but only telling us about the >>>>> food makes us hungry, not well-fed (and convinced). >>>> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >>>> >>>> In text, a bibliographic entity might be described using the >>>> bibliographic components allowed in inline text (as in the 1st >>>> paragraph) or with more detail using the element -- >>>> >>>>
>>>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>>>

But it's more formally described as >>>> >>>> Beethoven, Ludwig van, 1770-1827. >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >>>> . >>>> >>>> Kassel ; New York >>>> B?renreiter >>>> c2001 >>>> . >>>> >>>>

>>>>
>>>> >>>> [Unfortunately, this example doesn't allow , but it should. >>>> It's just an oversight in the ODD revision.] >>>> >>>> With only slight modification, mostly by eliminating separating >>>> punctuation, this publication can be described as the source of an MEI >>>> encoding using -- >>>> >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >>>> Beethoven, Ludwig van, 1770-1827 >>>> >>>> Urtext herausgegeben von >>>> Jonathan Del Mar >>>> >>>> >>>> >>>> Kassel ; New York >>>> B?renreiter >>>> c2001 >>>> >>>> >>>> >>>> and the MEI encoding itself can be described by -- >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>>> no. 7 in A major: op. 92 >>>> Beethoven, Ludwig van, 1770-1827 >>>> >>>> Encoded by >>>> Maja Hartwig >>>> Kristina Richts >>>> >>>> >>>> >>>> >>>> >>>> or, if composer and encoder are thought to be of equal importance -- >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>>> no. 7 in A major: op. 92 >>>> >>>> Composed by >>>> Beethoven, Ludwig van, 1770-1827 >>>> Encoded by >>>> Maja Hartwig >>>> Kristina Richts >>>> >>>> >>>> >>>> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >>>> >>>> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >>>> >>>> With the addition of @code on , the preceding example could be >>>> enhanced -- >>>> >>>> >>> code="cmp">Composed by Beethoven, Ludwig van, >>>> 1770-1827 >>>> >>>>> It's not that I don't see the usefulness of these elements, it's just >>>>> that I don't see a clear line where to stop when adding these >>>>> elements. I also totally agree that is useful (for >>>>> transcribing sources), although I see no difference about this in >>>>> and . I think the distinction we made (after passing >>>>> the long and wormy road of discussion?) is pretty useful: for >>>>> the texty part of a description, @code on names for processing. >>>>> Requiring may be useful for certain , like inside a >>>>> , but what do you plan to transcribe in the >>>>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>>>> it is by definition the file your operating in. You're about to >>>>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >>>> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >>>> >>>>> The benefit of Komponist comes into play when >>>>> you add @xml:lang to this. But the current Guidelines recommend to >>>>> use komponiert von, not the proper noun. >>>>> As I said, I see a benefit in etc., but I would really >>>>> like to restrict these elements as much as possible. >>>>> >>>>> There is some risk down that road ? I see MEI having to deal with the >>>>> same philosophical questions TEI has stumbled over, namely the >>>>> discussion about the distinction between persNames and persons. Don't >>>>> you see a chance for s to stay ignorant about this? Only because they >>>>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>>>> Yes, it uses a slightly different model, but it actually contains the same information. >>>>> >>>>> If you really feel a need for those elements, I would like to draw >>>>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >>>> As far as I am concerned, consider the list of new elements limited to list given above. >>>> >>>> I don't think this discussion has anything to do with personal names >>>> versus persons. I think we can avoid that topic for now. But I don't >>>> endorse self-imposed ignorance of any kind. :-) >>>> >>>> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >>>> >>>> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >>>> >>>> >>>> -- >>>> p. >>>> _______________________________________________ >>>> 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 kepper at edirom.de Fri Feb 8 16:22:11 2013 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 8 Feb 2013 16:22:11 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D173D49538@EXCHANGE-01.kb.dk> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk>, <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> , <81BA2560-7460-4566-A361-1F7681E19B4C@edirom.de>, <0B6F63F59F405E4C902DFE2C2329D0D173D49538@EXCHANGE-01.kb.dk> Message-ID: <3F6BD3E5-C8A5-4878-8384-92AAE85EBEAD@edirom.de> As I said in my last mail, I'm not totally aversed to these elements. It's just that I would like to see a well-thought concept *before* going there, unintentionally causing troubles like you describe. Also, I would like to separate the situation of and / . Let's start over: Which affiliation elements do we have on the table? Where and why are they needed? jo Am 08.02.2013 um 16:13 schrieb Axel Teich Geertinger : >> Precisely! That's why I don't understand the tempest their addition has created. But since you all object so >> strongly, I will remove them. > [...] >> isn't possible in fileDesc and why it's not possible to capture creator-like information for musical works in without abusing . > > Theoretically, I agree it's best not add these elements. From a pragmatic point of view... well, following the recent discussion we had just implemented and for letter references in MerMEId. So now I would have to remove them again. Anyway, I am not going to postpone (again) the opening of the MerMEId demo version we have scheduled for next week. Instead, we'll offer a transformation to whatever we will agree on when MEI2013 is released. It's hard to follow a target moving as fast as MEI :-) > > Best, > Axel > > > __________________________ > 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: Friday, February 08, 2013 9:22 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Am 08.02.2013 um 15:03 schrieb "Roland, Perry (pdr4h)" : > >> Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them! >> > > Yes, but we arrived there after some very intense discussions. This was probably not the best solution, but it was a solution that everyone could agree on. To paraphrase you, we managed to upset everyone to the same degree. If you start the discussion over and over again, you don't accept this balance. > >> The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good. >> >>> This example illustrates the problem of attributes referring to each other. >> >> Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me. >> >>> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values >>> for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for >>> other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're >>> quite safe _by following a convention as expressed in the Guidelines_. >> >> Ok, so don't sue me. Just go with it. > > It's not about blaming someone. We all agree that this isn't simple, that there is no perfect solution, and that one has to be conscious about the model he uses. There is nothing wrong in discussing the benefits and drawbacks of certain models. I'm just reluctant to add yet another possibility getting confused. > >> >>> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is >>> the case, I would probably argue to follow TEI in the the land of , etc. The s would >>> then point to s, which in turn may have multiple references to authorities (probably using or >>> some such as child elements). There would be no direct linking from the individual names anymore. >> >> Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious. >> > > But if I overlook the discussion correctly, it seems like you're the only one insisting on introducing and the like. If we'd leave that out and stick with the situation we had in 2.0.0, there is no issue. And to be honest, up to the level we discuss here, there is not much of a difference between and . I hardly see a war between different standards at this basic level? > > > I don't want to kill the discussion here, but if you have so many other obligations (and I know you have), do we really need to add this? Or wouldn't it be easier to remove it from the dev version? Is there someone else sufficiently attracted by the proposed elements to keep the discussion going? > > Best, > jo > > > >> -- >> 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: Friday, February 08, 2013 5:32 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Encoding of personal names >> >> Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : >> >>> Hi all, >>> >>> I guess I was just hoping somehow to stay out of this... sorry :-) >>> >>> I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. >>> >>> I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. >>> >>> I see another conceptual problem concerning @authority or @authURI as used in Perry's example: >>> Composed by >>> >>> Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have >>> cmp >>> or >>> composer >>> but not >>> Komponiert von >>> ? or am I mistaking? >> >> Again, let's have a look at the friendly manual. We have an example on page 217, which reads >> >> > authURI="http://d-nb.info/gnd" >> authority="GND" >> dbkey="118584596" >> role="composer">Wolfgang Amadeus Mozart >> >> This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: >> >> "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." >> >> This can be understood as a default specification of the values of @role. The Guidelines continue: >> >> "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." >> >> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. >> >> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. >> >> Best, >> Johannes >> >> >> >> >>> >>> Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: >>> >>> Beethoven >>> >>> That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to >>> fl. >>> >>> Any thoughts on how to solve this? >>> >>> /axel >>> >>> -----Oprindelig meddelelse----- >>> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl >>> Sendt: 8. februar 2013 09:47 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] Encoding of personal names >>> >>> On a scond try of replying to this mail... >>> >>> 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. >>> >>> 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. >>> >>> 3) should definitely be allowed in >>> >>> 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: >>> >>> Beethoven, Ludwig >>> van1770-1827 >>> >>> The date is not part of the person's name, although it's additional info for identifying purposes etc. >>> Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. >>> >>> >>> composed by >>> Beethoven, Ludwig van >>> 1811-1812 >>> >>> similar to ! >>> But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. >>> Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" >>> (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? >>> >>> 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. >>> >>> 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? >>> It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). >>> >>> >>> cheers, >>> benni >>> >>> Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>>>> Ah, here are the worms, freshly served from the foothills of the blue >>>>> ridge mountains ;-) >>>> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >>>> >>>>> Perry, honestly, I remember myriads of discussions about this, and >>>>> you still have this tendency of relapsing. >>>> Is this a subtle way of saying I'm old? :-) In any case, what you >>>> call "relapsing", I call "reconsideration" or "refinement". But to >>>> paraphrase Ronald Reagan, I won't hold your youth and inexperience >>>> against you. ;-) >>>> >>>>> First, what I miss in your post is an example of these elements in the context of . >>>>> You mention this is the meatful part, but only telling us about the >>>>> food makes us hungry, not well-fed (and convinced). >>>> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >>>> >>>> In text, a bibliographic entity might be described using the >>>> bibliographic components allowed in inline text (as in the 1st >>>> paragraph) or with more detail using the element -- >>>> >>>>
>>>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>>>

But it's more formally described as >>>> >>>> Beethoven, Ludwig van, 1770-1827. >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >>>> . >>>> >>>> Kassel ; New York >>>> B?renreiter >>>> c2001 >>>> . >>>> >>>>

>>>>
>>>> >>>> [Unfortunately, this example doesn't allow , but it should. >>>> It's just an oversight in the ODD revision.] >>>> >>>> With only slight modification, mostly by eliminating separating >>>> punctuation, this publication can be described as the source of an MEI >>>> encoding using -- >>>> >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >>>> Beethoven, Ludwig van, 1770-1827 >>>> >>>> Urtext herausgegeben von >>>> Jonathan Del Mar >>>> >>>> >>>> >>>> Kassel ; New York >>>> B?renreiter >>>> c2001 >>>> >>>> >>>> >>>> and the MEI encoding itself can be described by -- >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>>> no. 7 in A major: op. 92 >>>> Beethoven, Ludwig van, 1770-1827 >>>> >>>> Encoded by >>>> Maja Hartwig >>>> Kristina Richts >>>> >>>> >>>> >>>> >>>> >>>> or, if composer and encoder are thought to be of equal importance -- >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>>> no. 7 in A major: op. 92 >>>> >>>> Composed by >>>> Beethoven, Ludwig van, 1770-1827 >>>> Encoded by >>>> Maja Hartwig >>>> Kristina Richts >>>> >>>> >>>> >>>> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >>>> >>>> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >>>> >>>> With the addition of @code on , the preceding example could be >>>> enhanced -- >>>> >>>> >>> code="cmp">Composed by Beethoven, Ludwig van, >>>> 1770-1827 >>>> >>>>> It's not that I don't see the usefulness of these elements, it's just >>>>> that I don't see a clear line where to stop when adding these >>>>> elements. I also totally agree that is useful (for >>>>> transcribing sources), although I see no difference about this in >>>>> and . I think the distinction we made (after passing >>>>> the long and wormy road of discussion?) is pretty useful: for >>>>> the texty part of a description, @code on names for processing. >>>>> Requiring may be useful for certain , like inside a >>>>> , but what do you plan to transcribe in the >>>>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>>>> it is by definition the file your operating in. You're about to >>>>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >>>> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >>>> >>>>> The benefit of Komponist comes into play when >>>>> you add @xml:lang to this. But the current Guidelines recommend to >>>>> use komponiert von, not the proper noun. >>>>> As I said, I see a benefit in etc., but I would really >>>>> like to restrict these elements as much as possible. >>>>> >>>>> There is some risk down that road ? I see MEI having to deal with the >>>>> same philosophical questions TEI has stumbled over, namely the >>>>> discussion about the distinction between persNames and persons. Don't >>>>> you see a chance for s to stay ignorant about this? Only because they >>>>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>>>> Yes, it uses a slightly different model, but it actually contains the same information. >>>>> >>>>> If you really feel a need for those elements, I would like to draw >>>>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >>>> As far as I am concerned, consider the list of new elements limited to list given above. >>>> >>>> I don't think this discussion has anything to do with personal names >>>> versus persons. I think we can avoid that topic for now. But I don't >>>> endorse self-imposed ignorance of any kind. :-) >>>> >>>> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >>>> >>>> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >>>> >>>> >>>> -- >>>> p. >>>> _______________________________________________ >>>> 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 pdr4h at eservices.virginia.edu Fri Feb 8 16:22:34 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 8 Feb 2013 15:22:34 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D173D49538@EXCHANGE-01.kb.dk> References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk>, <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> , <81BA2560-7460-4566-A361-1F7681E19B4C@edirom.de>, , <0B6F63F59F405E4C902DFE2C2329D0D173D49538@EXCHANGE-01.kb.dk> Message-ID: Sorry for the thrashing about. But if , etc. go, so also do , , and . Sorry, but you're back to , and with @role. -- 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 Axel Teich Geertinger [atge at kb.dk] Sent: Friday, February 08, 2013 10:13 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names >Precisely! That's why I don't understand the tempest their addition has created. But since you all object so >strongly, I will remove them. [...] >isn't possible in fileDesc and why it's not possible to capture creator-like information for musical works in without abusing . Theoretically, I agree it's best not add these elements. From a pragmatic point of view... well, following the recent discussion we had just implemented and for letter references in MerMEId. So now I would have to remove them again. Anyway, I am not going to postpone (again) the opening of the MerMEId demo version we have scheduled for next week. Instead, we'll offer a transformation to whatever we will agree on when MEI2013 is released. It's hard to follow a target moving as fast as MEI :-) Best, Axel __________________________ 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: Friday, February 08, 2013 9:22 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names Am 08.02.2013 um 15:03 schrieb "Roland, Perry (pdr4h)" : > Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them! > Yes, but we arrived there after some very intense discussions. This was probably not the best solution, but it was a solution that everyone could agree on. To paraphrase you, we managed to upset everyone to the same degree. If you start the discussion over and over again, you don't accept this balance. > The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good. > >> This example illustrates the problem of attributes referring to each other. > > Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me. > >> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values >> for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for >> other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're >> quite safe _by following a convention as expressed in the Guidelines_. > > Ok, so don't sue me. Just go with it. It's not about blaming someone. We all agree that this isn't simple, that there is no perfect solution, and that one has to be conscious about the model he uses. There is nothing wrong in discussing the benefits and drawbacks of certain models. I'm just reluctant to add yet another possibility getting confused. > >> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is >> the case, I would probably argue to follow TEI in the the land of , etc. The s would >> then point to s, which in turn may have multiple references to authorities (probably using or >> some such as child elements). There would be no direct linking from the individual names anymore. > > Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious. > But if I overlook the discussion correctly, it seems like you're the only one insisting on introducing and the like. If we'd leave that out and stick with the situation we had in 2.0.0, there is no issue. And to be honest, up to the level we discuss here, there is not much of a difference between and . I hardly see a war between different standards at this basic level? I don't want to kill the discussion here, but if you have so many other obligations (and I know you have), do we really need to add this? Or wouldn't it be easier to remove it from the dev version? Is there someone else sufficiently attracted by the proposed elements to keep the discussion going? Best, jo > -- > 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: Friday, February 08, 2013 5:32 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : > >> Hi all, >> >> I guess I was just hoping somehow to stay out of this... sorry :-) >> >> I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. >> >> I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. >> >> I see another conceptual problem concerning @authority or @authURI as used in Perry's example: >> Composed by >> >> Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have >> cmp >> or >> composer >> but not >> Komponiert von >> ? or am I mistaking? > > Again, let's have a look at the friendly manual. We have an example on page 217, which reads > > authURI="http://d-nb.info/gnd" > authority="GND" > dbkey="118584596" > role="composer">Wolfgang Amadeus Mozart > > This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: > > "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." > > This can be understood as a default specification of the values of @role. The Guidelines continue: > > "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." > > These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. > > So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. > > Best, > Johannes > > > > >> >> Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: >> >> Beethoven >> >> That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to >> fl. >> >> Any thoughts on how to solve this? >> >> /axel >> >> -----Oprindelig meddelelse----- >> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl >> Sendt: 8. februar 2013 09:47 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] Encoding of personal names >> >> On a scond try of replying to this mail... >> >> 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. >> >> 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. >> >> 3) should definitely be allowed in >> >> 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: >> >> Beethoven, Ludwig >> van1770-1827 >> >> The date is not part of the person's name, although it's additional info for identifying purposes etc. >> Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. >> >> >> composed by >> Beethoven, Ludwig van >> 1811-1812 >> >> similar to ! >> But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. >> Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" >> (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? >> >> 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. >> >> 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? >> It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). >> >> >> cheers, >> benni >> >> Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>>> Ah, here are the worms, freshly served from the foothills of the blue >>>> ridge mountains ;-) >>> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >>> >>>> Perry, honestly, I remember myriads of discussions about this, and >>>> you still have this tendency of relapsing. >>> Is this a subtle way of saying I'm old? :-) In any case, what you >>> call "relapsing", I call "reconsideration" or "refinement". But to >>> paraphrase Ronald Reagan, I won't hold your youth and inexperience >>> against you. ;-) >>> >>>> First, what I miss in your post is an example of these elements in the context of . >>>> You mention this is the meatful part, but only telling us about the >>>> food makes us hungry, not well-fed (and convinced). >>> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >>> >>> In text, a bibliographic entity might be described using the >>> bibliographic components allowed in inline text (as in the 1st >>> paragraph) or with more detail using the element -- >>> >>>
>>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>>

But it's more formally described as >>> >>> Beethoven, Ludwig van, 1770-1827. >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >>> . >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> . >>> >>>

>>>
>>> >>> [Unfortunately, this example doesn't allow , but it should. >>> It's just an oversight in the ODD revision.] >>> >>> With only slight modification, mostly by eliminating separating >>> punctuation, this publication can be described as the source of an MEI >>> encoding using -- >>> >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Urtext herausgegeben von >>> Jonathan Del Mar >>> >>> >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> >>> >>> >>> and the MEI encoding itself can be described by -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> >>> >>> or, if composer and encoder are thought to be of equal importance -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> >>> Composed by >>> Beethoven, Ludwig van, 1770-1827 >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >>> >>> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >>> >>> With the addition of @code on , the preceding example could be >>> enhanced -- >>> >>> >> code="cmp">Composed by Beethoven, Ludwig van, >>> 1770-1827 >>> >>>> It's not that I don't see the usefulness of these elements, it's just >>>> that I don't see a clear line where to stop when adding these >>>> elements. I also totally agree that is useful (for >>>> transcribing sources), although I see no difference about this in >>>> and . I think the distinction we made (after passing >>>> the long and wormy road of discussion?) is pretty useful: for >>>> the texty part of a description, @code on names for processing. >>>> Requiring may be useful for certain , like inside a >>>> , but what do you plan to transcribe in the >>>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>>> it is by definition the file your operating in. You're about to >>>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >>> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >>> >>>> The benefit of Komponist comes into play when >>>> you add @xml:lang to this. But the current Guidelines recommend to >>>> use komponiert von, not the proper noun. >>>> As I said, I see a benefit in etc., but I would really >>>> like to restrict these elements as much as possible. >>>> >>>> There is some risk down that road ? I see MEI having to deal with the >>>> same philosophical questions TEI has stumbled over, namely the >>>> discussion about the distinction between persNames and persons. Don't >>>> you see a chance for s to stay ignorant about this? Only because they >>>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>>> Yes, it uses a slightly different model, but it actually contains the same information. >>>> >>>> If you really feel a need for those elements, I would like to draw >>>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >>> As far as I am concerned, consider the list of new elements limited to list given above. >>> >>> I don't think this discussion has anything to do with personal names >>> versus persons. I think we can avoid that topic for now. But I don't >>> endorse self-imposed ignorance of any kind. :-) >>> >>> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >>> >>> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >>> >>> >>> -- >>> p. >>> _______________________________________________ >>> 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 pdr4h at eservices.virginia.edu Fri Feb 8 16:38:21 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 8 Feb 2013 15:38:21 +0000 Subject: [MEI-L] Encoding of personal names In-Reply-To: References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk>, <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> , <81BA2560-7460-4566-A361-1F7681E19B4C@edirom.de>, , <0B6F63F59F405E4C902DFE2C2329D0D173D49538@EXCHANGE-01.kb.dk>, Message-ID: In fact, this calls into question all of the revisions of , including and as well as and its children, , , and . -- 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 Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] Sent: Friday, February 08, 2013 10:22 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names Sorry for the thrashing about. But if , etc. go, so also do , , and . Sorry, but you're back to , and with @role. -- 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 Axel Teich Geertinger [atge at kb.dk] Sent: Friday, February 08, 2013 10:13 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names >Precisely! That's why I don't understand the tempest their addition has created. But since you all object so >strongly, I will remove them. [...] >isn't possible in fileDesc and why it's not possible to capture creator-like information for musical works in without abusing . Theoretically, I agree it's best not add these elements. From a pragmatic point of view... well, following the recent discussion we had just implemented and for letter references in MerMEId. So now I would have to remove them again. Anyway, I am not going to postpone (again) the opening of the MerMEId demo version we have scheduled for next week. Instead, we'll offer a transformation to whatever we will agree on when MEI2013 is released. It's hard to follow a target moving as fast as MEI :-) Best, Axel __________________________ 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: Friday, February 08, 2013 9:22 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding of personal names Am 08.02.2013 um 15:03 schrieb "Roland, Perry (pdr4h)" : > Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them! > Yes, but we arrived there after some very intense discussions. This was probably not the best solution, but it was a solution that everyone could agree on. To paraphrase you, we managed to upset everyone to the same degree. If you start the discussion over and over again, you don't accept this balance. > The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good. > >> This example illustrates the problem of attributes referring to each other. > > Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me. > >> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values >> for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for >> other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're >> quite safe _by following a convention as expressed in the Guidelines_. > > Ok, so don't sue me. Just go with it. It's not about blaming someone. We all agree that this isn't simple, that there is no perfect solution, and that one has to be conscious about the model he uses. There is nothing wrong in discussing the benefits and drawbacks of certain models. I'm just reluctant to add yet another possibility getting confused. > >> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is >> the case, I would probably argue to follow TEI in the the land of , etc. The s would >> then point to s, which in turn may have multiple references to authorities (probably using or >> some such as child elements). There would be no direct linking from the individual names anymore. > > Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious. > But if I overlook the discussion correctly, it seems like you're the only one insisting on introducing and the like. If we'd leave that out and stick with the situation we had in 2.0.0, there is no issue. And to be honest, up to the level we discuss here, there is not much of a difference between and . I hardly see a war between different standards at this basic level? I don't want to kill the discussion here, but if you have so many other obligations (and I know you have), do we really need to add this? Or wouldn't it be easier to remove it from the dev version? Is there someone else sufficiently attracted by the proposed elements to keep the discussion going? Best, jo > -- > 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: Friday, February 08, 2013 5:32 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : > >> Hi all, >> >> I guess I was just hoping somehow to stay out of this... sorry :-) >> >> I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. >> >> I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. >> >> I see another conceptual problem concerning @authority or @authURI as used in Perry's example: >> Composed by >> >> Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have >> cmp >> or >> composer >> but not >> Komponiert von >> ? or am I mistaking? > > Again, let's have a look at the friendly manual. We have an example on page 217, which reads > > authURI="http://d-nb.info/gnd" > authority="GND" > dbkey="118584596" > role="composer">Wolfgang Amadeus Mozart > > This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: > > "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." > > This can be understood as a default specification of the values of @role. The Guidelines continue: > > "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." > > These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. > > So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. > > Best, > Johannes > > > > >> >> Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: >> >> Beethoven >> >> That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to >> fl. >> >> Any thoughts on how to solve this? >> >> /axel >> >> -----Oprindelig meddelelse----- >> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl >> Sendt: 8. februar 2013 09:47 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] Encoding of personal names >> >> On a scond try of replying to this mail... >> >> 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. >> >> 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. >> >> 3) should definitely be allowed in >> >> 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: >> >> Beethoven, Ludwig >> van1770-1827 >> >> The date is not part of the person's name, although it's additional info for identifying purposes etc. >> Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. >> >> >> composed by >> Beethoven, Ludwig van >> 1811-1812 >> >> similar to ! >> But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. >> Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" >> (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? >> >> 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. >> >> 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? >> It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). >> >> >> cheers, >> benni >> >> Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>>> Ah, here are the worms, freshly served from the foothills of the blue >>>> ridge mountains ;-) >>> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >>> >>>> Perry, honestly, I remember myriads of discussions about this, and >>>> you still have this tendency of relapsing. >>> Is this a subtle way of saying I'm old? :-) In any case, what you >>> call "relapsing", I call "reconsideration" or "refinement". But to >>> paraphrase Ronald Reagan, I won't hold your youth and inexperience >>> against you. ;-) >>> >>>> First, what I miss in your post is an example of these elements in the context of . >>>> You mention this is the meatful part, but only telling us about the >>>> food makes us hungry, not well-fed (and convinced). >>> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >>> >>> In text, a bibliographic entity might be described using the >>> bibliographic components allowed in inline text (as in the 1st >>> paragraph) or with more detail using the element -- >>> >>>
>>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>>

But it's more formally described as >>> >>> Beethoven, Ludwig van, 1770-1827. >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >>> . >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> . >>> >>>

>>>
>>> >>> [Unfortunately, this example doesn't allow , but it should. >>> It's just an oversight in the ODD revision.] >>> >>> With only slight modification, mostly by eliminating separating >>> punctuation, this publication can be described as the source of an MEI >>> encoding using -- >>> >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Urtext herausgegeben von >>> Jonathan Del Mar >>> >>> >>> >>> Kassel ; New York >>> B?renreiter >>> c2001 >>> >>> >>> >>> and the MEI encoding itself can be described by -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> Beethoven, Ludwig van, 1770-1827 >>> >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> >>> >>> or, if composer and encoder are thought to be of equal importance -- >>> >>> >>> Symphonies, no. 7, op. 92, A major >>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>> no. 7 in A major: op. 92 >>> >>> Composed by >>> Beethoven, Ludwig van, 1770-1827 >>> Encoded by >>> Maja Hartwig >>> Kristina Richts >>> >>> >>> >>> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >>> >>> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >>> >>> With the addition of @code on , the preceding example could be >>> enhanced -- >>> >>> >> code="cmp">Composed by Beethoven, Ludwig van, >>> 1770-1827 >>> >>>> It's not that I don't see the usefulness of these elements, it's just >>>> that I don't see a clear line where to stop when adding these >>>> elements. I also totally agree that is useful (for >>>> transcribing sources), although I see no difference about this in >>>> and . I think the distinction we made (after passing >>>> the long and wormy road of discussion?) is pretty useful: for >>>> the texty part of a description, @code on names for processing. >>>> Requiring may be useful for certain , like inside a >>>> , but what do you plan to transcribe in the >>>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>>> it is by definition the file your operating in. You're about to >>>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >>> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >>> >>>> The benefit of Komponist comes into play when >>>> you add @xml:lang to this. But the current Guidelines recommend to >>>> use komponiert von, not the proper noun. >>>> As I said, I see a benefit in etc., but I would really >>>> like to restrict these elements as much as possible. >>>> >>>> There is some risk down that road ? I see MEI having to deal with the >>>> same philosophical questions TEI has stumbled over, namely the >>>> discussion about the distinction between persNames and persons. Don't >>>> you see a chance for s to stay ignorant about this? Only because they >>>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>>> Yes, it uses a slightly different model, but it actually contains the same information. >>>> >>>> If you really feel a need for those elements, I would like to draw >>>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >>> As far as I am concerned, consider the list of new elements limited to list given above. >>> >>> I don't think this discussion has anything to do with personal names >>> versus persons. I think we can avoid that topic for now. But I don't >>> endorse self-imposed ignorance of any kind. :-) >>> >>> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >>> >>> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >>> >>> >>> -- >>> p. >>> _______________________________________________ >>> 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 kepper at edirom.de Fri Feb 8 17:38:31 2013 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 8 Feb 2013 17:38:31 +0100 Subject: [MEI-L] Encoding of personal names In-Reply-To: References: <510FF5F1.4080806@gmx.de>, <51136797.7020407@edirom.de> <51138A70.9070402@edirom.de>, <7BC57895-4C21-4F91-9E48-857DB2A46374@edirom.de> , <4E68CA58-2469-446A-BDE8-74AEDE04BE36@edirom.de> <5114BB72.9090109@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D173D4920E@EXCHANGE-01.kb.dk>, <8EB2A649-1DBA-4723-B79F-3C8AAF52361D@edirom.de> , <81BA2560-7460-4566-A361-1F7681E19B4C@edirom.de>, , <0B6F63F59F405E4C902DFE2C2329D0D173D49538@EXCHANGE-01.kb.dk>, Message-ID: <8ECD7C0F-4750-4C6B-A196-9E46E316BFF2@edirom.de> Clearly, we don't want to spill the kid with the water. There is obvious use for these elements in , and we just need to get straight about the models they follow and the consequence of their implementation in MEI. I'd suggest to let things cool down a little bit and then start over. Let us try to sort this out next week. What I post below is just a starting point for the discussion. Which elements do we have on the table? In which context should each of them be allowed? Do we need all of them? Is there something we can safely drop? Should they go a) inside a : Symphony No.5 Beethoven b) inside a : Symphony No.5 Beethoven c) inside a : Beethoven, Ludwig van, 1770-1827. ?title etc.? From my perspective, this would be in addition to the current model of etc., not a replacement. Therefore, I would like to set up a list of arguments for adding (some of) these possibilities. Raffaele, could you provide the TEI take on this? I'm sorry that this discussion extends like this, but it seems to me that we don't have a common view in the community *yet*. Let us all try to get there, and resolve this uncertainty ? not only for Axel's sake, but for all of us. Best, Johannes Am 08.02.2013 um 16:38 schrieb "Roland, Perry (pdr4h)" : > In fact, this calls into question all of the revisions of , including and as well as and its children, , , and . > > -- > 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 Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] > Sent: Friday, February 08, 2013 10:22 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Sorry for the thrashing about. But if , etc. go, so also do , , and . Sorry, but you're back to , and with @role. > > -- > 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 Axel Teich Geertinger [atge at kb.dk] > Sent: Friday, February 08, 2013 10:13 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > >> Precisely! That's why I don't understand the tempest their addition has created. But since you all object so >> strongly, I will remove them. > [...] >> isn't possible in fileDesc and why it's not possible to capture creator-like information for musical works in without abusing . > > Theoretically, I agree it's best not add these elements. From a pragmatic point of view... well, following the recent discussion we had just implemented and for letter references in MerMEId. So now I would have to remove them again. Anyway, I am not going to postpone (again) the opening of the MerMEId demo version we have scheduled for next week. Instead, we'll offer a transformation to whatever we will agree on when MEI2013 is released. It's hard to follow a target moving as fast as MEI :-) > > Best, > Axel > > > __________________________ > 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: Friday, February 08, 2013 9:22 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Encoding of personal names > > Am 08.02.2013 um 15:03 schrieb "Roland, Perry (pdr4h)" : > >> Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them! >> > > Yes, but we arrived there after some very intense discussions. This was probably not the best solution, but it was a solution that everyone could agree on. To paraphrase you, we managed to upset everyone to the same degree. If you start the discussion over and over again, you don't accept this balance. > >> The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good. >> >>> This example illustrates the problem of attributes referring to each other. >> >> Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me. >> >>> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values >>> for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for >>> other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're >>> quite safe _by following a convention as expressed in the Guidelines_. >> >> Ok, so don't sue me. Just go with it. > > It's not about blaming someone. We all agree that this isn't simple, that there is no perfect solution, and that one has to be conscious about the model he uses. There is nothing wrong in discussing the benefits and drawbacks of certain models. I'm just reluctant to add yet another possibility getting confused. > >> >>> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is >>> the case, I would probably argue to follow TEI in the the land of , etc. The s would >>> then point to s, which in turn may have multiple references to authorities (probably using or >>> some such as child elements). There would be no direct linking from the individual names anymore. >> >> Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious. >> > > But if I overlook the discussion correctly, it seems like you're the only one insisting on introducing and the like. If we'd leave that out and stick with the situation we had in 2.0.0, there is no issue. And to be honest, up to the level we discuss here, there is not much of a difference between and . I hardly see a war between different standards at this basic level? > > > I don't want to kill the discussion here, but if you have so many other obligations (and I know you have), do we really need to add this? Or wouldn't it be easier to remove it from the dev version? Is there someone else sufficiently attracted by the proposed elements to keep the discussion going? > > Best, > jo > > > >> -- >> 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: Friday, February 08, 2013 5:32 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Encoding of personal names >> >> Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger : >> >>> Hi all, >>> >>> I guess I was just hoping somehow to stay out of this... sorry :-) >>> >>> I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw ? if that is what we want ? would be to avoid special elements for specific roles (, etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with that cannot do with @role="cmp", except that in some cases we may have to choose instead of , if the role is not associated with a single person. >>> >>> I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information. >>> >>> I see another conceptual problem concerning @authority or @authURI as used in Perry's example: >>> Composed by >>> >>> Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have >>> cmp >>> or >>> composer >>> but not >>> Komponiert von >>> ? or am I mistaking? >> >> Again, let's have a look at the friendly manual. We have an example on page 217, which reads >> >> > authURI="http://d-nb.info/gnd" >> authority="GND" >> dbkey="118584596" >> role="composer">Wolfgang Amadeus Mozart >> >> This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read: >> >> "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role." >> >> This can be understood as a default specification of the values of @role. The Guidelines continue: >> >> "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used." >> >> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_. >> >> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of , etc. The s would then point to s, which in turn may have multiple references to authorities (probably using or some such as child elements). There would be no direct linking from the individual names anymore. >> >> Best, >> Johannes >> >> >> >> >>> >>> Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list: >>> >>> Beethoven >>> >>> That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to >>> fl. >>> >>> Any thoughts on how to solve this? >>> >>> /axel >>> >>> -----Oprindelig meddelelse----- >>> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl >>> Sendt: 8. februar 2013 09:47 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] Encoding of personal names >>> >>> On a scond try of replying to this mail... >>> >>> 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear. >>> >>> 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread. >>> >>> 3) should definitely be allowed in >>> >>> 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein as child of makes me feel uncomfortable. I'd prefer: >>> >>> Beethoven, Ludwig >>> van1770-1827 >>> >>> The date is not part of the person's name, although it's additional info for identifying purposes etc. >>> Then again, this is not possible within which should be an alternative for . Even if I was allowed to put in I'd expect this date to be associated with the responsibility, not the person. >>> >>> >>> composed by >>> Beethoven, Ludwig van >>> 1811-1812 >>> >>> similar to ! >>> But would not be able to hold this date of composition. Thus the benefit of explicitly marking a would deprive me of the possibilities to add additional data concerning the composition process. >>> Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author" >>> (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself? >>> >>> 5) I think we should dissalow multiple s in the same or is there any other grouping mechanism for the children of other than xml-order? Making it more feasible to process. >>> >>> 6) Still an open question for me is the @code on which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything? >>> It's definitely good to have such an attribute (as e.g. in ), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation). >>> >>> >>> cheers, >>> benni >>> >>> Am 07.02.2013 20:18, schrieb Roland, Perry (pdr4h): >>>>> Ah, here are the worms, freshly served from the foothills of the blue >>>>> ridge mountains ;-) >>>> It's what we specialize in. ;-) But it's not our entire Diet. Bah, dum, dum! >>>> >>>>> Perry, honestly, I remember myriads of discussions about this, and >>>>> you still have this tendency of relapsing. >>>> Is this a subtle way of saying I'm old? :-) In any case, what you >>>> call "relapsing", I call "reconsideration" or "refinement". But to >>>> paraphrase Ronald Reagan, I won't hold your youth and inexperience >>>> against you. ;-) >>>> >>>>> First, what I miss in your post is an example of these elements in the context of . >>>>> You mention this is the meatful part, but only telling us about the >>>>> food makes us hungry, not well-fed (and convinced). >>>> The message was long enough already. I didn't see a need to launch into another round of the discussions we endured not so long ago. But if you insist, ... >>>> >>>> In text, a bibliographic entity might be described using the >>>> bibliographic components allowed in inline text (as in the 1st >>>> paragraph) or with more detail using the element -- >>>> >>>>
>>>>

My favorite composition is Symphony No. 7 by Ludwig van Beethoven.

>>>>

But it's more formally described as >>>> >>>> Beethoven, Ludwig van, 1770-1827. >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92. >>>> . >>>> >>>> Kassel ; New York >>>> B?renreiter >>>> c2001 >>>> . >>>> >>>>

>>>>
>>>> >>>> [Unfortunately, this example doesn't allow , but it should. >>>> It's just an oversight in the ODD revision.] >>>> >>>> With only slight modification, mostly by eliminating separating >>>> punctuation, this publication can be described as the source of an MEI >>>> encoding using -- >>>> >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony no. 7 in A major: op. 92 >>>> Beethoven, Ludwig van, 1770-1827 >>>> >>>> Urtext herausgegeben von >>>> Jonathan Del Mar >>>> >>>> >>>> >>>> Kassel ; New York >>>> B?renreiter >>>> c2001 >>>> >>>> >>>> >>>> and the MEI encoding itself can be described by -- >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>>> no. 7 in A major: op. 92 >>>> Beethoven, Ludwig van, 1770-1827 >>>> >>>> Encoded by >>>> Maja Hartwig >>>> Kristina Richts >>>> >>>> >>>> >>>> >>>> >>>> or, if composer and encoder are thought to be of equal importance -- >>>> >>>> >>>> Symphonies, no. 7, op. 92, A major >>>> <title xml:lang="de">Symphonie Nr. 7 in A-dur = Symphony >>>> no. 7 in A major: op. 92 >>>> >>>> Composed by >>>> Beethoven, Ludwig van, 1770-1827 >>>> Encoded by >>>> Maja Hartwig >>>> Kristina Richts >>>> >>>> >>>> >>>> The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc. The more we can harmonize the markup used in these places, the better. But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme. >>>> >>>> The element should be required in the example above for two reasons: 1) it makes the use of here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by". The alternative of using @role on for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against. >>>> >>>> With the addition of @code on , the preceding example could be >>>> enhanced -- >>>> >>>> >>> code="cmp">Composed by Beethoven, Ludwig van, >>>> 1770-1827 >>>> >>>>> It's not that I don't see the usefulness of these elements, it's just >>>>> that I don't see a clear line where to stop when adding these >>>>> elements. I also totally agree that is useful (for >>>>> transcribing sources), although I see no difference about this in >>>>> and . I think the distinction we made (after passing >>>>> the long and wormy road of discussion?) is pretty useful: for >>>>> the texty part of a description, @code on names for processing. >>>>> Requiring may be useful for certain , like inside a >>>>> , but what do you plan to transcribe in the >>>>> fileDesc/titleStmt/respStmt? This about an electronic resource, and >>>>> it is by definition the file your operating in. You're about to >>>>> transcribe yourself here, starting into recursion mode. I think in fileDesc may be useful if you want to add additional text, but technically, there is no benefit compared to or the like. >>>> I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one. It's clear that creation of intellectual content is primary. For this role, TEI allows only , which will not suit musical purposes. I believe we need the ones I enumerated before: , , and . and are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role. Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one. This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work". MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear. >>>> >>>>> The benefit of Komponist comes into play when >>>>> you add @xml:lang to this. But the current Guidelines recommend to >>>>> use komponiert von, not the proper noun. >>>>> As I said, I see a benefit in etc., but I would really >>>>> like to restrict these elements as much as possible. >>>>> >>>>> There is some risk down that road ? I see MEI having to deal with the >>>>> same philosophical questions TEI has stumbled over, namely the >>>>> discussion about the distinction between persNames and persons. Don't >>>>> you see a chance for s to stay ignorant about this? Only because they >>>>> have jumped out of the window, do we really have to follow? Also, what does MODS allow that isn't possible with the current set? >>>>> Yes, it uses a slightly different model, but it actually contains the same information. >>>>> >>>>> If you really feel a need for those elements, I would like to draw >>>>> the shortest possible line, allowing only the most convincing elements. But who should identify them? >>>> As far as I am concerned, consider the list of new elements limited to list given above. >>>> >>>> I don't think this discussion has anything to do with personal names >>>> versus persons. I think we can avoid that topic for now. But I don't >>>> endorse self-imposed ignorance of any kind. :-) >>>> >>>> The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS. >>>> >>>> By the same token, using the role-like elements as described above would be closer to the approach taken by MARC. I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves. >>>> >>>> >>>> -- >>>> p. >>>> _______________________________________________ >>>> 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 slu at kb.dk Thu Feb 14 10:30:51 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Thu, 14 Feb 2013 09:30:51 +0000 Subject: [MEI-L] MerMEId 2013 Message-ID: <0C090608704AF04E898055296C932B1273DC2BF7@EXCHANGE-01.kb.dk> Dear everybody, Danish Center for Music Publishing (DCM - see http://bit.ly/VhDdOP) is preparing of a thematic catalogue of Carl Nielsen's Works (CNW). For the purpose we are developing a system for the editing and handling of music metadata, based on the the MEI header. We call our system MerMEId (Metadata Editor and Repository for MEI Data - see http://bit.ly/12CUmSM). It is built using the XForms language (an MVC based language for editing XML documents) and a native XML database. We use Orbeon Forms toolkit and eXist XML database and XQuery tools, both of which are running in a tomcat servlet container together with some java minor utilities implemented in house. We are preparing the release of our latest production release, called MerMEId 2013, as open source. As a first step we have set up a demo installation where anyone can play around with the system. Anyone interested in musical metadata are welcome to http://labs.kb.dk/editor/ Have a nice Valentine day Yours, Sigfrid Lundberg and Axel Teich Geertinger From kepper at edirom.de Thu Feb 14 11:36:56 2013 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 14 Feb 2013 11:36:56 +0100 Subject: [MEI-L] MerMEId 2013 In-Reply-To: <0C090608704AF04E898055296C932B1273DC2BF7@EXCHANGE-01.kb.dk> References: <0C090608704AF04E898055296C932B1273DC2BF7@EXCHANGE-01.kb.dk> Message-ID: Dear Sigge and Axel, congratulations for making this pre-release version public. It clearly illustrates its terrific benefit for the MEI world ? thanks for your hard work on this. Now it is on us to stop putting spokes in your wheels in order to help you achieve the final production release. I especially like the documentation that you've already provided, and I'm sure everyone else also understands that it takes time to hunt down all the tiny itches and twitches. I have just one question: Do you have a public bug tracker to harvest the community's feedback in a formalized way? This is clearly already a major, impressive step for MEI ? thanks again! Best regards, Johannes Am 14.02.2013 um 10:30 schrieb Sigfrid Lundberg: > Dear everybody, > > Danish Center for Music Publishing (DCM - see http://bit.ly/VhDdOP) is preparing of a thematic catalogue of Carl Nielsen's Works (CNW). > > For the purpose we are developing a system for the editing and handling of music metadata, based on the the MEI header. We call our system MerMEId (Metadata Editor and Repository for MEI Data - see http://bit.ly/12CUmSM). It is built using the XForms language (an MVC based language for editing XML documents) and a native XML database. We use Orbeon Forms toolkit and eXist XML database and XQuery tools, both of which are running in a tomcat servlet container together with some java minor utilities implemented in house. > > We are preparing the release of our latest production release, called MerMEId 2013, as open source. As a first step we have set up a demo installation where anyone can play around with the system. > > Anyone interested in musical metadata are welcome to http://labs.kb.dk/editor/ > > Have a nice Valentine day > > Yours, > > Sigfrid Lundberg and Axel Teich Geertinger > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From bohl at edirom.de Fri Feb 15 08:15:06 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 15 Feb 2013 08:15:06 +0100 Subject: [MEI-L] MerMEId 2013 In-Reply-To: <0C090608704AF04E898055296C932B1273DC2BF7@EXCHANGE-01.kb.dk> References: <0C090608704AF04E898055296C932B1273DC2BF7@EXCHANGE-01.kb.dk> Message-ID: <511DE07A.5040108@edirom.de> Congratulations for the public demo with nice documentation! cheers benjamin Am 14.02.2013 10:30, schrieb Sigfrid Lundberg: > Dear everybody, > > Danish Center for Music Publishing (DCM - see http://bit.ly/VhDdOP) is preparing of a thematic catalogue of Carl Nielsen's Works (CNW). > > For the purpose we are developing a system for the editing and handling of music metadata, based on the the MEI header. We call our system MerMEId (Metadata Editor and Repository for MEI Data - see http://bit.ly/12CUmSM). It is built using the XForms language (an MVC based language for editing XML documents) and a native XML database. We use Orbeon Forms toolkit and eXist XML database and XQuery tools, both of which are running in a tomcat servlet container together with some java minor utilities implemented in house. > > We are preparing the release of our latest production release, called MerMEId 2013, as open source. As a first step we have set up a demo installation where anyone can play around with the system. > > Anyone interested in musical metadata are welcome to http://labs.kb.dk/editor/ > > Have a nice Valentine day > > Yours, > > Sigfrid Lundberg and Axel Teich Geertinger > _______________________________________________ > 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 Feb 15 15:22:12 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 15 Feb 2013 14:22:12 +0000 Subject: [MEI-L] MerMEId 2013 In-Reply-To: <0C090608704AF04E898055296C932B1273DC2BF7@EXCHANGE-01.kb.dk> References: <0C090608704AF04E898055296C932B1273DC2BF7@EXCHANGE-01.kb.dk> Message-ID: Hi Sigfrid and Axel, Thanks for working so diligently on this. MerMEId is a fantastic advancement for MEI. I hope you're seeing a lot of interest in it. Best wishes, -- 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 Sigfrid Lundberg [slu at kb.dk] Sent: Thursday, February 14, 2013 4:30 AM To: Music Encoding Initiative Cc: DIS-DUF; DCM-mail Subject: [MEI-L] MerMEId 2013 Dear everybody, Danish Center for Music Publishing (DCM - see http://bit.ly/VhDdOP) is preparing of a thematic catalogue of Carl Nielsen's Works (CNW). For the purpose we are developing a system for the editing and handling of music metadata, based on the the MEI header. We call our system MerMEId (Metadata Editor and Repository for MEI Data - see http://bit.ly/12CUmSM). It is built using the XForms language (an MVC based language for editing XML documents) and a native XML database. We use Orbeon Forms toolkit and eXist XML database and XQuery tools, both of which are running in a tomcat servlet container together with some java minor utilities implemented in house. We are preparing the release of our latest production release, called MerMEId 2013, as open source. As a first step we have set up a demo installation where anyone can play around with the system. Anyone interested in musical metadata are welcome to http://labs.kb.dk/editor/ Have a nice Valentine day Yours, Sigfrid Lundberg and Axel Teich Geertinger _______________________________________________ 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 Feb 20 21:13:38 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 20 Feb 2013 20:13:38 +0000 Subject: [MEI-L] Steinberg's Music Notation Software Message-ID: Of interest to some here: http://blog.steinberg.net/2013/02/welcome/ "...chronicle the development of Steinberg?s new music notation and composition application." This looks like it's the Sibelius team re-born under Steinberg. -Andrew From kepper at edirom.de Fri Feb 22 15:44:44 2013 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 22 Feb 2013 15:44:44 +0100 Subject: [MEI-L] Tech Team Meeting February 2013 Message-ID: <6F9CF944-A4DB-41B1-A579-D9AA6934E2EF@edirom.de> Dear MEI-L, the Tech Team has scheduled it's next virtual meeting, which will be on March 6th, at 17:00 MEZ 04pm GMT 11am EST 08am PST If some of you would like to join this meeting, please contact me, and I will send you the link to our conference management system. Topics will include the next release of MEI and preparation of the upcoming conference in May. You're very welcome :-) Best regards, Johannes From donbyrd at indiana.edu Tue Feb 26 04:22:10 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Mon, 25 Feb 2013 22:22:10 -0500 Subject: [MEI-L] Time representation in MEI and EDTF Message-ID: <20130225222210.e9zau6xxk4w88g40@webmail.iu.edu> All-- I've been thinking a lot recently about representing time in extremely general ways, and I've gotten involved in discussion of EDTF, an "Extended Data Time Format" under development by the bibliographic community (http://www.loc.gov/standards/datetime/). In many ways, EDTF is "extended" compared to, say, ISO 8601, but the current draft is actually more limited in at least one important way: its maximum precision is a second, while both 8601 and XSD allow seconds with several -- quite possibly an unlimited number of -- decimal places. I'm telling you this because I'd like to see a musicologist or two involved in the EDTF discussion. Furthermore, I'd like to see support for seconds with multiple decimal places added to EDTF, and the EDTF coordinator at the Library of Congress seems willing to add it _if_ someone gives him a realistic use case. I'm not sure I have a realistic bibliographic use case, but I'll bet some of you do! Also, a side question. The MEI docs keep referring to "standard ISO form" for dates and times. What is "standard ISO form"? I can't find an explanation. Does that mean ISO 8601? --Don -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington From pdr4h at eservices.virginia.edu Sun Mar 10 04:46:56 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Sun, 10 Mar 2013 03:46:56 +0000 Subject: [MEI-L] FW: ACM Symposium on Document Engineering, Sep 2013 Message-ID: Hello, I thought this symposium might be interesting to some people on this list. They're looking for "papers that describe techniques and applications of document processing within the digital humanities". MEI is a document format, music encoding is within the digital humanities, ... :-) -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________________ Date: Thu, 7 Mar 2013 10:07:40 -0500 From: "Tamir Hassan (DocEng 2013 Publicity)" Subject: Invitation to submit papers on the Digital Humanities to ACM Symposium on Document Engineering, Sep 2013 We would like to encourage you and your colleagues to submit a paper to the 13th ACM Document Engineering Symposium (DocEng) which will be held in Florence, Italy Sep 10-13 this year. DocEng provides an annual international forum for presentations and discussions on principles, tools and processes that improve our ability to create, manage and maintain documents. It is a nice friendly conference with around 70 attendees preceded by a day of workshops and tutorials. Initially DocEng had a fairly technical focus but in the last few years it has broadened scope to include important application areas including the digital humanities. The idea is not to compete with existing digital humanities publishing venues but rather to provide a quality venue for papers that describe techniques and applications of document processing within the digital humanities. Please think about submitting a paper to DocEng. More information including the CFP is available at http://www.doceng2013.org Best regards Kim Marriott (Program Chair), Simone Marinai (Symposium Chair), Tamir Hassan (Publicity Chair) ===================== Important dates ? Workshop and tutorial proposals due: Friday, March 15, 2013 ? Full papers: ? abstracts due: Sunday, March 31, 2013 ? papers due: Sunday, April 7, 2013 ? acceptance notice: Wednesday, May 15, 2013 ? Short papers: ? abstracts due: Sunday, May 19, 2013 ? papers due: Wednesday, May 22, 2013 ? acceptance notice: Friday, June 14, 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Fri Mar 15 21:49:07 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 15 Mar 2013 20:49:07 +0000 Subject: [MEI-L] Music Encoding Conference 2013 Registration In-Reply-To: References: Message-ID: =============================================================== REGISTRATION NOW OPEN! The Music Encoding Conference 2013: Concepts, Methods, Editions 22-24 May, 2013 =============================================================== The Conference Organizers are pleased to announce that registration for the Music Encoding Conference 2013 - Concepts, Methods, Editions, to be held 22-24 May, 2013, at the Mainz Academy for Literature and Sciences in Mainz, Germany is now open. CONFERENCE SCHEDULE The conference schedule is available at http://music-encoding.org/conference/program. REGISTRATION To register, visit https://music-encoding.org/conftool before April 30. There will be *no on-site registration*. If you happen to miss the registration deadline, please contact conference2013 at music-encoding.org. The regular price for the conference is 80?, but there is a discounted rate of 60? for students. Eligibility for the student rate needs to be proved on-site by showing a student ID card or similar document. We offer a one-day tutorial on MEI at no additional charge, but please select the tutorial option during registration. The conference dinner, planned for Thursday evening, costs an additional 30?. There is no reduced fee for the dinner. Additional guests may register for the dinner only. SERVICES Your registration fee includes several things. First, the venue is somewhat out of the center of Mainz, with very few options for meals nearby. Therefore, we provide lunch on Thursday and Friday. We also provide catering for coffee breaks every morning and afternoon. The fee also includes a three-day ticket (Wednesday, Thursday, Friday) for local transit within Mainz. PAYMENT DETAILS Payment options are available within ConfTool. We accept payment by bank transfer and PayPal. Select PayPal if you wish to pay by credit card. Payment is made through the Edirom Service GbR, which will appear on your receipts. This small company supports the conference by taking care of all financial details without charge. Otherwise, payment by major credit cards wouldn't be possible. ADDITIONAL INFORMATION Additional details will be announced on the conference webpage at http://music-encoding.org/conference/2013. If you have any questions, please contact conference2013 at music-encoding.org. ABOUT THE CONFERENCE Music encoding is now a prominent feature of various areas in musicology and music librarianship. The encoding of symbolic music data provides a foundation for a wide range of scholarship, and over the last several years, has garnered a great deal of attention in the digital humanities. This conference intends to provide an overview of the current state of data modeling, generation, and use, and aims to introduce new perspectives on topics in the fields of traditional and computational musicology, music librarianship, and scholarly editing, as well as in the broader area of digital humanities. With its dual focus on music encoding and editing in the context of the digital humanities, the Program Committee is happy to announce keynote lectures by Frans Wiering (Universiteit Utrecht), and Daniel Pitti (University of Virginia), both distinguished scholars in their respective fields of musicology and markup technologies in the digital humanities. ------ Program Committee: Ichiro Fujinaga, McGill University, Montreal Niels Krabbe, Det Kongelige Bibliotek, K?benhavn, Elena Pierazzo, King's College, London Eleanor Selfridge-Field, CCARH, Stanford Joachim Veit, Universit?t Paderborn, Detmold (Local) Organizers: Johannes Kepper, Universit?t Paderborn Daniel R?wenstrunk, Universit?t Paderborn Perry Roland, University of Virginia From pdr4h at eservices.virginia.edu Fri Mar 22 19:45:43 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 22 Mar 2013 18:45:43 +0000 Subject: [MEI-L] Music Encoding Conference: Call for late-breaking papers/posters Message-ID: Dear friends, Please forgive duplicate postings. The Music Encoding Conference 2013 Concepts, Methods, Editions 22-24 May, 2013 The Program Committee is happy to announce that "late-breaking" paper and poster submissions will be accepted until April 7th. "Late-breaking" papers and posters usually describe projects or research under development or present results that were not available at the time of the original call for submissions. "Late-breaking" submissions will be subject to the same review process as before. Please visit https://music-encoding.org/conference/submission for more details. Please note that there is very limited space for additional oral presentations and posters. Notification of acceptance will occur on or before April 22nd. If you have any questions, please contact conference2013 at music-encoding.org. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu From esfield at stanford.edu Wed Mar 27 01:46:47 2013 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Tue, 26 Mar 2013 17:46:47 -0700 (PDT) Subject: [MEI-L] "music discovery requirements" from Notes 69/3 (2013) Message-ID: http://muse.jhu.edu/journals/notes/v069/69.3.newcomer.html This link should take you to a new, quite comprehensive article on "music discovery", the fruit of extensive consideration by the (US) Music Library Association. It focuses mainly on scores, for which reason I thought that those of you involved in the earlier discussion of "creators" et al. might appreciate some of the commentary. I realize that it is strongly flavored by US cataloguing protocols, but there are a few topics that may resonate (in spirit, at least) with MEI. If you cannot open the link, please let me know and I will download the PDF. Best regards, Eleanor Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bohl at edirom.de Fri Apr 5 08:41:22 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 05 Apr 2013 08:41:22 +0200 Subject: [MEI-L] Time representation in MEI and EDTF In-Reply-To: <20130225222210.e9zau6xxk4w88g40@webmail.iu.edu> References: <20130225222210.e9zau6xxk4w88g40@webmail.iu.edu> Message-ID: <515E7212.6030609@edirom.de> Hi Don, took me a while to look what this interesting email subject was all about and it is really interesting! The notions of implementing certainty in a timeformat that EDTF puts forward is certainly very promising for dating issues, although this might be conflicting with the possibilities metadata formats already give. An implementation of a fixed EDTF standard in a format already providing possibilities like certainty/uncertainty, not-before, not-after, etc. will result in even more ways of encoding the same thing, as metadata formats certainly won't easily drop such features. If it comes to music the decimal digits of seconds might not be interesting for source dating but for metadata of audio files, CDs, LPs or any other sound carrier. Also in things like performance analysis, or semiautomatic audio data analysis or some MIR issues, precise timecodes are essential. From my audio engineering background I'd even say that you'll need at least 3 digits decimal places. In binaural tests 10ms delay between the same signal on both ears have been proved to be audible by almost everybody. Trained audio engineers / musicians (the best of wich were percussionists) can hear differences smaller than 5ms, even a 1ms delay can be heard. Now for example describing digitized audio material, I don't see why one should not be able to describe sample positions, e.g. hh:mm:ss:sample. With audio samplerates of standardized sound carriers ranging as high as 192kHz this would mean a sample is something like 0.0052 milliseconds! Nevertheless there are phenomena on intersample level which lead DAW (Digital Audio Workstation) plugin developers to start oversampling in their software. The more technical we get on this the smaller will the time units get ;-) To cite someone fequently posting here: "just my two cents" cheers, Benjamin Am 26.02.2013 04:22, schrieb Byrd, Donald A.: > All-- > > I've been thinking a lot recently about representing time in extremely > general ways, and I've gotten involved in discussion of EDTF, an > "Extended Data Time Format" under development by the bibliographic > community (http://www.loc.gov/standards/datetime/). In many ways, EDTF > is "extended" compared to, say, ISO 8601, but the current draft is > actually more limited in at least one important way: its maximum > precision is a second, while both 8601 and XSD allow seconds with > several -- quite possibly an unlimited number of -- decimal places. > > I'm telling you this because I'd like to see a musicologist or two > involved in the EDTF discussion. Furthermore, I'd like to see support > for seconds with multiple decimal places added to EDTF, and the EDTF > coordinator at the Library of Congress seems willing to add it _if_ > someone gives him a realistic use case. I'm not sure I have a > realistic bibliographic use case, but I'll bet some of you do! > > Also, a side question. The MEI docs keep referring to "standard ISO > form" for dates and times. What is "standard ISO form"? I can't find > an explanation. Does that mean ISO 8601? > > --Don > > > -- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > Indiana University Bloomington > > > _______________________________________________ > 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 Fri Apr 5 22:36:22 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Fri, 05 Apr 2013 16:36:22 -0400 Subject: [MEI-L] Time representation in MEI and EDTF Message-ID: <20130405163622.oft4cnts4kkg88ss@webmail.iu.edu> On Fri, 05 Apr 2013 08:41:22 +0200, Benjamin Wolff Bohl wrote: > Hi Don, > took me a while to look what this interesting email subject was all > about and it is really interesting! The notions of implementing > certainty in a timeformat that EDTF puts forward is certainly very > promising for dating issues, although this might be conflicting with > the possibilities metadata formats already give. An implementation of > a fixed EDTF standard in a format already providing possibilities > like certainty/uncertainty, not-before, not-after, etc. will result > in even more ways of encoding the same thing, as metadata formats > certainly won't easily drop such features. > If it comes to music the decimal digits of seconds might not be > interesting for source dating but for metadata of audio files, CDs, > LPs or any other sound carrier. Also in things like performance > analysis, or semiautomatic audio data analysis or some MIR issues, > precise timecodes are essential. > From my audio engineering background I'd even say that you'll need at > least 3 digits decimal places. In binaural tests 10ms delay between > the same signal on both ears have been proved to be audible by almost > everybody. Trained audio engineers / musicians (the best of wich were > percussionists) can hear differences smaller than 5ms, even a 1ms > delay can be heard. Hi, Benjamin. Thanks for the reply; _I_ thought this was an interesting question, and one really deserving discussion! What you say about audible time differences agrees closely with what I've read and my own (limited) experience. Though I'm not convinced yet anyone can hear a 1 ms delay -- I would have said 2 ms or so -- but you probably know more than I do. > Now for example describing digitized audio material, I don't see why > one should not be able to describe sample positions, e.g. > hh:mm:ss:sample. > With audio samplerates of standardized sound carriers ranging as high > as 192kHz this would mean a sample is something like 0.0052 > milliseconds! > Nevertheless there are phenomena on intersample level which lead DAW > (Digital Audio Workstation) plugin developers to start oversampling > in their software. > The more technical we get on this the smaller will the time units get ;-) :-) Exactly. Oversampling involves frequencies in the megahertz, so intervals of less than a microsecond. But I think the main issues for EDTF are: (1) What range of applications it's intended to support. The official statement is the effort is "to develop a reasonably comprehensive date/time definition for the bibliographic community, as well as other interested communities, and submitting it for standardization or some other mode of formalization, for example a W3C note or an amendment to ISO 8601." Well, what other communities are interested? I suspect the academic music-encoding community is, and you and I (at least) agree that resolution of one second isn't nearly good enough! (2) Compatibility. In particular, is EDTF supposed to have the potential to replace ISO 8601? To a great extent, this is a tradeoff with difficulty of implementation. The list moderator's position seems to be "not if it makes implementing EDTF harder", but I think that's a mistake. Especially since they've already divided features into several levels, i.e., Level 0 is a subset of ISO 8601; Level 1 adds many features, and Level 2 adds more. So people that want only what ISO 8601 can deliver need only support EDTF Level 0. I think the major issues for MEI are similar. We certainly want to describe audio timing as accurately as anyone can hear, and we may want to describe digitized audio at the sample level -- but not considering oversampling, which is really just a convenience for the D/A converter. And we want to maintain compatibility with existing time representations _if_ it's not too hard. There's a lot more to say about all of this, but I'd better stop with the above twenty-two cents :-) . --DAB > To cite someone fequently posting here: > "just my two cents" > > cheers, > Benjamin > > Am 26.02.2013 04:22, schrieb Byrd, Donald A.: >> All-- >> >> I've been thinking a lot recently about representing time in >> extremely general ways, and I've gotten involved in discussion of >> EDTF, an "Extended Data Time Format" under development by the >> bibliographic community (http://www.loc.gov/standards/datetime/). In >> many ways, EDTF is "extended" compared to, say, ISO 8601, but the >> current draft is actually more limited in at least one important >> way: its maximum precision is a second, while both 8601 and XSD >> allow seconds with several -- quite possibly an unlimited number of >> -- decimal places. >> >> I'm telling you this because I'd like to see a musicologist or two >> involved in the EDTF discussion. Furthermore, I'd like to see >> support for seconds with multiple decimal places added to EDTF, and >> the EDTF coordinator at the Library of Congress seems willing to add >> it _if_ someone gives him a realistic use case. I'm not sure I have >> a realistic bibliographic use case, but I'll bet some of you do! >> >> Also, a side question. The MEI docs keep referring to "standard ISO >> form" for dates and times. What is "standard ISO form"? I can't find >> an explanation. Does that mean ISO 8601? >> >> --Don >> >> >> >> _______________________________________________ >> 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 Visiting Scientist, Research Technologies Indiana University Bloomington From raffaeleviglianti at gmail.com Tue Apr 9 20:54:54 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 9 Apr 2013 14:54:54 -0400 Subject: [MEI-L] Google Summer of Code at MITH Message-ID: Dear all, MITH is pleased to announce that Google has selected us as one of a hundred seventy seven mentoring organizations to participate in the 2013 Google Summer of Code (GSoC). Google is offering students a stipend to work with MITH and other organizations on open source projects, giving students an opportunity to see software development and open source culture outside the classroom. If you are, or know, a student interested in programming and literature, music, or some other aspect of the humanities and libraries, check out our page of ideas and our GSoC homepage . *We welcome applications for work related to MEI tool development. One of our ideas suggests to work on improving an existing MEI to VexFlow library, but other proposals are more than welcome.* In the following two weeks, we invite interested students to get in touch with mentors to discuss their project ideas. The actual application period will be between April 22nd and May 3rd. Please feel free to get in touch for further information and please spread the word to anyone you think might be interested. Best wishes, Raffaele -------------- next part -------------- An HTML attachment was scrubbed... URL: From maja.hartwig at gmx.de Fri Apr 12 11:02:10 2013 From: maja.hartwig at gmx.de (Maja Hartwig) Date: Fri, 12 Apr 2013 11:02:10 +0200 Subject: [MEI-L] graceful beams Message-ID: Dear MEIers, while working on a revised version of the MusicXML to MEI stylesheets, we noticed a situation that is not absolutely clear in MEI, or that could be improved by better documentation. We have an MusicXML file that has beamed chords with a leading grace note each. Those grace notes are not part of the beam (look at colored sample). While the old converter produces a single element which holds all chords, but also the grace notes (beginning with the second). This results in the rendition you see in the black&white sample. ? Of course MEI allows to avoid the beam element and use a beamSpan, which connects all chords to a beam from an external point, leaving out the grace notes. However, this markup seems slightly more complicated. ? (everything above is pseudo code, MEI is not working exactly like this) While we could simply stick with the beamSpan solution, I wonder if there is such thing as a grace note being member of a regular beam at all? Of course grace notes may be beamed, but only amongst their kind, correct? If this would be the case, we could simply define in the guidelines that grace notes do not attach to a beam drawn by a parent beam element. However, this solution would mean that there wouldn't be a way to attach it to that beam unless we come up with a new solution for that issue. What do you think? Have you ever seen a grace note attached to a regular beam? Do you expect that there is one out there? Don? Best, Johannes (having captured Maja's machine?) -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : PastedGraphic-1.png Dateityp : image/png Dateigr??e : 8663 bytes Beschreibung: nicht verf?gbar URL : -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : PastedGraphic-2.png Dateityp : image/png Dateigr??e : 5005 bytes Beschreibung: nicht verf?gbar URL : From zupftom at googlemail.com Fri Apr 12 12:21:53 2013 From: zupftom at googlemail.com (TW) Date: Fri, 12 Apr 2013 12:21:53 +0200 Subject: [MEI-L] graceful beams In-Reply-To: References: Message-ID: Dear Majohannes, I think grace notes could still explicitly be made part of a beam using the method you described above, using and @plist. (Or is this now called @members?) I think being forced to resort to is more than justified for the very rare or even non-existing case of grace-notes that are under the same beam with normal notes. Thomas 2013/4/12 Maja Hartwig > Dear MEIers, > > while working on a revised version of the MusicXML to MEI stylesheets, we > noticed a situation that is not absolutely clear in MEI, or that could be > improved by better documentation. We have an MusicXML file that has beamed > chords with a leading grace note each. Those grace notes are not part of > the beam (look at colored sample). While the old converter produces a > single element which holds all chords, but also the grace notes > (beginning with the second). This results in the rendition you see in the > black&white sample. > > > > > > > ? > > > Of course MEI allows to avoid the beam element and use a beamSpan, which > connects all chords to a beam from an external point, leaving out the grace > notes. However, this markup seems slightly more complicated. > > > > > > > > > ? > > > (everything above is pseudo code, MEI is not working exactly like this) > > While we could simply stick with the beamSpan solution, I wonder if there > is such thing as a grace note being member of a regular beam at all? Of > course grace notes may be beamed, but only amongst their kind, correct? If > this would be the case, we could simply define in the guidelines that grace > notes do not attach to a beam drawn by a parent beam element. However, this > solution would mean that there wouldn't be a way to attach it to that beam > unless we come up with a new solution for that issue. What do you think? > Have you ever seen a grace note attached to a regular beam? Do you expect > that there is one out there? Don? > > Best, > Johannes > > (having captured Maja's machine?) > > > > _______________________________________________ > 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: From pdr4h at eservices.virginia.edu Fri Apr 12 17:03:03 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 12 Apr 2013 15:03:03 +0000 Subject: [MEI-L] graceful beams In-Reply-To: References: Message-ID: Hi JoMaja, When you say "results in the rendition you see in the black&white sample", what's being used to produce the output? Grace notes are never connected to beams containing non-grace notes. Even though the grace notes are encoded inside the beam element, they are not logically part of the beamed group. Therefore, the software should ignore interspersed grace notes when drawing beams. Beams containing only grace notes, as you say, are a different matter. Obviously, in this case they should be connected. By the way, in your example output, the notes are misaligned. The first non-grace note in the top staff should vertically align with the first non-grace note in the bottom staff. -- 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 Maja Hartwig [maja.hartwig at gmx.de] Sent: Friday, April 12, 2013 5:02 AM To: Music Encoding Initiative Subject: [MEI-L] graceful beams Dear MEIers, while working on a revised version of the MusicXML to MEI stylesheets, we noticed a situation that is not absolutely clear in MEI, or that could be improved by better documentation. We have an MusicXML file that has beamed chords with a leading grace note each. Those grace notes are not part of the beam (look at colored sample). While the old converter produces a single element which holds all chords, but also the grace notes (beginning with the second). This results in the rendition you see in the black&white sample. ? Of course MEI allows to avoid the beam element and use a beamSpan, which connects all chords to a beam from an external point, leaving out the grace notes. However, this markup seems slightly more complicated. ? (everything above is pseudo code, MEI is not working exactly like this) While we could simply stick with the beamSpan solution, I wonder if there is such thing as a grace note being member of a regular beam at all? Of course grace notes may be beamed, but only amongst their kind, correct? If this would be the case, we could simply define in the guidelines that grace notes do not attach to a beam drawn by a parent beam element. However, this solution would mean that there wouldn't be a way to attach it to that beam unless we come up with a new solution for that issue. What do you think? Have you ever seen a grace note attached to a regular beam? Do you expect that there is one out there? Don? Best, Johannes (having captured Maja's machine?) [cid:3538974e-f8de-4fd2-a0b5-a69cccce25c0 at eservices.virginia.edu] [cid:9def1ae2-2d09-4a4b-9f05-dfd3580ec34c at eservices.virginia.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: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-1.png Type: image/png Size: 8663 bytes Desc: PastedGraphic-1.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-2.png Type: image/png Size: 5005 bytes Desc: PastedGraphic-2.png URL: From craigsapp at gmail.com Fri Apr 12 17:18:23 2013 From: craigsapp at gmail.com (Craig Sapp) Date: Fri, 12 Apr 2013 08:18:23 -0700 Subject: [MEI-L] graceful beams In-Reply-To: References: Message-ID: Hi Majohannes & JoMaja, I had Perry encode a similar example on page 3 of: http://wiki.ccarh.org/mediawiki/images/c/cb/30_short_mei_encoding_examples.pdf [image: Inline image 2] which was done Grace notes should never be beamed with regular notes so the second graphical example you gave would be an incorrect rendering of this data. The beat span should not be necessary in this case. Programmatically it takes work to determine if a beam is regular or grace: you must look inside the beam to see if the first note is regular or grace. With a beam span, to determine if it is regular or grace type, you would have to look at the next note which follows it. Also here is the other example on the above link (page 3) with a similar case: [image: Inline image 3] which is encoded as: Note that the grace notes are not attached to the beam of the regular notes even though they are not in grace-note beams. The only two cases that I can think of for beam spanning would be across barlines and in some sort of string notation to alternate playing on two different strings: [image: Inline image 4] -=+Craig On Fri, Apr 12, 2013 at 3:21 AM, TW wrote: > Dear Majohannes, > > I think grace notes could still explicitly be made part of a beam using > the method you described above, using and @plist. (Or is this > now called @members?) > I think being forced to resort to is more than justified for > the very rare or even non-existing case of grace-notes that are under the > same beam with normal notes. > > Thomas > > > > 2013/4/12 Maja Hartwig > >> Dear MEIers, >> >> while working on a revised version of the MusicXML to MEI stylesheets, we >> noticed a situation that is not absolutely clear in MEI, or that could be >> improved by better documentation. We have an MusicXML file that has beamed >> chords with a leading grace note each. Those grace notes are not part of >> the beam (look at colored sample). While the old converter produces a >> single element which holds all chords, but also the grace notes >> (beginning with the second). This results in the rendition you see in the >> black&white sample. >> >> >> >> >> >> >> ? >> >> >> Of course MEI allows to avoid the beam element and use a beamSpan, which >> connects all chords to a beam from an external point, leaving out the grace >> notes. However, this markup seems slightly more complicated. >> >> >> >> >> >> >> >> >> ? >> >> >> (everything above is pseudo code, MEI is not working exactly like this) >> >> While we could simply stick with the beamSpan solution, I wonder if there >> is such thing as a grace note being member of a regular beam at all? Of >> course grace notes may be beamed, but only amongst their kind, correct? If >> this would be the case, we could simply define in the guidelines that grace >> notes do not attach to a beam drawn by a parent beam element. However, this >> solution would mean that there wouldn't be a way to attach it to that beam >> unless we come up with a new solution for that issue. What do you think? >> Have you ever seen a grace note attached to a regular beam? Do you expect >> that there is one out there? Don? >> >> Best, >> Johannes >> >> (having captured Maja's machine?) >> >> >> >> _______________________________________________ >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2013-04-12 at 7.50.09 AM.png Type: image/png Size: 17777 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2013-04-12 at 8.14.29 AM.png Type: image/png Size: 16911 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2013-04-12 at 7.56.08 AM.png Type: image/png Size: 18032 bytes Desc: not available URL: From donbyrd at indiana.edu Sun Apr 14 00:23:39 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Sat, 13 Apr 2013 18:23:39 -0400 Subject: [MEI-L] graceful beams In-Reply-To: References: Message-ID: <20130413182339.pagg068bk0scsk8w@webmail.iu.edu> An interesting discussion! Thomas commented on "the very rare or even non-existing case of grace-notes that are under the same beam with normal notes". Perry and Craig both responded that grace notes should never be beamed with regular notes, but I disagree; "very rare" is correct. There are two issues here. (1) What's the definition of _grace note_? Of course, grace notes are normally small notes with a logical (metric) duration of zero; but both the third and 4th editions of the Harvard Dictionary of Music say large groups of grace notes _can_ take a duration (of a single note), for example in Chopin. And I've seen several examples of full-size and small notes with logical duration beamed together. (2) But even with the strict zero-duration definition, there _are_ cases where (IMHO) it's clearly proper to beam grace notes and regular notes. Here's the evidence. First, I know of published examples in Chopin (Nocturne, Op. 15 no. 2, mm. 8 & 9); Debussy (Preludes, Book 1: La Puerta del Vino and La Terrasse Des Audiences Du Clair De Lune); and Ives ("Lincoln, the Great Commoner", no. 11 in 114 Songs). The Chopin is attached (see the last two measures). As you see, in each measure, there's an ordinary notehead with a stem and beam to an ordinary note, and a stem and beam to one or more zero-duration grace notes. Also, Elaine Gould's _Behind Bars: The Definitive Guide to Music Notation_ says (p. 129) of grace notes "If accents are not appropriate, differentiate notes to be sounded on the beat either by writing them in rhythm or, alternatively, by joining them to a measured note." For the latter case, she gives an example essentially identical to the Chopin Nocturne example. And finally, in cases like this, it makes sense! FWIW, considering both the graphical and the logical aspects, Nightingale distinguishes three types of notes: * normal notes: notes with nonzero logical duration for the part they appear in, either full-size or small * grace notes: small notes with zero logical duration * cue notes: small notes with nonzero logical duration for a different part --Don On Fri, 12 Apr 2013 08:18:23 -0700, Craig Sapp wrote: > Hi Majohannes & JoMaja, > > I had Perry encode a similar example on page 3 of: > > http://wiki.ccarh.org/mediawiki/images/c/cb/30_short_mei_encoding_examples.pdf > > > [image: Inline image 2] > > which was done > > > > > > > > > > > > > > > Grace notes should never be beamed with regular notes so the second > graphical example you gave would be an incorrect rendering of this data. > The beat span should not be necessary in this case. Programmatically it > takes work to determine if a beam is regular or grace: you must look inside > the beam to see if the first note is regular or grace. With a beam span, > to determine if it is regular or grace type, you would have to look at the > next note which follows it. > > Also here is the other example on the above link (page 3) with a similar > case: > > [image: Inline image 3] > > which is encoded as: > > > > > > > > > > > Note that the grace notes are not attached to the beam of the regular notes > even though they are not in grace-note beams. > > The only two cases that I can think of for beam spanning would be across > barlines and in some sort of string notation to alternate playing on two > different strings: > > [image: Inline image 4] > > -=+Craig > > > On Fri, Apr 12, 2013 at 3:21 AM, TW wrote: > >> Dear Majohannes, >> >> I think grace notes could still explicitly be made part of a beam using >> the method you described above, using and @plist. (Or is this >> now called @members?) >> I think being forced to resort to is more than justified for >> the very rare or even non-existing case of grace-notes that are under the >> same beam with normal notes. >> >> Thomas >> >> >> >> 2013/4/12 Maja Hartwig >> >>> Dear MEIers, >>> >>> while working on a revised version of the MusicXML to MEI stylesheets, we >>> noticed a situation that is not absolutely clear in MEI, or that could be >>> improved by better documentation. We have an MusicXML file that has beamed >>> chords with a leading grace note each. Those grace notes are not part of >>> the beam (look at colored sample). While the old converter produces a >>> single element which holds all chords, but also the grace notes >>> (beginning with the second). This results in the rendition you see in the >>> black&white sample. >>> >>> >>> >>> >>> >>> >>> ... >>> >>> >>> Of course MEI allows to avoid the beam element and use a beamSpan, which >>> connects all chords to a beam from an external point, leaving out the grace >>> notes. However, this markup seems slightly more complicated. >>> >>> >>> >>> >>> >>> >>> >>> >>> ... >>> >>> >>> (everything above is pseudo code, MEI is not working exactly like this) >>> >>> While we could simply stick with the beamSpan solution, I wonder if there >>> is such thing as a grace note being member of a regular beam at all? Of >>> course grace notes may be beamed, but only amongst their kind, correct? If >>> this would be the case, we could simply define in the guidelines that grace >>> notes do not attach to a beam drawn by a parent beam element. However, this >>> solution would mean that there wouldn't be a way to attach it to that beam >>> unless we come up with a new solution for that issue. What do you think? >>> Have you ever seen a grace note attached to a regular beam? Do you expect >>> that there is one out there? Don? >>> >>> Best, >>> Johannes >>> >>> (having captured Maja's machine...) >>> >>> >> >> > -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington -------------- next part -------------- A non-text attachment was scrubbed... Name: Chopin_Nocturne_GrNoteBeams.png Type: image/png Size: 41343 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Sun Apr 14 06:17:17 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Sun, 14 Apr 2013 04:17:17 +0000 Subject: [MEI-L] graceful beams In-Reply-To: <20130413182339.pagg068bk0scsk8w@webmail.iu.edu> References: , <20130413182339.pagg068bk0scsk8w@webmail.iu.edu> Message-ID: Hi Don, Thanks for joining the discussion. I should've been wary of using the word "never". That's a dangerous word when it comes to music notation. (Note to self: Always avoid the words "always" and "never". Never use them.) Chopin's notation is usually pretty "slippery", so I'm not surprised you found evidence there to trip up the unsuspecting. However, in both the Mozart and Chopin examples, the notes in question are clearly not part of the beamed group of "principal" notes. Stem direction is the best evidence. The different stem directions leading to the beams attached to the A# in the penultimate measure of the Chopin clearly indicate that there are two "layers/parts/streams/voices" here. There isn't just one A#, but two which occupy the same visual space. The big A# just obscures the little one. The grace note A# belongs to the upper layer while the regular note A# goes with the lower one. The same thing occurs on the B natural in the last measure. Now that the part writing has been disentangled, what is most interesting is the *meaning* of this particular vertical alignment, the collision really, of a "principal" note and a "grace" note. What is Frederic trying to say? I believe he's indicating that the grace note arpeggio begins *with* the A#, not *after* it (this comports with Gould) and that the performer shouldn't rush getting to the A# at the top of the arpeggio. (By the way, I believe the sonic effect would've been the same if he'd simply written a wavy line in front of A#-C#-F#-A# in the right hand, just like what's in the left hand. But he made his choice and we have to live with it.) There's an instance in the 3rd measure of the Chopin example that's more closely analogous to the situation in the Mozart that started the discussion: the grace notes between beat 2 and its second half (assuming this notation is counted in 2/4) lie under the beam connecting the G#-A-G# sequence, but they're not touching it. In addition, they're part of their own little beamed group. They are *logically excluded* from participating in the "big beam group" in spite of occurring between its participating notes, just like the grace notes in the Mozart example. So, I stand by my assertion that grace notes are never (um, "extremely rarely") beamed with "regular" notes, where "beamed with" means "part of the same horizontal sequence as" normal-sized notes. Granted, I haven't seen the entire universe of music notation, but mixed grace- and normal-note beams are like unicorns -- I've heard talk of them, but as yet I haven't seen one. :-) -- 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 -------------- An HTML attachment was scrubbed... URL: From zupftom at googlemail.com Sun Apr 14 12:52:15 2013 From: zupftom at googlemail.com (TW) Date: Sun, 14 Apr 2013 12:52:15 +0200 Subject: [MEI-L] graceful beams In-Reply-To: References: <20130413182339.pagg068bk0scsk8w@webmail.iu.edu> Message-ID: So, to what conclusion do we come? I think MEI doesn't lack any features here, it should just be made clear at a more prominent place in the specification/documented that grace notes will graphically not be part of a beam, even if they occur within the element. If you *really* want grace notes to be part of the regular beam, you can still achieve this using existing means. Is this a valid summary of the discussion? Thomas 2013/4/14 Roland, Perry (pdr4h) > Hi Don, > > Thanks for joining the discussion. > > I should've been wary of using the word "never". That's a dangerous word > when it comes to music notation. (Note to self: Always avoid the words > "always" and "never". Never use them.) Chopin's notation is usually > pretty "slippery", so I'm not surprised you found evidence there to trip up > the unsuspecting. > > However, in both the Mozart and Chopin examples, the notes in question are > clearly not part of the beamed group of "principal" notes. Stem direction > is the best evidence. The different stem directions leading to the beams > attached to the A# in the penultimate measure of the Chopin clearly > indicate that there are two "layers/parts/streams/voices" here. There > isn't just one A#, but two which occupy the same visual space. The big A# > just obscures the little one. The grace note A# belongs to the upper layer > while the regular note A# goes with the lower one. The same thing occurs > on the B natural in the last measure. > > Now that the part writing has been disentangled, what is most interesting > is the *meaning* of this particular vertical alignment, the collision > really, of a "principal" note and a "grace" note. What is Frederic trying > to say? I believe he's indicating that the grace note arpeggio begins > *with* the A#, not *after* it (this comports with Gould) and that the > performer shouldn't rush getting to the A# at the top of the arpeggio. (By > the way, I believe the sonic effect would've been the same if he'd simply > written a wavy line in front of A#-C#-F#-A# in the right hand, just like > what's in the left hand. But he made his choice and we have to live with > it.) > > > There's an instance in the 3rd measure of the Chopin example that's more > closely analogous to the situation in the Mozart that started the > discussion: the grace notes between beat 2 and its second half (assuming > this notation is counted in 2/4) lie under the beam connecting the G#-A-G# > sequence, but they're not touching it. In addition, they're part of their > own little beamed group. They are *logically excluded* from > participating in the "big beam group" in spite of occurring between its > participating notes, just like the grace notes in the Mozart example. > > So, I stand by my assertion that grace notes are never (um, "extremely > rarely") beamed with "regular" notes, where "beamed with" means "part of > the same horizontal sequence as" normal-sized notes. Granted, I haven't > seen the entire universe of music notation, but mixed grace- and > normal-note beams are like unicorns -- I've heard talk of them, but as yet > I haven't seen one. :-) > > > -- > 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: From kepper at edirom.de Sun Apr 14 14:28:47 2013 From: kepper at edirom.de (Johannes Kepper) Date: Sun, 14 Apr 2013 14:28:47 +0200 Subject: [MEI-L] graceful beams In-Reply-To: References: <20130413182339.pagg068bk0scsk8w@webmail.iu.edu> Message-ID: <805DDBED-B372-472A-A67A-10F618EC8BEE@edirom.de> Yes, sort of. I would clarify in the guidelines that grace notes inside elements won't attach their stem to the beam, and if one wants to get this behavior, he would have to use beamSpan instead. A consequence of this is that there may be a meaning of nesting beam elements (= when there is a beamed group of grace notes), but that's allowed already. Thanks for the discussion. Best, Johannes Am 14.04.2013 um 12:52 schrieb TW : > So, to what conclusion do we come? I think MEI doesn't lack any features here, it should just be made clear at a more prominent place in the specification/documented that grace notes will graphically not be part of a beam, even if they occur within the element. If you *really* want grace notes to be part of the regular beam, you can still achieve this using existing means. > > Is this a valid summary of the discussion? > Thomas > > > > 2013/4/14 Roland, Perry (pdr4h) > Hi Don, > > Thanks for joining the discussion. > > I should've been wary of using the word "never". That's a dangerous word when it comes to music notation. (Note to self: Always avoid the words "always" and "never". Never use them.) Chopin's notation is usually pretty "slippery", so I'm not surprised you found evidence there to trip up the unsuspecting. > > However, in both the Mozart and Chopin examples, the notes in question are clearly not part of the beamed group of "principal" notes. Stem direction is the best evidence. The different stem directions leading to the beams attached to the A# in the penultimate measure of the Chopin clearly indicate that there are two "layers/parts/streams/voices" here. There isn't just one A#, but two which occupy the same visual space. The big A# just obscures the little one. The grace note A# belongs to the upper layer while the regular note A# goes with the lower one. The same thing occurs on the B natural in the last measure. > > Now that the part writing has been disentangled, what is most interesting is the *meaning* of this particular vertical alignment, the collision really, of a "principal" note and a "grace" note. What is Frederic trying to say? I believe he's indicating that the grace note arpeggio begins *with* the A#, not *after* it (this comports with Gould) and that the performer shouldn't rush getting to the A# at the top of the arpeggio. (By the way, I believe the sonic effect would've been the same if he'd simply written a wavy line in front of A#-C#-F#-A# in the right hand, just like what's in the left hand. But he made his choice and we have to live with it.) > > > There's an instance in the 3rd measure of the Chopin example that's more closely analogous to the situation in the Mozart that started the discussion: the grace notes between beat 2 and its second half (assuming this notation is counted in 2/4) lie under the beam connecting the G#-A-G# sequence, but they're not touching it. In addition, they're part of their own little beamed group. They are *logically excluded* from participating in the "big beam group" in spite of occurring between its participating notes, just like the grace notes in the Mozart example. > > So, I stand by my assertion that grace notes are never (um, "extremely rarely") beamed with "regular" notes, where "beamed with" means "part of the same horizontal sequence as" normal-sized notes. Granted, I haven't seen the entire universe of music notation, but mixed grace- and normal-note beams are like unicorns -- I've heard talk of them, but as yet I haven't seen one. :-) > > > > -- > 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 > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From litterscheid at notensatz.biz Sun Apr 14 14:31:05 2013 From: litterscheid at notensatz.biz (litterscheid at notensatz.biz) Date: Sun, 14 Apr 2013 14:31:05 +0200 Subject: [MEI-L] graceful beams In-Reply-To: References: <20130413182339.pagg068bk0scsk8w@webmail.iu.edu> Message-ID: <002d01ce390b$eee14fd0$cca3ef70$@biz> Because I have no idea how the size of a note is coded in MEI, I want t ask a question. In the attached file there is a small note (in this edition editorial addings are engraved as small notes) which HAS to be connected the the *normal* beam. I would no call that small note a grace note, but if the term *grace note* is the only way of encoding small notes, it would be good to be able to connect them to *normal* beams. Only a thought of an unknowing engraver J Frank --- NOTENSATZ LITTERSCHEID Frank Litterscheid Am Kuhkamp 7 37619 Hehlen Tel 05533 - 979733 Fax 05533 - 979732 litterscheid at notensatz.biz Von: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von TW Gesendet: Sonntag, 14. April 2013 12:52 An: Music Encoding Initiative Betreff: Re: [MEI-L] graceful beams So, to what conclusion do we come? I think MEI doesn't lack any features here, it should just be made clear at a more prominent place in the specification/documented that grace notes will graphically not be part of a beam, even if they occur within the element. If you *really* want grace notes to be part of the regular beam, you can still achieve this using existing means. Is this a valid summary of the discussion? Thomas 2013/4/14 Roland, Perry (pdr4h) Hi Don, Thanks for joining the discussion. I should've been wary of using the word "never". That's a dangerous word when it comes to music notation. (Note to self: Always avoid the words "always" and "never". Never use them.) Chopin's notation is usually pretty "slippery", so I'm not surprised you found evidence there to trip up the unsuspecting. However, in both the Mozart and Chopin examples, the notes in question are clearly not part of the beamed group of "principal" notes. Stem direction is the best evidence. The different stem directions leading to the beams attached to the A# in the penultimate measure of the Chopin clearly indicate that there are two "layers/parts/streams/voices" here. There isn't just one A#, but two which occupy the same visual space. The big A# just obscures the little one. The grace note A# belongs to the upper layer while the regular note A# goes with the lower one. The same thing occurs on the B natural in the last measure. Now that the part writing has been disentangled, what is most interesting is the *meaning* of this particular vertical alignment, the collision really, of a "principal" note and a "grace" note. What is Frederic trying to say? I believe he's indicating that the grace note arpeggio begins *with* the A#, not *after* it (this comports with Gould) and that the performer shouldn't rush getting to the A# at the top of the arpeggio. (By the way, I believe the sonic effect would've been the same if he'd simply written a wavy line in front of A#-C#-F#-A# in the right hand, just like what's in the left hand. But he made his choice and we have to live with it.) There's an instance in the 3rd measure of the Chopin example that's more closely analogous to the situation in the Mozart that started the discussion: the grace notes between beat 2 and its second half (assuming this notation is counted in 2/4) lie under the beam connecting the G#-A-G# sequence, but they're not touching it. In addition, they're part of their own little beamed group. They are *logically excluded* from participating in the "big beam group" in spite of occurring between its participating notes, just like the grace notes in the Mozart example. So, I stand by my assertion that grace notes are never (um, "extremely rarely") beamed with "regular" notes, where "beamed with" means "part of the same horizontal sequence as" normal-sized notes. Granted, I haven't seen the entire universe of music notation, but mixed grace- and normal-note beams are like unicorns -- I've heard talk of them, but as yet I haven't seen one. :-) -- 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Only_small_or_grace.jpg Type: image/jpeg Size: 12249 bytes Desc: not available URL: From kepper at edirom.de Sun Apr 14 14:45:54 2013 From: kepper at edirom.de (Johannes Kepper) Date: Sun, 14 Apr 2013 14:45:54 +0200 Subject: [MEI-L] graceful beams In-Reply-To: <002d01ce390b$eee14fd0$cca3ef70$@biz> References: <20130413182339.pagg068bk0scsk8w@webmail.iu.edu> <002d01ce390b$eee14fd0$cca3ef70$@biz> Message-ID: Hi Frank, there is an attribute @size on , which can be used independently from the @grace attribute. In other words, you don't have to call a note a grace if all you want is to change the size? Interesting example, though ;-) Sch?nen Sonntag, Johannes Am 14.04.2013 um 14:31 schrieb : > Because I have no idea how the size of a note is coded in MEI, I want t ask a question. > In the attached file there is a small note (in this edition editorial addings are engraved as small notes) which HAS to be connected the the *normal* beam. I would no call that small note a grace note, but if the term *grace note* is the only way of encoding small notes, it would be good to be able to connect them to *normal* beams. > > Only a thought of an unknowing engraver J > Frank > > --- > NOTENSATZ LITTERSCHEID > Frank Litterscheid > Am Kuhkamp 7 > 37619 Hehlen > Tel 05533 - 979733 > Fax 05533 - 979732 > litterscheid at notensatz.biz > > Von: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von TW > Gesendet: Sonntag, 14. April 2013 12:52 > An: Music Encoding Initiative > Betreff: Re: [MEI-L] graceful beams > > So, to what conclusion do we come? I think MEI doesn't lack any features here, it should just be made clear at a more prominent place in the specification/documented that grace notes will graphically not be part of a beam, even if they occur within the element. If you *really* want grace notes to be part of the regular beam, you can still achieve this using existing means. > > Is this a valid summary of the discussion? > Thomas > > > > 2013/4/14 Roland, Perry (pdr4h) > Hi Don, > > Thanks for joining the discussion. > > I should've been wary of using the word "never". That's a dangerous word when it comes to music notation. (Note to self: Always avoid the words "always" and "never". Never use them.) Chopin's notation is usually pretty "slippery", so I'm not surprised you found evidence there to trip up the unsuspecting. > > However, in both the Mozart and Chopin examples, the notes in question are clearly not part of the beamed group of "principal" notes. Stem direction is the best evidence. The different stem directions leading to the beams attached to the A# in the penultimate measure of the Chopin clearly indicate that there are two "layers/parts/streams/voices" here. There isn't just one A#, but two which occupy the same visual space. The big A# just obscures the little one. The grace note A# belongs to the upper layer while the regular note A# goes with the lower one. The same thing occurs on the B natural in the last measure. > > Now that the part writing has been disentangled, what is most interesting is the *meaning* of this particular vertical alignment, the collision really, of a "principal" note and a "grace" note. What is Frederic trying to say? I believe he's indicating that the grace note arpeggio begins *with* the A#, not *after* it (this comports with Gould) and that the performer shouldn't rush getting to the A# at the top of the arpeggio. (By the way, I believe the sonic effect would've been the same if he'd simply written a wavy line in front of A#-C#-F#-A# in the right hand, just like what's in the left hand. But he made his choice and we have to live with it.) > > > There's an instance in the 3rd measure of the Chopin example that's more closely analogous to the situation in the Mozart that started the discussion: the grace notes between beat 2 and its second half (assuming this notation is counted in 2/4) lie under the beam connecting the G#-A-G# sequence, but they're not touching it. In addition, they're part of their own little beamed group. They are *logically excluded* from participating in the "big beam group" in spite of occurring between its participating notes, just like the grace notes in the Mozart example. > > So, I stand by my assertion that grace notes are never (um, "extremely rarely") beamed with "regular" notes, where "beamed with" means "part of the same horizontal sequence as" normal-sized notes. Granted, I haven't seen the entire universe of music notation, but mixed grace- and normal-note beams are like unicorns -- I've heard talk of them, but as yet I haven't seen one. :-) > > > > -- > 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 > > > _______________________________________________ > 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 Sun Apr 14 15:32:02 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Sun, 14 Apr 2013 09:32:02 -0400 Subject: [MEI-L] graceful beams In-Reply-To: References: <20130413182339.pagg068bk0scsk8w@webmail.iu.edu> <002d01ce390b$eee14fd0$cca3ef70$@biz> Message-ID: <20130414093202.d395nzsftw0ks4cs@webmail.iu.edu> Whew; I'll try to catch up this flurry of activity before it's too late :-) . First, I agree almost 100% with Perry's analysis of the Chopin example, that it's really a (separate) grace note superimposed on the normal note; in fact, I was thinking of saying that, but I'm glad I didn't so it's clear arrived at the same conclusion independently. I seem to have deleted Maja's original message plus the Mozart example she attached; Johannes or Perry, would you mind resending it? -- but I'm sure Perry is correct about it too. This notational unicorn might exist; I'll keep my eyes peeled for it, but it's clearly SO rare, I don't think it's worth worry about. And Frank Litterscheid's example is an interesting one! But small notes that clearlyt aren't grace notes in the normal sense aren't that unusual, especially in Chopin :-) . Attached is the latest version of my "More Counterexamples in Conventional Music Notation"; section 3a lists about ten examples. --DAB On Sun, 14 Apr 2013 14:45:54 +0200, Johannes Kepper wrote: > Hi Frank, > > there is an attribute @size on , which can be used > independently from the @grace attribute. In other words, you don't > have to call a note a grace if all you want is to change the size... > > Interesting example, though ;-) > > Sch?nen Sonntag, > Johannes > > Am 14.04.2013 um 14:31 schrieb : > >> Because I have no idea how the size of a note is coded in MEI, I >> want t ask a question. >> In the attached file there is a small note (in this edition >> editorial addings are engraved as small notes) which HAS to be >> connected the the *normal* beam. I would no call that small note a >> grace note, but if the term *grace note* is the only way of encoding >> small notes, it would be good to be able to connect them to *normal* >> beams. >> >> Only a thought of an unknowing engraver J >> Frank >> >> --- >> NOTENSATZ LITTERSCHEID >> Frank Litterscheid >> Am Kuhkamp 7 >> 37619 Hehlen >> Tel 05533 - 979733 >> Fax 05533 - 979732 >> litterscheid at notensatz.biz >> >> Von: mei-l-bounces at lists.uni-paderborn.de >> [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von TW >> Gesendet: Sonntag, 14. April 2013 12:52 >> An: Music Encoding Initiative >> Betreff: Re: [MEI-L] graceful beams >> >> So, to what conclusion do we come? I think MEI doesn't lack any >> features here, it should just be made clear at a more prominent >> place in the specification/documented that grace notes will >> graphically not be part of a beam, even if they occur within the >> element. If you *really* want grace notes to be part of the >> regular beam, you can still achieve this using existing means. >> >> Is this a valid summary of the discussion? >> Thomas >> >> >> >> 2013/4/14 Roland, Perry (pdr4h) >> Hi Don, >> >> Thanks for joining the discussion. >> >> I should've been wary of using the word "never". That's a dangerous >> word when it comes to music notation. (Note to self: Always avoid >> the words "always" and "never". Never use them.) Chopin's notation >> is usually pretty "slippery", so I'm not surprised you found >> evidence there to trip up the unsuspecting. >> >> However, in both the Mozart and Chopin examples, the notes in >> question are clearly not part of the beamed group of "principal" >> notes. Stem direction is the best evidence. The different stem >> directions leading to the beams attached to the A# in the >> penultimate measure of the Chopin clearly indicate that there are >> two "layers/parts/streams/voices" here. There isn't just one A#, >> but two which occupy the same visual space. The big A# just obscures >> the little one. The grace note A# belongs to the upper layer while >> the regular note A# goes with the lower one. The same thing occurs >> on the B natural in the last measure. >> >> Now that the part writing has been disentangled, what is most >> interesting is the *meaning* of this particular vertical alignment, >> the collision really, of a "principal" note and a "grace" note. >> What is Frederic trying to say? I believe he's indicating that the >> grace note arpeggio begins *with* the A#, not *after* it (this >> comports with Gould) and that the performer shouldn't rush getting >> to the A# at the top of the arpeggio. (By the way, I believe the >> sonic effect would've been the same if he'd simply written a wavy >> line in front of A#-C#-F#-A# in the right hand, just like what's in >> the left hand. But he made his choice and we have to live with it.) >> >> >> There's an instance in the 3rd measure of the Chopin example that's >> more closely analogous to the situation in the Mozart that started >> the discussion: the grace notes between beat 2 and its second half >> (assuming this notation is counted in 2/4) lie under the beam >> connecting the G#-A-G# sequence, but they're not touching it. In >> addition, they're part of their own little beamed group. They are >> *logically excluded* from participating in the "big beam group" in >> spite of occurring between its participating notes, just like the >> grace notes in the Mozart example. >> >> So, I stand by my assertion that grace notes are never (um, >> "extremely rarely") beamed with "regular" notes, where "beamed with" >> means "part of the same horizontal sequence as" normal-sized notes. >> Granted, I haven't seen the entire universe of music notation, but >> mixed grace- and normal-note beams are like unicorns -- I've heard >> talk of them, but as yet I haven't seen one. :-) >> >> >> > -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington -------------- next part -------------- MORE COUNTEREXAMPLES IN CONVENTIONAL MUSIC NOTATION: a supplementary list by Donald Byrd, Indiana University, Bloomington Revised mid April 2013 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 (2012). 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 (2010) and my unpublished list of Music Without Barlines (2010). Thanks to Edward Auer, Lana Bode, Myke Cuthbert, Noam Elkies, Jay Hook, Thomas Loewenheim, David Meredith, and Gabi Teodoru for their contributions (noted below). THE LIST The list below is organized into top-level categories named and numbered as in the list in my dissertation. It uses the following conventions: 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. The term "chord" herein means a collection of notes on a single stem. (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) a. 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) b. Miscellaneous (NB: slurs with many inflection points were formerly listed here, but are now in my CMN Extremes list): Bartok: Two Rumanian Dances, Op. 8A no. 2 (compound beam) Beethoven: Violin Concerto (Br+H ed.), II, last measure (very wide fermata over a series of rests) 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) (4) Rhythm Notation. a. 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) *Dohnanyi: Violin Sonata, piano part (chords with quarter and half heads on same stem) [contrib. by Hook] 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) b. 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) c. 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. m. 26, 30 (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 the "quarter notes" are 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) d. Time signature change in middle of measure (B&I 10.8): Anonymous (folk song): Wassail Song (typically notated as 6/8 to C or 4/4, but 6/8 to Cut would make more sense: tempo is dotted-qtr = half) 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) e. 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) f. 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 (Muzyka (State Music Pub. House) ed.) (various conflicts??) [contrib. by Hook] Scriabin: Sonata no. 7 (Muzyka (State Music Pub. House) ed., Dover reprint), p. 148 (one notehead for normal 8th and triplet 8th ending at the same time) g. 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) h. 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) i. 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) j. Grace-note phenomena: Chopin: Nocturne, Op. 15 no. 2, mm.8 & 9 (ordinary notehead with one stem and beam to an ordinary note, and one stem and beam to grace -- not just small -- notes) Debussy: Estampes: Jardins sous la pluie (Durand, 1903) (series of 9 small-note 32nds marked "9": judging from the rhythmic context, apparently grace notes) (B&I 11.14) Debussy: Preludes, Book 1: La Puerta del Vino; La Terrasse Des Audiences Du Clair De Lune (Muzyka (State Music Pub. House)/Sorokin ed.) (normal notes beamed to grace notes) 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) Rachmaninoff: Prelude, Op. 32 no. 3 (Muzgiz ed.), mm. 23 & 24 (series of 5 small-note eighths marked "5": judging from the rhythmic context, apparently grace notes) (B&I 11.14) k. Other: 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) 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) 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. a. 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) b. One clef for two staves: Pozzoli: [solfeggio book; but NB probably published after 1935, and arguably not CMN] c. 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) d. 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) e. 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) f. 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] g. 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] h. 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) 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 (2012). Extremes of Conventional Music Notation. Retrieved June 20, 2012, from the World Wide Web: http://www.informatics.indiana.edu/donbyrd/CMNExtremes.htm . Byrd, Donald (2010). The Myth of Easy Time Signature Checking. Draft available at http://www.informatics.indiana.edu/donbyrd/Papers/CheckMeasDurVsTimeSigNotEasy.doc . Byrd, Donald, & Isaacson, Eric (2010). A Music Representation Requirement Specification for Academia. Computer Music Journal 27, no. 4 (2003), pp. 43-57; revised version retrieved February 20, 2012, from the World Wide Web: http://www.informatics.indiana.edu/donbyrd/Papers/MusicRepReqForAcad.doc . Hewlett, W., & Selfridge-Field, E. (Eds.) (1994). Music Notation Software. In Computing in Musicology, vol. 9, pp. 167-230. Hook, Julian (2011 December). How to Perform Impossible Rhythms. Music Theory Online 17, no. 4. Rastall, Richard (1982). The Notation of Western Music. New York: St. Martin's Press. From zupftom at googlemail.com Sun Apr 14 15:56:47 2013 From: zupftom at googlemail.com (TW) Date: Sun, 14 Apr 2013 15:56:47 +0200 Subject: [MEI-L] graceful beams In-Reply-To: <20130414093202.d395nzsftw0ks4cs@webmail.iu.edu> References: <20130413182339.pagg068bk0scsk8w@webmail.iu.edu> <002d01ce390b$eee14fd0$cca3ef70$@biz> <20130414093202.d395nzsftw0ks4cs@webmail.iu.edu> Message-ID: You can find the original post in the archives: https://lists.uni-paderborn.de/pipermail/mei-l/2013/000840.html 2013/4/14 Byrd, Donald A. > Whew; I'll try to catch up this flurry of activity before it's too late > :-) . > > First, I agree almost 100% with Perry's analysis of the Chopin example, > that it's really a (separate) grace note superimposed on the normal note; > in fact, I was thinking of saying that, but I'm glad I didn't so it's clear > arrived at the same conclusion independently. I seem to have deleted Maja's > original message plus the Mozart example she attached; Johannes or Perry, > would you mind resending it? -- but I'm sure Perry is correct about it too. > This notational unicorn might exist; I'll keep my eyes peeled for it, but > it's clearly SO rare, I don't think it's worth worry about. > > And Frank Litterscheid's example is an interesting one! But small notes > that clearlyt aren't grace notes in the normal sense aren't that unusual, > especially in Chopin :-) . Attached is the latest version of my "More > Counterexamples in Conventional Music Notation"; section 3a lists about ten > examples. > > --DAB > > > > On Sun, 14 Apr 2013 14:45:54 +0200, Johannes Kepper > wrote: > >> Hi Frank, >> >> there is an attribute @size on , which can be used >> independently from the @grace attribute. In other words, you don't >> have to call a note a grace if all you want is to change the size... >> >> >> Interesting example, though ;-) >> >> Sch?nen Sonntag, >> Johannes >> >> Am 14.04.2013 um 14:31 schrieb : >> >> Because I have no idea how the size of a note is coded in MEI, I >>> want t ask a question. >>> In the attached file there is a small note (in this edition >>> editorial addings are engraved as small notes) which HAS to be >>> connected the the *normal* beam. I would no call that small note a >>> grace note, but if the term *grace note* is the only way of encoding >>> small notes, it would be good to be able to connect them to *normal* >>> beams. >>> >>> Only a thought of an unknowing engraver J >>> Frank >>> >>> --- >>> NOTENSATZ LITTERSCHEID >>> Frank Litterscheid >>> Am Kuhkamp 7 >>> 37619 Hehlen >>> Tel 05533 - 979733 >>> Fax 05533 - 979732 >>> litterscheid at notensatz.biz >>> >>> Von: mei-l-bounces at lists.uni-**paderborn.de >>> [mailto:mei-l-bounces at lists.**uni-paderborn.de] >>> Im Auftrag von TW >>> Gesendet: Sonntag, 14. April 2013 12:52 >>> An: Music Encoding Initiative >>> Betreff: Re: [MEI-L] graceful beams >>> >>> So, to what conclusion do we come? I think MEI doesn't lack any >>> features here, it should just be made clear at a more prominent >>> place in the specification/documented that grace notes will >>> graphically not be part of a beam, even if they occur within the >>> element. If you *really* want grace notes to be part of the >>> regular beam, you can still achieve this using existing means. >>> >>> Is this a valid summary of the discussion? >>> Thomas >>> >>> >>> >>> 2013/4/14 Roland, Perry (pdr4h) >>> Hi Don, >>> >>> Thanks for joining the discussion. >>> >>> I should've been wary of using the word "never". That's a dangerous >>> word when it comes to music notation. (Note to self: Always avoid >>> the words "always" and "never". Never use them.) Chopin's notation >>> is usually pretty "slippery", so I'm not surprised you found >>> evidence there to trip up the unsuspecting. >>> >>> However, in both the Mozart and Chopin examples, the notes in >>> question are clearly not part of the beamed group of "principal" >>> notes. Stem direction is the best evidence. The different stem >>> directions leading to the beams attached to the A# in the >>> penultimate measure of the Chopin clearly indicate that there are >>> two "layers/parts/streams/voices" here. There isn't just one A#, >>> but two which occupy the same visual space. The big A# just obscures >>> the little one. The grace note A# belongs to the upper layer while >>> the regular note A# goes with the lower one. The same thing occurs >>> on the B natural in the last measure. >>> >>> Now that the part writing has been disentangled, what is most >>> interesting is the *meaning* of this particular vertical alignment, >>> the collision really, of a "principal" note and a "grace" note. >>> What is Frederic trying to say? I believe he's indicating that the >>> grace note arpeggio begins *with* the A#, not *after* it (this >>> comports with Gould) and that the performer shouldn't rush getting >>> to the A# at the top of the arpeggio. (By the way, I believe the >>> sonic effect would've been the same if he'd simply written a wavy >>> line in front of A#-C#-F#-A# in the right hand, just like what's in >>> the left hand. But he made his choice and we have to live with it.) >>> >>> >>> There's an instance in the 3rd measure of the Chopin example that's >>> more closely analogous to the situation in the Mozart that started >>> the discussion: the grace notes between beat 2 and its second half >>> (assuming this notation is counted in 2/4) lie under the beam >>> connecting the G#-A-G# sequence, but they're not touching it. In >>> addition, they're part of their own little beamed group. They are >>> *logically excluded* from participating in the "big beam group" in >>> spite of occurring between its participating notes, just like the >>> grace notes in the Mozart example. >>> >>> So, I stand by my assertion that grace notes are never (um, >>> "extremely rarely") beamed with "regular" notes, where "beamed with" >>> means "part of the same horizontal sequence as" normal-sized notes. >>> Granted, I haven't seen the entire universe of music notation, but >>> mixed grace- and normal-note beams are like unicorns -- I've heard >>> talk of them, but as yet I haven't seen one. :-) >>> >>> >>> >>> >> > > -- > > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > Indiana University Bloomington > > _______________________________________________ > 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: From sagar.chandarana123 at gmail.com Fri Apr 19 15:01:16 2013 From: sagar.chandarana123 at gmail.com (Sagar) Date: Fri, 19 Apr 2013 18:31:16 +0530 Subject: [MEI-L] Google Summer of Code at MITH Message-ID: <5171401C.50103@gmail.com> Hi Raffaele, I am Sagar Chandarana, currently pursuing my bachelor's degree in Information and Communication Technology and I am a 3rd year student at DA-IICT, India. While I was going through the GSOC list of accepted organizations and their ideas page, this particular project seems very interesting and even inspiring. It has been 6-7 months I've been learning and playing piano and my interests lead me to learn the notations in the sheet music. I would love to work on something which is actually a hobby for me. I've developed several websites for the projects I've done as a part of academics. I am familiar with JavaScript and jQuery. Infact they seem very easy to me as the degree I am pursuing and the projects I've worked on have taught me much more complex languages and algorithms. I've worked on Android and Adobe Flash, too. To mention, numbaland.com is currently hosting the games I made in Flash and I've been working on Tecla Android Application, which is a part of KomodoOpenLab and due to that, on gitHub I am one of the contributors International Development Research Centre (IDRC). I will post my detailed work experience in the formal application. For couple of days I've been researching about the 'MEI to VEXFLOW' library. My progress and the questions/confusions I face are as follows: 1) MEI1st is a very good tutorial and helped me learn the format very quickly. Currently going through the Guidelines to learn advanced headers and functionalities. To visualize the score created, I found only one tool: MEI Score Editor. Please let me know if any other tool is used by the MEI community in general. Moreover, is MEI to Audio possible? 2) I am messing up with Vexflow and the MEI to VEXFlow librarycode in order to understand properly. I'd like to know where should I begin in order get deep into the project. 3) Current softwares/tools are mostly compatible with MusicXML and not MEI. I can see musicXML to MEI conversion and vice-verse at many places on web. How reliable this conversion is? 4) Is there any plugin for 'musescore' software to import and export MEI. If there isn't, would it help for my proposal to write such a plugin for musescore or any other popular software, so that we can avoid MusicXML to MEI conversion, and much more as musescore offers a lot once the MEI is imported. Pardon me if I am asking too many questions but I am more curious as I discover the MEI more and more. Thanking you, Sagar Chandarana -------------- next part -------------- An HTML attachment was scrubbed... URL: From stadler at edirom.de Wed Apr 24 10:33:53 2013 From: stadler at edirom.de (Peter Stadler) Date: Wed, 24 Apr 2013 10:33:53 +0200 Subject: [MEI-L] Fwd: [Humanist] 26.985 speaker for the Music Library Association? References: <20130424050557.4FB9D2DB8@digitalhumanities.org> Message-ID: <5ED7957E-716C-481A-B39B-40AC9CACB73A@edirom.de> Dear all, forwarding this from the humanist list -- maybe that's of interest to some of you? Otherwise please excuse cross posting. Best Peter Anfang der weitergeleiteten Nachricht: > > Humanist Discussion Group, Vol. 26, No. 985. > Department of Digital Humanities, King's College London > www.digitalhumanities.org/humanist > > > > > Date: Tue, 23 Apr 2013 14:03:42 +0000 > From: Shawn Day > Subject: Wanted: Speaker for digital scholarship > > > The Music Library Association is seeking a speaker on digital scholarship to participate at its annual conference, February 26-March 2, 2014 in Atlanta, GA. The optimal speaker would be able to provide a perspective of DH in public libraries. > > If you are interested, please contact Kathleen DeLaurenti at: kathleendelaurenti at gmail.com. > > Please feel free to pass this on to interested parties (and yes, post at dh+lib). > > -- > Bob Kosovsky, Ph.D. -- Curator, Rare Books and Manuscripts, > Music Division, The New York Public Library for the Performing Arts > blog: http://www.nypl.org/blog/author/44 Twitter: @kos2 > Listowner: OPERA-L ; SMT-TALK ; SMT-ANNOUNCE ; SoundForge-users > - My opinions do not necessarily represent those of my institutions - > > > > _______________________________________________ > List posts to: humanist at lists.digitalhumanities.org > List info and archives at at: http://digitalhumanities.org/humanist > Listmember interface at: http://digitalhumanities.org/humanist/Restricted/listmember_interface.php > Subscribe at: http://www.digitalhumanities.org/humanist/membership_form.php -- Peter Stadler Carl-Maria-von-Weber-Gesamtausgabe Arbeitsstelle Detmold Gartenstr. 20 D-32756 Detmold Tel. +49 5231 975-665 Fax: +49 5231 975-668 stadler at weber-gesamtausgabe.de www.weber-gesamtausgabe.de From pdr4h at eservices.virginia.edu Wed Apr 24 15:55:10 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 24 Apr 2013 13:55:10 +0000 Subject: [MEI-L] Fwd: [Humanist] 26.985 speaker for the Music Library Association? Message-ID: Hi, Peter, Thanks for bringing this to the attention of the group. If anyone would like to nominate a potential speaker or would like to volunteer, feel free to make contact with Ms. DeLaurenti. -- 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 Peter Stadler [stadler at edirom.de] Sent: Wednesday, April 24, 2013 4:33 AM To: Music Encoding Initiative Subject: [MEI-L] Fwd: [Humanist] 26.985 speaker for the Music Library Association? Dear all, forwarding this from the humanist list -- maybe that's of interest to some of you? Otherwise please excuse cross posting. Best Peter Anfang der weitergeleiteten Nachricht: > > Humanist Discussion Group, Vol. 26, No. 985. > Department of Digital Humanities, King's College London > www.digitalhumanities.org/humanist > > > > > Date: Tue, 23 Apr 2013 14:03:42 +0000 > From: Shawn Day > Subject: Wanted: Speaker for digital scholarship > > > The Music Library Association is seeking a speaker on digital scholarship to participate at its annual conference, February 26-March 2, 2014 in Atlanta, GA. The optimal speaker would be able to provide a perspective of DH in public libraries. > > If you are interested, please contact Kathleen DeLaurenti at: kathleendelaurenti at gmail.com. > > Please feel free to pass this on to interested parties (and yes, post at dh+lib). > > -- > Bob Kosovsky, Ph.D. -- Curator, Rare Books and Manuscripts, > Music Division, The New York Public Library for the Performing Arts > blog: http://www.nypl.org/blog/author/44 Twitter: @kos2 > Listowner: OPERA-L ; SMT-TALK ; SMT-ANNOUNCE ; SoundForge-users > - My opinions do not necessarily represent those of my institutions - > > > > _______________________________________________ > List posts to: humanist at lists.digitalhumanities.org > List info and archives at at: http://digitalhumanities.org/humanist > Listmember interface at: http://digitalhumanities.org/humanist/Restricted/listmember_interface.php > Subscribe at: http://www.digitalhumanities.org/humanist/membership_form.php -- Peter Stadler Carl-Maria-von-Weber-Gesamtausgabe Arbeitsstelle Detmold Gartenstr. 20 D-32756 Detmold Tel. +49 5231 975-665 Fax: +49 5231 975-668 stadler at weber-gesamtausgabe.de www.weber-gesamtausgabe.de _______________________________________________ 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 Apr 26 23:01:03 2013 From: zupftom at googlemail.com (TW) Date: Fri, 26 Apr 2013 23:01:03 +0200 Subject: [MEI-L] Encoding elisions Message-ID: Dear MEI family, for Corpus monodicum, we need to encode situations where a scribe notates only the beginning and sometimes also the end of a chant section. Those are kind of cues and the scribe assumes the singer knows how to continue. It's really similar to when only the first words of a refrain are printed between verses. I think is the appropriate thing to use, like: Sex bomb turn me on. (Yes, Corpus monodicum also transcribes a few love songs.) Any objections to this structure? For some reason I don't feel 100% confident that this is what the element was made for. Thomas From raffaeleviglianti at gmail.com Sat Apr 27 00:41:41 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Fri, 26 Apr 2013 18:41:41 -0400 Subject: [MEI-L] Encoding elisions In-Reply-To: References: Message-ID: Hi Thomas, That sounds like a good case for to me. If you wanted, you could then encode the full passage with . Best, Raffaele On Fri, Apr 26, 2013 at 5:01 PM, TW wrote: > Dear MEI family, > > for Corpus monodicum, we need to encode situations where a scribe > notates only the beginning and sometimes also the end of a chant > section. Those are kind of cues and the scribe assumes the singer > knows how to continue. It's really similar to when only the first > words of a refrain are printed between verses. > > I think is the appropriate thing to use, like: > > > Sex > > > bomb > > > > > > > turn > > > me > > > on. > > > (Yes, Corpus monodicum also transcribes a few love songs.) > > Any objections to this structure? For some reason I don't feel 100% > confident that this is what the element was made for. > > 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: From pdr4h at eservices.virginia.edu Sat Apr 27 00:44:09 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 26 Apr 2013 22:44:09 +0000 Subject: [MEI-L] Encoding elisions In-Reply-To: References: Message-ID: Hi Thomas, The quick answer -- This isn't exactly what was intended for, but at the present time there's no other element that can be used instead. Someone more familiar with TEI will have to confirm this, but I believe there's also no element in TEI that indicates "nothing here in the original", so TEIers use -- incorrectly the way I read the Guidelines. The philosophical answer -- The source you're transcribing is complete; that is, there's no gap in it, per se, because nothing is "illegible, invisible, or inaudible". It only has a gap when compared against another, more complete source. Ideally, you should encode both sources, using , so that the comparison between them is explicit. Alternatively, you could "fill in" the missing material from the full source, marking the editorially supplied stuff with -- anything that isn't supplied is part of the original. I suppose you could achieve the same end using without content. You could always say, "Oh, I meant to put something in , I just never got around to it." :-) For mechanistic extraction of the original stuff -- the original material is everything minus the elements. I'm not averse to changing the description of to match this particular use, especially if there's precedent for it in TEI practice. Have a great 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 pdr4h at eservices.virginia.edu Sat Apr 27 00:49:51 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 26 Apr 2013 22:49:51 +0000 Subject: [MEI-L] Encoding elisions In-Reply-To: References: , Message-ID: can't occur directly within and so can't be wrapped around . -- 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: Friday, April 26, 2013 6:41 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding elisions Hi Thomas, That sounds like a good case for to me. If you wanted, you could then encode the full passage with . Best, Raffaele On Fri, Apr 26, 2013 at 5:01 PM, TW > wrote: Dear MEI family, for Corpus monodicum, we need to encode situations where a scribe notates only the beginning and sometimes also the end of a chant section. Those are kind of cues and the scribe assumes the singer knows how to continue. It's really similar to when only the first words of a refrain are printed between verses. I think is the appropriate thing to use, like: Sex bomb turn me on. (Yes, Corpus monodicum also transcribes a few love songs.) Any objections to this structure? For some reason I don't feel 100% confident that this is what the element was made for. 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: From pdr4h at eservices.virginia.edu Sat Apr 27 00:59:36 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 26 Apr 2013 22:59:36 +0000 Subject: [MEI-L] Encoding elisions In-Reply-To: References: , Message-ID: Sorry, I hit the send button too soon. As I was saying, can't occur directly within and so can't be wrapped around . is currently a member of model.editorialLike and that class occurs only in model.textphraseLike, model.textphraseLike.limited, and model.choicePart. So, it only works for textual abbreviations, not musical ones. One can object to this on philosophical grounds, but practical considerations make it very difficult to allow and its editorial brethren to hold both text and music notation. That would lead to utter chaos and confusion. Here be dragons! -- 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: Friday, April 26, 2013 6:41 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding elisions Hi Thomas, That sounds like a good case for to me. If you wanted, you could then encode the full passage with . Best, Raffaele On Fri, Apr 26, 2013 at 5:01 PM, TW wrote: Dear MEI family, for Corpus monodicum, we need to encode situations where a scribe notates only the beginning and sometimes also the end of a chant section. Those are kind of cues and the scribe assumes the singer knows how to continue. It's really similar to when only the first words of a refrain are printed between verses. I think is the appropriate thing to use, like: Sex bomb turn me on. (Yes, Corpus monodicum also transcribes a few love songs.) Any objections to this structure? For some reason I don't feel 100% confident that this is what the element was made for. Thomas _______________________________________________ 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 Apr 27 00:59:41 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Fri, 26 Apr 2013 18:59:41 -0400 Subject: [MEI-L] Encoding elisions In-Reply-To: References: Message-ID: Ok, sorry didn't check for validity. As far as I know elisions are encoded in TEI with and . S'ditch Shoreditch Not sure whether this would be the same kind of elision, really, but I see enough similarities. Raffaele On Fri, Apr 26, 2013 at 6:49 PM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > can't occur directly within and so can't be wrapped > around . > > > > -- > > 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:* Friday, April 26, 2013 6:41 PM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Encoding elisions > > Hi Thomas, > > That sounds like a good case for to me. If you wanted, you could > then encode the full passage with . > > Best, > Raffaele > > > On Fri, Apr 26, 2013 at 5:01 PM, TW wrote: > >> Dear MEI family, >> >> for Corpus monodicum, we need to encode situations where a scribe >> notates only the beginning and sometimes also the end of a chant >> section. Those are kind of cues and the scribe assumes the singer >> knows how to continue. It's really similar to when only the first >> words of a refrain are printed between verses. >> >> I think is the appropriate thing to use, like: >> >> >> Sex >> >> >> bomb >> >> >> >> >> >> >> turn >> >> >> me >> >> >> on. >> >> >> (Yes, Corpus monodicum also transcribes a few love songs.) >> >> Any objections to this structure? For some reason I don't feel 100% >> confident that this is what the element was made for. >> >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Sat Apr 27 01:05:02 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 26 Apr 2013 23:05:02 +0000 Subject: [MEI-L] Encoding elisions In-Reply-To: References: , Message-ID: No apology necessary. But I should check the schema and guidelines before I go off half-cocked. does allow musical constructs, just not . Don't you hate it when a perfectlly good statement is ruined by the facts? :-) Anyway, it looks like we have some work to do on and . MEI 2014, anyone? -- 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: Friday, April 26, 2013 6:59 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding elisions Ok, sorry didn't check for validity. As far as I know elisions are encoded in TEI with and . S'ditch Shoreditch Not sure whether this would be the same kind of elision, really, but I see enough similarities. Raffaele On Fri, Apr 26, 2013 at 6:49 PM, Roland, Perry (pdr4h) > wrote: can't occur directly within and so can't be wrapped around . -- 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: Friday, April 26, 2013 6:41 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Encoding elisions Hi Thomas, That sounds like a good case for to me. If you wanted, you could then encode the full passage with . Best, Raffaele On Fri, Apr 26, 2013 at 5:01 PM, TW > wrote: Dear MEI family, for Corpus monodicum, we need to encode situations where a scribe notates only the beginning and sometimes also the end of a chant section. Those are kind of cues and the scribe assumes the singer knows how to continue. It's really similar to when only the first words of a refrain are printed between verses. I think is the appropriate thing to use, like: Sex bomb turn me on. (Yes, Corpus monodicum also transcribes a few love songs.) Any objections to this structure? For some reason I don't feel 100% confident that this is what the element was made for. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zupftom at googlemail.com Sat Apr 27 11:33:42 2013 From: zupftom at googlemail.com (TW) Date: Sat, 27 Apr 2013 11:33:42 +0200 Subject: [MEI-L] Encoding elisions In-Reply-To: References: Message-ID: Thanks Raffaele and Perry! 2013/4/27 Roland, Perry (pdr4h) : > > Anyway, it looks like we have some work to do on and . MEI > 2014, anyone? > indeed looks like a good fit for our situation, but I don't think alone would be sufficient in the cases where we have start and end of a passage. (or something more appropriate that would have to be invented) would still be needed to indicate where the actual elision is. And in this project, editors will not provide an expanded form. If we try to use inside in a way that conforms with current MEI structures, we'd unfortunately have to resort to soviet Russia methods, packaging it in without an alternative. Instead of providing expanded forms, I could imagine that in the future the project will opt for pointing to other places in the corpus where the chant appears in its complete form (there might be multiple places to point to with different variants). We could use @corresp on
for this purpose - not only on the abbreviated ones. Thomas From roewenstrunk at edirom.de Tue Apr 30 11:14:23 2013 From: roewenstrunk at edirom.de (=?iso-8859-1?Q?Daniel_R=F6wenstrunk?=) Date: Tue, 30 Apr 2013 11:14:23 +0200 Subject: [MEI-L] Music Encoding Conference 2013: Extended Registration Message-ID: <8FDA6D66-F6F2-439D-86E2-A3FD5AA5A409@edirom.de> =============================================================== REGISTRATION EXTENDED The Music Encoding Conference 2013: Concepts, Methods, Editions 22-24 May, 2013 =============================================================== Dear colleagues, We want to share the latest news about the Music Encoding Conference and encourage you to join us for an exciting schedule of events. PROGRAM The conference will be held May 21-24 at the Academy for Literature and Sciences in Mainz. The full program is available at https://music-encoding.org/conference/program. REGISTRATION If you haven't registered yet, please do so as soon as possible. We have extended registration until *May 12*, but only those registered before May 1 are guaranteed to receive a thumb drive. A no-cost introduction to the Music Encoding Initiative will be provided on May 21 & 22. We look forward to seeing you in Mainz. For the local organizers, Daniel -- Dipl. Wirt. Inf. Daniel R?wenstrunk Project manager BMBF-Project "Freisch?tz Digital" Musikwiss. Seminar Detmold/Paderborn Gartenstr. 20 D-32756 Detmold Tel.: +49 5231 975665 Mail: roewenstrunk at edirom.de URL: http://www.freischuetz-digital.de -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From sylvainemartindeguise at gmail.com Tue Apr 30 11:30:32 2013 From: sylvainemartindeguise at gmail.com (Sylvaine Martin de Guise) Date: Tue, 30 Apr 2013 11:30:32 +0200 Subject: [MEI-L] Music Encoding Conference 2013: Extended Registration In-Reply-To: <8FDA6D66-F6F2-439D-86E2-A3FD5AA5A409@edirom.de> References: <8FDA6D66-F6F2-439D-86E2-A3FD5AA5A409@edirom.de> Message-ID: Dear M. Daniel , I thank you. Still it is not so clear how to get to the "thumb drive": after the tutorials? OK. I will see how to managed. Cordialy, Sylvaine Martin de Guise *Sylvaine Martin de Guise, compositrice ** * *47 avenue du Capitaine Glarner 93400 Saint-Ouen T?l.: 09-51-97-67-59 Cellulaire : 06-95-92-76-79 **** (adresse l'?t?, au mois d'ao?t) **78 rue de la Gr?ve* *Rivi?re-3-Pistoles, Qu?bec** Canada G0L 2E0* * * "La musique, c'est ce qu'on ?coute avec l'intention d'?couter de la musique." *Luciano Berio* - 2013/4/30 Daniel R?wenstrunk > =============================================================== > REGISTRATION EXTENDED > The Music Encoding Conference 2013: Concepts, Methods, Editions > 22-24 May, 2013 > =============================================================== > > Dear colleagues, > > We want to share the latest news about the Music Encoding Conference and > encourage > you to join us for an exciting schedule of events. > > PROGRAM > The conference will be held May 21-24 at the Academy for Literature and > Sciences in > Mainz. The full program is available at > https://music-encoding.org/conference/program. > > REGISTRATION > If you haven't registered yet, please do so as soon as possible. We have > extended > registration until *May 12*, but only those registered before May 1 are > guaranteed to > receive a thumb drive. > > A no-cost introduction to the Music Encoding Initiative will be provided > on May 21 & 22. > > > We look forward to seeing you in Mainz. > > For the local organizers, > Daniel > > > -- > Dipl. Wirt. Inf. Daniel R?wenstrunk > Project manager > BMBF-Project "Freisch?tz Digital" > > Musikwiss. Seminar Detmold/Paderborn > Gartenstr. 20 > D-32756 Detmold > > Tel.: +49 5231 975665 > Mail: roewenstrunk at edirom.de > URL: http://www.freischuetz-digital.de > > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From kepper at edirom.de Fri May 10 23:19:51 2013 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 10 May 2013 23:19:51 +0200 Subject: [MEI-L] Order of Guidelines chapters Message-ID: <38C7C77D-1855-4AAB-969F-53E246BD207D@edirom.de> Dear list, while preparing the documentation for the upcoming release of MEI, we stumbled upon an issue where we would like to get some feedback from the community. The next release release includes a new module in MEI (FRBR?), and we wondered about the preferences for ordering. It would make a lot of sense to put the new chapter next to the existing header chapter, but as all chapters are automatically numbered, this would result in different chapter numbers for almost the complete Guidelines of the new release, compared to the 2012 release. My question is: Do you prefer a) to keep existing chapter numbers whenever possible, or b) to have chapters organized by their relationship, ignoring changing numbers? Technically, it is not a big deal to implement it either way. I have a slight preference for b), but am open to arguments from both sides. There isn't much time left for discussion, so if you have strong opinions, please respond before Monday. Best, Johannes From Tore.Simonsen at nmh.no Fri May 10 23:47:03 2013 From: Tore.Simonsen at nmh.no (Tore Simonsen) Date: Fri, 10 May 2013 21:47:03 +0000 Subject: [MEI-L] Order of Guidelines chapters In-Reply-To: <38C7C77D-1855-4AAB-969F-53E246BD207D@edirom.de> References: <38C7C77D-1855-4AAB-969F-53E246BD207D@edirom.de> Message-ID: Hah, one of the few things I feel I might have an opinion of! As a fairly new reader I would prefer b) All the best Tore Simonsen -----Original Message----- From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Johannes Kepper Sent: 10. mai 2013 23:20 To: Music Encoding Initiative Subject: [MEI-L] Order of Guidelines chapters Dear list, while preparing the documentation for the upcoming release of MEI, we stumbled upon an issue where we would like to get some feedback from the community. The next release release includes a new module in MEI (FRBR...), and we wondered about the preferences for ordering. It would make a lot of sense to put the new chapter next to the existing header chapter, but as all chapters are automatically numbered, this would result in different chapter numbers for almost the complete Guidelines of the new release, compared to the 2012 release. My question is: Do you prefer a) to keep existing chapter numbers whenever possible, or b) to have chapters organized by their relationship, ignoring changing numbers? Technically, it is not a big deal to implement it either way. I have a slight preference for b), but am open to arguments from both sides. There isn't much time left for discussion, so if you have strong opinions, please respond before Monday. Best, Johannes _______________________________________________ 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 Sat May 11 02:54:20 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Fri, 10 May 2013 20:54:20 -0400 Subject: [MEI-L] Order of Guidelines chapters In-Reply-To: References: <38C7C77D-1855-4AAB-969F-53E246BD207D@edirom.de> Message-ID: <20130510205420.k47jx4mhgcwo4ogo@webmail.iu.edu> I vote for b also. I think the argument for backward compatibility of chapter numbers is pretty weak. --Don On Fri, 10 May 2013 21:47:03 +0000, Tore Simonsen wrote: > Hah, one of the few things I feel I might have an opinion of! > > As a fairly new reader I would prefer b) > > All the best > > Tore Simonsen > > -----Original Message----- > From: mei-l-bounces at lists.uni-paderborn.de > [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Johannes > Kepper > Sent: 10. mai 2013 23:20 > To: Music Encoding Initiative > Subject: [MEI-L] Order of Guidelines chapters > > Dear list, > > while preparing the documentation for the upcoming release of MEI, we > stumbled upon an issue where we would like to get some feedback from > the community. > > The next release release includes a new module in MEI (FRBR...), and > we wondered about the preferences for ordering. It would make a lot > of sense to put the new chapter next to the existing header chapter, > but as all chapters are automatically numbered, this would result in > different chapter numbers for almost the complete Guidelines of the > new release, compared to the 2012 release. My question is: Do you > prefer > > a) to keep existing chapter numbers whenever possible, or > > b) to have chapters organized by their relationship, ignoring > changing numbers? > > > Technically, it is not a big deal to implement it either way. I have > a slight preference for b), but am open to arguments from both sides. > There isn't much time left for discussion, so if you have strong > opinions, please respond before Monday. > > Best, > Johannes > > > _______________________________________________ > 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 Visiting Scientist, Research Technologies Indiana University Bloomington From laurent at music.mcgill.ca Sat May 11 09:45:19 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Sat, 11 May 2013 09:45:19 +0200 Subject: [MEI-L] Order of Guidelines chapters In-Reply-To: <2380_1368233678_518D96CD_2380_249_1_20130510205420.k47jx4mhgcwo4ogo@webmail.iu.edu> References: <38C7C77D-1855-4AAB-969F-53E246BD207D@edirom.de> <2380_1368233678_518D96CD_2380_249_1_20130510205420.k47jx4mhgcwo4ogo@webmail.iu.edu> Message-ID: b too, Laurent On Sat, May 11, 2013 at 2:54 AM, Byrd, Donald A. wrote: > I vote for b also. I think the argument for backward compatibility of > chapter numbers is pretty weak. > > --Don > > > > On Fri, 10 May 2013 21:47:03 +0000, Tore Simonsen > wrote: > > Hah, one of the few things I feel I might have an opinion of! >> >> As a fairly new reader I would prefer b) >> >> All the best >> >> Tore Simonsen >> >> -----Original Message----- >> From: mei-l-bounces at lists.uni-**paderborn.de >> [mailto:mei-l-bounces at lists.**uni-paderborn.de] >> On Behalf Of Johannes >> Kepper >> Sent: 10. mai 2013 23:20 >> To: Music Encoding Initiative >> Subject: [MEI-L] Order of Guidelines chapters >> >> Dear list, >> >> while preparing the documentation for the upcoming release of MEI, we >> stumbled upon an issue where we would like to get some feedback from >> the community. >> >> The next release release includes a new module in MEI (FRBR...), and >> we wondered about the preferences for ordering. It would make a lot >> of sense to put the new chapter next to the existing header chapter, >> but as all chapters are automatically numbered, this would result in >> different chapter numbers for almost the complete Guidelines of the >> new release, compared to the 2012 release. My question is: Do you >> prefer >> >> a) to keep existing chapter numbers whenever possible, or >> >> b) to have chapters organized by their relationship, ignoring >> changing numbers? >> >> >> Technically, it is not a big deal to implement it either way. I have >> a slight preference for b), but am open to arguments from both sides. >> There isn't much time left for discussion, so if you have strong >> opinions, please respond before Monday. >> >> Best, >> Johannes >> >> >> ______________________________**_________________ >> 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 > Visiting Scientist, Research Technologies > Indiana University Bloomington > > > > ______________________________**_________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.**de/mailman/listinfo/mei-l > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From Maja.Hartwig at gmx.de Sat May 11 09:54:18 2013 From: Maja.Hartwig at gmx.de (Maja Hartwig) Date: Sat, 11 May 2013 09:54:18 +0200 (CEST) Subject: [MEI-L] Order of Guidelines chapters In-Reply-To: References: <38C7C77D-1855-4AAB-969F-53E246BD207D@edirom.de> <2380_1368233678_518D96CD_2380_249_1_20130510205420.k47jx4mhgcwo4ogo@webmail.iu.edu>, Message-ID: Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From kristina.richts at gmx.de Sat May 11 10:03:59 2013 From: kristina.richts at gmx.de (Kristina Richts) Date: Sat, 11 May 2013 10:03:59 +0200 Subject: [MEI-L] Order of Guidelines chapters In-Reply-To: References: <38C7C77D-1855-4AAB-969F-53E246BD207D@edirom.de> <2380_1368233678_518D96CD_2380_249_1_20130510205420.k47jx4mhgcwo4ogo@webmail.iu.edu>, Message-ID: <518DFB6F.6060004@gmx.de> And one more vote for option b! Best, Kristina Am 11.05.2013 09:54, schrieb Maja Hartwig: > I also prefer option b! > Maja > *Gesendet:* Samstag, 11. Mai 2013 um 09:45 Uhr > *Von:* "Laurent Pugin" > *An:* "Music Encoding Initiative" > *Betreff:* Re: [MEI-L] Order of Guidelines chapters > b too, > Laurent > On Sat, May 11, 2013 at 2:54 AM, Byrd, Donald A. > wrote: > > I vote for b also. I think the argument for backward compatibility > of chapter numbers is pretty weak. > > --Don > > > > On Fri, 10 May 2013 21:47:03 +0000, Tore Simonsen > wrote: > > Hah, one of the few things I feel I might have an opinion of! > > As a fairly new reader I would prefer b) > > All the best > > Tore Simonsen > > -----Original Message----- > From: mei-l-bounces at lists.uni-paderborn.de > [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Johannes > Kepper > Sent: 10. mai 2013 23:20 > To: Music Encoding Initiative > Subject: [MEI-L] Order of Guidelines chapters > > Dear list, > > while preparing the documentation for the upcoming release of > MEI, we > stumbled upon an issue where we would like to get some > feedback from > the community. > > The next release release includes a new module in MEI > (FRBR...), and > we wondered about the preferences for ordering. It would make > a lot > of sense to put the new chapter next to the existing header > chapter, > but as all chapters are automatically numbered, this would > result in > different chapter numbers for almost the complete Guidelines > of the > new release, compared to the 2012 release. My question is: Do you > prefer > > a) to keep existing chapter numbers whenever possible, or > > b) to have chapters organized by their relationship, ignoring > changing numbers? > > > Technically, it is not a big deal to implement it either way. > I have > a slight preference for b), but am open to arguments from both > sides. > There isn't much time left for discussion, so if you have strong > opinions, please respond before Monday. > > Best, > Johannes > > > _______________________________________________ > 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 > Visiting Scientist, Research Technologies > 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 -- Kristina Richts M.A. DFG/NEH-Projekt "Digital Music Notation Data Model and Prototype Delivery System" Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D-32756 Detmold Tel.: +49 5231 975676 Mail: richts at music-encoding.org URL: http://music-encoding.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From veit at weber-gesamtausgabe.de Sat May 11 10:07:57 2013 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Sat, 11 May 2013 10:07:57 +0200 Subject: [MEI-L] Order of Guidelines chapters In-Reply-To: <38C7C77D-1855-4AAB-969F-53E246BD207D@edirom.de> References: <38C7C77D-1855-4AAB-969F-53E246BD207D@edirom.de> Message-ID: <518DFC5D.4060200@weber-gesamtausgabe.de> And a further vote for b) Joachim Am 10.05.13 23:19, schrieb Johannes Kepper: > Dear list, > > while preparing the documentation for the upcoming release of MEI, we stumbled upon an issue where we would like to get some feedback from the community. > > The next release release includes a new module in MEI (FRBR?), and we wondered about the preferences for ordering. It would make a lot of sense to put the new chapter next to the existing header chapter, but as all chapters are automatically numbered, this would result in different chapter numbers for almost the complete Guidelines of the new release, compared to the 2012 release. My question is: Do you prefer > > a) to keep existing chapter numbers whenever possible, or > > b) to have chapters organized by their relationship, ignoring changing numbers? > > > Technically, it is not a big deal to implement it either way. I have a slight preference for b), but am open to arguments from both sides. There isn't much time left for discussion, so if you have strong opinions, please respond before Monday. > > Best, > Johannes > > > > _______________________________________________ > 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 : From esfield at stanford.edu Sun May 12 03:44:50 2013 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Sat, 11 May 2013 18:44:50 -0700 (PDT) Subject: [MEI-L] Order of Guidelines chapters In-Reply-To: <518DFC5D.4060200@weber-gesamtausgabe.de> References: <38C7C77D-1855-4AAB-969F-53E246BD207D@edirom.de> <518DFC5D.4060200@weber-gesamtausgabe.de> Message-ID: <36a9820a.000012c0.00000020@CCARH-ADM-2.su.win.stanford.edu> And from me: (b) Eleanor -----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: Saturday, May 11, 2013 1:08 AM To: mei-l at lists.uni-paderborn.de Subject: Re: [MEI-L] Order of Guidelines chapters And a further vote for b) Joachim Am 10.05.13 23:19, schrieb Johannes Kepper: > Dear list, > > while preparing the documentation for the upcoming release of MEI, we stumbled upon an issue where we would like to get some feedback from the community. > > The next release release includes a new module in MEI (FRBR.), and we wondered about the preferences for ordering. It would make a lot of sense to put the new chapter next to the existing header chapter, but as all chapters are automatically numbered, this would result in different chapter numbers for almost the complete Guidelines of the new release, compared to the 2012 release. My question is: Do you prefer > > a) to keep existing chapter numbers whenever possible, or > > b) to have chapters organized by their relationship, ignoring changing numbers? > > > Technically, it is not a big deal to implement it either way. I have a slight preference for b), but am open to arguments from both sides. There isn't much time left for discussion, so if you have strong opinions, please respond before Monday. > > Best, > 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 Mon May 20 00:10:58 2013 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 20 May 2013 00:10:58 +0200 Subject: [MEI-L] Future Organization of MEI Message-ID: Dear MEI Community, in the last few years, this community was loosely built around a project jointly funded by NEH and DFG. This project gave access to travel money and helped to organize the community. However, the current project will end later this year, and a follow-up grant hasn't been funded by the two agencies. Therefore, it seems timely to discuss about the future of the organization of MEI. Right now, everything is handled quite informal. This has worked well in the last few years, and is clearly a reason for the success we've seen. However, we see a risk that this current structure may be regarded as intransparent, and could distract other people from getting involved in MEI. To prevent this misunderstanding, and to reach out for a wider community of actives and followers alike, we drafted a proposal for a new, slightly more formal structure of MEI, which you'll find attached to this mail. Coming Friday, the current MEI Council, which was established with the help of the DFG/NEH project, will meet during our conference in Mainz. We hope that our proposal will help to guide a discussion about the future of MEI as organization within that group, but we also believe that MEI is a community-driven project. Therefore, we would like to invite you all to share your thoughts about our proposal or alternative approaches. Give us your arguments for the meeting next week, and we make sure they're heard in the discussion both on- and offline. We don't anticipate a final decision by next week, but it would be great to agree on a direction and workflow by then. This is your opportunity to speak up and help shaping MEI for the next years. Best regards, Perry Roland and Johannes Kepper -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : meiOrganization.pdf Dateityp : application/pdf Dateigr??e : 59125 bytes Beschreibung: nicht verf?gbar URL : From K.Desmond at ucc.ie Thu May 23 23:37:34 2013 From: K.Desmond at ucc.ie (Desmond, Karen) Date: Thu, 23 May 2013 21:37:34 +0000 Subject: [MEI-L] neumes panel notes Message-ID: <37016A94-05C4-4626-9CB2-C5B97B0A6579@ucc.ie> Dear all, As promised here are the notes I took during the neumes panel this afternoon. Perry suggested we use this mailing list, instead of having a mailing list specific to the MEI Neumes SIG. Best, Karen -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PanelSessionMEINeumes2013.pdf Type: application/pdf Size: 42714 bytes Desc: PanelSessionMEINeumes2013.pdf URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From D.Spreadbury at steinberg.de Fri May 24 09:43:51 2013 From: D.Spreadbury at steinberg.de (Daniel Spreadbury) Date: Fri, 24 May 2013 09:43:51 +0200 Subject: [MEI-L] Standard Music Font Layout initiative Message-ID: Dear list members, Yesterday at the Music Encoding?Conference in Mainz I announced an initiative I have been working on for the past few months as part of our work on a new scoring program for Steinberg. I am hoping to build a community of experts around the initiative, and so I would like to invite any list members who are interested in this project to get in touch with me. You can see my slides from my conference presentation here: http://www.slideshare.net/dspreadbury/standard-music-font-layout There is also a web site for the Standard Music Font Layout (SMuFL), which you can find here: http://www.smufl.org/ Thanks very much, Daniel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 | www.steinberg.net Managing Director: Andreas Stelling, Kazunori Kobayashi Registration Court: Hamburg HRB 86534 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Sat May 25 00:05:17 2013 From: kepper at edirom.de (Johannes Kepper) Date: Sat, 25 May 2013 00:05:17 +0200 Subject: [MEI-L] Release of MEI 2013 Message-ID: Dear MEI Community, this week, we had a very productive conference at the Mainz Academy for Sciences and Literature, which was generally perceived as the MEI Members Meeting ? a title which officially wasn't assigned. While I'm sure others may be better suited to report on the conference itself, I would like to repeat an announcement made during the conference for those of us that couldn't make it to Mainz. --- We are happy to announce the release of MEI2013, a new iteration of our data framework. The release is available from http://music-encoding.org/downloads/mei2013 or the development repository at https://code.google.com/p/music-encoding/. The most distinct new feature is the implementation of FRBR, the Functional Requirements for Bibliographic Records. This model allows an easier alignment with state-of-the-art bibliographic data, but also opens new perspectives for scholarly editions. The merMEId tool developed by Siegfried Lundberg and Axel Teich Geertinger in Copenhagen, which they have announced several weeks ago on this list, already makes excellent use of this new module. With this new release, we also revised our website http://music.encoding.org to reflect all related changes. Most notably, this includes an online version of the Guidelines (http://music.encoding.org/documentation/guidelines2013), and a Sample Collection (http://music.encoding.org/documentation/samples) providing a set of about 150 MEI files conforming to either the 2012 or 2013 release. Most of these files are joined by a PDF with images of the underlying source and illustrate manifold aspects of MEI. However, this is intended to be an open collection, containing MEI instances from various origins. So if you happen to have an encoding of MEI at hand that you would be happy to share, please get in touch. There is also a search function available, which currently offers to search within certain metadata of the collection. The expansion of this functionality will be one of the major tasks for the upcoming months. A big thank goes to the MEI Technical Team for preparing this release. While many people have helped, let me explicitly mention Axel Teich Geertinger, who did a great job on the development, testing and documentation of the new FRBR module. I would also like to emphasize the contribution of Maja Hartwig and Kristina Richts, who did a great job on the sample collection, providing another great resource for getting in touch with MEI. Thank you ever so much. Best regards from Mainz, Johannes From elainehild at hotmail.com Sat May 25 12:37:58 2013 From: elainehild at hotmail.com (Elaine Hild) Date: Sat, 25 May 2013 04:37:58 -0600 Subject: [MEI-L] neumes panel notes In-Reply-To: <37016A94-05C4-4626-9CB2-C5B97B0A6579@ucc.ie> References: <37016A94-05C4-4626-9CB2-C5B97B0A6579@ucc.ie> Message-ID: Dear Karen, Thank you--both for this precise summary, and for your moderation of the panel. It was good to meet you again! All best wishes fromElaine From: K.Desmond at ucc.ie To: mei-l at lists.uni-paderborn.de Date: Thu, 23 May 2013 21:37:34 +0000 Subject: [MEI-L] neumes panel notes Dear all, As promised here are the notes I took during the neumes panel this afternoon. Perry suggested we use this mailing list, instead of having a mailing list specific to the MEI Neumes SIG. Best, Karen --Forwarded Message Attachment-- ----- Dr. Karen Desmond Lecturer in Musicology, Department of Music University College Cork, Ireland + 353 21 490 4530 k.desmond at ucc.iehttp://www.arsmusicae.org/wordpress/ _______________________________________________ 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: From slu at kb.dk Sat May 25 17:13:07 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Sat, 25 May 2013 15:13:07 +0000 Subject: [MEI-L] Some photos Message-ID: <0C090608704AF04E898055296C932B129A4318AB@EXCHANGE-01.kb.dk> Dear all Heads of development https://www.dropbox.com/s/jzjulvi0axr6z1n/L1003156_v1.JPG Red light, albeit outside the district https://www.dropbox.com/s/c0pvbdgh3rk2xoi/L1003162_v1.JPG Team building https://www.dropbox.com/s/htwclpvpu0jgcyi/L1003142.jpeg https://www.dropbox.com/s/czu09573ngwii3z/L1003147.jpeg https://www.dropbox.com/s/1l85y6lqccinynx/L1003150.jpeg https://www.dropbox.com/s/c6ejb8gwnhxzhsp/L1003152.jpeg Save away what you like. I'll eventualy remove them and preserve them somewhere else. In case of the posterity likes them. Cheers Sigfrid From stefan.morent at uni-tuebingen.de Sun May 26 15:34:29 2013 From: stefan.morent at uni-tuebingen.de (Prof. Dr. Morent) Date: Sun, 26 May 2013 15:34:29 +0200 Subject: [MEI-L] neumes panel notes In-Reply-To: References: <37016A94-05C4-4626-9CB2-C5B97B0A6579@ucc.ie> Message-ID: <20130526153429.72472j2qe80o1085@webmail.uni-tuebingen.de> Dear all from the SIG Neumes meeting at Mainz, thank you all again for participating and starting a fruitful discussion on the further development of the MEI neumes module. Special thanks to Karen for chairing the session! Best Stefan Zitat von Elaine Hild : > Dear Karen, > Thank you--both for this precise summary, and for your moderation of > the panel. > It was good to meet you again! > All best wishes fromElaine > > From: K.Desmond at ucc.ie > To: mei-l at lists.uni-paderborn.de > Date: Thu, 23 May 2013 21:37:34 +0000 > Subject: [MEI-L] neumes panel notes > > > > > > > Dear all, > As promised here are the notes I took during the neumes panel this > afternoon. Perry suggested we use this mailing list, instead of > having a mailing list specific to the MEI Neumes SIG. > Best, > Karen > > > > > --Forwarded Message Attachment-- > > > > ----- > > Dr. Karen Desmond > Lecturer in Musicology, Department of Music > University College Cork, Ireland > + 353 21 490 4530 > k.desmond at ucc.iehttp://www.arsmusicae.org/wordpress/ > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From F.Wiering at uu.nl Tue May 28 09:29:28 2013 From: F.Wiering at uu.nl (Frans Wiering) Date: Tue, 28 May 2013 09:29:28 +0200 Subject: [MEI-L] keynote slides Message-ID: <51A45CD8.4070408@uu.nl> Dear all, The slides of my keynote presentation at the Music Encoding Conference are now online at http://www.staff.science.uu.nl/~wieri103/presentations/WieringInteractiveMusicologyMainz2013.pdf It was a great pleasure to meet so many of you in Mainz! Best wishes, Frans -- --------------------------------------------------------------------- dr. Frans Wiering e-mail: F.Wiering at uu.nl --------------------------------------------------------------------- Utrecht University Department of Information and Computing Sciences (ICS) Buys Ballot Building, office 482 Princetonplein 5, De Uithof PO Box 80.089 NL-3508 TB Utrecht tel: +31-30-2536335 www: http://www.uu.nl/medewerkers/FWiering --------------------------------------------------------------------- From diet at bsb-muenchen.de Tue May 28 10:20:58 2013 From: diet at bsb-muenchen.de (=?UTF-8?Q?J=C3=BCrgen=20Diet?=) Date: Tue, 28 May 2013 10:20:58 +0200 Subject: [MEI-L] Wtrlt: [MUSIC-NOTATION] Call for Symposium / Workshop Music Notation #1 Message-ID: <51A4850A0200006F0006E750@gwia.bsb-muenchen.de> Dear MEI-list, the following mail might be of interest for those of you have not yet heard about the workshop in Paris on June 27. I got this mail today via the list music-notation at listes.ircam.fr Best regards, J?rgen Diet **************************************************************** J?rgen Diet (Coordinator of the Virtual Library of Musicology) Bavarian State Library Music Department Ludwigstr. 16 D-80539 Munich Germany Tel. ++49-89-28638-2768 Fax ++49-89-28638-2479 email: juergen.diet at bsb-muenchen.de ViFaMusik-Homepage: http://www.vifamusik.de/home.html?L=1 ViFaMusik-Blog (in German): http://vifamusik.wordpress.com ViFaMusik in Twitter (in German): http://twitter.com/vifamusik *************************************************************** >>> Pierre Couprie 28.05.2013 09:50 >>> Symposium / Workshop Music Notation #1 http://notation.afim-asso.org/doku.php/evenements/2013-06-27-etude-notation1 Organization : AFIM/MINT-OMF June 27 2013 - 9h-17h30 Universit? Paris-Sorbonne Maison de la recherche Room D040 26 rue Serpente 75006 Paris (M?tro Saint-Michel ou Od?on) The research group ?New Fields of Music Notation? organizes a workshop in June 27, 2013 at the Paris-Sorbonne University in collaboration with the research group Musicologie, Informatique et Nouvelles Technologies (MINT). This session will provide an opportunity to make a state of art of recent research in the field of musical notation through creation and musical research. The presentations may take different forms (formal or informal presentation, demonstration, etc..) and will last about 15 minutes. Here are some topics that may be addressed: ? Notation of interactivity ? Multimedia and/or interactive notation ? Software/plugin/frameworks/API for music notation ? New systems for music notation ? Notation and annotations, musical representations ? Gesture notation in arts This list is not exhaustive; other themes related to music notation and technologies will be welcome. This workshop will be divided in 2 parts: ? 9:00-1:00 PM: Public presentations ? 2:30 PM-4:30 PM: Opened discussion If you want to propose a presentation, please send a title and a short abstract before the June 10th to . From andrew.hankinson at mail.mcgill.ca Tue May 28 22:48:04 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Tue, 28 May 2013 20:48:04 +0000 Subject: [MEI-L] "When" element pointing Message-ID: Hi all, First, it was great to see everyone in Mainz. Thanks for a wonderful conference. Now, back to the business at hand: I was chatting with someone about the linking and alignment of audio and video files with a score. What they're interested in is taking multiple recordings and linking them up to a very sparse score representation (measures or even just sections). Looking at how the and @when system works, it doesn't look like this is currently possible; that is, it's possible to point from a score element to a single point on a timeline, but it's not possible to point from a time point to an element in the score. By using @when on a score-level element (measure, note, etc.) you're "polluting" the score representation with its location in a single timeline, rather than having the ability to, in multiple recordings, refer to the same score-level element at different time points. I don't think this would be too hard to add so I will volunteer to actually do the coding, but I would first like to hear if anyone has any objections or suggestions. Thanks, -Andrew From sylvainemartindeguise at gmail.com Wed May 29 07:38:39 2013 From: sylvainemartindeguise at gmail.com (=?utf-8?Q?sylvainemartindeguise@gmail.com?=) Date: Wed, 29 May 2013 05:38:39 +0000 Subject: [MEI-L] =?utf-8?q?=22When=22_element_pointing?= Message-ID: <51a59461.2a26b40a.382f.65d9@mx.google.com> Hello Andrew, Thank you for this information, still very accurate to me, when I?m a beginner with MEI. I will certainly take care of it while working to record a Algerian music : probably we will have to note the music with the conventional western notation, even if it is not the real way of composing in North Africa, since it is oral music. I will follow attentivly all of your further information, from you or other specialist in MEI, and spread it to my fellows algerian and tunisian. It was, indeed, a pleasure to meet you all in Mainz. Best regards, Sylvaine Martin de Guise Envoy? depuis Courrier Windows De : Andrew Hankinson Envoy? : ?28? ?mai? ?2013 ?22?:?48 ? : Music Encoding Initiative Objet : [MEI-L] "When" element pointing Hi all, First, it was great to see everyone in Mainz. Thanks for a wonderful conference. Now, back to the business at hand: I was chatting with someone about the linking and alignment of audio and video files with a score. What they're interested in is taking multiple recordings and linking them up to a very sparse score representation (measures or even just sections). Looking at how the and @when system works, it doesn't look like this is currently possible; that is, it's possible to point from a score element to a single point on a timeline, but it's not possible to point from a time point to an element in the score. By using @when on a score-level element (measure, note, etc.) you're "polluting" the score representation with its location in a single timeline, rather than having the ability to, in multiple recordings, refer to the same score-level element at different time points. I don't think this would be too hard to add so I will volunteer to actually do the coding, but I would first like to hear if anyone has any objections or suggestions. Thanks, -Andrew _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From sylvainemartindeguise at gmail.com Wed May 29 07:43:20 2013 From: sylvainemartindeguise at gmail.com (=?utf-8?Q?sylvainemartindeguise@gmail.com?=) Date: Wed, 29 May 2013 05:43:20 +0000 Subject: [MEI-L] =?utf-8?q?=22When=22_element_pointing?= Message-ID: <51a5957a.aa07b40a.2228.3f1a@mx.google.com> I have forget to ask: having a notebook Asus, I was trying to install Oxygen on it. But, it seems the program is too ?strong? and can not be install on a the computer. Do you know another type of editor, lighter may-be, that can fit a less strong computer, like AsusViva book? Thank you if anybody has the answer! Sylvaine Martin de Guise Envoy? depuis Courrier Windows De : Andrew Hankinson Envoy? : ?28? ?mai? ?2013 ?22?:?48 ? : Music Encoding Initiative Objet : [MEI-L] "When" element pointing Hi all, First, it was great to see everyone in Mainz. Thanks for a wonderful conference. Now, back to the business at hand: I was chatting with someone about the linking and alignment of audio and video files with a score. What they're interested in is taking multiple recordings and linking them up to a very sparse score representation (measures or even just sections). Looking at how the and @when system works, it doesn't look like this is currently possible; that is, it's possible to point from a score element to a single point on a timeline, but it's not possible to point from a time point to an element in the score. By using @when on a score-level element (measure, note, etc.) you're "polluting" the score representation with its location in a single timeline, rather than having the ability to, in multiple recordings, refer to the same score-level element at different time points. I don't think this would be too hard to add so I will volunteer to actually do the coding, but I would first like to hear if anyone has any objections or suggestions. Thanks, -Andrew _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From kepper at edirom.de Wed May 29 08:37:53 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 29 May 2013 08:37:53 +0200 Subject: [MEI-L] "When" element pointing In-Reply-To: References: Message-ID: <799DF2C0-5732-47FB-9ACB-A85A39DF2009@edirom.de> Am 28.05.2013 um 22:48 schrieb Andrew Hankinson: > Hi all, > > First, it was great to see everyone in Mainz. Thanks for a wonderful conference. wearing the organizer hat, I'd like to say that we are quite happy with it as well. It wouldn't have been possible without the great help of many, both from the Academy (Anna, Frau Biersch, Frau Buschmeier, Herr Krings, many others I don't even know the names of), and our Detmold team (Maja, Kristina, Anna). Thanks to you very very much indeed! > > Now, back to the business at hand: I was chatting with someone about the linking and alignment of audio and video files with a score. What they're interested in is taking multiple recordings and linking them up to a very sparse score representation (measures or even just sections). > > Looking at how the and @when system works, it doesn't look like this is currently possible; that is, it's possible to point from a score element to a single point on a timeline, but it's not possible to point from a time point to an element in the score. By using @when on a score-level element (measure, note, etc.) you're "polluting" the score representation with its location in a single timeline, rather than having the ability to, in multiple recordings, refer to the same score-level element at different time points. > Switching to the modelling hat, I would suggest to use a different approach: Have you considered something like This follows the model of facsimile and does not pollute the music tree. > I don't think this would be too hard to add so I will volunteer to actually do the coding, but I would first like to hear if anyone has any objections or suggestions. > I think the distinction between the / @when approach and is not clear enough ? even I can't recall it right now without reading my way through the guidelines. Isn't it great to spot new work after a release is done? ;-) Best, Jo > Thanks, > -Andrew > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From bohl at edirom.de Wed May 29 15:21:45 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Wed, 29 May 2013 15:21:45 +0200 Subject: [MEI-L] MEI Council Meeting, personal report Message-ID: <51A600E9.2040508@edirom.de> Dear [MEI-L]isteners, I herby provide you with my personal summary of the MEI Council Meeting held on Friday 24 from 3:30 pm to 6:00 pm at the end of Music Encoding Conference 2013 at the Academy of Science and Literature, Mainz May 21 to 24. Please respect the fact, that this is my personal sight on the meeting and I was not officially appointed to take minutes, although I think nobody was, and this is why I decided on sending this. Addition on corrections of my below statements are very welcome, directly on MEI-L. ======= The MEI Council Meeting was set to be open for everybody; not only members of the council attended, but also others interested in the discussion and willing to contribute. All in all more than 20 people were present (please excuse if anyone attending is missing on the list or any of the names are spelled wrong, feel free to correct me on this): 1. Johannes Kepper 2. Gabriele Buschmeier 3. Karen Desmond 4. Christine Siegert 5. Kristina Richts 6. Maja Hartwig 7. Anna-Maria Komprecht 8. Daniel R?wenstrunk 9. Sigfrid Lundberg 10. Peter Stadler 11. Nikolaos Beer 12. Donald Byrd 13. David Meredith 14. Richard Freedman 15. Eleanor Selfridge-Field 16. Stefan Morent 17. Joachim Veit 18. Guiliano Di Bacco 19. Craig Stuart Sapp 20. Tore Simonsen 21. Laurent Pugin 22. Axel Teich Geertinger 23. Perry Roland 24. Daniel Pitti (chairing the meeting) 25. Andrew Hankinson 26. Benjamin W. Bohl In his introductory words to the question "Where to from here?", Daniel Pitti (chairing the meeting) emphasized on the fairly remarkable progress, that MEI had made in terms of making it a community project. During the short amount of time from first collaborations in 2007 and 2009. The funding received through DFG/NEH Bilateral Digital Humanities Program from 2009 to 2013 helped disseminating the ideas of MEI and motivate additional researchers. With quite an amount of growth during the past few years MEI can proudly say to have something like a community, today. All in all the meeting was an open round of brain storming and discussion of ideas brought up concerning, as main topics: 1) funding development of MEI and the MEI Council 2) current and future organization of MEI and the MEI Community 1) funding development of MEI and the MEI Council In the light current funding ending this year and a third DFG/NEH funding having been denied, the first topic discussed was future funding of MEI community and especially face-to-face meetings of Technical Team and Council. Many suggestions were put forward, but eventually it became clear, that the funding programs mostly target at individual projects considering implementations of MEI for specific projects, and that they would not directly support development of MEI the same way as in recent years. At that point discussion moved towards current structure and organization and possible future forms or organization for the MEI community. 2) current and future organization of MEI and the MEI Community a) current organization Although there was general consensus that the current MEI Council is a worthwhile group that is very helpful to have, certain problems were put forward. A lack of transparency, especially regarding how to opt in or out, and what exactly the Council's role is; acting more like an advisory board, than as steering group for MEI or how its work is related to that of the Technical Team. It was recognized that this might discourage new potential contributors to MEI (MEI Community) from getting in touch, which some of the guests confirmed. b) future organization A multifaceted discussion and brain-storming of possible models for future MEI Community organization followed. Topics of major interest included questions as: - Whether members to a council/advisory board/steering group should be elected? - How such a group should and could reflect the peer groups of the community? - How could a legal status of such a group be achieved; in order to for instance sign letters of support on behalf of MEI Community? - and many more Most prominent during this discussion was an offer presented by Gabriele Buschmeier from the Mainz Academy. She put forward the idea to install MEI as an "Arbeitskreis" (working group) at Mainz Academy, which needs to be convened by a member of the Academy. She promised to determine the possibilities of hosting MEI at the Academy, and talk to Prof. Dr. Kurt G?rtner, whether he could imagine to act as convenor for this. In this context the MEI Community would be mostly free to organize itself, with the Academy providing full support for all administrative issues and serving as legal entity behind MEI. The offer was greatly appreciated by the attendants. Nevertheless, as sound reorganization of the MEI Community structures needs thorough discussion and planning and should not hamper the momentum that has caught the MEI Community. Thus Eleanor Selfridge-Field's proposal to install the following two groups, in addition to the current MEI Council, was accepted: I) An *Interim Steering Group* for MEI Community as a smaller group of people that could act on behalf of the MEI Community until clearer organization and structures are developed and decided upon. As one main subject to deal with, this group should negotiate formal collaboration with the Mainz Academy as described above. This group was decided to be staffed with Gabriele Buschmeier, Perry Roland, Johannes Kepper and potentially Kurt G?rtner (Member of the Academy, to be asked). II) A *Strategy Development Group* assigned to come up with proposals for a new organization of MEI. This group should represent the complete MEI Community, including delegates from peer groups that might not be involved at the moment. For this reason, it was proposed to use MEI-L to gather interested parties for this basically open group. For practical reasons, an initial group of volunteers was set up, which consists of: - Axel Teich Geertinger, - Laurent Pugin, (@Laurent: as you were proposed while shortly absent, is this your will?) - Christine Siegert, and - Benjamin W. Bohl. **Call for Participation** Anyone interested in joining this group please communicate this by replying to this message via MEI-L. If there are no objections I would like to volunteer for coordinating the formation of this group during this initial phase. The preliminary schedule for this group is to draft at least two proposals for future organization of the MEI Community within the next year; bringing these proposals to discussion both in MEI Council and MEI Community, for decision. It was agreed, that transparency and avoidance of bureaucratic overhead should be essential features of new structures, and democracy and participatory aspects should be considered likewise, but without neglecting efficient and simple structures. This might include careful reconsideration of the current structures (MEI Council and MEI Technical Team) that nevertheless have proved to be very helpful and effective fostering the interest of MEI Community and bringing it to ist current shape. It was also agreed that once new structures and forms of organizing MEI Community should be established, these would be examined after a number of years, with the option to revert or change to a different model. ======= With best regards, Benjamin W. Bohl -- *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D--32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail:bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From slu at kb.dk Tue Jun 4 15:01:18 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Tue, 4 Jun 2013 13:01:18 +0000 Subject: [MEI-L] bugs and patches Message-ID: <0C090608704AF04E898055296C932B129A437865@EXCHANGE-01.kb.dk> Dear anyone While transforming stuff I accumulate fixes for mei2mup-1.0.4.xsl I'm using. Suppose that there are at least half a dozen by now. Is there a place to submit them? Yours Sigfrid From andrew.hankinson at mail.mcgill.ca Tue Jun 4 15:06:41 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Tue, 4 Jun 2013 09:06:41 -0400 Subject: [MEI-L] bugs and patches In-Reply-To: <18192_1370350906_51ADE533_18192_5_3_0C090608704AF04E898055296C932B129A437865@EXCHANGE-01.kb.dk> References: <18192_1370350906_51ADE533_18192_5_3_0C090608704AF04E898055296C932B129A437865@EXCHANGE-01.kb.dk> Message-ID: <4D92A108-ED36-47B9-B566-CE8F535EEB85@mail.mcgill.ca> Hi Sigfrid, You can find the Google Code project for MEI here: http://code.google.com/p/music-encoding/ If you want to create a bug report, you can use the Issues tracker. You can also use that to submit a patch for the mei2mup script, and one of the technical team will look at it and, if it looks ok, merge it in for you. Cheers, -Andrew On 2013-06-04, at 9:01 AM, Sigfrid Lundberg wrote: > Dear anyone > > While transforming stuff I accumulate fixes for mei2mup-1.0.4.xsl I'm using. Suppose that there are at least half a dozen by now. Is there a place to submit them? > > Yours > > Sigfrid > _______________________________________________ > 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 Jun 4 15:37:21 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 4 Jun 2013 13:37:21 +0000 Subject: [MEI-L] "When" element pointing In-Reply-To: <799DF2C0-5732-47FB-9ACB-A85A39DF2009@edirom.de> References: , <799DF2C0-5732-47FB-9ACB-A85A39DF2009@edirom.de> Message-ID: First, let me add my congratulations to everyone -- organizers and participants alike -- for a wonderful conference. It was great to commune with the hive. :-) Second, it's possible to point from elements to elements in the music tree using @data, so "pollution" can be avoided now. But, this is an area of the spec that hasn't been exercised a great deal. So, as Jo suggests, we need to re-examine and and clear up any confusion. -- 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, May 29, 2013 2:37 AM To: Music Encoding Initiative Subject: Re: [MEI-L] "When" element pointing Am 28.05.2013 um 22:48 schrieb Andrew Hankinson: > Hi all, > > First, it was great to see everyone in Mainz. Thanks for a wonderful conference. wearing the organizer hat, I'd like to say that we are quite happy with it as well. It wouldn't have been possible without the great help of many, both from the Academy (Anna, Frau Biersch, Frau Buschmeier, Herr Krings, many others I don't even know the names of), and our Detmold team (Maja, Kristina, Anna). Thanks to you very very much indeed! > > Now, back to the business at hand: I was chatting with someone about the linking and alignment of audio and video files with a score. What they're interested in is taking multiple recordings and linking them up to a very sparse score representation (measures or even just sections). > > Looking at how the and @when system works, it doesn't look like this is currently possible; that is, it's possible to point from a score element to a single point on a timeline, but it's not possible to point from a time point to an element in the score. By using @when on a score-level element (measure, note, etc.) you're "polluting" the score representation with its location in a single timeline, rather than having the ability to, in multiple recordings, refer to the same score-level element at different time points. > Switching to the modelling hat, I would suggest to use a different approach: Have you considered something like This follows the model of facsimile and does not pollute the music tree. > I don't think this would be too hard to add so I will volunteer to actually do the coding, but I would first like to hear if anyone has any objections or suggestions. > I think the distinction between the / @when approach and is not clear enough ? even I can't recall it right now without reading my way through the guidelines. Isn't it great to spot new work after a release is done? ;-) Best, Jo > 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 bohl at edirom.de Thu Jun 6 18:43:56 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 06 Jun 2013 18:43:56 +0200 Subject: [MEI-L] CfP MEI Strategy Development Group In-Reply-To: <51A600E9.2040508@edirom.de> References: <51A600E9.2040508@edirom.de> Message-ID: <51B0BC4C.3040608@edirom.de> Dear List:eners, as mentioned before, in my personal report from the MEI Council Meeting at Mainz, MEI has to find new structures for future community development and participation. Having proposed to initialize formation of this group I hereby invite everyone to join the efforts of > A *Strategy Development Group* > > assigned to come up with proposals for a new organization of MEI. This > group should represent the complete MEI Community, including delegates > from peer groups that might not be involved at the moment. For this > reason, it was proposed to use MEI-L to gather interested parties for > this basically open group. > For practical reasons, an initial group of volunteers was set up, > which consists of: > - Axel Teich Geertinger, > - Laurent Pugin, (@Laurent: as you were proposed while shortly absent, > is this your will?) > - Christine Siegert, and > - Benjamin W. Bohl. > > **Call for Participation** Anyone interested in joining this group > please communicate this by replying to this message via MEI-L. > If there are no objections I would like to volunteer for coordinating > the formation of this group during this initial phase. > > The preliminary schedule for this group is to draft at least two > proposals for future organization of the MEI Community within the next > year; bringing these proposals to discussion both in MEI Council and > MEI Community, for decision. > It was agreed, that transparency and avoidance of bureaucratic > overhead should be essential features of new structures, and democracy > and participatory aspects should be considered likewise, but without > neglecting efficient and simple structures. This might include careful > reconsideration of the current structures (MEI Council and MEI > Technical Team) that nevertheless have proved to be very helpful and > effective fostering the interest of MEI Community and bringing it to > ist current shape. > It was also agreed that once new structures and forms of organizing > MEI Community should be established, these would be examined after a > number of years, with the option to revert or change to a different model. If you are interested in joining this group and developing strategies for the future of MEI, please contact me directly. A Mailinglist for internal discussions of this group will be available shortly and I'd be happy to send you an invitation to the list. Best regards, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** From esfield at stanford.edu Fri Jun 7 01:34:31 2013 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Thu, 6 Jun 2013 16:34:31 -0700 (PDT) Subject: [MEI-L] CfP MEI Strategy Development Group In-Reply-To: <51B0BC4C.3040608@edirom.de> References: <51A600E9.2040508@edirom.de> <51B0BC4C.3040608@edirom.de> Message-ID: <1190f066.00000d80.0000000e@CCARH-ADM-2.su.win.stanford.edu> Hi, Benjamin, You are starting out with a good steering group. Perhaps you should mail out small parts of the agenda to a large group and see what responses come in. Or...you could identify several topics that need to be addressed and put them in a survey. I'll be happy to read what you come up with, but I doubt I will be able to take an active part in drafting the provisions. Good luck with the task. Eleanor Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ -----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 Benjamin Wolff Bohl Sent: Thursday, June 06, 2013 9:44 AM To: mei-l at lists.uni-paderborn.de Subject: [MEI-L] CfP MEI Strategy Development Group Dear List:eners, as mentioned before, in my personal report from the MEI Council Meeting at Mainz, MEI has to find new structures for future community development and participation. Having proposed to initialize formation of this group I hereby invite everyone to join the efforts of > A *Strategy Development Group* > > assigned to come up with proposals for a new organization of MEI. This > group should represent the complete MEI Community, including delegates > from peer groups that might not be involved at the moment. For this > reason, it was proposed to use MEI-L to gather interested parties for > this basically open group. > For practical reasons, an initial group of volunteers was set up, > which consists of: > - Axel Teich Geertinger, > - Laurent Pugin, (@Laurent: as you were proposed while shortly absent, > is this your will?) > - Christine Siegert, and > - Benjamin W. Bohl. > > **Call for Participation** Anyone interested in joining this group > please communicate this by replying to this message via MEI-L. > If there are no objections I would like to volunteer for coordinating > the formation of this group during this initial phase. > > The preliminary schedule for this group is to draft at least two > proposals for future organization of the MEI Community within the next > year; bringing these proposals to discussion both in MEI Council and > MEI Community, for decision. > It was agreed, that transparency and avoidance of bureaucratic > overhead should be essential features of new structures, and democracy > and participatory aspects should be considered likewise, but without > neglecting efficient and simple structures. This might include careful > reconsideration of the current structures (MEI Council and MEI > Technical Team) that nevertheless have proved to be very helpful and > effective fostering the interest of MEI Community and bringing it to > ist current shape. > It was also agreed that once new structures and forms of organizing > MEI Community should be established, these would be examined after a > number of years, with the option to revert or change to a different model. If you are interested in joining this group and developing strategies for the future of MEI, please contact me directly. A Mailinglist for internal discussions of this group will be available shortly and I'd be happy to send you an invitation to the list. Best regards, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From bohl at edirom.de Fri Jun 7 08:40:21 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 07 Jun 2013 08:40:21 +0200 Subject: [MEI-L] CfP MEI Strategy Development Group In-Reply-To: <1190f066.00000d80.0000000e@CCARH-ADM-2.su.win.stanford.edu> References: <51A600E9.2040508@edirom.de> <51B0BC4C.3040608@edirom.de> <1190f066.00000d80.0000000e@CCARH-ADM-2.su.win.stanford.edu> Message-ID: <51B18055.4050404@edirom.de> Dear Eleanor, thank you very much for your good input concerning organizing the work of the group. Mailing out portions of the agenda and having surveys on MEI-L seems a very good idea! Sincerely, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 07.06.2013 01:34, schrieb Eleanor Selfridge-Field: > Hi, Benjamin, > > You are starting out with a good steering group. Perhaps you should mail > out small parts of the agenda to a large group and see what responses come > in. Or...you could identify several topics that need to be addressed and > put them in a survey. > > I'll be happy to read what you come up with, but I doubt I will be able to > take an active part in drafting the provisions. Good luck with the task. > > Eleanor > > > Eleanor Selfridge-Field > Consulting Professor, Music (and, by courtesy, Symbolic Systems) > Braun Music Center #129 > Stanford University > Stanford, CA 94305-3076, USA > http://www.stanford.edu/~esfield/ > > > > > > > > -----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 Benjamin Wolff Bohl > Sent: Thursday, June 06, 2013 9:44 AM > To: mei-l at lists.uni-paderborn.de > Subject: [MEI-L] CfP MEI Strategy Development Group > > Dear List:eners, > as mentioned before, in my personal report from the MEI Council Meeting at > Mainz, MEI has to find new structures for future community development and > participation. > Having proposed to initialize formation of this group I hereby invite > everyone to join the efforts of > >> A *Strategy Development Group* >> >> assigned to come up with proposals for a new organization of MEI. This >> group should represent the complete MEI Community, including delegates >> from peer groups that might not be involved at the moment. For this >> reason, it was proposed to use MEI-L to gather interested parties for >> this basically open group. >> For practical reasons, an initial group of volunteers was set up, >> which consists of: >> - Axel Teich Geertinger, >> - Laurent Pugin, (@Laurent: as you were proposed while shortly absent, >> is this your will?) >> - Christine Siegert, and >> - Benjamin W. Bohl. >> >> **Call for Participation** Anyone interested in joining this group >> please communicate this by replying to this message via MEI-L. >> If there are no objections I would like to volunteer for coordinating >> the formation of this group during this initial phase. >> >> The preliminary schedule for this group is to draft at least two >> proposals for future organization of the MEI Community within the next >> year; bringing these proposals to discussion both in MEI Council and >> MEI Community, for decision. >> It was agreed, that transparency and avoidance of bureaucratic >> overhead should be essential features of new structures, and democracy >> and participatory aspects should be considered likewise, but without >> neglecting efficient and simple structures. This might include careful >> reconsideration of the current structures (MEI Council and MEI >> Technical Team) that nevertheless have proved to be very helpful and >> effective fostering the interest of MEI Community and bringing it to >> ist current shape. >> It was also agreed that once new structures and forms of organizing >> MEI Community should be established, these would be examined after a >> number of years, with the option to revert or change to a different > model. > > If you are interested in joining this group and developing strategies for > the future of MEI, please contact me directly. A Mailinglist for internal > discussions of this group will be available shortly and I'd be happy to > send you an invitation to the list. > > > Best regards, > Benjamin > > *********************************************************** > Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz > Digital" > Benjamin Wolff Bohl > Gartenstra?e 20 > D?32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > E-Mail: bohl at edirom.de > > http://www.freischuetz-digital.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 stadler at edirom.de Tue Jun 11 17:02:30 2013 From: stadler at edirom.de (Peter Stadler) Date: Tue, 11 Jun 2013 17:02:30 +0200 Subject: [MEI-L] CfP MEI Strategy Development Group In-Reply-To: <51B18055.4050404@edirom.de> References: <51A600E9.2040508@edirom.de> <51B0BC4C.3040608@edirom.de> <1190f066.00000d80.0000000e@CCARH-ADM-2.su.win.stanford.edu> <51B18055.4050404@edirom.de> Message-ID: <7A8F3DC8-1885-49E0-86ED-1F9F81CCA89A@edirom.de> Just wanted to second this idea. Please keep MEI-L informed and don't hide the discussion in another list. (I would go so far to question the need for a separate list at all ...) Best Peter Am 07.06.2013 um 08:40 schrieb Benjamin Wolff Bohl : > Dear Eleanor, > thank you very much for your good input concerning organizing the work of the group. > Mailing out portions of the agenda and having surveys on MEI-L seems a very good idea! > > Sincerely, > Benjamin > > *********************************************************** > Musikwissenschaftliches Seminar Detmold/Paderborn > BMBF-Projekt "Freisch?tz Digital" > Benjamin Wolff Bohl > Gartenstra?e 20 > D?32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > E-Mail: bohl at edirom.de > > http://www.freischuetz-digital.de > *********************************************************** > > Am 07.06.2013 01:34, schrieb Eleanor Selfridge-Field: >> Hi, Benjamin, >> >> You are starting out with a good steering group. Perhaps you should mail >> out small parts of the agenda to a large group and see what responses come >> in. Or...you could identify several topics that need to be addressed and >> put them in a survey. >> >> I'll be happy to read what you come up with, but I doubt I will be able to >> take an active part in drafting the provisions. Good luck with the task. >> >> Eleanor >> >> >> Eleanor Selfridge-Field >> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >> Braun Music Center #129 >> Stanford University >> Stanford, CA 94305-3076, USA >> http://www.stanford.edu/~esfield/ >> >> >> >> >> >> >> >> -----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 Benjamin Wolff Bohl >> Sent: Thursday, June 06, 2013 9:44 AM >> To: mei-l at lists.uni-paderborn.de >> Subject: [MEI-L] CfP MEI Strategy Development Group >> >> Dear List:eners, >> as mentioned before, in my personal report from the MEI Council Meeting at >> Mainz, MEI has to find new structures for future community development and >> participation. >> Having proposed to initialize formation of this group I hereby invite >> everyone to join the efforts of >> >>> A *Strategy Development Group* >>> >>> assigned to come up with proposals for a new organization of MEI. This >>> group should represent the complete MEI Community, including delegates >>> from peer groups that might not be involved at the moment. For this >>> reason, it was proposed to use MEI-L to gather interested parties for >>> this basically open group. >>> For practical reasons, an initial group of volunteers was set up, >>> which consists of: >>> - Axel Teich Geertinger, >>> - Laurent Pugin, (@Laurent: as you were proposed while shortly absent, >>> is this your will?) >>> - Christine Siegert, and >>> - Benjamin W. Bohl. >>> >>> **Call for Participation** Anyone interested in joining this group >>> please communicate this by replying to this message via MEI-L. >>> If there are no objections I would like to volunteer for coordinating >>> the formation of this group during this initial phase. >>> >>> The preliminary schedule for this group is to draft at least two >>> proposals for future organization of the MEI Community within the next >>> year; bringing these proposals to discussion both in MEI Council and >>> MEI Community, for decision. >>> It was agreed, that transparency and avoidance of bureaucratic >>> overhead should be essential features of new structures, and democracy >>> and participatory aspects should be considered likewise, but without >>> neglecting efficient and simple structures. This might include careful >>> reconsideration of the current structures (MEI Council and MEI >>> Technical Team) that nevertheless have proved to be very helpful and >>> effective fostering the interest of MEI Community and bringing it to >>> ist current shape. >>> It was also agreed that once new structures and forms of organizing >>> MEI Community should be established, these would be examined after a >>> number of years, with the option to revert or change to a different >> model. >> >> If you are interested in joining this group and developing strategies for >> the future of MEI, please contact me directly. A Mailinglist for internal >> discussions of this group will be available shortly and I'd be happy to >> send you an invitation to the list. >> >> >> Best regards, >> Benjamin >> >> *********************************************************** >> Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz >> Digital" >> Benjamin Wolff Bohl >> Gartenstra?e 20 >> D?32756 Detmold >> >> Tel. +49 (0) 5231 / 975-669 >> Fax: +49 (0) 5231 / 975-668 >> E-Mail: bohl at edirom.de >> >> http://www.freischuetz-digital.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 > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From bc at bradcohen.net Wed Jun 12 09:28:37 2013 From: bc at bradcohen.net (Brad Cohen) Date: Wed, 12 Jun 2013 08:28:37 +0100 Subject: [MEI-L] Release of MEI 2013 In-Reply-To: References: Message-ID: On my way back to normal - including vocabulary! My accident was quite serious and I feel very lucky to be here. Look forward to being in touch soon. all best Brad On 24 May 2013, at 23:05, Johannes Kepper wrote: > Dear MEI Community, > > this week, we had a very productive conference at the Mainz Academy for Sciences and Literature, which was generally perceived as the MEI Members Meeting ? a title which officially wasn't assigned. While I'm sure others may be better suited to report on the conference itself, I would like to repeat an announcement made during the conference for those of us that couldn't make it to Mainz. > > --- > > We are happy to announce the release of MEI2013, a new iteration of our data framework. The release is available from http://music-encoding.org/downloads/mei2013 or the development repository at https://code.google.com/p/music-encoding/. The most distinct new feature is the implementation of FRBR, the Functional Requirements for Bibliographic Records. This model allows an easier alignment with state-of-the-art bibliographic data, but also opens new perspectives for scholarly editions. The merMEId tool developed by Siegfried Lundberg and Axel Teich Geertinger in Copenhagen, which they have announced several weeks ago on this list, already makes excellent use of this new module. > > With this new release, we also revised our website http://music.encoding.org to reflect all related changes. Most notably, this includes an online version of the Guidelines (http://music.encoding.org/documentation/guidelines2013), and a Sample Collection (http://music.encoding.org/documentation/samples) providing a set of about 150 MEI files conforming to either the 2012 or 2013 release. Most of these files are joined by a PDF with images of the underlying source and illustrate manifold aspects of MEI. However, this is intended to be an open collection, containing MEI instances from various origins. So if you happen to have an encoding of MEI at hand that you would be happy to share, please get in touch. There is also a search function available, which currently offers to search within certain metadata of the collection. The expansion of this functionality will be one of the major tasks for the upcoming months. > > A big thank goes to the MEI Technical Team for preparing this release. While many people have helped, let me explicitly mention Axel Teich Geertinger, who did a great job on the development, testing and documentation of the new FRBR module. I would also like to emphasize the contribution of Maja Hartwig and Kristina Richts, who did a great job on the sample collection, providing another great resource for getting in touch with MEI. Thank you ever so much. > > Best regards from Mainz, > Johannes > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From bohl at edirom.de Wed Jun 12 18:05:35 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Wed, 12 Jun 2013 18:05:35 +0200 Subject: [MEI-L] Release of MEI 2013 In-Reply-To: References: Message-ID: <51B89C4F.2030602@edirom.de> Dear Brad, get well soon! All the best to you, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 12.06.2013 09:28, schrieb Brad Cohen: > On my way back to normal - including vocabulary! My accident was quite serious and I feel very lucky to be here. > > Look forward to being in touch soon. > > all best > > Brad > > On 24 May 2013, at 23:05, Johannes Kepper wrote: > >> Dear MEI Community, >> >> this week, we had a very productive conference at the Mainz Academy for Sciences and Literature, which was generally perceived as the MEI Members Meeting ? a title which officially wasn't assigned. While I'm sure others may be better suited to report on the conference itself, I would like to repeat an announcement made during the conference for those of us that couldn't make it to Mainz. >> >> --- >> >> We are happy to announce the release of MEI2013, a new iteration of our data framework. The release is available from http://music-encoding.org/downloads/mei2013 or the development repository at https://code.google.com/p/music-encoding/. The most distinct new feature is the implementation of FRBR, the Functional Requirements for Bibliographic Records. This model allows an easier alignment with state-of-the-art bibliographic data, but also opens new perspectives for scholarly editions. The merMEId tool developed by Siegfried Lundberg and Axel Teich Geertinger in Copenhagen, which they have announced several weeks ago on this list, already makes excellent use of this new module. >> >> With this new release, we also revised our website http://music.encoding.org to reflect all related changes. Most notably, this includes an online version of the Guidelines (http://music.encoding.org/documentation/guidelines2013), and a Sample Collection (http://music.encoding.org/documentation/samples) providing a set of about 150 MEI files conforming to either the 2012 or 2013 release. Most of these files are joined by a PDF with images of the underlying source and illustrate manifold aspects of MEI. However, this is intended to be an open collection, containing MEI instances from various origins. So if you happen to have an encoding of MEI at hand that you would be happy to share, please get in touch. There is also a search function available, which currently offers to search within certain metadata of the collection. The expansion of this functionality will be one of the major tasks for the upcoming months. >> >> A big thank goes to the MEI Technical Team for preparing this release. While many people have helped, let me explicitly mention Axel Teich Geertinger, who did a great job on the development, testing and documentation of the new FRBR module. I would also like to emphasize the contribution of Maja Hartwig and Kristina Richts, who did a great job on the sample collection, providing another great resource for getting in touch with MEI. Thank you ever so much. >> >> Best regards from Mainz, >> 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 bohl at edirom.de Wed Jun 12 18:05:46 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Wed, 12 Jun 2013 18:05:46 +0200 Subject: [MEI-L] CfP MEI Strategy Development Group In-Reply-To: <7A8F3DC8-1885-49E0-86ED-1F9F81CCA89A@edirom.de> References: <51A600E9.2040508@edirom.de> <51B0BC4C.3040608@edirom.de> <1190f066.00000d80.0000000e@CCARH-ADM-2.su.win.stanford.edu> <51B18055.4050404@edirom.de> <7A8F3DC8-1885-49E0-86ED-1F9F81CCA89A@edirom.de> Message-ID: <51B89C5A.4070601@edirom.de> Dear Peter, thanks for your concerns regarding a separate list for the Structure Development Group. Of course, discussion of the Structure Development Group should be as open and transparent as possible! My first (1) thoughts for a separate mailinglist were that it would make it easier to keep together the discussion of the group; second (2), being appointed with the task of making up a couple of possible models for community organisation I think it is easier to have the possibility to develop these models to a certain degree, before prensenting them for public discussion. Third (3) this mailinglist would provide everybody with the possibility to directly address the whole Structure Development Group and fourth (4), being most important, avoid mails between group members to end in personal mail accounts, later forgotten and unavailable to the public by providing an archive of the mailinglist. My idea with this was to have only those wiling to participate in the group's work as members of the list but allow (moderated) input from anybody. Of course this would mean, an open list archive and regular reports to MEI-L on behalf of the Structure Development Group; and, of course, open discussion and (as I could imagine) surveys on MEI-L in order to grasp "waht does MEI want?" But for now I can calm everyone: nothing has been mingled on dark secluded mailinlists ;-) In fact, while making up a preliminary agenda for MEI-Struct during the past few days, a couple of mails reached me, concerning the groups work. >From the fact that these reached me by means of personal mail accounts (not over MEI-L) tells me, that there might be an interest in forwarding ideas and fist thoughts on a personal basis first! I'd be happy to hear other opinions on the above? (Especially from contributors to the new Structure Development Group!) Now to give a short report on current status: I'm happy to announce that two additional community members have joined the Structure Development Group: David Meredith, and Giuliano Di Bacco Best wishes, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 11.06.2013 17:02, schrieb Peter Stadler: > Just wanted to second this idea. > Please keep MEI-L informed and don't hide the discussion in another list. (I would go so far to question the need for a separate list at all ...) > > Best > Peter > > Am 07.06.2013 um 08:40 schrieb Benjamin Wolff Bohl : > >> Dear Eleanor, >> thank you very much for your good input concerning organizing the work of the group. >> Mailing out portions of the agenda and having surveys on MEI-L seems a very good idea! >> >> Sincerely, >> Benjamin >> >> *********************************************************** >> Musikwissenschaftliches Seminar Detmold/Paderborn >> BMBF-Projekt "Freisch?tz Digital" >> Benjamin Wolff Bohl >> Gartenstra?e 20 >> D?32756 Detmold >> >> Tel. +49 (0) 5231 / 975-669 >> Fax: +49 (0) 5231 / 975-668 >> E-Mail: bohl at edirom.de >> >> http://www.freischuetz-digital.de >> *********************************************************** >> >> Am 07.06.2013 01:34, schrieb Eleanor Selfridge-Field: >>> Hi, Benjamin, >>> >>> You are starting out with a good steering group. Perhaps you should mail >>> out small parts of the agenda to a large group and see what responses come >>> in. Or...you could identify several topics that need to be addressed and >>> put them in a survey. >>> >>> I'll be happy to read what you come up with, but I doubt I will be able to >>> take an active part in drafting the provisions. Good luck with the task. >>> >>> Eleanor >>> >>> >>> Eleanor Selfridge-Field >>> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >>> Braun Music Center #129 >>> Stanford University >>> Stanford, CA 94305-3076, USA >>> http://www.stanford.edu/~esfield/ >>> >>> >>> >>> >>> >>> >>> >>> -----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 Benjamin Wolff Bohl >>> Sent: Thursday, June 06, 2013 9:44 AM >>> To: mei-l at lists.uni-paderborn.de >>> Subject: [MEI-L] CfP MEI Strategy Development Group >>> >>> Dear List:eners, >>> as mentioned before, in my personal report from the MEI Council Meeting at >>> Mainz, MEI has to find new structures for future community development and >>> participation. >>> Having proposed to initialize formation of this group I hereby invite >>> everyone to join the efforts of >>> >>>> A *Strategy Development Group* >>>> >>>> assigned to come up with proposals for a new organization of MEI. This >>>> group should represent the complete MEI Community, including delegates >>>> from peer groups that might not be involved at the moment. For this >>>> reason, it was proposed to use MEI-L to gather interested parties for >>>> this basically open group. >>>> For practical reasons, an initial group of volunteers was set up, >>>> which consists of: >>>> - Axel Teich Geertinger, >>>> - Laurent Pugin, (@Laurent: as you were proposed while shortly absent, >>>> is this your will?) >>>> - Christine Siegert, and >>>> - Benjamin W. Bohl. >>>> >>>> **Call for Participation** Anyone interested in joining this group >>>> please communicate this by replying to this message via MEI-L. >>>> If there are no objections I would like to volunteer for coordinating >>>> the formation of this group during this initial phase. >>>> >>>> The preliminary schedule for this group is to draft at least two >>>> proposals for future organization of the MEI Community within the next >>>> year; bringing these proposals to discussion both in MEI Council and >>>> MEI Community, for decision. >>>> It was agreed, that transparency and avoidance of bureaucratic >>>> overhead should be essential features of new structures, and democracy >>>> and participatory aspects should be considered likewise, but without >>>> neglecting efficient and simple structures. This might include careful >>>> reconsideration of the current structures (MEI Council and MEI >>>> Technical Team) that nevertheless have proved to be very helpful and >>>> effective fostering the interest of MEI Community and bringing it to >>>> ist current shape. >>>> It was also agreed that once new structures and forms of organizing >>>> MEI Community should be established, these would be examined after a >>>> number of years, with the option to revert or change to a different >>> model. >>> >>> If you are interested in joining this group and developing strategies for >>> the future of MEI, please contact me directly. A Mailinglist for internal >>> discussions of this group will be available shortly and I'd be happy to >>> send you an invitation to the list. >>> >>> >>> Best regards, >>> Benjamin >>> >>> *********************************************************** >>> Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz >>> Digital" >>> Benjamin Wolff Bohl >>> Gartenstra?e 20 >>> D?32756 Detmold >>> >>> Tel. +49 (0) 5231 / 975-669 >>> Fax: +49 (0) 5231 / 975-668 >>> E-Mail: bohl at edirom.de >>> >>> http://www.freischuetz-digital.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 >> >> _______________________________________________ >> 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 gdibacco at indiana.edu Thu Jun 13 01:32:09 2013 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Wed, 12 Jun 2013 19:32:09 -0400 Subject: [MEI-L] CfP MEI Strategy Development Group In-Reply-To: <51B89C5A.4070601@edirom.de> References: <51A600E9.2040508@edirom.de> <51B0BC4C.3040608@edirom.de> <1190f066.00000d80.0000000e@CCARH-ADM-2.su.win.stanford.edu> <51B18055.4050404@edirom.de> <7A8F3DC8-1885-49E0-86ED-1F9F81CCA89A@edirom.de> <51B89C5A.4070601@edirom.de> Message-ID: <51B904F9.30108@indiana.edu> An HTML attachment was scrubbed... URL: From atge at kb.dk Thu Jun 13 14:14:02 2013 From: atge at kb.dk (Axel Teich Geertinger) Date: Thu, 13 Jun 2013 12:14:02 +0000 Subject: [MEI-L] CfP MEI Strategy Development Group In-Reply-To: <51B89C5A.4070601@edirom.de> References: <51A600E9.2040508@edirom.de> <51B0BC4C.3040608@edirom.de> <1190f066.00000d80.0000000e@CCARH-ADM-2.su.win.stanford.edu> <51B18055.4050404@edirom.de> <7A8F3DC8-1885-49E0-86ED-1F9F81CCA89A@edirom.de> <51B89C5A.4070601@edirom.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D19A3B75D2@EXCHANGE-01.kb.dk> Benni, I agree. I think the discussions should be open to anyone interested, but on the other hand I don't think we should flood MEI-L with our discussions. I am sure there will be a lot of mails about purely practical matters, for instance about coordinating the group's work, which will not be of interest to anyone else. I do not want to hide these mails from anyone, but I do want to avoid people leaving MEI-L because their inbox gets filled with mails addressing (primarily) a small group. It's like choosing between having a meeting in a train or in a meeting room. In the train, people are gathered because they want to get somewhere, but they are not necessarily going there for the same reason. They probably do not want to hear a group's discussions about the train company. In a meeting room, we can invite people to join the meeting if they want to; otherwise, they can just pass by. One could even ask what the point would be in appointing a structure development group if all discussions are to take place in the community at large. But of course we must be in close contact to MEI-L too as you suggest, and the group's discussions should be accessible in an open archive. I'm happy to welcome Dave and Giuliano to the group! And Giuliano, no need to apalogize - I think it is most valuable also people not too deeply involved in the development so far are represented; after all, the discussions are also about how to ensure openness towards the general public, MEI users, and future MEI developers. For now, the group of MEI users may be more or less identical to the group of MEI developers. Hopefully, that is going to change in the future, and there will be far more users than people involved in the current council. In my opinion, this makes it even more important to have the existing and rather large group of people actively contributing to the development of MEI (the current council + some more) organized somehow also in the future structure of the MEI community - as an advisory board or whatever. As I see it, this group is an essential resource and driving force for MEI development, contributing with code, ideas, bug reports, guidelines, trying out concepts, spreading the word etc. Users are something different. Well, that's part of the discussion already. If we agree to have a separate mei-strat mailing list, please do join it if you want to participate in - or just follow - the discussions. Best, Axel -----Oprindelig meddelelse----- Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl Sendt: 12. juni 2013 18:06 Til: mei-l at lists.uni-paderborn.de Emne: Re: [MEI-L] CfP MEI Strategy Development Group Dear Peter, thanks for your concerns regarding a separate list for the Structure Development Group. Of course, discussion of the Structure Development Group should be as open and transparent as possible! My first (1) thoughts for a separate mailinglist were that it would make it easier to keep together the discussion of the group; second (2), being appointed with the task of making up a couple of possible models for community organisation I think it is easier to have the possibility to develop these models to a certain degree, before prensenting them for public discussion. Third (3) this mailinglist would provide everybody with the possibility to directly address the whole Structure Development Group and fourth (4), being most important, avoid mails between group members to end in personal mail accounts, later forgotten and unavailable to the public by providing an archive of the mailinglist. My idea with this was to have only those wiling to participate in the group's work as members of the list but allow (moderated) input from anybody. Of course this would mean, an open list archive and regular reports to MEI-L on behalf of the Structure Development Group; and, of course, open discussion and (as I could imagine) surveys on MEI-L in order to grasp "waht does MEI want?" But for now I can calm everyone: nothing has been mingled on dark secluded mailinlists ;-) In fact, while making up a preliminary agenda for MEI-Struct during the past few days, a couple of mails reached me, concerning the groups work. >From the fact that these reached me by means of personal mail accounts (not over MEI-L) tells me, that there might be an interest in forwarding ideas and fist thoughts on a personal basis first! I'd be happy to hear other opinions on the above? (Especially from contributors to the new Structure Development Group!) Now to give a short report on current status: I'm happy to announce that two additional community members have joined the Structure Development Group: David Meredith, and Giuliano Di Bacco Best wishes, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D-32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 11.06.2013 17:02, schrieb Peter Stadler: > Just wanted to second this idea. > Please keep MEI-L informed and don't hide the discussion in another > list. (I would go so far to question the need for a separate list at > all ...) > > Best > Peter > > Am 07.06.2013 um 08:40 schrieb Benjamin Wolff Bohl : > >> Dear Eleanor, >> thank you very much for your good input concerning organizing the work of the group. >> Mailing out portions of the agenda and having surveys on MEI-L seems a very good idea! >> >> Sincerely, >> Benjamin >> >> *********************************************************** >> Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt >> "Freisch?tz Digital" >> Benjamin Wolff Bohl >> Gartenstra?e 20 >> D-32756 Detmold >> >> Tel. +49 (0) 5231 / 975-669 >> Fax: +49 (0) 5231 / 975-668 >> E-Mail: bohl at edirom.de >> >> http://www.freischuetz-digital.de >> *********************************************************** >> >> Am 07.06.2013 01:34, schrieb Eleanor Selfridge-Field: >>> Hi, Benjamin, >>> >>> You are starting out with a good steering group. Perhaps you should >>> mail out small parts of the agenda to a large group and see what >>> responses come in. Or...you could identify several topics that need >>> to be addressed and put them in a survey. >>> >>> I'll be happy to read what you come up with, but I doubt I will be >>> able to take an active part in drafting the provisions. Good luck with the task. >>> >>> Eleanor >>> >>> >>> Eleanor Selfridge-Field >>> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >>> Braun Music Center #129 Stanford University Stanford, CA 94305-3076, >>> USA http://www.stanford.edu/~esfield/ >>> >>> >>> >>> >>> >>> >>> >>> -----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 Benjamin Wolff Bohl >>> Sent: Thursday, June 06, 2013 9:44 AM >>> To: mei-l at lists.uni-paderborn.de >>> Subject: [MEI-L] CfP MEI Strategy Development Group >>> >>> Dear List:eners, >>> as mentioned before, in my personal report from the MEI Council >>> Meeting at Mainz, MEI has to find new structures for future >>> community development and participation. >>> Having proposed to initialize formation of this group I hereby >>> invite everyone to join the efforts of >>> >>>> A *Strategy Development Group* >>>> >>>> assigned to come up with proposals for a new organization of MEI. >>>> This group should represent the complete MEI Community, including >>>> delegates from peer groups that might not be involved at the >>>> moment. For this reason, it was proposed to use MEI-L to gather >>>> interested parties for this basically open group. >>>> For practical reasons, an initial group of volunteers was set up, >>>> which consists of: >>>> - Axel Teich Geertinger, >>>> - Laurent Pugin, (@Laurent: as you were proposed while shortly >>>> absent, is this your will?) >>>> - Christine Siegert, and >>>> - Benjamin W. Bohl. >>>> >>>> **Call for Participation** Anyone interested in joining this group >>>> please communicate this by replying to this message via MEI-L. >>>> If there are no objections I would like to volunteer for >>>> coordinating the formation of this group during this initial phase. >>>> >>>> The preliminary schedule for this group is to draft at least two >>>> proposals for future organization of the MEI Community within the >>>> next year; bringing these proposals to discussion both in MEI >>>> Council and MEI Community, for decision. >>>> It was agreed, that transparency and avoidance of bureaucratic >>>> overhead should be essential features of new structures, and >>>> democracy and participatory aspects should be considered likewise, >>>> but without neglecting efficient and simple structures. This might >>>> include careful reconsideration of the current structures (MEI >>>> Council and MEI Technical Team) that nevertheless have proved to be >>>> very helpful and effective fostering the interest of MEI Community >>>> and bringing it to ist current shape. >>>> It was also agreed that once new structures and forms of organizing >>>> MEI Community should be established, these would be examined after >>>> a number of years, with the option to revert or change to a >>>> different >>> model. >>> >>> If you are interested in joining this group and developing >>> strategies for the future of MEI, please contact me directly. A >>> Mailinglist for internal discussions of this group will be available >>> shortly and I'd be happy to send you an invitation to the list. >>> >>> >>> Best regards, >>> Benjamin >>> >>> *********************************************************** >>> Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt >>> "Freisch?tz Digital" >>> Benjamin Wolff Bohl >>> Gartenstra?e 20 >>> D-32756 Detmold >>> >>> Tel. +49 (0) 5231 / 975-669 >>> Fax: +49 (0) 5231 / 975-668 >>> E-Mail: bohl at edirom.de >>> >>> http://www.freischuetz-digital.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 >> >> _______________________________________________ >> 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 Thu Jun 13 14:21:10 2013 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 13 Jun 2013 14:21:10 +0200 Subject: [MEI-L] CfP MEI Strategy Development Group In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D19A3B75D2@EXCHANGE-01.kb.dk> References: <51A600E9.2040508@edirom.de> <51B0BC4C.3040608@edirom.de> <1190f066.00000d80.0000000e@CCARH-ADM-2.su.win.stanford.edu> <51B18055.4050404@edirom.de> <7A8F3DC8-1885-49E0-86ED-1F9F81CCA89A@edirom.de> <51B89C5A.4070601@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B75D2@EXCHANGE-01.kb.dk> Message-ID: <9EB7F608-0A95-4F82-B144-1EF272F0A23D@edirom.de> Axel, I couldn't agree more with what you said, especially about the distinction between developers and users. I think this is the opportunity to shape MEI so that it becomes more user-friendly, and to make it as accessible and open for anyone as possible. From this perspective, it's terrific that Giuliano and David have joined the group. Without knowing the exact group, I hope that others with a less-developed background in digital projects will join the group ? it seems important to get input from traditional musicologists, librarians etc. as well. Benni: Thanks for driving this :-) I assume you will announce the availability of this mailing list as soon as it's there, right? Best regards, Johannes Am 13.06.2013 um 14:14 schrieb Axel Teich Geertinger : > Benni, > > I agree. I think the discussions should be open to anyone interested, but on the other hand I don't think we should flood MEI-L with our discussions. I am sure there will be a lot of mails about purely practical matters, for instance about coordinating the group's work, which will not be of interest to anyone else. I do not want to hide these mails from anyone, but I do want to avoid people leaving MEI-L because their inbox gets filled with mails addressing (primarily) a small group. It's like choosing between having a meeting in a train or in a meeting room. In the train, people are gathered because they want to get somewhere, but they are not necessarily going there for the same reason. They probably do not want to hear a group's discussions about the train company. In a meeting room, we can invite people to join the meeting if they want to; otherwise, they can just pass by. One could even ask what the point would be in appointing a structure development group if all discussions are to take place in the community at large. But of course we must be in close contact to MEI-L too as you suggest, and the group's discussions should be accessible in an open archive. > > I'm happy to welcome Dave and Giuliano to the group! And Giuliano, no need to apalogize - I think it is most valuable also people not too deeply involved in the development so far are represented; after all, the discussions are also about how to ensure openness towards the general public, MEI users, and future MEI developers. For now, the group of MEI users may be more or less identical to the group of MEI developers. Hopefully, that is going to change in the future, and there will be far more users than people involved in the current council. In my opinion, this makes it even more important to have the existing and rather large group of people actively contributing to the development of MEI (the current council + some more) organized somehow also in the future structure of the MEI community - as an advisory board or whatever. As I see it, this group is an essential resource and driving force for MEI development, contributing with code, ideas, bug reports, guidelines, trying out concepts, spreading the word etc. Users are something different. > > Well, that's part of the discussion already. If we agree to have a separate mei-strat mailing list, please do join it if you want to participate in - or just follow - the discussions. > > Best, > Axel > > > -----Oprindelig meddelelse----- > Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl > Sendt: 12. juni 2013 18:06 > Til: mei-l at lists.uni-paderborn.de > Emne: Re: [MEI-L] CfP MEI Strategy Development Group > > Dear Peter, > thanks for your concerns regarding a separate list for the Structure Development Group. > Of course, discussion of the Structure Development Group should be as open and transparent as possible! > > My first (1) thoughts for a separate mailinglist were that it would make it easier to keep together the discussion of the group; second (2), being appointed with the task of making up a couple of possible models for community organisation I think it is easier to have the possibility to develop these models to a certain degree, before prensenting them for public discussion. > Third (3) this mailinglist would provide everybody with the possibility to directly address the whole Structure Development Group and fourth (4), being most important, avoid mails between group members to end in personal mail accounts, later forgotten and unavailable to the public by providing an archive of the mailinglist. > My idea with this was to have only those wiling to participate in the group's work as members of the list but allow (moderated) input from anybody. > Of course this would mean, an open list archive and regular reports to MEI-L on behalf of the Structure Development Group; and, of course, open discussion and (as I could imagine) surveys on MEI-L in order to grasp "waht does MEI want?" > > But for now I can calm everyone: nothing has been mingled on dark secluded mailinlists ;-) In fact, while making up a preliminary agenda for MEI-Struct during the past few days, a couple of mails reached me, concerning the groups work. > From the fact that these reached me by means of personal mail accounts (not over MEI-L) tells me, that there might be an interest in forwarding ideas and fist thoughts on a personal basis first! > > I'd be happy to hear other opinions on the above? (Especially from contributors to the new Structure Development Group!) > > Now to give a short report on current status: > I'm happy to announce that two additional community members have joined the Structure Development Group: > David Meredith, and > Giuliano Di Bacco > > Best wishes, > Benjamin > > *********************************************************** > Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" > Benjamin Wolff Bohl > Gartenstra?e 20 > D-32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > E-Mail: bohl at edirom.de > > http://www.freischuetz-digital.de > *********************************************************** > > Am 11.06.2013 17:02, schrieb Peter Stadler: >> Just wanted to second this idea. >> Please keep MEI-L informed and don't hide the discussion in another >> list. (I would go so far to question the need for a separate list at >> all ...) >> >> Best >> Peter >> >> Am 07.06.2013 um 08:40 schrieb Benjamin Wolff Bohl : >> >>> Dear Eleanor, >>> thank you very much for your good input concerning organizing the work of the group. >>> Mailing out portions of the agenda and having surveys on MEI-L seems a very good idea! >>> >>> Sincerely, >>> Benjamin >>> >>> *********************************************************** >>> Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt >>> "Freisch?tz Digital" >>> Benjamin Wolff Bohl >>> Gartenstra?e 20 >>> D-32756 Detmold >>> >>> Tel. +49 (0) 5231 / 975-669 >>> Fax: +49 (0) 5231 / 975-668 >>> E-Mail: bohl at edirom.de >>> >>> http://www.freischuetz-digital.de >>> *********************************************************** >>> >>> Am 07.06.2013 01:34, schrieb Eleanor Selfridge-Field: >>>> Hi, Benjamin, >>>> >>>> You are starting out with a good steering group. Perhaps you should >>>> mail out small parts of the agenda to a large group and see what >>>> responses come in. Or...you could identify several topics that need >>>> to be addressed and put them in a survey. >>>> >>>> I'll be happy to read what you come up with, but I doubt I will be >>>> able to take an active part in drafting the provisions. Good luck with the task. >>>> >>>> Eleanor >>>> >>>> >>>> Eleanor Selfridge-Field >>>> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >>>> Braun Music Center #129 Stanford University Stanford, CA 94305-3076, >>>> USA http://www.stanford.edu/~esfield/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----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 Benjamin Wolff Bohl >>>> Sent: Thursday, June 06, 2013 9:44 AM >>>> To: mei-l at lists.uni-paderborn.de >>>> Subject: [MEI-L] CfP MEI Strategy Development Group >>>> >>>> Dear List:eners, >>>> as mentioned before, in my personal report from the MEI Council >>>> Meeting at Mainz, MEI has to find new structures for future >>>> community development and participation. >>>> Having proposed to initialize formation of this group I hereby >>>> invite everyone to join the efforts of >>>> >>>>> A *Strategy Development Group* >>>>> >>>>> assigned to come up with proposals for a new organization of MEI. >>>>> This group should represent the complete MEI Community, including >>>>> delegates from peer groups that might not be involved at the >>>>> moment. For this reason, it was proposed to use MEI-L to gather >>>>> interested parties for this basically open group. >>>>> For practical reasons, an initial group of volunteers was set up, >>>>> which consists of: >>>>> - Axel Teich Geertinger, >>>>> - Laurent Pugin, (@Laurent: as you were proposed while shortly >>>>> absent, is this your will?) >>>>> - Christine Siegert, and >>>>> - Benjamin W. Bohl. >>>>> >>>>> **Call for Participation** Anyone interested in joining this group >>>>> please communicate this by replying to this message via MEI-L. >>>>> If there are no objections I would like to volunteer for >>>>> coordinating the formation of this group during this initial phase. >>>>> >>>>> The preliminary schedule for this group is to draft at least two >>>>> proposals for future organization of the MEI Community within the >>>>> next year; bringing these proposals to discussion both in MEI >>>>> Council and MEI Community, for decision. >>>>> It was agreed, that transparency and avoidance of bureaucratic >>>>> overhead should be essential features of new structures, and >>>>> democracy and participatory aspects should be considered likewise, >>>>> but without neglecting efficient and simple structures. This might >>>>> include careful reconsideration of the current structures (MEI >>>>> Council and MEI Technical Team) that nevertheless have proved to be >>>>> very helpful and effective fostering the interest of MEI Community >>>>> and bringing it to ist current shape. >>>>> It was also agreed that once new structures and forms of organizing >>>>> MEI Community should be established, these would be examined after >>>>> a number of years, with the option to revert or change to a >>>>> different >>>> model. >>>> >>>> If you are interested in joining this group and developing >>>> strategies for the future of MEI, please contact me directly. A >>>> Mailinglist for internal discussions of this group will be available >>>> shortly and I'd be happy to send you an invitation to the list. >>>> >>>> >>>> Best regards, >>>> Benjamin >>>> >>>> *********************************************************** >>>> Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt >>>> "Freisch?tz Digital" >>>> Benjamin Wolff Bohl >>>> Gartenstra?e 20 >>>> D-32756 Detmold >>>> >>>> Tel. +49 (0) 5231 / 975-669 >>>> Fax: +49 (0) 5231 / 975-668 >>>> E-Mail: bohl at edirom.de >>>> >>>> http://www.freischuetz-digital.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 >>> >>> _______________________________________________ >>> 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 atge at kb.dk Thu Jun 13 19:18:54 2013 From: atge at kb.dk (Axel Teich Geertinger) Date: Thu, 13 Jun 2013 17:18:54 +0000 Subject: [MEI-L] How to encode choices...? Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> Dear list, We are preparing a little experimental digital edition of a piece named "Kaleidakustikon" (c.1820) by Friedrich Kuhlau. It is an aleatoric piece of music of the same kind as, for instance, Kirnberger's "Der allezeit fertige Menuetten- und Polonaisencomponist" and the "Musikalisches W?rfelspiel" attributed to Mozart. It consists of 21 piles of cards, each card containing one bar of music. The player selects one of the 11 cards in each pile by throwing dice. Put together, these cards form a little waltz. The project is of course to make it an online game, at the same time giving us some experience with MEI workflows. The question is: How should we encode the multiple alternatives for each bar? The guidelines explain that the element "groups a number of alternative encodings for the same point in a text". Sounds perfect for this purpose. However, it only allows editorial markup elements like , , , , , , , and as child elements (BTW, the guidelines p. 163 also mention and , but not , , and - a mistake?). How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept? Best, Axel [http://support.kb.dk/images/kb_logo.jpg] Det Kongelige Bibliotek Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder | Interim Head of Centre 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 | 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 14433 bytes Desc: image001.jpg URL: From bohl at edirom.de Thu Jun 13 20:57:21 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 13 Jun 2013 20:57:21 +0200 Subject: [MEI-L] CfP MEI Strategy Development Group In-Reply-To: <9EB7F608-0A95-4F82-B144-1EF272F0A23D@edirom.de> References: <51A600E9.2040508@edirom.de> <51B0BC4C.3040608@edirom.de> <1190f066.00000d80.0000000e@CCARH-ADM-2.su.win.stanford.edu> <51B18055.4050404@edirom.de> <7A8F3DC8-1885-49E0-86ED-1F9F81CCA89A@edirom.de> <51B89C5A.4070601@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B75D2@EXCHANGE-01.kb.dk> <9EB7F608-0A95-4F82-B144-1EF272F0A23D@edirom.de> Message-ID: <51BA1611.2000805@edirom.de> Dear all, the MEI Strategy Development Group mailinglist (mei-Strat at lists.uni-paderborn.de ) is officially available now! Everyone having volunteered so far for being part of the group is registered to the list, being: - Axel T. Geertinger - Christine Siegert - David Meredith - Giuliano Di Bacco - Laurent Pugin and myself: - Benjamin W. Bohl *The list can be addressed by anybody, so feel free to provide us with input or requests!* To say it with a sentence by Giuliano, that surely is true for all of us: > Excellent. I look forward to starting with the good work on MEI-Strat. Nevertheless, as MEI Strategy Development Group still needs some time to form and get itself organised, I beg your pardon with respect to currently: - list subscription needs administrative confirmation, and - non subscribers' contributions to MEI-Strat are set to be moderated. The *Call for Participation* is prevailing so feel free to adress us with you willingness to contribute. In the meantime we might be undertaking first steps, in order to sort out communication strategies, and ogranisational issues, and prepare a first "official" address of MEI-Strat to MEI-L. For the time being and in great expectations, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail:bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 13.06.2013 14:21, schrieb Johannes Kepper: > Axel, > > I couldn't agree more with what you said, especially about the distinction between developers and users. I think this is the opportunity to shape MEI so that it becomes more user-friendly, and to make it as accessible and open for anyone as possible. From this perspective, it's terrific that Giuliano and David have joined the group. Without knowing the exact group, I hope that others with a less-developed background in digital projects will join the group ? it seems important to get input from traditional musicologists, librarians etc. as well. > > Benni: Thanks for driving this :-) I assume you will announce the availability of this mailing list as soon as it's there, right? > > Best regards, > Johannes > > > > Am 13.06.2013 um 14:14 schrieb Axel Teich Geertinger: > >> Benni, >> >> I agree. I think the discussions should be open to anyone interested, but on the other hand I don't think we should flood MEI-L with our discussions. I am sure there will be a lot of mails about purely practical matters, for instance about coordinating the group's work, which will not be of interest to anyone else. I do not want to hide these mails from anyone, but I do want to avoid people leaving MEI-L because their inbox gets filled with mails addressing (primarily) a small group. It's like choosing between having a meeting in a train or in a meeting room. In the train, people are gathered because they want to get somewhere, but they are not necessarily going there for the same reason. They probably do not want to hear a group's discussions about the train company. In a meeting room, we can invite people to join the meeting if they want to; otherwise, they can just pass by. One could even ask what the point would be in appointing a structure development group if all discussions a >> re to take place in the community at large. But of course we must be in close contact to MEI-L too as you suggest, and the group's discussions should be accessible in an open archive. >> >> I'm happy to welcome Dave and Giuliano to the group! And Giuliano, no need to apalogize - I think it is most valuable also people not too deeply involved in the development so far are represented; after all, the discussions are also about how to ensure openness towards the general public, MEI users, and future MEI developers. For now, the group of MEI users may be more or less identical to the group of MEI developers. Hopefully, that is going to change in the future, and there will be far more users than people involved in the current council. In my opinion, this makes it even more important to have the existing and rather large group of people actively contributing to the development of MEI (the current council + some more) organized somehow also in the future structure of the MEI community - as an advisory board or whatever. As I see it, this group is an essential resource and driving force for MEI development, contributing with code, ideas, bug reports, guidelines, trying out con >> cepts, spreading the word etc. Users are something different. >> >> Well, that's part of the discussion already. If we agree to have a separate mei-strat mailing list, please do join it if you want to participate in - or just follow - the discussions. >> >> Best, >> Axel >> >> >> -----Oprindelig meddelelse----- >> Fra:mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl >> Sendt: 12. juni 2013 18:06 >> Til:mei-l at lists.uni-paderborn.de >> Emne: Re: [MEI-L] CfP MEI Strategy Development Group >> >> Dear Peter, >> thanks for your concerns regarding a separate list for the Structure Development Group. >> Of course, discussion of the Structure Development Group should be as open and transparent as possible! >> >> My first (1) thoughts for a separate mailinglist were that it would make it easier to keep together the discussion of the group; second (2), being appointed with the task of making up a couple of possible models for community organisation I think it is easier to have the possibility to develop these models to a certain degree, before prensenting them for public discussion. >> Third (3) this mailinglist would provide everybody with the possibility to directly address the whole Structure Development Group and fourth (4), being most important, avoid mails between group members to end in personal mail accounts, later forgotten and unavailable to the public by providing an archive of the mailinglist. >> My idea with this was to have only those wiling to participate in the group's work as members of the list but allow (moderated) input from anybody. >> Of course this would mean, an open list archive and regular reports to MEI-L on behalf of the Structure Development Group; and, of course, open discussion and (as I could imagine) surveys on MEI-L in order to grasp "waht does MEI want?" >> >> But for now I can calm everyone: nothing has been mingled on dark secluded mailinlists ;-) In fact, while making up a preliminary agenda for MEI-Struct during the past few days, a couple of mails reached me, concerning the groups work. >> From the fact that these reached me by means of personal mail accounts (not over MEI-L) tells me, that there might be an interest in forwarding ideas and fist thoughts on a personal basis first! >> >> I'd be happy to hear other opinions on the above? (Especially from contributors to the new Structure Development Group!) >> >> Now to give a short report on current status: >> I'm happy to announce that two additional community members have joined the Structure Development Group: >> David Meredith, and >> Giuliano Di Bacco >> >> Best wishes, >> Benjamin >> >> *********************************************************** >> Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" >> Benjamin Wolff Bohl >> Gartenstra?e 20 >> D-32756 Detmold >> >> Tel. +49 (0) 5231 / 975-669 >> Fax: +49 (0) 5231 / 975-668 >> E-Mail:bohl at edirom.de >> >> http://www.freischuetz-digital.de >> *********************************************************** >> >> Am 11.06.2013 17:02, schrieb Peter Stadler: >>> Just wanted to second this idea. >>> Please keep MEI-L informed and don't hide the discussion in another >>> list. (I would go so far to question the need for a separate list at >>> all ...) >>> >>> Best >>> Peter >>> >>> Am 07.06.2013 um 08:40 schrieb Benjamin Wolff Bohl: >>> >>>> Dear Eleanor, >>>> thank you very much for your good input concerning organizing the work of the group. >>>> Mailing out portions of the agenda and having surveys on MEI-L seems a very good idea! >>>> >>>> Sincerely, >>>> Benjamin >>>> >>>> *********************************************************** >>>> Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt >>>> "Freisch?tz Digital" >>>> Benjamin Wolff Bohl >>>> Gartenstra?e 20 >>>> D-32756 Detmold >>>> >>>> Tel. +49 (0) 5231 / 975-669 >>>> Fax: +49 (0) 5231 / 975-668 >>>> E-Mail:bohl at edirom.de >>>> >>>> http://www.freischuetz-digital.de >>>> *********************************************************** >>>> >>>> Am 07.06.2013 01:34, schrieb Eleanor Selfridge-Field: >>>>> Hi, Benjamin, >>>>> >>>>> You are starting out with a good steering group. Perhaps you should >>>>> mail out small parts of the agenda to a large group and see what >>>>> responses come in. Or...you could identify several topics that need >>>>> to be addressed and put them in a survey. >>>>> >>>>> I'll be happy to read what you come up with, but I doubt I will be >>>>> able to take an active part in drafting the provisions. Good luck with the task. >>>>> >>>>> Eleanor >>>>> >>>>> >>>>> Eleanor Selfridge-Field >>>>> Consulting Professor, Music (and, by courtesy, Symbolic Systems) >>>>> Braun Music Center #129 Stanford University Stanford, CA 94305-3076, >>>>> USAhttp://www.stanford.edu/~esfield/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----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 Benjamin Wolff Bohl >>>>> Sent: Thursday, June 06, 2013 9:44 AM >>>>> To:mei-l at lists.uni-paderborn.de >>>>> Subject: [MEI-L] CfP MEI Strategy Development Group >>>>> >>>>> Dear List:eners, >>>>> as mentioned before, in my personal report from the MEI Council >>>>> Meeting at Mainz, MEI has to find new structures for future >>>>> community development and participation. >>>>> Having proposed to initialize formation of this group I hereby >>>>> invite everyone to join the efforts of >>>>> >>>>>> A *Strategy Development Group* >>>>>> >>>>>> assigned to come up with proposals for a new organization of MEI. >>>>>> This group should represent the complete MEI Community, including >>>>>> delegates from peer groups that might not be involved at the >>>>>> moment. For this reason, it was proposed to use MEI-L to gather >>>>>> interested parties for this basically open group. >>>>>> For practical reasons, an initial group of volunteers was set up, >>>>>> which consists of: >>>>>> - Axel Teich Geertinger, >>>>>> - Laurent Pugin, (@Laurent: as you were proposed while shortly >>>>>> absent, is this your will?) >>>>>> - Christine Siegert, and >>>>>> - Benjamin W. Bohl. >>>>>> >>>>>> **Call for Participation** Anyone interested in joining this group >>>>>> please communicate this by replying to this message via MEI-L. >>>>>> If there are no objections I would like to volunteer for >>>>>> coordinating the formation of this group during this initial phase. >>>>>> >>>>>> The preliminary schedule for this group is to draft at least two >>>>>> proposals for future organization of the MEI Community within the >>>>>> next year; bringing these proposals to discussion both in MEI >>>>>> Council and MEI Community, for decision. >>>>>> It was agreed, that transparency and avoidance of bureaucratic >>>>>> overhead should be essential features of new structures, and >>>>>> democracy and participatory aspects should be considered likewise, >>>>>> but without neglecting efficient and simple structures. This might >>>>>> include careful reconsideration of the current structures (MEI >>>>>> Council and MEI Technical Team) that nevertheless have proved to be >>>>>> very helpful and effective fostering the interest of MEI Community >>>>>> and bringing it to ist current shape. >>>>>> It was also agreed that once new structures and forms of organizing >>>>>> MEI Community should be established, these would be examined after >>>>>> a number of years, with the option to revert or change to a >>>>>> different >>>>> model. >>>>> >>>>> If you are interested in joining this group and developing >>>>> strategies for the future of MEI, please contact me directly. A >>>>> Mailinglist for internal discussions of this group will be available >>>>> shortly and I'd be happy to send you an invitation to the list. >>>>> >>>>> >>>>> Best regards, >>>>> Benjamin >>>>> >>>>> *********************************************************** >>>>> Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt >>>>> "Freisch?tz Digital" >>>>> Benjamin Wolff Bohl >>>>> Gartenstra?e 20 >>>>> D-32756 Detmold >>>>> >>>>> Tel. +49 (0) 5231 / 975-669 >>>>> Fax: +49 (0) 5231 / 975-668 >>>>> E-Mail:bohl at edirom.de >>>>> >>>>> http://www.freischuetz-digital.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 >>>> _______________________________________________ >>>> 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 -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From kepper at edirom.de Thu Jun 13 21:13:12 2013 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 13 Jun 2013 21:13:12 +0200 Subject: [MEI-L] How to encode choices...? In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> Message-ID: <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> Dear Axel, this is an interesting problem. I'm sure there are better answers around, but here's a first take from me. is about the "same point in a text", as you pointed out. Normally, you encode the alternatives in its child elements, which are normally paired ( and , and etc.). It is absolutely possible to have a set of elements. However, when interpreting the "same point in a text" in a verbose way, seems to be the wrong choice. Your example has a set of different texts, which may be shuffled or selected randomly, but most importantly, they are different texts. Also, my understanding of the elements from the edittrans module is that they should be used to enrich encodings with additional background knowledge of the editor. Here, everything seems to be in the sources (though this is certainly arguable?). I would probably encode every card as a separate section (or even mdiv), and then use an / structure referring to these to encode a virtual "walkthrough". Given you know that eleven cards should be played, it would look like so: ? ? ? and , and etc.). It is absolutely possible to have a set of elements. However, when interpreting the "same point in a text" in a verbose way, seems to be the wrong choice. Your example has a set of different texts, which may be shuffled or selected randomly, but most importantly, they are different texts. Also, my understanding of the elements from the edittrans module is that they should be used to enrich encodings with additional background knowledge of the editor. Here, everything seems to be in the sources (though this is certainly arguable?). I would probably encode every card as a separate section (or even mdiv), and then use an / structure referring to these to encode a virtual "walkthrough". Given you know that eleven cards should be played, it would look like so: ? ? ? > For the time being and in great expectations, > Benjamin > > *********************************************************** > Musikwissenschaftliches Seminar Detmold/Paderborn > BMBF-Projekt "Freisch?tz Digital" > Benjamin Wolff Bohl > Gartenstra?e 20 > D?32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > E-Mail: bohl at edirom.de > http://www.freischuetz-digital.de > *********************************************************** > > Am 13.06.2013 14:21, schrieb Johannes Kepper: > > Axel, > > I couldn't agree more with what you said, especially about the distinction between developers and users. I think this is the opportunity to shape MEI so that it becomes more user-friendly, and to make it as accessible and open for anyone as possible. From this perspective, it's terrific that Giuliano and David have joined the group. Without knowing the exact group, I hope that others with a less-developed background in digital projects will join the group ? it seems important to get input from traditional musicologists, librarians etc. as well. > > Benni: Thanks for driving this :-) I assume you will announce the availability of this mailing list as soon as it's there, right? > > Best regards, > Johannes > > > > Am 13.06.2013 um 14:14 schrieb Axel Teich Geertinger : > > > Benni, > > I agree. I think the discussions should be open to anyone interested, but on the other hand I don't think we should flood MEI-L with our discussions. I am sure there will be a lot of mails about purely practical matters, for instance about coordinating the group's work, which will not be of interest to anyone else. I do not want to hide these mails from anyone, but I do want to avoid people leaving MEI-L because their inbox gets filled with mails addressing (primarily) a small group. It's like choosing between having a meeting in a train or in a meeting room. In the train, people are gathered because they want to get somewhere, but they are not necessarily going there for the same reason. They probably do not want to hear a group's discussions about the train company. In a meeting room, we can invite people to join the meeting if they want to; otherwise, they can just pass by. One could even ask what the point would be in appointing a structure development group if all discus > sions a > > re to take place in the community at large. But of course we must be in close contact to MEI-L too as you suggest, and the group's discussions should be accessible in an open archive. > > I'm happy to welcome Dave and Giuliano to the group! And Giuliano, no need to apalogize - I think it is most valuable also people not too deeply involved in the development so far are represented; after all, the discussions are also about how to ensure openness towards the general public, MEI users, and future MEI developers. For now, the group of MEI users may be more or less identical to the group of MEI developers. Hopefully, that is going to change in the future, and there will be far more users than people involved in the current council. In my opinion, this makes it even more important to have the existing and rather large group of people actively contributing to the development of MEI (the current council + some more) organized somehow also in the future structure of the MEI community - as an advisory board or whatever. As I see it, this group is an essential resource and driving force for MEI development, contributing with code, ideas, bug reports, guidelines, trying > out con > > cepts, spreading the word etc. Users are something different. > > Well, that's part of the discussion already. If we agree to have a separate mei-strat mailing list, please do join it if you want to participate in - or just follow - the discussions. > > Best, > Axel > > > -----Oprindelig meddelelse----- > Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de ] P? vegne af Benjamin Wolff Bohl > Sendt: 12. juni 2013 18:06 > Til: mei-l at lists.uni-paderborn.de > Emne: Re: [MEI-L] CfP MEI Strategy Development Group > > Dear Peter, > thanks for your concerns regarding a separate list for the Structure Development Group. > Of course, discussion of the Structure Development Group should be as open and transparent as possible! > > My first (1) thoughts for a separate mailinglist were that it would make it easier to keep together the discussion of the group; second (2), being appointed with the task of making up a couple of possible models for community organisation I think it is easier to have the possibility to develop these models to a certain degree, before prensenting them for public discussion. > Third (3) this mailinglist would provide everybody with the possibility to directly address the whole Structure Development Group and fourth (4), being most important, avoid mails between group members to end in personal mail accounts, later forgotten and unavailable to the public by providing an archive of the mailinglist. > My idea with this was to have only those wiling to participate in the group's work as members of the list but allow (moderated) input from anybody. > Of course this would mean, an open list archive and regular reports to MEI-L on behalf of the Structure Development Group; and, of course, open discussion and (as I could imagine) surveys on MEI-L in order to grasp "waht does MEI want?" > > But for now I can calm everyone: nothing has been mingled on dark secluded mailinlists ;-) In fact, while making up a preliminary agenda for MEI-Struct during the past few days, a couple of mails reached me, concerning the groups work. > >From the fact that these reached me by means of personal mail accounts (not over MEI-L) tells me, that there might be an interest in forwarding ideas and fist thoughts on a personal basis first! > > I'd be happy to hear other opinions on the above? (Especially from contributors to the new Structure Development Group!) > > Now to give a short report on current status: > I'm happy to announce that two additional community members have joined the Structure Development Group: > David Meredith, and > Giuliano Di Bacco > > Best wishes, > Benjamin > > *********************************************************** > Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" > Benjamin Wolff Bohl > Gartenstra?e 20 > D-32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > E-Mail: bohl at edirom.de > http://www.freischuetz-digital.de > *********************************************************** > > Am 11.06.2013 17:02, schrieb Peter Stadler: > > Just wanted to second this idea. > Please keep MEI-L informed and don't hide the discussion in another > list. (I would go so far to question the need for a separate list at > all ...) > > Best > Peter > > Am 07.06.2013 um 08:40 schrieb Benjamin Wolff Bohl : > > > Dear Eleanor, > thank you very much for your good input concerning organizing the work of the group. > Mailing out portions of the agenda and having surveys on MEI-L seems a very good idea! > > Sincerely, > Benjamin > > *********************************************************** > Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt > "Freisch?tz Digital" > Benjamin Wolff Bohl > Gartenstra?e 20 > D-32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > E-Mail: bohl at edirom.de > http://www.freischuetz-digital.de > *********************************************************** > > Am 07.06.2013 01:34, schrieb Eleanor Selfridge-Field: > > Hi, Benjamin, > > You are starting out with a good steering group. Perhaps you should > mail out small parts of the agenda to a large group and see what > responses come in. Or...you could identify several topics that need > to be addressed and put them in a survey. > > I'll be happy to read what you come up with, but I doubt I will be > able to take an active part in drafting the provisions. Good luck with the task. > > Eleanor > > > Eleanor Selfridge-Field > Consulting Professor, Music (and, by courtesy, Symbolic Systems) > Braun Music Center #129 Stanford University Stanford, CA 94305-3076, > USA http://www.stanford.edu/~esfield/ > > > > > > > > -----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 Benjamin Wolff Bohl > Sent: Thursday, June 06, 2013 9:44 AM > To: mei-l at lists.uni-paderborn.de > Subject: [MEI-L] CfP MEI Strategy Development Group > > Dear List:eners, > as mentioned before, in my personal report from the MEI Council > Meeting at Mainz, MEI has to find new structures for future > community development and participation. > Having proposed to initialize formation of this group I hereby > invite everyone to join the efforts of > > > A *Strategy Development Group* > > assigned to come up with proposals for a new organization of MEI. > This group should represent the complete MEI Community, including > delegates from peer groups that might not be involved at the > moment. For this reason, it was proposed to use MEI-L to gather > interested parties for this basically open group. > For practical reasons, an initial group of volunteers was set up, > which consists of: > - Axel Teich Geertinger, > - Laurent Pugin, (@Laurent: as you were proposed while shortly > absent, is this your will?) > - Christine Siegert, and > - Benjamin W. Bohl. > > **Call for Participation** Anyone interested in joining this group > please communicate this by replying to this message via MEI-L. > If there are no objections I would like to volunteer for > coordinating the formation of this group during this initial phase. > > The preliminary schedule for this group is to draft at least two > proposals for future organization of the MEI Community within the > next year; bringing these proposals to discussion both in MEI > Council and MEI Community, for decision. > It was agreed, that transparency and avoidance of bureaucratic > overhead should be essential features of new structures, and > democracy and participatory aspects should be considered likewise, > but without neglecting efficient and simple structures. This might > include careful reconsideration of the current structures (MEI > Council and MEI Technical Team) that nevertheless have proved to be > very helpful and effective fostering the interest of MEI Community > and bringing it to ist current shape. > It was also agreed that once new structures and forms of organizing > MEI Community should be established, these would be examined after > a number of years, with the option to revert or change to a > different > > model. > > If you are interested in joining this group and developing > strategies for the future of MEI, please contact me directly. A > Mailinglist for internal discussions of this group will be available > shortly and I'd be happy to send you an invitation to the list. > > > Best regards, > Benjamin > > *********************************************************** > Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt > "Freisch?tz Digital" > Benjamin Wolff Bohl > Gartenstra?e 20 > D-32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > E-Mail: bohl at edirom.de > http://www.freischuetz-digital.de > *********************************************************** > > > _______________________________________________ > mei-l mailing listmei-l at lists.uni-paderborn.dehttps://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing listmei-l at lists.uni-paderborn.dehttps://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing listmei-l at lists.uni-paderborn.dehttps://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing listmei-l at lists.uni-paderborn.dehttps://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing listmei-l at lists.uni-paderborn.dehttps://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing listmei-l at lists.uni-paderborn.dehttps://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing listmei-l at lists.uni-paderborn.dehttps://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 > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From slu at kb.dk Thu Jun 13 21:30:15 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Thu, 13 Jun 2013 19:30:15 +0000 Subject: [MEI-L] How to encode choices...? In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk>, Message-ID: <0C090608704AF04E898055296C932B129A43BDE6@EXCHANGE-01.kb.dk> No, not really. But when we publish stuff, there will be a text here, or a pointer or redirect. http://www.kb.dk/en/kb/nb/mta/dcm/projekter/kaleidakustikon.html You can see some of the cards there. Sigfrid ________________________________________ Fra: mei-l-bounces+slu=kb.dk at lists.uni-paderborn.de [mei-l-bounces+slu=kb.dk at lists.uni-paderborn.de] på vegne af K?m?ves Zolt?n [zolaemil at gmail.com] Sendt: 13. juni 2013 21:23 Til: Music Encoding Initiative Emne: Re: [MEI-L] How to encode choices...? Hi Axel, Your project sounds fun, and I am also interested in variant handling, do you have a blog or news feed where I could follow updates? I am also a rookie in MEI, so please someone more experienced correct me if I am talking nonsense, but my guess would be to use the element ((reading) ? Contains a single reading within a textual variation.) that may contain a complete , or even
, therefore may be suitable for the purpose. Best, Zoltan ---- Zoltan Komives GSoC Intern Maryland Institute for Technology in the Humanities http://mith.umd.edu/people/person/zoltan-komives/ http://mith.umd.edu/mei-to-vexflow/ 2013/6/13 Axel Teich Geertinger > Dear list, We are preparing a little experimental digital edition of a piece named ?Kaleidakustikon? (c.1820) by Friedrich Kuhlau. It is an aleatoric piece of music of the same kind as, for instance, Kirnberger?s ?Der allezeit fertige Menuetten- und Polonaisencomponist? and the ?Musikalisches W?rfelspiel? attributed to Mozart. It consists of 21 piles of cards, each card containing one bar of music. The player selects one of the 11 cards in each pile by throwing dice. Put together, these cards form a little waltz. The project is of course to make it an online game, at the same time giving us some experience with MEI workflows. The question is: How should we encode the multiple alternatives for each bar? The guidelines explain that the element ?groups a number of alternative encodings for the same point in a text?. Sounds perfect for this purpose. However, it only allows editorial markup elements like , , , , , , , and as child elements (BTW, the guidelines p. 163 also mention and , but not , , and ? a mistake?). How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept? Best, Axel [http://support.kb.dk/images/kb_logo.jpg] Det Kongelige Bibliotek Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder | Interim Head of Centre 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 | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 14433 bytes Desc: image001.jpg URL: From atge at kb.dk Thu Jun 13 22:59:52 2013 From: atge at kb.dk (Axel Teich Geertinger) Date: Thu, 13 Jun 2013 20:59:52 +0000 Subject: [MEI-L] How to encode choices...? In-Reply-To: <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk> Hi Johannes and Zoltan Thank you for your input. I am not completely convinced by either approaches - using multiple in , or a number of elements in . I think I need be a little more specific about the nature of the work in question. The piles of cards are labeled A to V. The composition must begin with one of the cards A2 to A12 (bar 1), followed by one of the cards B2 to B12 (bar 2) etc. This means that the cards cannot be shuffled - each card can only appear in one particular place, so each pile of cards really does represent different texts at the "same point in the text", and that is why I thought would be the right element to use, because that's what it is: a choice one has to make at that particular point in order to perform or render the piece. Using and does not sound right to me, because they are for use with the critical apparatus (which is an editorial device, as I see it). The guidelines clearly say that "An app element always encapsulates the differences between varying sources". But here, the entire set of cards is _one_ source, and the alternatives are not variant readings in the sense used in a critical apparatus. They are not about disagreement between sources, but intentionally different options and exactly equally valid. As you say, the editorial elements within come in pairs, so signals to me that there will follow a element or something of that kind providing a (slightly) different (i.e. corrected, regularized etc.) encoding of the _same_ content. The guidelines say that "Contains material which is marked as following the original, rather than being normalized or corrected." It is not obvious to me how multiple siblings within should be understood. I was just hoping to be able to put
or or the like into ; that would make sense to me in this case. I see that this may imply turning into another one of these scary elements that - like - may contain just about anything and really are open to encoding all sorts of rubbish... All the best, 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: 13. juni 2013 21:13 Til: Music Encoding Initiative Emne: Re: [MEI-L] How to encode choices...? Dear Axel, this is an interesting problem. I'm sure there are better answers around, but here's a first take from me. is about the "same point in a text", as you pointed out. Normally, you encode the alternatives in its child elements, which are normally paired ( and , and etc.). It is absolutely possible to have a set of elements. However, when interpreting the "same point in a text" in a verbose way, seems to be the wrong choice. Your example has a set of different texts, which may be shuffled or selected randomly, but most importantly, they are different texts. Also, my understanding of the elements from the edittrans module is that they should be used to enrich encodings with additional background knowledge of the editor. Here, everything seems to be in the sources (though this is certainly arguable.). I would probably encode every card as a separate section (or even mdiv), and then use an / structure referring to these to encode a virtual "walkthrough". Given you know that eleven cards should be played, it would look like so: . . . It consists of 21 piles of cards, each card containing one bar of music. The player selects one of the 11 cards in each pile by throwing dice. Put together, these cards form a little waltz. The project is of course to make it an online game, at the same time giving us some experience with MEI workflows. > > The question is: How should we encode the multiple alternatives for each bar? The guidelines explain that the element "groups a number of alternative encodings for the same point in a text". Sounds perfect for this purpose. However, it only allows editorial markup elements like , , , , , , , and as child elements (BTW, the guidelines p. 163 also mention and , but not , , and - a mistake?). > > How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept? > > Best, > Axel > > > Det Kongelige Bibliotek > Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich > Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder | > Interim Head of Centre > > 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 > | 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 Thu Jun 13 23:28:56 2013 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Thu, 13 Jun 2013 14:28:56 -0700 (PDT) Subject: [MEI-L] How to encode choices...? In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> Message-ID: <93fd634c.000010c0.00000011@CCARH-ADM-2.su.win.stanford.edu> We have a dice game online at http://www.ccarh.org/courses/253/lab/kerndice/. Each possible measure has a number. There are virtual dice in the instructions lower on the page. Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ 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: Thursday, June 13, 2013 10:19 AM To: Music Encoding Initiative Subject: [MEI-L] How to encode choices...? Dear list, We are preparing a little experimental digital edition of a piece named ?Kaleidakustikon? (c.1820) by Friedrich Kuhlau. It is an aleatoric piece of music of the same kind as, for instance, Kirnberger?s ?Der allezeit fertige Menuetten- und Polonaisencomponist? and the ?Musikalisches W?rfelspiel? attributed to Mozart. It consists of 21 piles of cards, each card containing one bar of music. The player selects one of the 11 cards in each pile by throwing dice. Put together, these cards form a little waltz. The project is of course to make it an online game, at the same time giving us some experience with MEI workflows. The question is: How should we encode the multiple alternatives for each bar? The guidelines explain that the element ?groups a number of alternative encodings for the same point in a text?. Sounds perfect for this purpose. However, it only allows editorial markup elements like , , , , , , , and as child elements (BTW, the guidelines p. 163 also mention and , but not , , and ? a mistake?). How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept? Best, Axel http://support.kb.dk/images/kb_logo.jpg Det Kongelige Bibliotek Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder | Interim Head of Centre 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 | 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 14433 bytes Desc: not available URL: From raffaeleviglianti at gmail.com Thu Jun 13 23:49:56 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 13 Jun 2013 17:49:56 -0400 Subject: [MEI-L] How to encode choices...? In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk> Message-ID: Hi Axel, This is a fascinating problem and I also think that would also be more appropriate than in this case. Though , de fact more than by definition, is used for alternatives justified by the elements that can contain, such as , , , etc. So it's more editorial than what it seems. I would argue that would be closer to what you're looking for, because these are alternatives suggested by "the text on the source". One caveat of ossia is that the alternative has to be provided within the same source, but you seem to consider the cards as being one source, so maybe this will work. If I understand correctly, the cards can be consider as part of one "score", though a score that only gets determined by chance. Nonetheless, I would group the cards in a score element and assume that they only form one "movement" or section.
In
, I would create a "measure" for each of the 11 piles. Each represents the hypothetical measure that one of the alternative contents will fill. At this point, the content of each card is expressed as a staff within . You can use @decls to point to the description of the card as physical object. If you have more than one instrument, each one will need their ossia because of the measure-wise structure of MEI. And that's it. One thing that it's not encoding is the selection criteria (the dice). But arguably, that's a performance issue and can be expressed with a somewhere. Or you can customize the verbose definition of in ODD to specify that a computer program can pick any of the alternatives at random. Another way of looking at this problem is to keep the act of "putting the pieces together" completely out of the MEI. You can take a "documentary" approach by encoding the cards as separate objects, and their relationship get expressed elsewhere, either in a script's logic or with some subject-predicate-object triple structure. Best wishes, Raffaele On Thu, Jun 13, 2013 at 4:59 PM, Axel Teich Geertinger wrote: > Hi Johannes and Zoltan > > Thank you for your input. I am not completely convinced by either > approaches - using multiple in , or a number of > elements in . I think I need be a little more specific about the > nature of the work in question. The piles of cards are labeled A to V. The > composition must begin with one of the cards A2 to A12 (bar 1), followed by > one of the cards B2 to B12 (bar 2) etc. This means that the cards cannot be > shuffled - each card can only appear in one particular place, so each pile > of cards really does represent different texts at the "same point in the > text", and that is why I thought would be the right element to > use, because that's what it is: a choice one has to make at that particular > point in order to perform or render the piece. > > Using and does not sound right to me, because they are for use > with the critical apparatus (which is an editorial device, as I see it). > The guidelines clearly say that "An app element always encapsulates the > differences between varying sources". But here, the entire set of cards is > _one_ source, and the alternatives are not variant readings in the sense > used in a critical apparatus. They are not about disagreement between > sources, but intentionally different options and exactly equally valid. > > As you say, the editorial elements within come in pairs, so > signals to me that there will follow a element or something of > that kind providing a (slightly) different (i.e. corrected, regularized > etc.) encoding of the _same_ content. The guidelines say that > "Contains material which is marked as following the original, rather than > being normalized or corrected." It is not obvious to me how multiple > siblings within should be understood. I was just hoping to be able > to put
or or the like into ; that would make > sense to me in this case. I see that this may imply turning into > another one of these scary elements that - like - may contain just > about anything and really are open to encoding all sorts of rubbish... > > All the best, > 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: 13. juni 2013 21:13 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] How to encode choices...? > > Dear Axel, > > this is an interesting problem. I'm sure there are better answers around, > but here's a first take from me. > is about the "same point in a text", as you pointed out. > Normally, you encode the alternatives in its child elements, which are > normally paired ( and , and etc.). It is > absolutely possible to have a set of elements. However, when > interpreting the "same point in a text" in a verbose way, seems to > be the wrong choice. Your example has a set of different texts, which may > be shuffled or selected randomly, but most importantly, they are different > texts. Also, my understanding of the elements from the edittrans module is > that they should be used to enrich encodings with additional background > knowledge of the editor. Here, everything seems to be in the sources > (though this is certainly arguable.). > > I would probably encode every card as a separate section (or even mdiv), > and then use an / structure referring to these to encode a > virtual "walkthrough". Given you know that eleven cards should be played, > it would look like so: > > > > . > > > . > > > . > music of the same kind as, for instance, Kirnberger's "Der allezeit fertige > Menuetten- und Polonaisencomponist" and the "Musikalisches W?rfelspiel" > attributed to Mozart. > > It consists of 21 piles of cards, each card containing one bar of music. > The player selects one of the 11 cards in each pile by throwing dice. Put > together, these cards form a little waltz. The project is of course to make > it an online game, at the same time giving us some experience with MEI > workflows. > > > > The question is: How should we encode the multiple alternatives for each > bar? The guidelines explain that the element "groups a number of > alternative encodings for the same point in a text". Sounds perfect for > this purpose. However, it only allows editorial markup elements like > , , , , , , , and as > child elements (BTW, the guidelines p. 163 also mention and , > but not , , and - a mistake?). > > > > How do we encode choices among a number of alternatives provided by the > composer as part of the compositional concept? > > > > Best, > > Axel > > > > > > Det Kongelige Bibliotek > > Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich > > Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder | > > Interim Head of Centre > > > > 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 > > | 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 > > _______________________________________________ > 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: From slu at kb.dk Fri Jun 14 08:06:37 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Fri, 14 Jun 2013 06:06:37 +0000 Subject: [MEI-L] How to encode choices...? In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk>, Message-ID: <9rpwh2ha3vda0144drluyrmf.1371188694636@email.android.com> Thanks Raffaele for this analysis. I didn't even know that there was such an element as ossia. Currently we encode the cards as sections, since there are six piles of cards that are one and a half measures long appearing at the starts and endings of repeats. Each section has an unique xml:id constructed by pile and card number. The encoding is done such that I write whole tunes each with cards with the same number. Then we have written xquery for retrieving any tune given the their coordinates (pile,card) Sigfrid Skickat fr?n Samsung Tablet Raffaele Viglianti skrev: Hi Axel, This is a fascinating problem and I also think that would also be more appropriate than in this case. Though , de fact more than by definition, is used for alternatives justified by the elements that can contain, such as , , , etc. So it's more editorial than what it seems. I would argue that would be closer to what you're looking for, because these are alternatives suggested by "the text on the source". One caveat of ossia is that the alternative has to be provided within the same source, but you seem to consider the cards as being one source, so maybe this will work. If I understand correctly, the cards can be consider as part of one "score", though a score that only gets determined by chance. Nonetheless, I would group the cards in a score element and assume that they only form one "movement" or section.
In
, I would create a "measure" for each of the 11 piles. Each represents the hypothetical measure that one of the alternative contents will fill. At this point, the content of each card is expressed as a staff within . You can use @decls to point to the description of the card as physical object. If you have more than one instrument, each one will need their ossia because of the measure-wise structure of MEI. And that's it. One thing that it's not encoding is the selection criteria (the dice). But arguably, that's a performance issue and can be expressed with a somewhere. Or you can customize the verbose definition of in ODD to specify that a computer program can pick any of the alternatives at random. Another way of looking at this problem is to keep the act of "putting the pieces together" completely out of the MEI. You can take a "documentary" approach by encoding the cards as separate objects, and their relationship get expressed elsewhere, either in a script's logic or with some subject-predicate-object triple structure. Best wishes, Raffaele On Thu, Jun 13, 2013 at 4:59 PM, Axel Teich Geertinger > wrote: Hi Johannes and Zoltan Thank you for your input. I am not completely convinced by either approaches - using multiple in , or a number of elements in . I think I need be a little more specific about the nature of the work in question. The piles of cards are labeled A to V. The composition must begin with one of the cards A2 to A12 (bar 1), followed by one of the cards B2 to B12 (bar 2) etc. This means that the cards cannot be shuffled - each card can only appear in one particular place, so each pile of cards really does represent different texts at the "same point in the text", and that is why I thought would be the right element to use, because that's what it is: a choice one has to make at that particular point in order to perform or render the piece. Using and does not sound right to me, because they are for use with the critical apparatus (which is an editorial device, as I see it). The guidelines clearly say that "An app element always encapsulates the differences between varying sources". But here, the entire set of cards is _one_ source, and the alternatives are not variant readings in the sense used in a critical apparatus. They are not about disagreement between sources, but intentionally different options and exactly equally valid. As you say, the editorial elements within come in pairs, so signals to me that there will follow a element or something of that kind providing a (slightly) different (i.e. corrected, regularized etc.) encoding of the _same_ content. The guidelines say that "Contains material which is marked as following the original, rather than being normalized or corrected." It is not obvious to me how multiple siblings within should be understood. I was just hoping to be able to put
or or the like into ; that would make sense to me in this case. I see that this may imply turning into another one of these scary elements that - like - may contain just about anything and really are open to encoding all sorts of rubbish... All the best, 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: 13. juni 2013 21:13 Til: Music Encoding Initiative Emne: Re: [MEI-L] How to encode choices...? Dear Axel, this is an interesting problem. I'm sure there are better answers around, but here's a first take from me. is about the "same point in a text", as you pointed out. Normally, you encode the alternatives in its child elements, which are normally paired ( and , and etc.). It is absolutely possible to have a set of elements. However, when interpreting the "same point in a text" in a verbose way, seems to be the wrong choice. Your example has a set of different texts, which may be shuffled or selected randomly, but most importantly, they are different texts. Also, my understanding of the elements from the edittrans module is that they should be used to enrich encodings with additional background knowledge of the editor. Here, everything seems to be in the sources (though this is certainly arguable.). I would probably encode every card as a separate section (or even mdiv), and then use an / structure referring to these to encode a virtual "walkthrough". Given you know that eleven cards should be played, it would look like so: . . . It consists of 21 piles of cards, each card containing one bar of music. The player selects one of the 11 cards in each pile by throwing dice. Put together, these cards form a little waltz. The project is of course to make it an online game, at the same time giving us some experience with MEI workflows. > > The question is: How should we encode the multiple alternatives for each bar? The guidelines explain that the element "groups a number of alternative encodings for the same point in a text". Sounds perfect for this purpose. However, it only allows editorial markup elements like , , , , , , , and as child elements (BTW, the guidelines p. 163 also mention and , but not , , and - a mistake?). > > How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept? > > Best, > Axel > > > Det Kongelige Bibliotek > Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich > Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder | > Interim Head of Centre > > 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 > | 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 _______________________________________________ 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: From bohl at edirom.de Fri Jun 14 08:52:39 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 14 Jun 2013 08:52:39 +0200 Subject: [MEI-L] How to encode choices...? In-Reply-To: <9rpwh2ha3vda0144drluyrmf.1371188694636@email.android.com> References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk>, <9rpwh2ha3vda0144drluyrmf.1371188694636@email.android.com> Message-ID: <51BABDB7.4070003@edirom.de> Hi Sigfrid, hi Axel, great that someone else thinks of how to encode combinatorial games in music ;-) I can very much understand your idea of using it would make things so straightforward, wouldn't it? And also Zoltan's idea to use seems very plausible when reading the respective element descriptions. Nevertheless as has been mentioned, these elements were for editorial additions and the like. I tried to encode Francesco Saverio's Guida Armonica and still am on overhauling it and (maybe) bringing it to MEI. And in this context I stumbled over the attributes @prev and @next their description respectively say: "points to the next/previous event(s) in a user defined collection" Although not hitting the spot absolutely, I could imagine an encoding using mdiv elements to group the stacks (A, B, &c.) and sections for the individul cards. With @prev and @next on the sections pointing to possible next sections; something like this one:
Hope that helps, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D--32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 14.06.2013 08:06, schrieb Sigfrid Lundberg: > > > Thanks Raffaele for this analysis. I didn't even know that there was > such an element as ossia. > > Currently we encode the cards as sections, since there are six piles > of cards that are one and a half measures long appearing at the starts > and endings of repeats. Each section has an unique xml:id constructed > by pile and card number. > > The encoding is done such that I write whole tunes each with cards > with the same number. > > Then we have written xquery for retrieving any tune given the their > coordinates (pile,card) > > Sigfrid > > Skickat fr?n Samsung Tablet > > Raffaele Viglianti skrev: > Hi Axel, > > This is a fascinating problem and I also think that would > also be more appropriate than in this case. Though , de > fact more than by definition, is used for alternatives justified by > the elements that can contain, such as , , , > etc. So it's more editorial than what it seems. > > I would argue that would be closer to what you're looking for, > because these are alternatives suggested by "the text on the source". > One caveat of ossia is that the alternative has to be provided within > the same source, but you seem to consider the cards as being one > source, so maybe this will work. > > If I understand correctly, the cards can be consider as part of one > "score", though a score that only gets determined by chance. > Nonetheless, I would group the cards in a score element and assume > that they only form one "movement" or section. > > > >
> >
>
> > > In
, I would create a "measure" for each of the 11 piles. > Each represents the hypothetical measure that one of the alternative > contents will fill. > > > > > > > > > > > > > At this point, the content of each card is expressed as a staff within > . You can use @decls to point to the description of the card as > physical object. > If you have more than one instrument, each one will need their ossia > because of the measure-wise structure of MEI. > > > > > > > > > > > > > > > > > > > > > > > > > > > And that's it. One thing that it's not encoding is the selection > criteria (the dice). But arguably, that's a performance issue and can > be expressed with a somewhere. Or you can customize the verbose > definition of in ODD to specify that a computer program can > pick any of the alternatives at random. > > Another way of looking at this problem is to keep the act of "putting > the pieces together" completely out of the MEI. You can take a > "documentary" approach by encoding the cards as separate objects, and > their relationship get expressed elsewhere, either in a script's logic > or with some subject-predicate-object triple structure. > > Best wishes, > Raffaele > > > On Thu, Jun 13, 2013 at 4:59 PM, Axel Teich Geertinger > wrote: > > Hi Johannes and Zoltan > > Thank you for your input. I am not completely convinced by either > approaches - using multiple in , or a number of > elements in . I think I need be a little more specific > about the nature of the work in question. The piles of cards are > labeled A to V. The composition must begin with one of the cards > A2 to A12 (bar 1), followed by one of the cards B2 to B12 (bar 2) > etc. This means that the cards cannot be shuffled - each card can > only appear in one particular place, so each pile of cards really > does represent different texts at the "same point in the text", > and that is why I thought would be the right element to > use, because that's what it is: a choice one has to make at that > particular point in order to perform or render the piece. > > Using and does not sound right to me, because they are > for use with the critical apparatus (which is an editorial device, > as I see it). The guidelines clearly say that "An app element > always encapsulates the differences between varying sources". But > here, the entire set of cards is _one_ source, and the > alternatives are not variant readings in the sense used in a > critical apparatus. They are not about disagreement between > sources, but intentionally different options and exactly equally > valid. > > As you say, the editorial elements within come in pairs, > so signals to me that there will follow a element or > something of that kind providing a (slightly) different (i.e. > corrected, regularized etc.) encoding of the _same_ content. The > guidelines say that "Contains material which is marked as > following the original, rather than being normalized or > corrected." It is not obvious to me how multiple siblings > within should be understood. I was just hoping to be able > to put
or or the like into ; that > would make sense to me in this case. I see that this may imply > turning into another one of these scary elements that - > like - may contain just about anything and really are open > to encoding all sorts of rubbish... > > All the best, > 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: 13. juni 2013 21:13 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] How to encode choices...? > > Dear Axel, > > this is an interesting problem. I'm sure there are better answers > around, but here's a first take from me. > is about the "same point in a text", as you pointed out. > Normally, you encode the alternatives in its child elements, > which are normally paired ( and , and > etc.). It is absolutely possible to have a set of elements. > However, when interpreting the "same point in a text" in a verbose > way, seems to be the wrong choice. Your example has a set > of different texts, which may be shuffled or selected randomly, > but most importantly, they are different texts. Also, my > understanding of the elements from the edittrans module is that > they should be used to enrich encodings with additional background > knowledge of the editor. Here, everything seems to be in the > sources (though this is certainly arguable.). > > I would probably encode every card as a separate section (or even > mdiv), and then use an / structure referring to these > to encode a virtual "walkthrough". Given you know that eleven > cards should be played, it would look like so: > > > > . > > > . > > > . > an aleatoric piece of music of the same kind as, for instance, > Kirnberger's "Der allezeit fertige Menuetten- und > Polonaisencomponist" and the "Musikalisches W?rfelspiel" > attributed to Mozart. > > It consists of 21 piles of cards, each card containing one bar > of music. The player selects one of the 11 cards in each pile by > throwing dice. Put together, these cards form a little waltz. The > project is of course to make it an online game, at the same time > giving us some experience with MEI workflows. > > > > The question is: How should we encode the multiple alternatives > for each bar? The guidelines explain that the element > "groups a number of alternative encodings for the same point in a > text". Sounds perfect for this purpose. However, it only allows > editorial markup elements like , , , , > , , , and as child elements (BTW, > the guidelines p. 163 also mention and , but not > , , and - a mistake?). > > > > How do we encode choices among a number of alternatives provided > by the composer as part of the compositional concept? > > > > Best, > > Axel > > > > > > Det Kongelige Bibliotek > > Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich > > Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret > centerleder | > > Interim Head of Centre > > > > 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 > > > | 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 > > _______________________________________________ > 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 HTML-Daten wurde abgetrennt... URL: From atge at kb.dk Fri Jun 14 10:00:42 2013 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 14 Jun 2013 08:00:42 +0000 Subject: [MEI-L] How to encode choices...? In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AA0@EXCHANGE-01.kb.dk> Raffaele, Thanks a lot. Ossia may indeed be the key to the solution, in principle at least. However, since is a child of (or ), I cannot apply it at a higher level including 1) more than one measure and 2) more than one staff. The problem with your solution to the latter problem is that cannot contain (or
, which probably would be most useful here). Benjamin, I was happy to learn about your interest in these dice games at the conference in Mainz too. Your solution using
for the alternatives and @next/@prev to navigate through the piece surely works, only it does not really describe the compositional idea of these concepts, does it? I was hoping to find a solution explicitly marking the points of choice as such as well as the options in each case. I am attaching two of the cards (a2 and b2) for your information. As Sigge mentioned, some of them include an upbeat or (at the section ends) the two beats of the next bar ? that?s why we need something above level. Best, Axel Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Raffaele Viglianti Sendt: 13. juni 2013 23:50 Til: Music Encoding Initiative Emne: Re: [MEI-L] How to encode choices...? Hi Axel, This is a fascinating problem and I also think that would also be more appropriate than in this case. Though , de fact more than by definition, is used for alternatives justified by the elements that can contain, such as , , , etc. So it's more editorial than what it seems. I would argue that would be closer to what you're looking for, because these are alternatives suggested by "the text on the source". One caveat of ossia is that the alternative has to be provided within the same source, but you seem to consider the cards as being one source, so maybe this will work. If I understand correctly, the cards can be consider as part of one "score", though a score that only gets determined by chance. Nonetheless, I would group the cards in a score element and assume that they only form one "movement" or section.
In
, I would create a "measure" for each of the 11 piles. Each represents the hypothetical measure that one of the alternative contents will fill. At this point, the content of each card is expressed as a staff within . You can use @decls to point to the description of the card as physical object. If you have more than one instrument, each one will need their ossia because of the measure-wise structure of MEI. And that's it. One thing that it's not encoding is the selection criteria (the dice). But arguably, that's a performance issue and can be expressed with a somewhere. Or you can customize the verbose definition of in ODD to specify that a computer program can pick any of the alternatives at random. Another way of looking at this problem is to keep the act of "putting the pieces together" completely out of the MEI. You can take a "documentary" approach by encoding the cards as separate objects, and their relationship get expressed elsewhere, either in a script's logic or with some subject-predicate-object triple structure. Best wishes, Raffaele On Thu, Jun 13, 2013 at 4:59 PM, Axel Teich Geertinger > wrote: Hi Johannes and Zoltan Thank you for your input. I am not completely convinced by either approaches - using multiple in , or a number of elements in . I think I need be a little more specific about the nature of the work in question. The piles of cards are labeled A to V. The composition must begin with one of the cards A2 to A12 (bar 1), followed by one of the cards B2 to B12 (bar 2) etc. This means that the cards cannot be shuffled - each card can only appear in one particular place, so each pile of cards really does represent different texts at the "same point in the text", and that is why I thought would be the right element to use, because that's what it is: a choice one has to make at that particular point in order to perform or render the piece. Using and does not sound right to me, because they are for use with the critical apparatus (which is an editorial device, as I see it). The guidelines clearly say that "An app element always encapsulates the differences between varying sources". But here, the entire set of cards is _one_ source, and the alternatives are not variant readings in the sense used in a critical apparatus. They are not about disagreement between sources, but intentionally different options and exactly equally valid. As you say, the editorial elements within come in pairs, so signals to me that there will follow a element or something of that kind providing a (slightly) different (i.e. corrected, regularized etc.) encoding of the _same_ content. The guidelines say that "Contains material which is marked as following the original, rather than being normalized or corrected." It is not obvious to me how multiple siblings within should be understood. I was just hoping to be able to put
or or the like into ; that would make sense to me in this case. I see that this may imply turning into another one of these scary elements that - like - may contain just about anything and really are open to encoding all sorts of rubbish... All the best, 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: 13. juni 2013 21:13 Til: Music Encoding Initiative Emne: Re: [MEI-L] How to encode choices...? Dear Axel, this is an interesting problem. I'm sure there are better answers around, but here's a first take from me. is about the "same point in a text", as you pointed out. Normally, you encode the alternatives in its child elements, which are normally paired ( and , and etc.). It is absolutely possible to have a set of elements. However, when interpreting the "same point in a text" in a verbose way, seems to be the wrong choice. Your example has a set of different texts, which may be shuffled or selected randomly, but most importantly, they are different texts. Also, my understanding of the elements from the edittrans module is that they should be used to enrich encodings with additional background knowledge of the editor. Here, everything seems to be in the sources (though this is certainly arguable.). I would probably encode every card as a separate section (or even mdiv), and then use an / structure referring to these to encode a virtual "walkthrough". Given you know that eleven cards should be played, it would look like so: . . . It consists of 21 piles of cards, each card containing one bar of music. The player selects one of the 11 cards in each pile by throwing dice. Put together, these cards form a little waltz. The project is of course to make it an online game, at the same time giving us some experience with MEI workflows. > > The question is: How should we encode the multiple alternatives for each bar? The guidelines explain that the element "groups a number of alternative encodings for the same point in a text". Sounds perfect for this purpose. However, it only allows editorial markup elements like , , , , , , , and as child elements (BTW, the guidelines p. 163 also mention and , but not , , and - a mistake?). > > How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept? > > Best, > Axel > > > Det Kongelige Bibliotek > Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich > Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder | > Interim Head of Centre > > 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 > | 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 _______________________________________________ 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: From atge at kb.dk Fri Jun 14 11:38:00 2013 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 14 Jun 2013 09:38:00 +0000 Subject: [MEI-L] Now with attachments... In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AA0@EXCHANGE-01.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AA0@EXCHANGE-01.kb.dk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AFC@EXCHANGE-01.kb.dk> Right, I forgot the attachments. Here they are. /axel Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Axel Teich Geertinger Sendt: 14. juni 2013 10:01 Til: Music Encoding Initiative Emne: Re: [MEI-L] How to encode choices...? Raffaele, Thanks a lot. Ossia may indeed be the key to the solution, in principle at least. However, since is a child of (or ), I cannot apply it at a higher level including 1) more than one measure and 2) more than one staff. The problem with your solution to the latter problem is that cannot contain (or
, which probably would be most useful here). Benjamin, I was happy to learn about your interest in these dice games at the conference in Mainz too. Your solution using
for the alternatives and @next/@prev to navigate through the piece surely works, only it does not really describe the compositional idea of these concepts, does it? I was hoping to find a solution explicitly marking the points of choice as such as well as the options in each case. I am attaching two of the cards (a2 and b2) for your information. As Sigge mentioned, some of them include an upbeat or (at the section ends) the two beats of the next bar ? that?s why we need something above level. Best, Axel Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Raffaele Viglianti Sendt: 13. juni 2013 23:50 Til: Music Encoding Initiative Emne: Re: [MEI-L] How to encode choices...? Hi Axel, This is a fascinating problem and I also think that would also be more appropriate than in this case. Though , de fact more than by definition, is used for alternatives justified by the elements that can contain, such as , , , etc. So it's more editorial than what it seems. I would argue that would be closer to what you're looking for, because these are alternatives suggested by "the text on the source". One caveat of ossia is that the alternative has to be provided within the same source, but you seem to consider the cards as being one source, so maybe this will work. If I understand correctly, the cards can be consider as part of one "score", though a score that only gets determined by chance. Nonetheless, I would group the cards in a score element and assume that they only form one "movement" or section.
In
, I would create a "measure" for each of the 11 piles. Each represents the hypothetical measure that one of the alternative contents will fill. At this point, the content of each card is expressed as a staff within . You can use @decls to point to the description of the card as physical object. If you have more than one instrument, each one will need their ossia because of the measure-wise structure of MEI. And that's it. One thing that it's not encoding is the selection criteria (the dice). But arguably, that's a performance issue and can be expressed with a somewhere. Or you can customize the verbose definition of in ODD to specify that a computer program can pick any of the alternatives at random. Another way of looking at this problem is to keep the act of "putting the pieces together" completely out of the MEI. You can take a "documentary" approach by encoding the cards as separate objects, and their relationship get expressed elsewhere, either in a script's logic or with some subject-predicate-object triple structure. Best wishes, Raffaele On Thu, Jun 13, 2013 at 4:59 PM, Axel Teich Geertinger > wrote: Hi Johannes and Zoltan Thank you for your input. I am not completely convinced by either approaches - using multiple in , or a number of elements in . I think I need be a little more specific about the nature of the work in question. The piles of cards are labeled A to V. The composition must begin with one of the cards A2 to A12 (bar 1), followed by one of the cards B2 to B12 (bar 2) etc. This means that the cards cannot be shuffled - each card can only appear in one particular place, so each pile of cards really does represent different texts at the "same point in the text", and that is why I thought would be the right element to use, because that's what it is: a choice one has to make at that particular point in order to perform or render the piece. Using and does not sound right to me, because they are for use with the critical apparatus (which is an editorial device, as I see it). The guidelines clearly say that "An app element always encapsulates the differences between varying sources". But here, the entire set of cards is _one_ source, and the alternatives are not variant readings in the sense used in a critical apparatus. They are not about disagreement between sources, but intentionally different options and exactly equally valid. As you say, the editorial elements within come in pairs, so signals to me that there will follow a element or something of that kind providing a (slightly) different (i.e. corrected, regularized etc.) encoding of the _same_ content. The guidelines say that "Contains material which is marked as following the original, rather than being normalized or corrected." It is not obvious to me how multiple siblings within should be understood. I was just hoping to be able to put
or or the like into ; that would make sense to me in this case. I see that this may imply turning into another one of these scary elements that - like - may contain just about anything and really are open to encoding all sorts of rubbish... All the best, 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: 13. juni 2013 21:13 Til: Music Encoding Initiative Emne: Re: [MEI-L] How to encode choices...? Dear Axel, this is an interesting problem. I'm sure there are better answers around, but here's a first take from me. is about the "same point in a text", as you pointed out. Normally, you encode the alternatives in its child elements, which are normally paired ( and , and etc.). It is absolutely possible to have a set of elements. However, when interpreting the "same point in a text" in a verbose way, seems to be the wrong choice. Your example has a set of different texts, which may be shuffled or selected randomly, but most importantly, they are different texts. Also, my understanding of the elements from the edittrans module is that they should be used to enrich encodings with additional background knowledge of the editor. Here, everything seems to be in the sources (though this is certainly arguable.). I would probably encode every card as a separate section (or even mdiv), and then use an / structure referring to these to encode a virtual "walkthrough". Given you know that eleven cards should be played, it would look like so: . . . It consists of 21 piles of cards, each card containing one bar of music. The player selects one of the 11 cards in each pile by throwing dice. Put together, these cards form a little waltz. The project is of course to make it an online game, at the same time giving us some experience with MEI workflows. > > The question is: How should we encode the multiple alternatives for each bar? The guidelines explain that the element "groups a number of alternative encodings for the same point in a text". Sounds perfect for this purpose. However, it only allows editorial markup elements like , , , , , , , and as child elements (BTW, the guidelines p. 163 also mention and , but not , , and - a mistake?). > > How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept? > > Best, > Axel > > > Det Kongelige Bibliotek > Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich > Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder | > Interim Head of Centre > > 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 > | 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 _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: a_02.jpg Type: image/jpeg Size: 50986 bytes Desc: a_02.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: b_02.jpg Type: image/jpeg Size: 46905 bytes Desc: b_02.jpg URL: From kepper at edirom.de Fri Jun 14 12:07:25 2013 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 14 Jun 2013 12:07:25 +0200 Subject: [MEI-L] Now with attachments... In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AFC@EXCHANGE-01.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AA0@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AFC@EXCHANGE-01.kb.dk> Message-ID: Hi all, I see the argument for , and maybe extending it to allow its appearance further up in the tree is the way to go, but I wonder if there is an explanation available on the card deck. In other words: Would someone not familiar with the background recognize the purpose of the cards just by looking at them? Is the "processing" really a part of the music that you transcribe, or is this algorithmic logic better addressed elsewhere? This seems to be a specific case of musical rules, to be applied on a strictly defined corpus (the cards?). I'm not sure if MEI is the right format to address these rules adequately. This answer is clearly not satisfactory, as there is no such format yet (Benni?), but Raffaele's pointer to RDF seems reasonable for a quick solution. Another possibility, if you prefer to have everything in XML (though RDF can be expressed in XML as well), would be to include a snippet of XSLT somewhere in the header. I'm not suggesting that you actually use this XSLT for processing the files, but for documenting the algorithm. Well, there are many ways of driving oneself insane when modelling music? Best, Johannes Am 14.06.2013 um 11:38 schrieb Axel Teich Geertinger: > Right, I forgot the attachments. Here they are. > > /axel > > Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Axel Teich Geertinger > Sendt: 14. juni 2013 10:01 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] How to encode choices...? > > Raffaele, > > Thanks a lot. Ossia may indeed be the key to the solution, in principle at least. However, since is a child of (or ), I cannot apply it at a higher level including 1) more than one measure and 2) more than one staff. > The problem with your solution to the latter problem is that cannot contain (or
, which probably would be most useful here). > > Benjamin, I was happy to learn about your interest in these dice games at the conference in Mainz too. Your solution using
for the alternatives and @next/@prev to navigate through the piece surely works, only it does not really describe the compositional idea of these concepts, does it? I was hoping to find a solution explicitly marking the points of choice as such as well as the options in each case. > > I am attaching two of the cards (a2 and b2) for your information. As Sigge mentioned, some of them include an upbeat or (at the section ends) the two beats of the next bar ? that?s why we need something above level. > > Best, > Axel > > > > Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Raffaele Viglianti > Sendt: 13. juni 2013 23:50 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] How to encode choices...? > > Hi Axel, > > This is a fascinating problem and I also think that would also be more appropriate than in this case. Though , de fact more than by definition, is used for alternatives justified by the elements that can contain, such as , , , etc. So it's more editorial than what it seems. > > I would argue that would be closer to what you're looking for, because these are alternatives suggested by "the text on the source". One caveat of ossia is that the alternative has to be provided within the same source, but you seem to consider the cards as being one source, so maybe this will work. > > If I understand correctly, the cards can be consider as part of one "score", though a score that only gets determined by chance. Nonetheless, I would group the cards in a score element and assume that they only form one "movement" or section. > > > >
> >
>
> > > In
, I would create a "measure" for each of the 11 piles. Each represents the hypothetical measure that one of the alternative contents will fill. > > > > > > > > > > > > > At this point, the content of each card is expressed as a staff within . You can use @decls to point to the description of the card as physical object. > If you have more than one instrument, each one will need their ossia because of the measure-wise structure of MEI. > > > > > > > > > > > > > > > > > > > > > > > > > > > And that's it. One thing that it's not encoding is the selection criteria (the dice). But arguably, that's a performance issue and can be expressed with a somewhere. Or you can customize the verbose definition of in ODD to specify that a computer program can pick any of the alternatives at random. > > Another way of looking at this problem is to keep the act of "putting the pieces together" completely out of the MEI. You can take a "documentary" approach by encoding the cards as separate objects, and their relationship get expressed elsewhere, either in a script's logic or with some subject-predicate-object triple structure. > > Best wishes, > Raffaele > > > On Thu, Jun 13, 2013 at 4:59 PM, Axel Teich Geertinger wrote: > Hi Johannes and Zoltan > > Thank you for your input. I am not completely convinced by either approaches - using multiple in , or a number of elements in . I think I need be a little more specific about the nature of the work in question. The piles of cards are labeled A to V. The composition must begin with one of the cards A2 to A12 (bar 1), followed by one of the cards B2 to B12 (bar 2) etc. This means that the cards cannot be shuffled - each card can only appear in one particular place, so each pile of cards really does represent different texts at the "same point in the text", and that is why I thought would be the right element to use, because that's what it is: a choice one has to make at that particular point in order to perform or render the piece. > > Using and does not sound right to me, because they are for use with the critical apparatus (which is an editorial device, as I see it). The guidelines clearly say that "An app element always encapsulates the differences between varying sources". But here, the entire set of cards is _one_ source, and the alternatives are not variant readings in the sense used in a critical apparatus. They are not about disagreement between sources, but intentionally different options and exactly equally valid. > > As you say, the editorial elements within come in pairs, so signals to me that there will follow a element or something of that kind providing a (slightly) different (i.e. corrected, regularized etc.) encoding of the _same_ content. The guidelines say that "Contains material which is marked as following the original, rather than being normalized or corrected." It is not obvious to me how multiple siblings within should be understood. I was just hoping to be able to put
or or the like into ; that would make sense to me in this case. I see that this may imply turning into another one of these scary elements that - like - may contain just about anything and really are open to encoding all sorts of rubbish... > > All the best, > 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: 13. juni 2013 21:13 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] How to encode choices...? > > Dear Axel, > > this is an interesting problem. I'm sure there are better answers around, but here's a first take from me. > is about the "same point in a text", as you pointed out. Normally, you encode the alternatives in its child elements, which are normally paired ( and , and etc.). It is absolutely possible to have a set of elements. However, when interpreting the "same point in a text" in a verbose way, seems to be the wrong choice. Your example has a set of different texts, which may be shuffled or selected randomly, but most importantly, they are different texts. Also, my understanding of the elements from the edittrans module is that they should be used to enrich encodings with additional background knowledge of the editor. Here, everything seems to be in the sources (though this is certainly arguable.). > > I would probably encode every card as a separate section (or even mdiv), and then use an / structure referring to these to encode a virtual "walkthrough". Given you know that eleven cards should be played, it would look like so: > > > > . > > > . > > > . > > It consists of 21 piles of cards, each card containing one bar of music. The player selects one of the 11 cards in each pile by throwing dice. Put together, these cards form a little waltz. The project is of course to make it an online game, at the same time giving us some experience with MEI workflows. > > > > The question is: How should we encode the multiple alternatives for each bar? The guidelines explain that the element "groups a number of alternative encodings for the same point in a text". Sounds perfect for this purpose. However, it only allows editorial markup elements like , , , , , , , and as child elements (BTW, the guidelines p. 163 also mention and , but not , , and - a mistake?). > > > > How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept? > > > > Best, > > Axel > > > > > > Det Kongelige Bibliotek > > Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich > > Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder | > > Interim Head of Centre > > > > 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 > > | 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 > > _______________________________________________ > 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 Fri Jun 14 13:10:38 2013 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 14 Jun 2013 11:10:38 +0000 Subject: [MEI-L] Choice In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AA0@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AFC@EXCHANGE-01.kb.dk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D19A3B7B91@EXCHANGE-01.kb.dk> Yes, perhaps it is too much to expect from an encoding system like MEI. In this particular case, there is no written explanation with the cards, but I am quite sure there has been one. Our copy is not complete: The lid of the box as well as 8 cards from the H pile are missing, which is the only one we have been able to locate (if anyone knows of another copy please let us know!!). The answer to your question, whether one would be able to understand the concept without an explanation, would certainly be yes (unless we have misunderstood it, obviously...). So for now, let us assume these rules are part of the composition. The encoding of a compositional concept that goes beyond the mere notation may indeed be outside the scope of MEI. I just thought it would be nifty to describe within in a single MEI encoding not only the contents of the cards, but also the way they are organized (i.e. which options there are at each point in the piece). The actual selection of one particular path through the material is something different, or rather a next step. Your choice of cards equals an editorial decision and could very well be recorded using /, as I see it. Technically there are many ways of handling the logic, of course. As Sigge explained, he has encoded each of the layers (the first one being a2, b2, c2, d2... etc.) in a separate file, so we have 11 files, each containing a complete waltz. On request, the programmed logic selects the first measure from one of the files, appends the next measure from another one (or the same) etc. No problem. But to me, the interesting question here is whether MEI is or should be capable of semantically encoding a source of this kind. Best, 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: 14. juni 2013 12:07 Til: Music Encoding Initiative Emne: Re: [MEI-L] Now with attachments... Hi all, I see the argument for , and maybe extending it to allow its appearance further up in the tree is the way to go, but I wonder if there is an explanation available on the card deck. In other words: Would someone not familiar with the background recognize the purpose of the cards just by looking at them? Is the "processing" really a part of the music that you transcribe, or is this algorithmic logic better addressed elsewhere? This seems to be a specific case of musical rules, to be applied on a strictly defined corpus (the cards.). I'm not sure if MEI is the right format to address these rules adequately. This answer is clearly not satisfactory, as there is no such format yet (Benni?), but Raffaele's pointer to RDF seems reasonable for a quick solution. Another possibility, if you prefer to have everything in XML (though RDF can be expressed in XML as well), would be to include a snippet of XSLT somewhere in the header. I'm not suggesting that you actually use this XSLT for processing the files, but for documenting the algorithm. Well, there are many ways of driving oneself insane when modelling music. Best, Johannes Am 14.06.2013 um 11:38 schrieb Axel Teich Geertinger: > Right, I forgot the attachments. Here they are. > > /axel > > Fra: mei-l-bounces at lists.uni-paderborn.de > [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Axel Teich > Geertinger > Sendt: 14. juni 2013 10:01 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] How to encode choices...? > > Raffaele, > > Thanks a lot. Ossia may indeed be the key to the solution, in principle at least. However, since is a child of (or ), I cannot apply it at a higher level including 1) more than one measure and 2) more than one staff. > The problem with your solution to the latter problem is that cannot contain (or
, which probably would be most useful here). > > Benjamin, I was happy to learn about your interest in these dice games at the conference in Mainz too. Your solution using
for the alternatives and @next/@prev to navigate through the piece surely works, only it does not really describe the compositional idea of these concepts, does it? I was hoping to find a solution explicitly marking the points of choice as such as well as the options in each case. > > I am attaching two of the cards (a2 and b2) for your information. As Sigge mentioned, some of them include an upbeat or (at the section ends) the two beats of the next bar - that's why we need something above level. > > Best, > Axel > > > > Fra: mei-l-bounces at lists.uni-paderborn.de > [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Raffaele > Viglianti > Sendt: 13. juni 2013 23:50 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] How to encode choices...? > > Hi Axel, > > This is a fascinating problem and I also think that would also be more appropriate than in this case. Though , de fact more than by definition, is used for alternatives justified by the elements that can contain, such as , , , etc. So it's more editorial than what it seems. > > I would argue that would be closer to what you're looking for, because these are alternatives suggested by "the text on the source". One caveat of ossia is that the alternative has to be provided within the same source, but you seem to consider the cards as being one source, so maybe this will work. > > If I understand correctly, the cards can be consider as part of one "score", though a score that only gets determined by chance. Nonetheless, I would group the cards in a score element and assume that they only form one "movement" or section. > > > >
> >
>
> > > In
, I would create a "measure" for each of the 11 piles. Each represents the hypothetical measure that one of the alternative contents will fill. > > > > > > > > > > > > > At this point, the content of each card is expressed as a staff within . You can use @decls to point to the description of the card as physical object. > If you have more than one instrument, each one will need their ossia because of the measure-wise structure of MEI. > > > > > > > > > > > > > > > > > > > > > > > > > > > And that's it. One thing that it's not encoding is the selection criteria (the dice). But arguably, that's a performance issue and can be expressed with a somewhere. Or you can customize the verbose definition of in ODD to specify that a computer program can pick any of the alternatives at random. > > Another way of looking at this problem is to keep the act of "putting the pieces together" completely out of the MEI. You can take a "documentary" approach by encoding the cards as separate objects, and their relationship get expressed elsewhere, either in a script's logic or with some subject-predicate-object triple structure. > > Best wishes, > Raffaele > > > On Thu, Jun 13, 2013 at 4:59 PM, Axel Teich Geertinger wrote: > Hi Johannes and Zoltan > > Thank you for your input. I am not completely convinced by either approaches - using multiple in , or a number of elements in . I think I need be a little more specific about the nature of the work in question. The piles of cards are labeled A to V. The composition must begin with one of the cards A2 to A12 (bar 1), followed by one of the cards B2 to B12 (bar 2) etc. This means that the cards cannot be shuffled - each card can only appear in one particular place, so each pile of cards really does represent different texts at the "same point in the text", and that is why I thought would be the right element to use, because that's what it is: a choice one has to make at that particular point in order to perform or render the piece. > > Using and does not sound right to me, because they are for use with the critical apparatus (which is an editorial device, as I see it). The guidelines clearly say that "An app element always encapsulates the differences between varying sources". But here, the entire set of cards is _one_ source, and the alternatives are not variant readings in the sense used in a critical apparatus. They are not about disagreement between sources, but intentionally different options and exactly equally valid. > > As you say, the editorial elements within come in pairs, so signals to me that there will follow a element or something of that kind providing a (slightly) different (i.e. corrected, regularized etc.) encoding of the _same_ content. The guidelines say that "Contains material which is marked as following the original, rather than being normalized or corrected." It is not obvious to me how multiple siblings within should be understood. I was just hoping to be able to put
or or the like into ; that would make sense to me in this case. I see that this may imply turning into another one of these scary elements that - like - may contain just about anything and really are open to encoding all sorts of rubbish... > > All the best, > 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: 13. juni 2013 21:13 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] How to encode choices...? > > Dear Axel, > > this is an interesting problem. I'm sure there are better answers around, but here's a first take from me. > is about the "same point in a text", as you pointed out. Normally, you encode the alternatives in its child elements, which are normally paired ( and , and etc.). It is absolutely possible to have a set of elements. However, when interpreting the "same point in a text" in a verbose way, seems to be the wrong choice. Your example has a set of different texts, which may be shuffled or selected randomly, but most importantly, they are different texts. Also, my understanding of the elements from the edittrans module is that they should be used to enrich encodings with additional background knowledge of the editor. Here, everything seems to be in the sources (though this is certainly arguable.). > > I would probably encode every card as a separate section (or even mdiv), and then use an / structure referring to these to encode a virtual "walkthrough". Given you know that eleven cards should be played, it would look like so: > > > > . > > > . > > > . > > It consists of 21 piles of cards, each card containing one bar of music. The player selects one of the 11 cards in each pile by throwing dice. Put together, these cards form a little waltz. The project is of course to make it an online game, at the same time giving us some experience with MEI workflows. > > > > The question is: How should we encode the multiple alternatives for each bar? The guidelines explain that the element "groups a number of alternative encodings for the same point in a text". Sounds perfect for this purpose. However, it only allows editorial markup elements like , , , , , , , and as child elements (BTW, the guidelines p. 163 also mention and , but not , , and - a mistake?). > > > > How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept? > > > > Best, > > Axel > > > > > > Det Kongelige Bibliotek > > Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich > > Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder > > | Interim Head of Centre > > > > 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 > > | 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 > > _______________________________________________ > 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 14 13:54:09 2013 From: zupftom at googlemail.com (TW) Date: Fri, 14 Jun 2013 13:54:09 +0200 Subject: [MEI-L] Now with attachments... In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AA0@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AFC@EXCHANGE-01.kb.dk> Message-ID: 2013/6/14 Johannes Kepper : > Well, there are many ways of driving oneself insane when modelling music? > I think I'll hang this on my wall[1]! Thomas [1] http://docs.google.com/file/d/0Byfv7jFulQoFQlYtbklaMzNTdDQ/edit From kepper at edirom.de Fri Jun 14 13:57:08 2013 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 14 Jun 2013 13:57:08 +0200 Subject: [MEI-L] Now with attachments... In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AA0@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AFC@EXCHANGE-01.kb.dk> Message-ID: <815F5C83-9BCF-4C15-B5EF-49DDDF14D488@edirom.de> +1 ;-) Am 14.06.2013 um 13:54 schrieb TW : > 2013/6/14 Johannes Kepper : >> Well, there are many ways of driving oneself insane when modelling music? >> > > I think I'll hang this on my wall[1]! > > Thomas > > > [1] http://docs.google.com/file/d/0Byfv7jFulQoFQlYtbklaMzNTdDQ/edit > > _______________________________________________ > 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 Fri Jun 14 14:10:05 2013 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 14 Jun 2013 14:10:05 +0200 Subject: [MEI-L] Choice In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D19A3B7B91@EXCHANGE-01.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D19A3B769A@EXCHANGE-01.kb.dk> <9C1A3659-9B00-40E7-92DA-3AC731B37439@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D19A3B788E@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AA0@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7AFC@EXCHANGE-01.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D19A3B7B91@EXCHANGE-01.kb.dk> Message-ID: You're absolutely right that MEI should offer a way of expressing things like this, especially since aleatoric pieces are not unheard of in traditional cmn repertoire (your examples are a good start here). Another element that comes to my mind is , which is normally used to describe how (potentially repeated) sections should be resolved for a performance. What it offers is the traditional ABACA scheme. Right now it uses the anyURIs data type, and maybe XPointer offers something that could be used to grasp the logic, roughly in the way of a regular expression. I'm not sufficiently familiar with XPointer / XPath to say it's not possible, especially with the newer versions (XPath3.0, anyone?), but maybe we should investigate this direction. I think it's already good when we agree that all solutions within MEI we came up so far have been somewhat "creative"? Now we have to see if we can come up with a more appropriate solution, and how this would fit into MEI. The only thing I would like to make sure here is that the solution should be clearly separable from the encoding of the musical text given on each of these cards. It should be possible to encode them without knowing the rules (how many cards to be drawn from which deck, in which order etc.). We're getting there, sooner or later we're getting there? jo Am 14.06.2013 um 13:10 schrieb Axel Teich Geertinger : > Yes, perhaps it is too much to expect from an encoding system like MEI. > > In this particular case, there is no written explanation with the cards, but I am quite sure there has been one. Our copy is not complete: The lid of the box as well as 8 cards from the H pile are missing, which is the only one we have been able to locate (if anyone knows of another copy please let us know!!). The answer to your question, whether one would be able to understand the concept without an explanation, would certainly be yes (unless we have misunderstood it, obviously...). So for now, let us assume these rules are part of the composition. > The encoding of a compositional concept that goes beyond the mere notation may indeed be outside the scope of MEI. I just thought it would be nifty to describe within in a single MEI encoding not only the contents of the cards, but also the way they are organized (i.e. which options there are at each point in the piece). > > The actual selection of one particular path through the material is something different, or rather a next step. Your choice of cards equals an editorial decision and could very well be recorded using /, as I see it. > Technically there are many ways of handling the logic, of course. As Sigge explained, he has encoded each of the layers (the first one being a2, b2, c2, d2... etc.) in a separate file, so we have 11 files, each containing a complete waltz. On request, the programmed logic selects the first measure from one of the files, appends the next measure from another one (or the same) etc. No problem. > > But to me, the interesting question here is whether MEI is or should be capable of semantically encoding a source of this kind. > > Best, > 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: 14. juni 2013 12:07 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] Now with attachments... > > Hi all, > > I see the argument for , and maybe extending it to allow its appearance further up in the tree is the way to go, but I wonder if there is an explanation available on the card deck. In other words: Would someone not familiar with the background recognize the purpose of the cards just by looking at them? Is the "processing" really a part of the music that you transcribe, or is this algorithmic logic better addressed elsewhere? This seems to be a specific case of musical rules, to be applied on a strictly defined corpus (the cards.). I'm not sure if MEI is the right format to address these rules adequately. This answer is clearly not satisfactory, as there is no such format yet (Benni?), but Raffaele's pointer to RDF seems reasonable for a quick solution. Another possibility, if you prefer to have everything in XML (though RDF can be expressed in XML as well), would be to include a snippet of XSLT somewhere in the header. I'm not suggesting that you actually use this XSLT for processing the files, but for documenting the algorithm. Well, there are many ways of driving oneself insane when modelling music. > > > Best, > Johannes > > > > Am 14.06.2013 um 11:38 schrieb Axel Teich Geertinger: > >> Right, I forgot the attachments. Here they are. >> >> /axel >> >> Fra: mei-l-bounces at lists.uni-paderborn.de >> [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Axel Teich >> Geertinger >> Sendt: 14. juni 2013 10:01 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] How to encode choices...? >> >> Raffaele, >> >> Thanks a lot. Ossia may indeed be the key to the solution, in principle at least. However, since is a child of (or ), I cannot apply it at a higher level including 1) more than one measure and 2) more than one staff. >> The problem with your solution to the latter problem is that cannot contain (or
, which probably would be most useful here). >> >> Benjamin, I was happy to learn about your interest in these dice games at the conference in Mainz too. Your solution using
for the alternatives and @next/@prev to navigate through the piece surely works, only it does not really describe the compositional idea of these concepts, does it? I was hoping to find a solution explicitly marking the points of choice as such as well as the options in each case. >> >> I am attaching two of the cards (a2 and b2) for your information. As Sigge mentioned, some of them include an upbeat or (at the section ends) the two beats of the next bar - that's why we need something above level. >> >> Best, >> Axel >> >> >> >> Fra: mei-l-bounces at lists.uni-paderborn.de >> [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Raffaele >> Viglianti >> Sendt: 13. juni 2013 23:50 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] How to encode choices...? >> >> Hi Axel, >> >> This is a fascinating problem and I also think that would also be more appropriate than in this case. Though , de fact more than by definition, is used for alternatives justified by the elements that can contain, such as , , , etc. So it's more editorial than what it seems. >> >> I would argue that would be closer to what you're looking for, because these are alternatives suggested by "the text on the source". One caveat of ossia is that the alternative has to be provided within the same source, but you seem to consider the cards as being one source, so maybe this will work. >> >> If I understand correctly, the cards can be consider as part of one "score", though a score that only gets determined by chance. Nonetheless, I would group the cards in a score element and assume that they only form one "movement" or section. >> >> >> >>
>> >>
>>
>> >> >> In
, I would create a "measure" for each of the 11 piles. Each represents the hypothetical measure that one of the alternative contents will fill. >> >> >> >> >> >> >> >> >> >> >> >> >> At this point, the content of each card is expressed as a staff within . You can use @decls to point to the description of the card as physical object. >> If you have more than one instrument, each one will need their ossia because of the measure-wise structure of MEI. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> And that's it. One thing that it's not encoding is the selection criteria (the dice). But arguably, that's a performance issue and can be expressed with a somewhere. Or you can customize the verbose definition of in ODD to specify that a computer program can pick any of the alternatives at random. >> >> Another way of looking at this problem is to keep the act of "putting the pieces together" completely out of the MEI. You can take a "documentary" approach by encoding the cards as separate objects, and their relationship get expressed elsewhere, either in a script's logic or with some subject-predicate-object triple structure. >> >> Best wishes, >> Raffaele >> >> >> On Thu, Jun 13, 2013 at 4:59 PM, Axel Teich Geertinger wrote: >> Hi Johannes and Zoltan >> >> Thank you for your input. I am not completely convinced by either approaches - using multiple in , or a number of elements in . I think I need be a little more specific about the nature of the work in question. The piles of cards are labeled A to V. The composition must begin with one of the cards A2 to A12 (bar 1), followed by one of the cards B2 to B12 (bar 2) etc. This means that the cards cannot be shuffled - each card can only appear in one particular place, so each pile of cards really does represent different texts at the "same point in the text", and that is why I thought would be the right element to use, because that's what it is: a choice one has to make at that particular point in order to perform or render the piece. >> >> Using and does not sound right to me, because they are for use with the critical apparatus (which is an editorial device, as I see it). The guidelines clearly say that "An app element always encapsulates the differences between varying sources". But here, the entire set of cards is _one_ source, and the alternatives are not variant readings in the sense used in a critical apparatus. They are not about disagreement between sources, but intentionally different options and exactly equally valid. >> >> As you say, the editorial elements within come in pairs, so signals to me that there will follow a element or something of that kind providing a (slightly) different (i.e. corrected, regularized etc.) encoding of the _same_ content. The guidelines say that "Contains material which is marked as following the original, rather than being normalized or corrected." It is not obvious to me how multiple siblings within should be understood. I was just hoping to be able to put
or or the like into ; that would make sense to me in this case. I see that this may imply turning into another one of these scary elements that - like - may contain just about anything and really are open to encoding all sorts of rubbish... >> >> All the best, >> 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: 13. juni 2013 21:13 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] How to encode choices...? >> >> Dear Axel, >> >> this is an interesting problem. I'm sure there are better answers around, but here's a first take from me. >> is about the "same point in a text", as you pointed out. Normally, you encode the alternatives in its child elements, which are normally paired ( and , and etc.). It is absolutely possible to have a set of elements. However, when interpreting the "same point in a text" in a verbose way, seems to be the wrong choice. Your example has a set of different texts, which may be shuffled or selected randomly, but most importantly, they are different texts. Also, my understanding of the elements from the edittrans module is that they should be used to enrich encodings with additional background knowledge of the editor. Here, everything seems to be in the sources (though this is certainly arguable.). >> >> I would probably encode every card as a separate section (or even mdiv), and then use an / structure referring to these to encode a virtual "walkthrough". Given you know that eleven cards should be played, it would look like so: >> >> >> >> . >> >> >> . >> >> >> . >> >> It consists of 21 piles of cards, each card containing one bar of music. The player selects one of the 11 cards in each pile by throwing dice. Put together, these cards form a little waltz. The project is of course to make it an online game, at the same time giving us some experience with MEI workflows. >>> >>> The question is: How should we encode the multiple alternatives for each bar? The guidelines explain that the element "groups a number of alternative encodings for the same point in a text". Sounds perfect for this purpose. However, it only allows editorial markup elements like , , , , , , , and as child elements (BTW, the guidelines p. 163 also mention and , but not , , and - a mistake?). >>> >>> How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept? >>> >>> Best, >>> Axel >>> >>> >>> Det Kongelige Bibliotek >>> Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich >>> Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder >>> | Interim Head of Centre >>> >>> 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 >>> | 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 >> >> _______________________________________________ >> 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 mwalter at haverford.edu Tue Jun 18 23:31:30 2013 From: mwalter at haverford.edu (Micah Walter) Date: Tue, 18 Jun 2013 17:31:30 -0400 Subject: [MEI-L] Encoding ligature and coloration brackets Message-ID: <5DBA059A-C13A-4D1C-AD10-86A94E9A169E@haverford.edu> Hello, folks, I?m working on the Du Chemin project with Richard Freedman at Haverford College. For those who don?t know about the project, it involves making modern editions of some 391 Renaissance chansons, which we will be encoding in MEI. Based on database searches, excerpts from these songs will be dynamically displayed in a web browser. Although we are encoding the modern edition of the piece, as opposed to the original mensural notation, we are attempting to make our scholarly editions (and hence our encodings) as transparent as possible to the original notation. As a result, our engraved editions make use of two bracket symbols, at least one of which is fairly common in the transcription of mensural music. [Follow the links for example images.] A solid bracket indicates notes that were joined by a ligature in the source A broken bracket indicates notes that were colored in the source; that is, their mensural values are indicated in part by their coloration I haven?t found any place in the Guidelines that describes what kind of elements might be used for these, whether specific or generic. A spanning element similar to is probably what is needed; is there a generic ?grouping? element? Note that the Guidelines say that ?[t]he element should *not* be used for brackets in modern notation that indicate notes that were part of a ligature in the original source? , and I assume that the @coloration attribute should similarly not be misused. Does anyone have any ideas about encoding these symbols? Micah Walter Haverford College -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Wed Jun 19 16:50:44 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 19 Jun 2013 14:50:44 +0000 Subject: [MEI-L] Encoding ligature and coloration brackets In-Reply-To: <5DBA059A-C13A-4D1C-AD10-86A94E9A169E@haverford.edu> References: <5DBA059A-C13A-4D1C-AD10-86A94E9A169E@haverford.edu> Message-ID: Hi, Micah, The generic grouping element in MEI is . The name may be a bit of a misnomer, but the presumption is that if you're creating a group of some sort, then you want to say something about it. There are several approaches one can take to your question about brackets: 1) Use the @startid, @endid, and @plist attributes to identify the targets of the annotation (the affected notes, that is) and the @type attribute to classify the two kinds of annotation (ligature and coloration in the original source) and then draw the appropriate brackets in the rendering phase. 2) "Draw" the brackets needed using , using @type to classify the lines. Because the brackets will consist of multiple elements, however, using @type isn't optimal. The more round-about, but better option is to use to group and classify the elements. 3) Use to define the brackets you need, then use to place the brackets relative to the notes. This part of the MEI schema has not been exercised much, so I anticipate you'll find it to be inadequate regarding the placement of the symbol with respect to different sets of notes. What's lacking is a way to "parameterize" and ; in other words, the ability to use the same symbol definition in different contexts. However, I'm not discouraging you from this path -- in fact, it would be very helpful if you tried this out and reported on how well it worked. That would provide an opportunity to improve MEI. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zupftom at googlemail.com Wed Jun 19 19:50:48 2013 From: zupftom at googlemail.com (TW) Date: Wed, 19 Jun 2013 19:50:48 +0200 Subject: [MEI-L] Encoding ligature and coloration brackets In-Reply-To: References: <5DBA059A-C13A-4D1C-AD10-86A94E9A169E@haverford.edu> Message-ID: In my eyes, the choice between , and or depends on two things: Whether and how you generate the graphics from the encoded MEI and what is the "philosophy" of your encoding. I understand that your encoding process is also a transcription process of mensural notation into CMN. It appears that you therefore need the CMN structures and can not use the mensural module. Given that, I see that you can move between two encoding "extremes": Either making an encoding that aims at describing the graphical elements which should be put on the page when visualizing, or an encoding that does not yet focus too much on presentation but is meant to capture what the original notation "means in modern terms", capturing additional information that is worth carrying over--but can not be represented in CMN--in abstract, meaningful structures. In my eyes, the latter approach makes more sense. It is, so to say, more flexible, as the first approach already decides rather precisely how to visualize the music, while the latter is more content-oriented and leaves open how to visualize non-CMN features. Who knows, there might be other wishes for visualization in the future. But from a pragmatic point of view, the best solution might be the one that that makes your life easiest when producing the brackets while generating the graphics--if you do this from the MEI data. Are you using the data for rendering, and if so, what does the process look like? Thomas From mwalter at haverford.edu Wed Jun 19 20:32:28 2013 From: mwalter at haverford.edu (Micah Walter) Date: Wed, 19 Jun 2013 14:32:28 -0400 Subject: [MEI-L] Encoding ligature and coloration brackets In-Reply-To: References: <5DBA059A-C13A-4D1C-AD10-86A94E9A169E@haverford.edu> Message-ID: <97806E5A-72BE-42F1-8F91-13F6C339F7DA@haverford.edu> To me, it always makes more sense to use semantically meaningful markup. You are right about our goals in encoding as accurate (and abstract) a form of the CMN as we can. We're rendering on the fly from MEI using VexFlow . I'll see if I can try using to describe the content of the music, but as you suggested, we might reach a point where we just need the brackets printed, by hook or by crook?we'll see. I suppose it would also be possible to *both* draw brackets explicitly *and* encode content using ?this might be an eventual compromise. Thanks for the suggestions, Micah On 19 June 2013, at 13:50, TW wrote: > In my eyes, the choice between , and or > depends on two things: Whether and how you generate the > graphics from the encoded MEI and what is the "philosophy" of your > encoding. > > I understand that your encoding process is also a transcription > process of mensural notation into CMN. It appears that you therefore > need the CMN structures and can not use the mensural module. Given > that, I see that you can move between two encoding "extremes": Either > making an encoding that aims at describing the graphical elements > which should be put on the page when visualizing, or an encoding that > does not yet focus too much on presentation but is meant to capture > what the original notation "means in modern terms", capturing > additional information that is worth carrying over--but can not be > represented in CMN--in abstract, meaningful structures. > > In my eyes, the latter approach makes more sense. It is, so to say, > more flexible, as the first approach already decides rather precisely > how to visualize the music, while the latter is more content-oriented > and leaves open how to visualize non-CMN features. Who knows, there > might be other wishes for visualization in the future. > > But from a pragmatic point of view, the best solution might be the one > that that makes your life easiest when producing the brackets while > generating the graphics--if you do this from the MEI data. Are you > using the data for rendering, and if so, what does the process look > like? > > Thomas > > _______________________________________________ > 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 Jun 19 22:15:21 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 19 Jun 2013 22:15:21 +0200 Subject: [MEI-L] Encoding ligature and coloration brackets In-Reply-To: <97806E5A-72BE-42F1-8F91-13F6C339F7DA@haverford.edu> References: <5DBA059A-C13A-4D1C-AD10-86A94E9A169E@haverford.edu> <97806E5A-72BE-42F1-8F91-13F6C339F7DA@haverford.edu> Message-ID: <70913B68-0D37-4B5B-BA83-43C8BF8C9F7D@edirom.de> Hi Micah, In an ideal world, I would recommend to encode both the mensural notation and its transcription to cmn, and connect the two of them as closely as possible / reasonable. However, I suspect that your world is equally non-ideal as mine, so you may not have the resources to do that. Under these circumstances, Perry's first suggestion seems most appropriate to me ? the bracket is a sort of graphical annotation to the musical text. It has a very specific meaning, and a very specific rendering. What I would do now is to define a schema for this kind of annotation, based on the element. This would (probably) result in a set of schematron files, that make sure that all have a @subtype, which is either "solid" or "broken". They must appear only where other control events are allowed, that is inside a , but nowhere else (let's put editorial markup aside for a moment). These s should also be forced to indicate their range by @startid and @endid (or @tstamp and @tstamp2, if you prefer). Other markup inside should be suppressed. This would give you a very specific element, that may not appear in other places in your markup and interfere with other kinds of s. Based on the experience you have with it, and if other people request the same kind of element, it could serve as incubator for a new specific element (in contrast to a specific profile for a generic element like ). In the end, this kind of bracket is not super-unusual? What this doesn't solve is the way of drawing the bracket with Vexflow. However, if you use in this specific way, it should be possible to include some rules in the translation that generate your lines from the . The concept is not that different from a hairpin, for instance, where one element is converted into a set of lines that relate to some specified notes. I wouldn't recommend to include additional elements in the encoding itself. I suspect more problems than it solves (changes on one element would have to be reflected to the other etc.). Hope this helps, jo Am 19.06.2013 um 20:32 schrieb Micah Walter: > To me, it always makes more sense to use semantically meaningful markup. You are right about our goals in encoding as accurate (and abstract) a form of the CMN as we can. We're rendering on the fly from MEI using VexFlow . I'll see if I can try using to describe the content of the music, but as you suggested, we might reach a point where we just need the brackets printed, by hook or by crook?we'll see. > > I suppose it would also be possible to *both* draw brackets explicitly *and* encode content using ?this might be an eventual compromise. > > Thanks for the suggestions, > Micah > > > On 19 June 2013, at 13:50, TW wrote: > >> In my eyes, the choice between , and or >> depends on two things: Whether and how you generate the >> graphics from the encoded MEI and what is the "philosophy" of your >> encoding. >> >> I understand that your encoding process is also a transcription >> process of mensural notation into CMN. It appears that you therefore >> need the CMN structures and can not use the mensural module. Given >> that, I see that you can move between two encoding "extremes": Either >> making an encoding that aims at describing the graphical elements >> which should be put on the page when visualizing, or an encoding that >> does not yet focus too much on presentation but is meant to capture >> what the original notation "means in modern terms", capturing >> additional information that is worth carrying over--but can not be >> represented in CMN--in abstract, meaningful structures. >> >> In my eyes, the latter approach makes more sense. It is, so to say, >> more flexible, as the first approach already decides rather precisely >> how to visualize the music, while the latter is more content-oriented >> and leaves open how to visualize non-CMN features. Who knows, there >> might be other wishes for visualization in the future. >> >> But from a pragmatic point of view, the best solution might be the one >> that that makes your life easiest when producing the brackets while >> generating the graphics--if you do this from the MEI data. Are you >> using the data for rendering, and if so, what does the process look >> like? >> >> 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 mwalter at haverford.edu Wed Jun 19 22:29:49 2013 From: mwalter at haverford.edu (Micah Walter) Date: Wed, 19 Jun 2013 16:29:49 -0400 Subject: [MEI-L] Encoding ligature and coloration brackets In-Reply-To: <70913B68-0D37-4B5B-BA83-43C8BF8C9F7D@edirom.de> References: <5DBA059A-C13A-4D1C-AD10-86A94E9A169E@haverford.edu> <97806E5A-72BE-42F1-8F91-13F6C339F7DA@haverford.edu> <70913B68-0D37-4B5B-BA83-43C8BF8C9F7D@edirom.de> Message-ID: This makes complete sense! Thanks for the specific recommendations. I would, of course, like to encode the mensural notation as well, but unfortunately that is beyond the scope of our resources at the moment. -Micah On 19 June 2013, at 16:15, Johannes Kepper wrote: > Hi Micah, > > In an ideal world, I would recommend to encode both the mensural notation and its transcription to cmn, and connect the two of them as closely as possible / reasonable. However, I suspect that your world is equally non-ideal as mine, so you may not have the resources to do that. Under these circumstances, Perry's first suggestion seems most appropriate to me ? the bracket is a sort of graphical annotation to the musical text. It has a very specific meaning, and a very specific rendering. What I would do now is to define a schema for this kind of annotation, based on the element. This would (probably) result in a set of schematron files, that make sure that all have a @subtype, which is either "solid" or "broken". They must appear only where other control events are allowed, that is inside a , but nowhere else (let's put editorial markup aside for a moment). These s should also be forced to indicate their range by @startid and @endid (or @tstamp and @tstamp2, if you prefer). Other markup inside should be suppressed. This would give you a very specific element, that may not appear in other places in your markup and interfere with other kinds of s. Based on the experience you have with it, and if other people request the same kind of element, it could serve as incubator for a new specific element (in contrast to a specific profile for a generic element like ). In the end, this kind of bracket is not super-unusual? > > What this doesn't solve is the way of drawing the bracket with Vexflow. However, if you use in this specific way, it should be possible to include some rules in the translation that generate your lines from the . The concept is not that different from a hairpin, for instance, where one element is converted into a set of lines that relate to some specified notes. I wouldn't recommend to include additional elements in the encoding itself. I suspect more problems than it solves (changes on one element would have to be reflected to the other etc.). > > Hope this helps, > jo > > > > > > > > > Am 19.06.2013 um 20:32 schrieb Micah Walter: > >> To me, it always makes more sense to use semantically meaningful markup. You are right about our goals in encoding as accurate (and abstract) a form of the CMN as we can. We're rendering on the fly from MEI using VexFlow . I'll see if I can try using to describe the content of the music, but as you suggested, we might reach a point where we just need the brackets printed, by hook or by crook?we'll see. >> >> I suppose it would also be possible to *both* draw brackets explicitly *and* encode content using ?this might be an eventual compromise. >> >> Thanks for the suggestions, >> Micah >> >> >> On 19 June 2013, at 13:50, TW wrote: >> >>> In my eyes, the choice between , and or >>> depends on two things: Whether and how you generate the >>> graphics from the encoded MEI and what is the "philosophy" of your >>> encoding. >>> >>> I understand that your encoding process is also a transcription >>> process of mensural notation into CMN. It appears that you therefore >>> need the CMN structures and can not use the mensural module. Given >>> that, I see that you can move between two encoding "extremes": Either >>> making an encoding that aims at describing the graphical elements >>> which should be put on the page when visualizing, or an encoding that >>> does not yet focus too much on presentation but is meant to capture >>> what the original notation "means in modern terms", capturing >>> additional information that is worth carrying over--but can not be >>> represented in CMN--in abstract, meaningful structures. >>> >>> In my eyes, the latter approach makes more sense. It is, so to say, >>> more flexible, as the first approach already decides rather precisely >>> how to visualize the music, while the latter is more content-oriented >>> and leaves open how to visualize non-CMN features. Who knows, there >>> might be other wishes for visualization in the future. >>> >>> But from a pragmatic point of view, the best solution might be the one >>> that that makes your life easiest when producing the brackets while >>> generating the graphics--if you do this from the MEI data. Are you >>> using the data for rendering, and if so, what does the process look >>> like? >>> >>> 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 From andrew.hankinson at gmail.com Wed Jun 19 22:57:34 2013 From: andrew.hankinson at gmail.com (Andrew Hankinson) Date: Wed, 19 Jun 2013 16:57:34 -0400 Subject: [MEI-L] MEI Customization Webapp Message-ID: <69FEB076-A5F0-48D8-8FCD-2893A1594402@gmail.com> Hi, I noticed that the customization service web app (custom.music-encoding.org) is still a release behind (MEI 2012). If someone has a moment, could this please be updated to MEI 2013 (or the code posted somewhere so that someone can submit a patch to update it?) Perhaps we could still offer MEI 2012 as an option for download as well as the latest release. Thanks! -Andrew From kepper at edirom.de Wed Jun 19 23:01:00 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 19 Jun 2013 23:01:00 +0200 Subject: [MEI-L] MEI Customization Webapp In-Reply-To: <69FEB076-A5F0-48D8-8FCD-2893A1594402@gmail.com> References: <69FEB076-A5F0-48D8-8FCD-2893A1594402@gmail.com> Message-ID: Hi Andrew, Daniel can say more about the service, but as a temporary workaround, you could just canonicalize on your own and submit that as local source file? Best, Johannes Am 19.06.2013 um 22:57 schrieb Andrew Hankinson : > Hi, > > I noticed that the customization service web app (custom.music-encoding.org) is still a release behind (MEI 2012). If someone has a moment, could this please be updated to MEI 2013 (or the code posted somewhere so that someone can submit a patch to update it?) > > Perhaps we could still offer MEI 2012 as an option for download as well as the latest release. > > Thanks! > -Andrew > _______________________________________________ > 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 21 09:34:57 2013 From: roewenstrunk at edirom.de (=?windows-1252?Q?Daniel_R=F6wenstrunk?=) Date: Fri, 21 Jun 2013 09:34:57 +0200 Subject: [MEI-L] MEI Customization Webapp In-Reply-To: References: <69FEB076-A5F0-48D8-8FCD-2893A1594402@gmail.com> Message-ID: Hi all, The customization service is up to date, again. Sorry for the delay. I kept the option for the MEI 2012 release as Andrew suggested. Cheers, Daniel Am 19.06.2013 um 23:01 schrieb Johannes Kepper : > Hi Andrew, > > Daniel can say more about the service, but as a temporary workaround, you could just canonicalize on your own and submit that as local source file? > > Best, > Johannes > > Am 19.06.2013 um 22:57 schrieb Andrew Hankinson : > >> Hi, >> >> I noticed that the customization service web app (custom.music-encoding.org) is still a release behind (MEI 2012). If someone has a moment, could this please be updated to MEI 2013 (or the code posted somewhere so that someone can submit a patch to update it?) >> >> Perhaps we could still offer MEI 2012 as an option for download as well as the latest release. >> >> 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 mwalter at haverford.edu Fri Jun 21 20:06:25 2013 From: mwalter at haverford.edu (Micah Walter) Date: Fri, 21 Jun 2013 14:06:25 -0400 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? Message-ID: Hello, all, My latest question relevant to encoding modern editions of Renaissance music deals with editorial accidentals, as in the case of musica ficta. Such an accidental is conventionally placed above the single note it affects (see attachment). Possibly the option that best makes use of the intent of MEI's elements would be to use the tag, containing the single element. Or maybe would work as well. Another solution might be to encode the editorial meaning of such an accidental using the tag; while seems to work for the original reading, the best tag for the editorial reading is unclear. ? Has anyone dealt with this issue before? Thanks, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2013-06-21 at 10.56.05 .png Type: image/png Size: 10616 bytes Desc: not available URL: From gdibacco at indiana.edu Fri Jun 21 21:21:28 2013 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Fri, 21 Jun 2013 15:21:28 -0400 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: References: Message-ID: <51C4A7B8.1010809@indiana.edu> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 10616 bytes Desc: not available URL: From kepper at edirom.de Fri Jun 21 22:58:55 2013 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 21 Jun 2013 22:58:55 +0200 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: <51C4A7B8.1010809@indiana.edu> References: <51C4A7B8.1010809@indiana.edu> Message-ID: <22C30E84-6EB3-4D85-9955-F40D9ED8D8CF@edirom.de> Hi Guiliano and Micah, @accid.ges is frequently used to make an accidental specified by the key signature explicit for individual notes. In F-maj, you wouldn't use @accid="f" on every b, but adding @accid.ges="f" for every b makes processing much easier. @accid.ges denotes an accidental that is audible, but not visible. However, the absence of the attribute doesn't mean that the b should be played as natural in F-maj. So in most cases, it is just a convenience, but the attribute can be very handy when it comes to specifying the range of written accidentals, which doesn't necessarily end at the barline in certain repertoires. Regarding the original question, there are more valid answers. My first take would be to keep it as simple as possible. Obviously, the @accid attribute doesn't allow any additional markup to specify it's function. The next best solution is to use the child of . Besides an @accid attribute, it also has @func (allowed values: 'edit' or 'caution') and @place. Your example could be encoded like so: Of course, you could provide an @accid.ges on the note, if this helps your workflow. Editorial markup like (with a pair of and ) or (maybe more appropriate) is equally possible, but not necessarily required for your purpose (as far as I understand). Since your encoding reflects a translation into a different notational system anyway, I think it's not necessary to make the music ficta even more special than in the solution suggested above. Hope this helps, Johannes Am 21.06.2013 um 21:21 schrieb Giuliano Di Bacco : > > Hello, > and thanks to Micah for asking this question. I am also interested in how to approach this issue. > At the moment I am not working on specific examples but just browsing the guidelines (I take it that we are not talking about rendering the position of the accident above the note but the meaning of it = markup) and was wondering whether the @accid.ges attribute (att.accidental.performed) could handle this. > Guidelines: "records the performed pitch inflection when it differs from the written accidental". It seems that it can be an attribute of . So, what if a note has no written accidental, but an accidental needs to be performed? Here we are not dealing with an editorial amendment proper () but we are to make explicit what is implicit in how the music works (or what the editor believes the original notation means). I thought that @accid.ges may be a possible alternative to (which otherwise I would be inclined to use). > If I am wrong as I suspect ("ges" stands for "gestural"), could somebody please spend a few words on the intended use of accid.ges? > > Thanks & cheers > Giuliano > > -- > Giuliano Di Bacco > Director, Center for the History of Music Theory and Literature > Indiana University Jacobs School of Music > Bloomington, IN 47405 - USA - www.chmtl.indiana.edu > Project Director, Thesaurus Musicarum Latinarum > > > Micah Walter wrote on 21/06/2013 14:06: >> Hello, all, >> >> My latest question relevant to encoding modern editions of Renaissance music deals with editorial accidentals, as in the case of musica ficta. Such an accidental is conventionally placed above the single note it affects (see attachment). >> >> Possibly the option that best makes use of the intent of MEI's elements would be to use the tag, containing the single element. Or maybe would work as well. Another solution might be to encode the editorial meaning of such an accidental using the tag; while seems to work for the original reading, the best tag for the editorial reading is unclear. ? >> >> Has anyone dealt with this issue before? >> >> Thanks, >> Micah >> >> >> >> >> _______________________________________________ >> 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 Jun 21 23:06:11 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Fri, 21 Jun 2013 17:06:11 -0400 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: <22C30E84-6EB3-4D85-9955-F40D9ED8D8CF@edirom.de> References: <51C4A7B8.1010809@indiana.edu> <22C30E84-6EB3-4D85-9955-F40D9ED8D8CF@edirom.de> Message-ID: Hello, What about: Raffaele On Fri, Jun 21, 2013 at 4:58 PM, Johannes Kepper wrote: > Hi Guiliano and Micah, > > @accid.ges is frequently used to make an accidental specified by the key > signature explicit for individual notes. In F-maj, you wouldn't use > @accid="f" on every b, but adding @accid.ges="f" for every b makes > processing much easier. @accid.ges denotes an accidental that is audible, > but not visible. However, the absence of the attribute doesn't mean that > the b should be played as natural in F-maj. So in most cases, it is just a > convenience, but the attribute can be very handy when it comes to > specifying the range of written accidentals, which doesn't necessarily end > at the barline in certain repertoires. > > Regarding the original question, there are more valid answers. My first > take would be to keep it as simple as possible. Obviously, the @accid > attribute doesn't allow any additional markup to specify it's function. The > next best solution is to use the child of . Besides an @accid > attribute, it also has @func (allowed values: 'edit' or 'caution') and > @place. Your example could be encoded like so: > > > > > > Of course, you could provide an @accid.ges on the note, if this helps your > workflow. Editorial markup like (with a pair of and ) > or (maybe more appropriate) is equally possible, but not > necessarily required for your purpose (as far as I understand). Since your > encoding reflects a translation into a different notational system anyway, > I think it's not necessary to make the music ficta even more special than > in the solution suggested above. > > Hope this helps, > Johannes > > > Am 21.06.2013 um 21:21 schrieb Giuliano Di Bacco : > > > > > Hello, > > and thanks to Micah for asking this question. I am also interested in > how to approach this issue. > > At the moment I am not working on specific examples but just > browsing the guidelines (I take it that we are not talking about rendering > the position of the accident above the note but the meaning of it = markup) > and was wondering whether the @accid.ges attribute > (att.accidental.performed) could handle this. > > Guidelines: "records the performed pitch inflection when it differs > from the written accidental". It seems that it can be an attribute of > . So, what if a note has no written accidental, but an accidental > needs to be performed? Here we are not dealing with an editorial amendment > proper () but we are to make explicit what is implicit in how the > music works (or what the editor believes the original notation means). I > thought that @accid.ges may be a possible alternative to (which > otherwise I would be inclined to use). > > If I am wrong as I suspect ("ges" stands for "gestural"), could > somebody please spend a few words on the intended use of accid.ges? > > > > Thanks & cheers > > Giuliano > > > > -- > > Giuliano Di Bacco > > Director, Center for the History of Music Theory and Literature > > Indiana University Jacobs School of Music > > Bloomington, IN 47405 - USA - www.chmtl.indiana.edu > > Project Director, Thesaurus Musicarum Latinarum > > > > > > Micah Walter wrote on 21/06/2013 14:06: > >> Hello, all, > >> > >> My latest question relevant to encoding modern editions of Renaissance > music deals with editorial accidentals, as in the case of musica ficta. > Such an accidental is conventionally placed above the single note it > affects (see attachment). > >> > >> Possibly the option that best makes use of the intent of MEI's elements > would be to use the tag, containing the single element. Or > maybe would work as well. Another solution might be to encode > the editorial meaning of such an accidental using the tag; while > seems to work for the original reading, the best tag for the > editorial reading is unclear. ? > >> > >> Has anyone dealt with this issue before? > >> > >> Thanks, > >> Micah > >> > >> > >> > >> > >> _______________________________________________ > >> 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: From craigsapp at gmail.com Fri Jun 21 23:37:08 2013 From: craigsapp at gmail.com (Craig Sapp) Date: Fri, 21 Jun 2013 14:37:08 -0700 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: <51C4A7B8.1010809@indiana.edu> References: <51C4A7B8.1010809@indiana.edu> Message-ID: Hi Everyone, Thanks Johannes, I added editorial accidental translations to my Humdrum to MEI converter. For example this piece has 118 editorial accidentals: http://jrp.ccarh.org/cgi-bin/jrp?a=notationwithficta&f=Jos2107-O_admirabile_commercium The MEI data now has the editorial accidentals marked: http://jrp.ccarh.org/cgi-bin/jrp?a=mei&f=Jos2107-O_admirabile_commercium Such as measure 10 in the second part: I didn't use @place="above" as that is pretty much the default for editorial accidentals and I'll leave it up to any renderer to decide otherwise. Here is the original data before conversion to MEI: http://jrp.ccarh.org/cgi-bin/jrp?a=humdrum&f=Jos2107-O_admirabile_commercium which has the the above musical extract being originally written in Humdrum as: 2f\] 4e-i\ 4d\ 2e-i\ 2d\ where "i" is a user-signifier which is defined later on in the file with the line: !!!RDF**kern: i=editorial accidental -=+Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From craigsapp at gmail.com Fri Jun 21 23:52:34 2013 From: craigsapp at gmail.com (Craig Sapp) Date: Fri, 21 Jun 2013 14:52:34 -0700 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: References: <51C4A7B8.1010809@indiana.edu> <22C30E84-6EB3-4D85-9955-F40D9ED8D8CF@edirom.de> Message-ID: Hi Raffaele, On Fri, Jun 21, 2013 at 2:06 PM, Raffaele Viglianti < raffaeleviglianti at gmail.com> wrote: > > > > I wouldn't mind, but crazy purists would complain that if you use this to indicate an editorial B-flat, then it is semantically incorrect since B-flat is technically not a musica ficta note. So it is in general better to think of them as editorial accidentals used to chromatically inflect notes for performance, which usually happen to move the notes onto musica ficta pitches. -=+Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.komives at gmail.com Sat Jun 22 14:38:57 2013 From: zoltan.komives at gmail.com (Zoltan Komives) Date: Sat, 22 Jun 2013 13:38:57 +0100 Subject: [MEI-L] [mei-devel] Attribute default values In-Reply-To: <99A8EF15-B395-4327-A3D0-CE97FB390EFA@mail.mcgill.ca> References: <7232_1371832961_51C48280_7232_408_1_CAOwwund2O0Rj_0N4ZwUgW74XdXnzFvb3tfGowdTamSUFxhVxmA@mail.gmail.com> <99A8EF15-B395-4327-A3D0-CE97FB390EFA@mail.mcgill.ca> Message-ID: Hi Andrew, Thanks for your reply! Maybe it's not actually inconsistent, but here is an example that's puzzling at first glance (from Altenburg_concerto_C_major.xml ): It seems it assumes @barthru=true as default since it only uses barthru explicitly when the value is "false" - however, it wouldn't make much sense to have @barthru true in the outer staff group and false in the inner staff group; and the accompanying .pdfproves that the editor surely didn't mean to indicated that. >Do you mean that it should be specified in the guidelines whether the absence of >@barthru means true or false by default? Yes, that's what I meant, please see my answer re Thomas Weber's reply in the following email! Zoltan P.S.: following Andrew's suggestion I am moving this discussion from mei-devel to MEI-L 2013/6/21 Andrew Hankinson > Hi Zoltan, > > Could you give an example of how the @barthru attribute is inconsistently > used? Do you mean that it should be specified in the guidelines whether the > absence of @barthru means true or false by default? I think it's safe to > assume that the absence of it is an implicit false value. > > Also, perhaps this discussion can be moved to the MEI-L mailing list? > > -Andrew > > On 2013-06-21, at 12:42 PM, Zoltan Komives > wrote: > > Hi All, > > I am working on MEItoVexFlow , > a javascript library that renders music encoded in MEI onto HTML5 canvas. > We will have to decide upon the default behaviour for certains attributes > in case they are not present. > > We are going to define a customization for our particular application, but > it raises the question whether there are some attributes that would benefit > from a default value set by the guidelines. > > In particular, we've come across the @barthru attribute (*"indicates > whether bar lines go across the space between staves (true) or are only > drawn across the lines of each staff (false)."*). Its use is highly > inconsistent across the sample encodings, and we think that maybe for this > particular attribute we would gain more in consistency than the loss in > flexibility. > > Please let me know what you think. > > Best wishes, > Zoltan > > > -- > > Zoltan Komives > GSoC Intern > Maryland Institute for Technology in the Humanities > http://mith.umd.edu/people/person/zoltan-komives/ > zoltan.komives at gmail.com > > _______________________________________________ > mei-devel mailing list > mei-devel at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-devel > > > > _______________________________________________ > mei-devel mailing list > mei-devel at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.komives at gmail.com Sat Jun 22 14:41:58 2013 From: zoltan.komives at gmail.com (Zoltan Komives) Date: Sat, 22 Jun 2013 13:41:58 +0100 Subject: [MEI-L] [mei-devel] Attribute default values In-Reply-To: <51C4B32D.1070700@web.de> References: <51C4B32D.1070700@web.de> Message-ID: Hi Thomas, Thanks for your reply! I am very new to MEI, and your answer helps me a lot to understand some of the MEI principles! I understand that the option for "no information is provided" is a basic MEI principle to achieve maximum flexibility. >That said, assuming default values for attributes like @barthru would sort of force projects to set this >attribute because leaving it out would have implications that were not intended. I see, e.g. by we want to mean neither "bar lines crossing across all the staves", nor "bar lines do not cross any of the staves". Following the "no information principle" it simply means nothing about bar lines. However, in some cases an assumption of a default value can be implied by the presence of the explicit information within the same (or nested, or nesting) structure. E.g. by the editor most probably means staffGrp="false" in the outer group, rather than "no information about whether bar lines are crossing in the outer group or not, but bar lines definitely crossing in the inner group". Another example is where the inner group should surely "inherit" its parent's barthru="false" if we think about it intuitively. Do I understand it right, that profiles are meant to handle these sorts of ambiguities of encoding? It would be great if you could point me towards further info regarding profiles. Thanks very much Zoltan P.S.: following Andrew Hankinson's suggestion I am moving this discussion from mei-devel to MEI-L 2013/6/21 Thomas Weber > Hi Zoltan, > > welcome to the wonderful world of MEI! It's good to see people driving > MEItoVexFlow forward. > > > Am 21.06.2013 18:42, schrieb Zoltan Komives: > >> We will have to decide upon the default behaviour for certains >> attributes in case they are not present. >> >> We are going to define a customization for our particular application, >> but it raises the question whether there are some attributes that would >> benefit from a default value set by the guidelines. >> >> In particular, we've come across the @barthru attribute (/"indicates >> >> whether bar lines go across the space between staves (true) or are only >> drawn across the lines of each staff (false)."/). Its use is highly >> >> inconsistent across the sample encodings, and we think that maybe for >> this particular attribute we would gain more in consistency than the >> loss in flexibility. >> >> > > I don't think that for MEI it would make sense to define defaults for > attributes like this. I only fear my explanation will not really help to > bring MEItoVexFlow forward in the short run... > > MEI, being designed for musicological uses, by intention allows very > different music encoding approaches. Musicological projects may have very > different requirements, some concentrating on mere pitch information more > in a MIDI like fashion, some encoding as much as possible of the layout > information found in a specific source, some not even encoding musical > content at all but only structural or macro-layout information. This > means, MEI gives you the choice to encode just the information required for > a specific project, leaving everything else out. That said, assuming > default values for attributes like @barthru would sort of force projects to > set this attribute because leaving it out would have implications that were > not intended. > > A missing @barthru in my eyes should just be read as "this particular > encoding does not record information about whether barlines cross the space > between staffs". If you have to deal with data that has no @barthru but > you need it, then you unfortunately have to find your own solutions how to > fill them in (which might be just assuming them to be false, or do some > more clever guessing). > > There were plans to define MEI "profiles" that follow stricter rules to > make MEI data more exchangeable for certain applications. For your > application, a profile that enforces information needed for rendering would > of course be very useful. As profiles don't exist yet, you could take the > initiative and make suggestion how such a profile should look like. Also, > there were plans to create tools that would "iron" and "canonicalize" MEI > so you can then work with more consistently encoded data. I have a few > small XSLT 2.0 stylesheets that cover some aspects of this (like converting > attributes to elements in cases where there are both attributes and > elements available to encode the same thing; or add @plist to spanning > elements). I guess we should start collecting these things. > > I wish you a successful summer and am curious what we will see after this > GSOC! > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zupftom at googlemail.com Sat Jun 22 15:00:10 2013 From: zupftom at googlemail.com (TW) Date: Sat, 22 Jun 2013 15:00:10 +0200 Subject: [MEI-L] [mei-devel] Attribute default values In-Reply-To: References: <51C4B32D.1070700@web.de> Message-ID: Am 22.06.2013 14:41, schrieb Zoltan Komives: > > However, in some cases an assumption of a default value can be implied > by the presence of the explicit information within the same (or nested, > or nesting) structure. > > E.g. by > > > > > I must agree! > > Do I understand it right, that profiles are meant to handle these sorts > of ambiguities of encoding? It would be great if you could point me > towards further info regarding profiles. > My understanding of these ideas is to create subsets of MEI with stricter rules that are required to provide more information in a more consistent way. (I'm thinking about something similar to the Open Score Format, which is a stricter MusicXML.) I'm not sure whether anyone has already done work on something like this, but I think *ideally* such profiles (or however you might call them) should not allow ambiguity to start with rather than giving you rules how to resolve ambiguity. Others might be more competent than me talking about this. Cheers! Thomas From raffaeleviglianti at gmail.com Sat Jun 22 20:10:47 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Sat, 22 Jun 2013 14:10:47 -0400 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: References: <51C4A7B8.1010809@indiana.edu> <22C30E84-6EB3-4D85-9955-F40D9ED8D8CF@edirom.de> Message-ID: Thanks Craig, I forgot about @func="edit". It certainly avoids confusion. I also see what you mean about @place; it probably won't hurt if Micah added it to his encoding, though. Raffaele On Fri, Jun 21, 2013 at 5:52 PM, Craig Sapp wrote: > Hi Raffaele, > > On Fri, Jun 21, 2013 at 2:06 PM, Raffaele Viglianti < > raffaeleviglianti at gmail.com> wrote: > >> >> >> >> > > I wouldn't mind, but crazy purists would complain that if you use this to > indicate an editorial B-flat, then it is semantically incorrect since > B-flat is technically not a musica ficta note. So it is in general better > to think of them as editorial accidentals used to chromatically inflect > notes for performance, which usually happen to move the notes onto musica > ficta pitches. > > > -=+Craig > > > _______________________________________________ > 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: From raffaeleviglianti at gmail.com Sat Jun 22 20:19:56 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Sat, 22 Jun 2013 14:19:56 -0400 Subject: [MEI-L] [mei-devel] Attribute default values In-Reply-To: References: <51C4B32D.1070700@web.de> Message-ID: I've suggested to Zoltan elsewhere that a good (I believe) way around this issue is to produce an ODD that documents the assumptions that the program makes when not enough information is provided. It's possible to use to express the default value of an attribute, and if the program needs a value for a missing attribute to proceed, it can default to . ODD, in practice, could be used to define what Thomas is calling a "profile". Zoltan's question, I think, is more general: is there room in the guidelines to cover what it means to omit an optional attribute? Most optional attributes may signify the presence/absence of a symbol or feature, but others like @barthru become meaningful as soon as there are barlines. Perhaps @barthru needs a change in the ODD from optional to mandatory-when-applicable and a note in the guidelines? Are there other attributes that could benefit from the same treatment? Raffaele On Sat, Jun 22, 2013 at 9:00 AM, TW wrote: > Am 22.06.2013 14:41, schrieb Zoltan Komives: > > > > However, in some cases an assumption of a default value can be implied > > by the presence of the explicit information within the same (or nested, > > or nesting) structure. > > > > E.g. by > > > > > > > > > > > > > I must agree! > > > > > > Do I understand it right, that profiles are meant to handle these sorts > > of ambiguities of encoding? It would be great if you could point me > > towards further info regarding profiles. > > > > > My understanding of these ideas is to create subsets of MEI with > stricter rules that are required to provide more information in a more > consistent way. (I'm thinking about something similar to the Open > Score Format, which is a stricter MusicXML.) I'm not sure whether > anyone has already done work on something like this, but I think > *ideally* such profiles (or however you might call them) should not > allow ambiguity to start with rather than giving you rules how to > resolve ambiguity. > > Others might be more competent than me talking about this. > > Cheers! > 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: From mwalter at haverford.edu Sat Jun 22 20:45:08 2013 From: mwalter at haverford.edu (Micah Walter) Date: Sat, 22 Jun 2013 14:45:08 -0400 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: References: <51C4A7B8.1010809@indiana.edu> <22C30E84-6EB3-4D85-9955-F40D9ED8D8CF@edirom.de> Message-ID: <90F4F437-BFC7-4C44-9047-1BA63ADDB1EC@haverford.edu> Thanks all for the suggestions! I like the specificity provided by @place, and the clarification provided by @reason. While I'm fine with the loose usage of "ficta" in this case, it might be even more useful to provide a particular reason: "cadence" (raised tone at authentic cadence), "preparation" (lowered sixth degree in Phrygian lead-up to authentic cadence), "tritone" (to avoid struck dissonance), "imitation", etc. I'd also be interested to hear reasons for preferring over , or vice versa. -Micah On Jun 21, 2013, at 17:52, Craig Sapp wrote: > Hi Raffaele, > > On Fri, Jun 21, 2013 at 2:06 PM, Raffaele Viglianti wrote: >> >> >> > > I wouldn't mind, but crazy purists would complain that if you use this to indicate an editorial B-flat, then it is semantically incorrect since B-flat is technically not a musica ficta note. So it is in general better to think of them as editorial accidentals used to chromatically inflect notes for performance, which usually happen to move the notes onto musica ficta pitches. > > > -=+Craig > > _______________________________________________ > 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: From raffaeleviglianti at gmail.com Sat Jun 22 20:57:01 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Sat, 22 Jun 2013 14:57:01 -0400 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: <90F4F437-BFC7-4C44-9047-1BA63ADDB1EC@haverford.edu> References: <51C4A7B8.1010809@indiana.edu> <22C30E84-6EB3-4D85-9955-F40D9ED8D8CF@edirom.de> <90F4F437-BFC7-4C44-9047-1BA63ADDB1EC@haverford.edu> Message-ID: Even if you might keep supplid/@reason to encode a taxonomy of editorial additions, I would still use @func="edit" on like Craig suggested. About supplied v add: "The and elements may be used to record where material has been added or deleted in the source material." (i.e. not provided/removed by the editor) http://music-encoding.org/documentation/guidelines2013/editTrans#edittransAddDel Supplied "Contains material supplied by the transcriber or editor in place of text which cannot be read, either because of physical damage or loss in the original or because it is illegible for any reason." http://music-encoding.org/documentation/guidelines2013/supplied Raffaele On Sat, Jun 22, 2013 at 2:45 PM, Micah Walter wrote: > Thanks all for the suggestions! > > I like the specificity provided by @place, and the clarification provided > by @reason. While I'm fine with the loose usage of "ficta" in this case, it > might be even more useful to provide a particular reason: "cadence" (raised > tone at authentic cadence), "preparation" (lowered sixth degree in Phrygian > lead-up to authentic cadence), "tritone" (to avoid struck dissonance), > "imitation", etc. > > I'd also be interested to hear reasons for preferring over > , or vice versa. > > -Micah > > > On Jun 21, 2013, at 17:52, Craig Sapp wrote: > > Hi Raffaele, > > On Fri, Jun 21, 2013 at 2:06 PM, Raffaele Viglianti < > raffaeleviglianti at gmail.com> wrote: > >> >> >> >> > > I wouldn't mind, but crazy purists would complain that if you use this to > indicate an editorial B-flat, then it is semantically incorrect since > B-flat is technically not a musica ficta note. So it is in general better > to think of them as editorial accidentals used to chromatically inflect > notes for performance, which usually happen to move the notes onto musica > ficta pitches. > > > -=+Craig > > _______________________________________________ > 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: From andrew.hankinson at mail.mcgill.ca Sat Jun 22 21:03:30 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Sat, 22 Jun 2013 15:03:30 -0400 Subject: [MEI-L] [mei-devel] Attribute default values In-Reply-To: <29575_1371925229_51C5EAED_29575_352_1_CAMyHAnNO5AfeEc7cBAH2cq54N5uQyo-kyCbANj7FZEGEZc61eg@mail.gmail.com> References: <51C4B32D.1070700@web.de> <29575_1371925229_51C5EAED_29575_352_1_CAMyHAnNO5AfeEc7cBAH2cq54N5uQyo-kyCbANj7FZEGEZc61eg@mail.gmail.com> Message-ID: As Thomas points out, I'm not sure that we want to go down the "mandatory-when-applicable" route. It may be that the omission of the @barthru (or similar attributes) is a conscious decision in the encoding, so specifying a default value in its absence may introduce undesired assumptions. My opinion is that the best way to deal with ambiguity is to deal with it at the application level and then document your application's behaviour. If it were me, I would default to "false-if-not-present" for boolean values but, like Thomas mentions, another application might parse this as "unimportant-if-not-present". Either way, it's up to the implementation to specify behaviour, not the spec. For non-boolean values it might be a bit trickier, but again I think the best way to deal with it is to make reasonable assumptions in how your users expect your application to behave and then document it. On 2013-06-22, at 2:19 PM, Raffaele Viglianti wrote: > I've suggested to Zoltan elsewhere that a good (I believe) way around this issue is to produce an ODD that documents the assumptions that the program makes when not enough information is provided. > > It's possible to use to express the default value of an attribute, and if the program needs a value for a missing attribute to proceed, it can default to . > > ODD, in practice, could be used to define what Thomas is calling a "profile". > > Zoltan's question, I think, is more general: is there room in the guidelines to cover what it means to omit an optional attribute? Most optional attributes may signify the presence/absence of a symbol or feature, but others like @barthru become meaningful as soon as there are barlines. > > Perhaps @barthru needs a change in the ODD from optional to mandatory-when-applicable and a note in the guidelines? Are there other attributes that could benefit from the same treatment? > > Raffaele > > > On Sat, Jun 22, 2013 at 9:00 AM, TW wrote: > Am 22.06.2013 14:41, schrieb Zoltan Komives: > > > > However, in some cases an assumption of a default value can be implied > > by the presence of the explicit information within the same (or nested, > > or nesting) structure. > > > > E.g. by > > > > > > > > > > > > > I must agree! > > > > > > Do I understand it right, that profiles are meant to handle these sorts > > of ambiguities of encoding? It would be great if you could point me > > towards further info regarding profiles. > > > > > My understanding of these ideas is to create subsets of MEI with > stricter rules that are required to provide more information in a more > consistent way. (I'm thinking about something similar to the Open > Score Format, which is a stricter MusicXML.) I'm not sure whether > anyone has already done work on something like this, but I think > *ideally* such profiles (or however you might call them) should not > allow ambiguity to start with rather than giving you rules how to > resolve ambiguity. > > Others might be more competent than me talking about this. > > Cheers! > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zupftom at web.de Sat Jun 22 14:59:29 2013 From: zupftom at web.de (Thomas Weber) Date: Sat, 22 Jun 2013 14:59:29 +0200 Subject: [MEI-L] [mei-devel] Attribute default values In-Reply-To: References: <51C4B32D.1070700@web.de> Message-ID: <51C59FB1.1050405@web.de> Am 22.06.2013 14:41, schrieb Zoltan Komives: > > However, in some cases an assumption of a default value can be implied > by the presence of the explicit information within the same (or nested, > or nesting) structure. > > E.g. by > > > > > I must agree! > > Do I understand it right, that profiles are meant to handle these sorts > of ambiguities of encoding? It would be great if you could point me > towards further info regarding profiles. > My understanding of these ideas is to create subsets of MEI with stricter rules that are required to provide more information in a more consistent way. (I'm thinking about something similar to the Open Score Format, which is a stricter MusicXML.) I'm not sure whether anyone has already done work on something like this, but I think *ideally* such profiles (or however you might call them) should not allow ambiguity to start with rather than giving you rules how to resolve ambiguity. Others might be more competent than me talking about this. Cheers! Thomas From stadler at edirom.de Mon Jun 24 10:35:48 2013 From: stadler at edirom.de (Peter Stadler) Date: Mon, 24 Jun 2013 10:35:48 +0200 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: References: <51C4A7B8.1010809@indiana.edu> <22C30E84-6EB3-4D85-9955-F40D9ED8D8CF@edirom.de> Message-ID: <6676512D-4232-4EB0-AE76-6EC251115B92@edirom.de> Well, I am confused now ? What is the difference between and ? To me, both look like editorial additions?! An additional note on the description of . (Having tei:supplied in mind) I find the current description "? illegible for any reason" misleading as it seems there *must* have been something written. But what about editorial additions due to simple omission in the authorial score? TEI simply says: "signifies text supplied by the transcriber or editor for any reason ?"[1] Best Peter [1] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-supplied.html Am 22.06.2013 um 20:10 schrieb Raffaele Viglianti : > Thanks Craig, I forgot about @func="edit". It certainly avoids confusion. I also see what you mean about @place; it probably won't hurt if Micah added it to his encoding, though. > > Raffaele > > > On Fri, Jun 21, 2013 at 5:52 PM, Craig Sapp wrote: > Hi Raffaele, > > On Fri, Jun 21, 2013 at 2:06 PM, Raffaele Viglianti wrote: > > > > > I wouldn't mind, but crazy purists would complain that if you use this to indicate an editorial B-flat, then it is semantically incorrect since B-flat is technically not a musica ficta note. So it is in general better to think of them as editorial accidentals used to chromatically inflect notes for performance, which usually happen to move the notes onto musica ficta pitches. > > > -=+Craig > -- Peter Stadler Carl-Maria-von-Weber-Gesamtausgabe Arbeitsstelle Detmold Gartenstr. 20 D-32756 Detmold Tel. +49 5231 975-665 Fax: +49 5231 975-668 stadler at weber-gesamtausgabe.de www.weber-gesamtausgabe.de From pdr4h at eservices.virginia.edu Mon Jun 24 15:37:19 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 24 Jun 2013 13:37:19 +0000 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: <6676512D-4232-4EB0-AE76-6EC251115B92@edirom.de> References: <51C4A7B8.1010809@indiana.edu> <22C30E84-6EB3-4D85-9955-F40D9ED8D8CF@edirom.de> , <6676512D-4232-4EB0-AE76-6EC251115B92@edirom.de> Message-ID: Hi Peter, They are indeed both nearly the same thing. is more expressive in that it provides a more complete reason for the accidental, while is intentionally more compact, tying the func attribute directly to the accid element instead of requiring the additional nested markup. This style is useful for direct translation from other encoding systems that don't have any notion of supplied vs correction vs regularization ... Unless the MEI is being transformed from another encoding scheme, the first example should be preferred. I agree that the one sentence definition of is somewhat misleading. But, in section 11.4.1 "Omissions, Unclear Readings, Damage, and Supplied Readings", the MEI Guidelines provide a little more, well, guidance -- "Sometimes the editor provides information not present in the source material. These conjectures or emendations are marked up in MEI using the element." Would re-wording this sentence help clear up confusion? -- 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 Peter Stadler [stadler at edirom.de] Sent: Monday, June 24, 2013 4:35 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Conventional encoding of suggested accidentals (ficta)? Well, I am confused now ? What is the difference between and ? To me, both look like editorial additions?! An additional note on the description of . (Having tei:supplied in mind) I find the current description "? illegible for any reason" misleading as it seems there *must* have been something written. But what about editorial additions due to simple omission in the authorial score? TEI simply says: "signifies text supplied by the transcriber or editor for any reason ?"[1] Best Peter [1] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-supplied.html Am 22.06.2013 um 20:10 schrieb Raffaele Viglianti : > Thanks Craig, I forgot about @func="edit". It certainly avoids confusion. I also see what you mean about @place; it probably won't hurt if Micah added it to his encoding, though. > > Raffaele > > > On Fri, Jun 21, 2013 at 5:52 PM, Craig Sapp wrote: > Hi Raffaele, > > On Fri, Jun 21, 2013 at 2:06 PM, Raffaele Viglianti wrote: > > > > > I wouldn't mind, but crazy purists would complain that if you use this to indicate an editorial B-flat, then it is semantically incorrect since B-flat is technically not a musica ficta note. So it is in general better to think of them as editorial accidentals used to chromatically inflect notes for performance, which usually happen to move the notes onto musica ficta pitches. > > > -=+Craig > -- Peter Stadler Carl-Maria-von-Weber-Gesamtausgabe Arbeitsstelle Detmold Gartenstr. 20 D-32756 Detmold Tel. +49 5231 975-665 Fax: +49 5231 975-668 stadler at weber-gesamtausgabe.de www.weber-gesamtausgabe.de _______________________________________________ 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 Jun 24 15:51:03 2013 From: stadler at edirom.de (Peter Stadler) Date: Mon, 24 Jun 2013 15:51:03 +0200 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: References: <51C4A7B8.1010809@indiana.edu> <22C30E84-6EB3-4D85-9955-F40D9ED8D8CF@edirom.de> , <6676512D-4232-4EB0-AE76-6EC251115B92@edirom.de> Message-ID: <203A705D-9E7B-4C70-A9DC-27923EEE6A9D@edirom.de> Hi Perry, thanks for the clarification! > I agree that the one sentence definition of is somewhat misleading. But, in section 11.4.1 "Omissions, Unclear Readings, Damage, and Supplied Readings", the MEI Guidelines provide a little more, well, guidance -- > > "Sometimes the editor provides information not present in the source material. These conjectures or emendations are marked up in MEI using the element." > > Would re-wording this sentence help clear up confusion? Admittedly I only looked at the short description. The wording in section 11.4.1 makes it very clear by adding this "not present in the source material". So I'd propose to add (supply?!) this information to the the element description as well. Shall I file a feature request? Best Peter -- Peter Stadler Carl-Maria-von-Weber-Gesamtausgabe Arbeitsstelle Detmold Gartenstr. 20 D-32756 Detmold Tel. +49 5231 975-665 Fax: +49 5231 975-668 stadler at weber-gesamtausgabe.de www.weber-gesamtausgabe.de From pdr4h at eservices.virginia.edu Mon Jun 24 16:21:05 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 24 Jun 2013 14:21:05 +0000 Subject: [MEI-L] Conventional encoding of suggested accidentals (ficta)? In-Reply-To: <203A705D-9E7B-4C70-A9DC-27923EEE6A9D@edirom.de> References: <51C4A7B8.1010809@indiana.edu> <22C30E84-6EB3-4D85-9955-F40D9ED8D8CF@edirom.de> , <6676512D-4232-4EB0-AE76-6EC251115B92@edirom.de> , <203A705D-9E7B-4C70-A9DC-27923EEE6A9D@edirom.de> Message-ID: Yes, please file an issue report. Thank you, -- 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 Peter Stadler [stadler at edirom.de] Sent: Monday, June 24, 2013 9:51 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Conventional encoding of suggested accidentals (ficta)? Hi Perry, thanks for the clarification! > I agree that the one sentence definition of is somewhat misleading. But, in section 11.4.1 "Omissions, Unclear Readings, Damage, and Supplied Readings", the MEI Guidelines provide a little more, well, guidance -- > > "Sometimes the editor provides information not present in the source material. These conjectures or emendations are marked up in MEI using the element." > > Would re-wording this sentence help clear up confusion? Admittedly I only looked at the short description. The wording in section 11.4.1 makes it very clear by adding this "not present in the source material". So I'd propose to add (supply?!) this information to the the element description as well. Shall I file a feature request? Best Peter -- Peter Stadler Carl-Maria-von-Weber-Gesamtausgabe Arbeitsstelle Detmold Gartenstr. 20 D-32756 Detmold Tel. +49 5231 975-665 Fax: +49 5231 975-668 stadler at weber-gesamtausgabe.de www.weber-gesamtausgabe.de _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From david_day at byu.edu Thu Jun 27 08:22:21 2013 From: david_day at byu.edu (David Day) Date: Thu, 27 Jun 2013 06:22:21 +0000 Subject: [MEI-L] Weber edition online Message-ID: <4318104D-7761-40CA-B852-2B5C94B14E68@byu.edu> I apologize in advance if this question is not central to the purposes of the list. At a previous conference I recall a presentation related to planning or progress to create a Weber critical edition online, or at least a critical edition of Der Freischutz. I have not been able to locate this online. Can anyone point me in the right direction? Thanks in advance, David Day From kepper at edirom.de Thu Jun 27 08:44:49 2013 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 27 Jun 2013 08:44:49 +0200 Subject: [MEI-L] Weber edition online In-Reply-To: <4318104D-7761-40CA-B852-2B5C94B14E68@byu.edu> References: <4318104D-7761-40CA-B852-2B5C94B14E68@byu.edu> Message-ID: <4A2F8983-EF53-4D83-8791-AA77A19290F0@edirom.de> Dear David, there is an online edition of the Freisch?tz under development. The website for this is http://www.freischuetz-digital.de. I just noticed I'm having problems to access the website, which we'll look into now. But even when this problem is resolved, you won't be able to find the edition there yet. We're still setting up the data, but we hope to publish some initial material there in the near future. The project ends in summer 2015, so there is still a long way to go before we're finished. If you're looking for other Weber materials, I can recommend the website of the Weber complete works edition. They don't have editions of the music, but provide very good access to diaries, letters and other material from Weber and some contemporaries. Check it out at http://www.weber-gesamtausgabe.de. If you have more specific questions, just let me know ? on or off list. Best regards, Johannes Am 27.06.2013 um 08:22 schrieb David Day : > I apologize in advance if this question is not central to the purposes of the list. > > At a previous conference I recall a presentation related to planning or progress to create a Weber critical edition online, or at least a critical edition of Der Freischutz. I have not been able to locate this online. Can anyone point me in the right direction? > > Thanks in advance, > David Day > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From david_day at byu.edu Thu Jun 27 09:06:42 2013 From: david_day at byu.edu (David Day) Date: Thu, 27 Jun 2013 07:06:42 +0000 Subject: [MEI-L] Weber edition online In-Reply-To: <4A2F8983-EF53-4D83-8791-AA77A19290F0@edirom.de> References: <4318104D-7761-40CA-B852-2B5C94B14E68@byu.edu> <4A2F8983-EF53-4D83-8791-AA77A19290F0@edirom.de> Message-ID: <51BD03AE-8B53-4FBE-8EBF-40B7E5495B2A@byu.edu> Thanks a million! On Jun 27, 2013, at 8:44 AM, Johannes Kepper wrote: > Dear David, > > there is an online edition of the Freisch?tz under development. The website for this is http://www.freischuetz-digital.de. I just noticed I'm having problems to access the website, which we'll look into now. But even when this problem is resolved, you won't be able to find the edition there yet. We're still setting up the data, but we hope to publish some initial material there in the near future. The project ends in summer 2015, so there is still a long way to go before we're finished. > > If you're looking for other Weber materials, I can recommend the website of the Weber complete works edition. They don't have editions of the music, but provide very good access to diaries, letters and other material from Weber and some contemporaries. Check it out at http://www.weber-gesamtausgabe.de. > > If you have more specific questions, just let me know ? on or off list. > > Best regards, > Johannes > > > > > > > Am 27.06.2013 um 08:22 schrieb David Day : > >> I apologize in advance if this question is not central to the purposes of the list. >> >> At a previous conference I recall a presentation related to planning or progress to create a Weber critical edition online, or at least a critical edition of Der Freischutz. I have not been able to locate this online. Can anyone point me in the right direction? >> >> Thanks in advance, >> David Day >> _______________________________________________ >> 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 mwalter at haverford.edu Mon Jul 1 17:25:01 2013 From: mwalter at haverford.edu (Micah Walter) Date: Mon, 1 Jul 2013 11:25:01 -0400 Subject: [MEI-L] Lyrics: Extender lines Message-ID: <02CE3FEB-30FE-47E0-BDE9-B1D2DF9306BB@haverford.edu> According to the Guidelines, @con="u" indicates that "[a]n underscore sign (indicating prologation of the syllable) is used as a connector between syllables". Later in the same section, the Guidelines state the following: "Occasionally, a word or a final syllable needs to be extended across multiple notes. In this case an ?extender? is provided. An extender is a continuous line drawn at the text's baseline from the end of the syllable associated with the first note until the last note to be sung with the syllable. The" [the paragraph abruptly breaks off here] Is there a difference between the "underscore" and the "extender"? Will the extender only be added if @con="u" has been encoded? Here is the link to the relevant section: http://music-encoding.org/documentation/guidelines2013/lyricsDesc Thanks, Micah Walter From andrew.hankinson at mail.mcgill.ca Mon Jul 1 18:01:47 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 1 Jul 2013 16:01:47 +0000 Subject: [MEI-L] Lyrics: Extender lines In-Reply-To: <13879_1372692332_51D19F69_13879_157_1_02CE3FEB-30FE-47E0-BDE9-B1D2DF9306BB@haverford.edu> References: <13879_1372692332_51D19F69_13879_157_1_02CE3FEB-30FE-47E0-BDE9-B1D2DF9306BB@haverford.edu> Message-ID: Hi Micah, Thanks for pointing out that paragraph trailing off. I've fixed it (in the MEI 2013 and in the development branch). I will leave it to others to properly respond to your question. -Andrew On 2013-07-01, at 11:25 AM, Micah Walter wrote: > According to the Guidelines, @con="u" indicates that "[a]n underscore sign (indicating prologation of the syllable) is used as a connector between syllables". Later in the same section, the Guidelines state the following: > > "Occasionally, a word or a final syllable needs to be extended across multiple notes. In this case an ?extender? is provided. An extender is a continuous line drawn at the text's baseline from the end of the syllable associated with the first note until the last note to be sung with the syllable. The" [the paragraph abruptly breaks off here] > > Is there a difference between the "underscore" and the "extender"? Will the extender only be added if @con="u" has been encoded? > > Here is the link to the relevant section: http://music-encoding.org/documentation/guidelines2013/lyricsDesc > > Thanks, > Micah Walter > _______________________________________________ > 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 Mon Jul 1 20:01:52 2013 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Mon, 1 Jul 2013 11:01:52 -0700 (PDT) Subject: [MEI-L] Lyrics: Extender lines In-Reply-To: Message-ID: <1446372412.475234.1372701712868.JavaMail.root@stanford.edu> Extender types, referring only to music, not to MEI: 1. There are two kinds, the difference being contextual. 2. BUT there is some variation in publishers' house styles. There may also be some variables related to the language of the lyrics. At CCARH (main languages being Itlain and German), we use the extended underscore for words at the end of a text line, where the extension is likely to accommodate only one additional note. If a syllable in the middle of a text line has a melisma, we use a series of hyphens. One the things that varies with house style is where these types are complemented by phrase marks in the music itself. French text underlay is problematic in that the number of syllables as sung may be greater than the number normally heard in speech. Eleanor Selfridge-Field /* Style Definitions */p.MsoNormal, p.MsoAutoSig, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt;}@page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;}div.WordSection1 {page:WordSection1;} Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ ----- Original Message ----- From: Andrew Hankinson To: Music Encoding Initiative Sent: Mon, 01 Jul 2013 09:01:47 -0700 (PDT) Subject: Re: [MEI-L] Lyrics: Extender lines Hi Micah, Thanks for pointing out that paragraph trailing off. I've fixed it (in the MEI 2013 and in the development branch). I will leave it to others to properly respond to your question. -Andrew On 2013-07-01, at 11:25 AM, Micah Walter wrote: > According to the Guidelines, @con="u" indicates that "[a]n underscore sign (indicating prologation of the syllable) is used as a connector between syllables". Later in the same section, the Guidelines state the following: > > "Occasionally, a word or a final syllable needs to be extended across multiple notes. In this case an ?extender? is provided. An extender is a continuous line drawn at the text's baseline from the end of the syllable associated with the first note until the last note to be sung with the syllable. The" [the paragraph abruptly breaks off here] > > Is there a difference between the "underscore" and the "extender"? Will the extender only be added if @con="u" has been encoded? > > Here is the link to the relevant section: http://music-encoding.org/documentation/guidelines2013/lyricsDesc > > Thanks, > Micah Walter > _______________________________________________ > 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 Jul 1 20:29:57 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 1 Jul 2013 18:29:57 +0000 Subject: [MEI-L] Lyrics: Extender lines In-Reply-To: <02CE3FEB-30FE-47E0-BDE9-B1D2DF9306BB@haverford.edu> References: <02CE3FEB-30FE-47E0-BDE9-B1D2DF9306BB@haverford.edu> Message-ID: Hi, Micah, Sorry about the typo. Thanks, Andrew, for fixing it. @con is intended to hold so-called "connectors" between syllables that consist of a *single indicator*, in this case a single "_", as in "Per_ry". This is sometimes found as a substitute for a single hypen/dash. The primary purpose of these connectors is to provide syllabification of the text. @extender is for those situations where a continuous line is to be drawn, often under a melismatic passage. @con and @extender are independent of each other. It's not necessary to provide @con in order to get an extender. You do have to decide, however, whether your software will expect @extender or, when it's not present, render an extender based on the presence of @con="u". The reason for this complication is that lyrics don't always appear under notes. In these cases @extender isn't applicable, yet syllabification may still be desirable. Does that 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 Micah Walter [mwalter at haverford.edu] Sent: Monday, July 01, 2013 11:25 AM To: Music Encoding Initiative Subject: [MEI-L] Lyrics: Extender lines According to the Guidelines, @con="u" indicates that "[a]n underscore sign (indicating prologation of the syllable) is used as a connector between syllables". Later in the same section, the Guidelines state the following: "Occasionally, a word or a final syllable needs to be extended across multiple notes. In this case an ?extender? is provided. An extender is a continuous line drawn at the text's baseline from the end of the syllable associated with the first note until the last note to be sung with the syllable. The" [the paragraph abruptly breaks off here] Is there a difference between the "underscore" and the "extender"? Will the extender only be added if @con="u" has been encoded? Here is the link to the relevant section: http://music-encoding.org/documentation/guidelines2013/lyricsDesc Thanks, Micah Walter _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From mwalter at haverford.edu Mon Jul 1 23:56:19 2013 From: mwalter at haverford.edu (Micah Walter) Date: Mon, 1 Jul 2013 17:56:19 -0400 Subject: [MEI-L] Lyrics: Extender lines In-Reply-To: References: <02CE3FEB-30FE-47E0-BDE9-B1D2DF9306BB@haverford.edu> Message-ID: <61E73DF4-23B5-41D6-AF1C-D2180A843383@haverford.edu> So I understand that an extender is not necessarily added automatically; @extender="true" is necessary for the software to add an extender for a syllable lasting more than one note. However, some software may provide extenders automatically without the @extender attribute. @con="u" is essentially for a mid-word hyphen that happens to be on the baseline. Perhaps the sentence "In this case an ?extender? is provided" could be revised to "For such cases, the @extender attribute is provided"? Thanks for the help, Micah On 1 July 2013, at 14:29, "Roland, Perry (pdr4h)" wrote: > Hi, Micah, > > Sorry about the typo. Thanks, Andrew, for fixing it. > > @con is intended to hold so-called "connectors" between syllables that consist of a *single indicator*, in this case a single "_", as in "Per_ry". This is sometimes found as a substitute for a single hypen/dash. The primary purpose of these connectors is to provide syllabification of the text. > > @extender is for those situations where a continuous line is to be drawn, often under a melismatic passage. > > @con and @extender are independent of each other. It's not necessary to provide @con in order to get an extender. You do have to decide, however, whether your software will expect @extender or, when it's not present, render an extender based on the presence of @con="u". > > The reason for this complication is that lyrics don't always appear under notes. In these cases @extender isn't applicable, yet syllabification may still be desirable. > > Does that 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 Micah Walter [mwalter at haverford.edu] > Sent: Monday, July 01, 2013 11:25 AM > To: Music Encoding Initiative > Subject: [MEI-L] Lyrics: Extender lines > > According to the Guidelines, @con="u" indicates that "[a]n underscore sign (indicating prologation of the syllable) is used as a connector between syllables". Later in the same section, the Guidelines state the following: > > "Occasionally, a word or a final syllable needs to be extended across multiple notes. In this case an ?extender? is provided. An extender is a continuous line drawn at the text's baseline from the end of the syllable associated with the first note until the last note to be sung with the syllable. The" [the paragraph abruptly breaks off here] > > Is there a difference between the "underscore" and the "extender"? Will the extender only be added if @con="u" has been encoded? > > Here is the link to the relevant section: http://music-encoding.org/documentation/guidelines2013/lyricsDesc > > Thanks, > Micah Walter > _______________________________________________ > 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 Jul 2 00:59:09 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 1 Jul 2013 18:59:09 -0400 Subject: [MEI-L] Lyrics: Extender lines In-Reply-To: <17200_1372715802_51D1FB19_17200_179_1_61E73DF4-23B5-41D6-AF1C-D2180A843383@haverford.edu> References: <02CE3FEB-30FE-47E0-BDE9-B1D2DF9306BB@haverford.edu> <17200_1372715802_51D1FB19_17200_179_1_61E73DF4-23B5-41D6-AF1C-D2180A843383@haverford.edu> Message-ID: If you create a patch for the guidelines, I'll merge it in. -Andrew On 2013-07-01, at 5:56 PM, Micah Walter wrote: > So I understand that an extender is not necessarily added automatically; @extender="true" is necessary for the software to add an extender for a syllable lasting more than one note. However, some software may provide extenders automatically without the @extender attribute. @con="u" is essentially for a mid-word hyphen that happens to be on the baseline. > > Perhaps the sentence "In this case an ?extender? is provided" could be revised to "For such cases, the @extender attribute is provided"? > > Thanks for the help, > Micah > > > On 1 July 2013, at 14:29, "Roland, Perry (pdr4h)" wrote: > >> Hi, Micah, >> >> Sorry about the typo. Thanks, Andrew, for fixing it. >> >> @con is intended to hold so-called "connectors" between syllables that consist of a *single indicator*, in this case a single "_", as in "Per_ry". This is sometimes found as a substitute for a single hypen/dash. The primary purpose of these connectors is to provide syllabification of the text. >> >> @extender is for those situations where a continuous line is to be drawn, often under a melismatic passage. >> >> @con and @extender are independent of each other. It's not necessary to provide @con in order to get an extender. You do have to decide, however, whether your software will expect @extender or, when it's not present, render an extender based on the presence of @con="u". >> >> The reason for this complication is that lyrics don't always appear under notes. In these cases @extender isn't applicable, yet syllabification may still be desirable. >> >> Does that 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 Micah Walter [mwalter at haverford.edu] >> Sent: Monday, July 01, 2013 11:25 AM >> To: Music Encoding Initiative >> Subject: [MEI-L] Lyrics: Extender lines >> >> According to the Guidelines, @con="u" indicates that "[a]n underscore sign (indicating prologation of the syllable) is used as a connector between syllables". Later in the same section, the Guidelines state the following: >> >> "Occasionally, a word or a final syllable needs to be extended across multiple notes. In this case an ?extender? is provided. An extender is a continuous line drawn at the text's baseline from the end of the syllable associated with the first note until the last note to be sung with the syllable. The" [the paragraph abruptly breaks off here] >> >> Is there a difference between the "underscore" and the "extender"? Will the extender only be added if @con="u" has been encoded? >> >> Here is the link to the relevant section: http://music-encoding.org/documentation/guidelines2013/lyricsDesc >> >> Thanks, >> Micah Walter >> _______________________________________________ >> 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 mwalter at haverford.edu Tue Jul 2 16:15:17 2013 From: mwalter at haverford.edu (Micah Walter) Date: Tue, 2 Jul 2013 10:15:17 -0400 Subject: [MEI-L] Lyrics: Extender lines In-Reply-To: References: <02CE3FEB-30FE-47E0-BDE9-B1D2DF9306BB@haverford.edu> <17200_1372715802_51D1FB19_17200_179_1_61E73DF4-23B5-41D6-AF1C-D2180A843383@haverford.edu> Message-ID: <5D32D06F-F49A-4583-8BA9-DC8661284100@haverford.edu> In looking at the element description for , I didn't see @extender listed as a possible attribute (it is otherwise used for ). Is this also an incorrect omission? -Micah On 1 July 2013, at 18:59, Andrew Hankinson wrote: > If you create a patch for the guidelines, I'll merge it in. > > -Andrew > > On 2013-07-01, at 5:56 PM, Micah Walter > wrote: > >> So I understand that an extender is not necessarily added automatically; @extender="true" is necessary for the software to add an extender for a syllable lasting more than one note. However, some software may provide extenders automatically without the @extender attribute. @con="u" is essentially for a mid-word hyphen that happens to be on the baseline. >> >> Perhaps the sentence "In this case an ?extender? is provided" could be revised to "For such cases, the @extender attribute is provided"? >> >> Thanks for the help, >> Micah >> >> >> On 1 July 2013, at 14:29, "Roland, Perry (pdr4h)" wrote: >> >>> Hi, Micah, >>> >>> Sorry about the typo. Thanks, Andrew, for fixing it. >>> >>> @con is intended to hold so-called "connectors" between syllables that consist of a *single indicator*, in this case a single "_", as in "Per_ry". This is sometimes found as a substitute for a single hypen/dash. The primary purpose of these connectors is to provide syllabification of the text. >>> >>> @extender is for those situations where a continuous line is to be drawn, often under a melismatic passage. >>> >>> @con and @extender are independent of each other. It's not necessary to provide @con in order to get an extender. You do have to decide, however, whether your software will expect @extender or, when it's not present, render an extender based on the presence of @con="u". >>> >>> The reason for this complication is that lyrics don't always appear under notes. In these cases @extender isn't applicable, yet syllabification may still be desirable. >>> >>> Does that 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 Micah Walter [mwalter at haverford.edu] >>> Sent: Monday, July 01, 2013 11:25 AM >>> To: Music Encoding Initiative >>> Subject: [MEI-L] Lyrics: Extender lines >>> >>> According to the Guidelines, @con="u" indicates that "[a]n underscore sign (indicating prologation of the syllable) is used as a connector between syllables". Later in the same section, the Guidelines state the following: >>> >>> "Occasionally, a word or a final syllable needs to be extended across multiple notes. In this case an ?extender? is provided. An extender is a continuous line drawn at the text's baseline from the end of the syllable associated with the first note until the last note to be sung with the syllable. The" [the paragraph abruptly breaks off here] >>> >>> Is there a difference between the "underscore" and the "extender"? Will the extender only be added if @con="u" has been encoded? >>> >>> Here is the link to the relevant section: http://music-encoding.org/documentation/guidelines2013/lyricsDesc >>> >>> Thanks, >>> Micah Walter >>> _______________________________________________ >>> 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 Tue Jul 2 16:54:50 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 2 Jul 2013 14:54:50 +0000 Subject: [MEI-L] Lyrics: Extender lines In-Reply-To: <5D32D06F-F49A-4583-8BA9-DC8661284100@haverford.edu> References: <02CE3FEB-30FE-47E0-BDE9-B1D2DF9306BB@haverford.edu> <17200_1372715802_51D1FB19_17200_179_1_61E73DF4-23B5-41D6-AF1C-D2180A843383@haverford.edu> , <5D32D06F-F49A-4583-8BA9-DC8661284100@haverford.edu> Message-ID: I have to apologize for my recent misleading, nay, incorrect statements. Sometimes I forget the details of MEI myself. I'm sorry for not researching my answer to Micah's question before firing up the email machine. It plainly says in the description of the value "u" for @con that it is for "syllable extension", not syllabification like I stated earlier. So-called "extenders" should be drawn based on this value. Syllabification may therefore be indicated by either "d" (dash) or "u". There's actually no need for @extender on , so it's omission is not an error. How's this as a revision to the Guidelines? -- "Occasionally, a word or syllable needs to be extended across multiple notes. In this case, a so-called ?extender? (a continuous line drawn at the text's baseline from the end of the syllable or word associated with the first note until the last note to be sung with the syllable or word) may be rendered based on the presence of the @con attribute with a value of ?u?." Clearer? Mea culpa, -- 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 Micah Walter [mwalter at haverford.edu] Sent: Tuesday, July 02, 2013 10:15 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Lyrics: Extender lines In looking at the element description for , I didn't see @extender listed as a possible attribute (it is otherwise used for ). Is this also an incorrect omission? -Micah On 1 July 2013, at 18:59, Andrew Hankinson wrote: > If you create a patch for the guidelines, I'll merge it in. > > -Andrew > > On 2013-07-01, at 5:56 PM, Micah Walter > wrote: > >> So I understand that an extender is not necessarily added automatically; @extender="true" is necessary for the software to add an extender for a syllable lasting more than one note. However, some software may provide extenders automatically without the @extender attribute. @con="u" is essentially for a mid-word hyphen that happens to be on the baseline. >> >> Perhaps the sentence "In this case an ?extender? is provided" could be revised to "For such cases, the @extender attribute is provided"? >> >> Thanks for the help, >> Micah >> >> >> On 1 July 2013, at 14:29, "Roland, Perry (pdr4h)" wrote: >> >>> Hi, Micah, >>> >>> Sorry about the typo. Thanks, Andrew, for fixing it. >>> >>> @con is intended to hold so-called "connectors" between syllables that consist of a *single indicator*, in this case a single "_", as in "Per_ry". This is sometimes found as a substitute for a single hypen/dash. The primary purpose of these connectors is to provide syllabification of the text. >>> >>> @extender is for those situations where a continuous line is to be drawn, often under a melismatic passage. >>> >>> @con and @extender are independent of each other. It's not necessary to provide @con in order to get an extender. You do have to decide, however, whether your software will expect @extender or, when it's not present, render an extender based on the presence of @con="u". >>> >>> The reason for this complication is that lyrics don't always appear under notes. In these cases @extender isn't applicable, yet syllabification may still be desirable. >>> >>> Does that 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 Micah Walter [mwalter at haverford.edu] >>> Sent: Monday, July 01, 2013 11:25 AM >>> To: Music Encoding Initiative >>> Subject: [MEI-L] Lyrics: Extender lines >>> >>> According to the Guidelines, @con="u" indicates that "[a]n underscore sign (indicating prologation of the syllable) is used as a connector between syllables". Later in the same section, the Guidelines state the following: >>> >>> "Occasionally, a word or a final syllable needs to be extended across multiple notes. In this case an ?extender? is provided. An extender is a continuous line drawn at the text's baseline from the end of the syllable associated with the first note until the last note to be sung with the syllable. The" [the paragraph abruptly breaks off here] >>> >>> Is there a difference between the "underscore" and the "extender"? Will the extender only be added if @con="u" has been encoded? >>> >>> Here is the link to the relevant section: http://music-encoding.org/documentation/guidelines2013/lyricsDesc >>> >>> Thanks, >>> Micah Walter >>> _______________________________________________ >>> 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 zolaemil at gmail.com Mon Jul 8 10:56:34 2013 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Mon, 8 Jul 2013 09:56:34 +0100 Subject: [MEI-L] Interpreting @tstamp2 Message-ID: Hi All, I'm looking for confirmation that my thinking is right about interpreting @tstamp2 values (e.g. 2m+2) when the time signature changes between the location of the element indicating @tstamp and the 2nd next measure. According to the guidelines '*the timestamp (@tstamp) of a musical event is calculated in relation to the meter of the *current* measure and resembles the so-called ?beat?.*' About @tstamp: '*[@tstamp2] is expressed using the same logic as described above*'. (see http://music-encoding.org/documentation/guidelines2013/cmn#cmnTstamp ) I haven't found any explicit statement how to understand *current* measure in case of @tstamp2. Strictly speaking, *current* measure is the measure where the element with the @tstamp2 is located. However intuitively, all encountered measures should be considered with their effective time signature, therefore if there are three measures, the first in 2/4, the second in 5/8 and the third is 2/4, then 2m+1 should indicate the first quarter note in the last measure (as opposed to the 5th eights note in the second measure). Thank you Zoltan Komives -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Mon Jul 8 11:02:06 2013 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 8 Jul 2013 11:02:06 +0200 Subject: [MEI-L] Interpreting @tstamp2 In-Reply-To: References: Message-ID: Hi Zolt?n, congrats, you've spotted another underspecification. You're absolutely right ? it makes no sense to calculate the distance and timestamp of the range all by the first meter if that is changed later on. The "2m" part is clearly independent from the meter, and for the "+3" part, the "ending measure" should be regarded as current (so that in case of a meter change from 4/4 to 6/8, it would denote the third eighth in this case). Can you file a bug report on Google Code? Best, Johannes Am 08.07.2013 um 10:56 schrieb K?m?ves Zolt?n : > Hi All, > > I'm looking for confirmation that my thinking is right about interpreting @tstamp2 values (e.g. 2m+2) when the time signature changes between the location of the element indicating @tstamp and the 2nd next measure. > > According to the guidelines 'the timestamp (@tstamp) of a musical event is calculated in relation to the meter of the *current* measure and resembles the so-called ?beat?.' About @tstamp: '[@tstamp2] is expressed using the same logic as described above'. (see http://music-encoding.org/documentation/guidelines2013/cmn#cmnTstamp ) > > I haven't found any explicit statement how to understand *current* measure in case of @tstamp2. Strictly speaking, *current* measure is the measure where the element with the @tstamp2 is located. However intuitively, all encountered measures should be considered with their effective time signature, therefore if there are three measures, the first in 2/4, the second in 5/8 and the third is 2/4, then 2m+1 should indicate the first quarter note in the last measure (as opposed to the 5th eights note in the second measure). > > Thank you > Zoltan Komives > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From zolaemil at gmail.com Mon Jul 8 11:26:52 2013 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Mon, 8 Jul 2013 10:26:52 +0100 Subject: [MEI-L] Interpreting @tstamp2 In-Reply-To: References: Message-ID: Hi Johannes, Thanks for your answer! Sure will file the issue, is this the link to do so: https://code.google.com/p/music-encoding/ ? Thanks Zoltan 2013/7/8 Johannes Kepper > Hi Zolt?n, > > congrats, you've spotted another underspecification. You're absolutely > right ? it makes no sense to calculate the distance and timestamp of the > range all by the first meter if that is changed later on. The "2m" part is > clearly independent from the meter, and for the "+3" part, the "ending > measure" should be regarded as current (so that in case of a meter change > from 4/4 to 6/8, it would denote the third eighth in this case). > > Can you file a bug report on Google Code? > > Best, > Johannes > > Am 08.07.2013 um 10:56 schrieb K?m?ves Zolt?n : > > > Hi All, > > > > I'm looking for confirmation that my thinking is right about > interpreting @tstamp2 values (e.g. 2m+2) when the time signature changes > between the location of the element indicating @tstamp and the 2nd next > measure. > > > > According to the guidelines 'the timestamp (@tstamp) of a musical event > is calculated in relation to the meter of the *current* measure and > resembles the so-called ?beat?.' About @tstamp: '[@tstamp2] is expressed > using the same logic as described above'. (see > http://music-encoding.org/documentation/guidelines2013/cmn#cmnTstamp ) > > > > I haven't found any explicit statement how to understand *current* > measure in case of @tstamp2. Strictly speaking, *current* measure is the > measure where the element with the @tstamp2 is located. However > intuitively, all encountered measures should be considered with their > effective time signature, therefore if there are three measures, the first > in 2/4, the second in 5/8 and the third is 2/4, then 2m+1 should indicate > the first quarter note in the last measure (as opposed to the 5th eights > note in the second measure). > > > > Thank you > > Zoltan Komives > > _______________________________________________ > > 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: From zolaemil at gmail.com Mon Jul 8 12:07:21 2013 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Mon, 8 Jul 2013 11:07:21 +0100 Subject: [MEI-L] Interpreting @tstamp2 In-Reply-To: References: Message-ID: Thinking about it, it's about considering *target* measure, rather than *current* measure. Current measure sometimes equals to target measure, but more generally timestamp values relate to the time signature of the measure where they are pointing to. @tstamp can only point to the current measure, so in that case the distinction is irrelevant, but in case of @tstamp2 maybe it would make a sense to say that beats in @tstamp2 values are calculated in relation to the target measure, and if no measure part "[1-9]m" is specified then target measure = current measure. What do you think? Zoltan 2013/7/8 K?m?ves Zolt?n > Hi Johannes, > > Thanks for your answer! > > Sure will file the issue, is this the link to do so: > https://code.google.com/p/music-encoding/ ? > > Thanks > Zoltan > > > 2013/7/8 Johannes Kepper > >> Hi Zolt?n, >> >> congrats, you've spotted another underspecification. You're absolutely >> right ? it makes no sense to calculate the distance and timestamp of the >> range all by the first meter if that is changed later on. The "2m" part is >> clearly independent from the meter, and for the "+3" part, the "ending >> measure" should be regarded as current (so that in case of a meter change >> from 4/4 to 6/8, it would denote the third eighth in this case). >> >> Can you file a bug report on Google Code? >> >> Best, >> Johannes >> >> Am 08.07.2013 um 10:56 schrieb K?m?ves Zolt?n : >> >> > Hi All, >> > >> > I'm looking for confirmation that my thinking is right about >> interpreting @tstamp2 values (e.g. 2m+2) when the time signature changes >> between the location of the element indicating @tstamp and the 2nd next >> measure. >> > >> > According to the guidelines 'the timestamp (@tstamp) of a musical event >> is calculated in relation to the meter of the *current* measure and >> resembles the so-called ?beat?.' About @tstamp: '[@tstamp2] is expressed >> using the same logic as described above'. (see >> http://music-encoding.org/documentation/guidelines2013/cmn#cmnTstamp ) >> > >> > I haven't found any explicit statement how to understand *current* >> measure in case of @tstamp2. Strictly speaking, *current* measure is the >> measure where the element with the @tstamp2 is located. However >> intuitively, all encountered measures should be considered with their >> effective time signature, therefore if there are three measures, the first >> in 2/4, the second in 5/8 and the third is 2/4, then 2m+1 should indicate >> the first quarter note in the last measure (as opposed to the 5th eights >> note in the second measure). >> > >> > Thank you >> > Zoltan Komives >> > _______________________________________________ >> > 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: From kepper at edirom.de Mon Jul 8 12:15:47 2013 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 8 Jul 2013 12:15:47 +0200 Subject: [MEI-L] Interpreting @tstamp2 In-Reply-To: References: Message-ID: I agree that "target measure" is probably clearer than "current measure" in this context. One thing I wanted to add: It is possibly to omit the "[1-9]m" part, but I would strongly recommend to write this always as "0m+2" etc. To me, the regex that defines this data type (available from http://www.music-encoding.org/documentation/guidelines2013/data.MEASUREBEAT) is defined too loosely. I would also advise against the whitespaces in there, even though they may increase readability (I guess that's their justification in the first place). What do others think ? should we provide stricter rules for data.MEASUREBEAT, or should we leave it as open as it is now? Johannes Am 08.07.2013 um 12:07 schrieb K?m?ves Zolt?n : > Thinking about it, it's about considering *target* measure, rather than *current* measure. > > Current measure sometimes equals to target measure, but more generally timestamp values relate to the time signature of the measure where they are pointing to. @tstamp can only point to the current measure, so in that case the distinction is irrelevant, but in case of @tstamp2 maybe it would make a sense to say that beats in @tstamp2 values are calculated in relation to the target measure, and if no measure part "[1-9]m" is specified then target measure = current measure. > > What do you think? > Zoltan > > > 2013/7/8 K?m?ves Zolt?n > Hi Johannes, > > Thanks for your answer! > > Sure will file the issue, is this the link to do so: https://code.google.com/p/music-encoding/ ? > > Thanks > Zoltan > > > 2013/7/8 Johannes Kepper > Hi Zolt?n, > > congrats, you've spotted another underspecification. You're absolutely right ? it makes no sense to calculate the distance and timestamp of the range all by the first meter if that is changed later on. The "2m" part is clearly independent from the meter, and for the "+3" part, the "ending measure" should be regarded as current (so that in case of a meter change from 4/4 to 6/8, it would denote the third eighth in this case). > > Can you file a bug report on Google Code? > > Best, > Johannes > > Am 08.07.2013 um 10:56 schrieb K?m?ves Zolt?n : > > > Hi All, > > > > I'm looking for confirmation that my thinking is right about interpreting @tstamp2 values (e.g. 2m+2) when the time signature changes between the location of the element indicating @tstamp and the 2nd next measure. > > > > According to the guidelines 'the timestamp (@tstamp) of a musical event is calculated in relation to the meter of the *current* measure and resembles the so-called ?beat?.' About @tstamp: '[@tstamp2] is expressed using the same logic as described above'. (see http://music-encoding.org/documentation/guidelines2013/cmn#cmnTstamp ) > > > > I haven't found any explicit statement how to understand *current* measure in case of @tstamp2. Strictly speaking, *current* measure is the measure where the element with the @tstamp2 is located. However intuitively, all encountered measures should be considered with their effective time signature, therefore if there are three measures, the first in 2/4, the second in 5/8 and the third is 2/4, then 2m+1 should indicate the first quarter note in the last measure (as opposed to the 5th eights note in the second measure). > > > > Thank you > > Zoltan Komives > > _______________________________________________ > > 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 bohl at edirom.de Tue Jul 9 19:01:03 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Tue, 09 Jul 2013 19:01:03 +0200 Subject: [MEI-L] MEI Strategy Development Group Message-ID: <51DC41CF.80006@edirom.de> Der MEI-L:isteners, as mentioned earlier on this list, during the MEI Council meeting at Mainz formation of a MEI Strategy Development Group was decided. This group should develop ideas and models for future organization of MEI community. So far the initial group has been reinforced by a couple of additional members making us the following seven: - Anna Maria Komprecht - Axel Teich Geertinger - Christine Siegert - David Meredith - Giuliano Di Bacco - Laurent Pugin - Benjamin W. Bohl We installed a new mailinglist mei-strat at lists.uni-paderborn.de for the group's purposes. Currently this mailinglist is for goup members only (subscription needs confirmation), nevertheless anyone can address the list with moderated contributions or read the open archives at https://lists.uni-paderborn.de/pipermail/mei-strat/. So far we've elected a "keeper" and started discussing some first ideas. The next step during the following weeks will be to set up our agenda for the following year. **If you are interested in participating or contributing to our group feel free to contact us via the above mentioned list or to adress me personally.** On behalf of the MEI Strategy Development Group, Benjamin W. Bohl - Keeper - -- *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D--32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail:bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From zupftom at googlemail.com Wed Jul 10 08:23:49 2013 From: zupftom at googlemail.com (TW) Date: Wed, 10 Jul 2013 08:23:49 +0200 Subject: [MEI-L] Interpreting @tstamp2 In-Reply-To: References: Message-ID: 2013/7/8 Johannes Kepper : > One thing I wanted to add: It is possibly to omit the "[1-9]m" part, but I would strongly recommend to write this always as "0m+2" etc. To me, the regex that defines this data type (available from http://www.music-encoding.org/documentation/guidelines2013/data.MEASUREBEAT) is defined too loosely. I would also advise against the whitespaces in there, even though they may increase readability (I guess that's their justification in the first place). What do others think ? should we provide stricter rules for data.MEASUREBEAT, or should we leave it as open as it is now? > Everything that adds consistency and simplifies processing of MEI data without removing flexibility and without making things more difficult for encoders has my vote. Thomas From bohl at edirom.de Fri Jul 12 16:06:06 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 12 Jul 2013 16:06:06 +0200 Subject: [MEI-L] [Announcement] Edirom-Summer-School 2013 Message-ID: <51E00D4E.4080306@edirom.de> **if you have received this message through other menas already, please excuse cross posting.** Dear colleagues, let me inform you about Edirom-Summer-School 2013 taking place *23 to 27 September 2013* at Heinz-Nixdorf-Institute of the University of Paderborn, Germany, dedicated to the field of *digital text- and music edition *and offering a total of *13 distinct courses*. This year Musicology Seminar Detmold/Paderborn (University of Paderborn and Hochschule f?r Musik Detmold) is organising Edirom-Summer-School with the BMBF-funded project DARIAH-DE . Morover, the program is enriched by courses from TextGrid , Herzog August Bibliothek Wolfenb?ttel , Technische Universit?t Darmstadt (DH), and the Danish Centre for Music Publication in Copenhagen. The scope of course reaches from basic introductions to the markup standards of the Text Encoding Initiative (TEI) and the Music Encoding Initiative (MEI), across working with respective software tools for editor or library purposes (TextGrid, Edirom, MerMEId), up to practice-oriented courses dealing with more advanced features of encoding manuscripts with TEI and/or MEI. The *"Edirom-User-Forum"* will give opportunity of exchange between current and (potential) future users of the Edirom Tools. This year, for the first time, we offer *individual **research counsel sessions on "Digital Music Edition"*. Those interested, be it projects or individual scientists, can apply for a time slot with one of our staff members by submitting a short expos?. The complete program and further information on registration can be found on our new website http://ess.uni-paderborn.de. Registration deadline is *30 A**ugust*. Sincerely, Benjamin W. Bohl -- *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D--32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail:bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From mwalter at haverford.edu Tue Jul 23 20:41:30 2013 From: mwalter at haverford.edu (Micah Walter) Date: Tue, 23 Jul 2013 14:41:30 -0400 Subject: [MEI-L] Reconstructed parts Message-ID: <51BC93E0-3F3A-4F0A-826B-6D9B6C53EBCE@haverford.edu> Hello, folks, I have a question about encoding reconstructed parts. The project I'm working on contains complete works that are missing entire parts, as two of the parts are contained in a second partbook that is now lost. Different reconstructions are of course possible, and so I'd like to use the tag. Is the following, then, a reasonable encoding? Thanks, Micah Walter -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaeleviglianti at gmail.com Tue Jul 23 21:14:26 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 23 Jul 2013 15:14:26 -0400 Subject: [MEI-L] Reconstructed parts In-Reply-To: <51BC93E0-3F3A-4F0A-826B-6D9B6C53EBCE@haverford.edu> References: <51BC93E0-3F3A-4F0A-826B-6D9B6C53EBCE@haverford.edu> Message-ID: Hi Micah, The debate around seems to keep going :) As it is defined now, only deals with editorial "clarifications" of some text on a source, either by correction, regularization, expansion. This is in line with the TEI use of and I think it should stay like this. Nonetheless, there seems to be a need for a more generic "alternative" element, and it might be worth talking about this more and perhaps look at TEI's (which, btw, is not widely used as far as I know) http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT. For your case, I'd suggest to more simply make full use of and its attributes. This encodes strongly, as it were, that there are two different opinions because of supplied/@resp. And it encodes weakly that they are exclusive because of staff/@n. I wish there were a way to encode the exclusivity more strongly, but I don't think there's a way of doing so without tag abuse at the moment. Hope this helps, Raffaele On Tue, Jul 23, 2013 at 2:41 PM, Micah Walter wrote: > Hello, folks, > > I have a question about encoding reconstructed parts. The project I'm > working on contains complete works that are missing entire parts, as two of > the parts are contained in a second partbook that is now lost. > > Different reconstructions are of course possible, and so I'd like to use > the tag. Is the following, then, a reasonable encoding? > > > > > > > > > > > > > > > > > > > Thanks, > Micah Walter > > _______________________________________________ > 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: From esfield at stanford.edu Wed Jul 24 02:25:09 2013 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Tue, 23 Jul 2013 17:25:09 -0700 (PDT) Subject: [MEI-L] Reconstructed parts In-Reply-To: Message-ID: <511097838.2262229.1374625509450.JavaMail.root@stanford.edu> Hi, All, Micah is addressing an important need of musicologists, and it touches on an area that is probably irrelevant to TEI. I'm only perplexed about the word "choice". This is not about differing opinions. It could incur in a situation in which the editor proposes two or more realizations of lost material. (an important court case in France recently addressed this subject. The new material was understood to constitute new authorship, in contrast to the 1725 music otherwise present.) To be clear, one would have to say "proposed completion/realization." or something similar. Basso continuo realizations are similarly editorial creations. In both cases the added material is normally typeset in small notes, so unambiguous tags may do double duty in the future. Best regards, Eleanor Selfridge- Field esfield at stanford.edu /* Style Definitions */p.MsoNormal, p.MsoAutoSig, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt;}@page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;}div.WordSection1 {page:WordSection1;} Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ ----- Original Message ----- From: Raffaele Viglianti To: Music Encoding Initiative Sent: Tue, 23 Jul 2013 12:14:26 -0700 (PDT) Subject: Re: [MEI-L] Reconstructed parts Hi Micah, The debate around seems to keep going :) As it is defined now, only deals with editorial "clarifications" of some text on a source, either by correction, regularization, expansion. This is in line with the TEI use of and I think it should stay like this. Nonetheless, there seems to be a need for a more generic "alternative" element, and it might be worth talking about this more and perhaps look at TEI's (which, btw, is not widely used as far as I know) http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT. For your case, I'd suggest to more simply make full use of and its attributes. This encodes strongly, as it were, that there are two different opinions because of supplied/@resp. And it encodes weakly that they are exclusive because of staff/@n. I wish there were a way to encode the exclusivity more strongly, but I don't think there's a way of doing so without tag abuse at the moment. Hope this helps, Raffaele On Tue, Jul 23, 2013 at 2:41 PM, Micah Walter wrote: > Hello, folks, > > I have a question about encoding reconstructed parts. The project I'm > working on contains complete works that are missing entire parts, as two of > the parts are contained in a second partbook that is now lost. > > Different reconstructions are of course possible, and so I'd like to use > the tag. Is the following, then, a reasonable encoding? > > > > > > > > > > > > > > > > > > > Thanks, > Micah Walter > > _______________________________________________ > 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 24 04:25:50 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 24 Jul 2013 02:25:50 +0000 Subject: [MEI-L] Reconstructed parts In-Reply-To: <511097838.2262229.1374625509450.JavaMail.root@stanford.edu> References: , <511097838.2262229.1374625509450.JavaMail.root@stanford.edu> Message-ID: Hello all, I believe this situation is addressed in section 12.3 of the TEI Guidelines, "Using Apparatus Elements in Transcriptions" (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCTR) -- "It is often desirable to record different transcriptions of one stretch of text. These variant transcriptions may be grouped within a single app element. An application may then construct different ?views? of the transcription by extraction of the appropriate variant readings from the apparatus elements embedded in the transcription." The example provided Virginite is grete perfectio perfectio un perfectiou n isn't music, of course, but it's applicable to Micah's question. Because the elements have no @wit attribute (@source in MEI), they are not tied to a particular witness/source document. In other words, each of the readings here is a conjecture/reconstruction by the person identified as responsible (ES, FJF, and PGR). Applying this principle to Micah's example, we arrive at the following MEI markup -- Of course, this is only one method. There's nothing wrong with Raffaele's suggestion. But using in a transcriptional context is simple and keeps us from inventing more and more elements for smaller and smaller return. Since MEI permits within , this markup keeps us from having to repeat , which could lead to processing issues. Of course, there's no rule that says these different 'views' have to come from different people, so this markup also addresses Eleanor's example of multiple reconstructions by the same editor. -- 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 Eleanor Selfridge-Field [esfield at stanford.edu] Sent: Tuesday, July 23, 2013 8:25 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Reconstructed parts Hi, All, Micah is addressing an important need of musicologists, and it touches on an area that is probably irrelevant to TEI. I'm only perplexed about the word "choice". This is not about differing opinions. It could incur in a situation in which the editor proposes two or more realizations of lost material. (an important court case in France recently addressed this subject. The new material was understood to constitute new authorship, in contrast to the 1725 music otherwise present.) To be clear, one would have to say "proposed completion/realization." or something similar. Basso continuo realizations are similarly editorial creations. In both cases the added material is normally typeset in small notes, so unambiguous tags may do double duty in the future. Best regards, Eleanor Selfridge- Field esfield at stanford.edu /* Style Definitions */p.MsoNormal, p.MsoAutoSig, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt;}@page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;}div.WordSection1 {page:WordSection1;} Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ ----- Original Message ----- From: Raffaele Viglianti To: Music Encoding Initiative Sent: Tue, 23 Jul 2013 12:14:26 -0700 (PDT) Subject: Re: [MEI-L] Reconstructed parts Hi Micah, The debate around seems to keep going :) As it is defined now, only deals with editorial "clarifications" of some text on a source, either by correction, regularization, expansion. This is in line with the TEI use of and I think it should stay like this. Nonetheless, there seems to be a need for a more generic "alternative" element, and it might be worth talking about this more and perhaps look at TEI's (which, btw, is not widely used as far as I know) http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT. For your case, I'd suggest to more simply make full use of and its attributes. This encodes strongly, as it were, that there are two different opinions because of supplied/@resp. And it encodes weakly that they are exclusive because of staff/@n. I wish there were a way to encode the exclusivity more strongly, but I don't think there's a way of doing so without tag abuse at the moment. Hope this helps, Raffaele On Tue, Jul 23, 2013 at 2:41 PM, Micah Walter wrote: > Hello, folks, > > I have a question about encoding reconstructed parts. The project I'm > working on contains complete works that are missing entire parts, as two of > the parts are contained in a second partbook that is now lost. > > Different reconstructions are of course possible, and so I'd like to use > the tag. Is the following, then, a reasonable encoding? > > > > > > > > > > > > > > > > > > > Thanks, > Micah Walter > > _______________________________________________ > 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 Jul 24 15:14:10 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Wed, 24 Jul 2013 09:14:10 -0400 Subject: [MEI-L] Reconstructed parts In-Reply-To: References: <511097838.2262229.1374625509450.JavaMail.root@stanford.edu> Message-ID: Hi Perry, Good point, your solution makes perfect sense. I'm stuck with the idea that rdg = another physical source, but there's no need to be this strict, especially if @source and @resp can distinguish two different uses. So +1 to app/rdg for Micah's case. Raffaele On Tue, Jul 23, 2013 at 10:25 PM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > Hello all, > > I believe this situation is addressed in section 12.3 of the TEI > Guidelines, "Using Apparatus Elements in Transcriptions" ( > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCTR) -- > > "It is often desirable to record different transcriptions of one stretch > of text. These variant transcriptions may be grouped within a single app > element. An application may then construct different ?views? of the > transcription by extraction of the appropriate variant readings from the > apparatus elements embedded in the transcription." > > The example provided > > Virginite is grete > > perfectio > > > > > perfectio > un > > perfectiou > n > > > > isn't music, of course, but it's applicable to Micah's question. Because > the elements have no @wit attribute (@source in MEI), they are not > tied to a particular witness/source document. In other words, each of the > readings here is a conjecture/reconstruction by the person identified as > responsible (ES, FJF, and PGR). > > Applying this principle to Micah's example, we arrive at the following MEI > markup -- > > > > > > > > > > > > > > > > > > Of course, this is only one method. There's nothing wrong with Raffaele's > suggestion. But using in a transcriptional context is simple and > keeps us from inventing more and more elements for smaller and smaller > return. Since MEI permits within , this markup keeps us from > having to repeat , which could lead to processing issues. Of > course, there's no rule that says these different 'views' have to come from > different people, so this markup also addresses Eleanor's example of > multiple reconstructions by the same editor. > > -- > 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 Eleanor > Selfridge-Field [esfield at stanford.edu] > Sent: Tuesday, July 23, 2013 8:25 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Reconstructed parts > > Hi, All, > > Micah is addressing an important need of musicologists, and it touches on > an area that is probably irrelevant to TEI. I'm only perplexed about the > word "choice". This is not about differing opinions. It could incur in a > situation in which the editor proposes two or more realizations of lost > material. (an important court case in France recently addressed this > subject. The new material was understood to constitute new authorship, in > contrast to the 1725 music otherwise present.) > > To be clear, one would have to say "proposed completion/realization." or > something similar. Basso continuo realizations are similarly editorial > creations. In both cases the added material is normally typeset in small > notes, so unambiguous tags may do double duty in the future. > > Best regards, > > Eleanor Selfridge- Field > esfield at stanford.edu > > > > > > > > > xmlns:w="urn:schemas-microsoft-com:office:word" > xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" > xmlns="http://www.w3.org/TR/REC-html40"> > > /* Style Definitions */p.MsoNormal, p.MsoAutoSig, li.MsoNormal, > div.MsoNormal {margin:0cm; margin-bottom:.0001pt;}@page WordSection1 > {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; > mso-header-margin:36.0pt; mso-footer-margin:36.0pt; > mso-paper-source:0;}div.WordSection1 {page:WordSection1;} > > > > > > Eleanor Selfridge-Field > > Consulting Professor, Music (and, by courtesy, Symbolic Systems) > > Braun Music Center #129 > > Stanford University > > Stanford, CA 94305-3076, USA > > http://www.stanford.edu/~esfield/ > > > > > > > > > > > ----- Original Message ----- > From: Raffaele Viglianti > To: Music Encoding Initiative > Sent: Tue, 23 Jul 2013 12:14:26 -0700 (PDT) > Subject: Re: [MEI-L] Reconstructed parts > > Hi Micah, > > The debate around seems to keep going :) As it is defined now, > only deals with editorial "clarifications" of some text on a > source, either by correction, regularization, expansion. > This is in line with the TEI use of and I think it should stay > like this. > > Nonetheless, there seems to be a need for a more generic "alternative" > element, and it might be worth talking about this more and perhaps look at > TEI's (which, btw, is not widely used as far as I know) > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT. > > For your case, I'd suggest to more simply make full use of and > its attributes. > > > > > > > > > > This encodes strongly, as it were, that there are two different opinions > because of supplied/@resp. And it encodes weakly that they are exclusive > because of staff/@n. I wish there were a way to encode the exclusivity more > strongly, but I don't think there's a way of doing so without tag abuse at > the moment. > > Hope this helps, > Raffaele > > > > > On Tue, Jul 23, 2013 at 2:41 PM, Micah Walter > wrote: > > > Hello, folks, > > > > I have a question about encoding reconstructed parts. The project I'm > > working on contains complete works that are missing entire parts, as two > of > > the parts are contained in a second partbook that is now lost. > > > > Different reconstructions are of course possible, and so I'd like to use > > the tag. Is the following, then, a reasonable encoding? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > Micah Walter > > > > _______________________________________________ > > 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: From mwalter at haverford.edu Wed Jul 24 17:04:51 2013 From: mwalter at haverford.edu (Micah Walter) Date: Wed, 24 Jul 2013 11:04:51 -0400 Subject: [MEI-L] Reconstructed parts In-Reply-To: References: <511097838.2262229.1374625509450.JavaMail.root@stanford.edu> Message-ID: <86C98F26-4AF7-4F8F-8286-2B553B5BD2A5@haverford.edu> Thanks, Perry. This does make a lot of sense, and I don't know why I didn't look into earlier. It certainly looks like the "correct" tag for this situation. -Micah On 24 July 2013, at 09:14, Raffaele Viglianti wrote: > Hi Perry, > > Good point, your solution makes perfect sense. I'm stuck with the idea that rdg = another physical source, but there's no need to be this strict, especially if @source and @resp can distinguish two different uses. So +1 to app/rdg for Micah's case. > > Raffaele > > > On Tue, Jul 23, 2013 at 10:25 PM, Roland, Perry (pdr4h) wrote: > Hello all, > > I believe this situation is addressed in section 12.3 of the TEI Guidelines, "Using Apparatus Elements in Transcriptions" (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCTR) -- > > "It is often desirable to record different transcriptions of one stretch of text. These variant transcriptions may be grouped within a single app element. An application may then construct different ?views? of the transcription by extraction of the appropriate variant readings from the apparatus elements embedded in the transcription." > > The example provided > > Virginite is grete > > perfectio > > > > > perfectio > un > > perfectiou > n > > > > isn't music, of course, but it's applicable to Micah's question. Because the elements have no @wit attribute (@source in MEI), they are not tied to a particular witness/source document. In other words, each of the readings here is a conjecture/reconstruction by the person identified as responsible (ES, FJF, and PGR). > > Applying this principle to Micah's example, we arrive at the following MEI markup -- > > > > > > > > > > > > > > > > > > Of course, this is only one method. There's nothing wrong with Raffaele's suggestion. But using in a transcriptional context is simple and keeps us from inventing more and more elements for smaller and smaller return. Since MEI permits within , this markup keeps us from having to repeat , which could lead to processing issues. Of course, there's no rule that says these different 'views' have to come from different people, so this markup also addresses Eleanor's example of multiple reconstructions by the same editor. > > -- > 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 Eleanor Selfridge-Field [esfield at stanford.edu] > Sent: Tuesday, July 23, 2013 8:25 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Reconstructed parts > > Hi, All, > > Micah is addressing an important need of musicologists, and it touches on an area that is probably irrelevant to TEI. I'm only perplexed about the word "choice". This is not about differing opinions. It could incur in a situation in which the editor proposes two or more realizations of lost material. (an important court case in France recently addressed this subject. The new material was understood to constitute new authorship, in contrast to the 1725 music otherwise present.) > > To be clear, one would have to say "proposed completion/realization." or something similar. Basso continuo realizations are similarly editorial creations. In both cases the added material is normally typeset in small notes, so unambiguous tags may do double duty in the future. > > Best regards, > > Eleanor Selfridge- Field > esfield at stanford.edu > > > > > > > > > xmlns:w="urn:schemas-microsoft-com:office:word" > xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" > xmlns="http://www.w3.org/TR/REC-html40"> > > /* Style Definitions */p.MsoNormal, p.MsoAutoSig, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt;}@page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;}div.WordSection1 {page:WordSection1;} > > > > > > Eleanor Selfridge-Field > > Consulting Professor, Music (and, by courtesy, Symbolic Systems) > > Braun Music Center #129 > > Stanford University > > Stanford, CA 94305-3076, USA > > http://www.stanford.edu/~esfield/ > > > > > > > > > > > ----- Original Message ----- > From: Raffaele Viglianti > To: Music Encoding Initiative > Sent: Tue, 23 Jul 2013 12:14:26 -0700 (PDT) > Subject: Re: [MEI-L] Reconstructed parts > > Hi Micah, > > The debate around seems to keep going :) As it is defined now, > only deals with editorial "clarifications" of some text on a > source, either by correction, regularization, expansion. > This is in line with the TEI use of and I think it should stay > like this. > > Nonetheless, there seems to be a need for a more generic "alternative" > element, and it might be worth talking about this more and perhaps look at > TEI's (which, btw, is not widely used as far as I know) > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT. > > For your case, I'd suggest to more simply make full use of and > its attributes. > > > > > > > > > > This encodes strongly, as it were, that there are two different opinions > because of supplied/@resp. And it encodes weakly that they are exclusive > because of staff/@n. I wish there were a way to encode the exclusivity more > strongly, but I don't think there's a way of doing so without tag abuse at > the moment. > > Hope this helps, > Raffaele > > > > > On Tue, Jul 23, 2013 at 2:41 PM, Micah Walter wrote: > > > Hello, folks, > > > > I have a question about encoding reconstructed parts. The project I'm > > working on contains complete works that are missing entire parts, as two of > > the parts are contained in a second partbook that is now lost. > > > > Different reconstructions are of course possible, and so I'd like to use > > the tag. Is the following, then, a reasonable encoding? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > Micah Walter > > > > _______________________________________________ > > 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: From mwalter at haverford.edu Thu Jul 25 17:18:27 2013 From: mwalter at haverford.edu (Micah Walter) Date: Thu, 25 Jul 2013 11:18:27 -0400 Subject: [MEI-L] Reconstructed parts In-Reply-To: References: <511097838.2262229.1374625509450.JavaMail.root@stanford.edu> Message-ID: <854947E4-F820-4212-B774-3E3624D830B9@haverford.edu> Another idea: Would be a good way to clarify the purpose of the reading? Or is @type reserved for another use? -Micah On 24 July 2013, at 09:14, Raffaele Viglianti wrote: > Hi Perry, > > Good point, your solution makes perfect sense. I'm stuck with the idea that rdg = another physical source, but there's no need to be this strict, especially if @source and @resp can distinguish two different uses. So +1 to app/rdg for Micah's case. > > Raffaele > > > On Tue, Jul 23, 2013 at 10:25 PM, Roland, Perry (pdr4h) wrote: > Hello all, > > I believe this situation is addressed in section 12.3 of the TEI Guidelines, "Using Apparatus Elements in Transcriptions" (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCTR) -- > > "It is often desirable to record different transcriptions of one stretch of text. These variant transcriptions may be grouped within a single app element. An application may then construct different ?views? of the transcription by extraction of the appropriate variant readings from the apparatus elements embedded in the transcription." > > The example provided > > Virginite is grete > > perfectio > > > > > perfectio > un > > perfectiou > n > > > > isn't music, of course, but it's applicable to Micah's question. Because the elements have no @wit attribute (@source in MEI), they are not tied to a particular witness/source document. In other words, each of the readings here is a conjecture/reconstruction by the person identified as responsible (ES, FJF, and PGR). > > Applying this principle to Micah's example, we arrive at the following MEI markup -- > > > > > > > > > > > > > > > > > > Of course, this is only one method. There's nothing wrong with Raffaele's suggestion. But using in a transcriptional context is simple and keeps us from inventing more and more elements for smaller and smaller return. Since MEI permits within , this markup keeps us from having to repeat , which could lead to processing issues. Of course, there's no rule that says these different 'views' have to come from different people, so this markup also addresses Eleanor's example of multiple reconstructions by the same editor. > > -- > 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 Eleanor Selfridge-Field [esfield at stanford.edu] > Sent: Tuesday, July 23, 2013 8:25 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Reconstructed parts > > Hi, All, > > Micah is addressing an important need of musicologists, and it touches on an area that is probably irrelevant to TEI. I'm only perplexed about the word "choice". This is not about differing opinions. It could incur in a situation in which the editor proposes two or more realizations of lost material. (an important court case in France recently addressed this subject. The new material was understood to constitute new authorship, in contrast to the 1725 music otherwise present.) > > To be clear, one would have to say "proposed completion/realization." or something similar. Basso continuo realizations are similarly editorial creations. In both cases the added material is normally typeset in small notes, so unambiguous tags may do double duty in the future. > > Best regards, > > Eleanor Selfridge- Field > esfield at stanford.edu > > > > > > > > > xmlns:w="urn:schemas-microsoft-com:office:word" > xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" > xmlns="http://www.w3.org/TR/REC-html40"> > > /* Style Definitions */p.MsoNormal, p.MsoAutoSig, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt;}@page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;}div.WordSection1 {page:WordSection1;} > > > > > > Eleanor Selfridge-Field > > Consulting Professor, Music (and, by courtesy, Symbolic Systems) > > Braun Music Center #129 > > Stanford University > > Stanford, CA 94305-3076, USA > > http://www.stanford.edu/~esfield/ > > > > > > > > > > > ----- Original Message ----- > From: Raffaele Viglianti > To: Music Encoding Initiative > Sent: Tue, 23 Jul 2013 12:14:26 -0700 (PDT) > Subject: Re: [MEI-L] Reconstructed parts > > Hi Micah, > > The debate around seems to keep going :) As it is defined now, > only deals with editorial "clarifications" of some text on a > source, either by correction, regularization, expansion. > This is in line with the TEI use of and I think it should stay > like this. > > Nonetheless, there seems to be a need for a more generic "alternative" > element, and it might be worth talking about this more and perhaps look at > TEI's (which, btw, is not widely used as far as I know) > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT. > > For your case, I'd suggest to more simply make full use of and > its attributes. > > > > > > > > > > This encodes strongly, as it were, that there are two different opinions > because of supplied/@resp. And it encodes weakly that they are exclusive > because of staff/@n. I wish there were a way to encode the exclusivity more > strongly, but I don't think there's a way of doing so without tag abuse at > the moment. > > Hope this helps, > Raffaele > > > > > On Tue, Jul 23, 2013 at 2:41 PM, Micah Walter wrote: > > > Hello, folks, > > > > I have a question about encoding reconstructed parts. The project I'm > > working on contains complete works that are missing entire parts, as two of > > the parts are contained in a second partbook that is now lost. > > > > Different reconstructions are of course possible, and so I'd like to use > > the tag. Is the following, then, a reasonable encoding? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > Micah Walter > > > > _______________________________________________ > > 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: From pdr4h at eservices.virginia.edu Thu Jul 25 17:56:44 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 25 Jul 2013 15:56:44 +0000 Subject: [MEI-L] Reconstructed parts In-Reply-To: <854947E4-F820-4212-B774-3E3624D830B9@haverford.edu> References: <511097838.2262229.1374625509450.JavaMail.root@stanford.edu> , <854947E4-F820-4212-B774-3E3624D830B9@haverford.edu> Message-ID: Hi Micah, To quote the Guidelines, "@type characterizes the element in some sense, using any convenient classification scheme or typology." The attributes @type and @subtype provide a kind of ad hoc extension and restriction mechanism, so the values can be anything you want. Of course, the downside is you can't expect others to utilize the same values you've chosen. There's only one instance where @type is reserved -- on -- strictly to mimic TEI's use of @type is its element. -- 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 Micah Walter [mwalter at haverford.edu] Sent: Thursday, July 25, 2013 11:18 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Reconstructed parts Another idea: Would be a good way to clarify the purpose of the reading? Or is @type reserved for another use? -Micah On 24 July 2013, at 09:14, Raffaele Viglianti wrote: Hi Perry, Good point, your solution makes perfect sense. I'm stuck with the idea that rdg = another physical source, but there's no need to be this strict, especially if @source and @resp can distinguish two different uses. So +1 to app/rdg for Micah's case. Raffaele On Tue, Jul 23, 2013 at 10:25 PM, Roland, Perry (pdr4h) wrote: Hello all, I believe this situation is addressed in section 12.3 of the TEI Guidelines, "Using Apparatus Elements in Transcriptions" (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCTR) -- "It is often desirable to record different transcriptions of one stretch of text. These variant transcriptions may be grouped within a single app element. An application may then construct different ?views? of the transcription by extraction of the appropriate variant readings from the apparatus elements embedded in the transcription." The example provided Virginite is grete perfectio perfectio un perfectiou n isn't music, of course, but it's applicable to Micah's question. Because the elements have no @wit attribute (@source in MEI), they are not tied to a particular witness/source document. In other words, each of the readings here is a conjecture/reconstruction by the person identified as responsible (ES, FJF, and PGR). Applying this principle to Micah's example, we arrive at the following MEI markup -- Of course, this is only one method. There's nothing wrong with Raffaele's suggestion. But using in a transcriptional context is simple and keeps us from inventing more and more elements for smaller and smaller return. Since MEI permits within , this markup keeps us from having to repeat , which could lead to processing issues. Of course, there's no rule that says these different 'views' have to come from different people, so this markup also addresses Eleanor's example of multiple reconstructions by the same editor. -- 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 Eleanor Selfridge-Field [esfield at stanford.edu] Sent: Tuesday, July 23, 2013 8:25 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Reconstructed parts Hi, All, Micah is addressing an important need of musicologists, and it touches on an area that is probably irrelevant to TEI. I'm only perplexed about the word "choice". This is not about differing opinions. It could incur in a situation in which the editor proposes two or more realizations of lost material. (an important court case in France recently addressed this subject. The new material was understood to constitute new authorship, in contrast to the 1725 music otherwise present.) To be clear, one would have to say "proposed completion/realization." or something similar. Basso continuo realizations are similarly editorial creations. In both cases the added material is normally typeset in small notes, so unambiguous tags may do double duty in the future. Best regards, Eleanor Selfridge- Field esfield at stanford.edu /* Style Definitions */p.MsoNormal, p.MsoAutoSig, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt;}@page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;}div.WordSection1 {page:WordSection1;} Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ ----- Original Message ----- From: Raffaele Viglianti To: Music Encoding Initiative Sent: Tue, 23 Jul 2013 12:14:26 -0700 (PDT) Subject: Re: [MEI-L] Reconstructed parts Hi Micah, The debate around seems to keep going :) As it is defined now, only deals with editorial "clarifications" of some text on a source, either by correction, regularization, expansion. This is in line with the TEI use of and I think it should stay like this. Nonetheless, there seems to be a need for a more generic "alternative" element, and it might be worth talking about this more and perhaps look at TEI's (which, btw, is not widely used as far as I know) http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT. For your case, I'd suggest to more simply make full use of and its attributes. This encodes strongly, as it were, that there are two different opinions because of supplied/@resp. And it encodes weakly that they are exclusive because of staff/@n. I wish there were a way to encode the exclusivity more strongly, but I don't think there's a way of doing so without tag abuse at the moment. Hope this helps, Raffaele On Tue, Jul 23, 2013 at 2:41 PM, Micah Walter wrote: > Hello, folks, > > I have a question about encoding reconstructed parts. The project I'm > working on contains complete works that are missing entire parts, as two of > the parts are contained in a second partbook that is now lost. > > Different reconstructions are of course possible, and so I'd like to use > the tag. Is the following, then, a reasonable encoding? > > > > > > > > > > > > > > > > > > > Thanks, > Micah Walter > > _______________________________________________ > 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 Aug 4 07:11:18 2013 From: zupftom at googlemail.com (TW) Date: Sun, 4 Aug 2013 07:11:18 +0200 Subject: [MEI-L] Where to report customization service bugs? Message-ID: Hi all, would it make sense to report problems with the customization service via the Google Code issue tracker? The problem: When generating guidelines, the CSS files are missing and the image links point to the wrong directory (or the images are in the wrong directory, depending on what perspective you take). Have a nice Sunday! Thomas From kepper at edirom.de Sun Aug 4 11:07:21 2013 From: kepper at edirom.de (Johannes Kepper) Date: Sun, 4 Aug 2013 11:07:21 +0200 Subject: [MEI-L] Where to report customization service bugs? In-Reply-To: References: Message-ID: Hi Thomas, I admit that this is somewhat tricky. All references should be relative to the driver.xml file in the repository, but when checking the current situation, I just noticed that the CSS is not contained in the zip you get from custom.music-encoding.org. So the current behavior is definitely faulty, and you should report that an Google Code. However, we already planned to revise the service and integrate it better with the website itself. Looking at our current schedule, this won't happen before September, and even September is pretty dense already? You may have to be patient, or you could volunteer ;-) Best, Johannes Am 04.08.2013 um 07:11 schrieb TW: > Hi all, > > would it make sense to report problems with the customization service > via the Google Code issue tracker? > > The problem: When generating guidelines, the CSS files are missing > and the image links point to the wrong directory (or the images are in > the wrong directory, depending on what perspective you take). > > Have a nice Sunday! > Thomas > > _______________________________________________ > 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 Sun Aug 4 11:26:47 2013 From: roewenstrunk at edirom.de (=?iso-8859-1?Q?Daniel_R=F6wenstrunk?=) Date: Sun, 4 Aug 2013 11:26:47 +0200 Subject: [MEI-L] Where to report customization service bugs? In-Reply-To: References: Message-ID: <62AD8F91-EF50-408B-AC18-C60795697FEA@edirom.de> Hi Thomas, I'm not quite sure what plans Johannes is talking about? My plan with the service is to keep it most separate from other services and thus most flexible in regards of integration and use. I intend to publish the code on GitHub and so reporting errors at Google Code wouldn't be very helpful. Actually, I created a repository on GitHub just a second ago: https://github.com/Edirom/custoMEIzation (the code will follow soon?). So, please report the issue there. Greetings, Daniel Am 04.08.2013 um 11:07 schrieb Johannes Kepper : > Hi Thomas, > > I admit that this is somewhat tricky. All references should be relative to the driver.xml file in the repository, but when checking the current situation, I just noticed that the CSS is not contained in the zip you get from custom.music-encoding.org. So the current behavior is definitely faulty, and you should report that an Google Code. However, we already planned to revise the service and integrate it better with the website itself. Looking at our current schedule, this won't happen before September, and even September is pretty dense already? You may have to be patient, or you could volunteer ;-) > > Best, > Johannes > > > > > Am 04.08.2013 um 07:11 schrieb TW: > >> Hi all, >> >> would it make sense to report problems with the customization service >> via the Google Code issue tracker? >> >> The problem: When generating guidelines, the CSS files are missing >> and the image links point to the wrong directory (or the images are in >> the wrong directory, depending on what perspective you take). >> >> Have a nice Sunday! >> 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 -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 455 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From raffaeleviglianti at gmail.com Sun Aug 4 15:10:07 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Sun, 4 Aug 2013 09:10:07 -0400 Subject: [MEI-L] New TEI with MEI ODDs; projects; TEI MM meeting Message-ID: Dear all, I've updated the TEI with MEI ODDs and schemata to use the latest release of TEI (v.2.5.0) and MEI (2013). You can find them on GitHub: https://github.com/TEI-Music-SIG/tei-mei I'd also like to announce that the Music SIG is meeting at the TEI Members Meeting in Rome, on 3 October at 2.30pm. In preparation for this meeting I'm wondering if your project, or a project you know of, is: - encoding texts with music notation - using the TEI element - using any of the example ODDs If you do, please let me know either on or off list. Also, if you're planning on coming to the TEI members meeting in Rome in October and are considering joining the SIG meeting, or in general have other questions about TEI and music, please get in touch :) All the best, Raffaele -------------- next part -------------- An HTML attachment was scrubbed... URL: From zupftom at googlemail.com Sun Aug 4 17:25:41 2013 From: zupftom at googlemail.com (TW) Date: Sun, 4 Aug 2013 17:25:41 +0200 Subject: [MEI-L] Where to report customization service bugs? In-Reply-To: <62AD8F91-EF50-408B-AC18-C60795697FEA@edirom.de> References: <62AD8F91-EF50-408B-AC18-C60795697FEA@edirom.de> Message-ID: Hallo Daniel, before submitting the issue to the new repository: Is there a specific reason not to have the customization service code in the Google Code repository? Thomas 2013/8/4 Daniel R?wenstrunk : > Hi Thomas, > > I'm not quite sure what plans Johannes is talking about? My plan with the service is to keep it most separate from other services and thus most flexible in regards of integration and use. I intend to publish the code on GitHub and so reporting errors at Google Code wouldn't be very helpful. Actually, I created a repository on GitHub just a second ago: https://github.com/Edirom/custoMEIzation (the code will follow soon?). So, please report the issue there. > > Greetings, > Daniel > > > Am 04.08.2013 um 11:07 schrieb Johannes Kepper : > >> Hi Thomas, >> >> I admit that this is somewhat tricky. All references should be relative to the driver.xml file in the repository, but when checking the current situation, I just noticed that the CSS is not contained in the zip you get from custom.music-encoding.org. So the current behavior is definitely faulty, and you should report that an Google Code. However, we already planned to revise the service and integrate it better with the website itself. Looking at our current schedule, this won't happen before September, and even September is pretty dense already? You may have to be patient, or you could volunteer ;-) >> >> Best, >> Johannes >> >> >> >> >> Am 04.08.2013 um 07:11 schrieb TW: >> >>> Hi all, >>> >>> would it make sense to report problems with the customization service >>> via the Google Code issue tracker? >>> >>> The problem: When generating guidelines, the CSS files are missing >>> and the image links point to the wrong directory (or the images are in >>> the wrong directory, depending on what perspective you take). >>> >>> Have a nice Sunday! >>> 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 > From roewenstrunk at edirom.de Sun Aug 4 17:44:43 2013 From: roewenstrunk at edirom.de (=?windows-1252?Q?Daniel_R=F6wenstrunk?=) Date: Sun, 4 Aug 2013 17:44:43 +0200 Subject: [MEI-L] Where to report customization service bugs? In-Reply-To: References: <62AD8F91-EF50-408B-AC18-C60795697FEA@edirom.de> Message-ID: <7C6A1435-109A-4CF4-80EB-FB5B2458AB90@edirom.de> Let me ask you in return, what would be a good reason to have it in the Google Code repo and not on GitHub? Daniel Am 04.08.2013 um 17:25 schrieb TW : > Hallo Daniel, > > before submitting the issue to the new repository: Is there a > specific reason not to have the customization service code in the > Google Code repository? > > Thomas > > 2013/8/4 Daniel R?wenstrunk : >> Hi Thomas, >> >> I'm not quite sure what plans Johannes is talking about? My plan with the service is to keep it most separate from other services and thus most flexible in regards of integration and use. I intend to publish the code on GitHub and so reporting errors at Google Code wouldn't be very helpful. Actually, I created a repository on GitHub just a second ago: https://github.com/Edirom/custoMEIzation (the code will follow soon?). So, please report the issue there. >> >> Greetings, >> Daniel >> >> >> Am 04.08.2013 um 11:07 schrieb Johannes Kepper : >> >>> Hi Thomas, >>> >>> I admit that this is somewhat tricky. All references should be relative to the driver.xml file in the repository, but when checking the current situation, I just noticed that the CSS is not contained in the zip you get from custom.music-encoding.org. So the current behavior is definitely faulty, and you should report that an Google Code. However, we already planned to revise the service and integrate it better with the website itself. Looking at our current schedule, this won't happen before September, and even September is pretty dense already? You may have to be patient, or you could volunteer ;-) >>> >>> Best, >>> Johannes >>> >>> >>> >>> >>> Am 04.08.2013 um 07:11 schrieb TW: >>> >>>> Hi all, >>>> >>>> would it make sense to report problems with the customization service >>>> via the Google Code issue tracker? >>>> >>>> The problem: When generating guidelines, the CSS files are missing >>>> and the image links point to the wrong directory (or the images are in >>>> the wrong directory, depending on what perspective you take). >>>> >>>> Have a nice Sunday! >>>> 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 >> > > _______________________________________________ > 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 Aug 4 17:52:58 2013 From: zupftom at googlemail.com (TW) Date: Sun, 4 Aug 2013 17:52:58 +0200 Subject: [MEI-L] Where to report customization service bugs? In-Reply-To: <7C6A1435-109A-4CF4-80EB-FB5B2458AB90@edirom.de> References: <62AD8F91-EF50-408B-AC18-C60795697FEA@edirom.de> <7C6A1435-109A-4CF4-80EB-FB5B2458AB90@edirom.de> Message-ID: Good question ;-) My thought was that the tools directory might be a good place for the customization service, but on the other hand, a separate repository would make the Google Code repository less crowded. 2013/8/4 Daniel R?wenstrunk : > Let me ask you in return, what would be a good reason to have it in the Google Code repo and not on GitHub? > > Daniel > > > Am 04.08.2013 um 17:25 schrieb TW : > >> Hallo Daniel, >> >> before submitting the issue to the new repository: Is there a >> specific reason not to have the customization service code in the >> Google Code repository? >> >> Thomas >> >> 2013/8/4 Daniel R?wenstrunk : >>> Hi Thomas, >>> >>> I'm not quite sure what plans Johannes is talking about? My plan with the service is to keep it most separate from other services and thus most flexible in regards of integration and use. I intend to publish the code on GitHub and so reporting errors at Google Code wouldn't be very helpful. Actually, I created a repository on GitHub just a second ago: https://github.com/Edirom/custoMEIzation (the code will follow soon?). So, please report the issue there. >>> >>> Greetings, >>> Daniel >>> >>> >>> Am 04.08.2013 um 11:07 schrieb Johannes Kepper : >>> >>>> Hi Thomas, >>>> >>>> I admit that this is somewhat tricky. All references should be relative to the driver.xml file in the repository, but when checking the current situation, I just noticed that the CSS is not contained in the zip you get from custom.music-encoding.org. So the current behavior is definitely faulty, and you should report that an Google Code. However, we already planned to revise the service and integrate it better with the website itself. Looking at our current schedule, this won't happen before September, and even September is pretty dense already? You may have to be patient, or you could volunteer ;-) >>>> >>>> Best, >>>> Johannes >>>> >>>> >>>> >>>> >>>> Am 04.08.2013 um 07:11 schrieb TW: >>>> >>>>> Hi all, >>>>> >>>>> would it make sense to report problems with the customization service >>>>> via the Google Code issue tracker? >>>>> >>>>> The problem: When generating guidelines, the CSS files are missing >>>>> and the image links point to the wrong directory (or the images are in >>>>> the wrong directory, depending on what perspective you take). >>>>> >>>>> Have a nice Sunday! >>>>> 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 >>> >> >> _______________________________________________ >> 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 Sun Aug 4 18:27:41 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Sun, 4 Aug 2013 12:27:41 -0400 Subject: [MEI-L] Where to report customization service bugs? In-Reply-To: References: <62AD8F91-EF50-408B-AC18-C60795697FEA@edirom.de> <7C6A1435-109A-4CF4-80EB-FB5B2458AB90@edirom.de> Message-ID: +1 to having separate tool in separate GitHub repo. Makes it somewhat easier to contribute to :) Raffaele On Sun, Aug 4, 2013 at 11:52 AM, TW wrote: > Good question ;-) My thought was that the tools directory might be a > good place for the customization service, but on the other hand, a > separate repository would make the Google Code repository less > crowded. > > 2013/8/4 Daniel R?wenstrunk : > > Let me ask you in return, what would be a good reason to have it in the > Google Code repo and not on GitHub? > > > > Daniel > > > > > > Am 04.08.2013 um 17:25 schrieb TW : > > > >> Hallo Daniel, > >> > >> before submitting the issue to the new repository: Is there a > >> specific reason not to have the customization service code in the > >> Google Code repository? > >> > >> Thomas > >> > >> 2013/8/4 Daniel R?wenstrunk : > >>> Hi Thomas, > >>> > >>> I'm not quite sure what plans Johannes is talking about? My plan with > the service is to keep it most separate from other services and thus most > flexible in regards of integration and use. I intend to publish the code on > GitHub and so reporting errors at Google Code wouldn't be very helpful. > Actually, I created a repository on GitHub just a second ago: > https://github.com/Edirom/custoMEIzation (the code will follow soon?). > So, please report the issue there. > >>> > >>> Greetings, > >>> Daniel > >>> > >>> > >>> Am 04.08.2013 um 11:07 schrieb Johannes Kepper : > >>> > >>>> Hi Thomas, > >>>> > >>>> I admit that this is somewhat tricky. All references should be > relative to the driver.xml file in the repository, but when checking the > current situation, I just noticed that the CSS is not contained in the zip > you get from custom.music-encoding.org. So the current behavior is > definitely faulty, and you should report that an Google Code. However, we > already planned to revise the service and integrate it better with the > website itself. Looking at our current schedule, this won't happen before > September, and even September is pretty dense already? You may have to be > patient, or you could volunteer ;-) > >>>> > >>>> Best, > >>>> Johannes > >>>> > >>>> > >>>> > >>>> > >>>> Am 04.08.2013 um 07:11 schrieb TW: > >>>> > >>>>> Hi all, > >>>>> > >>>>> would it make sense to report problems with the customization service > >>>>> via the Google Code issue tracker? > >>>>> > >>>>> The problem: When generating guidelines, the CSS files are missing > >>>>> and the image links point to the wrong directory (or the images are > in > >>>>> the wrong directory, depending on what perspective you take). > >>>>> > >>>>> Have a nice Sunday! > >>>>> 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 > >>> > >> > >> _______________________________________________ > >> 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: From zupftom at googlemail.com Sun Aug 4 18:57:52 2013 From: zupftom at googlemail.com (TW) Date: Sun, 4 Aug 2013 18:57:52 +0200 Subject: [MEI-L] Where to report customization service bugs? In-Reply-To: References: <62AD8F91-EF50-408B-AC18-C60795697FEA@edirom.de> <7C6A1435-109A-4CF4-80EB-FB5B2458AB90@edirom.de> Message-ID: Reported the issues to the GitHub repo, but there's no code there yet. 2013/8/4 Raffaele Viglianti : > +1 to having separate tool in separate GitHub repo. Makes it somewhat easier > to contribute to :) > > Raffaele > > > On Sun, Aug 4, 2013 at 11:52 AM, TW wrote: >> >> Good question ;-) My thought was that the tools directory might be a >> good place for the customization service, but on the other hand, a >> separate repository would make the Google Code repository less >> crowded. >> >> 2013/8/4 Daniel R?wenstrunk : >> > Let me ask you in return, what would be a good reason to have it in the >> > Google Code repo and not on GitHub? >> > >> > Daniel >> > >> > >> > Am 04.08.2013 um 17:25 schrieb TW : >> > >> >> Hallo Daniel, >> >> >> >> before submitting the issue to the new repository: Is there a >> >> specific reason not to have the customization service code in the >> >> Google Code repository? >> >> >> >> Thomas >> >> >> >> 2013/8/4 Daniel R?wenstrunk : >> >>> Hi Thomas, >> >>> >> >>> I'm not quite sure what plans Johannes is talking about? My plan with >> >>> the service is to keep it most separate from other services and thus most >> >>> flexible in regards of integration and use. I intend to publish the code on >> >>> GitHub and so reporting errors at Google Code wouldn't be very helpful. >> >>> Actually, I created a repository on GitHub just a second ago: >> >>> https://github.com/Edirom/custoMEIzation (the code will follow soon?). So, >> >>> please report the issue there. >> >>> >> >>> Greetings, >> >>> Daniel >> >>> >> >>> >> >>> Am 04.08.2013 um 11:07 schrieb Johannes Kepper : >> >>> >> >>>> Hi Thomas, >> >>>> >> >>>> I admit that this is somewhat tricky. All references should be >> >>>> relative to the driver.xml file in the repository, but when checking the >> >>>> current situation, I just noticed that the CSS is not contained in the zip >> >>>> you get from custom.music-encoding.org. So the current behavior is >> >>>> definitely faulty, and you should report that an Google Code. However, we >> >>>> already planned to revise the service and integrate it better with the >> >>>> website itself. Looking at our current schedule, this won't happen before >> >>>> September, and even September is pretty dense already? You may have to be >> >>>> patient, or you could volunteer ;-) >> >>>> >> >>>> Best, >> >>>> Johannes >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Am 04.08.2013 um 07:11 schrieb TW: >> >>>> >> >>>>> Hi all, >> >>>>> >> >>>>> would it make sense to report problems with the customization >> >>>>> service >> >>>>> via the Google Code issue tracker? >> >>>>> >> >>>>> The problem: When generating guidelines, the CSS files are missing >> >>>>> and the image links point to the wrong directory (or the images are >> >>>>> in >> >>>>> the wrong directory, depending on what perspective you take). >> >>>>> >> >>>>> Have a nice Sunday! >> >>>>> 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 >> >>> >> >> >> >> _______________________________________________ >> >> 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 Wed Aug 7 11:58:11 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 7 Aug 2013 11:58:11 +0200 Subject: [MEI-L] typable events Message-ID: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> Dear List, I have some issues I've found recently that I would like to discuss. Let's start with a question about typable events. In current MEI, it is not possible to use @type (att.tybable) on all events (model.eventLike), such as notes, rests, chords, spaces, tuplets, bTrems etc. I wonder if this is intention, or if we just missed to add that class. Even if it was our intention (though I haven't found a former discussion on this), what were the arguments, and do we still think this is a necessary restriction? The following sample may be skipped for brevity? > My example for this is somewhat questionable in itself, so let me explain it a bit. For our Freisch?tz edition, we're heading off with Finale data converted to MEI via MusicXML. In the case of multiple layers on one staff, Finale clips shared events at the end of the second (and any subsequent) layer: If both layers share a rest at the end, only the first layer holds this rest, while the second is just incomplete. > > For several reasons, I think this is faulty behavior, and therefore add corresponding spaces by XSLT. However, I would like to keep track which spaces were contained in the original file, and which spaces were added by me. A simple @type on the latter would be perfect for me. > > I am fully aware that MEI offers a whole plethora of elements to indicate added, normalized, or otherwise changed content. But since this is just an intermediate step in the process of generating my data, I regard this additional markup as too complicated. I'm not sure if I will keep this information after the next step of proofreading. On the other hand, I don't want to operate on invalid data, even if it is only a temporary state. I'm pretty sure there are simpler examples and better arguments at hand, but I hope my example makes the point. So, what do others say ? should events like notes and rests be typable? Best, Johannes From zupftom at googlemail.com Wed Aug 7 13:03:16 2013 From: zupftom at googlemail.com (TW) Date: Wed, 7 Aug 2013 13:03:16 +0200 Subject: [MEI-L] typable events In-Reply-To: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> Message-ID: My favourite attribute to abuse for temporary solutions that should not result in invalid MEI is @label as it's available almost everywhere. (Kristina can tell you a thing or two about that.) 2013/8/7 Johannes Kepper : > Dear List, > > I have some issues I've found recently that I would like to discuss. Let's start with a question about typable events. In current MEI, it is not possible to use @type (att.tybable) on all events (model.eventLike), such as notes, rests, chords, spaces, tuplets, bTrems etc. > I wonder if this is intention, or if we just missed to add that class. Even if it was our intention (though I haven't found a former discussion on this), what were the arguments, and do we still think this is a necessary restriction? > > The following sample may be skipped for brevity? >> My example for this is somewhat questionable in itself, so let me explain it a bit. For our Freisch?tz edition, we're heading off with Finale data converted to MEI via MusicXML. In the case of multiple layers on one staff, Finale clips shared events at the end of the second (and any subsequent) layer: If both layers share a rest at the end, only the first layer holds this rest, while the second is just incomplete. >> >> For several reasons, I think this is faulty behavior, and therefore add corresponding spaces by XSLT. However, I would like to keep track which spaces were contained in the original file, and which spaces were added by me. A simple @type on the latter would be perfect for me. >> >> I am fully aware that MEI offers a whole plethora of elements to indicate added, normalized, or otherwise changed content. But since this is just an intermediate step in the process of generating my data, I regard this additional markup as too complicated. I'm not sure if I will keep this information after the next step of proofreading. On the other hand, I don't want to operate on invalid data, even if it is only a temporary state. > > I'm pretty sure there are simpler examples and better arguments at hand, but I hope my example makes the point. So, what do others say ? should events like notes and rests be typable? > > Best, > 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 Aug 7 13:07:57 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 7 Aug 2013 13:07:57 +0200 Subject: [MEI-L] typable events In-Reply-To: References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> Message-ID: <97E89245-E33A-438A-934B-52E634C35567@edirom.de> Hi Thomas, thanks for pointing that out. This solution seems to be too temporary to me, I would like to have something more stable. Also, I'm actually using both @type and @subtype. But this is just about my example ? what's your take on the availability of @type on events in general? jo Am 07.08.2013 um 13:03 schrieb TW : > My favourite attribute to abuse for temporary solutions that should > not result in invalid MEI is @label as it's available almost > everywhere. (Kristina can tell you a thing or two about that.) > > 2013/8/7 Johannes Kepper : >> Dear List, >> >> I have some issues I've found recently that I would like to discuss. Let's start with a question about typable events. In current MEI, it is not possible to use @type (att.tybable) on all events (model.eventLike), such as notes, rests, chords, spaces, tuplets, bTrems etc. >> I wonder if this is intention, or if we just missed to add that class. Even if it was our intention (though I haven't found a former discussion on this), what were the arguments, and do we still think this is a necessary restriction? >> >> The following sample may be skipped for brevity? >>> My example for this is somewhat questionable in itself, so let me explain it a bit. For our Freisch?tz edition, we're heading off with Finale data converted to MEI via MusicXML. In the case of multiple layers on one staff, Finale clips shared events at the end of the second (and any subsequent) layer: If both layers share a rest at the end, only the first layer holds this rest, while the second is just incomplete. >>> >>> For several reasons, I think this is faulty behavior, and therefore add corresponding spaces by XSLT. However, I would like to keep track which spaces were contained in the original file, and which spaces were added by me. A simple @type on the latter would be perfect for me. >>> >>> I am fully aware that MEI offers a whole plethora of elements to indicate added, normalized, or otherwise changed content. But since this is just an intermediate step in the process of generating my data, I regard this additional markup as too complicated. I'm not sure if I will keep this information after the next step of proofreading. On the other hand, I don't want to operate on invalid data, even if it is only a temporary state. >> >> I'm pretty sure there are simpler examples and better arguments at hand, but I hope my example makes the point. So, what do others say ? should events like notes and rests be typable? >> >> Best, >> 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 andrew.hankinson at mail.mcgill.ca Wed Aug 7 13:46:13 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 7 Aug 2013 11:46:13 +0000 Subject: [MEI-L] typable events In-Reply-To: <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> Message-ID: The only thing I have to add here is from an old discussion Perry and I had a while back. I just remembered it when reading through Johannes' e-mail, so I'll reproduce it here: > ? I think it's good practice to use @type to indicate the *classification of the element itself, not its contents.* For example, Perry Roland as opposed to Perry Roland. The first seems to me like a good use of @type -- it classifies the name, not Perry Roland. Down the second path is ruin and death. :) In the case of the example Johannes provided, I'm unclear what the problem is. Is it that you can't do ""? This seems a strange way of marking it up, especially since we have quite extensive functionality for editorial additions. Couldn't it be: ? -Andrew On 2013-08-07, at 1:07 PM, Johannes Kepper wrote: > Hi Thomas, > > thanks for pointing that out. This solution seems to be too temporary to me, I would like to have something more stable. Also, I'm actually using both @type and @subtype. But this is just about my example ? what's your take on the availability of @type on events in general? > > jo > > > > Am 07.08.2013 um 13:03 schrieb TW : > >> My favourite attribute to abuse for temporary solutions that should >> not result in invalid MEI is @label as it's available almost >> everywhere. (Kristina can tell you a thing or two about that.) >> >> 2013/8/7 Johannes Kepper : >>> Dear List, >>> >>> I have some issues I've found recently that I would like to discuss. Let's start with a question about typable events. In current MEI, it is not possible to use @type (att.tybable) on all events (model.eventLike), such as notes, rests, chords, spaces, tuplets, bTrems etc. >>> I wonder if this is intention, or if we just missed to add that class. Even if it was our intention (though I haven't found a former discussion on this), what were the arguments, and do we still think this is a necessary restriction? >>> >>> The following sample may be skipped for brevity? >>>> My example for this is somewhat questionable in itself, so let me explain it a bit. For our Freisch?tz edition, we're heading off with Finale data converted to MEI via MusicXML. In the case of multiple layers on one staff, Finale clips shared events at the end of the second (and any subsequent) layer: If both layers share a rest at the end, only the first layer holds this rest, while the second is just incomplete. >>>> >>>> For several reasons, I think this is faulty behavior, and therefore add corresponding spaces by XSLT. However, I would like to keep track which spaces were contained in the original file, and which spaces were added by me. A simple @type on the latter would be perfect for me. >>>> >>>> I am fully aware that MEI offers a whole plethora of elements to indicate added, normalized, or otherwise changed content. But since this is just an intermediate step in the process of generating my data, I regard this additional markup as too complicated. I'm not sure if I will keep this information after the next step of proofreading. On the other hand, I don't want to operate on invalid data, even if it is only a temporary state. >>> >>> I'm pretty sure there are simpler examples and better arguments at hand, but I hope my example makes the point. So, what do others say ? should events like notes and rests be typable? >>> >>> Best, >>> 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 raffaeleviglianti at gmail.com Wed Aug 7 15:18:11 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Wed, 7 Aug 2013 09:18:11 -0400 Subject: [MEI-L] typable events In-Reply-To: References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> Message-ID: This also seems a bit forced to me. The datatype for att.typed is too free, with good reason sometimes, but in this context it would be too misleading without a better specified taxonomy. Andrew's solution is much more expressive and understandable by any MEI application than a type value that is not in the schema and is understandable by your application only. Raffaele On Wed, Aug 7, 2013 at 7:46 AM, Andrew Hankinson < andrew.hankinson at mail.mcgill.ca> wrote: > The only thing I have to add here is from an old discussion Perry and I > had a while back. I just remembered it when reading through Johannes' > e-mail, so I'll reproduce it here: > > > ? I think it's good practice to use @type to indicate the > *classification of the element itself, not its contents.* For example, > Perry Roland as opposed to type="composer">Perry Roland. The first seems to me like a good use > of @type -- it classifies the name, not Perry Roland. Down the second path > is ruin and death. :) > > In the case of the example Johannes provided, I'm unclear what the problem > is. Is it that you can't do ""? This seems a > strange way of marking it up, especially since we have quite extensive > functionality for editorial additions. > > Couldn't it be: > > > ? > > > > > > -Andrew > > On 2013-08-07, at 1:07 PM, Johannes Kepper > wrote: > > > Hi Thomas, > > > > thanks for pointing that out. This solution seems to be too temporary to > me, I would like to have something more stable. Also, I'm actually using > both @type and @subtype. But this is just about my example ? what's your > take on the availability of @type on events in general? > > > > jo > > > > > > > > Am 07.08.2013 um 13:03 schrieb TW : > > > >> My favourite attribute to abuse for temporary solutions that should > >> not result in invalid MEI is @label as it's available almost > >> everywhere. (Kristina can tell you a thing or two about that.) > >> > >> 2013/8/7 Johannes Kepper : > >>> Dear List, > >>> > >>> I have some issues I've found recently that I would like to discuss. > Let's start with a question about typable events. In current MEI, it is not > possible to use @type (att.tybable) on all events (model.eventLike), such > as notes, rests, chords, spaces, tuplets, bTrems etc. > >>> I wonder if this is intention, or if we just missed to add that class. > Even if it was our intention (though I haven't found a former discussion on > this), what were the arguments, and do we still think this is a necessary > restriction? > >>> > >>> The following sample may be skipped for brevity? > >>>> My example for this is somewhat questionable in itself, so let me > explain it a bit. For our Freisch?tz edition, we're heading off with Finale > data converted to MEI via MusicXML. In the case of multiple layers on one > staff, Finale clips shared events at the end of the second (and any > subsequent) layer: If both layers share a rest at the end, only the first > layer holds this rest, while the second is just incomplete. > >>>> > >>>> For several reasons, I think this is faulty behavior, and therefore > add corresponding spaces by XSLT. However, I would like to keep track which > spaces were contained in the original file, and which spaces were added by > me. A simple @type on the latter would be perfect for me. > >>>> > >>>> I am fully aware that MEI offers a whole plethora of elements to > indicate added, normalized, or otherwise changed content. But since this is > just an intermediate step in the process of generating my data, I regard > this additional markup as too complicated. I'm not sure if I will keep this > information after the next step of proofreading. On the other hand, I don't > want to operate on invalid data, even if it is only a temporary state. > >>> > >>> I'm pretty sure there are simpler examples and better arguments at > hand, but I hope my example makes the point. So, what do others say ? > should events like notes and rests be typable? > >>> > >>> Best, > >>> 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 > > > _______________________________________________ > 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: From kepper at edirom.de Wed Aug 7 15:39:05 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 7 Aug 2013 15:39:05 +0200 Subject: [MEI-L] typable events In-Reply-To: References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> Message-ID: Hi Andrew, my actual example is which could be encoded as While this is absolutely possible, it complicates intermediate steps a bit, since I already have to deal with editorial markup then. Remember, this is only temporary data that I won't publish, and that I don't regard as ready yet. However, it is a state that will be submitted to my repository, and will thus be visible to others. If it was a more stable state, I would certainly take the approach, but in the end, this will just result in a couple of sentences in the documentation. For now, all I want to achieve is to get an indicator where I have to look during proofreading. The benefit of the attribute-only solution is that I can just strip the attribute when I'm done, assuming I have made my changes where necessary beforehand. But again, you're discussing my example, which I already announced as being questionable. I'm deeply sorry that I didn't come up with a better one, but I had none in mind. Without having a better one by now, I suspect that in most situations where one would add @type to events, MEI would allow an alternative using editorial markup. But still, I wonder if we shouldn't allow @type on events. It would be easier for me to follow your arguments if you would address this question as well, not just my ill-considered example? Thanks, jo Am 07.08.2013 um 13:46 schrieb Andrew Hankinson : > The only thing I have to add here is from an old discussion Perry and I had a while back. I just remembered it when reading through Johannes' e-mail, so I'll reproduce it here: > >> ? I think it's good practice to use @type to indicate the *classification of the element itself, not its contents.* For example, Perry Roland as opposed to Perry Roland. The first seems to me like a good use of @type -- it classifies the name, not Perry Roland. Down the second path is ruin and death. :) > > In the case of the example Johannes provided, I'm unclear what the problem is. Is it that you can't do ""? This seems a strange way of marking it up, especially since we have quite extensive functionality for editorial additions. > > Couldn't it be: > > > ? > > > > > > -Andrew > > On 2013-08-07, at 1:07 PM, Johannes Kepper > wrote: > >> Hi Thomas, >> >> thanks for pointing that out. This solution seems to be too temporary to me, I would like to have something more stable. Also, I'm actually using both @type and @subtype. But this is just about my example ? what's your take on the availability of @type on events in general? >> >> jo >> >> >> >> Am 07.08.2013 um 13:03 schrieb TW : >> >>> My favourite attribute to abuse for temporary solutions that should >>> not result in invalid MEI is @label as it's available almost >>> everywhere. (Kristina can tell you a thing or two about that.) >>> >>> 2013/8/7 Johannes Kepper : >>>> Dear List, >>>> >>>> I have some issues I've found recently that I would like to discuss. Let's start with a question about typable events. In current MEI, it is not possible to use @type (att.tybable) on all events (model.eventLike), such as notes, rests, chords, spaces, tuplets, bTrems etc. >>>> I wonder if this is intention, or if we just missed to add that class. Even if it was our intention (though I haven't found a former discussion on this), what were the arguments, and do we still think this is a necessary restriction? >>>> >>>> The following sample may be skipped for brevity? >>>>> My example for this is somewhat questionable in itself, so let me explain it a bit. For our Freisch?tz edition, we're heading off with Finale data converted to MEI via MusicXML. In the case of multiple layers on one staff, Finale clips shared events at the end of the second (and any subsequent) layer: If both layers share a rest at the end, only the first layer holds this rest, while the second is just incomplete. >>>>> >>>>> For several reasons, I think this is faulty behavior, and therefore add corresponding spaces by XSLT. However, I would like to keep track which spaces were contained in the original file, and which spaces were added by me. A simple @type on the latter would be perfect for me. >>>>> >>>>> I am fully aware that MEI offers a whole plethora of elements to indicate added, normalized, or otherwise changed content. But since this is just an intermediate step in the process of generating my data, I regard this additional markup as too complicated. I'm not sure if I will keep this information after the next step of proofreading. On the other hand, I don't want to operate on invalid data, even if it is only a temporary state. >>>> >>>> I'm pretty sure there are simpler examples and better arguments at hand, but I hope my example makes the point. So, what do others say ? should events like notes and rests be typable? >>>> >>>> Best, >>>> 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 > > > _______________________________________________ > 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 Aug 7 16:08:15 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 7 Aug 2013 14:08:15 +0000 Subject: [MEI-L] typable events In-Reply-To: <29913_1375882794_52024E28_29913_175_1_EC508459-C132-4A60-B0A7-E7B8DF21873D@edirom.de> References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> <29913_1375882794_52024E28_29913_175_1_EC508459-C132-4A60-B0A7-E7B8DF21873D@edirom.de> Message-ID: Oh, I wasn't making any particular argument -- just trying to understand your need. The phrase that I copied from Perry seemed to suggest that @type should be used to typify the element, not the use or context. So "" (to make up an example) might be OK, whereas '' seems weird, since you're typifying the use and context of the element, not the element itself. I have no problem with @type on events, per se, but since "type" is such a loose concept I think that would open it up for abuse for people trying to do "quick and dirty" encoding. Should we consider or to be "good" MEI? Hopefully not, but I think it would be the kind of thing that would be a tempting solution when you're not an expert encoder. Leaving @type off of them may indeed be an oversight, but maybe we don't want to go too crazy with @type in favour of more expressive markup. If it's just temporary, and you just want an attribute that you can abuse for a transitional file, why not do as Thomas suggested and put it in @label, perhaps with a fixed formatting that you can process later: You could then split on the hyphens in any @label and have your layer, event, and reason all in one easy-to-chew package. :) Alternately, you can do it another way and store a list of IDs in a separate plain text file or CSV, which you can then use later when processing it. -Andrew On 2013-08-07, at 3:39 PM, Johannes Kepper wrote: > Hi Andrew, > > my actual example is > > > > which could be encoded as > > > > > > > While this is absolutely possible, it complicates intermediate steps a bit, since I already have to deal with editorial markup then. Remember, this is only temporary data that I won't publish, and that I don't regard as ready yet. However, it is a state that will be submitted to my repository, and will thus be visible to others. If it was a more stable state, I would certainly take the approach, but in the end, this will just result in a couple of sentences in the documentation. For now, all I want to achieve is to get an indicator where I have to look during proofreading. The benefit of the attribute-only solution is that I can just strip the attribute when I'm done, assuming I have made my changes where necessary beforehand. > > But again, you're discussing my example, which I already announced as being questionable. I'm deeply sorry that I didn't come up with a better one, but I had none in mind. Without having a better one by now, I suspect that in most situations where one would add @type to events, MEI would allow an alternative using editorial markup. But still, I wonder if we shouldn't allow @type on events. > > It would be easier for me to follow your arguments if you would address this question as well, not just my ill-considered example? > > Thanks, > jo > > > > > > Am 07.08.2013 um 13:46 schrieb Andrew Hankinson : > >> The only thing I have to add here is from an old discussion Perry and I had a while back. I just remembered it when reading through Johannes' e-mail, so I'll reproduce it here: >> >>> ? I think it's good practice to use @type to indicate the *classification of the element itself, not its contents.* For example, Perry Roland as opposed to Perry Roland. The first seems to me like a good use of @type -- it classifies the name, not Perry Roland. Down the second path is ruin and death. :) >> >> In the case of the example Johannes provided, I'm unclear what the problem is. Is it that you can't do ""? This seems a strange way of marking it up, especially since we have quite extensive functionality for editorial additions. >> >> Couldn't it be: >> >> >> ? >> >> >> >> >> >> -Andrew >> >> On 2013-08-07, at 1:07 PM, Johannes Kepper >> wrote: >> >>> Hi Thomas, >>> >>> thanks for pointing that out. This solution seems to be too temporary to me, I would like to have something more stable. Also, I'm actually using both @type and @subtype. But this is just about my example ? what's your take on the availability of @type on events in general? >>> >>> jo >>> >>> >>> >>> Am 07.08.2013 um 13:03 schrieb TW : >>> >>>> My favourite attribute to abuse for temporary solutions that should >>>> not result in invalid MEI is @label as it's available almost >>>> everywhere. (Kristina can tell you a thing or two about that.) >>>> >>>> 2013/8/7 Johannes Kepper : >>>>> Dear List, >>>>> >>>>> I have some issues I've found recently that I would like to discuss. Let's start with a question about typable events. In current MEI, it is not possible to use @type (att.tybable) on all events (model.eventLike), such as notes, rests, chords, spaces, tuplets, bTrems etc. >>>>> I wonder if this is intention, or if we just missed to add that class. Even if it was our intention (though I haven't found a former discussion on this), what were the arguments, and do we still think this is a necessary restriction? >>>>> >>>>> The following sample may be skipped for brevity? >>>>>> My example for this is somewhat questionable in itself, so let me explain it a bit. For our Freisch?tz edition, we're heading off with Finale data converted to MEI via MusicXML. In the case of multiple layers on one staff, Finale clips shared events at the end of the second (and any subsequent) layer: If both layers share a rest at the end, only the first layer holds this rest, while the second is just incomplete. >>>>>> >>>>>> For several reasons, I think this is faulty behavior, and therefore add corresponding spaces by XSLT. However, I would like to keep track which spaces were contained in the original file, and which spaces were added by me. A simple @type on the latter would be perfect for me. >>>>>> >>>>>> I am fully aware that MEI offers a whole plethora of elements to indicate added, normalized, or otherwise changed content. But since this is just an intermediate step in the process of generating my data, I regard this additional markup as too complicated. I'm not sure if I will keep this information after the next step of proofreading. On the other hand, I don't want to operate on invalid data, even if it is only a temporary state. >>>>> >>>>> I'm pretty sure there are simpler examples and better arguments at hand, but I hope my example makes the point. So, what do others say ? should events like notes and rests be typable? >>>>> >>>>> Best, >>>>> 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 >> >> >> _______________________________________________ >> 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 Wed Aug 7 16:19:16 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 7 Aug 2013 16:19:16 +0200 Subject: [MEI-L] typable events In-Reply-To: References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> <29913_1375882794_52024E28_29913_175_1_EC508459-C132-4A60-B0A7-E7B8DF21873D@edirom.de> Message-ID: <6AD03340-8DD5-4285-B0C8-1508444CD03C@edirom.de> Hi Andrew, I wasn't complaining about your argumentation, not at all :-) Actually, when I set that up, I didn't think about it much. It was just today when I noticed that it doesn't validate, and I wondered why that is. I totally agree that the current state is, say, less than ideal? I see your point about inviting abuse when making @type more general available, and I guess I'm willing to follow that argument. However, I'm less convinced that @label is actually a better solution for my needs. Since I'm saying something _about_ my MEI, I wonder if an attribute in a private namespace might be an option? This would break validity (unless I change my MEI accordingly), but it would be clearly something said from "outside", without pretending to be my final MEI? Opinions? jo Am 07.08.2013 um 16:08 schrieb Andrew Hankinson : > Oh, I wasn't making any particular argument -- just trying to understand your need. > > The phrase that I copied from Perry seemed to suggest that @type should be used to typify the element, not the use or context. So "" (to make up an example) might be OK, whereas '' seems weird, since you're typifying the use and context of the element, not the element itself. > > I have no problem with @type on events, per se, but since "type" is such a loose concept I think that would open it up for abuse for people trying to do "quick and dirty" encoding. Should we consider or to be "good" MEI? Hopefully not, but I think it would be the kind of thing that would be a tempting solution when you're not an expert encoder. > > Leaving @type off of them may indeed be an oversight, but maybe we don't want to go too crazy with @type in favour of more expressive markup. > > If it's just temporary, and you just want an attribute that you can abuse for a transitional file, why not do as Thomas suggested and put it in @label, perhaps with a fixed formatting that you can process later: > > > > You could then split on the hyphens in any @label and have your layer, event, and reason all in one easy-to-chew package. :) > > Alternately, you can do it another way and store a list of IDs in a separate plain text file or CSV, which you can then use later when processing it. > > -Andrew > > On 2013-08-07, at 3:39 PM, Johannes Kepper > wrote: > >> Hi Andrew, >> >> my actual example is >> >> >> >> which could be encoded as >> >> >> >> >> >> >> While this is absolutely possible, it complicates intermediate steps a bit, since I already have to deal with editorial markup then. Remember, this is only temporary data that I won't publish, and that I don't regard as ready yet. However, it is a state that will be submitted to my repository, and will thus be visible to others. If it was a more stable state, I would certainly take the approach, but in the end, this will just result in a couple of sentences in the documentation. For now, all I want to achieve is to get an indicator where I have to look during proofreading. The benefit of the attribute-only solution is that I can just strip the attribute when I'm done, assuming I have made my changes where necessary beforehand. >> >> But again, you're discussing my example, which I already announced as being questionable. I'm deeply sorry that I didn't come up with a better one, but I had none in mind. Without having a better one by now, I suspect that in most situations where one would add @type to events, MEI would allow an alternative using editorial markup. But still, I wonder if we shouldn't allow @type on events. >> >> It would be easier for me to follow your arguments if you would address this question as well, not just my ill-considered example? >> >> Thanks, >> jo >> >> >> >> >> >> Am 07.08.2013 um 13:46 schrieb Andrew Hankinson : >> >>> The only thing I have to add here is from an old discussion Perry and I had a while back. I just remembered it when reading through Johannes' e-mail, so I'll reproduce it here: >>> >>>> ? I think it's good practice to use @type to indicate the *classification of the element itself, not its contents.* For example, Perry Roland as opposed to Perry Roland. The first seems to me like a good use of @type -- it classifies the name, not Perry Roland. Down the second path is ruin and death. :) >>> >>> In the case of the example Johannes provided, I'm unclear what the problem is. Is it that you can't do ""? This seems a strange way of marking it up, especially since we have quite extensive functionality for editorial additions. >>> >>> Couldn't it be: >>> >>> >>> ? >>> >>> >>> >>> >>> >>> -Andrew >>> >>> On 2013-08-07, at 1:07 PM, Johannes Kepper >>> wrote: >>> >>>> Hi Thomas, >>>> >>>> thanks for pointing that out. This solution seems to be too temporary to me, I would like to have something more stable. Also, I'm actually using both @type and @subtype. But this is just about my example ? what's your take on the availability of @type on events in general? >>>> >>>> jo >>>> >>>> >>>> >>>> Am 07.08.2013 um 13:03 schrieb TW : >>>> >>>>> My favourite attribute to abuse for temporary solutions that should >>>>> not result in invalid MEI is @label as it's available almost >>>>> everywhere. (Kristina can tell you a thing or two about that.) >>>>> >>>>> 2013/8/7 Johannes Kepper : >>>>>> Dear List, >>>>>> >>>>>> I have some issues I've found recently that I would like to discuss. Let's start with a question about typable events. In current MEI, it is not possible to use @type (att.tybable) on all events (model.eventLike), such as notes, rests, chords, spaces, tuplets, bTrems etc. >>>>>> I wonder if this is intention, or if we just missed to add that class. Even if it was our intention (though I haven't found a former discussion on this), what were the arguments, and do we still think this is a necessary restriction? >>>>>> >>>>>> The following sample may be skipped for brevity? >>>>>>> My example for this is somewhat questionable in itself, so let me explain it a bit. For our Freisch?tz edition, we're heading off with Finale data converted to MEI via MusicXML. In the case of multiple layers on one staff, Finale clips shared events at the end of the second (and any subsequent) layer: If both layers share a rest at the end, only the first layer holds this rest, while the second is just incomplete. >>>>>>> >>>>>>> For several reasons, I think this is faulty behavior, and therefore add corresponding spaces by XSLT. However, I would like to keep track which spaces were contained in the original file, and which spaces were added by me. A simple @type on the latter would be perfect for me. >>>>>>> >>>>>>> I am fully aware that MEI offers a whole plethora of elements to indicate added, normalized, or otherwise changed content. But since this is just an intermediate step in the process of generating my data, I regard this additional markup as too complicated. I'm not sure if I will keep this information after the next step of proofreading. On the other hand, I don't want to operate on invalid data, even if it is only a temporary state. >>>>>> >>>>>> I'm pretty sure there are simpler examples and better arguments at hand, but I hope my example makes the point. So, what do others say ? should events like notes and rests be typable? >>>>>> >>>>>> Best, >>>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 donbyrd at indiana.edu Wed Aug 7 16:35:14 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Wed, 07 Aug 2013 10:35:14 -0400 Subject: [MEI-L] typable events In-Reply-To: <6AD03340-8DD5-4285-B0C8-1508444CD03C@edirom.de> References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> <29913_1375882794_52024E28_29913_175_1_EC508459-C132-4A60-B0A7-E7B8DF21873D@edirom.de> <6AD03340-8DD5-4285-B0C8-1508444CD03C@edirom.de> Message-ID: <20130807103514.sbagghceo8cgg0sg@webmail.iu.edu> Disclaimer: this is a hasty comment from someone who hasn't been following the details of the discussion :-| . Ahem. Using an attribute in a private namespace seems like exactly what you want. If anything, breaking validity unless you change your def. of MEI sounds like an advantage, since then if you fail to clean up your intermediate code properly, anyone running against standard MEI would likely find that out very quickly. --Don On Wed, 7 Aug 2013 16:19:16 +0200, Johannes Kepper wrote: > Hi Andrew, > > I wasn't complaining about your argumentation, not at all :-) > > Actually, when I set that up, I didn't think about it much. It was > just today when I noticed that it doesn't validate, and I wondered > why that is. I totally agree that the current state is, say, less > than ideal... I see your point about inviting abuse when making @type > more general available, and I guess I'm willing to follow that > argument. However, I'm less convinced that @label is actually a > better solution for my needs. Since I'm saying something _about_ my > MEI, I wonder if an attribute in a private namespace might be an > option? This would break validity (unless I change my MEI > accordingly), but it would be clearly something said from "outside", > without pretending to be my final MEI... > > Opinions? > jo > > > Am 07.08.2013 um 16:08 schrieb Andrew Hankinson > : > >> Oh, I wasn't making any particular argument -- just trying to >> understand your need. >> >> The phrase that I copied from Perry seemed to suggest that @type >> should be used to typify the element, not the use or context. So >> "" (to make up an example) might be OK, >> whereas '' seems weird, >> since you're typifying the use and context of the element, not the >> element itself. >> >> I have no problem with @type on events, per se, but since "type" is >> such a loose concept I think that would open it up for abuse for >> people trying to do "quick and dirty" encoding. Should we consider >> or to be "good" MEI? >> Hopefully not, but I think it would be the kind of thing that would >> be a tempting solution when you're not an expert encoder. >> >> Leaving @type off of them may indeed be an oversight, but maybe we >> don't want to go too crazy with @type in favour of more expressive >> markup. >> >> If it's just temporary, and you just want an attribute that you can >> abuse for a transitional file, why not do as Thomas suggested and >> put it in @label, perhaps with a fixed formatting that you can >> process later: >> >> >> >> You could then split on the hyphens in any @label and have your >> layer, event, and reason all in one easy-to-chew package. :) >> >> Alternately, you can do it another way and store a list of IDs in a >> separate plain text file or CSV, which you can then use later when >> processing it. >> >> -Andrew >> >> On 2013-08-07, at 3:39 PM, Johannes Kepper >> wrote: >> >>> Hi Andrew, >>> >>> my actual example is >>> >>> >> corresp="#d1e2682" dur="4"/> >>> >>> which could be encoded as >>> >>> >>> >>> >>> >>> >>> While this is absolutely possible, it complicates intermediate >>> steps a bit, since I already have to deal with editorial markup >>> then. Remember, this is only temporary data that I won't publish, >>> and that I don't regard as ready yet. However, it is a state that >>> will be submitted to my repository, and will thus be visible to >>> others. If it was a more stable state, I would certainly take the >>> approach, but in the end, this will just result in a >>> couple of sentences in the documentation. For now, all I want to >>> achieve is to get an indicator where I have to look during >>> proofreading. The benefit of the attribute-only solution is that I >>> can just strip the attribute when I'm done, assuming I have made my >>> changes where necessary beforehand. >>> >>> But again, you're discussing my example, which I already announced >>> as being questionable. I'm deeply sorry that I didn't come up with >>> a better one, but I had none in mind. Without having a better one >>> by now, I suspect that in most situations where one would add @type >>> to events, MEI would allow an alternative using editorial markup. >>> But still, I wonder if we shouldn't allow @type on events. >>> >>> It would be easier for me to follow your arguments if you would >>> address this question as well, not just my ill-considered example... >>> >>> Thanks, >>> jo >>> >>> >>> >>> >>> >>> Am 07.08.2013 um 13:46 schrieb Andrew Hankinson >>> : >>> >>>> The only thing I have to add here is from an old discussion Perry >>>> and I had a while back. I just remembered it when reading through >>>> Johannes' e-mail, so I'll reproduce it here: >>>> >>>>> ... I think it's good practice to use @type to indicate the >>>>> *classification of the element itself, not its contents.* For >>>>> example, Perry Roland as opposed to >>>>> Perry Roland. The first seems to me >>>>> like a good use of @type -- it classifies the name, not Perry >>>>> Roland. Down the second path is ruin and death. :) >>>> >>>> In the case of the example Johannes provided, I'm unclear what the >>>> problem is. Is it that you can't do ""? >>>> This seems a strange way of marking it up, especially since we >>>> have quite extensive functionality for editorial additions. >>>> >>>> Couldn't it be: >>>> >>>> >>>> ... >>>> >>>> >>>> >>>> >>>> >>>> -Andrew >>>> >>>> On 2013-08-07, at 1:07 PM, Johannes Kepper >>>> wrote: >>>> >>>>> Hi Thomas, >>>>> >>>>> thanks for pointing that out. This solution seems to be too >>>>> temporary to me, I would like to have something more stable. >>>>> Also, I'm actually using both @type and @subtype. But this is >>>>> just about my example - what's your take on the availability of >>>>> @type on events in general? >>>>> >>>>> jo >>>>> >>>>> >>>>> >>>>> Am 07.08.2013 um 13:03 schrieb TW : >>>>> >>>>>> My favourite attribute to abuse for temporary solutions that should >>>>>> not result in invalid MEI is @label as it's available almost >>>>>> everywhere. (Kristina can tell you a thing or two about that.) >>>>>> >>>>>> 2013/8/7 Johannes Kepper : >>>>>>> Dear List, >>>>>>> >>>>>>> I have some issues I've found recently that I would like to >>>>>>> discuss. Let's start with a question about typable events. In >>>>>>> current MEI, it is not possible to use @type (att.tybable) on >>>>>>> all events (model.eventLike), such as notes, rests, chords, >>>>>>> spaces, tuplets, bTrems etc. >>>>>>> I wonder if this is intention, or if we just missed to add that >>>>>>> class. Even if it was our intention (though I haven't found a >>>>>>> former discussion on this), what were the arguments, and do we >>>>>>> still think this is a necessary restriction? >>>>>>> >>>>>>> The following sample may be skipped for brevity... >>>>>>>> My example for this is somewhat questionable in itself, so let >>>>>>>> me explain it a bit. For our Freisch?tz edition, we're heading >>>>>>>> off with Finale data converted to MEI via MusicXML. In the >>>>>>>> case of multiple layers on one staff, Finale clips shared >>>>>>>> events at the end of the second (and any subsequent) layer: If >>>>>>>> both layers share a rest at the end, only the first layer >>>>>>>> holds this rest, while the second is just incomplete. >>>>>>>> >>>>>>>> For several reasons, I think this is faulty behavior, and >>>>>>>> therefore add corresponding spaces by XSLT. However, I would >>>>>>>> like to keep track which spaces were contained in the original >>>>>>>> file, and which spaces were added by me. A simple @type on the >>>>>>>> latter would be perfect for me. >>>>>>>> >>>>>>>> I am fully aware that MEI offers a whole plethora of elements >>>>>>>> to indicate added, normalized, or otherwise changed content. >>>>>>>> But since this is just an intermediate step in the process of >>>>>>>> generating my data, I regard this additional markup as too >>>>>>>> complicated. I'm not sure if I will keep this information >>>>>>>> after the next step of proofreading. On the other hand, I >>>>>>>> don't want to operate on invalid data, even if it is only a >>>>>>>> temporary state. >>>>>>> >>>>>>> I'm pretty sure there are simpler examples and better arguments >>>>>>> at hand, but I hope my example makes the point. So, what do >>>>>>> others say - should events like notes and rests be typable? >>>>>>> >>>>>>> Best, >>>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 > -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington From zupftom at googlemail.com Wed Aug 7 18:09:10 2013 From: zupftom at googlemail.com (TW) Date: Wed, 7 Aug 2013 18:09:10 +0200 Subject: [MEI-L] typable events In-Reply-To: <97E89245-E33A-438A-934B-52E634C35567@edirom.de> References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <97E89245-E33A-438A-934B-52E634C35567@edirom.de> Message-ID: 2013/8/7 Johannes Kepper : > [...] what's your take on the availability of @type on events in general? > Let me think aloud: I think Andrew and Raffaele make some valid points concerning your application. But to pick up on Andrews mail: Could a rule of thumb be: @type should only be used in cases where the elements with the same name but with a different type attribute could be thought of as different data types or OO classes that have a common ancestor class? Introducing a new element would almost be justifiable in such cases. So, Perry Roland Perrius Rolandi is O.K. These might be two distinct different "fields" (i.e. elements) in a database, you might almost almost (sic) want to do something like Perry Roland Perrius Rolandi But you shouldn't do Perry Roland Perrius Rolandi as (following Andrew's argumentation) you're saying something about the specific name, not the abstract element containing the name. Perry Roland Perrius Rolandi would not be possible because you can't put content information inside the element name. If there is something to this rule of thumb, are there any scenarios in which @type makes sense on events? What comes to my mind is because there are these two types of graphically very distinct multi measure rests (the "American" ones[1] drawn like |---|, the "European" ones[2] composed of multiple symbols). They are even so different that one might want to specify different sets of presentational properties. For the American one, you might want to specify the length of the line, whereas for the European one, you might want to specify the set of symbols the multiRest is composed of, especially if one finds a deviation from the rule somewhere. So I think this example supports that @type could indeed make sense on events. Speaking of @type and reading Raffaele's mail, I'm wondering whether it would be desirable to provide a formal means of specifying a taxonomy that is used for @type? Something along the lines of , like Or possibly even elements inside , although is currently only used to specify a term that applies to a specific resource, not to define a term. [1] https://upload.wikimedia.org/wikipedia/commons/thumb/e/ef/15_bars_multirest.png/160px-15_bars_multirest.png [2] https://upload.wikimedia.org/wikipedia/commons/thumb/c/c4/Old_multirests.png/440px-Old_multirests.png From raffaeleviglianti at gmail.com Wed Aug 7 18:19:36 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Wed, 7 Aug 2013 12:19:36 -0400 Subject: [MEI-L] typable events In-Reply-To: References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <97E89245-E33A-438A-934B-52E634C35567@edirom.de> Message-ID: On Wed, Aug 7, 2013 at 12:09 PM, TW wrote: > > Speaking of @type and reading Raffaele's mail, I'm wondering whether > it would be desirable to provide a formal means of specifying a > taxonomy that is used for @type? Something along the lines of > , like > > > > > > Or possibly even elements inside , although is > currently only used to specify a term that applies to a specific > resource, not to define a term. > Hi Thomas, you would do this in ODD, by overriding the definition of @type, either at model level, or element level: So your schemata will force you to use only those when encoding, and if you add you can also generate documentation for a human reader. In theory, an ODD-aware application parsing MEI (wouldn't that be awesome) should be able to pick on this change from the standard and act accordingly (at least by throwing a warning, or asking for user input, or what have you) Raffaele > > [1] > https://upload.wikimedia.org/wikipedia/commons/thumb/e/ef/15_bars_multirest.png/160px-15_bars_multirest.png > [2] > https://upload.wikimedia.org/wikipedia/commons/thumb/c/c4/Old_multirests.png/440px-Old_multirests.png > > _______________________________________________ > 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: From zupftom at googlemail.com Wed Aug 7 18:46:12 2013 From: zupftom at googlemail.com (TW) Date: Wed, 7 Aug 2013 18:46:12 +0200 Subject: [MEI-L] typable events In-Reply-To: <6AD03340-8DD5-4285-B0C8-1508444CD03C@edirom.de> References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> <29913_1375882794_52024E28_29913_175_1_EC508459-C132-4A60-B0A7-E7B8DF21873D@edirom.de> <6AD03340-8DD5-4285-B0C8-1508444CD03C@edirom.de> Message-ID: 2013/8/7 Johannes Kepper : > > [...] I see your point about inviting abuse when making @type more general available, and I guess I'm willing to follow that argument. However, I'm less convinced that @label is actually a better solution for my needs. Since I'm saying something _about_ my MEI, I wonder if an attribute in a private namespace might be an option? This would break validity (unless I change my MEI accordingly), but it would be clearly something said from "outside", without pretending to be my final MEI? > As adding temporary data to MEI files that is intended for further processing steps seems not too uncommon (at least we do it and you do it), maybe one could introduce something like HTML5's data-* attributes[1] that give more flexibility, circumventing the need to abuse existing structures for inappropriate purposes? Probably elements will work better than attributes, though. One suggestion for your application could be 1 rest or, given we allow the fictional tempData element to be given arbitrary attributes (possibly making @type mandatory): That's probably cleaner than something more along the lines of HTML5 @data-* like although avoiding additional elements might might make things easier for some applications. In any case I fear that wilcard attribute names like @tempData-* would not even be specifiable with ODD. Speaking of ODD: Of course one would have to find good arguments for introducing elements or attributes like this rather than creating an ODD modification. [1] http://www.w3.org/html/wg/drafts/html/master/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes From pdr4h at eservices.virginia.edu Wed Aug 7 23:29:42 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 7 Aug 2013 21:29:42 +0000 Subject: [MEI-L] typable events In-Reply-To: References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> <29913_1375882794_52024E28_29913_175_1_EC508459-C132-4A60-B0A7-E7B8DF21873D@edirom.de> <6AD03340-8DD5-4285-B0C8-1508444CD03C@edirom.de>, Message-ID: Hi everyone, Sorry for joining the conversation late. I'm at the Balisage conference in Montreal where MEI appears to be already known and appreciated by several participants. Hooray! The lack of the att.typed class on members of model.event was a deliberate choice. The intention was to head off abuse of @type and @subtype. My statements about using these attributes only to classify the element and not its contents, while not strictly enforceable, were also intended to get users to think about the problems that casual use of these attributes has the potential to cause. Where appropriate elements and attributes are already available, such as for Johannes' example, they should be used, of course. If, after careful analysis, it's determined that extension is necessary, I'd recommend, in descending order of desirability, 1) additional elements and/or attributes in a private namespace, then 2) @type and @subtype. Formal customization should be considered first since it is fairly easy to accomplish with ODD & Roma and it gives you the opportunity to make your intention absolutely clear -- with beautiful, well-written documentation. :-) Addressing Thomas' suggestion, it's not technically difficult to globally allow the use of attributes and elements from an unknown namespace in RNG, but I can't say with confidence whether/how that can be accomplished in ODD. I agree with Thomas' final comment, however, that allowing such additions subverts the use of formal customization for extension. I'm reluctant to open that particular door. -- 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, August 07, 2013 12:46 PM To: Music Encoding Initiative Subject: Re: [MEI-L] typable events 2013/8/7 Johannes Kepper : > > [...] I see your point about inviting abuse when making @type more general available, and I guess I'm willing to follow that argument. However, I'm less convinced that @label is actually a better solution for my needs. Since I'm saying something _about_ my MEI, I wonder if an attribute in a private namespace might be an option? This would break validity (unless I change my MEI accordingly), but it would be clearly something said from "outside", without pretending to be my final MEI? > As adding temporary data to MEI files that is intended for further processing steps seems not too uncommon (at least we do it and you do it), maybe one could introduce something like HTML5's data-* attributes[1] that give more flexibility, circumventing the need to abuse existing structures for inappropriate purposes? Probably elements will work better than attributes, though. One suggestion for your application could be 1 rest or, given we allow the fictional tempData element to be given arbitrary attributes (possibly making @type mandatory): That's probably cleaner than something more along the lines of HTML5 @data-* like although avoiding additional elements might might make things easier for some applications. In any case I fear that wilcard attribute names like @tempData-* would not even be specifiable with ODD. Speaking of ODD: Of course one would have to find good arguments for introducing elements or attributes like this rather than creating an ODD modification. [1] http://www.w3.org/html/wg/drafts/html/master/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes _______________________________________________ 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 Aug 7 23:31:01 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 7 Aug 2013 21:31:01 +0000 Subject: [MEI-L] typable events In-Reply-To: <20130807103514.sbagghceo8cgg0sg@webmail.iu.edu> References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> <29913_1375882794_52024E28_29913_175_1_EC508459-C132-4A60-B0A7-E7B8DF21873D@edirom.de> <6AD03340-8DD5-4285-B0C8-1508444CD03C@edirom.de>, <20130807103514.sbagghceo8cgg0sg@webmail.iu.edu> Message-ID: Don's comment +1 -- 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 Byrd, Donald A. [donbyrd at indiana.edu] Sent: Wednesday, August 07, 2013 10:35 AM To: Music Encoding Initiative; Johannes Kepper Subject: Re: [MEI-L] typable events Disclaimer: this is a hasty comment from someone who hasn't been following the details of the discussion :-| . Ahem. Using an attribute in a private namespace seems like exactly what you want. If anything, breaking validity unless you change your def. of MEI sounds like an advantage, since then if you fail to clean up your intermediate code properly, anyone running against standard MEI would likely find that out very quickly. --Don On Wed, 7 Aug 2013 16:19:16 +0200, Johannes Kepper wrote: > Hi Andrew, > > I wasn't complaining about your argumentation, not at all :-) > > Actually, when I set that up, I didn't think about it much. It was > just today when I noticed that it doesn't validate, and I wondered > why that is. I totally agree that the current state is, say, less > than ideal... I see your point about inviting abuse when making @type > more general available, and I guess I'm willing to follow that > argument. However, I'm less convinced that @label is actually a > better solution for my needs. Since I'm saying something _about_ my > MEI, I wonder if an attribute in a private namespace might be an > option? This would break validity (unless I change my MEI > accordingly), but it would be clearly something said from "outside", > without pretending to be my final MEI... > > Opinions? > jo > > > Am 07.08.2013 um 16:08 schrieb Andrew Hankinson > : > >> Oh, I wasn't making any particular argument -- just trying to >> understand your need. >> >> The phrase that I copied from Perry seemed to suggest that @type >> should be used to typify the element, not the use or context. So >> "" (to make up an example) might be OK, >> whereas '' seems weird, >> since you're typifying the use and context of the element, not the >> element itself. >> >> I have no problem with @type on events, per se, but since "type" is >> such a loose concept I think that would open it up for abuse for >> people trying to do "quick and dirty" encoding. Should we consider >> or to be "good" MEI? >> Hopefully not, but I think it would be the kind of thing that would >> be a tempting solution when you're not an expert encoder. >> >> Leaving @type off of them may indeed be an oversight, but maybe we >> don't want to go too crazy with @type in favour of more expressive >> markup. >> >> If it's just temporary, and you just want an attribute that you can >> abuse for a transitional file, why not do as Thomas suggested and >> put it in @label, perhaps with a fixed formatting that you can >> process later: >> >> >> >> You could then split on the hyphens in any @label and have your >> layer, event, and reason all in one easy-to-chew package. :) >> >> Alternately, you can do it another way and store a list of IDs in a >> separate plain text file or CSV, which you can then use later when >> processing it. >> >> -Andrew >> >> On 2013-08-07, at 3:39 PM, Johannes Kepper >> wrote: >> >>> Hi Andrew, >>> >>> my actual example is >>> >>> >> corresp="#d1e2682" dur="4"/> >>> >>> which could be encoded as >>> >>> >>> >>> >>> >>> >>> While this is absolutely possible, it complicates intermediate >>> steps a bit, since I already have to deal with editorial markup >>> then. Remember, this is only temporary data that I won't publish, >>> and that I don't regard as ready yet. However, it is a state that >>> will be submitted to my repository, and will thus be visible to >>> others. If it was a more stable state, I would certainly take the >>> approach, but in the end, this will just result in a >>> couple of sentences in the documentation. For now, all I want to >>> achieve is to get an indicator where I have to look during >>> proofreading. The benefit of the attribute-only solution is that I >>> can just strip the attribute when I'm done, assuming I have made my >>> changes where necessary beforehand. >>> >>> But again, you're discussing my example, which I already announced >>> as being questionable. I'm deeply sorry that I didn't come up with >>> a better one, but I had none in mind. Without having a better one >>> by now, I suspect that in most situations where one would add @type >>> to events, MEI would allow an alternative using editorial markup. >>> But still, I wonder if we shouldn't allow @type on events. >>> >>> It would be easier for me to follow your arguments if you would >>> address this question as well, not just my ill-considered example... >>> >>> Thanks, >>> jo >>> >>> >>> >>> >>> >>> Am 07.08.2013 um 13:46 schrieb Andrew Hankinson >>> : >>> >>>> The only thing I have to add here is from an old discussion Perry >>>> and I had a while back. I just remembered it when reading through >>>> Johannes' e-mail, so I'll reproduce it here: >>>> >>>>> ... I think it's good practice to use @type to indicate the >>>>> *classification of the element itself, not its contents.* For >>>>> example, Perry Roland as opposed to >>>>> Perry Roland. The first seems to me >>>>> like a good use of @type -- it classifies the name, not Perry >>>>> Roland. Down the second path is ruin and death. :) >>>> >>>> In the case of the example Johannes provided, I'm unclear what the >>>> problem is. Is it that you can't do ""? >>>> This seems a strange way of marking it up, especially since we >>>> have quite extensive functionality for editorial additions. >>>> >>>> Couldn't it be: >>>> >>>> >>>> ... >>>> >>>> >>>> >>>> >>>> >>>> -Andrew >>>> >>>> On 2013-08-07, at 1:07 PM, Johannes Kepper >>>> wrote: >>>> >>>>> Hi Thomas, >>>>> >>>>> thanks for pointing that out. This solution seems to be too >>>>> temporary to me, I would like to have something more stable. >>>>> Also, I'm actually using both @type and @subtype. But this is >>>>> just about my example - what's your take on the availability of >>>>> @type on events in general? >>>>> >>>>> jo >>>>> >>>>> >>>>> >>>>> Am 07.08.2013 um 13:03 schrieb TW : >>>>> >>>>>> My favourite attribute to abuse for temporary solutions that should >>>>>> not result in invalid MEI is @label as it's available almost >>>>>> everywhere. (Kristina can tell you a thing or two about that.) >>>>>> >>>>>> 2013/8/7 Johannes Kepper : >>>>>>> Dear List, >>>>>>> >>>>>>> I have some issues I've found recently that I would like to >>>>>>> discuss. Let's start with a question about typable events. In >>>>>>> current MEI, it is not possible to use @type (att.tybable) on >>>>>>> all events (model.eventLike), such as notes, rests, chords, >>>>>>> spaces, tuplets, bTrems etc. >>>>>>> I wonder if this is intention, or if we just missed to add that >>>>>>> class. Even if it was our intention (though I haven't found a >>>>>>> former discussion on this), what were the arguments, and do we >>>>>>> still think this is a necessary restriction? >>>>>>> >>>>>>> The following sample may be skipped for brevity... >>>>>>>> My example for this is somewhat questionable in itself, so let >>>>>>>> me explain it a bit. For our Freisch?tz edition, we're heading >>>>>>>> off with Finale data converted to MEI via MusicXML. In the >>>>>>>> case of multiple layers on one staff, Finale clips shared >>>>>>>> events at the end of the second (and any subsequent) layer: If >>>>>>>> both layers share a rest at the end, only the first layer >>>>>>>> holds this rest, while the second is just incomplete. >>>>>>>> >>>>>>>> For several reasons, I think this is faulty behavior, and >>>>>>>> therefore add corresponding spaces by XSLT. However, I would >>>>>>>> like to keep track which spaces were contained in the original >>>>>>>> file, and which spaces were added by me. A simple @type on the >>>>>>>> latter would be perfect for me. >>>>>>>> >>>>>>>> I am fully aware that MEI offers a whole plethora of elements >>>>>>>> to indicate added, normalized, or otherwise changed content. >>>>>>>> But since this is just an intermediate step in the process of >>>>>>>> generating my data, I regard this additional markup as too >>>>>>>> complicated. I'm not sure if I will keep this information >>>>>>>> after the next step of proofreading. On the other hand, I >>>>>>>> don't want to operate on invalid data, even if it is only a >>>>>>>> temporary state. >>>>>>> >>>>>>> I'm pretty sure there are simpler examples and better arguments >>>>>>> at hand, but I hope my example makes the point. So, what do >>>>>>> others say - should events like notes and rests be typable? >>>>>>> >>>>>>> Best, >>>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 > -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington _______________________________________________ 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 Aug 7 23:37:17 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 7 Aug 2013 23:37:17 +0200 Subject: [MEI-L] typable events In-Reply-To: References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> <29913_1375882794_52024E28_29913_175_1_EC508459-C132-4A60-B0A7-E7B8DF21873D@edirom.de> <6AD03340-8DD5-4285-B0C8-1508444CD03C@edirom.de>, <20130807103514.sbagghceo8cgg0sg@webmail.iu.edu> Message-ID: Ok, let me summarize the discussion so far: * we all agree that making events typable invites abuse more than it solves actual problems. As long as no one speaks up with better arguments, we won't make this available * I'll think over my bad behavior in the past and try harder next time ;-) (probably doing the private namespace thing then?) Thanks for the discussion :-) Jo Am 07.08.2013 um 23:31 schrieb "Roland, Perry (pdr4h)" : > > Don's comment +1 > > -- > 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 Byrd, Donald A. [donbyrd at indiana.edu] > Sent: Wednesday, August 07, 2013 10:35 AM > To: Music Encoding Initiative; Johannes Kepper > Subject: Re: [MEI-L] typable events > > Disclaimer: this is a hasty comment from someone who hasn't been > following the details of the discussion :-| . Ahem. Using an attribute > in a private namespace seems like exactly what you want. If anything, > breaking validity unless you change your def. of MEI sounds like an > advantage, since then if you fail to clean up your intermediate code > properly, anyone running against standard MEI would likely find that > out very quickly. > > --Don > > > On Wed, 7 Aug 2013 16:19:16 +0200, Johannes Kepper wrote: >> Hi Andrew, >> >> I wasn't complaining about your argumentation, not at all :-) >> >> Actually, when I set that up, I didn't think about it much. It was >> just today when I noticed that it doesn't validate, and I wondered >> why that is. I totally agree that the current state is, say, less >> than ideal... I see your point about inviting abuse when making @type >> more general available, and I guess I'm willing to follow that >> argument. However, I'm less convinced that @label is actually a >> better solution for my needs. Since I'm saying something _about_ my >> MEI, I wonder if an attribute in a private namespace might be an >> option? This would break validity (unless I change my MEI >> accordingly), but it would be clearly something said from "outside", >> without pretending to be my final MEI... >> >> Opinions? >> jo >> >> >> Am 07.08.2013 um 16:08 schrieb Andrew Hankinson >> : >> >>> Oh, I wasn't making any particular argument -- just trying to >>> understand your need. >>> >>> The phrase that I copied from Perry seemed to suggest that @type >>> should be used to typify the element, not the use or context. So >>> "" (to make up an example) might be OK, >>> whereas '' seems weird, >>> since you're typifying the use and context of the element, not the >>> element itself. >>> >>> I have no problem with @type on events, per se, but since "type" is >>> such a loose concept I think that would open it up for abuse for >>> people trying to do "quick and dirty" encoding. Should we consider >>> or to be "good" MEI? >>> Hopefully not, but I think it would be the kind of thing that would >>> be a tempting solution when you're not an expert encoder. >>> >>> Leaving @type off of them may indeed be an oversight, but maybe we >>> don't want to go too crazy with @type in favour of more expressive >>> markup. >>> >>> If it's just temporary, and you just want an attribute that you can >>> abuse for a transitional file, why not do as Thomas suggested and >>> put it in @label, perhaps with a fixed formatting that you can >>> process later: >>> >>> >>> >>> You could then split on the hyphens in any @label and have your >>> layer, event, and reason all in one easy-to-chew package. :) >>> >>> Alternately, you can do it another way and store a list of IDs in a >>> separate plain text file or CSV, which you can then use later when >>> processing it. >>> >>> -Andrew >>> >>> On 2013-08-07, at 3:39 PM, Johannes Kepper >>> wrote: >>> >>>> Hi Andrew, >>>> >>>> my actual example is >>>> >>>> >>> corresp="#d1e2682" dur="4"/> >>>> >>>> which could be encoded as >>>> >>>> >>>> >>>> >>>> >>>> >>>> While this is absolutely possible, it complicates intermediate >>>> steps a bit, since I already have to deal with editorial markup >>>> then. Remember, this is only temporary data that I won't publish, >>>> and that I don't regard as ready yet. However, it is a state that >>>> will be submitted to my repository, and will thus be visible to >>>> others. If it was a more stable state, I would certainly take the >>>> approach, but in the end, this will just result in a >>>> couple of sentences in the documentation. For now, all I want to >>>> achieve is to get an indicator where I have to look during >>>> proofreading. The benefit of the attribute-only solution is that I >>>> can just strip the attribute when I'm done, assuming I have made my >>>> changes where necessary beforehand. >>>> >>>> But again, you're discussing my example, which I already announced >>>> as being questionable. I'm deeply sorry that I didn't come up with >>>> a better one, but I had none in mind. Without having a better one >>>> by now, I suspect that in most situations where one would add @type >>>> to events, MEI would allow an alternative using editorial markup. >>>> But still, I wonder if we shouldn't allow @type on events. >>>> >>>> It would be easier for me to follow your arguments if you would >>>> address this question as well, not just my ill-considered example... >>>> >>>> Thanks, >>>> jo >>>> >>>> >>>> >>>> >>>> >>>> Am 07.08.2013 um 13:46 schrieb Andrew Hankinson >>>> : >>>> >>>>> The only thing I have to add here is from an old discussion Perry >>>>> and I had a while back. I just remembered it when reading through >>>>> Johannes' e-mail, so I'll reproduce it here: >>>>> >>>>>> ... I think it's good practice to use @type to indicate the >>>>>> *classification of the element itself, not its contents.* For >>>>>> example, Perry Roland as opposed to >>>>>> Perry Roland. The first seems to me >>>>>> like a good use of @type -- it classifies the name, not Perry >>>>>> Roland. Down the second path is ruin and death. :) >>>>> >>>>> In the case of the example Johannes provided, I'm unclear what the >>>>> problem is. Is it that you can't do ""? >>>>> This seems a strange way of marking it up, especially since we >>>>> have quite extensive functionality for editorial additions. >>>>> >>>>> Couldn't it be: >>>>> >>>>> >>>>> ... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -Andrew >>>>> >>>>> On 2013-08-07, at 1:07 PM, Johannes Kepper >>>>> wrote: >>>>> >>>>>> Hi Thomas, >>>>>> >>>>>> thanks for pointing that out. This solution seems to be too >>>>>> temporary to me, I would like to have something more stable. >>>>>> Also, I'm actually using both @type and @subtype. But this is >>>>>> just about my example - what's your take on the availability of >>>>>> @type on events in general? >>>>>> >>>>>> jo >>>>>> >>>>>> >>>>>> >>>>>> Am 07.08.2013 um 13:03 schrieb TW : >>>>>> >>>>>>> My favourite attribute to abuse for temporary solutions that should >>>>>>> not result in invalid MEI is @label as it's available almost >>>>>>> everywhere. (Kristina can tell you a thing or two about that.) >>>>>>> >>>>>>> 2013/8/7 Johannes Kepper : >>>>>>>> Dear List, >>>>>>>> >>>>>>>> I have some issues I've found recently that I would like to >>>>>>>> discuss. Let's start with a question about typable events. In >>>>>>>> current MEI, it is not possible to use @type (att.tybable) on >>>>>>>> all events (model.eventLike), such as notes, rests, chords, >>>>>>>> spaces, tuplets, bTrems etc. >>>>>>>> I wonder if this is intention, or if we just missed to add that >>>>>>>> class. Even if it was our intention (though I haven't found a >>>>>>>> former discussion on this), what were the arguments, and do we >>>>>>>> still think this is a necessary restriction? >>>>>>>> >>>>>>>> The following sample may be skipped for brevity... >>>>>>>>> My example for this is somewhat questionable in itself, so let >>>>>>>>> me explain it a bit. For our Freisch?tz edition, we're heading >>>>>>>>> off with Finale data converted to MEI via MusicXML. In the >>>>>>>>> case of multiple layers on one staff, Finale clips shared >>>>>>>>> events at the end of the second (and any subsequent) layer: If >>>>>>>>> both layers share a rest at the end, only the first layer >>>>>>>>> holds this rest, while the second is just incomplete. >>>>>>>>> >>>>>>>>> For several reasons, I think this is faulty behavior, and >>>>>>>>> therefore add corresponding spaces by XSLT. However, I would >>>>>>>>> like to keep track which spaces were contained in the original >>>>>>>>> file, and which spaces were added by me. A simple @type on the >>>>>>>>> latter would be perfect for me. >>>>>>>>> >>>>>>>>> I am fully aware that MEI offers a whole plethora of elements >>>>>>>>> to indicate added, normalized, or otherwise changed content. >>>>>>>>> But since this is just an intermediate step in the process of >>>>>>>>> generating my data, I regard this additional markup as too >>>>>>>>> complicated. I'm not sure if I will keep this information >>>>>>>>> after the next step of proofreading. On the other hand, I >>>>>>>>> don't want to operate on invalid data, even if it is only a >>>>>>>>> temporary state. >>>>>>>> >>>>>>>> I'm pretty sure there are simpler examples and better arguments >>>>>>>> at hand, but I hope my example makes the point. So, what do >>>>>>>> others say - should events like notes and rests be typable? >>>>>>>> >>>>>>>> Best, >>>>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > > -- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > 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 pdr4h at eservices.virginia.edu Wed Aug 7 23:40:11 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 7 Aug 2013 21:40:11 +0000 Subject: [MEI-L] interesting Balisage moment Message-ID: Reporting from Balisage -- It's interesting to hear that DITA (Darwin Information Typing Architecture) is following a similar path to that of MEI from parameterized DTD to modularized RNG. We, however, have taken an additional step to ODD. DITA probably won't go there, however, due to its reliance on architectural forms (also a feature of past versions of MEI). I hear architectural forms are making a comeback, though, so maybe MEI could go "back to the future" as well. :-) -- 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, August 07, 2013 5:29 PM To: Music Encoding Initiative Subject: Re: [MEI-L] typable events Hi everyone, Sorry for joining the conversation late. I'm at the Balisage conference in Montreal where MEI appears to be already known and appreciated by several participants. Hooray! The lack of the att.typed class on members of model.event was a deliberate choice. The intention was to head off abuse of @type and @subtype. My statements about using these attributes only to classify the element and not its contents, while not strictly enforceable, were also intended to get users to think about the problems that casual use of these attributes has the potential to cause. Where appropriate elements and attributes are already available, such as for Johannes' example, they should be used, of course. If, after careful analysis, it's determined that extension is necessary, I'd recommend, in descending order of desirability, 1) additional elements and/or attributes in a private namespace, then 2) @type and @subtype. Formal customization should be considered first since it is fairly easy to accomplish with ODD & Roma and it gives you the opportunity to make your intention absolutely clear -- with beautiful, well-written documentation. :-) Addressing Thomas' suggestion, it's not technically difficult to globally allow the use of attributes and elements from an unknown namespace in RNG, but I can't say with confidence whether/how that can be accomplished in ODD. I agree with Thomas' final comment, however, that allowing such additions subverts the use of formal customization for extension. I'm reluctant to open that particular door. -- 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, August 07, 2013 12:46 PM To: Music Encoding Initiative Subject: Re: [MEI-L] typable events 2013/8/7 Johannes Kepper : > > [...] I see your point about inviting abuse when making @type more general available, and I guess I'm willing to follow that argument. However, I'm less convinced that @label is actually a better solution for my needs. Since I'm saying something _about_ my MEI, I wonder if an attribute in a private namespace might be an option? This would break validity (unless I change my MEI accordingly), but it would be clearly something said from "outside", without pretending to be my final MEI? > As adding temporary data to MEI files that is intended for further processing steps seems not too uncommon (at least we do it and you do it), maybe one could introduce something like HTML5's data-* attributes[1] that give more flexibility, circumventing the need to abuse existing structures for inappropriate purposes? Probably elements will work better than attributes, though. One suggestion for your application could be 1 rest or, given we allow the fictional tempData element to be given arbitrary attributes (possibly making @type mandatory): That's probably cleaner than something more along the lines of HTML5 @data-* like although avoiding additional elements might might make things easier for some applications. In any case I fear that wilcard attribute names like @tempData-* would not even be specifiable with ODD. Speaking of ODD: Of course one would have to find good arguments for introducing elements or attributes like this rather than creating an ODD modification. [1] http://www.w3.org/html/wg/drafts/html/master/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes _______________________________________________ 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 Aug 7 23:54:41 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 7 Aug 2013 21:54:41 +0000 Subject: [MEI-L] typable events In-Reply-To: References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> <29913_1375882794_52024E28_29913_175_1_EC508459-C132-4A60-B0A7-E7B8DF21873D@edirom.de> <6AD03340-8DD5-4285-B0C8-1508444CD03C@edirom.de>, <20130807103514.sbagghceo8cgg0sg@webmail.iu.edu> , Message-ID: Thanks, Johannes, for the summary. The discussion so far notwithstanding, I have been considering the addition of @type and @subtype (or perhaps @analog) to control events, especially , since is a generic container for "stuff" associated with events. As such, in a conversion from some other music representation scheme with more specific elements for this kind of "stuff", it would be helpful to be able to associate the MEI element with the element in the source representation from which it is derived. For example, MEI has no element specifically for fingerings, so that kind of info. has to go in a . In order to facilitate conversion of the MEI back to the original form, it is necessary to know that this particular translates back to a element, not some other. Or perhaps I should follow my own advice and create a new element in 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-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Wednesday, August 07, 2013 5:37 PM To: Music Encoding Initiative Subject: Re: [MEI-L] typable events Ok, let me summarize the discussion so far: * we all agree that making events typable invites abuse more than it solves actual problems. As long as no one speaks up with better arguments, we won't make this available * I'll think over my bad behavior in the past and try harder next time ;-) (probably doing the private namespace thing then?) Thanks for the discussion :-) Jo Am 07.08.2013 um 23:31 schrieb "Roland, Perry (pdr4h)" : > > Don's comment +1 > > -- > 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 Byrd, Donald A. [donbyrd at indiana.edu] > Sent: Wednesday, August 07, 2013 10:35 AM > To: Music Encoding Initiative; Johannes Kepper > Subject: Re: [MEI-L] typable events > > Disclaimer: this is a hasty comment from someone who hasn't been > following the details of the discussion :-| . Ahem. Using an attribute > in a private namespace seems like exactly what you want. If anything, > breaking validity unless you change your def. of MEI sounds like an > advantage, since then if you fail to clean up your intermediate code > properly, anyone running against standard MEI would likely find that > out very quickly. > > --Don > > > On Wed, 7 Aug 2013 16:19:16 +0200, Johannes Kepper wrote: >> Hi Andrew, >> >> I wasn't complaining about your argumentation, not at all :-) >> >> Actually, when I set that up, I didn't think about it much. It was >> just today when I noticed that it doesn't validate, and I wondered >> why that is. I totally agree that the current state is, say, less >> than ideal... I see your point about inviting abuse when making @type >> more general available, and I guess I'm willing to follow that >> argument. However, I'm less convinced that @label is actually a >> better solution for my needs. Since I'm saying something _about_ my >> MEI, I wonder if an attribute in a private namespace might be an >> option? This would break validity (unless I change my MEI >> accordingly), but it would be clearly something said from "outside", >> without pretending to be my final MEI... >> >> Opinions? >> jo >> >> >> Am 07.08.2013 um 16:08 schrieb Andrew Hankinson >> : >> >>> Oh, I wasn't making any particular argument -- just trying to >>> understand your need. >>> >>> The phrase that I copied from Perry seemed to suggest that @type >>> should be used to typify the element, not the use or context. So >>> "" (to make up an example) might be OK, >>> whereas '' seems weird, >>> since you're typifying the use and context of the element, not the >>> element itself. >>> >>> I have no problem with @type on events, per se, but since "type" is >>> such a loose concept I think that would open it up for abuse for >>> people trying to do "quick and dirty" encoding. Should we consider >>> or to be "good" MEI? >>> Hopefully not, but I think it would be the kind of thing that would >>> be a tempting solution when you're not an expert encoder. >>> >>> Leaving @type off of them may indeed be an oversight, but maybe we >>> don't want to go too crazy with @type in favour of more expressive >>> markup. >>> >>> If it's just temporary, and you just want an attribute that you can >>> abuse for a transitional file, why not do as Thomas suggested and >>> put it in @label, perhaps with a fixed formatting that you can >>> process later: >>> >>> >>> >>> You could then split on the hyphens in any @label and have your >>> layer, event, and reason all in one easy-to-chew package. :) >>> >>> Alternately, you can do it another way and store a list of IDs in a >>> separate plain text file or CSV, which you can then use later when >>> processing it. >>> >>> -Andrew >>> >>> On 2013-08-07, at 3:39 PM, Johannes Kepper >>> wrote: >>> >>>> Hi Andrew, >>>> >>>> my actual example is >>>> >>>> >>> corresp="#d1e2682" dur="4"/> >>>> >>>> which could be encoded as >>>> >>>> >>>> >>>> >>>> >>>> >>>> While this is absolutely possible, it complicates intermediate >>>> steps a bit, since I already have to deal with editorial markup >>>> then. Remember, this is only temporary data that I won't publish, >>>> and that I don't regard as ready yet. However, it is a state that >>>> will be submitted to my repository, and will thus be visible to >>>> others. If it was a more stable state, I would certainly take the >>>> approach, but in the end, this will just result in a >>>> couple of sentences in the documentation. For now, all I want to >>>> achieve is to get an indicator where I have to look during >>>> proofreading. The benefit of the attribute-only solution is that I >>>> can just strip the attribute when I'm done, assuming I have made my >>>> changes where necessary beforehand. >>>> >>>> But again, you're discussing my example, which I already announced >>>> as being questionable. I'm deeply sorry that I didn't come up with >>>> a better one, but I had none in mind. Without having a better one >>>> by now, I suspect that in most situations where one would add @type >>>> to events, MEI would allow an alternative using editorial markup. >>>> But still, I wonder if we shouldn't allow @type on events. >>>> >>>> It would be easier for me to follow your arguments if you would >>>> address this question as well, not just my ill-considered example... >>>> >>>> Thanks, >>>> jo >>>> >>>> >>>> >>>> >>>> >>>> Am 07.08.2013 um 13:46 schrieb Andrew Hankinson >>>> : >>>> >>>>> The only thing I have to add here is from an old discussion Perry >>>>> and I had a while back. I just remembered it when reading through >>>>> Johannes' e-mail, so I'll reproduce it here: >>>>> >>>>>> ... I think it's good practice to use @type to indicate the >>>>>> *classification of the element itself, not its contents.* For >>>>>> example, Perry Roland as opposed to >>>>>> Perry Roland. The first seems to me >>>>>> like a good use of @type -- it classifies the name, not Perry >>>>>> Roland. Down the second path is ruin and death. :) >>>>> >>>>> In the case of the example Johannes provided, I'm unclear what the >>>>> problem is. Is it that you can't do ""? >>>>> This seems a strange way of marking it up, especially since we >>>>> have quite extensive functionality for editorial additions. >>>>> >>>>> Couldn't it be: >>>>> >>>>> >>>>> ... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -Andrew >>>>> >>>>> On 2013-08-07, at 1:07 PM, Johannes Kepper >>>>> wrote: >>>>> >>>>>> Hi Thomas, >>>>>> >>>>>> thanks for pointing that out. This solution seems to be too >>>>>> temporary to me, I would like to have something more stable. >>>>>> Also, I'm actually using both @type and @subtype. But this is >>>>>> just about my example - what's your take on the availability of >>>>>> @type on events in general? >>>>>> >>>>>> jo >>>>>> >>>>>> >>>>>> >>>>>> Am 07.08.2013 um 13:03 schrieb TW : >>>>>> >>>>>>> My favourite attribute to abuse for temporary solutions that should >>>>>>> not result in invalid MEI is @label as it's available almost >>>>>>> everywhere. (Kristina can tell you a thing or two about that.) >>>>>>> >>>>>>> 2013/8/7 Johannes Kepper : >>>>>>>> Dear List, >>>>>>>> >>>>>>>> I have some issues I've found recently that I would like to >>>>>>>> discuss. Let's start with a question about typable events. In >>>>>>>> current MEI, it is not possible to use @type (att.tybable) on >>>>>>>> all events (model.eventLike), such as notes, rests, chords, >>>>>>>> spaces, tuplets, bTrems etc. >>>>>>>> I wonder if this is intention, or if we just missed to add that >>>>>>>> class. Even if it was our intention (though I haven't found a >>>>>>>> former discussion on this), what were the arguments, and do we >>>>>>>> still think this is a necessary restriction? >>>>>>>> >>>>>>>> The following sample may be skipped for brevity... >>>>>>>>> My example for this is somewhat questionable in itself, so let >>>>>>>>> me explain it a bit. For our Freisch?tz edition, we're heading >>>>>>>>> off with Finale data converted to MEI via MusicXML. In the >>>>>>>>> case of multiple layers on one staff, Finale clips shared >>>>>>>>> events at the end of the second (and any subsequent) layer: If >>>>>>>>> both layers share a rest at the end, only the first layer >>>>>>>>> holds this rest, while the second is just incomplete. >>>>>>>>> >>>>>>>>> For several reasons, I think this is faulty behavior, and >>>>>>>>> therefore add corresponding spaces by XSLT. However, I would >>>>>>>>> like to keep track which spaces were contained in the original >>>>>>>>> file, and which spaces were added by me. A simple @type on the >>>>>>>>> latter would be perfect for me. >>>>>>>>> >>>>>>>>> I am fully aware that MEI offers a whole plethora of elements >>>>>>>>> to indicate added, normalized, or otherwise changed content. >>>>>>>>> But since this is just an intermediate step in the process of >>>>>>>>> generating my data, I regard this additional markup as too >>>>>>>>> complicated. I'm not sure if I will keep this information >>>>>>>>> after the next step of proofreading. On the other hand, I >>>>>>>>> don't want to operate on invalid data, even if it is only a >>>>>>>>> temporary state. >>>>>>>> >>>>>>>> I'm pretty sure there are simpler examples and better arguments >>>>>>>> at hand, but I hope my example makes the point. So, what do >>>>>>>> others say - should events like notes and rests be typable? >>>>>>>> >>>>>>>> Best, >>>>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > > -- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > 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 _______________________________________________ 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 Aug 7 23:57:53 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 7 Aug 2013 21:57:53 +0000 Subject: [MEI-L] typable events In-Reply-To: References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> <29913_1375882794_52024E28_29913_175_1_EC508459-C132-4A60-B0A7-E7B8DF21873D@edirom.de> <6AD03340-8DD5-4285-B0C8-1508444CD03C@edirom.de>, <20130807103514.sbagghceo8cgg0sg@webmail.iu.edu> , Message-ID: Oops, nevermind! already has @type. Maybe it shouldn't? -- 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, August 07, 2013 5:37 PM To: Music Encoding Initiative Subject: Re: [MEI-L] typable events Ok, let me summarize the discussion so far: * we all agree that making events typable invites abuse more than it solves actual problems. As long as no one speaks up with better arguments, we won't make this available * I'll think over my bad behavior in the past and try harder next time ;-) (probably doing the private namespace thing then?) Thanks for the discussion :-) Jo Am 07.08.2013 um 23:31 schrieb "Roland, Perry (pdr4h)" : > > Don's comment +1 > > -- > 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 Byrd, Donald A. [donbyrd at indiana.edu] > Sent: Wednesday, August 07, 2013 10:35 AM > To: Music Encoding Initiative; Johannes Kepper > Subject: Re: [MEI-L] typable events > > Disclaimer: this is a hasty comment from someone who hasn't been > following the details of the discussion :-| . Ahem. Using an attribute > in a private namespace seems like exactly what you want. If anything, > breaking validity unless you change your def. of MEI sounds like an > advantage, since then if you fail to clean up your intermediate code > properly, anyone running against standard MEI would likely find that > out very quickly. > > --Don > > > On Wed, 7 Aug 2013 16:19:16 +0200, Johannes Kepper wrote: >> Hi Andrew, >> >> I wasn't complaining about your argumentation, not at all :-) >> >> Actually, when I set that up, I didn't think about it much. It was >> just today when I noticed that it doesn't validate, and I wondered >> why that is. I totally agree that the current state is, say, less >> than ideal... I see your point about inviting abuse when making @type >> more general available, and I guess I'm willing to follow that >> argument. However, I'm less convinced that @label is actually a >> better solution for my needs. Since I'm saying something _about_ my >> MEI, I wonder if an attribute in a private namespace might be an >> option? This would break validity (unless I change my MEI >> accordingly), but it would be clearly something said from "outside", >> without pretending to be my final MEI... >> >> Opinions? >> jo >> >> >> Am 07.08.2013 um 16:08 schrieb Andrew Hankinson >> : >> >>> Oh, I wasn't making any particular argument -- just trying to >>> understand your need. >>> >>> The phrase that I copied from Perry seemed to suggest that @type >>> should be used to typify the element, not the use or context. So >>> "" (to make up an example) might be OK, >>> whereas '' seems weird, >>> since you're typifying the use and context of the element, not the >>> element itself. >>> >>> I have no problem with @type on events, per se, but since "type" is >>> such a loose concept I think that would open it up for abuse for >>> people trying to do "quick and dirty" encoding. Should we consider >>> or to be "good" MEI? >>> Hopefully not, but I think it would be the kind of thing that would >>> be a tempting solution when you're not an expert encoder. >>> >>> Leaving @type off of them may indeed be an oversight, but maybe we >>> don't want to go too crazy with @type in favour of more expressive >>> markup. >>> >>> If it's just temporary, and you just want an attribute that you can >>> abuse for a transitional file, why not do as Thomas suggested and >>> put it in @label, perhaps with a fixed formatting that you can >>> process later: >>> >>> >>> >>> You could then split on the hyphens in any @label and have your >>> layer, event, and reason all in one easy-to-chew package. :) >>> >>> Alternately, you can do it another way and store a list of IDs in a >>> separate plain text file or CSV, which you can then use later when >>> processing it. >>> >>> -Andrew >>> >>> On 2013-08-07, at 3:39 PM, Johannes Kepper >>> wrote: >>> >>>> Hi Andrew, >>>> >>>> my actual example is >>>> >>>> >>> corresp="#d1e2682" dur="4"/> >>>> >>>> which could be encoded as >>>> >>>> >>>> >>>> >>>> >>>> >>>> While this is absolutely possible, it complicates intermediate >>>> steps a bit, since I already have to deal with editorial markup >>>> then. Remember, this is only temporary data that I won't publish, >>>> and that I don't regard as ready yet. However, it is a state that >>>> will be submitted to my repository, and will thus be visible to >>>> others. If it was a more stable state, I would certainly take the >>>> approach, but in the end, this will just result in a >>>> couple of sentences in the documentation. For now, all I want to >>>> achieve is to get an indicator where I have to look during >>>> proofreading. The benefit of the attribute-only solution is that I >>>> can just strip the attribute when I'm done, assuming I have made my >>>> changes where necessary beforehand. >>>> >>>> But again, you're discussing my example, which I already announced >>>> as being questionable. I'm deeply sorry that I didn't come up with >>>> a better one, but I had none in mind. Without having a better one >>>> by now, I suspect that in most situations where one would add @type >>>> to events, MEI would allow an alternative using editorial markup. >>>> But still, I wonder if we shouldn't allow @type on events. >>>> >>>> It would be easier for me to follow your arguments if you would >>>> address this question as well, not just my ill-considered example... >>>> >>>> Thanks, >>>> jo >>>> >>>> >>>> >>>> >>>> >>>> Am 07.08.2013 um 13:46 schrieb Andrew Hankinson >>>> : >>>> >>>>> The only thing I have to add here is from an old discussion Perry >>>>> and I had a while back. I just remembered it when reading through >>>>> Johannes' e-mail, so I'll reproduce it here: >>>>> >>>>>> ... I think it's good practice to use @type to indicate the >>>>>> *classification of the element itself, not its contents.* For >>>>>> example, Perry Roland as opposed to >>>>>> Perry Roland. The first seems to me >>>>>> like a good use of @type -- it classifies the name, not Perry >>>>>> Roland. Down the second path is ruin and death. :) >>>>> >>>>> In the case of the example Johannes provided, I'm unclear what the >>>>> problem is. Is it that you can't do ""? >>>>> This seems a strange way of marking it up, especially since we >>>>> have quite extensive functionality for editorial additions. >>>>> >>>>> Couldn't it be: >>>>> >>>>> >>>>> ... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -Andrew >>>>> >>>>> On 2013-08-07, at 1:07 PM, Johannes Kepper >>>>> wrote: >>>>> >>>>>> Hi Thomas, >>>>>> >>>>>> thanks for pointing that out. This solution seems to be too >>>>>> temporary to me, I would like to have something more stable. >>>>>> Also, I'm actually using both @type and @subtype. But this is >>>>>> just about my example - what's your take on the availability of >>>>>> @type on events in general? >>>>>> >>>>>> jo >>>>>> >>>>>> >>>>>> >>>>>> Am 07.08.2013 um 13:03 schrieb TW : >>>>>> >>>>>>> My favourite attribute to abuse for temporary solutions that should >>>>>>> not result in invalid MEI is @label as it's available almost >>>>>>> everywhere. (Kristina can tell you a thing or two about that.) >>>>>>> >>>>>>> 2013/8/7 Johannes Kepper : >>>>>>>> Dear List, >>>>>>>> >>>>>>>> I have some issues I've found recently that I would like to >>>>>>>> discuss. Let's start with a question about typable events. In >>>>>>>> current MEI, it is not possible to use @type (att.tybable) on >>>>>>>> all events (model.eventLike), such as notes, rests, chords, >>>>>>>> spaces, tuplets, bTrems etc. >>>>>>>> I wonder if this is intention, or if we just missed to add that >>>>>>>> class. Even if it was our intention (though I haven't found a >>>>>>>> former discussion on this), what were the arguments, and do we >>>>>>>> still think this is a necessary restriction? >>>>>>>> >>>>>>>> The following sample may be skipped for brevity... >>>>>>>>> My example for this is somewhat questionable in itself, so let >>>>>>>>> me explain it a bit. For our Freisch?tz edition, we're heading >>>>>>>>> off with Finale data converted to MEI via MusicXML. In the >>>>>>>>> case of multiple layers on one staff, Finale clips shared >>>>>>>>> events at the end of the second (and any subsequent) layer: If >>>>>>>>> both layers share a rest at the end, only the first layer >>>>>>>>> holds this rest, while the second is just incomplete. >>>>>>>>> >>>>>>>>> For several reasons, I think this is faulty behavior, and >>>>>>>>> therefore add corresponding spaces by XSLT. However, I would >>>>>>>>> like to keep track which spaces were contained in the original >>>>>>>>> file, and which spaces were added by me. A simple @type on the >>>>>>>>> latter would be perfect for me. >>>>>>>>> >>>>>>>>> I am fully aware that MEI offers a whole plethora of elements >>>>>>>>> to indicate added, normalized, or otherwise changed content. >>>>>>>>> But since this is just an intermediate step in the process of >>>>>>>>> generating my data, I regard this additional markup as too >>>>>>>>> complicated. I'm not sure if I will keep this information >>>>>>>>> after the next step of proofreading. On the other hand, I >>>>>>>>> don't want to operate on invalid data, even if it is only a >>>>>>>>> temporary state. >>>>>>>> >>>>>>>> I'm pretty sure there are simpler examples and better arguments >>>>>>>> at hand, but I hope my example makes the point. So, what do >>>>>>>> others say - should events like notes and rests be typable? >>>>>>>> >>>>>>>> Best, >>>>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > > -- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > 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 _______________________________________________ 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 Aug 8 00:10:12 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 7 Aug 2013 22:10:12 +0000 Subject: [MEI-L] typable events In-Reply-To: References: <4E1A1663-6A68-4617-BA54-6C64E9707B99@edirom.de> <13808_1375873694_52022A9E_13808_18_1_97E89245-E33A-438A-934B-52E634C35567@edirom.de> <29913_1375882794_52024E28_29913_175_1_EC508459-C132-4A60-B0A7-E7B8DF21873D@edirom.de> <6AD03340-8DD5-4285-B0C8-1508444CD03C@edirom.de>, <20130807103514.sbagghceo8cgg0sg@webmail.iu.edu> , , Message-ID: Perhaps and other control events should allow @analog. Placing @analog att.common would make it available nearly globally. That would address mapping to/from other representations once and for all. -- 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 Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] Sent: Wednesday, August 07, 2013 5:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] typable events Oops, nevermind! already has @type. Maybe it shouldn't? -- 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, August 07, 2013 5:37 PM To: Music Encoding Initiative Subject: Re: [MEI-L] typable events Ok, let me summarize the discussion so far: * we all agree that making events typable invites abuse more than it solves actual problems. As long as no one speaks up with better arguments, we won't make this available * I'll think over my bad behavior in the past and try harder next time ;-) (probably doing the private namespace thing then?) Thanks for the discussion :-) Jo Am 07.08.2013 um 23:31 schrieb "Roland, Perry (pdr4h)" : > > Don's comment +1 > > -- > 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 Byrd, Donald A. [donbyrd at indiana.edu] > Sent: Wednesday, August 07, 2013 10:35 AM > To: Music Encoding Initiative; Johannes Kepper > Subject: Re: [MEI-L] typable events > > Disclaimer: this is a hasty comment from someone who hasn't been > following the details of the discussion :-| . Ahem. Using an attribute > in a private namespace seems like exactly what you want. If anything, > breaking validity unless you change your def. of MEI sounds like an > advantage, since then if you fail to clean up your intermediate code > properly, anyone running against standard MEI would likely find that > out very quickly. > > --Don > > > On Wed, 7 Aug 2013 16:19:16 +0200, Johannes Kepper wrote: >> Hi Andrew, >> >> I wasn't complaining about your argumentation, not at all :-) >> >> Actually, when I set that up, I didn't think about it much. It was >> just today when I noticed that it doesn't validate, and I wondered >> why that is. I totally agree that the current state is, say, less >> than ideal... I see your point about inviting abuse when making @type >> more general available, and I guess I'm willing to follow that >> argument. However, I'm less convinced that @label is actually a >> better solution for my needs. Since I'm saying something _about_ my >> MEI, I wonder if an attribute in a private namespace might be an >> option? This would break validity (unless I change my MEI >> accordingly), but it would be clearly something said from "outside", >> without pretending to be my final MEI... >> >> Opinions? >> jo >> >> >> Am 07.08.2013 um 16:08 schrieb Andrew Hankinson >> : >> >>> Oh, I wasn't making any particular argument -- just trying to >>> understand your need. >>> >>> The phrase that I copied from Perry seemed to suggest that @type >>> should be used to typify the element, not the use or context. So >>> "" (to make up an example) might be OK, >>> whereas '' seems weird, >>> since you're typifying the use and context of the element, not the >>> element itself. >>> >>> I have no problem with @type on events, per se, but since "type" is >>> such a loose concept I think that would open it up for abuse for >>> people trying to do "quick and dirty" encoding. Should we consider >>> or to be "good" MEI? >>> Hopefully not, but I think it would be the kind of thing that would >>> be a tempting solution when you're not an expert encoder. >>> >>> Leaving @type off of them may indeed be an oversight, but maybe we >>> don't want to go too crazy with @type in favour of more expressive >>> markup. >>> >>> If it's just temporary, and you just want an attribute that you can >>> abuse for a transitional file, why not do as Thomas suggested and >>> put it in @label, perhaps with a fixed formatting that you can >>> process later: >>> >>> >>> >>> You could then split on the hyphens in any @label and have your >>> layer, event, and reason all in one easy-to-chew package. :) >>> >>> Alternately, you can do it another way and store a list of IDs in a >>> separate plain text file or CSV, which you can then use later when >>> processing it. >>> >>> -Andrew >>> >>> On 2013-08-07, at 3:39 PM, Johannes Kepper >>> wrote: >>> >>>> Hi Andrew, >>>> >>>> my actual example is >>>> >>>> >>> corresp="#d1e2682" dur="4"/> >>>> >>>> which could be encoded as >>>> >>>> >>>> >>>> >>>> >>>> >>>> While this is absolutely possible, it complicates intermediate >>>> steps a bit, since I already have to deal with editorial markup >>>> then. Remember, this is only temporary data that I won't publish, >>>> and that I don't regard as ready yet. However, it is a state that >>>> will be submitted to my repository, and will thus be visible to >>>> others. If it was a more stable state, I would certainly take the >>>> approach, but in the end, this will just result in a >>>> couple of sentences in the documentation. For now, all I want to >>>> achieve is to get an indicator where I have to look during >>>> proofreading. The benefit of the attribute-only solution is that I >>>> can just strip the attribute when I'm done, assuming I have made my >>>> changes where necessary beforehand. >>>> >>>> But again, you're discussing my example, which I already announced >>>> as being questionable. I'm deeply sorry that I didn't come up with >>>> a better one, but I had none in mind. Without having a better one >>>> by now, I suspect that in most situations where one would add @type >>>> to events, MEI would allow an alternative using editorial markup. >>>> But still, I wonder if we shouldn't allow @type on events. >>>> >>>> It would be easier for me to follow your arguments if you would >>>> address this question as well, not just my ill-considered example... >>>> >>>> Thanks, >>>> jo >>>> >>>> >>>> >>>> >>>> >>>> Am 07.08.2013 um 13:46 schrieb Andrew Hankinson >>>> : >>>> >>>>> The only thing I have to add here is from an old discussion Perry >>>>> and I had a while back. I just remembered it when reading through >>>>> Johannes' e-mail, so I'll reproduce it here: >>>>> >>>>>> ... I think it's good practice to use @type to indicate the >>>>>> *classification of the element itself, not its contents.* For >>>>>> example, Perry Roland as opposed to >>>>>> Perry Roland. The first seems to me >>>>>> like a good use of @type -- it classifies the name, not Perry >>>>>> Roland. Down the second path is ruin and death. :) >>>>> >>>>> In the case of the example Johannes provided, I'm unclear what the >>>>> problem is. Is it that you can't do ""? >>>>> This seems a strange way of marking it up, especially since we >>>>> have quite extensive functionality for editorial additions. >>>>> >>>>> Couldn't it be: >>>>> >>>>> >>>>> ... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -Andrew >>>>> >>>>> On 2013-08-07, at 1:07 PM, Johannes Kepper >>>>> wrote: >>>>> >>>>>> Hi Thomas, >>>>>> >>>>>> thanks for pointing that out. This solution seems to be too >>>>>> temporary to me, I would like to have something more stable. >>>>>> Also, I'm actually using both @type and @subtype. But this is >>>>>> just about my example - what's your take on the availability of >>>>>> @type on events in general? >>>>>> >>>>>> jo >>>>>> >>>>>> >>>>>> >>>>>> Am 07.08.2013 um 13:03 schrieb TW : >>>>>> >>>>>>> My favourite attribute to abuse for temporary solutions that should >>>>>>> not result in invalid MEI is @label as it's available almost >>>>>>> everywhere. (Kristina can tell you a thing or two about that.) >>>>>>> >>>>>>> 2013/8/7 Johannes Kepper : >>>>>>>> Dear List, >>>>>>>> >>>>>>>> I have some issues I've found recently that I would like to >>>>>>>> discuss. Let's start with a question about typable events. In >>>>>>>> current MEI, it is not possible to use @type (att.tybable) on >>>>>>>> all events (model.eventLike), such as notes, rests, chords, >>>>>>>> spaces, tuplets, bTrems etc. >>>>>>>> I wonder if this is intention, or if we just missed to add that >>>>>>>> class. Even if it was our intention (though I haven't found a >>>>>>>> former discussion on this), what were the arguments, and do we >>>>>>>> still think this is a necessary restriction? >>>>>>>> >>>>>>>> The following sample may be skipped for brevity... >>>>>>>>> My example for this is somewhat questionable in itself, so let >>>>>>>>> me explain it a bit. For our Freisch?tz edition, we're heading >>>>>>>>> off with Finale data converted to MEI via MusicXML. In the >>>>>>>>> case of multiple layers on one staff, Finale clips shared >>>>>>>>> events at the end of the second (and any subsequent) layer: If >>>>>>>>> both layers share a rest at the end, only the first layer >>>>>>>>> holds this rest, while the second is just incomplete. >>>>>>>>> >>>>>>>>> For several reasons, I think this is faulty behavior, and >>>>>>>>> therefore add corresponding spaces by XSLT. However, I would >>>>>>>>> like to keep track which spaces were contained in the original >>>>>>>>> file, and which spaces were added by me. A simple @type on the >>>>>>>>> latter would be perfect for me. >>>>>>>>> >>>>>>>>> I am fully aware that MEI offers a whole plethora of elements >>>>>>>>> to indicate added, normalized, or otherwise changed content. >>>>>>>>> But since this is just an intermediate step in the process of >>>>>>>>> generating my data, I regard this additional markup as too >>>>>>>>> complicated. I'm not sure if I will keep this information >>>>>>>>> after the next step of proofreading. On the other hand, I >>>>>>>>> don't want to operate on invalid data, even if it is only a >>>>>>>>> temporary state. >>>>>>>> >>>>>>>> I'm pretty sure there are simpler examples and better arguments >>>>>>>> at hand, but I hope my example makes the point. So, what do >>>>>>>> others say - should events like notes and rests be typable? >>>>>>>> >>>>>>>> Best, >>>>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > > -- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > 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 _______________________________________________ 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 bohl at edirom.de Mon Aug 12 14:41:11 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Mon, 12 Aug 2013 14:41:11 +0200 Subject: [MEI-L] halfmRpt and @rend Message-ID: Hi all, proofreading our data in Freisch?tz-Digital I came across repeat symbols. First case I was wondering whether to go with beatRpt but then I realized there was halmRpt, as well. As Weber writes his repeats as double slashes (not the common %) we're in eager need of @rend to indicate this circumstance. While @rend is available on beatRpt, it isn't on halfmRpt. Is there any reason for that, am I missing something? Best, Benjamin From raffaeleviglianti at gmail.com Mon Aug 12 14:44:34 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Mon, 12 Aug 2013 08:44:34 -0400 Subject: [MEI-L] halfmRpt and @rend In-Reply-To: References: Message-ID: FWIW, having looked at the same material, I also think a @rend would be very useful there. Raf On Mon, Aug 12, 2013 at 8:41 AM, Benjamin Wolff Bohl wrote: > Hi all, > > proofreading our data in Freisch?tz-Digital I came across repeat symbols. > First case I was wondering whether to go with beatRpt but then I realized > there was halmRpt, as well. > As Weber writes his repeats as double slashes (not the common %) we're in > eager need of @rend to indicate this circumstance. While @rend is available > on beatRpt, it isn't on halfmRpt. > > Is there any reason for that, am I missing something? > > Best, > Benjamin > _______________________________________________ > 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: From pdr4h at eservices.virginia.edu Mon Aug 12 15:20:21 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 12 Aug 2013 13:20:21 +0000 Subject: [MEI-L] halfmRpt and @rend In-Reply-To: References: , Message-ID: Pretty sure that's an oversight. Please submit a ticket. Thanks, -- 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: Monday, August 12, 2013 8:44 AM To: Music Encoding Initiative Subject: Re: [MEI-L] halfmRpt and @rend FWIW, having looked at the same material, I also think a @rend would be very useful there. Raf On Mon, Aug 12, 2013 at 8:41 AM, Benjamin Wolff Bohl > wrote: Hi all, proofreading our data in Freisch?tz-Digital I came across repeat symbols. First case I was wondering whether to go with beatRpt but then I realized there was halmRpt, as well. As Weber writes his repeats as double slashes (not the common %) we're in eager need of @rend to indicate this circumstance. While @rend is available on beatRpt, it isn't on halfmRpt. Is there any reason for that, am I missing something? Best, Benjamin _______________________________________________ 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: From bohl at edirom.de Mon Aug 12 16:44:50 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Mon, 12 Aug 2013 16:44:50 +0200 Subject: [MEI-L] halfmRpt and @rend In-Reply-To: References: , Message-ID: <5208F4E2.5050602@edirom.de> I just checked on mRpt and mRpt2, both of which don't allow @rend either. Anyhow, all of the rpt elements allow @altsym. Considering this in combination with googlecode isuue 144 (http://code.google.com/p/music-encoding/issues/detail?id=144) "reserve @rend and @style for CSS-like renditional information", is it the right way to go, or should we stick with @altsym and maybe disallow @rend on beatRpt? Best, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D--32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 12.08.2013 15:20, schrieb Roland, Perry (pdr4h): > > Pretty sure that's an oversight. Please submit a ticket. > > Thanks, > > -- > > 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:* Monday, August 12, 2013 8:44 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] halfmRpt and @rend > > FWIW, having looked at the same material, I also think a @rend would > be very useful there. > > Raf > > > On Mon, Aug 12, 2013 at 8:41 AM, Benjamin Wolff Bohl > wrote: > > Hi all, > > proofreading our data in Freisch?tz-Digital I came across repeat > symbols. First case I was wondering whether to go with beatRpt but > then I realized there was halmRpt, as well. > As Weber writes his repeats as double slashes (not the common %) > we're in eager need of @rend to indicate this circumstance. While > @rend is available on beatRpt, it isn't on halfmRpt. > > Is there any reason for that, am I missing something? > > 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 -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From pdr4h at eservices.virginia.edu Mon Aug 12 17:56:53 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 12 Aug 2013 15:56:53 +0000 Subject: [MEI-L] halfmRpt and @rend In-Reply-To: <5208F4E2.5050602@edirom.de> References: , , <5208F4E2.5050602@edirom.de> Message-ID: Hmmm, forgot about that! If we proceed with plans to make @rend and @style available on more elements but with generic typographic meaning, existing @rend attributes will have to be replaced by some other attribute that carries element-specific renditional information, possibly @form. For now, @altsym is the only other option. Remember, however, that the value of @altsym must be a URI that points to a symbolDef element. Considering the potential of SMuFL, I've been thinking a character-oriented method for indicating an exact or alternate rendition might be another way to go. We could, like TEI, provide for defining a character in the header which is then pointed to using an attribute, similar to the way and @altsym work), or we could allow text content of elements to contain Unicode character references to codepoints defined by SMuFL. Another possibility is to re-work so that it can hold the Unicode reference (making it similar to TEI's ) which is pointed to using @altsym as before. This is going to take a while to discuss and implement, though. -- 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 Benjamin Wolff Bohl [bohl at edirom.de] Sent: Monday, August 12, 2013 10:44 AM To: Music Encoding Initiative Subject: Re: [MEI-L] halfmRpt and @rend I just checked on mRpt and mRpt2, both of which don't allow @rend either. Anyhow, all of the rpt elements allow @altsym. Considering this in combination with googlecode isuue 144 (http://code.google.com/p/music-encoding/issues/detail?id=144) "reserve @rend and @style for CSS-like renditional information", is it the right way to go, or should we stick with @altsym and maybe disallow @rend on beatRpt? Best, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 12.08.2013 15:20, schrieb Roland, Perry (pdr4h): Pretty sure that's an oversight. Please submit a ticket. Thanks, -- 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: Monday, August 12, 2013 8:44 AM To: Music Encoding Initiative Subject: Re: [MEI-L] halfmRpt and @rend FWIW, having looked at the same material, I also think a @rend would be very useful there. Raf On Mon, Aug 12, 2013 at 8:41 AM, Benjamin Wolff Bohl > wrote: Hi all, proofreading our data in Freisch?tz-Digital I came across repeat symbols. First case I was wondering whether to go with beatRpt but then I realized there was halmRpt, as well. As Weber writes his repeats as double slashes (not the common %) we're in eager need of @rend to indicate this circumstance. While @rend is available on beatRpt, it isn't on halfmRpt. Is there any reason for that, am I missing something? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zupftom at googlemail.com Mon Aug 12 20:37:17 2013 From: zupftom at googlemail.com (TW) Date: Mon, 12 Aug 2013 20:37:17 +0200 Subject: [MEI-L] halfmRpt and @rend In-Reply-To: References: <5208F4E2.5050602@edirom.de> Message-ID: This is interesting, we were about to bring up a similar problem with the Corpus monodicum encoding. In my understanding, @altsym was meant to provide rendering information, not to describe the appearance of a source. But, as I understand it, the suggested use of @altsym for the Freisch?tz would first and foremost encode the symbol found in the source. That's very similar to some requirements we have for Corpus monodicum, where editors want to encode certain symbols that scribes are using in the source (specifically: different variants of symbols with the same melodic meaning). Currently, we do this with annotations. However, we would like to also encode a table of all those variants that are used. In the printed edition, tables like this will be included and it would be sensible to also encode them in MEI. would come close to our requirements. However, rather than artificially recreating them with the vector elements available inside , we'd want to provide a scanned instance of each symbol. We have two suggestions to make: 1) Introduce another attribute that would serve as a complement to @altsym, but is intended for specifying that a certain symbol was used in the source. This pair would work exactly like the @style/@rend pair, one being for describing what's found, one indicating how it should be rendered. 2) Officially make multi-purpose (or introduce a similar structure, which however I don't favour). We'd need to provide a facsimile snippet with something like . Either this should be allowed inside , or we should be able to use the @facs mechanism, although this wouldn't be preferable in our case as we don't provide facsimiles 2013/8/12 Roland, Perry (pdr4h) : > Hmmm, forgot about that! > > > > If we proceed with plans to make @rend and @style available on more elements > but with generic typographic meaning, existing @rend attributes will have to > be replaced by some other attribute that carries element-specific > renditional information, possibly @form. For now, @altsym is the only other > option. Remember, however, that the value of @altsym must be a URI that > points to a symbolDef element. > > > > Considering the potential of SMuFL, I've been thinking a character-oriented > method for indicating an exact or alternate rendition might be another way > to go. We could, like TEI, provide for defining a character in the header > which is then pointed to using an attribute, similar to the way > and @altsym work), or we could allow text content of elements to contain > Unicode character references to codepoints defined by SMuFL. Another > possibility is to re-work so that it can hold the Unicode > reference (making it similar to TEI's ) which is pointed to using > @altsym as before. This is going to take a while to discuss and implement, > though. > > > > -- > > 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 Benjamin Wolff Bohl > [bohl at edirom.de] > Sent: Monday, August 12, 2013 10:44 AM > > To: Music Encoding Initiative > Subject: Re: [MEI-L] halfmRpt and @rend > > I just checked on mRpt and mRpt2, both of which don't allow @rend either. > Anyhow, all of the rpt elements allow @altsym. > > Considering this in combination with googlecode isuue 144 > (http://code.google.com/p/music-encoding/issues/detail?id=144) "reserve > @rend and @style for CSS-like renditional information", is it the right way > to go, or should we stick with @altsym and maybe disallow @rend on beatRpt? > > Best, > Benjamin > > *********************************************************** > Musikwissenschaftliches Seminar Detmold/Paderborn > BMBF-Projekt "Freisch?tz Digital" > Benjamin Wolff Bohl > Gartenstra?e 20 > D?32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > E-Mail: bohl at edirom.de > > http://www.freischuetz-digital.de > *********************************************************** > > Am 12.08.2013 15:20, schrieb Roland, Perry (pdr4h): > > Pretty sure that's an oversight. Please submit a ticket. > > > > Thanks, > > > > -- > > 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: Monday, August 12, 2013 8:44 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] halfmRpt and @rend > > FWIW, having looked at the same material, I also think a @rend would be very > useful there. > > Raf > > > On Mon, Aug 12, 2013 at 8:41 AM, Benjamin Wolff Bohl wrote: >> >> Hi all, >> >> proofreading our data in Freisch?tz-Digital I came across repeat symbols. >> First case I was wondering whether to go with beatRpt but then I realized >> there was halmRpt, as well. >> As Weber writes his repeats as double slashes (not the common %) we're in >> eager need of @rend to indicate this circumstance. While @rend is available >> on beatRpt, it isn't on halfmRpt. >> >> Is there any reason for that, am I missing something? >> >> 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 Mon Aug 12 20:44:43 2013 From: zupftom at googlemail.com (TW) Date: Mon, 12 Aug 2013 20:44:43 +0200 Subject: [MEI-L] halfmRpt and @rend In-Reply-To: References: <5208F4E2.5050602@edirom.de> Message-ID: I'm sorry, I accidentally hit Ctrl+Return, which made the Google webmail interface send my last mail before I was finished. Anyway, I wrote most of what I wanted to write. I guess I should write on ODD modification and provide that on mei-incubator to discuss this further. 2013/8/12 TW : > This is interesting, we were about to bring up a similar problem with > the Corpus monodicum encoding. In my understanding, @altsym was meant > to provide rendering information, not to describe the appearance of a > source. But, as I understand it, the suggested use of @altsym for the > Freisch?tz would first and foremost encode the symbol found in the > source. > > That's very similar to some requirements we have for Corpus monodicum, > where editors want to encode certain symbols that scribes are using in > the source (specifically: different variants of symbols with the same > melodic meaning). > > Currently, we do this with annotations. However, we would like to > also encode a table of all those variants that are used. In the > printed edition, tables like this will be included and it would be > sensible to also encode them in MEI. would come close > to our requirements. However, rather than artificially recreating > them with the vector elements available inside , we'd want to > provide a scanned instance of each symbol. > > We have two suggestions to make: > > 1) Introduce another attribute that would serve as a complement to > @altsym, but is intended for specifying that a certain symbol was used > in the source. This pair would work exactly like the @style/@rend > pair, one being for describing what's found, one indicating how it > should be rendered. > > 2) Officially make multi-purpose (or introduce a similar > structure, which however I don't favour). We'd need to provide a > facsimile snippet with something like . Either this should > be allowed inside , or we should be able to use the @facs > mechanism, although this wouldn't be preferable in our case as we > don't provide facsimiles > > > > 2013/8/12 Roland, Perry (pdr4h) : >> Hmmm, forgot about that! >> >> >> >> If we proceed with plans to make @rend and @style available on more elements >> but with generic typographic meaning, existing @rend attributes will have to >> be replaced by some other attribute that carries element-specific >> renditional information, possibly @form. For now, @altsym is the only other >> option. Remember, however, that the value of @altsym must be a URI that >> points to a symbolDef element. >> >> >> >> Considering the potential of SMuFL, I've been thinking a character-oriented >> method for indicating an exact or alternate rendition might be another way >> to go. We could, like TEI, provide for defining a character in the header >> which is then pointed to using an attribute, similar to the way >> and @altsym work), or we could allow text content of elements to contain >> Unicode character references to codepoints defined by SMuFL. Another >> possibility is to re-work so that it can hold the Unicode >> reference (making it similar to TEI's ) which is pointed to using >> @altsym as before. This is going to take a while to discuss and implement, >> though. >> >> >> >> -- >> >> 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 Benjamin Wolff Bohl >> [bohl at edirom.de] >> Sent: Monday, August 12, 2013 10:44 AM >> >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] halfmRpt and @rend >> >> I just checked on mRpt and mRpt2, both of which don't allow @rend either. >> Anyhow, all of the rpt elements allow @altsym. >> >> Considering this in combination with googlecode isuue 144 >> (http://code.google.com/p/music-encoding/issues/detail?id=144) "reserve >> @rend and @style for CSS-like renditional information", is it the right way >> to go, or should we stick with @altsym and maybe disallow @rend on beatRpt? >> >> Best, >> Benjamin >> >> *********************************************************** >> Musikwissenschaftliches Seminar Detmold/Paderborn >> BMBF-Projekt "Freisch?tz Digital" >> Benjamin Wolff Bohl >> Gartenstra?e 20 >> D?32756 Detmold >> >> Tel. +49 (0) 5231 / 975-669 >> Fax: +49 (0) 5231 / 975-668 >> E-Mail: bohl at edirom.de >> >> http://www.freischuetz-digital.de >> *********************************************************** >> >> Am 12.08.2013 15:20, schrieb Roland, Perry (pdr4h): >> >> Pretty sure that's an oversight. Please submit a ticket. >> >> >> >> Thanks, >> >> >> >> -- >> >> 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: Monday, August 12, 2013 8:44 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] halfmRpt and @rend >> >> FWIW, having looked at the same material, I also think a @rend would be very >> useful there. >> >> Raf >> >> >> On Mon, Aug 12, 2013 at 8:41 AM, Benjamin Wolff Bohl wrote: >>> >>> Hi all, >>> >>> proofreading our data in Freisch?tz-Digital I came across repeat symbols. >>> First case I was wondering whether to go with beatRpt but then I realized >>> there was halmRpt, as well. >>> As Weber writes his repeats as double slashes (not the common %) we're in >>> eager need of @rend to indicate this circumstance. While @rend is available >>> on beatRpt, it isn't on halfmRpt. >>> >>> Is there any reason for that, am I missing something? >>> >>> 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 Mon Aug 12 21:03:25 2013 From: zupftom at googlemail.com (TW) Date: Mon, 12 Aug 2013 21:03:25 +0200 Subject: [MEI-L] halfmRpt and @rend In-Reply-To: References: <5208F4E2.5050602@edirom.de> Message-ID: 2013/8/12 TW : > Anyway, I wrote most of what I wanted to write. I guess I should > write on ODD modification and provide that on mei-incubator to discuss > this further. > BTW: Wasn't there supposed to be a tutorial or guidelines concerning ODD modifications somewhere? From raffaeleviglianti at gmail.com Tue Aug 13 21:39:00 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 13 Aug 2013 15:39:00 -0400 Subject: [MEI-L] halfmRpt and @rend In-Reply-To: References: <5208F4E2.5050602@edirom.de> Message-ID: ODD works in the same way for both MEI and TEI. There's quite a bit of ODD documentation and tutorials for customizing TEI out there that you can use for your MEI work. Start from here: http://www.tei-c.org/Guidelines/Customization/odds.xml Raf On Mon, Aug 12, 2013 at 3:03 PM, TW wrote: > 2013/8/12 TW : > > Anyway, I wrote most of what I wanted to write. I guess I should > > write on ODD modification and provide that on mei-incubator to discuss > > this further. > > > > > BTW: Wasn't there supposed to be a tutorial or guidelines concerning > ODD modifications somewhere? > > _______________________________________________ > 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: From stadler at edirom.de Tue Aug 13 22:20:17 2013 From: stadler at edirom.de (Peter Stadler) Date: Tue, 13 Aug 2013 22:20:17 +0200 Subject: [MEI-L] halfmRpt and @rend In-Reply-To: References: <5208F4E2.5050602@edirom.de> Message-ID: Yeah, and there is an ODD workshop at the Edirom-Summer-School :-) http://ess.uni-paderborn.de/programm.html#odd Best Peter Am 13.08.2013 um 21:39 schrieb Raffaele Viglianti : > ODD works in the same way for both MEI and TEI. There's quite a bit of ODD documentation and tutorials for customizing TEI out there that you can use for your MEI work. Start from here: http://www.tei-c.org/Guidelines/Customization/odds.xml > > Raf > > > On Mon, Aug 12, 2013 at 3:03 PM, TW wrote: > 2013/8/12 TW : > > Anyway, I wrote most of what I wanted to write. I guess I should > > write on ODD modification and provide that on mei-incubator to discuss > > this further. > > > > > BTW: Wasn't there supposed to be a tutorial or guidelines concerning > ODD modifications somewhere? > -- Peter Stadler Carl-Maria-von-Weber-Gesamtausgabe Arbeitsstelle Detmold Gartenstr. 20 D-32756 Detmold Tel. +49 5231 975-665 Fax: +49 5231 975-668 stadler at weber-gesamtausgabe.de www.weber-gesamtausgabe.de -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 455 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From bohl at edirom.de Wed Aug 14 17:25:19 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Wed, 14 Aug 2013 17:25:19 +0200 Subject: [MEI-L] Learning ODD (from: halfmRpt and @rend) In-Reply-To: References: <5208F4E2.5050602@edirom.de> Message-ID: <520BA15F.8000503@edirom.de> Now guess what I was going to post ;-) Hi Thomas, although a TEI resource, concerning ODD you might consider: http://www.tei-c.org/Guidelines/Customization/odds.xml or come to Edirom-Summer-School 2013 to Peter's ODD course (http://ess.uni-paderborn.de) Cheers, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 12.08.2013 21:03, schrieb TW: > 2013/8/12 TW : >> Anyway, I wrote most of what I wanted to write. I guess I should >> write on ODD modification and provide that on mei-incubator to discuss >> this further. >> > > BTW: Wasn't there supposed to be a tutorial or guidelines concerning > ODD modifications somewhere? > > _______________________________________________ > 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 Aug 14 18:31:20 2013 From: zupftom at googlemail.com (TW) Date: Wed, 14 Aug 2013 18:31:20 +0200 Subject: [MEI-L] Learning ODD (from: halfmRpt and @rend) In-Reply-To: <520BA15F.8000503@edirom.de> References: <5208F4E2.5050602@edirom.de> <520BA15F.8000503@edirom.de> Message-ID: Thanks for that link, Raffaele and Benjamin. (Due to family duties, Edirom Summer School unfortunately is not an option for me.) 2013/8/14 Benjamin Wolff Bohl : > Now guess what I was going to post ;-) > > Hi Thomas, > > although a TEI resource, > concerning ODD you might consider: > http://www.tei-c.org/Guidelines/Customization/odds.xml > > or come to Edirom-Summer-School 2013 to Peter's ODD course > (http://ess.uni-paderborn.de) > > Cheers, > Benjamin > > *********************************************************** > Musikwissenschaftliches Seminar Detmold/Paderborn > BMBF-Projekt "Freisch?tz Digital" > Benjamin Wolff Bohl > Gartenstra?e 20 > D?32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > E-Mail: bohl at edirom.de > > http://www.freischuetz-digital.de > *********************************************************** > > Am 12.08.2013 21:03, schrieb TW: >> >> 2013/8/12 TW : >>> >>> Anyway, I wrote most of what I wanted to write. I guess I should >>> write on ODD modification and provide that on mei-incubator to discuss >>> this further. >>> >> >> BTW: Wasn't there supposed to be a tutorial or guidelines concerning >> ODD modifications somewhere? >> >> _______________________________________________ >> 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 bohl at edirom.de Thu Aug 15 11:21:23 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 15 Aug 2013 11:21:23 +0200 Subject: [MEI-L] where to report broken link in guidelines In-Reply-To: References: <5208F4E2.5050602@edirom.de> <520BA15F.8000503@edirom.de> Message-ID: <520C9D93.8090608@edirom.de> Hi all, recently when browsing the online MEI guidelines (big thanks for that!) I stumbled over a broken link in CMN chapter 4.2.6.1 Breath Marks with the link text "23 User-defined Symbols". Actually it points to: http://www.music-encoding.org/documentation/guidelines2013/#userSymbols the hash is the problem as it works with http://www.music-encoding.org/documentation/guidelines2013/userSymbols Moreover when rechecking just a minute ago, I realised that: http://www.music-encoding.org/documentation/guidelines2013 will succeed whereas: http://www.music-encoding.org/documentation/guidelines2013/ will not!! Is there a correct place to report these things to? Best, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** From andrew.hankinson at mail.mcgill.ca Thu Aug 15 16:12:14 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Thu, 15 Aug 2013 14:12:14 +0000 Subject: [MEI-L] File extensions Message-ID: Hi all, Is there a common understanding of what the proper file extension for MEI files should be? I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? -Andrew ==== Related: -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? From kepper at edirom.de Thu Aug 15 16:21:34 2013 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 15 Aug 2013 16:21:34 +0200 Subject: [MEI-L] File extensions In-Reply-To: References: Message-ID: Hi Andrew, I'm using .mei when I code by hand. However, I have to admit that sometimes I use .xml, namely when I work in an eXist XML database and don't want to explain the database that .mei doesn't mean it's a binary file? I would classify this as bad behavior, or maybe even laziness, but I don't think we had a discussion about the recommended way yet. If we would come up with a consensus that .mei should be used, I'd be happy to improve myself :-) I like the idea of registering a mimetype, but I have no clue how this works? just my (private) two cents jo Am 15.08.2013 um 16:12 schrieb Andrew Hankinson: > Hi all, > > Is there a common understanding of what the proper file extension for MEI files should be? > > I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? > > -Andrew > > ==== > Related: > -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? > > > _______________________________________________ > 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 Thu Aug 15 16:22:38 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 15 Aug 2013 10:22:38 -0400 Subject: [MEI-L] File extensions In-Reply-To: References: Message-ID: XML is XML, I think. So I use .xml regularly. Not a big fan of .mei, .tei, .odd that I see around sometimes. It's possibly a small thing, but I just see that as a file association nightmare in any OS :P On Thu, Aug 15, 2013 at 10:12 AM, Andrew Hankinson < andrew.hankinson at mail.mcgill.ca> wrote: > Hi all, > > Is there a common understanding of what the proper file extension for MEI > files should be? > > I've been assuming .mei is the "standard", but a counter-example of .xml > was recently brought to my attention. So, I thought I'd poll the collected > wisdom and see what others were doing. Are you using .xml, .mei, or some > other variation on these? > > -Andrew > > ==== > Related: > -- Should we register an actual mimetype? Maybe: > application/vnd.music-encoding+xml ? > > > _______________________________________________ > 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: From raffaeleviglianti at gmail.com Thu Aug 15 16:32:19 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 15 Aug 2013 10:32:19 -0400 Subject: [MEI-L] File extensions In-Reply-To: References: Message-ID: FWIW, this was TEI's application for a mimetype. I don't *think* it was successful, I might be wrong. http://tools.ietf.org/html/draft-lundberg-app-tei-xml-02 Raf On Thu, Aug 15, 2013 at 10:22 AM, Raffaele Viglianti < raffaeleviglianti at gmail.com> wrote: > XML is XML, I think. > > So I use .xml regularly. Not a big fan of .mei, .tei, .odd that I see > around sometimes. It's possibly a small thing, but I just see that as a > file association nightmare in any OS :P > > > > On Thu, Aug 15, 2013 at 10:12 AM, Andrew Hankinson < > andrew.hankinson at mail.mcgill.ca> wrote: > >> Hi all, >> >> Is there a common understanding of what the proper file extension for MEI >> files should be? >> >> I've been assuming .mei is the "standard", but a counter-example of .xml >> was recently brought to my attention. So, I thought I'd poll the collected >> wisdom and see what others were doing. Are you using .xml, .mei, or some >> other variation on these? >> >> -Andrew >> >> ==== >> Related: >> -- Should we register an actual mimetype? Maybe: >> application/vnd.music-encoding+xml ? >> >> >> _______________________________________________ >> 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: From andrew.hankinson at mail.mcgill.ca Thu Aug 15 16:38:19 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Thu, 15 Aug 2013 14:38:19 +0000 Subject: [MEI-L] File extensions In-Reply-To: <18277_1376577173_520CE692_18277_266_1_CAMyHAnNyigCCz3DyvMEdCrqn52cdWzYGFJn5En3wCB9S9Wfgiw@mail.gmail.com> References: <18277_1376577173_520CE692_18277_266_1_CAMyHAnNyigCCz3DyvMEdCrqn52cdWzYGFJn5En3wCB9S9Wfgiw@mail.gmail.com> Message-ID: I suspect that it wasn't successful because they applied for the standards track, and not the vendor-specific track. The former needs to be published by a recognized standards committee, while the latter can be more free but needs to have 'vnd.' prepended. On 2013-08-15, at 4:32 PM, Raffaele Viglianti > wrote: FWIW, this was TEI's application for a mimetype. I don't *think* it was successful, I might be wrong. http://tools.ietf.org/html/draft-lundberg-app-tei-xml-02 Raf On Thu, Aug 15, 2013 at 10:22 AM, Raffaele Viglianti > wrote: XML is XML, I think. So I use .xml regularly. Not a big fan of .mei, .tei, .odd that I see around sometimes. It's possibly a small thing, but I just see that as a file association nightmare in any OS :P On Thu, Aug 15, 2013 at 10:12 AM, Andrew Hankinson > wrote: Hi all, Is there a common understanding of what the proper file extension for MEI files should be? I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? -Andrew ==== Related: -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? _______________________________________________ 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: From slu at kb.dk Thu Aug 15 16:39:26 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Thu, 15 Aug 2013 14:39:26 +0000 Subject: [MEI-L] File extensions In-Reply-To: References: Message-ID: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> Hi, I'm using .xml as suffix. Don't really care. As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. Cheers Sigfrid ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 15. august 2013 16:12 Til: Music Encoding Initiative Emne: [MEI-L] File extensions Hi all, Is there a common understanding of what the proper file extension for MEI files should be? I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? -Andrew ==== Related: -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From slu at kb.dk Thu Aug 15 16:44:39 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Thu, 15 Aug 2013 14:44:39 +0000 Subject: [MEI-L] File extensions In-Reply-To: References: <18277_1376577173_520CE692_18277_266_1_CAMyHAnNyigCCz3DyvMEdCrqn52cdWzYGFJn5En3wCB9S9Wfgiw@mail.gmail.com>, Message-ID: <0C090608704AF04E898055296C932B129B82783A@EXCHANGE-01.kb.dk> True, we had problems. But then I got hold of someone who explained and resubmitted it as an informational RFC. It wen't through 8 peer reviewers before it was accepted since it is a voting system within the IESG. Most of them just said "yes" Sigfrid ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 15. august 2013 16:38 Til: Music Encoding Initiative Emne: Re: [MEI-L] File extensions I suspect that it wasn't successful because they applied for the standards track, and not the vendor-specific track. The former needs to be published by a recognized standards committee, while the latter can be more free but needs to have 'vnd.' prepended. On 2013-08-15, at 4:32 PM, Raffaele Viglianti > wrote: FWIW, this was TEI's application for a mimetype. I don't *think* it was successful, I might be wrong. http://tools.ietf.org/html/draft-lundberg-app-tei-xml-02 Raf On Thu, Aug 15, 2013 at 10:22 AM, Raffaele Viglianti > wrote: XML is XML, I think. So I use .xml regularly. Not a big fan of .mei, .tei, .odd that I see around sometimes. It's possibly a small thing, but I just see that as a file association nightmare in any OS :P On Thu, Aug 15, 2013 at 10:12 AM, Andrew Hankinson > wrote: Hi all, Is there a common understanding of what the proper file extension for MEI files should be? I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? -Andrew ==== Related: -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? _______________________________________________ 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 Thu Aug 15 16:44:55 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 15 Aug 2013 14:44:55 +0000 Subject: [MEI-L] File extensions In-Reply-To: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> References: , <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> Message-ID: Hi Sigfrid, Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) -- 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 Sigfrid Lundberg [slu at kb.dk] Sent: Thursday, August 15, 2013 10:39 AM To: Music Encoding Initiative Subject: Re: [MEI-L] File extensions Hi, I'm using .xml as suffix. Don't really care. As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. Cheers Sigfrid ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 15. august 2013 16:12 Til: Music Encoding Initiative Emne: [MEI-L] File extensions Hi all, Is there a common understanding of what the proper file extension for MEI files should be? I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? -Andrew ==== Related: -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? _______________________________________________ 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 slu at kb.dk Thu Aug 15 16:49:43 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Thu, 15 Aug 2013 14:49:43 +0000 Subject: [MEI-L] File extensions In-Reply-To: References: , <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk>, Message-ID: <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> My keyboard is too fast. Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure S ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] Sendt: 15. august 2013 16:44 Til: Music Encoding Initiative Emne: Re: [MEI-L] File extensions Hi Sigfrid, Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) -- 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 Sigfrid Lundberg [slu at kb.dk] Sent: Thursday, August 15, 2013 10:39 AM To: Music Encoding Initiative Subject: Re: [MEI-L] File extensions Hi, I'm using .xml as suffix. Don't really care. As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. Cheers Sigfrid ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 15. august 2013 16:12 Til: Music Encoding Initiative Emne: [MEI-L] File extensions Hi all, Is there a common understanding of what the proper file extension for MEI files should be? I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? -Andrew ==== Related: -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? _______________________________________________ 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 Thu Aug 15 17:09:28 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 15 Aug 2013 15:09:28 +0000 Subject: [MEI-L] File extensions In-Reply-To: <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> References: , <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk>, , <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> Message-ID: Sigge, Thanks for being so gracious in your acceptance of my effort to "volunteer" you. There's no rush on this. After Christmas/beginning of 2014 is fine. I'm sure you'll find willing volunteers to help you write the proposal. You can "volunteer" me in return. :-) Anyone who wants to participate, please contact Sigge. I hear he's starting a list. :-) Thanks again, -- 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 Sigfrid Lundberg [slu at kb.dk] Sent: Thursday, August 15, 2013 10:49 AM To: Music Encoding Initiative Subject: Re: [MEI-L] File extensions My keyboard is too fast. Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure S ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] Sendt: 15. august 2013 16:44 Til: Music Encoding Initiative Emne: Re: [MEI-L] File extensions Hi Sigfrid, Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) -- 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 Sigfrid Lundberg [slu at kb.dk] Sent: Thursday, August 15, 2013 10:39 AM To: Music Encoding Initiative Subject: Re: [MEI-L] File extensions Hi, I'm using .xml as suffix. Don't really care. As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. Cheers Sigfrid ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 15. august 2013 16:12 Til: Music Encoding Initiative Emne: [MEI-L] File extensions Hi all, Is there a common understanding of what the proper file extension for MEI files should be? I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? -Andrew ==== Related: -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? _______________________________________________ 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 Thu Aug 15 17:23:02 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Thu, 15 Aug 2013 15:23:02 +0000 Subject: [MEI-L] File extensions In-Reply-To: <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> References: , <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk>, , <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> Message-ID: You can sign me up too. Personally, I like .mei. XML could also be thought of as plain text, so I would argue that we should go with the most specific usage, rather than the most general. We could just go with .txt and be just as correct as .xml. Either way, though, I think this is an appropriate topic for putting some guidance in the Guidelines. I'll volunteer to write it, but I would like some way of getting a consensus. Any ideas? An online poll? -Andrew On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" wrote: > > Sigge, > > Thanks for being so gracious in your acceptance of my effort to "volunteer" you. > > There's no rush on this. After Christmas/beginning of 2014 is fine. I'm sure you'll find willing volunteers to help you write the proposal. You can "volunteer" me in return. :-) > > Anyone who wants to participate, please contact Sigge. I hear he's starting a list. :-) > > Thanks again, > > -- > 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 Sigfrid Lundberg [slu at kb.dk] > Sent: Thursday, August 15, 2013 10:49 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] File extensions > > My keyboard is too fast. > > Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure > > S > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] > Sendt: 15. august 2013 16:44 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] File extensions > > Hi Sigfrid, > > Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) > > -- > 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 Sigfrid Lundberg [slu at kb.dk] > Sent: Thursday, August 15, 2013 10:39 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] File extensions > > Hi, > > I'm using .xml as suffix. Don't really care. > > As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. > > Cheers > > Sigfrid > > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sendt: 15. august 2013 16:12 > Til: Music Encoding Initiative > Emne: [MEI-L] File extensions > > Hi all, > > Is there a common understanding of what the proper file extension for MEI files should be? > > I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? > > -Andrew > > ==== > Related: > -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? > > > _______________________________________________ > 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 slu at kb.dk Thu Aug 15 17:47:41 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Thu, 15 Aug 2013 15:47:41 +0000 Subject: [MEI-L] File extensions In-Reply-To: References: , <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk>, , <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu>, Message-ID: <0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> .txt is a poor choice. Most web servers will deliver that as text/plain which is not what you want. In apache web server there is a file mime-types which connects extensions to mime types, which then interacts with users web clients and plug-ins and helper applications Sigfrid ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 15. august 2013 17:23 Til: Music Encoding Initiative Emne: Re: [MEI-L] File extensions You can sign me up too. Personally, I like .mei. XML could also be thought of as plain text, so I would argue that we should go with the most specific usage, rather than the most general. We could just go with .txt and be just as correct as .xml. Either way, though, I think this is an appropriate topic for putting some guidance in the Guidelines. I'll volunteer to write it, but I would like some way of getting a consensus. Any ideas? An online poll? -Andrew On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" wrote: > > Sigge, > > Thanks for being so gracious in your acceptance of my effort to "volunteer" you. > > There's no rush on this. After Christmas/beginning of 2014 is fine. I'm sure you'll find willing volunteers to help you write the proposal. You can "volunteer" me in return. :-) > > Anyone who wants to participate, please contact Sigge. I hear he's starting a list. :-) > > Thanks again, > > -- > 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 Sigfrid Lundberg [slu at kb.dk] > Sent: Thursday, August 15, 2013 10:49 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] File extensions > > My keyboard is too fast. > > Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure > > S > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] > Sendt: 15. august 2013 16:44 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] File extensions > > Hi Sigfrid, > > Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) > > -- > 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 Sigfrid Lundberg [slu at kb.dk] > Sent: Thursday, August 15, 2013 10:39 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] File extensions > > Hi, > > I'm using .xml as suffix. Don't really care. > > As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. > > Cheers > > Sigfrid > > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sendt: 15. august 2013 16:12 > Til: Music Encoding Initiative > Emne: [MEI-L] File extensions > > Hi all, > > Is there a common understanding of what the proper file extension for MEI files should be? > > I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? > > -Andrew > > ==== > Related: > -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? > > > _______________________________________________ > 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 zupftom at googlemail.com Thu Aug 15 17:58:40 2013 From: zupftom at googlemail.com (TW) Date: Thu, 15 Aug 2013 17:58:40 +0200 Subject: [MEI-L] File extensions In-Reply-To: <0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> References: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> <0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> Message-ID: 2013/8/15 Sigfrid Lundberg : > .txt is a poor choice. Most web servers will deliver that as text/plain which is not what you want. In apache web server there is a file mime-types which connects extensions to mime types, which then interacts with users web clients and plug-ins and helper applications > In that regard, .mei would be the perfect choice because if there's a MIME type for MEI one day, the webserver can easily be told how to deliver .mei files in the htaccess. From andrew.hankinson at mail.mcgill.ca Thu Aug 15 18:02:36 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Thu, 15 Aug 2013 16:02:36 +0000 Subject: [MEI-L] File extensions In-Reply-To: <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> References: , <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk>, , <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu>, <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> Message-ID: I was using it more as an illustration than a suggestion. I brought the extension topic up because I look at these being our options for mime type settings: application/xml .xml -> Straightforward, generic, but what if you have a consumer that can take MEI files directly? We have notation software that can serve MEI XML, so it would be nice if we can take advantage of the mime types here. application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type seems like a big problem. application/vnd.mei+xml .mei -> Seems like the best solution, yes? (the MEI mime type I give is just an example). -Andrew On 2013-08-15, at 5:47 PM, Sigfrid Lundberg wrote: > .txt is a poor choice. Most web servers will deliver that as text/plain which is not what you want. In apache web server there is a file mime-types which connects extensions to mime types, which then interacts with users web clients and plug-ins and helper applications > > Sigfrid > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sendt: 15. august 2013 17:23 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] File extensions > > You can sign me up too. > > Personally, I like .mei. XML could also be thought of as plain text, so I would argue that we should go with the most specific usage, rather than the most general. We could just go with .txt and be just as correct as .xml. > > Either way, though, I think this is an appropriate topic for putting some guidance in the Guidelines. I'll volunteer to write it, but I would like some way of getting a consensus. > > Any ideas? An online poll? > > -Andrew > > On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > wrote: > >> >> Sigge, >> >> Thanks for being so gracious in your acceptance of my effort to "volunteer" you. >> >> There's no rush on this. After Christmas/beginning of 2014 is fine. I'm sure you'll find willing volunteers to help you write the proposal. You can "volunteer" me in return. :-) >> >> Anyone who wants to participate, please contact Sigge. I hear he's starting a list. :-) >> >> Thanks again, >> >> -- >> 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 Sigfrid Lundberg [slu at kb.dk] >> Sent: Thursday, August 15, 2013 10:49 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] File extensions >> >> My keyboard is too fast. >> >> Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure >> >> S >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] >> Sendt: 15. august 2013 16:44 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] File extensions >> >> Hi Sigfrid, >> >> Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) >> >> -- >> 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 Sigfrid Lundberg [slu at kb.dk] >> Sent: Thursday, August 15, 2013 10:39 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] File extensions >> >> Hi, >> >> I'm using .xml as suffix. Don't really care. >> >> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. >> >> Cheers >> >> Sigfrid >> >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >> Sendt: 15. august 2013 16:12 >> Til: Music Encoding Initiative >> Emne: [MEI-L] File extensions >> >> Hi all, >> >> Is there a common understanding of what the proper file extension for MEI files should be? >> >> I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? >> >> -Andrew >> >> ==== >> Related: >> -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? >> >> >> _______________________________________________ >> 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 slu at kb.dk Thu Aug 15 18:08:01 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Thu, 15 Aug 2013 16:08:01 +0000 Subject: [MEI-L] File extensions In-Reply-To: References: , <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk>, , <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu>, <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk>, Message-ID: <0C090608704AF04E898055296C932B129B8278AD@EXCHANGE-01.kb.dk> Why is vnd important? Sigfrid ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 15. august 2013 18:02 Til: Music Encoding Initiative Emne: Re: [MEI-L] File extensions I was using it more as an illustration than a suggestion. I brought the extension topic up because I look at these being our options for mime type settings: application/xml .xml -> Straightforward, generic, but what if you have a consumer that can take MEI files directly? We have notation software that can serve MEI XML, so it would be nice if we can take advantage of the mime types here. application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type seems like a big problem. application/vnd.mei+xml .mei -> Seems like the best solution, yes? (the MEI mime type I give is just an example). -Andrew On 2013-08-15, at 5:47 PM, Sigfrid Lundberg wrote: > .txt is a poor choice. Most web servers will deliver that as text/plain which is not what you want. In apache web server there is a file mime-types which connects extensions to mime types, which then interacts with users web clients and plug-ins and helper applications > > Sigfrid > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sendt: 15. august 2013 17:23 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] File extensions > > You can sign me up too. > > Personally, I like .mei. XML could also be thought of as plain text, so I would argue that we should go with the most specific usage, rather than the most general. We could just go with .txt and be just as correct as .xml. > > Either way, though, I think this is an appropriate topic for putting some guidance in the Guidelines. I'll volunteer to write it, but I would like some way of getting a consensus. > > Any ideas? An online poll? > > -Andrew > > On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > wrote: > >> >> Sigge, >> >> Thanks for being so gracious in your acceptance of my effort to "volunteer" you. >> >> There's no rush on this. After Christmas/beginning of 2014 is fine. I'm sure you'll find willing volunteers to help you write the proposal. You can "volunteer" me in return. :-) >> >> Anyone who wants to participate, please contact Sigge. I hear he's starting a list. :-) >> >> Thanks again, >> >> -- >> 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 Sigfrid Lundberg [slu at kb.dk] >> Sent: Thursday, August 15, 2013 10:49 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] File extensions >> >> My keyboard is too fast. >> >> Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure >> >> S >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] >> Sendt: 15. august 2013 16:44 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] File extensions >> >> Hi Sigfrid, >> >> Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) >> >> -- >> 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 Sigfrid Lundberg [slu at kb.dk] >> Sent: Thursday, August 15, 2013 10:39 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] File extensions >> >> Hi, >> >> I'm using .xml as suffix. Don't really care. >> >> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. >> >> Cheers >> >> Sigfrid >> >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >> Sendt: 15. august 2013 16:12 >> Til: Music Encoding Initiative >> Emne: [MEI-L] File extensions >> >> Hi all, >> >> Is there a common understanding of what the proper file extension for MEI files should be? >> >> I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? >> >> -Andrew >> >> ==== >> Related: >> -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? >> >> >> _______________________________________________ >> 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 raffaeleviglianti at gmail.com Thu Aug 15 18:27:05 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 15 Aug 2013 12:27:05 -0400 Subject: [MEI-L] File extensions In-Reply-To: References: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> Message-ID: On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson < andrew.hankinson at mail.mcgill.ca> wrote: > > application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type seems > like a big problem. > > application/vnd.mei+xml .mei -> Seems like the best solution, yes? > As far as I know mimetype is orthogonal to file extension, so even if we secure a mimetype application/mei+xml it won't matter if your file has .xml or .mei extension. I personally don't see an issue with file extension at all. What's the problem with using either .mei or .xml? In a web context all that matters is the mimetype, in a OS context, using .xml is generally going to make things easier, but it's not eventually not a big deal. Raf > > (the MEI mime type I give is just an example). > > -Andrew > > > On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > wrote: > > > .txt is a poor choice. Most web servers will deliver that as text/plain > which is not what you want. In apache web server there is a file mime-types > which connects extensions to mime types, which then interacts with users > web clients and plug-ins and helper applications > > > > Sigfrid > > ________________________________________ > > Fra: mei-l-bounces at lists.uni-paderborn.de [ > mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [ > andrew.hankinson at mail.mcgill.ca] > > Sendt: 15. august 2013 17:23 > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] File extensions > > > > You can sign me up too. > > > > Personally, I like .mei. XML could also be thought of as plain text, so > I would argue that we should go with the most specific usage, rather than > the most general. We could just go with .txt and be just as correct as .xml. > > > > Either way, though, I think this is an appropriate topic for putting > some guidance in the Guidelines. I'll volunteer to write it, but I would > like some way of getting a consensus. > > > > Any ideas? An online poll? > > > > -Andrew > > > > On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" < > pdr4h at eservices.virginia.edu> > > wrote: > > > >> > >> Sigge, > >> > >> Thanks for being so gracious in your acceptance of my effort to > "volunteer" you. > >> > >> There's no rush on this. After Christmas/beginning of 2014 is fine. > I'm sure you'll find willing volunteers to help you write the proposal. > You can "volunteer" me in return. :-) > >> > >> Anyone who wants to participate, please contact Sigge. I hear he's > starting a list. :-) > >> > >> Thanks again, > >> > >> -- > >> 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 Sigfrid Lundberg [ > slu at kb.dk] > >> Sent: Thursday, August 15, 2013 10:49 AM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] File extensions > >> > >> My keyboard is too fast. > >> > >> Cannot promise to write it alone and have to discuss it here in > Copenhagen. Not before Christmas, that's for sure > >> > >> S > >> ________________________________________ > >> Fra: mei-l-bounces at lists.uni-paderborn.de [ > mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry > (pdr4h) [pdr4h at eservices.virginia.edu] > >> Sendt: 15. august 2013 16:44 > >> Til: Music Encoding Initiative > >> Emne: Re: [MEI-L] File extensions > >> > >> Hi Sigfrid, > >> > >> Sounds like we have a volunteer to lead the way to registering an MEI > mimetype. :-) > >> > >> -- > >> 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 Sigfrid Lundberg [ > slu at kb.dk] > >> Sent: Thursday, August 15, 2013 10:39 AM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] File extensions > >> > >> Hi, > >> > >> I'm using .xml as suffix. Don't really care. > >> > >> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I > have strong opinions on your "by the way" question. Yes, we should register > a mime type, and it should be application/mei+xml. Since it is in the > application hierarchy it requires an RFC and some negotiations with IESG > and IETF before one get a line in the appropriate IANA document. > >> > >> Cheers > >> > >> Sigfrid > >> > >> ________________________________________ > >> Fra: mei-l-bounces at lists.uni-paderborn.de [ > mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [ > andrew.hankinson at mail.mcgill.ca] > >> Sendt: 15. august 2013 16:12 > >> Til: Music Encoding Initiative > >> Emne: [MEI-L] File extensions > >> > >> Hi all, > >> > >> Is there a common understanding of what the proper file extension for > MEI files should be? > >> > >> I've been assuming .mei is the "standard", but a counter-example of > .xml was recently brought to my attention. So, I thought I'd poll the > collected wisdom and see what others were doing. Are you using .xml, .mei, > or some other variation on these? > >> > >> -Andrew > >> > >> ==== > >> Related: > >> -- Should we register an actual mimetype? Maybe: > application/vnd.music-encoding+xml ? > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bohl at edirom.de Fri Aug 16 09:54:21 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 16 Aug 2013 09:54:21 +0200 Subject: [MEI-L] File extensions In-Reply-To: References: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> Message-ID: <520DDAAD.9090905@edirom.de> Just to put my two cents in: I use .xml no matter what schema I am working with. I never used .mei If I remember correctly, even TEI'S ROMA tool oputputs the ODD files as .xml and that's fine. This way you do not have to have the knowledge that you can use a XML (or even Text) editor to open it. One can rely on the filesystem to handle the data in an appropriate manner. Bst Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D--32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 15.08.2013 18:27, schrieb Raffaele Viglianti: > > On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson > > wrote: > > > application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type > seems like a big problem. > > application/vnd.mei+xml .mei -> Seems like the best solution, yes? > > > As far as I know mimetype is orthogonal to file extension, so even if > we secure a mimetype application/mei+xml it won't matter if your file > has .xml or .mei extension. > > I personally don't see an issue with file extension at all. What's the > problem with using either .mei or .xml? In a web context all that > matters is the mimetype, in a OS context, using .xml is generally > going to make things easier, but it's not eventually not a big deal. > > Raf > > > (the MEI mime type I give is just an example). > > -Andrew > > > On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > > wrote: > > > .txt is a poor choice. Most web servers will deliver that as > text/plain which is not what you want. In apache web server there > is a file mime-types which connects extensions to mime types, > which then interacts with users web clients and plug-ins and > helper applications > > > > Sigfrid > > ________________________________________ > > Fra: mei-l-bounces at lists.uni-paderborn.de > > [mei-l-bounces at lists.uni-paderborn.de > ] på vegne af > Andrew Hankinson [andrew.hankinson at mail.mcgill.ca > ] > > Sendt: 15. august 2013 17:23 > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] File extensions > > > > You can sign me up too. > > > > Personally, I like .mei. XML could also be thought of as plain > text, so I would argue that we should go with the most specific > usage, rather than the most general. We could just go with .txt > and be just as correct as .xml. > > > > Either way, though, I think this is an appropriate topic for > putting some guidance in the Guidelines. I'll volunteer to write > it, but I would like some way of getting a consensus. > > > > Any ideas? An online poll? > > > > -Andrew > > > > On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > > > > wrote: > > > >> > >> Sigge, > >> > >> Thanks for being so gracious in your acceptance of my effort to > "volunteer" you. > >> > >> There's no rush on this. After Christmas/beginning of 2014 is > fine. I'm sure you'll find willing volunteers to help you write > the proposal. You can "volunteer" me in return. :-) > >> > >> Anyone who wants to participate, please contact Sigge. I hear > he's starting a list. :-) > >> > >> Thanks again, > >> > >> -- > >> 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 Sigfrid > Lundberg [slu at kb.dk ] > >> Sent: Thursday, August 15, 2013 10:49 AM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] File extensions > >> > >> My keyboard is too fast. > >> > >> Cannot promise to write it alone and have to discuss it here in > Copenhagen. Not before Christmas, that's for sure > >> > >> S > >> ________________________________________ > >> Fra: mei-l-bounces at lists.uni-paderborn.de > > [mei-l-bounces at lists.uni-paderborn.de > ] på vegne af > Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu > ] > >> Sendt: 15. august 2013 16:44 > >> Til: Music Encoding Initiative > >> Emne: Re: [MEI-L] File extensions > >> > >> Hi Sigfrid, > >> > >> Sounds like we have a volunteer to lead the way to registering > an MEI mimetype. :-) > >> > >> -- > >> 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 > Sigfrid Lundberg [slu at kb.dk ] > >> Sent: Thursday, August 15, 2013 10:39 AM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] File extensions > >> > >> Hi, > >> > >> I'm using .xml as suffix. Don't really care. > >> > >> As I'm a coauthor of RFC6129 > (http://tools.ietf.org/html/rfc6129) I have strong opinions on > your "by the way" question. Yes, we should register a mime type, > and it should be application/mei+xml. Since it is in the > application hierarchy it requires an RFC and some negotiations > with IESG and IETF before one get a line in the appropriate IANA > document. > >> > >> Cheers > >> > >> Sigfrid > >> > >> ________________________________________ > >> Fra: mei-l-bounces at lists.uni-paderborn.de > > [mei-l-bounces at lists.uni-paderborn.de > ] på vegne af > Andrew Hankinson [andrew.hankinson at mail.mcgill.ca > ] > >> Sendt: 15. august 2013 16:12 > >> Til: Music Encoding Initiative > >> Emne: [MEI-L] File extensions > >> > >> Hi all, > >> > >> Is there a common understanding of what the proper file > extension for MEI files should be? > >> > >> I've been assuming .mei is the "standard", but a > counter-example of .xml was recently brought to my attention. So, > I thought I'd poll the collected wisdom and see what others were > doing. Are you using .xml, .mei, or some other variation on these? > >> > >> -Andrew > >> > >> ==== > >> Related: > >> -- Should we register an actual mimetype? Maybe: > application/vnd.music-encoding+xml ? > >> > >> > >> _______________________________________________ > >> 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 -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From bohl at edirom.de Fri Aug 16 09:54:26 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 16 Aug 2013 09:54:26 +0200 Subject: [MEI-L] File extensions In-Reply-To: References: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> Message-ID: <520DDAB2.60106@edirom.de> Just to put my two cents in: I use .xml no matter what schema I am working with. I never used .mei If I remember correctly, even TEI'S ROMA tool oputputs the ODD files as .xml and that's fine. This way you do not have to have the knowledge that you can use a XML (or even Text) editor to open it. One can rely on the filesystem to handle the data in an appropriate manner. Best Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D--32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 15.08.2013 18:27, schrieb Raffaele Viglianti: > > On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson > > wrote: > > > application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type > seems like a big problem. > > application/vnd.mei+xml .mei -> Seems like the best solution, yes? > > > As far as I know mimetype is orthogonal to file extension, so even if > we secure a mimetype application/mei+xml it won't matter if your file > has .xml or .mei extension. > > I personally don't see an issue with file extension at all. What's the > problem with using either .mei or .xml? In a web context all that > matters is the mimetype, in a OS context, using .xml is generally > going to make things easier, but it's not eventually not a big deal. > > Raf > > > (the MEI mime type I give is just an example). > > -Andrew > > > On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > > wrote: > > > .txt is a poor choice. Most web servers will deliver that as > text/plain which is not what you want. In apache web server there > is a file mime-types which connects extensions to mime types, > which then interacts with users web clients and plug-ins and > helper applications > > > > Sigfrid > > ________________________________________ > > Fra: mei-l-bounces at lists.uni-paderborn.de > > [mei-l-bounces at lists.uni-paderborn.de > ] på vegne af > Andrew Hankinson [andrew.hankinson at mail.mcgill.ca > ] > > Sendt: 15. august 2013 17:23 > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] File extensions > > > > You can sign me up too. > > > > Personally, I like .mei. XML could also be thought of as plain > text, so I would argue that we should go with the most specific > usage, rather than the most general. We could just go with .txt > and be just as correct as .xml. > > > > Either way, though, I think this is an appropriate topic for > putting some guidance in the Guidelines. I'll volunteer to write > it, but I would like some way of getting a consensus. > > > > Any ideas? An online poll? > > > > -Andrew > > > > On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > > > > wrote: > > > >> > >> Sigge, > >> > >> Thanks for being so gracious in your acceptance of my effort to > "volunteer" you. > >> > >> There's no rush on this. After Christmas/beginning of 2014 is > fine. I'm sure you'll find willing volunteers to help you write > the proposal. You can "volunteer" me in return. :-) > >> > >> Anyone who wants to participate, please contact Sigge. I hear > he's starting a list. :-) > >> > >> Thanks again, > >> > >> -- > >> 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 Sigfrid > Lundberg [slu at kb.dk ] > >> Sent: Thursday, August 15, 2013 10:49 AM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] File extensions > >> > >> My keyboard is too fast. > >> > >> Cannot promise to write it alone and have to discuss it here in > Copenhagen. Not before Christmas, that's for sure > >> > >> S > >> ________________________________________ > >> Fra: mei-l-bounces at lists.uni-paderborn.de > > [mei-l-bounces at lists.uni-paderborn.de > ] på vegne af > Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu > ] > >> Sendt: 15. august 2013 16:44 > >> Til: Music Encoding Initiative > >> Emne: Re: [MEI-L] File extensions > >> > >> Hi Sigfrid, > >> > >> Sounds like we have a volunteer to lead the way to registering > an MEI mimetype. :-) > >> > >> -- > >> 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 > Sigfrid Lundberg [slu at kb.dk ] > >> Sent: Thursday, August 15, 2013 10:39 AM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] File extensions > >> > >> Hi, > >> > >> I'm using .xml as suffix. Don't really care. > >> > >> As I'm a coauthor of RFC6129 > (http://tools.ietf.org/html/rfc6129) I have strong opinions on > your "by the way" question. Yes, we should register a mime type, > and it should be application/mei+xml. Since it is in the > application hierarchy it requires an RFC and some negotiations > with IESG and IETF before one get a line in the appropriate IANA > document. > >> > >> Cheers > >> > >> Sigfrid > >> > >> ________________________________________ > >> Fra: mei-l-bounces at lists.uni-paderborn.de > > [mei-l-bounces at lists.uni-paderborn.de > ] på vegne af > Andrew Hankinson [andrew.hankinson at mail.mcgill.ca > ] > >> Sendt: 15. august 2013 16:12 > >> Til: Music Encoding Initiative > >> Emne: [MEI-L] File extensions > >> > >> Hi all, > >> > >> Is there a common understanding of what the proper file > extension for MEI files should be? > >> > >> I've been assuming .mei is the "standard", but a > counter-example of .xml was recently brought to my attention. So, > I thought I'd poll the collected wisdom and see what others were > doing. Are you using .xml, .mei, or some other variation on these? > >> > >> -Andrew > >> > >> ==== > >> Related: > >> -- Should we register an actual mimetype? Maybe: > application/vnd.music-encoding+xml ? > >> > >> > >> _______________________________________________ > >> 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 -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From andrew.hankinson at mail.mcgill.ca Fri Aug 16 23:53:35 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 16 Aug 2013 21:53:35 +0000 Subject: [MEI-L] File extensions In-Reply-To: <32319_1376584102_520D01A5_32319_65_14_CAMyHAnMf_iRiVdvcp487sSzYYm0ibTeBDGNP4-vi82e=ZTNPHw@mail.gmail.com> References: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> <32319_1376584102_520D01A5_32319_65_14_CAMyHAnMf_iRiVdvcp487sSzYYm0ibTeBDGNP4-vi82e=ZTNPHw@mail.gmail.com> Message-ID: Not quite orthogonal. A web server will serve files with the specified extension as a given mime-type. It's true that you can write the mime type to the header if you're in a web application environment, but by registering a mime type we can provide a method for placing MEI files on a server, and it opening in a default application on the users' machine, for example. This can be especially useful in a mobile environment, where sometimes you have limited control over which application will open a downloaded file. So, in a web context the extension does matter, since (by default) the web server will serve files with a given extension with a certain mime type. That's the second part of the mime type definition for servers: "application/vnd.mei+xml .mei" maps all .mei files to the application/vnd.mei+xml mime type. Using .xml is fine if you want to open it in an XML editor. However, if we want to open it in a notation editor (dreaming of the future) then it's best if we choose .mei now, and then allow the user to specify the application that handles it as needed. To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I understand, appending vnd. makes the mime type registration process much easier, since it doesn't need to go through the standards bodies to be approved. The MusicXML mime type uses the vnd. prefix, something like "application/vnd.recordare-musicxml+xml" So I thought that we might go for the easy registration first. It doesn't preclude later registration of a more formal mimetype. But here I will defer to those with more experience in the process. -Andrew On 2013-08-15, at 6:27 PM, Raffaele Viglianti > wrote: On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson > wrote: application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type seems like a big problem. application/vnd.mei+xml .mei -> Seems like the best solution, yes? As far as I know mimetype is orthogonal to file extension, so even if we secure a mimetype application/mei+xml it won't matter if your file has .xml or .mei extension. I personally don't see an issue with file extension at all. What's the problem with using either .mei or .xml? In a web context all that matters is the mimetype, in a OS context, using .xml is generally going to make things easier, but it's not eventually not a big deal. Raf (the MEI mime type I give is just an example). -Andrew On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > wrote: > .txt is a poor choice. Most web servers will deliver that as text/plain which is not what you want. In apache web server there is a file mime-types which connects extensions to mime types, which then interacts with users web clients and plug-ins and helper applications > > Sigfrid > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sendt: 15. august 2013 17:23 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] File extensions > > You can sign me up too. > > Personally, I like .mei. XML could also be thought of as plain text, so I would argue that we should go with the most specific usage, rather than the most general. We could just go with .txt and be just as correct as .xml. > > Either way, though, I think this is an appropriate topic for putting some guidance in the Guidelines. I'll volunteer to write it, but I would like some way of getting a consensus. > > Any ideas? An online poll? > > -Andrew > > On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > > wrote: > >> >> Sigge, >> >> Thanks for being so gracious in your acceptance of my effort to "volunteer" you. >> >> There's no rush on this. After Christmas/beginning of 2014 is fine. I'm sure you'll find willing volunteers to help you write the proposal. You can "volunteer" me in return. :-) >> >> Anyone who wants to participate, please contact Sigge. I hear he's starting a list. :-) >> >> Thanks again, >> >> -- >> 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 Sigfrid Lundberg [slu at kb.dk] >> Sent: Thursday, August 15, 2013 10:49 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] File extensions >> >> My keyboard is too fast. >> >> Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure >> >> S >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] >> Sendt: 15. august 2013 16:44 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] File extensions >> >> Hi Sigfrid, >> >> Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) >> >> -- >> 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 Sigfrid Lundberg [slu at kb.dk] >> Sent: Thursday, August 15, 2013 10:39 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] File extensions >> >> Hi, >> >> I'm using .xml as suffix. Don't really care. >> >> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. >> >> Cheers >> >> Sigfrid >> >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >> Sendt: 15. august 2013 16:12 >> Til: Music Encoding Initiative >> Emne: [MEI-L] File extensions >> >> Hi all, >> >> Is there a common understanding of what the proper file extension for MEI files should be? >> >> I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? >> >> -Andrew >> >> ==== >> Related: >> -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From slu at kb.dk Mon Aug 19 09:18:35 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Mon, 19 Aug 2013 07:18:35 +0000 Subject: [MEI-L] File extensions In-Reply-To: References: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> <32319_1376584102_520D01A5_32319_65_14_CAMyHAnMf_iRiVdvcp487sSzYYm0ibTeBDGNP4-vi82e=ZTNPHw@mail.gmail.com>, Message-ID: <0C090608704AF04E898055296C932B129B827B99@EXCHANGE-01.kb.dk> I know that, but why do you want it to register it as a vendor specific format. We're creating a standard, arn't we? Sigge ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 16. august 2013 23:53 Til: Music Encoding Initiative Emne: Re: [MEI-L] File extensions Not quite orthogonal. A web server will serve files with the specified extension as a given mime-type. It's true that you can write the mime type to the header if you're in a web application environment, but by registering a mime type we can provide a method for placing MEI files on a server, and it opening in a default application on the users' machine, for example. This can be especially useful in a mobile environment, where sometimes you have limited control over which application will open a downloaded file. So, in a web context the extension does matter, since (by default) the web server will serve files with a given extension with a certain mime type. That's the second part of the mime type definition for servers: "application/vnd.mei+xml .mei" maps all .mei files to the application/vnd.mei+xml mime type. Using .xml is fine if you want to open it in an XML editor. However, if we want to open it in a notation editor (dreaming of the future) then it's best if we choose .mei now, and then allow the user to specify the application that handles it as needed. To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I understand, appending vnd. makes the mime type registration process much easier, since it doesn't need to go through the standards bodies to be approved. The MusicXML mime type uses the vnd. prefix, something like "application/vnd.recordare-musicxml+xml" So I thought that we might go for the easy registration first. It doesn't preclude later registration of a more formal mimetype. But here I will defer to those with more experience in the process. -Andrew On 2013-08-15, at 6:27 PM, Raffaele Viglianti > wrote: On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson > wrote: application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type seems like a big problem. application/vnd.mei+xml .mei -> Seems like the best solution, yes? As far as I know mimetype is orthogonal to file extension, so even if we secure a mimetype application/mei+xml it won't matter if your file has .xml or .mei extension. I personally don't see an issue with file extension at all. What's the problem with using either .mei or .xml? In a web context all that matters is the mimetype, in a OS context, using .xml is generally going to make things easier, but it's not eventually not a big deal. Raf (the MEI mime type I give is just an example). -Andrew On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > wrote: > .txt is a poor choice. Most web servers will deliver that as text/plain which is not what you want. In apache web server there is a file mime-types which connects extensions to mime types, which then interacts with users web clients and plug-ins and helper applications > > Sigfrid > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sendt: 15. august 2013 17:23 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] File extensions > > You can sign me up too. > > Personally, I like .mei. XML could also be thought of as plain text, so I would argue that we should go with the most specific usage, rather than the most general. We could just go with .txt and be just as correct as .xml. > > Either way, though, I think this is an appropriate topic for putting some guidance in the Guidelines. I'll volunteer to write it, but I would like some way of getting a consensus. > > Any ideas? An online poll? > > -Andrew > > On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > > wrote: > >> >> Sigge, >> >> Thanks for being so gracious in your acceptance of my effort to "volunteer" you. >> >> There's no rush on this. After Christmas/beginning of 2014 is fine. I'm sure you'll find willing volunteers to help you write the proposal. You can "volunteer" me in return. :-) >> >> Anyone who wants to participate, please contact Sigge. I hear he's starting a list. :-) >> >> Thanks again, >> >> -- >> 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 Sigfrid Lundberg [slu at kb.dk] >> Sent: Thursday, August 15, 2013 10:49 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] File extensions >> >> My keyboard is too fast. >> >> Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure >> >> S >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] >> Sendt: 15. august 2013 16:44 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] File extensions >> >> Hi Sigfrid, >> >> Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) >> >> -- >> 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 Sigfrid Lundberg [slu at kb.dk] >> Sent: Thursday, August 15, 2013 10:39 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] File extensions >> >> Hi, >> >> I'm using .xml as suffix. Don't really care. >> >> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. >> >> Cheers >> >> Sigfrid >> >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >> Sendt: 15. august 2013 16:12 >> Til: Music Encoding Initiative >> Emne: [MEI-L] File extensions >> >> Hi all, >> >> Is there a common understanding of what the proper file extension for MEI files should be? >> >> I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? >> >> -Andrew >> >> ==== >> Related: >> -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? >> >> >> _______________________________________________ >> 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 Mon Aug 19 11:51:15 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 19 Aug 2013 09:51:15 +0000 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: <20670_1376896736_5211C6E0_20670_118_1_0C090608704AF04E898055296C932B129B827B99@EXCHANGE-01.kb.dk> References: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> <32319_1376584102_520D01A5_32319_65_14_CAMyHAnMf_iRiVdvcp487sSzYYm0ibTeBDGNP4-vi82e=ZTNPHw@mail.gmail.com>, <20670_1376896736_5211C6E0_20670_118_1_0C090608704AF04E898055296C932B129B827B99@EXCHANGE-01.kb.dk> Message-ID: Oof. That's a can of worms. Warning: Lots of opinions to follow. If you're creating physical widgets where part A needs to fit with part B, big-S Standards can be a great thing. For a small and loosely-bound community like MEI, a Standard wouldn't really bring much to the table, and, I think, would actually cause more harm than good. What do we standardize? The complete ODD file, including the parts of the ODD file that are mutually exclusive? (see: integration of both mensural and CMN timing modules?) The CMN customization? Any decision to standardize something will likely exclude a significant part of the community. We can't even come to a consensus about which file extension to use! What MEI brings to the world isn't actually an XML schema. I like to think that you can express MEI in any formalized structure. XML brings the ability to validate and impose constraints, but if XML was to be eclipsed by another structural language (like SGML was eclipsed by XML?) then I think that the intellectual structure of MEI could simply be transplanted to the new system. So, in a roundabout answer to your question: No, I don't think we're creating a Standard. I think we're creating a method, and I think with time and usage certain parts of this method may emerge to a de-facto standard, or even, yes, a Standard. But MEI as a whole? I don't think we should even think of trying to register this as a Standard. There's just too many moving parts. A vendor-specific mime type seems to be the most flexible method. In my reading about mime type registration, the "x-" prefix was used for experimental or non-standard use. Since RFC6648, however, this has been deprecated. Current best practice, as far as I can tell, says that non-standards-track mime types should be registered under the vendor-specific or personal (vanity) track. I would be happy to be corrected, though -- I'm new at this! So, application/vnd.mei+xml, or application/vnd.mei+json, or application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle [1] --- all of these are possibilities, but trying to go through the Standardization process for them seems like a lot of work for little, no, or even negative gain. -Andrew [1] http://www.candlescript.org/doc/candle-markup-reference.htm On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: > I know that, but why do you want it to register it as a vendor specific format. > > We're creating a standard, arn't we? > > Sigge > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sendt: 16. august 2013 23:53 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] File extensions > > Not quite orthogonal. A web server will serve files with the specified extension as a given mime-type. It's true that you can write the mime type to the header if you're in a web application environment, but by registering a mime type we can provide a method for placing MEI files on a server, and it opening in a default application on the users' machine, for example. > > This can be especially useful in a mobile environment, where sometimes you have limited control over which application will open a downloaded file. > > So, in a web context the extension does matter, since (by default) the web server will serve files with a given extension with a certain mime type. That's the second part of the mime type definition for servers: "application/vnd.mei+xml .mei" maps all .mei files to the application/vnd.mei+xml mime type. > > Using .xml is fine if you want to open it in an XML editor. However, if we want to open it in a notation editor (dreaming of the future) then it's best if we choose .mei now, and then allow the user to specify the application that handles it as needed. > > To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I understand, appending vnd. makes the mime type registration process much easier, since it doesn't need to go through the standards bodies to be approved. The MusicXML mime type uses the vnd. prefix, something like "application/vnd.recordare-musicxml+xml" So I thought that we might go for the easy registration first. It doesn't preclude later registration of a more formal mimetype. But here I will defer to those with more experience in the process. > > -Andrew > > > On 2013-08-15, at 6:27 PM, Raffaele Viglianti > wrote: > > > On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson > wrote: > > application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type seems like a big problem. > > application/vnd.mei+xml .mei -> Seems like the best solution, yes? > > As far as I know mimetype is orthogonal to file extension, so even if we secure a mimetype application/mei+xml it won't matter if your file has .xml or .mei extension. > > I personally don't see an issue with file extension at all. What's the problem with using either .mei or .xml? In a web context all that matters is the mimetype, in a OS context, using .xml is generally going to make things easier, but it's not eventually not a big deal. > > Raf > > > (the MEI mime type I give is just an example). > > -Andrew > > > On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > > wrote: > >> .txt is a poor choice. Most web servers will deliver that as text/plain which is not what you want. In apache web server there is a file mime-types which connects extensions to mime types, which then interacts with users web clients and plug-ins and helper applications >> >> Sigfrid >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >> Sendt: 15. august 2013 17:23 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] File extensions >> >> You can sign me up too. >> >> Personally, I like .mei. XML could also be thought of as plain text, so I would argue that we should go with the most specific usage, rather than the most general. We could just go with .txt and be just as correct as .xml. >> >> Either way, though, I think this is an appropriate topic for putting some guidance in the Guidelines. I'll volunteer to write it, but I would like some way of getting a consensus. >> >> Any ideas? An online poll? >> >> -Andrew >> >> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > >> wrote: >> >>> >>> Sigge, >>> >>> Thanks for being so gracious in your acceptance of my effort to "volunteer" you. >>> >>> There's no rush on this. After Christmas/beginning of 2014 is fine. I'm sure you'll find willing volunteers to help you write the proposal. You can "volunteer" me in return. :-) >>> >>> Anyone who wants to participate, please contact Sigge. I hear he's starting a list. :-) >>> >>> Thanks again, >>> >>> -- >>> 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 Sigfrid Lundberg [slu at kb.dk] >>> Sent: Thursday, August 15, 2013 10:49 AM >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] File extensions >>> >>> My keyboard is too fast. >>> >>> Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure >>> >>> S >>> ________________________________________ >>> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] >>> Sendt: 15. august 2013 16:44 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] File extensions >>> >>> Hi Sigfrid, >>> >>> Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) >>> >>> -- >>> 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 Sigfrid Lundberg [slu at kb.dk] >>> Sent: Thursday, August 15, 2013 10:39 AM >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] File extensions >>> >>> Hi, >>> >>> I'm using .xml as suffix. Don't really care. >>> >>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. >>> >>> Cheers >>> >>> Sigfrid >>> >>> ________________________________________ >>> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >>> Sendt: 15. august 2013 16:12 >>> Til: Music Encoding Initiative >>> Emne: [MEI-L] File extensions >>> >>> Hi all, >>> >>> Is there a common understanding of what the proper file extension for MEI files should be? >>> >>> I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? >>> >>> -Andrew >>> >>> ==== >>> Related: >>> -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? >>> >>> >>> _______________________________________________ >>> 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 slu at kb.dk Mon Aug 19 12:28:23 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Mon, 19 Aug 2013 10:28:23 +0000 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: References: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> <32319_1376584102_520D01A5_32319_65_14_CAMyHAnMf_iRiVdvcp487sSzYYm0ibTeBDGNP4-vi82e=ZTNPHw@mail.gmail.com>, <20670_1376896736_5211C6E0_20670_118_1_0C090608704AF04E898055296C932B129B827B99@EXCHANGE-01.kb.dk>, Message-ID: <0C090608704AF04E898055296C932B129B827C76@EXCHANGE-01.kb.dk> Sorry for using the word standard. Suppose it is better to describe our business as we are dealers in methodologies for the description of what is known about pieces of symbolic music. As a long term subscriber to the xml-dev list I'm used to worms, which doesn't mean that I like them, or even eat them. Sigfrid ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 19. august 2013 11:51 Til: Music Encoding Initiative Emne: Re: [MEI-L] Standards (was: File extensions) Oof. That's a can of worms. Warning: Lots of opinions to follow. If you're creating physical widgets where part A needs to fit with part B, big-S Standards can be a great thing. For a small and loosely-bound community like MEI, a Standard wouldn't really bring much to the table, and, I think, would actually cause more harm than good. What do we standardize? The complete ODD file, including the parts of the ODD file that are mutually exclusive? (see: integration of both mensural and CMN timing modules?) The CMN customization? Any decision to standardize something will likely exclude a significant part of the community. We can't even come to a consensus about which file extension to use! What MEI brings to the world isn't actually an XML schema. I like to think that you can express MEI in any formalized structure. XML brings the ability to validate and impose constraints, but if XML was to be eclipsed by another structural language (like SGML was eclipsed by XML?) then I think that the intellectual structure of MEI could simply be transplanted to the new system. So, in a roundabout answer to your question: No, I don't think we're creating a Standard. I think we're creating a method, and I think with time and usage certain parts of this method may emerge to a de-facto standard, or even, yes, a Standard. But MEI as a whole? I don't think we should even think of trying to register this as a Standard. There's just too many moving parts. A vendor-specific mime type seems to be the most flexible method. In my reading about mime type registration, the "x-" prefix was used for experimental or non-standard use. Since RFC6648, however, this has been deprecated. Current best practice, as far as I can tell, says that non-standards-track mime types should be registered under the vendor-specific or personal (vanity) track. I would be happy to be corrected, though -- I'm new at this! So, application/vnd.mei+xml, or application/vnd.mei+json, or application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle [1] --- all of these are possibilities, but trying to go through the Standardization process for them seems like a lot of work for little, no, or even negative gain. -Andrew [1] http://www.candlescript.org/doc/candle-markup-reference.htm On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: > I know that, but why do you want it to register it as a vendor specific format. > > We're creating a standard, arn't we? > > Sigge > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sendt: 16. august 2013 23:53 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] File extensions > > Not quite orthogonal. A web server will serve files with the specified extension as a given mime-type. It's true that you can write the mime type to the header if you're in a web application environment, but by registering a mime type we can provide a method for placing MEI files on a server, and it opening in a default application on the users' machine, for example. > > This can be especially useful in a mobile environment, where sometimes you have limited control over which application will open a downloaded file. > > So, in a web context the extension does matter, since (by default) the web server will serve files with a given extension with a certain mime type. That's the second part of the mime type definition for servers: "application/vnd.mei+xml .mei" maps all .mei files to the application/vnd.mei+xml mime type. > > Using .xml is fine if you want to open it in an XML editor. However, if we want to open it in a notation editor (dreaming of the future) then it's best if we choose .mei now, and then allow the user to specify the application that handles it as needed. > > To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I understand, appending vnd. makes the mime type registration process much easier, since it doesn't need to go through the standards bodies to be approved. The MusicXML mime type uses the vnd. prefix, something like "application/vnd.recordare-musicxml+xml" So I thought that we might go for the easy registration first. It doesn't preclude later registration of a more formal mimetype. But here I will defer to those with more experience in the process. > > -Andrew > > > On 2013-08-15, at 6:27 PM, Raffaele Viglianti > wrote: > > > On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson > wrote: > > application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type seems like a big problem. > > application/vnd.mei+xml .mei -> Seems like the best solution, yes? > > As far as I know mimetype is orthogonal to file extension, so even if we secure a mimetype application/mei+xml it won't matter if your file has .xml or .mei extension. > > I personally don't see an issue with file extension at all. What's the problem with using either .mei or .xml? In a web context all that matters is the mimetype, in a OS context, using .xml is generally going to make things easier, but it's not eventually not a big deal. > > Raf > > > (the MEI mime type I give is just an example). > > -Andrew > > > On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > > wrote: > >> .txt is a poor choice. Most web servers will deliver that as text/plain which is not what you want. In apache web server there is a file mime-types which connects extensions to mime types, which then interacts with users web clients and plug-ins and helper applications >> >> Sigfrid >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >> Sendt: 15. august 2013 17:23 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] File extensions >> >> You can sign me up too. >> >> Personally, I like .mei. XML could also be thought of as plain text, so I would argue that we should go with the most specific usage, rather than the most general. We could just go with .txt and be just as correct as .xml. >> >> Either way, though, I think this is an appropriate topic for putting some guidance in the Guidelines. I'll volunteer to write it, but I would like some way of getting a consensus. >> >> Any ideas? An online poll? >> >> -Andrew >> >> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > >> wrote: >> >>> >>> Sigge, >>> >>> Thanks for being so gracious in your acceptance of my effort to "volunteer" you. >>> >>> There's no rush on this. After Christmas/beginning of 2014 is fine. I'm sure you'll find willing volunteers to help you write the proposal. You can "volunteer" me in return. :-) >>> >>> Anyone who wants to participate, please contact Sigge. I hear he's starting a list. :-) >>> >>> Thanks again, >>> >>> -- >>> 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 Sigfrid Lundberg [slu at kb.dk] >>> Sent: Thursday, August 15, 2013 10:49 AM >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] File extensions >>> >>> My keyboard is too fast. >>> >>> Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure >>> >>> S >>> ________________________________________ >>> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] >>> Sendt: 15. august 2013 16:44 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] File extensions >>> >>> Hi Sigfrid, >>> >>> Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) >>> >>> -- >>> 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 Sigfrid Lundberg [slu at kb.dk] >>> Sent: Thursday, August 15, 2013 10:39 AM >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] File extensions >>> >>> Hi, >>> >>> I'm using .xml as suffix. Don't really care. >>> >>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. >>> >>> Cheers >>> >>> Sigfrid >>> >>> ________________________________________ >>> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >>> Sendt: 15. august 2013 16:12 >>> Til: Music Encoding Initiative >>> Emne: [MEI-L] File extensions >>> >>> Hi all, >>> >>> Is there a common understanding of what the proper file extension for MEI files should be? >>> >>> I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? >>> >>> -Andrew >>> >>> ==== >>> Related: >>> -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ 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 19 12:40:12 2013 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 19 Aug 2013 12:40:12 +0200 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: <0C090608704AF04E898055296C932B129B827C76@EXCHANGE-01.kb.dk> References: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> <32319_1376584102_520D01A5_32319_65_14_CAMyHAnMf_iRiVdvcp487sSzYYm0ibTeBDGNP4-vi82e=ZTNPHw@mail.gmail.com>, <20670_1376896736_5211C6E0_20670_118_1_0C090608704AF04E898055296C932B129B827B99@EXCHANGE-01.kb.dk>, <0C090608704AF04E898055296C932B129B827C76@EXCHANGE-01.kb.dk> Message-ID: two cents from someone who's completely in the dark? I don't like the "vendor" term: To my (non-native english) ears, it sounds a little bit too commercial. It may or may not fit for MusicXML, but it doesn't seem to fit for us. If there are other tracks, we should follow them instead. If (S|s)tandard in the mimetype sense means something completely determined, it's not appropriate for us. We shouldn't restrict our future development by stocking ourselves to one specific version of MEI which may not be changed easily anymore. I wouldn't even do this for a defined subset of MEI (like cmn), as it has the potential to cannibalize the community, weakening support for other, more obscure parts of MEI. However, if (S|s)tandard is meant to be more open, I'm fine with this. For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one mimetype? If so, it seems comparable to our situation. best, jo Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg : > Sorry for using the word standard. > > Suppose it is better to describe our business as we are dealers in methodologies for the description of what is known about pieces of symbolic music. > > As a long term subscriber to the xml-dev list I'm used to worms, which doesn't mean that I like them, or even eat them. > > Sigfrid > > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sendt: 19. august 2013 11:51 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] Standards (was: File extensions) > > Oof. That's a can of worms. > > Warning: Lots of opinions to follow. > > If you're creating physical widgets where part A needs to fit with part B, big-S Standards can be a great thing. > > For a small and loosely-bound community like MEI, a Standard wouldn't really bring much to the table, and, I think, would actually cause more harm than good. What do we standardize? The complete ODD file, including the parts of the ODD file that are mutually exclusive? (see: integration of both mensural and CMN timing modules?) The CMN customization? Any decision to standardize something will likely exclude a significant part of the community. We can't even come to a consensus about which file extension to use! > > What MEI brings to the world isn't actually an XML schema. I like to think that you can express MEI in any formalized structure. XML brings the ability to validate and impose constraints, but if XML was to be eclipsed by another structural language (like SGML was eclipsed by XML?) then I think that the intellectual structure of MEI could simply be transplanted to the new system. > > So, in a roundabout answer to your question: No, I don't think we're creating a Standard. I think we're creating a method, and I think with time and usage certain parts of this method may emerge to a de-facto standard, or even, yes, a Standard. But MEI as a whole? I don't think we should even think of trying to register this as a Standard. There's just too many moving parts. > > A vendor-specific mime type seems to be the most flexible method. In my reading about mime type registration, the "x-" prefix was used for experimental or non-standard use. Since RFC6648, however, this has been deprecated. Current best practice, as far as I can tell, says that non-standards-track mime types should be registered under the vendor-specific or personal (vanity) track. I would be happy to be corrected, though -- I'm new at this! > > So, application/vnd.mei+xml, or application/vnd.mei+json, or application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle [1] --- all of these are possibilities, but trying to go through the Standardization process for them seems like a lot of work for little, no, or even negative gain. > > -Andrew > > [1] http://www.candlescript.org/doc/candle-markup-reference.htm > > On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: > >> I know that, but why do you want it to register it as a vendor specific format. >> >> We're creating a standard, arn't we? >> >> Sigge >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >> Sendt: 16. august 2013 23:53 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] File extensions >> >> Not quite orthogonal. A web server will serve files with the specified extension as a given mime-type. It's true that you can write the mime type to the header if you're in a web application environment, but by registering a mime type we can provide a method for placing MEI files on a server, and it opening in a default application on the users' machine, for example. >> >> This can be especially useful in a mobile environment, where sometimes you have limited control over which application will open a downloaded file. >> >> So, in a web context the extension does matter, since (by default) the web server will serve files with a given extension with a certain mime type. That's the second part of the mime type definition for servers: "application/vnd.mei+xml .mei" maps all .mei files to the application/vnd.mei+xml mime type. >> >> Using .xml is fine if you want to open it in an XML editor. However, if we want to open it in a notation editor (dreaming of the future) then it's best if we choose .mei now, and then allow the user to specify the application that handles it as needed. >> >> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I understand, appending vnd. makes the mime type registration process much easier, since it doesn't need to go through the standards bodies to be approved. The MusicXML mime type uses the vnd. prefix, something like "application/vnd.recordare-musicxml+xml" So I thought that we might go for the easy registration first. It doesn't preclude later registration of a more formal mimetype. But here I will defer to those with more experience in the process. >> >> -Andrew >> >> >> On 2013-08-15, at 6:27 PM, Raffaele Viglianti > wrote: >> >> >> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson > wrote: >> >> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type seems like a big problem. >> >> application/vnd.mei+xml .mei -> Seems like the best solution, yes? >> >> As far as I know mimetype is orthogonal to file extension, so even if we secure a mimetype application/mei+xml it won't matter if your file has .xml or .mei extension. >> >> I personally don't see an issue with file extension at all. What's the problem with using either .mei or .xml? In a web context all that matters is the mimetype, in a OS context, using .xml is generally going to make things easier, but it's not eventually not a big deal. >> >> Raf >> >> >> (the MEI mime type I give is just an example). >> >> -Andrew >> >> >> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > >> wrote: >> >>> .txt is a poor choice. Most web servers will deliver that as text/plain which is not what you want. In apache web server there is a file mime-types which connects extensions to mime types, which then interacts with users web clients and plug-ins and helper applications >>> >>> Sigfrid >>> ________________________________________ >>> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >>> Sendt: 15. august 2013 17:23 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] File extensions >>> >>> You can sign me up too. >>> >>> Personally, I like .mei. XML could also be thought of as plain text, so I would argue that we should go with the most specific usage, rather than the most general. We could just go with .txt and be just as correct as .xml. >>> >>> Either way, though, I think this is an appropriate topic for putting some guidance in the Guidelines. I'll volunteer to write it, but I would like some way of getting a consensus. >>> >>> Any ideas? An online poll? >>> >>> -Andrew >>> >>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > >>> wrote: >>> >>>> >>>> Sigge, >>>> >>>> Thanks for being so gracious in your acceptance of my effort to "volunteer" you. >>>> >>>> There's no rush on this. After Christmas/beginning of 2014 is fine. I'm sure you'll find willing volunteers to help you write the proposal. You can "volunteer" me in return. :-) >>>> >>>> Anyone who wants to participate, please contact Sigge. I hear he's starting a list. :-) >>>> >>>> Thanks again, >>>> >>>> -- >>>> 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 Sigfrid Lundberg [slu at kb.dk] >>>> Sent: Thursday, August 15, 2013 10:49 AM >>>> To: Music Encoding Initiative >>>> Subject: Re: [MEI-L] File extensions >>>> >>>> My keyboard is too fast. >>>> >>>> Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure >>>> >>>> S >>>> ________________________________________ >>>> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] >>>> Sendt: 15. august 2013 16:44 >>>> Til: Music Encoding Initiative >>>> Emne: Re: [MEI-L] File extensions >>>> >>>> Hi Sigfrid, >>>> >>>> Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) >>>> >>>> -- >>>> 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 Sigfrid Lundberg [slu at kb.dk] >>>> Sent: Thursday, August 15, 2013 10:39 AM >>>> To: Music Encoding Initiative >>>> Subject: Re: [MEI-L] File extensions >>>> >>>> Hi, >>>> >>>> I'm using .xml as suffix. Don't really care. >>>> >>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. >>>> >>>> Cheers >>>> >>>> Sigfrid >>>> >>>> ________________________________________ >>>> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >>>> Sendt: 15. august 2013 16:12 >>>> Til: Music Encoding Initiative >>>> Emne: [MEI-L] File extensions >>>> >>>> Hi all, >>>> >>>> Is there a common understanding of what the proper file extension for MEI files should be? >>>> >>>> I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? >>>> >>>> -Andrew >>>> >>>> ==== >>>> Related: >>>> -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > 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 dave at create.aau.dk Mon Aug 19 13:26:48 2013 From: dave at create.aau.dk (David Meredith) Date: Mon, 19 Aug 2013 11:26:48 +0000 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: Message-ID: Hi all, Tomorrow, the "strategy" committee is having its first virtual meeting to discuss possible ways in which MEI can be managed in the future. I will be (tentatively) suggesting that we think about managing it as a W3C working group. And I have in my diary to prepare a short presentation this afternoon about this. (Sychronicity? :) ) My view is that MEI's volatile and diffuse definition and development is *THE* main reason why there has so far been so little interest in developing software to support it. Before developing software to support a particular file format (let's face it, that's basically what MEI is), a software developer needs 1. a clear definition of what the format is; 2. reasonable confidence that his/her software isn't going to become obsolete the next time the format's definition is revised; and 3. a good idea of how often the format's definition is going to be changed, so that they can plan new versions of the software that supports it. These can best be achieved by establishing MEI as a *standard*, with a properly published and managed definition and properly established processes for developing this definition to accommodate users' changing needs while keeping volatility and backwards incompatibility to a minimum so that developers aren't scared off. I'm not completely sure that the W3C route is necessarily the best one, but clearly we want some form of standardisation framework that is: 1. relatively low-ceremony: we're all volunteers, so we don't have oceans of time and money to spend on keeping MEI alive; 2. well-recognized and international so that we maximise the likelihood of people wanting to develop software to support MEI. If anyone else has experience with this kind of process and would like to contribute to tomorrow's meeting, please talk to Benjamin about it. I agree with Johannes that decisions about the definition and development of MEI should remain independent of commercial enterprises. MEI should be run by and for the academic community. However, I don't see how clarifying and stabilizing the definition and development of MEI would be in any sense detrimental. Cheers, Dave On 19/08/2013 12:40, "Johannes Kepper" wrote: >two cents from someone who's completely in the dark? > >I don't like the "vendor" term: To my (non-native english) ears, it >sounds a little bit too commercial. It may or may not fit for MusicXML, >but it doesn't seem to fit for us. If there are other tracks, we should >follow them instead. > >If (S|s)tandard in the mimetype sense means something completely >determined, it's not appropriate for us. We shouldn't restrict our future >development by stocking ourselves to one specific version of MEI which >may not be changed easily anymore. I wouldn't even do this for a defined >subset of MEI (like cmn), as it has the potential to cannibalize the >community, weakening support for other, more obscure parts of MEI. >However, if (S|s)tandard is meant to be more open, I'm fine with this. >For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one >mimetype? If so, it seems comparable to our situation. > > >best, >jo > > > > >Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg : > >> Sorry for using the word standard. >> >> Suppose it is better to describe our business as we are dealers in >>methodologies for the description of what is known about pieces of >>symbolic music. >> >> As a long term subscriber to the xml-dev list I'm used to worms, which >>doesn't mean that I like them, or even eat them. >> >> Sigfrid >> >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de >>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson >>[andrew.hankinson at mail.mcgill.ca] >> Sendt: 19. august 2013 11:51 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] Standards (was: File extensions) >> >> Oof. That's a can of worms. >> >> Warning: Lots of opinions to follow. >> >> If you're creating physical widgets where part A needs to fit with part >>B, big-S Standards can be a great thing. >> >> For a small and loosely-bound community like MEI, a Standard wouldn't >>really bring much to the table, and, I think, would actually cause more >>harm than good. What do we standardize? The complete ODD file, including >>the parts of the ODD file that are mutually exclusive? (see: integration >>of both mensural and CMN timing modules?) The CMN customization? Any >>decision to standardize something will likely exclude a significant part >>of the community. We can't even come to a consensus about which file >>extension to use! >> >> What MEI brings to the world isn't actually an XML schema. I like to >>think that you can express MEI in any formalized structure. XML brings >>the ability to validate and impose constraints, but if XML was to be >>eclipsed by another structural language (like SGML was eclipsed by XML?) >>then I think that the intellectual structure of MEI could simply be >>transplanted to the new system. >> >> So, in a roundabout answer to your question: No, I don't think we're >>creating a Standard. I think we're creating a method, and I think with >>time and usage certain parts of this method may emerge to a de-facto >>standard, or even, yes, a Standard. But MEI as a whole? I don't think we >>should even think of trying to register this as a Standard. There's just >>too many moving parts. >> >> A vendor-specific mime type seems to be the most flexible method. In my >>reading about mime type registration, the "x-" prefix was used for >>experimental or non-standard use. Since RFC6648, however, this has been >>deprecated. Current best practice, as far as I can tell, says that >>non-standards-track mime types should be registered under the >>vendor-specific or personal (vanity) track. I would be happy to be >>corrected, though -- I'm new at this! >> >> So, application/vnd.mei+xml, or application/vnd.mei+json, or >>application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle >>[1] --- all of these are possibilities, but trying to go through the >>Standardization process for them seems like a lot of work for little, >>no, or even negative gain. >> >> -Andrew >> >> [1] http://www.candlescript.org/doc/candle-markup-reference.htm >> >> On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: >> >>> I know that, but why do you want it to register it as a vendor >>>specific format. >>> >>> We're creating a standard, arn't we? >>> >>> Sigge >>> ________________________________________ >>> Fra: mei-l-bounces at lists.uni-paderborn.de >>>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew >>>Hankinson [andrew.hankinson at mail.mcgill.ca] >>> Sendt: 16. august 2013 23:53 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] File extensions >>> >>> Not quite orthogonal. A web server will serve files with the specified >>>extension as a given mime-type. It's true that you can write the mime >>>type to the header if you're in a web application environment, but by >>>registering a mime type we can provide a method for placing MEI files >>>on a server, and it opening in a default application on the users' >>>machine, for example. >>> >>> This can be especially useful in a mobile environment, where sometimes >>>you have limited control over which application will open a downloaded >>>file. >>> >>> So, in a web context the extension does matter, since (by default) the >>>web server will serve files with a given extension with a certain mime >>>type. That's the second part of the mime type definition for servers: >>>"application/vnd.mei+xml .mei" maps all .mei files to the >>>application/vnd.mei+xml mime type. >>> >>> Using .xml is fine if you want to open it in an XML editor. However, >>>if we want to open it in a notation editor (dreaming of the future) >>>then it's best if we choose .mei now, and then allow the user to >>>specify the application that handles it as needed. >>> >>> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I >>>understand, appending vnd. makes the mime type registration process >>>much easier, since it doesn't need to go through the standards bodies >>>to be approved. The MusicXML mime type uses the vnd. prefix, something >>>like "application/vnd.recordare-musicxml+xml" So I thought that we >>>might go for the easy registration first. It doesn't preclude later >>>registration of a more formal mimetype. But here I will defer to those >>>with more experience in the process. >>> >>> -Andrew >>> >>> >>> On 2013-08-15, at 6:27 PM, Raffaele Viglianti >>>> wrote: >>> >>> >>> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson >>> >>>> wrote: >>> >>> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type >>>seems like a big problem. >>> >>> application/vnd.mei+xml .mei -> Seems like the best solution, yes? >>> >>> As far as I know mimetype is orthogonal to file extension, so even if >>>we secure a mimetype application/mei+xml it won't matter if your file >>>has .xml or .mei extension. >>> >>> I personally don't see an issue with file extension at all. What's the >>>problem with using either .mei or .xml? In a web context all that >>>matters is the mimetype, in a OS context, using .xml is generally going >>>to make things easier, but it's not eventually not a big deal. >>> >>> Raf >>> >>> >>> (the MEI mime type I give is just an example). >>> >>> -Andrew >>> >>> >>> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg >>>> >>> wrote: >>> >>>> .txt is a poor choice. Most web servers will deliver that as >>>>text/plain which is not what you want. In apache web server there is a >>>>file mime-types which connects extensions to mime types, which then >>>>interacts with users web clients and plug-ins and helper applications >>>> >>>> Sigfrid >>>> ________________________________________ >>>> Fra: >>>>mei-l-bounces at lists.uni-paderborn.de>>>erborn.de> >>>>[mei-l-bounces at lists.uni-paderborn.de>>>derborn.de>] på vegne af Andrew Hankinson >>>>[andrew.hankinson at mail.mcgill.ca>>>>] >>>> Sendt: 15. august 2013 17:23 >>>> Til: Music Encoding Initiative >>>> Emne: Re: [MEI-L] File extensions >>>> >>>> You can sign me up too. >>>> >>>> Personally, I like .mei. XML could also be thought of as plain text, >>>>so I would argue that we should go with the most specific usage, >>>>rather than the most general. We could just go with .txt and be just >>>>as correct as .xml. >>>> >>>> Either way, though, I think this is an appropriate topic for putting >>>>some guidance in the Guidelines. I'll volunteer to write it, but I >>>>would like some way of getting a consensus. >>>> >>>> Any ideas? An online poll? >>>> >>>> -Andrew >>>> >>>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" >>>>> >>>> wrote: >>>> >>>>> >>>>> Sigge, >>>>> >>>>> Thanks for being so gracious in your acceptance of my effort to >>>>>"volunteer" you. >>>>> >>>>> There's no rush on this. After Christmas/beginning of 2014 is fine. >>>>> I'm sure you'll find willing volunteers to help you write the >>>>>proposal. You can "volunteer" me in return. :-) >>>>> >>>>> Anyone who wants to participate, please contact Sigge. I hear he's >>>>>starting a list. :-) >>>>> >>>>> Thanks again, >>>>> >>>>> -- >>>>> 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>>>>a.edu at lists.uni-paderborn.de> >>>>>[mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de>>>>ia.edu at lists.uni-paderborn.de>] on behalf of Sigfrid Lundberg >>>>>[slu at kb.dk] >>>>> Sent: Thursday, August 15, 2013 10:49 AM >>>>> To: Music Encoding Initiative >>>>> Subject: Re: [MEI-L] File extensions >>>>> >>>>> My keyboard is too fast. >>>>> >>>>> Cannot promise to write it alone and have to discuss it here in >>>>>Copenhagen. Not before Christmas, that's for sure >>>>> >>>>> S >>>>> ________________________________________ >>>>> Fra: >>>>>mei-l-bounces at lists.uni-paderborn.de>>>>derborn.de> >>>>>[mei-l-bounces at lists.uni-paderborn.de>>>>aderborn.de>] på vegne af Roland, Perry (pdr4h) >>>>>[pdr4h at eservices.virginia.edu] >>>>> Sendt: 15. august 2013 16:44 >>>>> Til: Music Encoding Initiative >>>>> Emne: Re: [MEI-L] File extensions >>>>> >>>>> Hi Sigfrid, >>>>> >>>>> Sounds like we have a volunteer to lead the way to registering an >>>>>MEI mimetype. :-) >>>>> >>>>> -- >>>>> 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>>>>derborn.de> >>>>>[mei-l-bounces at lists.uni-paderborn.de>>>>aderborn.de>] on behalf of Sigfrid Lundberg >>>>>[slu at kb.dk] >>>>> Sent: Thursday, August 15, 2013 10:39 AM >>>>> To: Music Encoding Initiative >>>>> Subject: Re: [MEI-L] File extensions >>>>> >>>>> Hi, >>>>> >>>>> I'm using .xml as suffix. Don't really care. >>>>> >>>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I >>>>>have strong opinions on your "by the way" question. Yes, we should >>>>>register a mime type, and it should be application/mei+xml. Since it >>>>>is in the application hierarchy it requires an RFC and some >>>>>negotiations with IESG and IETF before one get a line in the >>>>>appropriate IANA document. >>>>> >>>>> Cheers >>>>> >>>>> Sigfrid >>>>> >>>>> ________________________________________ >>>>> Fra: >>>>>mei-l-bounces at lists.uni-paderborn.de>>>>derborn.de> >>>>>[mei-l-bounces at lists.uni-paderborn.de>>>>aderborn.de>] på vegne af Andrew Hankinson >>>>>[andrew.hankinson at mail.mcgill.ca>>>>a>] >>>>> Sendt: 15. august 2013 16:12 >>>>> Til: Music Encoding Initiative >>>>> Emne: [MEI-L] File extensions >>>>> >>>>> Hi all, >>>>> >>>>> Is there a common understanding of what the proper file extension >>>>>for MEI files should be? >>>>> >>>>> I've been assuming .mei is the "standard", but a counter-example of >>>>>.xml was recently brought to my attention. So, I thought I'd poll the >>>>>collected wisdom and see what others were doing. Are you using .xml, >>>>>.mei, or some other variation on these? >>>>> >>>>> -Andrew >>>>> >>>>> ==== >>>>> Related: >>>>> -- Should we register an actual mimetype? Maybe: >>>>>application/vnd.music-encoding+xml ? >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> _______________________________________________ >> 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 slu at kb.dk Mon Aug 19 15:23:14 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Mon, 19 Aug 2013 13:23:14 +0000 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: References: <0C090608704AF04E898055296C932B129B82781B@EXCHANGE-01.kb.dk> <0C090608704AF04E898055296C932B129B827850@EXCHANGE-01.kb.dk> <26763_1376579382_520CEF35_26763_84_19_BBCC497C40D85642B90E9F94FC30343D2DB3C014@grant1.eservices.virginia.edu> <23360_1376581672_520CF828_23360_49_1_0C090608704AF04E898055296C932B129B827888@EXCHANGE-01.kb.dk> <32319_1376584102_520D01A5_32319_65_14_CAMyHAnMf_iRiVdvcp487sSzYYm0ibTeBDGNP4-vi82e=ZTNPHw@mail.gmail.com>, <20670_1376896736_5211C6E0_20670_118_1_0C090608704AF04E898055296C932B129B827B99@EXCHANGE-01.kb.dk>, <0C090608704AF04E898055296C932B129B827C76@EXCHANGE-01.kb.dk>, Message-ID: <0C090608704AF04E898055296C932B129B827CB5@EXCHANGE-01.kb.dk> The html versions you mention share mime type text/html Then there currently a conflict whether or not xhtml with html5 semantics should be allowed to use to use that mime type, or should use application/xhtml+xml [1] The worms in that can are big as Boa constrictors Sigfrid [1] http://www.w3.org/TR/xhtml-media-types/ ________________________________________ Fra: mei-l-bounces+slu=kb.dk at lists.uni-paderborn.de [mei-l-bounces+slu=kb.dk at lists.uni-paderborn.de] på vegne af Johannes Kepper [kepper at edirom.de] Sendt: 19. august 2013 12:40 Til: Music Encoding Initiative Emne: Re: [MEI-L] Standards (was: File extensions) two cents from someone who's completely in the dark? I don't like the "vendor" term: To my (non-native english) ears, it sounds a little bit too commercial. It may or may not fit for MusicXML, but it doesn't seem to fit for us. If there are other tracks, we should follow them instead. If (S|s)tandard in the mimetype sense means something completely determined, it's not appropriate for us. We shouldn't restrict our future development by stocking ourselves to one specific version of MEI which may not be changed easily anymore. I wouldn't even do this for a defined subset of MEI (like cmn), as it has the potential to cannibalize the community, weakening support for other, more obscure parts of MEI. However, if (S|s)tandard is meant to be more open, I'm fine with this. For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one mimetype? If so, it seems comparable to our situation. best, jo Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg : > Sorry for using the word standard. > > Suppose it is better to describe our business as we are dealers in methodologies for the description of what is known about pieces of symbolic music. > > As a long term subscriber to the xml-dev list I'm used to worms, which doesn't mean that I like them, or even eat them. > > Sigfrid > > ________________________________________ > Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sendt: 19. august 2013 11:51 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] Standards (was: File extensions) > > Oof. That's a can of worms. > > Warning: Lots of opinions to follow. > > If you're creating physical widgets where part A needs to fit with part B, big-S Standards can be a great thing. > > For a small and loosely-bound community like MEI, a Standard wouldn't really bring much to the table, and, I think, would actually cause more harm than good. What do we standardize? The complete ODD file, including the parts of the ODD file that are mutually exclusive? (see: integration of both mensural and CMN timing modules?) The CMN customization? Any decision to standardize something will likely exclude a significant part of the community. We can't even come to a consensus about which file extension to use! > > What MEI brings to the world isn't actually an XML schema. I like to think that you can express MEI in any formalized structure. XML brings the ability to validate and impose constraints, but if XML was to be eclipsed by another structural language (like SGML was eclipsed by XML?) then I think that the intellectual structure of MEI could simply be transplanted to the new system. > > So, in a roundabout answer to your question: No, I don't think we're creating a Standard. I think we're creating a method, and I think with time and usage certain parts of this method may emerge to a de-facto standard, or even, yes, a Standard. But MEI as a whole? I don't think we should even think of trying to register this as a Standard. There's just too many moving parts. > > A vendor-specific mime type seems to be the most flexible method. In my reading about mime type registration, the "x-" prefix was used for experimental or non-standard use. Since RFC6648, however, this has been deprecated. Current best practice, as far as I can tell, says that non-standards-track mime types should be registered under the vendor-specific or personal (vanity) track. I would be happy to be corrected, though -- I'm new at this! > > So, application/vnd.mei+xml, or application/vnd.mei+json, or application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle [1] --- all of these are possibilities, but trying to go through the Standardization process for them seems like a lot of work for little, no, or even negative gain. > > -Andrew > > [1] http://www.candlescript.org/doc/candle-markup-reference.htm > > On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: > >> I know that, but why do you want it to register it as a vendor specific format. >> >> We're creating a standard, arn't we? >> >> Sigge >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >> Sendt: 16. august 2013 23:53 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] File extensions >> >> Not quite orthogonal. A web server will serve files with the specified extension as a given mime-type. It's true that you can write the mime type to the header if you're in a web application environment, but by registering a mime type we can provide a method for placing MEI files on a server, and it opening in a default application on the users' machine, for example. >> >> This can be especially useful in a mobile environment, where sometimes you have limited control over which application will open a downloaded file. >> >> So, in a web context the extension does matter, since (by default) the web server will serve files with a given extension with a certain mime type. That's the second part of the mime type definition for servers: "application/vnd.mei+xml .mei" maps all .mei files to the application/vnd.mei+xml mime type. >> >> Using .xml is fine if you want to open it in an XML editor. However, if we want to open it in a notation editor (dreaming of the future) then it's best if we choose .mei now, and then allow the user to specify the application that handles it as needed. >> >> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I understand, appending vnd. makes the mime type registration process much easier, since it doesn't need to go through the standards bodies to be approved. The MusicXML mime type uses the vnd. prefix, something like "application/vnd.recordare-musicxml+xml" So I thought that we might go for the easy registration first. It doesn't preclude later registration of a more formal mimetype. But here I will defer to those with more experience in the process. >> >> -Andrew >> >> >> On 2013-08-15, at 6:27 PM, Raffaele Viglianti > wrote: >> >> >> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson > wrote: >> >> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type seems like a big problem. >> >> application/vnd.mei+xml .mei -> Seems like the best solution, yes? >> >> As far as I know mimetype is orthogonal to file extension, so even if we secure a mimetype application/mei+xml it won't matter if your file has .xml or .mei extension. >> >> I personally don't see an issue with file extension at all. What's the problem with using either .mei or .xml? In a web context all that matters is the mimetype, in a OS context, using .xml is generally going to make things easier, but it's not eventually not a big deal. >> >> Raf >> >> >> (the MEI mime type I give is just an example). >> >> -Andrew >> >> >> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > >> wrote: >> >>> .txt is a poor choice. Most web servers will deliver that as text/plain which is not what you want. In apache web server there is a file mime-types which connects extensions to mime types, which then interacts with users web clients and plug-ins and helper applications >>> >>> Sigfrid >>> ________________________________________ >>> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >>> Sendt: 15. august 2013 17:23 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] File extensions >>> >>> You can sign me up too. >>> >>> Personally, I like .mei. XML could also be thought of as plain text, so I would argue that we should go with the most specific usage, rather than the most general. We could just go with .txt and be just as correct as .xml. >>> >>> Either way, though, I think this is an appropriate topic for putting some guidance in the Guidelines. I'll volunteer to write it, but I would like some way of getting a consensus. >>> >>> Any ideas? An online poll? >>> >>> -Andrew >>> >>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > >>> wrote: >>> >>>> >>>> Sigge, >>>> >>>> Thanks for being so gracious in your acceptance of my effort to "volunteer" you. >>>> >>>> There's no rush on this. After Christmas/beginning of 2014 is fine. I'm sure you'll find willing volunteers to help you write the proposal. You can "volunteer" me in return. :-) >>>> >>>> Anyone who wants to participate, please contact Sigge. I hear he's starting a list. :-) >>>> >>>> Thanks again, >>>> >>>> -- >>>> 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 Sigfrid Lundberg [slu at kb.dk] >>>> Sent: Thursday, August 15, 2013 10:49 AM >>>> To: Music Encoding Initiative >>>> Subject: Re: [MEI-L] File extensions >>>> >>>> My keyboard is too fast. >>>> >>>> Cannot promise to write it alone and have to discuss it here in Copenhagen. Not before Christmas, that's for sure >>>> >>>> S >>>> ________________________________________ >>>> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] >>>> Sendt: 15. august 2013 16:44 >>>> Til: Music Encoding Initiative >>>> Emne: Re: [MEI-L] File extensions >>>> >>>> Hi Sigfrid, >>>> >>>> Sounds like we have a volunteer to lead the way to registering an MEI mimetype. :-) >>>> >>>> -- >>>> 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 Sigfrid Lundberg [slu at kb.dk] >>>> Sent: Thursday, August 15, 2013 10:39 AM >>>> To: Music Encoding Initiative >>>> Subject: Re: [MEI-L] File extensions >>>> >>>> Hi, >>>> >>>> I'm using .xml as suffix. Don't really care. >>>> >>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I have strong opinions on your "by the way" question. Yes, we should register a mime type, and it should be application/mei+xml. Since it is in the application hierarchy it requires an RFC and some negotiations with IESG and IETF before one get a line in the appropriate IANA document. >>>> >>>> Cheers >>>> >>>> Sigfrid >>>> >>>> ________________________________________ >>>> Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] >>>> Sendt: 15. august 2013 16:12 >>>> Til: Music Encoding Initiative >>>> Emne: [MEI-L] File extensions >>>> >>>> Hi all, >>>> >>>> Is there a common understanding of what the proper file extension for MEI files should be? >>>> >>>> I've been assuming .mei is the "standard", but a counter-example of .xml was recently brought to my attention. So, I thought I'd poll the collected wisdom and see what others were doing. Are you using .xml, .mei, or some other variation on these? >>>> >>>> -Andrew >>>> >>>> ==== >>>> Related: >>>> -- Should we register an actual mimetype? Maybe: application/vnd.music-encoding+xml ? >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > 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 Aug 19 15:45:14 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Mon, 19 Aug 2013 09:45:14 -0400 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: References: Message-ID: I'm not participating in the strategy committee, though I worry about establishing MEI as a W3C working group if that also requires us to come up with a stricter standard that, while keeping the same MEI, it would limit its combinations. I'm echoing Johannes' worries of a subset becoming more important than other, perhaps less popular, MEI forms. I like very much what Andrew said about MEI: it's a method. I'd say that it's an application of text encoding methods to music. As such, it is not just a file format. Application support is important: but flexibility is required to apply text encoding methods and support innovative research. An alternative to boxing MEI within an official standard body is to invest more on the formalization of MEI customization and use, namely ODD. This means a) educating the community to using ODD for describing with both words and elements how they're using MEI; b) creating ODD-parsing applications that can, for example, act as middleware between a project-tailored MEI and a generic MEI application. Raf On Mon, Aug 19, 2013 at 7:26 AM, David Meredith wrote: > Hi all, > > Tomorrow, the "strategy" committee is having its first virtual meeting to > discuss possible ways in which MEI can be managed in the future. > > I will be (tentatively) suggesting that we think about managing it as a > W3C working group. And I have in my diary to prepare a short presentation > this afternoon about this. (Sychronicity? :) ) > > My view is that MEI's volatile and diffuse definition and development is > *THE* main reason why there has so far been so little interest in > developing software to support it. Before developing software to support a > particular file format (let's face it, that's basically what MEI is), a > software developer needs > > 1. a clear definition of what the format is; > 2. reasonable confidence that his/her software isn't going to become > obsolete the next time the format's definition is revised; and > 3. a good idea of how often the format's definition is going to be > changed, so that they can plan new versions of the software that supports > it. > > These can best be achieved by establishing MEI as a *standard*, with a > properly published and managed definition and properly established > processes for developing this definition to accommodate users' changing > needs while keeping volatility and backwards incompatibility to a minimum > so that developers aren't scared off. > > I'm not completely sure that the W3C route is necessarily the best one, > but clearly we want some form of standardisation framework that is: > > 1. relatively low-ceremony: we're all volunteers, so we don't have oceans > of time and money to spend on keeping MEI alive; > 2. well-recognized and international so that we maximise the likelihood of > people wanting to develop software to support MEI. > > If anyone else has experience with this kind of process and would like to > contribute to tomorrow's meeting, please talk to Benjamin about it. > > I agree with Johannes that decisions about the definition and development > of MEI should remain independent of commercial enterprises. MEI should be > run by and for the academic community. However, I don't see how clarifying > and stabilizing the definition and development of MEI would be in any > sense detrimental. > > Cheers, > Dave > > > On 19/08/2013 12:40, "Johannes Kepper" wrote: > > >two cents from someone who's completely in the dark? > > > >I don't like the "vendor" term: To my (non-native english) ears, it > >sounds a little bit too commercial. It may or may not fit for MusicXML, > >but it doesn't seem to fit for us. If there are other tracks, we should > >follow them instead. > > > >If (S|s)tandard in the mimetype sense means something completely > >determined, it's not appropriate for us. We shouldn't restrict our future > >development by stocking ourselves to one specific version of MEI which > >may not be changed easily anymore. I wouldn't even do this for a defined > >subset of MEI (like cmn), as it has the potential to cannibalize the > >community, weakening support for other, more obscure parts of MEI. > >However, if (S|s)tandard is meant to be more open, I'm fine with this. > >For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one > >mimetype? If so, it seems comparable to our situation. > > > > > >best, > >jo > > > > > > > > > >Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg : > > > >> Sorry for using the word standard. > >> > >> Suppose it is better to describe our business as we are dealers in > >>methodologies for the description of what is known about pieces of > >>symbolic music. > >> > >> As a long term subscriber to the xml-dev list I'm used to worms, which > >>doesn't mean that I like them, or even eat them. > >> > >> Sigfrid > >> > >> ________________________________________ > >> Fra: mei-l-bounces at lists.uni-paderborn.de > >>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson > >>[andrew.hankinson at mail.mcgill.ca] > >> Sendt: 19. august 2013 11:51 > >> Til: Music Encoding Initiative > >> Emne: Re: [MEI-L] Standards (was: File extensions) > >> > >> Oof. That's a can of worms. > >> > >> Warning: Lots of opinions to follow. > >> > >> If you're creating physical widgets where part A needs to fit with part > >>B, big-S Standards can be a great thing. > >> > >> For a small and loosely-bound community like MEI, a Standard wouldn't > >>really bring much to the table, and, I think, would actually cause more > >>harm than good. What do we standardize? The complete ODD file, including > >>the parts of the ODD file that are mutually exclusive? (see: integration > >>of both mensural and CMN timing modules?) The CMN customization? Any > >>decision to standardize something will likely exclude a significant part > >>of the community. We can't even come to a consensus about which file > >>extension to use! > >> > >> What MEI brings to the world isn't actually an XML schema. I like to > >>think that you can express MEI in any formalized structure. XML brings > >>the ability to validate and impose constraints, but if XML was to be > >>eclipsed by another structural language (like SGML was eclipsed by XML?) > >>then I think that the intellectual structure of MEI could simply be > >>transplanted to the new system. > >> > >> So, in a roundabout answer to your question: No, I don't think we're > >>creating a Standard. I think we're creating a method, and I think with > >>time and usage certain parts of this method may emerge to a de-facto > >>standard, or even, yes, a Standard. But MEI as a whole? I don't think we > >>should even think of trying to register this as a Standard. There's just > >>too many moving parts. > >> > >> A vendor-specific mime type seems to be the most flexible method. In my > >>reading about mime type registration, the "x-" prefix was used for > >>experimental or non-standard use. Since RFC6648, however, this has been > >>deprecated. Current best practice, as far as I can tell, says that > >>non-standards-track mime types should be registered under the > >>vendor-specific or personal (vanity) track. I would be happy to be > >>corrected, though -- I'm new at this! > >> > >> So, application/vnd.mei+xml, or application/vnd.mei+json, or > >>application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle > >>[1] --- all of these are possibilities, but trying to go through the > >>Standardization process for them seems like a lot of work for little, > >>no, or even negative gain. > >> > >> -Andrew > >> > >> [1] http://www.candlescript.org/doc/candle-markup-reference.htm > >> > >> On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: > >> > >>> I know that, but why do you want it to register it as a vendor > >>>specific format. > >>> > >>> We're creating a standard, arn't we? > >>> > >>> Sigge > >>> ________________________________________ > >>> Fra: mei-l-bounces at lists.uni-paderborn.de > >>>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew > >>>Hankinson [andrew.hankinson at mail.mcgill.ca] > >>> Sendt: 16. august 2013 23:53 > >>> Til: Music Encoding Initiative > >>> Emne: Re: [MEI-L] File extensions > >>> > >>> Not quite orthogonal. A web server will serve files with the specified > >>>extension as a given mime-type. It's true that you can write the mime > >>>type to the header if you're in a web application environment, but by > >>>registering a mime type we can provide a method for placing MEI files > >>>on a server, and it opening in a default application on the users' > >>>machine, for example. > >>> > >>> This can be especially useful in a mobile environment, where sometimes > >>>you have limited control over which application will open a downloaded > >>>file. > >>> > >>> So, in a web context the extension does matter, since (by default) the > >>>web server will serve files with a given extension with a certain mime > >>>type. That's the second part of the mime type definition for servers: > >>>"application/vnd.mei+xml .mei" maps all .mei files to the > >>>application/vnd.mei+xml mime type. > >>> > >>> Using .xml is fine if you want to open it in an XML editor. However, > >>>if we want to open it in a notation editor (dreaming of the future) > >>>then it's best if we choose .mei now, and then allow the user to > >>>specify the application that handles it as needed. > >>> > >>> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I > >>>understand, appending vnd. makes the mime type registration process > >>>much easier, since it doesn't need to go through the standards bodies > >>>to be approved. The MusicXML mime type uses the vnd. prefix, something > >>>like "application/vnd.recordare-musicxml+xml" So I thought that we > >>>might go for the easy registration first. It doesn't preclude later > >>>registration of a more formal mimetype. But here I will defer to those > >>>with more experience in the process. > >>> > >>> -Andrew > >>> > >>> > >>> On 2013-08-15, at 6:27 PM, Raffaele Viglianti > >>>> > wrote: > >>> > >>> > >>> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson > >>> > > >>>> wrote: > >>> > >>> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type > >>>seems like a big problem. > >>> > >>> application/vnd.mei+xml .mei -> Seems like the best solution, yes? > >>> > >>> As far as I know mimetype is orthogonal to file extension, so even if > >>>we secure a mimetype application/mei+xml it won't matter if your file > >>>has .xml or .mei extension. > >>> > >>> I personally don't see an issue with file extension at all. What's the > >>>problem with using either .mei or .xml? In a web context all that > >>>matters is the mimetype, in a OS context, using .xml is generally going > >>>to make things easier, but it's not eventually not a big deal. > >>> > >>> Raf > >>> > >>> > >>> (the MEI mime type I give is just an example). > >>> > >>> -Andrew > >>> > >>> > >>> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > >>>> > >>> wrote: > >>> > >>>> .txt is a poor choice. Most web servers will deliver that as > >>>>text/plain which is not what you want. In apache web server there is a > >>>>file mime-types which connects extensions to mime types, which then > >>>>interacts with users web clients and plug-ins and helper applications > >>>> > >>>> Sigfrid > >>>> ________________________________________ > >>>> Fra: > >>>>mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-pad > >>>>erborn.de> > >>>>[mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-pa > >>>>derborn.de>] på vegne af Andrew Hankinson > >>>>[andrew.hankinson at mail.mcgill.ca andrew.hankinson at mail.mcgill.ca > >>>>>] > >>>> Sendt: 15. august 2013 17:23 > >>>> Til: Music Encoding Initiative > >>>> Emne: Re: [MEI-L] File extensions > >>>> > >>>> You can sign me up too. > >>>> > >>>> Personally, I like .mei. XML could also be thought of as plain text, > >>>>so I would argue that we should go with the most specific usage, > >>>>rather than the most general. We could just go with .txt and be just > >>>>as correct as .xml. > >>>> > >>>> Either way, though, I think this is an appropriate topic for putting > >>>>some guidance in the Guidelines. I'll volunteer to write it, but I > >>>>would like some way of getting a consensus. > >>>> > >>>> Any ideas? An online poll? > >>>> > >>>> -Andrew > >>>> > >>>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > >>>>> > >>>> wrote: > >>>> > >>>>> > >>>>> Sigge, > >>>>> > >>>>> Thanks for being so gracious in your acceptance of my effort to > >>>>>"volunteer" you. > >>>>> > >>>>> There's no rush on this. After Christmas/beginning of 2014 is fine. > >>>>> I'm sure you'll find willing volunteers to help you write the > >>>>>proposal. You can "volunteer" me in return. :-) > >>>>> > >>>>> Anyone who wants to participate, please contact Sigge. I hear he's > >>>>>starting a list. :-) > >>>>> > >>>>> Thanks again, > >>>>> > >>>>> -- > >>>>> 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 virgini > >>>>>a.edu at lists.uni-paderborn.de> > >>>>>[mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de virgin > >>>>>ia.edu at lists.uni-paderborn.de>] on behalf of Sigfrid Lundberg > >>>>>[slu at kb.dk] > >>>>> Sent: Thursday, August 15, 2013 10:49 AM > >>>>> To: Music Encoding Initiative > >>>>> Subject: Re: [MEI-L] File extensions > >>>>> > >>>>> My keyboard is too fast. > >>>>> > >>>>> Cannot promise to write it alone and have to discuss it here in > >>>>>Copenhagen. Not before Christmas, that's for sure > >>>>> > >>>>> S > >>>>> ________________________________________ > >>>>> Fra: > >>>>>mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-pa > >>>>>derborn.de> > >>>>>[mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-p > >>>>>aderborn.de>] på vegne af Roland, Perry (pdr4h) > >>>>>[pdr4h at eservices.virginia.edu] > >>>>> Sendt: 15. august 2013 16:44 > >>>>> Til: Music Encoding Initiative > >>>>> Emne: Re: [MEI-L] File extensions > >>>>> > >>>>> Hi Sigfrid, > >>>>> > >>>>> Sounds like we have a volunteer to lead the way to registering an > >>>>>MEI mimetype. :-) > >>>>> > >>>>> -- > >>>>> 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-pa > >>>>>derborn.de> > >>>>>[mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-p > >>>>>aderborn.de>] on behalf of Sigfrid Lundberg > >>>>>[slu at kb.dk] > >>>>> Sent: Thursday, August 15, 2013 10:39 AM > >>>>> To: Music Encoding Initiative > >>>>> Subject: Re: [MEI-L] File extensions > >>>>> > >>>>> Hi, > >>>>> > >>>>> I'm using .xml as suffix. Don't really care. > >>>>> > >>>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I > >>>>>have strong opinions on your "by the way" question. Yes, we should > >>>>>register a mime type, and it should be application/mei+xml. Since it > >>>>>is in the application hierarchy it requires an RFC and some > >>>>>negotiations with IESG and IETF before one get a line in the > >>>>>appropriate IANA document. > >>>>> > >>>>> Cheers > >>>>> > >>>>> Sigfrid > >>>>> > >>>>> ________________________________________ > >>>>> Fra: > >>>>>mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-pa > >>>>>derborn.de> > >>>>>[mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-p > >>>>>aderborn.de>] på vegne af Andrew Hankinson > >>>>>[andrew.hankinson at mail.mcgill.ca andrew.hankinson at mail.mcgill.c > >>>>>a>] > >>>>> Sendt: 15. august 2013 16:12 > >>>>> Til: Music Encoding Initiative > >>>>> Emne: [MEI-L] File extensions > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Is there a common understanding of what the proper file extension > >>>>>for MEI files should be? > >>>>> > >>>>> I've been assuming .mei is the "standard", but a counter-example of > >>>>>.xml was recently brought to my attention. So, I thought I'd poll the > >>>>>collected wisdom and see what others were doing. Are you using .xml, > >>>>>.mei, or some other variation on these? > >>>>> > >>>>> -Andrew > >>>>> > >>>>> ==== > >>>>> Related: > >>>>> -- Should we register an actual mimetype? Maybe: > >>>>>application/vnd.music-encoding+xml ? > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> > >> > >> _______________________________________________ > >> 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: From bohl at edirom.de Mon Aug 19 17:14:03 2013 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Mon, 19 Aug 2013 17:14:03 +0200 Subject: [MEI-L] First Virtual MEeting of Strategy Development Group Message-ID: <5212363B.4070306@edirom.de> Hi MEI-List:eners, I'm happy to let you all know that MEI Strategy Development Group is taking up work with its first virtual meeting tomorrow: Tuesday 20 August 4:30 pm to 6:00pm (CEST; UTC+2 Berlin) Our preliminary agenda is: - Discuss scope of group's work - Sneak peak into organisation models (TEI, dm-l, etc.) - Lay out an agenda for the following year If you have any interesting ideas for us, feel free to address us at: Mei-Strat at lists.uni-paderborn.de If you want to join the group shorthand please contact me directly at: b.w.bohl at googlemail.com On behalf of the MEI Strategy Development Group, Bejamin - Keeper -- *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D--32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From donbyrd at indiana.edu Mon Aug 19 21:04:33 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Mon, 19 Aug 2013 15:04:33 -0400 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: References: Message-ID: <20130819150433.libv051680o000o8@webmail.iu.edu> It seems clear that there's no consensus in the MEI community on what MEI is :-) . Andrew says it "isn't actually an XML schema. I like to think that you can express MEI in any formalized structure." That is, MEI is more abstract tha a schema, and I agree. On the other hand, Dave says "a particular file format [is] basically what MEI is" -- i.e., MEI is no more abstract than a schema, perhaps less so, and I agree. I've been working on a universal representation of time and a paper about it, and being forced to think about _representations_ vs. _encodings_. The usual distinction is that a representation says what information is conveyed; an encoding says how it's conveyed, i.e., what bit patterns mean what. Is that the difference between Unicode proper (which defines a bunch of code points and principles for assigning new ones), and UTF8, UTF16, UTF32, and raw Unicode, hi-endian or low-endian, with or without BOMs (each of defines the meaning of various patterns of bits)? I don't think so: by assigning code points, Unicode proper says how the information is conveyed. The UTFs etc. are just rearranging the bits for convenience, e.g., via "transformation formats". So maybe hi-endian UTF16 is a _concrete_ encoding, and raw Unicode is an _abstract_ encoding. (I just made those terms up, but I'll but others have used them before. So be it.) It seems to me that MEI is, in concept, a representation of music. But it's nearly impossible to even _discuss_ representations without using encodings! So we generally talk about ODD definitions and XML schemas, which I suspect are abstract encodings; what we actually, uh, encode music in is a concrete encoding, a.k.a. file format. I hope this helps, but I'm afraid it'll cause more confusion. If so, please forgive me! --Don On Mon, 19 Aug 2013 11:26:48 +0000, David Meredith wrote: > Hi all, > > Tomorrow, the "strategy" committee is having its first virtual meeting to > discuss possible ways in which MEI can be managed in the future. > > I will be (tentatively) suggesting that we think about managing it as a > W3C working group. And I have in my diary to prepare a short presentation > this afternoon about this. (Sychronicity? :) ) > > My view is that MEI's volatile and diffuse definition and development is > *THE* main reason why there has so far been so little interest in > developing software to support it. Before developing software to support a > particular file format (let's face it, that's basically what MEI is), a > software developer needs > > 1. a clear definition of what the format is; > 2. reasonable confidence that his/her software isn't going to become > obsolete the next time the format's definition is revised; and > 3. a good idea of how often the format's definition is going to be > changed, so that they can plan new versions of the software that supports > it. > > These can best be achieved by establishing MEI as a *standard*, with a > properly published and managed definition and properly established > processes for developing this definition to accommodate users' changing > needs while keeping volatility and backwards incompatibility to a minimum > so that developers aren't scared off. > > I'm not completely sure that the W3C route is necessarily the best one, > but clearly we want some form of standardisation framework that is: > > 1. relatively low-ceremony: we're all volunteers, so we don't have oceans > of time and money to spend on keeping MEI alive; > 2. well-recognized and international so that we maximise the likelihood of > people wanting to develop software to support MEI. > > If anyone else has experience with this kind of process and would like to > contribute to tomorrow's meeting, please talk to Benjamin about it. > > I agree with Johannes that decisions about the definition and development > of MEI should remain independent of commercial enterprises. MEI should be > run by and for the academic community. However, I don't see how clarifying > and stabilizing the definition and development of MEI would be in any > sense detrimental. > > Cheers, > Dave > > > On 19/08/2013 12:40, "Johannes Kepper" wrote: > >> two cents from someone who's completely in the darkS >> >> I don't like the "vendor" term: To my (non-native english) ears, it >> sounds a little bit too commercial. It may or may not fit for MusicXML, >> but it doesn't seem to fit for us. If there are other tracks, we should >> follow them instead. >> >> If (S|s)tandard in the mimetype sense means something completely >> determined, it's not appropriate for us. We shouldn't restrict our future >> development by stocking ourselves to one specific version of MEI which >> may not be changed easily anymore. I wouldn't even do this for a defined >> subset of MEI (like cmn), as it has the potential to cannibalize the >> community, weakening support for other, more obscure parts of MEI. >> However, if (S|s)tandard is meant to be more open, I'm fine with this. >> For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one >> mimetype? If so, it seems comparable to our situation. >> >> >> best, >> jo >> >> >> >> >> Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg : >> >>> Sorry for using the word standard. >>> >>> Suppose it is better to describe our business as we are dealers in >>> methodologies for the description of what is known about pieces of >>> symbolic music. >>> >>> As a long term subscriber to the xml-dev list I'm used to worms, which >>> doesn't mean that I like them, or even eat them. >>> >>> Sigfrid >>> >>> ________________________________________ >>> Fra: mei-l-bounces at lists.uni-paderborn.de >>> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson >>> [andrew.hankinson at mail.mcgill.ca] >>> Sendt: 19. august 2013 11:51 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] Standards (was: File extensions) >>> >>> Oof. That's a can of worms. >>> >>> Warning: Lots of opinions to follow. >>> >>> If you're creating physical widgets where part A needs to fit with part >>> B, big-S Standards can be a great thing. >>> >>> For a small and loosely-bound community like MEI, a Standard wouldn't >>> really bring much to the table, and, I think, would actually cause more >>> harm than good. What do we standardize? The complete ODD file, including >>> the parts of the ODD file that are mutually exclusive? (see: integration >>> of both mensural and CMN timing modulesS) The CMN customization? Any >>> decision to standardize something will likely exclude a significant part >>> of the community. We can't even come to a consensus about which file >>> extension to use! >>> >>> What MEI brings to the world isn't actually an XML schema. I like to >>> think that you can express MEI in any formalized structure. XML brings >>> the ability to validate and impose constraints, but if XML was to be >>> eclipsed by another structural language (like SGML was eclipsed by XMLS) >>> then I think that the intellectual structure of MEI could simply be >>> transplanted to the new system. >>> >>> So, in a roundabout answer to your question: No, I don't think we're >>> creating a Standard. I think we're creating a method, and I think with >>> time and usage certain parts of this method may emerge to a de-facto >>> standard, or even, yes, a Standard. But MEI as a whole? I don't think we >>> should even think of trying to register this as a Standard. There's just >>> too many moving parts. >>> >>> A vendor-specific mime type seems to be the most flexible method. In my >>> reading about mime type registration, the "x-" prefix was used for >>> experimental or non-standard use. Since RFC6648, however, this has been >>> deprecated. Current best practice, as far as I can tell, says that >>> non-standards-track mime types should be registered under the >>> vendor-specific or personal (vanity) track. I would be happy to be >>> corrected, though -- I'm new at this! >>> >>> So, application/vnd.mei+xml, or application/vnd.mei+json, or >>> application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle >>> [1] --- all of these are possibilities, but trying to go through the >>> Standardization process for them seems like a lot of work for little, >>> no, or even negative gain. >>> >>> -Andrew >>> >>> [1] http://www.candlescript.org/doc/candle-markup-reference.htm >>> >>> On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: >>> >>>> I know that, but why do you want it to register it as a vendor >>>> specific format. >>>> >>>> We're creating a standard, arn't we? >>>> >>>> Sigge >>>> ________________________________________ >>>> Fra: mei-l-bounces at lists.uni-paderborn.de >>>> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew >>>> Hankinson [andrew.hankinson at mail.mcgill.ca] >>>> Sendt: 16. august 2013 23:53 >>>> Til: Music Encoding Initiative >>>> Emne: Re: [MEI-L] File extensions >>>> >>>> Not quite orthogonal. A web server will serve files with the specified >>>> extension as a given mime-type. It's true that you can write the mime >>>> type to the header if you're in a web application environment, but by >>>> registering a mime type we can provide a method for placing MEI files >>>> on a server, and it opening in a default application on the users' >>>> machine, for example. >>>> >>>> This can be especially useful in a mobile environment, where sometimes >>>> you have limited control over which application will open a downloaded >>>> file. >>>> >>>> So, in a web context the extension does matter, since (by default) the >>>> web server will serve files with a given extension with a certain mime >>>> type. That's the second part of the mime type definition for servers: >>>> "application/vnd.mei+xml .mei" maps all .mei files to the >>>> application/vnd.mei+xml mime type. >>>> >>>> Using .xml is fine if you want to open it in an XML editor. However, >>>> if we want to open it in a notation editor (dreaming of the future) >>>> then it's best if we choose .mei now, and then allow the user to >>>> specify the application that handles it as needed. >>>> >>>> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I >>>> understand, appending vnd. makes the mime type registration process >>>> much easier, since it doesn't need to go through the standards bodies >>>> to be approved. The MusicXML mime type uses the vnd. prefix, something >>>> like "application/vnd.recordare-musicxml+xml" So I thought that we >>>> might go for the easy registration first. It doesn't preclude later >>>> registration of a more formal mimetype. But here I will defer to those >>>> with more experience in the process. >>>> >>>> -Andrew >>>> >>>> >>>> On 2013-08-15, at 6:27 PM, Raffaele Viglianti >>>> > wrote: >>>> >>>> >>>> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson >>>> >>>>> wrote: >>>> >>>> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type >>>> seems like a big problem. >>>> >>>> application/vnd.mei+xml .mei -> Seems like the best solution, yes? >>>> >>>> As far as I know mimetype is orthogonal to file extension, so even if >>>> we secure a mimetype application/mei+xml it won't matter if your file >>>> has .xml or .mei extension. >>>> >>>> I personally don't see an issue with file extension at all. What's the >>>> problem with using either .mei or .xml? In a web context all that >>>> matters is the mimetype, in a OS context, using .xml is generally going >>>> to make things easier, but it's not eventually not a big deal. >>>> >>>> Raf >>>> >>>> >>>> (the MEI mime type I give is just an example). >>>> >>>> -Andrew >>>> >>>> >>>> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg >>>> > >>>> wrote: >>>> >>>>> .txt is a poor choice. Most web servers will deliver that as >>>>> text/plain which is not what you want. In apache web server there is a >>>>> file mime-types which connects extensions to mime types, which then >>>>> interacts with users web clients and plug-ins and helper applications >>>>> >>>>> Sigfrid >>>>> ________________________________________ >>>>> Fra: >>>>> mei-l-bounces at lists.uni-paderborn.de>>>> erborn.de> >>>>> [mei-l-bounces at lists.uni-paderborn.de>>>> derborn.de>] på vegne af Andrew Hankinson >>>>> [andrew.hankinson at mail.mcgill.ca>>>>> ] >>>>> Sendt: 15. august 2013 17:23 >>>>> Til: Music Encoding Initiative >>>>> Emne: Re: [MEI-L] File extensions >>>>> >>>>> You can sign me up too. >>>>> >>>>> Personally, I like .mei. XML could also be thought of as plain text, >>>>> so I would argue that we should go with the most specific usage, >>>>> rather than the most general. We could just go with .txt and be just >>>>> as correct as .xml. >>>>> >>>>> Either way, though, I think this is an appropriate topic for putting >>>>> some guidance in the Guidelines. I'll volunteer to write it, but I >>>>> would like some way of getting a consensus. >>>>> >>>>> Any ideas? An online poll? >>>>> >>>>> -Andrew >>>>> >>>>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" >>>>> > >>>>> wrote: >>>>> >>>>>> >>>>>> Sigge, >>>>>> >>>>>> Thanks for being so gracious in your acceptance of my effort to >>>>>> "volunteer" you. >>>>>> >>>>>> There's no rush on this. After Christmas/beginning of 2014 is fine. >>>>>> I'm sure you'll find willing volunteers to help you write the >>>>>> proposal. You can "volunteer" me in return. :-) >>>>>> >>>>>> Anyone who wants to participate, please contact Sigge. I hear he's >>>>>> starting a list. :-) >>>>>> >>>>>> Thanks again, >>>>>> >>>>>> -- >>>>>> 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>>>>> a.edu at lists.uni-paderborn.de> >>>>>> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de>>>>> ia.edu at lists.uni-paderborn.de>] on behalf of Sigfrid Lundberg >>>>>> [slu at kb.dk] >>>>>> Sent: Thursday, August 15, 2013 10:49 AM >>>>>> To: Music Encoding Initiative >>>>>> Subject: Re: [MEI-L] File extensions >>>>>> >>>>>> My keyboard is too fast. >>>>>> >>>>>> Cannot promise to write it alone and have to discuss it here in >>>>>> Copenhagen. Not before Christmas, that's for sure >>>>>> >>>>>> S >>>>>> ________________________________________ >>>>>> Fra: >>>>>> mei-l-bounces at lists.uni-paderborn.de>>>>> derborn.de> >>>>>> [mei-l-bounces at lists.uni-paderborn.de>>>>> aderborn.de>] på vegne af Roland, Perry (pdr4h) >>>>>> [pdr4h at eservices.virginia.edu] >>>>>> Sendt: 15. august 2013 16:44 >>>>>> Til: Music Encoding Initiative >>>>>> Emne: Re: [MEI-L] File extensions >>>>>> >>>>>> Hi Sigfrid, >>>>>> >>>>>> Sounds like we have a volunteer to lead the way to registering an >>>>>> MEI mimetype. :-) >>>>>> >>>>>> -- >>>>>> 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>>>>> derborn.de> >>>>>> [mei-l-bounces at lists.uni-paderborn.de>>>>> aderborn.de>] on behalf of Sigfrid Lundberg >>>>>> [slu at kb.dk] >>>>>> Sent: Thursday, August 15, 2013 10:39 AM >>>>>> To: Music Encoding Initiative >>>>>> Subject: Re: [MEI-L] File extensions >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm using .xml as suffix. Don't really care. >>>>>> >>>>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I >>>>>> have strong opinions on your "by the way" question. Yes, we should >>>>>> register a mime type, and it should be application/mei+xml. Since it >>>>>> is in the application hierarchy it requires an RFC and some >>>>>> negotiations with IESG and IETF before one get a line in the >>>>>> appropriate IANA document. >>>>>> >>>>>> Cheers >>>>>> >>>>>> Sigfrid >>>>>> >>>>>> ________________________________________ >>>>>> Fra: >>>>>> mei-l-bounces at lists.uni-paderborn.de>>>>> derborn.de> >>>>>> [mei-l-bounces at lists.uni-paderborn.de>>>>> aderborn.de>] på vegne af Andrew Hankinson >>>>>> [andrew.hankinson at mail.mcgill.ca>>>>> a>] >>>>>> Sendt: 15. august 2013 16:12 >>>>>> Til: Music Encoding Initiative >>>>>> Emne: [MEI-L] File extensions >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Is there a common understanding of what the proper file extension >>>>>> for MEI files should be? >>>>>> >>>>>> I've been assuming .mei is the "standard", but a counter-example of >>>>>> .xml was recently brought to my attention. So, I thought I'd poll the >>>>>> collected wisdom and see what others were doing. Are you using .xml, >>>>>> .mei, or some other variation on these? >>>>>> >>>>>> -Andrew >>>>>> >>>>>> ==== >>>>>> Related: >>>>>> -- Should we register an actual mimetype? Maybe: >>>>>> application/vnd.music-encoding+xml ? >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 > -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington From andrew.hankinson at mail.mcgill.ca Mon Aug 19 21:51:55 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 19 Aug 2013 19:51:55 +0000 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: <28650_1376919949_5212218C_28650_131_1_CAMyHAnOz7vG2TQtJPKct4iyyBk2JM6uoH8KOg5c3==t7yt3xTA@mail.gmail.com> References: <28650_1376919949_5212218C_28650_131_1_CAMyHAnOz7vG2TQtJPKct4iyyBk2JM6uoH8KOg5c3==t7yt3xTA@mail.gmail.com> Message-ID: I'm just full of opinions today? :) I don't see MEI as a file format. To be a little pedantic, but hopefully make a point: XML is a file format; MEI is a method of arranging objects so that they convey some sort of musical sense. What form that musical sense takes is dependent on what you want to express. What MEI brings to the table that sets it apart from all other encoding systems is a way of doing custom things easily without needing to re-define the parts that you don't care about. In that sense, it's more like a SDK or API than it is to a file format. MEI has always had the "Cart before the Horse" model with respect to developing the encoding independent of any software implementations. I know this was done on purpose, and I think it's because once a software client is involved in the creation of the specification, the implemented features tend to dictate the method of encoding. (Perry can stop me from putting words in his mouth if that's not the case). So I don't agree with Dave's assessment about the lack of interest in developing software support. In fact, I think you would find that there is a lot of interest in developing software for it -- it's just that the software that gets built is for a specific project or purpose, since what we expect from MEI differs from project to project. I came to MEI because it offered a method of encoding OMR; others are using it for digital edition work; some are using it for encoding "close readings" of musical texts, still others are using it for high-level metadata work. This can't all be supported by one client. When I hear that there is "no software support," I think what is meant is that there is no graphical editor that can produce an MEI-encoded file. In that sense, yes, that is somewhat correct. There are other emerging options here, though. The Sibelius MEI plugin is speeding along, thanks to some work by Richard Freedman and his students. The musicxml2mei XSLT is actively developed and constantly enhanced. Craig Sapp's amazing work on transforming other formats to and from MEI has brought MEI to both the KernScores and the Josquin project. Even the MeiSe project gave us some usable graphical software. So while Sibelius, Finale, and MuseScore don't support MEI, the purpose and use of these software packages is often orthogonal to how MEI is actually being used and the software that is actually being developed. I think any attempt at standardization or more rigid specification needs to understand that this is a fundamental feature of MEI, and not a bug that needs to be fixed by stricter definitions. To answer Johannes: There are three "trees" in mime type registration: Standards, Vendor ('vnd.'), and Personal ('prs.'), (otherwise known of as "Vanity.") You can see the mime type registration form here: http://www.iana.org/cgi-bin/mediatypes.pl. The Standards tree is reserved for use by Standards Organizations (W3C, IEEE, ISO, ANSI, etc.) and ownership and control of the mime type is the standards organization, NOT the community that produced the spec. (See: http://tools.ietf.org/html/rfc6838#section-3.1) On the other hand, RFC 6838 says this about Vendor registration: "The vendor tree is used for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly in this context and are considered equivalent. Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree. A registration may be placed in the vendor tree by anyone who needs to interchange files associated with some product or set of products. However, the registration properly belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party in order to correct or update it." http://tools.ietf.org/html/rfc6838#page-6 The third track, Personal, is basically for experimental or internal interchange. It's almost certainly not what we want. So basically, if you want to register a mime type and have it recognized but still retain the freedom to change and modify it without needing to go through a standards body you should go with the Vendor tree. -Andrew On 2013-08-19, at 3:45 PM, Raffaele Viglianti > wrote: I'm not participating in the strategy committee, though I worry about establishing MEI as a W3C working group if that also requires us to come up with a stricter standard that, while keeping the same MEI, it would limit its combinations. I'm echoing Johannes' worries of a subset becoming more important than other, perhaps less popular, MEI forms. I like very much what Andrew said about MEI: it's a method. I'd say that it's an application of text encoding methods to music. As such, it is not just a file format. Application support is important: but flexibility is required to apply text encoding methods and support innovative research. An alternative to boxing MEI within an official standard body is to invest more on the formalization of MEI customization and use, namely ODD. This means a) educating the community to using ODD for describing with both words and elements how they're using MEI; b) creating ODD-parsing applications that can, for example, act as middleware between a project-tailored MEI and a generic MEI application. Raf On Mon, Aug 19, 2013 at 7:26 AM, David Meredith > wrote: Hi all, Tomorrow, the "strategy" committee is having its first virtual meeting to discuss possible ways in which MEI can be managed in the future. I will be (tentatively) suggesting that we think about managing it as a W3C working group. And I have in my diary to prepare a short presentation this afternoon about this. (Sychronicity? :) ) My view is that MEI's volatile and diffuse definition and development is *THE* main reason why there has so far been so little interest in developing software to support it. Before developing software to support a particular file format (let's face it, that's basically what MEI is), a software developer needs 1. a clear definition of what the format is; 2. reasonable confidence that his/her software isn't going to become obsolete the next time the format's definition is revised; and 3. a good idea of how often the format's definition is going to be changed, so that they can plan new versions of the software that supports it. These can best be achieved by establishing MEI as a *standard*, with a properly published and managed definition and properly established processes for developing this definition to accommodate users' changing needs while keeping volatility and backwards incompatibility to a minimum so that developers aren't scared off. I'm not completely sure that the W3C route is necessarily the best one, but clearly we want some form of standardisation framework that is: 1. relatively low-ceremony: we're all volunteers, so we don't have oceans of time and money to spend on keeping MEI alive; 2. well-recognized and international so that we maximise the likelihood of people wanting to develop software to support MEI. If anyone else has experience with this kind of process and would like to contribute to tomorrow's meeting, please talk to Benjamin about it. I agree with Johannes that decisions about the definition and development of MEI should remain independent of commercial enterprises. MEI should be run by and for the academic community. However, I don't see how clarifying and stabilizing the definition and development of MEI would be in any sense detrimental. Cheers, Dave On 19/08/2013 12:40, "Johannes Kepper" > wrote: >two cents from someone who's completely in the dark? > >I don't like the "vendor" term: To my (non-native english) ears, it >sounds a little bit too commercial. It may or may not fit for MusicXML, >but it doesn't seem to fit for us. If there are other tracks, we should >follow them instead. > >If (S|s)tandard in the mimetype sense means something completely >determined, it's not appropriate for us. We shouldn't restrict our future >development by stocking ourselves to one specific version of MEI which >may not be changed easily anymore. I wouldn't even do this for a defined >subset of MEI (like cmn), as it has the potential to cannibalize the >community, weakening support for other, more obscure parts of MEI. >However, if (S|s)tandard is meant to be more open, I'm fine with this. >For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one >mimetype? If so, it seems comparable to our situation. > > >best, >jo > > > > >Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg >: > >> Sorry for using the word standard. >> >> Suppose it is better to describe our business as we are dealers in >>methodologies for the description of what is known about pieces of >>symbolic music. >> >> As a long term subscriber to the xml-dev list I'm used to worms, which >>doesn't mean that I like them, or even eat them. >> >> Sigfrid >> >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de >>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson >>[andrew.hankinson at mail.mcgill.ca] >> Sendt: 19. august 2013 11:51 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] Standards (was: File extensions) >> >> Oof. That's a can of worms. >> >> Warning: Lots of opinions to follow. >> >> If you're creating physical widgets where part A needs to fit with part >>B, big-S Standards can be a great thing. >> >> For a small and loosely-bound community like MEI, a Standard wouldn't >>really bring much to the table, and, I think, would actually cause more >>harm than good. What do we standardize? The complete ODD file, including >>the parts of the ODD file that are mutually exclusive? (see: integration >>of both mensural and CMN timing modules?) The CMN customization? Any >>decision to standardize something will likely exclude a significant part >>of the community. We can't even come to a consensus about which file >>extension to use! >> >> What MEI brings to the world isn't actually an XML schema. I like to >>think that you can express MEI in any formalized structure. XML brings >>the ability to validate and impose constraints, but if XML was to be >>eclipsed by another structural language (like SGML was eclipsed by XML?) >>then I think that the intellectual structure of MEI could simply be >>transplanted to the new system. >> >> So, in a roundabout answer to your question: No, I don't think we're >>creating a Standard. I think we're creating a method, and I think with >>time and usage certain parts of this method may emerge to a de-facto >>standard, or even, yes, a Standard. But MEI as a whole? I don't think we >>should even think of trying to register this as a Standard. There's just >>too many moving parts. >> >> A vendor-specific mime type seems to be the most flexible method. In my >>reading about mime type registration, the "x-" prefix was used for >>experimental or non-standard use. Since RFC6648, however, this has been >>deprecated. Current best practice, as far as I can tell, says that >>non-standards-track mime types should be registered under the >>vendor-specific or personal (vanity) track. I would be happy to be >>corrected, though -- I'm new at this! >> >> So, application/vnd.mei+xml, or application/vnd.mei+json, or >>application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle >>[1] --- all of these are possibilities, but trying to go through the >>Standardization process for them seems like a lot of work for little, >>no, or even negative gain. >> >> -Andrew >> >> [1] http://www.candlescript.org/doc/candle-markup-reference.htm >> >> On 2013-08-19, at 9:18 AM, Sigfrid Lundberg > wrote: >> >>> I know that, but why do you want it to register it as a vendor >>>specific format. >>> >>> We're creating a standard, arn't we? >>> >>> Sigge >>> ________________________________________ >>> Fra: mei-l-bounces at lists.uni-paderborn.de >>>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew >>>Hankinson [andrew.hankinson at mail.mcgill.ca] >>> Sendt: 16. august 2013 23:53 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] File extensions >>> >>> Not quite orthogonal. A web server will serve files with the specified >>>extension as a given mime-type. It's true that you can write the mime >>>type to the header if you're in a web application environment, but by >>>registering a mime type we can provide a method for placing MEI files >>>on a server, and it opening in a default application on the users' >>>machine, for example. >>> >>> This can be especially useful in a mobile environment, where sometimes >>>you have limited control over which application will open a downloaded >>>file. >>> >>> So, in a web context the extension does matter, since (by default) the >>>web server will serve files with a given extension with a certain mime >>>type. That's the second part of the mime type definition for servers: >>>"application/vnd.mei+xml .mei" maps all .mei files to the >>>application/vnd.mei+xml mime type. >>> >>> Using .xml is fine if you want to open it in an XML editor. However, >>>if we want to open it in a notation editor (dreaming of the future) >>>then it's best if we choose .mei now, and then allow the user to >>>specify the application that handles it as needed. >>> >>> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I >>>understand, appending vnd. makes the mime type registration process >>>much easier, since it doesn't need to go through the standards bodies >>>to be approved. The MusicXML mime type uses the vnd. prefix, something >>>like "application/vnd.recordare-musicxml+xml" So I thought that we >>>might go for the easy registration first. It doesn't preclude later >>>registration of a more formal mimetype. But here I will defer to those >>>with more experience in the process. >>> >>> -Andrew >>> >>> >>> On 2013-08-15, at 6:27 PM, Raffaele Viglianti >>>>> wrote: >>> >>> >>> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson >>>> >>>> wrote: >>> >>> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type >>>seems like a big problem. >>> >>> application/vnd.mei+xml .mei -> Seems like the best solution, yes? >>> >>> As far as I know mimetype is orthogonal to file extension, so even if >>>we secure a mimetype application/mei+xml it won't matter if your file >>>has .xml or .mei extension. >>> >>> I personally don't see an issue with file extension at all. What's the >>>problem with using either .mei or .xml? In a web context all that >>>matters is the mimetype, in a OS context, using .xml is generally going >>>to make things easier, but it's not eventually not a big deal. >>> >>> Raf >>> >>> >>> (the MEI mime type I give is just an example). >>> >>> -Andrew >>> >>> >>> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg >>>>> >>> wrote: >>> >>>> .txt is a poor choice. Most web servers will deliver that as >>>>text/plain which is not what you want. In apache web server there is a >>>>file mime-types which connects extensions to mime types, which then >>>>interacts with users web clients and plug-ins and helper applications >>>> >>>> Sigfrid >>>> ________________________________________ >>>> Fra: >>>>mei-l-bounces at lists.uni-paderborn.de >>>>erborn.de> >>>>[mei-l-bounces at lists.uni-paderborn.de >>>>derborn.de>] på vegne af Andrew Hankinson >>>>[andrew.hankinson at mail.mcgill.ca >>>>>] >>>> Sendt: 15. august 2013 17:23 >>>> Til: Music Encoding Initiative >>>> Emne: Re: [MEI-L] File extensions >>>> >>>> You can sign me up too. >>>> >>>> Personally, I like .mei. XML could also be thought of as plain text, >>>>so I would argue that we should go with the most specific usage, >>>>rather than the most general. We could just go with .txt and be just >>>>as correct as .xml. >>>> >>>> Either way, though, I think this is an appropriate topic for putting >>>>some guidance in the Guidelines. I'll volunteer to write it, but I >>>>would like some way of getting a consensus. >>>> >>>> Any ideas? An online poll? >>>> >>>> -Andrew >>>> >>>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" >>>>>> >>>> wrote: >>>> >>>>> >>>>> Sigge, >>>>> >>>>> Thanks for being so gracious in your acceptance of my effort to >>>>>"volunteer" you. >>>>> >>>>> There's no rush on this. After Christmas/beginning of 2014 is fine. >>>>> I'm sure you'll find willing volunteers to help you write the >>>>>proposal. You can "volunteer" me in return. :-) >>>>> >>>>> Anyone who wants to participate, please contact Sigge. I hear he's >>>>>starting a list. :-) >>>>> >>>>> Thanks again, >>>>> >>>>> -- >>>>> 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 >>>>>a.edu at lists.uni-paderborn.de> >>>>>[mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de >>>>>ia.edu at lists.uni-paderborn.de>] on behalf of Sigfrid Lundberg >>>>>[slu at kb.dk>] >>>>> Sent: Thursday, August 15, 2013 10:49 AM >>>>> To: Music Encoding Initiative >>>>> Subject: Re: [MEI-L] File extensions >>>>> >>>>> My keyboard is too fast. >>>>> >>>>> Cannot promise to write it alone and have to discuss it here in >>>>>Copenhagen. Not before Christmas, that's for sure >>>>> >>>>> S >>>>> ________________________________________ >>>>> Fra: >>>>>mei-l-bounces at lists.uni-paderborn.de >>>>>derborn.de> >>>>>[mei-l-bounces at lists.uni-paderborn.de >>>>>aderborn.de>] på vegne af Roland, Perry (pdr4h) >>>>>[pdr4h at eservices.virginia.edu>] >>>>> Sendt: 15. august 2013 16:44 >>>>> Til: Music Encoding Initiative >>>>> Emne: Re: [MEI-L] File extensions >>>>> >>>>> Hi Sigfrid, >>>>> >>>>> Sounds like we have a volunteer to lead the way to registering an >>>>>MEI mimetype. :-) >>>>> >>>>> -- >>>>> 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 >>>>>derborn.de> >>>>>[mei-l-bounces at lists.uni-paderborn.de >>>>>aderborn.de>] on behalf of Sigfrid Lundberg >>>>>[slu at kb.dk>] >>>>> Sent: Thursday, August 15, 2013 10:39 AM >>>>> To: Music Encoding Initiative >>>>> Subject: Re: [MEI-L] File extensions >>>>> >>>>> Hi, >>>>> >>>>> I'm using .xml as suffix. Don't really care. >>>>> >>>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I >>>>>have strong opinions on your "by the way" question. Yes, we should >>>>>register a mime type, and it should be application/mei+xml. Since it >>>>>is in the application hierarchy it requires an RFC and some >>>>>negotiations with IESG and IETF before one get a line in the >>>>>appropriate IANA document. >>>>> >>>>> Cheers >>>>> >>>>> Sigfrid >>>>> >>>>> ________________________________________ >>>>> Fra: >>>>>mei-l-bounces at lists.uni-paderborn.de >>>>>derborn.de> >>>>>[mei-l-bounces at lists.uni-paderborn.de >>>>>aderborn.de>] på vegne af Andrew Hankinson >>>>>[andrew.hankinson at mail.mcgill.ca >>>>>a>] >>>>> Sendt: 15. august 2013 16:12 >>>>> Til: Music Encoding Initiative >>>>> Emne: [MEI-L] File extensions >>>>> >>>>> Hi all, >>>>> >>>>> Is there a common understanding of what the proper file extension >>>>>for MEI files should be? >>>>> >>>>> I've been assuming .mei is the "standard", but a counter-example of >>>>>.xml was recently brought to my attention. So, I thought I'd poll the >>>>>collected wisdom and see what others were doing. Are you using .xml, >>>>>.mei, or some other variation on these? >>>>> >>>>> -Andrew >>>>> >>>>> ==== >>>>> Related: >>>>> -- Should we register an actual mimetype? Maybe: >>>>>application/vnd.music-encoding+xml ? >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> _______________________________________________ >> 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: From dave at create.aau.dk Mon Aug 19 23:28:56 2013 From: dave at create.aau.dk (David Meredith) Date: Mon, 19 Aug 2013 21:28:56 +0000 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: Message-ID: Some thoughts in response to Andrew's wise words. 1. I don't see why customizability and standardization are mutually exclusive. I would say that there need to be standardized ways of customizing the language and some relatively stable core subset of the language to allow for interchange and interoperability. 2. I agree that MEI should be developed independently of any particular software clients. However, I think (at least a part of) it should be standardized and stable enough to allow for large-scale information interchange and interoperability, so that A's software can read (at least some core subset of) all those encodings that B has worked so hard to produce; and so that B can use A's software to process his encodings. Writing converters to and from MEI helps, but if I have to convert that rich MEI file into some lesser format like MusicXML, kern or MIDI before I can use it, then I lose much of the value of having the information in MEI in the first place. We need powerful software the fully supports MEI and this requires MEI to have a certain guaranteed level of definition and stability. 3. MEI is an XML language. This means it is an information storage and interchange format, not a data-structure. Any reasonably complex piece of application software will read in an MEI file and then represent it internally in some data structure designed specifically for the purpose in hand, that may well bear little resemblance to how the information was stored in the original MEI file. The important thing is that MEI is powerful enough to represent/encode all the information and knowledge about a musical object that users need (or may need). I believe MEI is unique in that it has been developed by people who are extremely knowledgeable about and sensitive to the semantics of music notation of a wide variety of types. This means that it is capable of encoding/representing knowledge and information about music notation that no other format/language can. 4. I don't think anyone can reasonably disagree with the claim that MEI has (relatively) little software support. So far, we have a small number of groups heroically developing software for their own purposes and (relatively) only modest re-use even between these groups. Compared to, say, MIDI, for example, or even, (dare I say it) MusicXML, MEI has relatively little software support. I believe that if a core subset of the MEI specification were managed as a well-recognized stable standard, then it would attract much more interest from software developers. That said, I strongly agree that the definition and development of MEI should remain firmly in the hands of the academics who use it and NOT be transferred to any commercial enterprises. 5. Of course, the maintenance and development of MEI does not have to be done by means of an official standardization route such as a W3C Recommendation. However, if MEI does not achieve the status of at least a fairly high-profile *de facto* standard, then I'm concerned that it will never achieve the wide-spread use that I believe it deserves. Incidentally, there do not currently seem to be any W3C working groups or acknowledged member submissions on music notation. Shouldn't we see this as an opportunity for establishing MEI as the standard for representing music notation (of all types) on the web? Cheers, Dave From: Andrew Hankinson > Reply-To: Music Encoding Initiative > Date: Monday, 19 August 2013 21:51 To: Music Encoding Initiative > Subject: Re: [MEI-L] Standards (was: File extensions) I'm just full of opinions today? :) I don't see MEI as a file format. To be a little pedantic, but hopefully make a point: XML is a file format; MEI is a method of arranging objects so that they convey some sort of musical sense. What form that musical sense takes is dependent on what you want to express. What MEI brings to the table that sets it apart from all other encoding systems is a way of doing custom things easily without needing to re-define the parts that you don't care about. In that sense, it's more like a SDK or API than it is to a file format. MEI has always had the "Cart before the Horse" model with respect to developing the encoding independent of any software implementations. I know this was done on purpose, and I think it's because once a software client is involved in the creation of the specification, the implemented features tend to dictate the method of encoding. (Perry can stop me from putting words in his mouth if that's not the case). So I don't agree with Dave's assessment about the lack of interest in developing software support. In fact, I think you would find that there is a lot of interest in developing software for it -- it's just that the software that gets built is for a specific project or purpose, since what we expect from MEI differs from project to project. I came to MEI because it offered a method of encoding OMR; others are using it for digital edition work; some are using it for encoding "close readings" of musical texts, still others are using it for high-level metadata work. This can't all be supported by one client. When I hear that there is "no software support," I think what is meant is that there is no graphical editor that can produce an MEI-encoded file. In that sense, yes, that is somewhat correct. There are other emerging options here, though. The Sibelius MEI plugin is speeding along, thanks to some work by Richard Freedman and his students. The musicxml2mei XSLT is actively developed and constantly enhanced. Craig Sapp's amazing work on transforming other formats to and from MEI has brought MEI to both the KernScores and the Josquin project. Even the MeiSe project gave us some usable graphical software. So while Sibelius, Finale, and MuseScore don't support MEI, the purpose and use of these software packages is often orthogonal to how MEI is actually being used and the software that is actually being developed. I think any attempt at standardization or more rigid specification needs to understand that this is a fundamental feature of MEI, and not a bug that needs to be fixed by stricter definitions. To answer Johannes: There are three "trees" in mime type registration: Standards, Vendor ('vnd.'), and Personal ('prs.'), (otherwise known of as "Vanity.") You can see the mime type registration form here: http://www.iana.org/cgi-bin/mediatypes.pl. The Standards tree is reserved for use by Standards Organizations (W3C, IEEE, ISO, ANSI, etc.) and ownership and control of the mime type is the standards organization, NOT the community that produced the spec. (See: http://tools.ietf.org/html/rfc6838#section-3.1) On the other hand, RFC 6838 says this about Vendor registration: "The vendor tree is used for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly in this context and are considered equivalent. Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree. A registration may be placed in the vendor tree by anyone who needs to interchange files associated with some product or set of products. However, the registration properly belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party in order to correct or update it." http://tools.ietf.org/html/rfc6838#page-6 The third track, Personal, is basically for experimental or internal interchange. It's almost certainly not what we want. So basically, if you want to register a mime type and have it recognized but still retain the freedom to change and modify it without needing to go through a standards body you should go with the Vendor tree. -Andrew On 2013-08-19, at 3:45 PM, Raffaele Viglianti > wrote: I'm not participating in the strategy committee, though I worry about establishing MEI as a W3C working group if that also requires us to come up with a stricter standard that, while keeping the same MEI, it would limit its combinations. I'm echoing Johannes' worries of a subset becoming more important than other, perhaps less popular, MEI forms. I like very much what Andrew said about MEI: it's a method. I'd say that it's an application of text encoding methods to music. As such, it is not just a file format. Application support is important: but flexibility is required to apply text encoding methods and support innovative research. An alternative to boxing MEI within an official standard body is to invest more on the formalization of MEI customization and use, namely ODD. This means a) educating the community to using ODD for describing with both words and elements how they're using MEI; b) creating ODD-parsing applications that can, for example, act as middleware between a project-tailored MEI and a generic MEI application. Raf On Mon, Aug 19, 2013 at 7:26 AM, David Meredith > wrote: Hi all, Tomorrow, the "strategy" committee is having its first virtual meeting to discuss possible ways in which MEI can be managed in the future. I will be (tentatively) suggesting that we think about managing it as a W3C working group. And I have in my diary to prepare a short presentation this afternoon about this. (Sychronicity? :) ) My view is that MEI's volatile and diffuse definition and development is *THE* main reason why there has so far been so little interest in developing software to support it. Before developing software to support a particular file format (let's face it, that's basically what MEI is), a software developer needs 1. a clear definition of what the format is; 2. reasonable confidence that his/her software isn't going to become obsolete the next time the format's definition is revised; and 3. a good idea of how often the format's definition is going to be changed, so that they can plan new versions of the software that supports it. These can best be achieved by establishing MEI as a *standard*, with a properly published and managed definition and properly established processes for developing this definition to accommodate users' changing needs while keeping volatility and backwards incompatibility to a minimum so that developers aren't scared off. I'm not completely sure that the W3C route is necessarily the best one, but clearly we want some form of standardisation framework that is: 1. relatively low-ceremony: we're all volunteers, so we don't have oceans of time and money to spend on keeping MEI alive; 2. well-recognized and international so that we maximise the likelihood of people wanting to develop software to support MEI. If anyone else has experience with this kind of process and would like to contribute to tomorrow's meeting, please talk to Benjamin about it. I agree with Johannes that decisions about the definition and development of MEI should remain independent of commercial enterprises. MEI should be run by and for the academic community. However, I don't see how clarifying and stabilizing the definition and development of MEI would be in any sense detrimental. Cheers, Dave On 19/08/2013 12:40, "Johannes Kepper" > wrote: >two cents from someone who's completely in the dark? > >I don't like the "vendor" term: To my (non-native english) ears, it >sounds a little bit too commercial. It may or may not fit for MusicXML, >but it doesn't seem to fit for us. If there are other tracks, we should >follow them instead. > >If (S|s)tandard in the mimetype sense means something completely >determined, it's not appropriate for us. We shouldn't restrict our future >development by stocking ourselves to one specific version of MEI which >may not be changed easily anymore. I wouldn't even do this for a defined >subset of MEI (like cmn), as it has the potential to cannibalize the >community, weakening support for other, more obscure parts of MEI. >However, if (S|s)tandard is meant to be more open, I'm fine with this. >For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one >mimetype? If so, it seems comparable to our situation. > > >best, >jo > > > > >Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg >: > >> Sorry for using the word standard. >> >> Suppose it is better to describe our business as we are dealers in >>methodologies for the description of what is known about pieces of >>symbolic music. >> >> As a long term subscriber to the xml-dev list I'm used to worms, which >>doesn't mean that I like them, or even eat them. >> >> Sigfrid >> >> ________________________________________ >> Fra: mei-l-bounces at lists.uni-paderborn.de >>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson >>[andrew.hankinson at mail.mcgill.ca] >> Sendt: 19. august 2013 11:51 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] Standards (was: File extensions) >> >> Oof. That's a can of worms. >> >> Warning: Lots of opinions to follow. >> >> If you're creating physical widgets where part A needs to fit with part >>B, big-S Standards can be a great thing. >> >> For a small and loosely-bound community like MEI, a Standard wouldn't >>really bring much to the table, and, I think, would actually cause more >>harm than good. What do we standardize? The complete ODD file, including >>the parts of the ODD file that are mutually exclusive? (see: integration >>of both mensural and CMN timing modules?) The CMN customization? Any >>decision to standardize something will likely exclude a significant part >>of the community. We can't even come to a consensus about which file >>extension to use! >> >> What MEI brings to the world isn't actually an XML schema. I like to >>think that you can express MEI in any formalized structure. XML brings >>the ability to validate and impose constraints, but if XML was to be >>eclipsed by another structural language (like SGML was eclipsed by XML?) >>then I think that the intellectual structure of MEI could simply be >>transplanted to the new system. >> >> So, in a roundabout answer to your question: No, I don't think we're >>creating a Standard. I think we're creating a method, and I think with >>time and usage certain parts of this method may emerge to a de-facto >>standard, or even, yes, a Standard. But MEI as a whole? I don't think we >>should even think of trying to register this as a Standard. There's just >>too many moving parts. >> >> A vendor-specific mime type seems to be the most flexible method. In my >>reading about mime type registration, the "x-" prefix was used for >>experimental or non-standard use. Since RFC6648, however, this has been >>deprecated. Current best practice, as far as I can tell, says that >>non-standards-track mime types should be registered under the >>vendor-specific or personal (vanity) track. I would be happy to be >>corrected, though -- I'm new at this! >> >> So, application/vnd.mei+xml, or application/vnd.mei+json, or >>application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle >>[1] --- all of these are possibilities, but trying to go through the >>Standardization process for them seems like a lot of work for little, >>no, or even negative gain. >> >> -Andrew >> >> [1] http://www.candlescript.org/doc/candle-markup-reference.htm >> >> On 2013-08-19, at 9:18 AM, Sigfrid Lundberg > wrote: >> >>> I know that, but why do you want it to register it as a vendor >>>specific format. >>> >>> We're creating a standard, arn't we? >>> >>> Sigge >>> ________________________________________ >>> Fra: mei-l-bounces at lists.uni-paderborn.de >>>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew >>>Hankinson [andrew.hankinson at mail.mcgill.ca] >>> Sendt: 16. august 2013 23:53 >>> Til: Music Encoding Initiative >>> Emne: Re: [MEI-L] File extensions >>> >>> Not quite orthogonal. A web server will serve files with the specified >>>extension as a given mime-type. It's true that you can write the mime >>>type to the header if you're in a web application environment, but by >>>registering a mime type we can provide a method for placing MEI files >>>on a server, and it opening in a default application on the users' >>>machine, for example. >>> >>> This can be especially useful in a mobile environment, where sometimes >>>you have limited control over which application will open a downloaded >>>file. >>> >>> So, in a web context the extension does matter, since (by default) the >>>web server will serve files with a given extension with a certain mime >>>type. That's the second part of the mime type definition for servers: >>>"application/vnd.mei+xml .mei" maps all .mei files to the >>>application/vnd.mei+xml mime type. >>> >>> Using .xml is fine if you want to open it in an XML editor. However, >>>if we want to open it in a notation editor (dreaming of the future) >>>then it's best if we choose .mei now, and then allow the user to >>>specify the application that handles it as needed. >>> >>> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I >>>understand, appending vnd. makes the mime type registration process >>>much easier, since it doesn't need to go through the standards bodies >>>to be approved. The MusicXML mime type uses the vnd. prefix, something >>>like "application/vnd.recordare-musicxml+xml" So I thought that we >>>might go for the easy registration first. It doesn't preclude later >>>registration of a more formal mimetype. But here I will defer to those >>>with more experience in the process. >>> >>> -Andrew >>> >>> >>> On 2013-08-15, at 6:27 PM, Raffaele Viglianti >>>>> wrote: >>> >>> >>> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson >>>> >>>> wrote: >>> >>> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type >>>seems like a big problem. >>> >>> application/vnd.mei+xml .mei -> Seems like the best solution, yes? >>> >>> As far as I know mimetype is orthogonal to file extension, so even if >>>we secure a mimetype application/mei+xml it won't matter if your file >>>has .xml or .mei extension. >>> >>> I personally don't see an issue with file extension at all. What's the >>>problem with using either .mei or .xml? In a web context all that >>>matters is the mimetype, in a OS context, using .xml is generally going >>>to make things easier, but it's not eventually not a big deal. >>> >>> Raf >>> >>> >>> (the MEI mime type I give is just an example). >>> >>> -Andrew >>> >>> >>> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg >>>>> >>> wrote: >>> >>>> .txt is a poor choice. Most web servers will deliver that as >>>>text/plain which is not what you want. In apache web server there is a >>>>file mime-types which connects extensions to mime types, which then >>>>interacts with users web clients and plug-ins and helper applications >>>> >>>> Sigfrid >>>> ________________________________________ >>>> Fra: >>>>mei-l-bounces at lists.uni-paderborn.de >>>>erborn.de> >>>>[mei-l-bounces at lists.uni-paderborn.de >>>>derborn.de>] på vegne af Andrew Hankinson >>>>[andrew.hankinson at mail.mcgill.ca >>>>>] >>>> Sendt: 15. august 2013 17:23 >>>> Til: Music Encoding Initiative >>>> Emne: Re: [MEI-L] File extensions >>>> >>>> You can sign me up too. >>>> >>>> Personally, I like .mei. XML could also be thought of as plain text, >>>>so I would argue that we should go with the most specific usage, >>>>rather than the most general. We could just go with .txt and be just >>>>as correct as .xml. >>>> >>>> Either way, though, I think this is an appropriate topic for putting >>>>some guidance in the Guidelines. I'll volunteer to write it, but I >>>>would like some way of getting a consensus. >>>> >>>> Any ideas? An online poll? >>>> >>>> -Andrew >>>> >>>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" >>>>>> >>>> wrote: >>>> >>>>> >>>>> Sigge, >>>>> >>>>> Thanks for being so gracious in your acceptance of my effort to >>>>>"volunteer" you. >>>>> >>>>> There's no rush on this. After Christmas/beginning of 2014 is fine. >>>>> I'm sure you'll find willing volunteers to help you write the >>>>>proposal. You can "volunteer" me in return. :-) >>>>> >>>>> Anyone who wants to participate, please contact Sigge. I hear he's >>>>>starting a list. :-) >>>>> >>>>> Thanks again, >>>>> >>>>> -- >>>>> 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 >>>>>a.edu at lists.uni-paderborn.de> >>>>>[mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de >>>>>ia.edu at lists.uni-paderborn.de>] on behalf of Sigfrid Lundberg >>>>>[slu at kb.dk>] >>>>> Sent: Thursday, August 15, 2013 10:49 AM >>>>> To: Music Encoding Initiative >>>>> Subject: Re: [MEI-L] File extensions >>>>> >>>>> My keyboard is too fast. >>>>> >>>>> Cannot promise to write it alone and have to discuss it here in >>>>>Copenhagen. Not before Christmas, that's for sure >>>>> >>>>> S >>>>> ________________________________________ >>>>> Fra: >>>>>mei-l-bounces at lists.uni-paderborn.de >>>>>derborn.de> >>>>>[mei-l-bounces at lists.uni-paderborn.de >>>>>aderborn.de>] på vegne af Roland, Perry (pdr4h) >>>>>[pdr4h at eservices.virginia.edu>] >>>>> Sendt: 15. august 2013 16:44 >>>>> Til: Music Encoding Initiative >>>>> Emne: Re: [MEI-L] File extensions >>>>> >>>>> Hi Sigfrid, >>>>> >>>>> Sounds like we have a volunteer to lead the way to registering an >>>>>MEI mimetype. :-) >>>>> >>>>> -- >>>>> 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 >>>>>derborn.de> >>>>>[mei-l-bounces at lists.uni-paderborn.de >>>>>aderborn.de>] on behalf of Sigfrid Lundberg >>>>>[slu at kb.dk>] >>>>> Sent: Thursday, August 15, 2013 10:39 AM >>>>> To: Music Encoding Initiative >>>>> Subject: Re: [MEI-L] File extensions >>>>> >>>>> Hi, >>>>> >>>>> I'm using .xml as suffix. Don't really care. >>>>> >>>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I >>>>>have strong opinions on your "by the way" question. Yes, we should >>>>>register a mime type, and it should be application/mei+xml. Since it >>>>>is in the application hierarchy it requires an RFC and some >>>>>negotiations with IESG and IETF before one get a line in the >>>>>appropriate IANA document. >>>>> >>>>> Cheers >>>>> >>>>> Sigfrid >>>>> >>>>> ________________________________________ >>>>> Fra: >>>>>mei-l-bounces at lists.uni-paderborn.de >>>>>derborn.de> >>>>>[mei-l-bounces at lists.uni-paderborn.de >>>>>aderborn.de>] på vegne af Andrew Hankinson >>>>>[andrew.hankinson at mail.mcgill.ca >>>>>a>] >>>>> Sendt: 15. august 2013 16:12 >>>>> Til: Music Encoding Initiative >>>>> Emne: [MEI-L] File extensions >>>>> >>>>> Hi all, >>>>> >>>>> Is there a common understanding of what the proper file extension >>>>>for MEI files should be? >>>>> >>>>> I've been assuming .mei is the "standard", but a counter-example of >>>>>.xml was recently brought to my attention. So, I thought I'd poll the >>>>>collected wisdom and see what others were doing. Are you using .xml, >>>>>.mei, or some other variation on these? >>>>> >>>>> -Andrew >>>>> >>>>> ==== >>>>> Related: >>>>> -- Should we register an actual mimetype? Maybe: >>>>>application/vnd.music-encoding+xml ? >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> _______________________________________________ >> 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: From kepper at edirom.de Tue Aug 20 08:32:06 2013 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 20 Aug 2013 08:32:06 +0200 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: References: Message-ID: <5F985845-AD73-4825-BEA4-6CBB3E040A96@edirom.de> Some more thoughts? We had a proposal on a toolkit for MEI, that would have offered several profiles of MEI for specific tasks, conversions between these profiles, and other common tasks that would have facilitated usage of MEI significantly. The plan was to do this as a group, with almost all projects currently developing for MEI being involved. It appears our proposal wasn't spelled convincingly enough, so it didn't go through. However, the idea is still alive, and we're definitely looking for appropriate tracks to re-submit. The main difference to the idea of a core set is that we intentionally had several such core sets. It would be easy to identify just one core subset of MEI that would satisfy the needs of average music software developers. It would probably be something like the cmn module, with a reduced header and little else. Actually, not much has changed here in the last three years. However, such a subset would not satisfy the needs of almost all projects currently involved in MEI. It may or may not be appropriate for corpus analysis, but even there, I'd say it neglects the potential of other MEI modules more appropriate to the purpose. So yes, such a core set of MEI is likely to increase software support for MEI. But at the same time, it doesn't buy us much more than our own MusicXML equivalent within the world of MEI. We (as academics) still have to (up|down)convert our data into and out of this subset. In essence, there is little gain compared to the current situation with MusicXML and the converter we provide (please note that Perry is working on the opposite direction back into MusicXML right now). But, making such a core subset a Standard recognized by some Standards organization will effectively freeze development on everything that's inside the Standard. In my daily work, I regularly notice areas in MEI that haven't been used much ever since their invention, which may benefit from a gentle remodelling. When I said that the probable core was stable for some years now, this wasn't completely correct. The one big thing we changed significantly was the treatment of ossia. Are we really in the position to say that no such case will be found in the next few years? Even if so, can we exclude the possibility that changes to one of the more distant modules eventually result in changes to this core? So instead of defining and standardizing one core set of MEI, I'm in favor of specifying multiple profiles, each for a specific task. Read the word profile as nothing more than a best practice recommendation when you want to interchange with other applications operating in the same area. Actually, the reason for the little amount of code sharing between our projects is the fact that we all operate on different profiles already. I'm very much in favor of providing better / more stable "interfaces" for developers. However, I think it is important to clearly communicate the fact that MEI is more than just a well-defined format for common use cases ? it is a framework that offers a whole realm of encoding options, which need to be selected and specified in order to distill an actually usable format. My point is that by providing a whole set of standards (notice the small s) based on / derived from the MEI framework, it seems more likely that we as the scholarly community keep control over MEI as a whole. We need to find the right tradeoff between widest possible dissemination (also in the commercial world) and continued applicability for our scholarly needs. No one ever said that this would be easy? (but isn't the fact that we're facing this problem already an indication of success?) Best, Johannes Am 19.08.2013 um 23:28 schrieb David Meredith: > Some thoughts in response to Andrew's wise words. > > 1. I don't see why customizability and standardization are mutually exclusive. I would say that there need to be standardized ways of customizing the language and some relatively stable core subset of the language to allow for interchange and interoperability. > > 2. I agree that MEI should be developed independently of any particular software clients. However, I think (at least a part of) it should be standardized and stable enough to allow for large-scale information interchange and interoperability, so that A's software can read (at least some core subset of) all those encodings that B has worked so hard to produce; and so that B can use A's software to process his encodings. Writing converters to and from MEI helps, but if I have to convert that rich MEI file into some lesser format like MusicXML, kern or MIDI before I can use it, then I lose much of the value of having the information in MEI in the first place. We need powerful software the fully supports MEI and this requires MEI to have a certain guaranteed level of definition and stability. > > 3. MEI is an XML language. This means it is an information storage and interchange format, not a data-structure. Any reasonably complex piece of application software will read in an MEI file and then represent it internally in some data structure designed specifically for the purpose in hand, that may well bear little resemblance to how the information was stored in the original MEI file. The important thing is that MEI is powerful enough to represent/encode all the information and knowledge about a musical object that users need (or may need). I believe MEI is unique in that it has been developed by people who are extremely knowledgeable about and sensitive to the semantics of music notation of a wide variety of types. This means that it is capable of encoding/representing knowledge and information about music notation that no other format/language can. > > 4. I don't think anyone can reasonably disagree with the claim that MEI has (relatively) little software support. So far, we have a small number of groups heroically developing software for their own purposes and (relatively) only modest re-use even between these groups. Compared to, say, MIDI, for example, or even, (dare I say it) MusicXML, MEI has relatively little software support. I believe that if a core subset of the MEI specification were managed as a well-recognized stable standard, then it would attract much more interest from software developers. That said, I strongly agree that the definition and development of MEI should remain firmly in the hands of the academics who use it and NOT be transferred to any commercial enterprises. > > 5. Of course, the maintenance and development of MEI does not have to be done by means of an official standardization route such as a W3C Recommendation. However, if MEI does not achieve the status of at least a fairly high-profile *de facto* standard, then I'm concerned that it will never achieve the wide-spread use that I believe it deserves. > > Incidentally, there do not currently seem to be any W3C working groups or acknowledged member submissions on music notation. Shouldn't we see this as an opportunity for establishing MEI as the standard for representing music notation (of all types) on the web? > > Cheers, > Dave > > > > From: Andrew Hankinson > Reply-To: Music Encoding Initiative > Date: Monday, 19 August 2013 21:51 > To: Music Encoding Initiative > Subject: Re: [MEI-L] Standards (was: File extensions) > >> I'm just full of opinions today? :) >> >> I don't see MEI as a file format. To be a little pedantic, but hopefully make a point: XML is a file format; MEI is a method of arranging objects so that they convey some sort of musical sense. What form that musical sense takes is dependent on what you want to express. What MEI brings to the table that sets it apart from all other encoding systems is a way of doing custom things easily without needing to re-define the parts that you don't care about. In that sense, it's more like a SDK or API than it is to a file format. >> >> MEI has always had the "Cart before the Horse" model with respect to developing the encoding independent of any software implementations. I know this was done on purpose, and I think it's because once a software client is involved in the creation of the specification, the implemented features tend to dictate the method of encoding. (Perry can stop me from putting words in his mouth if that's not the case). >> >> So I don't agree with Dave's assessment about the lack of interest in developing software support. In fact, I think you would find that there is a lot of interest in developing software for it -- it's just that the software that gets built is for a specific project or purpose, since what we expect from MEI differs from project to project. I came to MEI because it offered a method of encoding OMR; others are using it for digital edition work; some are using it for encoding "close readings" of musical texts, still others are using it for high-level metadata work. This can't all be supported by one client. >> >> When I hear that there is "no software support," I think what is meant is that there is no graphical editor that can produce an MEI-encoded file. In that sense, yes, that is somewhat correct. There are other emerging options here, though. The Sibelius MEI plugin is speeding along, thanks to some work by Richard Freedman and his students. The musicxml2mei XSLT is actively developed and constantly enhanced. Craig Sapp's amazing work on transforming other formats to and from MEI has brought MEI to both the KernScores and the Josquin project. Even the MeiSe project gave us some usable graphical software. >> >> So while Sibelius, Finale, and MuseScore don't support MEI, the purpose and use of these software packages is often orthogonal to how MEI is actually being used and the software that is actually being developed. I think any attempt at standardization or more rigid specification needs to understand that this is a fundamental feature of MEI, and not a bug that needs to be fixed by stricter definitions. >> >> To answer Johannes: There are three "trees" in mime type registration: Standards, Vendor ('vnd.'), and Personal ('prs.'), (otherwise known of as "Vanity.") You can see the mime type registration form here: http://www.iana.org/cgi-bin/mediatypes.pl. >> >> The Standards tree is reserved for use by Standards Organizations (W3C, IEEE, ISO, ANSI, etc.) and ownership and control of the mime type is the standards organization, NOT the community that produced the spec. (See: http://tools.ietf.org/html/rfc6838#section-3.1) >> >> On the other hand, RFC 6838 says this about Vendor registration: >> >> "The vendor tree is used for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly in this context and are considered equivalent. Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree. >> >> A registration may be placed in the vendor tree by anyone who needs to interchange files associated with some product or set of products. However, the registration properly belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party in order to correct or update it." >> >> http://tools.ietf.org/html/rfc6838#page-6 >> >> The third track, Personal, is basically for experimental or internal interchange. It's almost certainly not what we want. >> >> So basically, if you want to register a mime type and have it recognized but still retain the freedom to change and modify it without needing to go through a standards body you should go with the Vendor tree. >> >> -Andrew >> >> On 2013-08-19, at 3:45 PM, Raffaele Viglianti >> wrote: >> >>> I'm not participating in the strategy committee, though I worry about establishing MEI as a W3C working group if that also requires us to come up with a stricter standard that, while keeping the same MEI, it would limit its combinations. >>> >>> I'm echoing Johannes' worries of a subset becoming more important than other, perhaps less popular, MEI forms. >>> >>> I like very much what Andrew said about MEI: it's a method. I'd say that it's an application of text encoding methods to music. As such, it is not just a file format. >>> >>> Application support is important: but flexibility is required to apply text encoding methods and support innovative research. An alternative to boxing MEI within an official standard body is to invest more on the formalization of MEI customization and use, namely ODD. This means a) educating the community to using ODD for describing with both words and elements how they're using MEI; b) creating ODD-parsing applications that can, for example, act as middleware between a project-tailored MEI and a generic MEI application. >>> >>> Raf >>> >>> >>> On Mon, Aug 19, 2013 at 7:26 AM, David Meredith wrote: >>>> Hi all, >>>> >>>> Tomorrow, the "strategy" committee is having its first virtual meeting to >>>> discuss possible ways in which MEI can be managed in the future. >>>> >>>> I will be (tentatively) suggesting that we think about managing it as a >>>> W3C working group. And I have in my diary to prepare a short presentation >>>> this afternoon about this. (Sychronicity? :) ) >>>> >>>> My view is that MEI's volatile and diffuse definition and development is >>>> *THE* main reason why there has so far been so little interest in >>>> developing software to support it. Before developing software to support a >>>> particular file format (let's face it, that's basically what MEI is), a >>>> software developer needs >>>> >>>> 1. a clear definition of what the format is; >>>> 2. reasonable confidence that his/her software isn't going to become >>>> obsolete the next time the format's definition is revised; and >>>> 3. a good idea of how often the format's definition is going to be >>>> changed, so that they can plan new versions of the software that supports >>>> it. >>>> >>>> These can best be achieved by establishing MEI as a *standard*, with a >>>> properly published and managed definition and properly established >>>> processes for developing this definition to accommodate users' changing >>>> needs while keeping volatility and backwards incompatibility to a minimum >>>> so that developers aren't scared off. >>>> >>>> I'm not completely sure that the W3C route is necessarily the best one, >>>> but clearly we want some form of standardisation framework that is: >>>> >>>> 1. relatively low-ceremony: we're all volunteers, so we don't have oceans >>>> of time and money to spend on keeping MEI alive; >>>> 2. well-recognized and international so that we maximise the likelihood of >>>> people wanting to develop software to support MEI. >>>> >>>> If anyone else has experience with this kind of process and would like to >>>> contribute to tomorrow's meeting, please talk to Benjamin about it. >>>> >>>> I agree with Johannes that decisions about the definition and development >>>> of MEI should remain independent of commercial enterprises. MEI should be >>>> run by and for the academic community. However, I don't see how clarifying >>>> and stabilizing the definition and development of MEI would be in any >>>> sense detrimental. >>>> >>>> Cheers, >>>> Dave >>>> >>>> >>>> On 19/08/2013 12:40, "Johannes Kepper" wrote: >>>> >>>> >two cents from someone who's completely in the dark? >>>> > >>>> >I don't like the "vendor" term: To my (non-native english) ears, it >>>> >sounds a little bit too commercial. It may or may not fit for MusicXML, >>>> >but it doesn't seem to fit for us. If there are other tracks, we should >>>> >follow them instead. >>>> > >>>> >If (S|s)tandard in the mimetype sense means something completely >>>> >determined, it's not appropriate for us. We shouldn't restrict our future >>>> >development by stocking ourselves to one specific version of MEI which >>>> >may not be changed easily anymore. I wouldn't even do this for a defined >>>> >subset of MEI (like cmn), as it has the potential to cannibalize the >>>> >community, weakening support for other, more obscure parts of MEI. >>>> >However, if (S|s)tandard is meant to be more open, I'm fine with this. >>>> >For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one >>>> >mimetype? If so, it seems comparable to our situation. >>>> > >>>> > >>>> >best, >>>> >jo >>>> > >>>> > >>>> > >>>> > >>>> >Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg : >>>> > >>>> >> Sorry for using the word standard. >>>> >> >>>> >> Suppose it is better to describe our business as we are dealers in >>>> >>methodologies for the description of what is known about pieces of >>>> >>symbolic music. >>>> >> >>>> >> As a long term subscriber to the xml-dev list I'm used to worms, which >>>> >>doesn't mean that I like them, or even eat them. >>>> >> >>>> >> Sigfrid >>>> >> >>>> >> ________________________________________ >>>> >> Fra: mei-l-bounces at lists.uni-paderborn.de >>>> >>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson >>>> >>[andrew.hankinson at mail.mcgill.ca] >>>> >> Sendt: 19. august 2013 11:51 >>>> >> Til: Music Encoding Initiative >>>> >> Emne: Re: [MEI-L] Standards (was: File extensions) >>>> >> >>>> >> Oof. That's a can of worms. >>>> >> >>>> >> Warning: Lots of opinions to follow. >>>> >> >>>> >> If you're creating physical widgets where part A needs to fit with part >>>> >>B, big-S Standards can be a great thing. >>>> >> >>>> >> For a small and loosely-bound community like MEI, a Standard wouldn't >>>> >>really bring much to the table, and, I think, would actually cause more >>>> >>harm than good. What do we standardize? The complete ODD file, including >>>> >>the parts of the ODD file that are mutually exclusive? (see: integration >>>> >>of both mensural and CMN timing modules?) The CMN customization? Any >>>> >>decision to standardize something will likely exclude a significant part >>>> >>of the community. We can't even come to a consensus about which file >>>> >>extension to use! >>>> >> >>>> >> What MEI brings to the world isn't actually an XML schema. I like to >>>> >>think that you can express MEI in any formalized structure. XML brings >>>> >>the ability to validate and impose constraints, but if XML was to be >>>> >>eclipsed by another structural language (like SGML was eclipsed by XML?) >>>> >>then I think that the intellectual structure of MEI could simply be >>>> >>transplanted to the new system. >>>> >> >>>> >> So, in a roundabout answer to your question: No, I don't think we're >>>> >>creating a Standard. I think we're creating a method, and I think with >>>> >>time and usage certain parts of this method may emerge to a de-facto >>>> >>standard, or even, yes, a Standard. But MEI as a whole? I don't think we >>>> >>should even think of trying to register this as a Standard. There's just >>>> >>too many moving parts. >>>> >> >>>> >> A vendor-specific mime type seems to be the most flexible method. In my >>>> >>reading about mime type registration, the "x-" prefix was used for >>>> >>experimental or non-standard use. Since RFC6648, however, this has been >>>> >>deprecated. Current best practice, as far as I can tell, says that >>>> >>non-standards-track mime types should be registered under the >>>> >>vendor-specific or personal (vanity) track. I would be happy to be >>>> >>corrected, though -- I'm new at this! >>>> >> >>>> >> So, application/vnd.mei+xml, or application/vnd.mei+json, or >>>> >>application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle >>>> >>[1] --- all of these are possibilities, but trying to go through the >>>> >>Standardization process for them seems like a lot of work for little, >>>> >>no, or even negative gain. >>>> >> >>>> >> -Andrew >>>> >> >>>> >> [1] http://www.candlescript.org/doc/candle-markup-reference.htm >>>> >> >>>> >> On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: >>>> >> >>>> >>> I know that, but why do you want it to register it as a vendor >>>> >>>specific format. >>>> >>> >>>> >>> We're creating a standard, arn't we? >>>> >>> >>>> >>> Sigge >>>> >>> ________________________________________ >>>> >>> Fra: mei-l-bounces at lists.uni-paderborn.de >>>> >>>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew >>>> >>>Hankinson [andrew.hankinson at mail.mcgill.ca] >>>> >>> Sendt: 16. august 2013 23:53 >>>> >>> Til: Music Encoding Initiative >>>> >>> Emne: Re: [MEI-L] File extensions >>>> >>> >>>> >>> Not quite orthogonal. A web server will serve files with the specified >>>> >>>extension as a given mime-type. It's true that you can write the mime >>>> >>>type to the header if you're in a web application environment, but by >>>> >>>registering a mime type we can provide a method for placing MEI files >>>> >>>on a server, and it opening in a default application on the users' >>>> >>>machine, for example. >>>> >>> >>>> >>> This can be especially useful in a mobile environment, where sometimes >>>> >>>you have limited control over which application will open a downloaded >>>> >>>file. >>>> >>> >>>> >>> So, in a web context the extension does matter, since (by default) the >>>> >>>web server will serve files with a given extension with a certain mime >>>> >>>type. That's the second part of the mime type definition for servers: >>>> >>>"application/vnd.mei+xml .mei" maps all .mei files to the >>>> >>>application/vnd.mei+xml mime type. >>>> >>> >>>> >>> Using .xml is fine if you want to open it in an XML editor. However, >>>> >>>if we want to open it in a notation editor (dreaming of the future) >>>> >>>then it's best if we choose .mei now, and then allow the user to >>>> >>>specify the application that handles it as needed. >>>> >>> >>>> >>> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I >>>> >>>understand, appending vnd. makes the mime type registration process >>>> >>>much easier, since it doesn't need to go through the standards bodies >>>> >>>to be approved. The MusicXML mime type uses the vnd. prefix, something >>>> >>>like "application/vnd.recordare-musicxml+xml" So I thought that we >>>> >>>might go for the easy registration first. It doesn't preclude later >>>> >>>registration of a more formal mimetype. But here I will defer to those >>>> >>>with more experience in the process. >>>> >>> >>>> >>> -Andrew >>>> >>> >>>> >>> >>>> >>> On 2013-08-15, at 6:27 PM, Raffaele Viglianti >>>> >>>> wrote: >>>> >>> >>>> >>> >>>> >>> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson >>>> >>> >>>> >>>> wrote: >>>> >>> >>>> >>> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type >>>> >>>seems like a big problem. >>>> >>> >>>> >>> application/vnd.mei+xml .mei -> Seems like the best solution, yes? >>>> >>> >>>> >>> As far as I know mimetype is orthogonal to file extension, so even if >>>> >>>we secure a mimetype application/mei+xml it won't matter if your file >>>> >>>has .xml or .mei extension. >>>> >>> >>>> >>> I personally don't see an issue with file extension at all. What's the >>>> >>>problem with using either .mei or .xml? In a web context all that >>>> >>>matters is the mimetype, in a OS context, using .xml is generally going >>>> >>>to make things easier, but it's not eventually not a big deal. >>>> >>> >>>> >>> Raf >>>> >>> >>>> >>> >>>> >>> (the MEI mime type I give is just an example). >>>> >>> >>>> >>> -Andrew >>>> >>> >>>> >>> >>>> >>> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg >>>> >>>> >>>> >>> wrote: >>>> >>> >>>> >>>> .txt is a poor choice. Most web servers will deliver that as >>>> >>>>text/plain which is not what you want. In apache web server there is a >>>> >>>>file mime-types which connects extensions to mime types, which then >>>> >>>>interacts with users web clients and plug-ins and helper applications >>>> >>>> >>>> >>>> Sigfrid >>>> >>>> ________________________________________ >>>> >>>> Fra: >>>> >>>>mei-l-bounces at lists.uni-paderborn.de>>> >>>>erborn.de> >>>> >>>>[mei-l-bounces at lists.uni-paderborn.de>>> >>>>derborn.de>] på vegne af Andrew Hankinson >>>> >>>>[andrew.hankinson at mail.mcgill.ca>>> >>>>>] >>>> >>>> Sendt: 15. august 2013 17:23 >>>> >>>> Til: Music Encoding Initiative >>>> >>>> Emne: Re: [MEI-L] File extensions >>>> >>>> >>>> >>>> You can sign me up too. >>>> >>>> >>>> >>>> Personally, I like .mei. XML could also be thought of as plain text, >>>> >>>>so I would argue that we should go with the most specific usage, >>>> >>>>rather than the most general. We could just go with .txt and be just >>>> >>>>as correct as .xml. >>>> >>>> >>>> >>>> Either way, though, I think this is an appropriate topic for putting >>>> >>>>some guidance in the Guidelines. I'll volunteer to write it, but I >>>> >>>>would like some way of getting a consensus. >>>> >>>> >>>> >>>> Any ideas? An online poll? >>>> >>>> >>>> >>>> -Andrew >>>> >>>> >>>> >>>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" >>>> >>>>> >>>> >>>> wrote: >>>> >>>> >>>> >>>>> >>>> >>>>> Sigge, >>>> >>>>> >>>> >>>>> Thanks for being so gracious in your acceptance of my effort to >>>> >>>>>"volunteer" you. >>>> >>>>> >>>> >>>>> There's no rush on this. After Christmas/beginning of 2014 is fine. >>>> >>>>> I'm sure you'll find willing volunteers to help you write the >>>> >>>>>proposal. You can "volunteer" me in return. :-) >>>> >>>>> >>>> >>>>> Anyone who wants to participate, please contact Sigge. I hear he's >>>> >>>>>starting a list. :-) >>>> >>>>> >>>> >>>>> Thanks again, >>>> >>>>> >>>> >>>>> -- >>>> >>>>> 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>>> >>>>>a.edu at lists.uni-paderborn.de> >>>> >>>>>[mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de>>> >>>>>ia.edu at lists.uni-paderborn.de>] on behalf of Sigfrid Lundberg >>>> >>>>>[slu at kb.dk] >>>> >>>>> Sent: Thursday, August 15, 2013 10:49 AM >>>> >>>>> To: Music Encoding Initiative >>>> >>>>> Subject: Re: [MEI-L] File extensions >>>> >>>>> >>>> >>>>> My keyboard is too fast. >>>> >>>>> >>>> >>>>> Cannot promise to write it alone and have to discuss it here in >>>> >>>>>Copenhagen. Not before Christmas, that's for sure >>>> >>>>> >>>> >>>>> S >>>> >>>>> ________________________________________ >>>> >>>>> Fra: >>>> >>>>>mei-l-bounces at lists.uni-paderborn.de>>> >>>>>derborn.de> >>>> >>>>>[mei-l-bounces at lists.uni-paderborn.de>>> >>>>>aderborn.de>] på vegne af Roland, Perry (pdr4h) >>>> >>>>>[pdr4h at eservices.virginia.edu] >>>> >>>>> Sendt: 15. august 2013 16:44 >>>> >>>>> Til: Music Encoding Initiative >>>> >>>>> Emne: Re: [MEI-L] File extensions >>>> >>>>> >>>> >>>>> Hi Sigfrid, >>>> >>>>> >>>> >>>>> Sounds like we have a volunteer to lead the way to registering an >>>> >>>>>MEI mimetype. :-) >>>> >>>>> >>>> >>>>> -- >>>> >>>>> 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>>> >>>>>derborn.de> >>>> >>>>>[mei-l-bounces at lists.uni-paderborn.de>>> >>>>>aderborn.de>] on behalf of Sigfrid Lundberg >>>> >>>>>[slu at kb.dk] >>>> >>>>> Sent: Thursday, August 15, 2013 10:39 AM >>>> >>>>> To: Music Encoding Initiative >>>> >>>>> Subject: Re: [MEI-L] File extensions >>>> >>>>> >>>> >>>>> Hi, >>>> >>>>> >>>> >>>>> I'm using .xml as suffix. Don't really care. >>>> >>>>> >>>> >>>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I >>>> >>>>>have strong opinions on your "by the way" question. Yes, we should >>>> >>>>>register a mime type, and it should be application/mei+xml. Since it >>>> >>>>>is in the application hierarchy it requires an RFC and some >>>> >>>>>negotiations with IESG and IETF before one get a line in the >>>> >>>>>appropriate IANA document. >>>> >>>>> >>>> >>>>> Cheers >>>> >>>>> >>>> >>>>> Sigfrid >>>> >>>>> >>>> >>>>> ________________________________________ >>>> >>>>> Fra: >>>> >>>>>mei-l-bounces at lists.uni-paderborn.de>>> >>>>>derborn.de> >>>> >>>>>[mei-l-bounces at lists.uni-paderborn.de>>> >>>>>aderborn.de>] på vegne af Andrew Hankinson >>>> >>>>>[andrew.hankinson at mail.mcgill.ca>>> >>>>>a>] >>>> >>>>> Sendt: 15. august 2013 16:12 >>>> >>>>> Til: Music Encoding Initiative >>>> >>>>> Emne: [MEI-L] File extensions >>>> >>>>> >>>> >>>>> Hi all, >>>> >>>>> >>>> >>>>> Is there a common understanding of what the proper file extension >>>> >>>>>for MEI files should be? >>>> >>>>> >>>> >>>>> I've been assuming .mei is the "standard", but a counter-example of >>>> >>>>>.xml was recently brought to my attention. So, I thought I'd poll the >>>> >>>>>collected wisdom and see what others were doing. Are you using .xml, >>>> >>>>>.mei, or some other variation on these? >>>> >>>>> >>>> >>>>> -Andrew >>>> >>>>> >>>> >>>>> ==== >>>> >>>>> Related: >>>> >>>>> -- Should we register an actual mimetype? Maybe: >>>> >>>>>application/vnd.music-encoding+xml ? >>>> >>>>> >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> 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 >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> 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 kepper at edirom.de Tue Aug 20 10:23:55 2013 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 20 Aug 2013 10:23:55 +0200 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: <5F985845-AD73-4825-BEA4-6CBB3E040A96@edirom.de> References: <5F985845-AD73-4825-BEA4-6CBB3E040A96@edirom.de> Message-ID: <8556B8EE-29FE-448B-8769-CC7C49962983@edirom.de> After an hour on the car, even more thoughts? Coming back to the question of mime types, I think we all agree that having such a thing would be good. I understand we can head for the standards track (application/mei+xml) or the vendor track (application/vnd.mei+xml). I think Andrew's arguments about keeping control are very similar to the arguments from my last mail, and if the word vendor is really so loosely defined, I'm fine with it. However, I still have one question about the standards track. When all kinds of HTML share a mimetype, can't we get a mimetype for every MEI instance under the sun? If so, would it matter if we change the format? Like HTML, we have means to specify which version one uses, so this shouldn't be a problem, right? I think the mimetype issue is almost completely independent from the question of standardizing MEI itself. Maybe I'm too anxious in this regard, but as Dave pointed out, our resources to work on MEI are not endless. As soon as commercial vendors step in the game, they're not unlikely to put more on the table than we could. I don't think they could overrule us with regard to schema development, but they could establish a de facto standard that fits their needs, but not ours. That said, I'm not at all against the involvement of commercial parties, I just say that we need to be very careful about this, and need to make sure that we don't get ourselves a Trojan Horse (even if it's not supposed to be one). So commercial support for MEI is great, but it has to be clear that MEI is more than just the cmn module, and supporting MEI almost always means supporting a certain subset of MEI. If we communicate this clearly, I'm fine. Best, Johannes Am 20.08.2013 um 08:32 schrieb Johannes Kepper : > Some more thoughts? > > > We had a proposal on a toolkit for MEI, that would have offered several profiles of MEI for specific tasks, conversions between these profiles, and other common tasks that would have facilitated usage of MEI significantly. The plan was to do this as a group, with almost all projects currently developing for MEI being involved. It appears our proposal wasn't spelled convincingly enough, so it didn't go through. However, the idea is still alive, and we're definitely looking for appropriate tracks to re-submit. > > The main difference to the idea of a core set is that we intentionally had several such core sets. It would be easy to identify just one core subset of MEI that would satisfy the needs of average music software developers. It would probably be something like the cmn module, with a reduced header and little else. Actually, not much has changed here in the last three years. However, such a subset would not satisfy the needs of almost all projects currently involved in MEI. It may or may not be appropriate for corpus analysis, but even there, I'd say it neglects the potential of other MEI modules more appropriate to the purpose. > > So yes, such a core set of MEI is likely to increase software support for MEI. But at the same time, it doesn't buy us much more than our own MusicXML equivalent within the world of MEI. We (as academics) still have to (up|down)convert our data into and out of this subset. In essence, there is little gain compared to the current situation with MusicXML and the converter we provide (please note that Perry is working on the opposite direction back into MusicXML right now). But, making such a core subset a Standard recognized by some Standards organization will effectively freeze development on everything that's inside the Standard. In my daily work, I regularly notice areas in MEI that haven't been used much ever since their invention, which may benefit from a gentle remodelling. When I said that the probable core was stable for some years now, this wasn't completely correct. The one big thing we changed significantly was the treatment of ossia. Are we really in the position to say that no such case will be found in the next few years? Even if so, can we exclude the possibility that changes to one of the more distant modules eventually result in changes to this core? > > So instead of defining and standardizing one core set of MEI, I'm in favor of specifying multiple profiles, each for a specific task. Read the word profile as nothing more than a best practice recommendation when you want to interchange with other applications operating in the same area. Actually, the reason for the little amount of code sharing between our projects is the fact that we all operate on different profiles already. > > I'm very much in favor of providing better / more stable "interfaces" for developers. However, I think it is important to clearly communicate the fact that MEI is more than just a well-defined format for common use cases ? it is a framework that offers a whole realm of encoding options, which need to be selected and specified in order to distill an actually usable format. My point is that by providing a whole set of standards (notice the small s) based on / derived from the MEI framework, it seems more likely that we as the scholarly community keep control over MEI as a whole. We need to find the right tradeoff between widest possible dissemination (also in the commercial world) and continued applicability for our scholarly needs. No one ever said that this would be easy? (but isn't the fact that we're facing this problem already an indication of success?) > > Best, > Johannes > > > > > > > > > Am 19.08.2013 um 23:28 schrieb David Meredith: > >> Some thoughts in response to Andrew's wise words. >> >> 1. I don't see why customizability and standardization are mutually exclusive. I would say that there need to be standardized ways of customizing the language and some relatively stable core subset of the language to allow for interchange and interoperability. >> >> 2. I agree that MEI should be developed independently of any particular software clients. However, I think (at least a part of) it should be standardized and stable enough to allow for large-scale information interchange and interoperability, so that A's software can read (at least some core subset of) all those encodings that B has worked so hard to produce; and so that B can use A's software to process his encodings. Writing converters to and from MEI helps, but if I have to convert that rich MEI file into some lesser format like MusicXML, kern or MIDI before I can use it, then I lose much of the value of having the information in MEI in the first place. We need powerful software the fully supports MEI and this requires MEI to have a certain guaranteed level of definition and stability. >> >> 3. MEI is an XML language. This means it is an information storage and interchange format, not a data-structure. Any reasonably complex piece of application software will read in an MEI file and then represent it internally in some data structure designed specifically for the purpose in hand, that may well bear little resemblance to how the information was stored in the original MEI file. The important thing is that MEI is powerful enough to represent/encode all the information and knowledge about a musical object that users need (or may need). I believe MEI is unique in that it has been developed by people who are extremely knowledgeable about and sensitive to the semantics of music notation of a wide variety of types. This means that it is capable of encoding/representing knowledge and information about music notation that no other format/language can. >> >> 4. I don't think anyone can reasonably disagree with the claim that MEI has (relatively) little software support. So far, we have a small number of groups heroically developing software for their own purposes and (relatively) only modest re-use even between these groups. Compared to, say, MIDI, for example, or even, (dare I say it) MusicXML, MEI has relatively little software support. I believe that if a core subset of the MEI specification were managed as a well-recognized stable standard, then it would attract much more interest from software developers. That said, I strongly agree that the definition and development of MEI should remain firmly in the hands of the academics who use it and NOT be transferred to any commercial enterprises. >> >> 5. Of course, the maintenance and development of MEI does not have to be done by means of an official standardization route such as a W3C Recommendation. However, if MEI does not achieve the status of at least a fairly high-profile *de facto* standard, then I'm concerned that it will never achieve the wide-spread use that I believe it deserves. >> >> Incidentally, there do not currently seem to be any W3C working groups or acknowledged member submissions on music notation. Shouldn't we see this as an opportunity for establishing MEI as the standard for representing music notation (of all types) on the web? >> >> Cheers, >> Dave >> >> >> >> From: Andrew Hankinson >> Reply-To: Music Encoding Initiative >> Date: Monday, 19 August 2013 21:51 >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Standards (was: File extensions) >> >>> I'm just full of opinions today? :) >>> >>> I don't see MEI as a file format. To be a little pedantic, but hopefully make a point: XML is a file format; MEI is a method of arranging objects so that they convey some sort of musical sense. What form that musical sense takes is dependent on what you want to express. What MEI brings to the table that sets it apart from all other encoding systems is a way of doing custom things easily without needing to re-define the parts that you don't care about. In that sense, it's more like a SDK or API than it is to a file format. >>> >>> MEI has always had the "Cart before the Horse" model with respect to developing the encoding independent of any software implementations. I know this was done on purpose, and I think it's because once a software client is involved in the creation of the specification, the implemented features tend to dictate the method of encoding. (Perry can stop me from putting words in his mouth if that's not the case). >>> >>> So I don't agree with Dave's assessment about the lack of interest in developing software support. In fact, I think you would find that there is a lot of interest in developing software for it -- it's just that the software that gets built is for a specific project or purpose, since what we expect from MEI differs from project to project. I came to MEI because it offered a method of encoding OMR; others are using it for digital edition work; some are using it for encoding "close readings" of musical texts, still others are using it for high-level metadata work. This can't all be supported by one client. >>> >>> When I hear that there is "no software support," I think what is meant is that there is no graphical editor that can produce an MEI-encoded file. In that sense, yes, that is somewhat correct. There are other emerging options here, though. The Sibelius MEI plugin is speeding along, thanks to some work by Richard Freedman and his students. The musicxml2mei XSLT is actively developed and constantly enhanced. Craig Sapp's amazing work on transforming other formats to and from MEI has brought MEI to both the KernScores and the Josquin project. Even the MeiSe project gave us some usable graphical software. >>> >>> So while Sibelius, Finale, and MuseScore don't support MEI, the purpose and use of these software packages is often orthogonal to how MEI is actually being used and the software that is actually being developed. I think any attempt at standardization or more rigid specification needs to understand that this is a fundamental feature of MEI, and not a bug that needs to be fixed by stricter definitions. >>> >>> To answer Johannes: There are three "trees" in mime type registration: Standards, Vendor ('vnd.'), and Personal ('prs.'), (otherwise known of as "Vanity.") You can see the mime type registration form here: http://www.iana.org/cgi-bin/mediatypes.pl. >>> >>> The Standards tree is reserved for use by Standards Organizations (W3C, IEEE, ISO, ANSI, etc.) and ownership and control of the mime type is the standards organization, NOT the community that produced the spec. (See: http://tools.ietf.org/html/rfc6838#section-3.1) >>> >>> On the other hand, RFC 6838 says this about Vendor registration: >>> >>> "The vendor tree is used for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly in this context and are considered equivalent. Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree. >>> >>> A registration may be placed in the vendor tree by anyone who needs to interchange files associated with some product or set of products. However, the registration properly belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party in order to correct or update it." >>> >>> http://tools.ietf.org/html/rfc6838#page-6 >>> >>> The third track, Personal, is basically for experimental or internal interchange. It's almost certainly not what we want. >>> >>> So basically, if you want to register a mime type and have it recognized but still retain the freedom to change and modify it without needing to go through a standards body you should go with the Vendor tree. >>> >>> -Andrew >>> >>> On 2013-08-19, at 3:45 PM, Raffaele Viglianti >>> wrote: >>> >>>> I'm not participating in the strategy committee, though I worry about establishing MEI as a W3C working group if that also requires us to come up with a stricter standard that, while keeping the same MEI, it would limit its combinations. >>>> >>>> I'm echoing Johannes' worries of a subset becoming more important than other, perhaps less popular, MEI forms. >>>> >>>> I like very much what Andrew said about MEI: it's a method. I'd say that it's an application of text encoding methods to music. As such, it is not just a file format. >>>> >>>> Application support is important: but flexibility is required to apply text encoding methods and support innovative research. An alternative to boxing MEI within an official standard body is to invest more on the formalization of MEI customization and use, namely ODD. This means a) educating the community to using ODD for describing with both words and elements how they're using MEI; b) creating ODD-parsing applications that can, for example, act as middleware between a project-tailored MEI and a generic MEI application. >>>> >>>> Raf >>>> >>>> >>>> On Mon, Aug 19, 2013 at 7:26 AM, David Meredith wrote: >>>>> Hi all, >>>>> >>>>> Tomorrow, the "strategy" committee is having its first virtual meeting to >>>>> discuss possible ways in which MEI can be managed in the future. >>>>> >>>>> I will be (tentatively) suggesting that we think about managing it as a >>>>> W3C working group. And I have in my diary to prepare a short presentation >>>>> this afternoon about this. (Sychronicity? :) ) >>>>> >>>>> My view is that MEI's volatile and diffuse definition and development is >>>>> *THE* main reason why there has so far been so little interest in >>>>> developing software to support it. Before developing software to support a >>>>> particular file format (let's face it, that's basically what MEI is), a >>>>> software developer needs >>>>> >>>>> 1. a clear definition of what the format is; >>>>> 2. reasonable confidence that his/her software isn't going to become >>>>> obsolete the next time the format's definition is revised; and >>>>> 3. a good idea of how often the format's definition is going to be >>>>> changed, so that they can plan new versions of the software that supports >>>>> it. >>>>> >>>>> These can best be achieved by establishing MEI as a *standard*, with a >>>>> properly published and managed definition and properly established >>>>> processes for developing this definition to accommodate users' changing >>>>> needs while keeping volatility and backwards incompatibility to a minimum >>>>> so that developers aren't scared off. >>>>> >>>>> I'm not completely sure that the W3C route is necessarily the best one, >>>>> but clearly we want some form of standardisation framework that is: >>>>> >>>>> 1. relatively low-ceremony: we're all volunteers, so we don't have oceans >>>>> of time and money to spend on keeping MEI alive; >>>>> 2. well-recognized and international so that we maximise the likelihood of >>>>> people wanting to develop software to support MEI. >>>>> >>>>> If anyone else has experience with this kind of process and would like to >>>>> contribute to tomorrow's meeting, please talk to Benjamin about it. >>>>> >>>>> I agree with Johannes that decisions about the definition and development >>>>> of MEI should remain independent of commercial enterprises. MEI should be >>>>> run by and for the academic community. However, I don't see how clarifying >>>>> and stabilizing the definition and development of MEI would be in any >>>>> sense detrimental. >>>>> >>>>> Cheers, >>>>> Dave >>>>> >>>>> >>>>> On 19/08/2013 12:40, "Johannes Kepper" wrote: >>>>> >>>>>> two cents from someone who's completely in the dark? >>>>>> >>>>>> I don't like the "vendor" term: To my (non-native english) ears, it >>>>>> sounds a little bit too commercial. It may or may not fit for MusicXML, >>>>>> but it doesn't seem to fit for us. If there are other tracks, we should >>>>>> follow them instead. >>>>>> >>>>>> If (S|s)tandard in the mimetype sense means something completely >>>>>> determined, it's not appropriate for us. We shouldn't restrict our future >>>>>> development by stocking ourselves to one specific version of MEI which >>>>>> may not be changed easily anymore. I wouldn't even do this for a defined >>>>>> subset of MEI (like cmn), as it has the potential to cannibalize the >>>>>> community, weakening support for other, more obscure parts of MEI. >>>>>> However, if (S|s)tandard is meant to be more open, I'm fine with this. >>>>>> For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one >>>>>> mimetype? If so, it seems comparable to our situation. >>>>>> >>>>>> >>>>>> best, >>>>>> jo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg : >>>>>> >>>>>>> Sorry for using the word standard. >>>>>>> >>>>>>> Suppose it is better to describe our business as we are dealers in >>>>>>> methodologies for the description of what is known about pieces of >>>>>>> symbolic music. >>>>>>> >>>>>>> As a long term subscriber to the xml-dev list I'm used to worms, which >>>>>>> doesn't mean that I like them, or even eat them. >>>>>>> >>>>>>> Sigfrid >>>>>>> >>>>>>> ________________________________________ >>>>>>> Fra: mei-l-bounces at lists.uni-paderborn.de >>>>>>> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson >>>>>>> [andrew.hankinson at mail.mcgill.ca] >>>>>>> Sendt: 19. august 2013 11:51 >>>>>>> Til: Music Encoding Initiative >>>>>>> Emne: Re: [MEI-L] Standards (was: File extensions) >>>>>>> >>>>>>> Oof. That's a can of worms. >>>>>>> >>>>>>> Warning: Lots of opinions to follow. >>>>>>> >>>>>>> If you're creating physical widgets where part A needs to fit with part >>>>>>> B, big-S Standards can be a great thing. >>>>>>> >>>>>>> For a small and loosely-bound community like MEI, a Standard wouldn't >>>>>>> really bring much to the table, and, I think, would actually cause more >>>>>>> harm than good. What do we standardize? The complete ODD file, including >>>>>>> the parts of the ODD file that are mutually exclusive? (see: integration >>>>>>> of both mensural and CMN timing modules?) The CMN customization? Any >>>>>>> decision to standardize something will likely exclude a significant part >>>>>>> of the community. We can't even come to a consensus about which file >>>>>>> extension to use! >>>>>>> >>>>>>> What MEI brings to the world isn't actually an XML schema. I like to >>>>>>> think that you can express MEI in any formalized structure. XML brings >>>>>>> the ability to validate and impose constraints, but if XML was to be >>>>>>> eclipsed by another structural language (like SGML was eclipsed by XML?) >>>>>>> then I think that the intellectual structure of MEI could simply be >>>>>>> transplanted to the new system. >>>>>>> >>>>>>> So, in a roundabout answer to your question: No, I don't think we're >>>>>>> creating a Standard. I think we're creating a method, and I think with >>>>>>> time and usage certain parts of this method may emerge to a de-facto >>>>>>> standard, or even, yes, a Standard. But MEI as a whole? I don't think we >>>>>>> should even think of trying to register this as a Standard. There's just >>>>>>> too many moving parts. >>>>>>> >>>>>>> A vendor-specific mime type seems to be the most flexible method. In my >>>>>>> reading about mime type registration, the "x-" prefix was used for >>>>>>> experimental or non-standard use. Since RFC6648, however, this has been >>>>>>> deprecated. Current best practice, as far as I can tell, says that >>>>>>> non-standards-track mime types should be registered under the >>>>>>> vendor-specific or personal (vanity) track. I would be happy to be >>>>>>> corrected, though -- I'm new at this! >>>>>>> >>>>>>> So, application/vnd.mei+xml, or application/vnd.mei+json, or >>>>>>> application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle >>>>>>> [1] --- all of these are possibilities, but trying to go through the >>>>>>> Standardization process for them seems like a lot of work for little, >>>>>>> no, or even negative gain. >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> [1] http://www.candlescript.org/doc/candle-markup-reference.htm >>>>>>> >>>>>>> On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: >>>>>>> >>>>>>>> I know that, but why do you want it to register it as a vendor >>>>>>>> specific format. >>>>>>>> >>>>>>>> We're creating a standard, arn't we? >>>>>>>> >>>>>>>> Sigge >>>>>>>> ________________________________________ >>>>>>>> Fra: mei-l-bounces at lists.uni-paderborn.de >>>>>>>> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew >>>>>>>> Hankinson [andrew.hankinson at mail.mcgill.ca] >>>>>>>> Sendt: 16. august 2013 23:53 >>>>>>>> Til: Music Encoding Initiative >>>>>>>> Emne: Re: [MEI-L] File extensions >>>>>>>> >>>>>>>> Not quite orthogonal. A web server will serve files with the specified >>>>>>>> extension as a given mime-type. It's true that you can write the mime >>>>>>>> type to the header if you're in a web application environment, but by >>>>>>>> registering a mime type we can provide a method for placing MEI files >>>>>>>> on a server, and it opening in a default application on the users' >>>>>>>> machine, for example. >>>>>>>> >>>>>>>> This can be especially useful in a mobile environment, where sometimes >>>>>>>> you have limited control over which application will open a downloaded >>>>>>>> file. >>>>>>>> >>>>>>>> So, in a web context the extension does matter, since (by default) the >>>>>>>> web server will serve files with a given extension with a certain mime >>>>>>>> type. That's the second part of the mime type definition for servers: >>>>>>>> "application/vnd.mei+xml .mei" maps all .mei files to the >>>>>>>> application/vnd.mei+xml mime type. >>>>>>>> >>>>>>>> Using .xml is fine if you want to open it in an XML editor. However, >>>>>>>> if we want to open it in a notation editor (dreaming of the future) >>>>>>>> then it's best if we choose .mei now, and then allow the user to >>>>>>>> specify the application that handles it as needed. >>>>>>>> >>>>>>>> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I >>>>>>>> understand, appending vnd. makes the mime type registration process >>>>>>>> much easier, since it doesn't need to go through the standards bodies >>>>>>>> to be approved. The MusicXML mime type uses the vnd. prefix, something >>>>>>>> like "application/vnd.recordare-musicxml+xml" So I thought that we >>>>>>>> might go for the easy registration first. It doesn't preclude later >>>>>>>> registration of a more formal mimetype. But here I will defer to those >>>>>>>> with more experience in the process. >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> >>>>>>>> On 2013-08-15, at 6:27 PM, Raffaele Viglianti >>>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson >>>>>>>> >>>>>>>>> wrote: >>>>>>>> >>>>>>>> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type >>>>>>>> seems like a big problem. >>>>>>>> >>>>>>>> application/vnd.mei+xml .mei -> Seems like the best solution, yes? >>>>>>>> >>>>>>>> As far as I know mimetype is orthogonal to file extension, so even if >>>>>>>> we secure a mimetype application/mei+xml it won't matter if your file >>>>>>>> has .xml or .mei extension. >>>>>>>> >>>>>>>> I personally don't see an issue with file extension at all. What's the >>>>>>>> problem with using either .mei or .xml? In a web context all that >>>>>>>> matters is the mimetype, in a OS context, using .xml is generally going >>>>>>>> to make things easier, but it's not eventually not a big deal. >>>>>>>> >>>>>>>> Raf >>>>>>>> >>>>>>>> >>>>>>>> (the MEI mime type I give is just an example). >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> >>>>>>>> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>>> .txt is a poor choice. Most web servers will deliver that as >>>>>>>>> text/plain which is not what you want. In apache web server there is a >>>>>>>>> file mime-types which connects extensions to mime types, which then >>>>>>>>> interacts with users web clients and plug-ins and helper applications >>>>>>>>> >>>>>>>>> Sigfrid >>>>>>>>> ________________________________________ >>>>>>>>> Fra: >>>>>>>>> mei-l-bounces at lists.uni-paderborn.de>>>>>>>> erborn.de> >>>>>>>>> [mei-l-bounces at lists.uni-paderborn.de>>>>>>>> derborn.de>] på vegne af Andrew Hankinson >>>>>>>>> [andrew.hankinson at mail.mcgill.ca>>>>>>>>> ] >>>>>>>>> Sendt: 15. august 2013 17:23 >>>>>>>>> Til: Music Encoding Initiative >>>>>>>>> Emne: Re: [MEI-L] File extensions >>>>>>>>> >>>>>>>>> You can sign me up too. >>>>>>>>> >>>>>>>>> Personally, I like .mei. XML could also be thought of as plain text, >>>>>>>>> so I would argue that we should go with the most specific usage, >>>>>>>>> rather than the most general. We could just go with .txt and be just >>>>>>>>> as correct as .xml. >>>>>>>>> >>>>>>>>> Either way, though, I think this is an appropriate topic for putting >>>>>>>>> some guidance in the Guidelines. I'll volunteer to write it, but I >>>>>>>>> would like some way of getting a consensus. >>>>>>>>> >>>>>>>>> Any ideas? An online poll? >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sigge, >>>>>>>>>> >>>>>>>>>> Thanks for being so gracious in your acceptance of my effort to >>>>>>>>>> "volunteer" you. >>>>>>>>>> >>>>>>>>>> There's no rush on this. After Christmas/beginning of 2014 is fine. >>>>>>>>>> I'm sure you'll find willing volunteers to help you write the >>>>>>>>>> proposal. You can "volunteer" me in return. :-) >>>>>>>>>> >>>>>>>>>> Anyone who wants to participate, please contact Sigge. I hear he's >>>>>>>>>> starting a list. :-) >>>>>>>>>> >>>>>>>>>> Thanks again, >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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>>>>>>>>> a.edu at lists.uni-paderborn.de> >>>>>>>>>> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de>>>>>>>>> ia.edu at lists.uni-paderborn.de>] on behalf of Sigfrid Lundberg >>>>>>>>>> [slu at kb.dk] >>>>>>>>>> Sent: Thursday, August 15, 2013 10:49 AM >>>>>>>>>> To: Music Encoding Initiative >>>>>>>>>> Subject: Re: [MEI-L] File extensions >>>>>>>>>> >>>>>>>>>> My keyboard is too fast. >>>>>>>>>> >>>>>>>>>> Cannot promise to write it alone and have to discuss it here in >>>>>>>>>> Copenhagen. Not before Christmas, that's for sure >>>>>>>>>> >>>>>>>>>> S >>>>>>>>>> ________________________________________ >>>>>>>>>> Fra: >>>>>>>>>> mei-l-bounces at lists.uni-paderborn.de>>>>>>>>> derborn.de> >>>>>>>>>> [mei-l-bounces at lists.uni-paderborn.de>>>>>>>>> aderborn.de>] på vegne af Roland, Perry (pdr4h) >>>>>>>>>> [pdr4h at eservices.virginia.edu] >>>>>>>>>> Sendt: 15. august 2013 16:44 >>>>>>>>>> Til: Music Encoding Initiative >>>>>>>>>> Emne: Re: [MEI-L] File extensions >>>>>>>>>> >>>>>>>>>> Hi Sigfrid, >>>>>>>>>> >>>>>>>>>> Sounds like we have a volunteer to lead the way to registering an >>>>>>>>>> MEI mimetype. :-) >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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>>>>>>>>> derborn.de> >>>>>>>>>> [mei-l-bounces at lists.uni-paderborn.de>>>>>>>>> aderborn.de>] on behalf of Sigfrid Lundberg >>>>>>>>>> [slu at kb.dk] >>>>>>>>>> Sent: Thursday, August 15, 2013 10:39 AM >>>>>>>>>> To: Music Encoding Initiative >>>>>>>>>> Subject: Re: [MEI-L] File extensions >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I'm using .xml as suffix. Don't really care. >>>>>>>>>> >>>>>>>>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I >>>>>>>>>> have strong opinions on your "by the way" question. Yes, we should >>>>>>>>>> register a mime type, and it should be application/mei+xml. Since it >>>>>>>>>> is in the application hierarchy it requires an RFC and some >>>>>>>>>> negotiations with IESG and IETF before one get a line in the >>>>>>>>>> appropriate IANA document. >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> >>>>>>>>>> Sigfrid >>>>>>>>>> >>>>>>>>>> ________________________________________ >>>>>>>>>> Fra: >>>>>>>>>> mei-l-bounces at lists.uni-paderborn.de>>>>>>>>> derborn.de> >>>>>>>>>> [mei-l-bounces at lists.uni-paderborn.de>>>>>>>>> aderborn.de>] på vegne af Andrew Hankinson >>>>>>>>>> [andrew.hankinson at mail.mcgill.ca>>>>>>>>> a>] >>>>>>>>>> Sendt: 15. august 2013 16:12 >>>>>>>>>> Til: Music Encoding Initiative >>>>>>>>>> Emne: [MEI-L] File extensions >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Is there a common understanding of what the proper file extension >>>>>>>>>> for MEI files should be? >>>>>>>>>> >>>>>>>>>> I've been assuming .mei is the "standard", but a counter-example of >>>>>>>>>> .xml was recently brought to my attention. So, I thought I'd poll the >>>>>>>>>> collected wisdom and see what others were doing. Are you using .xml, >>>>>>>>>> .mei, or some other variation on these? >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> >>>>>>>>>> ==== >>>>>>>>>> Related: >>>>>>>>>> -- Should we register an actual mimetype? Maybe: >>>>>>>>>> application/vnd.music-encoding+xml ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 laurent at music.mcgill.ca Tue Aug 20 10:36:28 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Tue, 20 Aug 2013 10:36:28 +0200 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: <32748_1376980352_52130D7F_32748_299_1_5F985845-AD73-4825-BEA4-6CBB3E040A96@edirom.de> References: <32748_1376980352_52130D7F_32748_299_1_5F985845-AD73-4825-BEA4-6CBB3E040A96@edirom.de> Message-ID: One more remark: I can perfectly see the drawback of seeing MEI becoming a standard if this can make it loose some of its flexibility in its development. However, I am pretty sure we all aim at seeing MEI becoming as stable as possible. When developing tools, be they commercial or scholarly, changes in the specifications create extra work. In a way, making well organized and versioned releases as we do now is a way of standardizing it. And we certainly hope to see the frequency of the versions to be as low as possible. Versioning with a standard is also possible, isn't 'it? So to me, the question is more to see if we can find a standardization path or structure that do not create overhead that we can not afford. Best, Laurent On Tue, Aug 20, 2013 at 8:32 AM, Johannes Kepper wrote: > Some more thoughts? > > > We had a proposal on a toolkit for MEI, that would have offered several > profiles of MEI for specific tasks, conversions between these profiles, and > other common tasks that would have facilitated usage of MEI significantly. > The plan was to do this as a group, with almost all projects currently > developing for MEI being involved. It appears our proposal wasn't spelled > convincingly enough, so it didn't go through. However, the idea is still > alive, and we're definitely looking for appropriate tracks to re-submit. > > The main difference to the idea of a core set is that we intentionally had > several such core sets. It would be easy to identify just one core subset > of MEI that would satisfy the needs of average music software developers. > It would probably be something like the cmn module, with a reduced header > and little else. Actually, not much has changed here in the last three > years. However, such a subset would not satisfy the needs of almost all > projects currently involved in MEI. It may or may not be appropriate for > corpus analysis, but even there, I'd say it neglects the potential of other > MEI modules more appropriate to the purpose. > > So yes, such a core set of MEI is likely to increase software support for > MEI. But at the same time, it doesn't buy us much more than our own > MusicXML equivalent within the world of MEI. We (as academics) still have > to (up|down)convert our data into and out of this subset. In essence, there > is little gain compared to the current situation with MusicXML and the > converter we provide (please note that Perry is working on the opposite > direction back into MusicXML right now). But, making such a core subset a > Standard recognized by some Standards organization will effectively freeze > development on everything that's inside the Standard. In my daily work, I > regularly notice areas in MEI that haven't been used much ever since their > invention, which may benefit from a gentle remodelling. When I said that > the probable core was stable for some years now, this wasn't completely > correct. The one big thing we changed significantly was the treatment of > ossia. Are we really in the position to say that no such case will be found > in the next few years? Even if so, can we exclude the possibility that > changes to one of the more distant modules eventually result in changes to > this core? > > So instead of defining and standardizing one core set of MEI, I'm in favor > of specifying multiple profiles, each for a specific task. Read the word > profile as nothing more than a best practice recommendation when you want > to interchange with other applications operating in the same area. > Actually, the reason for the little amount of code sharing between our > projects is the fact that we all operate on different profiles already. > > I'm very much in favor of providing better / more stable "interfaces" for > developers. However, I think it is important to clearly communicate the > fact that MEI is more than just a well-defined format for common use cases > ? it is a framework that offers a whole realm of encoding options, which > need to be selected and specified in order to distill an actually usable > format. My point is that by providing a whole set of standards (notice the > small s) based on / derived from the MEI framework, it seems more likely > that we as the scholarly community keep control over MEI as a whole. We > need to find the right tradeoff between widest possible dissemination (also > in the commercial world) and continued applicability for our scholarly > needs. No one ever said that this would be easy? (but isn't the fact that > we're facing this problem already an indication of success?) > > Best, > Johannes > > > > > > > > > Am 19.08.2013 um 23:28 schrieb David Meredith: > > > Some thoughts in response to Andrew's wise words. > > > > 1. I don't see why customizability and standardization are mutually > exclusive. I would say that there need to be standardized ways of > customizing the language and some relatively stable core subset of the > language to allow for interchange and interoperability. > > > > 2. I agree that MEI should be developed independently of any particular > software clients. However, I think (at least a part of) it should be > standardized and stable enough to allow for large-scale information > interchange and interoperability, so that A's software can read (at least > some core subset of) all those encodings that B has worked so hard to > produce; and so that B can use A's software to process his encodings. > Writing converters to and from MEI helps, but if I have to convert that > rich MEI file into some lesser format like MusicXML, kern or MIDI before I > can use it, then I lose much of the value of having the information in MEI > in the first place. We need powerful software the fully supports MEI and > this requires MEI to have a certain guaranteed level of definition and > stability. > > > > 3. MEI is an XML language. This means it is an information storage and > interchange format, not a data-structure. Any reasonably complex piece of > application software will read in an MEI file and then represent it > internally in some data structure designed specifically for the purpose in > hand, that may well bear little resemblance to how the information was > stored in the original MEI file. The important thing is that MEI is > powerful enough to represent/encode all the information and knowledge about > a musical object that users need (or may need). I believe MEI is unique in > that it has been developed by people who are extremely knowledgeable about > and sensitive to the semantics of music notation of a wide variety of > types. This means that it is capable of encoding/representing knowledge and > information about music notation that no other format/language can. > > > > 4. I don't think anyone can reasonably disagree with the claim that MEI > has (relatively) little software support. So far, we have a small number of > groups heroically developing software for their own purposes and > (relatively) only modest re-use even between these groups. Compared to, > say, MIDI, for example, or even, (dare I say it) MusicXML, MEI has > relatively little software support. I believe that if a core subset of the > MEI specification were managed as a well-recognized stable standard, then > it would attract much more interest from software developers. That said, I > strongly agree that the definition and development of MEI should remain > firmly in the hands of the academics who use it and NOT be transferred to > any commercial enterprises. > > > > 5. Of course, the maintenance and development of MEI does not have to be > done by means of an official standardization route such as a W3C > Recommendation. However, if MEI does not achieve the status of at least a > fairly high-profile *de facto* standard, then I'm concerned that it will > never achieve the wide-spread use that I believe it deserves. > > > > Incidentally, there do not currently seem to be any W3C working groups > or acknowledged member submissions on music notation. Shouldn't we see this > as an opportunity for establishing MEI as the standard for representing > music notation (of all types) on the web? > > > > Cheers, > > Dave > > > > > > > > From: Andrew Hankinson > > Reply-To: Music Encoding Initiative > > Date: Monday, 19 August 2013 21:51 > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Standards (was: File extensions) > > > >> I'm just full of opinions today? :) > >> > >> I don't see MEI as a file format. To be a little pedantic, but > hopefully make a point: XML is a file format; MEI is a method of arranging > objects so that they convey some sort of musical sense. What form that > musical sense takes is dependent on what you want to express. What MEI > brings to the table that sets it apart from all other encoding systems is a > way of doing custom things easily without needing to re-define the parts > that you don't care about. In that sense, it's more like a SDK or API than > it is to a file format. > >> > >> MEI has always had the "Cart before the Horse" model with respect to > developing the encoding independent of any software implementations. I know > this was done on purpose, and I think it's because once a software client > is involved in the creation of the specification, the implemented features > tend to dictate the method of encoding. (Perry can stop me from putting > words in his mouth if that's not the case). > >> > >> So I don't agree with Dave's assessment about the lack of interest in > developing software support. In fact, I think you would find that there is > a lot of interest in developing software for it -- it's just that the > software that gets built is for a specific project or purpose, since what > we expect from MEI differs from project to project. I came to MEI because > it offered a method of encoding OMR; others are using it for digital > edition work; some are using it for encoding "close readings" of musical > texts, still others are using it for high-level metadata work. This can't > all be supported by one client. > >> > >> When I hear that there is "no software support," I think what is meant > is that there is no graphical editor that can produce an MEI-encoded file. > In that sense, yes, that is somewhat correct. There are other emerging > options here, though. The Sibelius MEI plugin is speeding along, thanks to > some work by Richard Freedman and his students. The musicxml2mei XSLT is > actively developed and constantly enhanced. Craig Sapp's amazing work on > transforming other formats to and from MEI has brought MEI to both the > KernScores and the Josquin project. Even the MeiSe project gave us some > usable graphical software. > >> > >> So while Sibelius, Finale, and MuseScore don't support MEI, the purpose > and use of these software packages is often orthogonal to how MEI is > actually being used and the software that is actually being developed. I > think any attempt at standardization or more rigid specification needs to > understand that this is a fundamental feature of MEI, and not a bug that > needs to be fixed by stricter definitions. > >> > >> To answer Johannes: There are three "trees" in mime type registration: > Standards, Vendor ('vnd.'), and Personal ('prs.'), (otherwise known of as > "Vanity.") You can see the mime type registration form here: > http://www.iana.org/cgi-bin/mediatypes.pl. > >> > >> The Standards tree is reserved for use by Standards Organizations (W3C, > IEEE, ISO, ANSI, etc.) and ownership and control of the mime type is the > standards organization, NOT the community that produced the spec. (See: > http://tools.ietf.org/html/rfc6838#section-3.1) > >> > >> On the other hand, RFC 6838 says this about Vendor registration: > >> > >> "The vendor tree is used for media types associated with publicly > available products. "Vendor" and "producer" are construed very broadly in > this context and are considered equivalent. Note that industry consortia as > well as non-commercial entities that do not qualify as recognized > standards-related organizations can quite appropriately register media > types in the vendor tree. > >> > >> A registration may be placed in the vendor tree by anyone who needs to > interchange files associated with some product or set of products. However, > the registration properly belongs to the vendor or organization producing > the software that employs the type being registered, and that vendor or > organization can at any time elect to assert ownership of a registration > done by a third party in order to correct or update it." > >> > >> http://tools.ietf.org/html/rfc6838#page-6 > >> > >> The third track, Personal, is basically for experimental or internal > interchange. It's almost certainly not what we want. > >> > >> So basically, if you want to register a mime type and have it > recognized but still retain the freedom to change and modify it without > needing to go through a standards body you should go with the Vendor tree. > >> > >> -Andrew > >> > >> On 2013-08-19, at 3:45 PM, Raffaele Viglianti < > raffaeleviglianti at gmail.com> > >> wrote: > >> > >>> I'm not participating in the strategy committee, though I worry about > establishing MEI as a W3C working group if that also requires us to come up > with a stricter standard that, while keeping the same MEI, it would limit > its combinations. > >>> > >>> I'm echoing Johannes' worries of a subset becoming more important than > other, perhaps less popular, MEI forms. > >>> > >>> I like very much what Andrew said about MEI: it's a method. I'd say > that it's an application of text encoding methods to music. As such, it is > not just a file format. > >>> > >>> Application support is important: but flexibility is required to apply > text encoding methods and support innovative research. An alternative to > boxing MEI within an official standard body is to invest more on the > formalization of MEI customization and use, namely ODD. This means a) > educating the community to using ODD for describing with both words and > elements how they're using MEI; b) creating ODD-parsing applications that > can, for example, act as middleware between a project-tailored MEI and a > generic MEI application. > >>> > >>> Raf > >>> > >>> > >>> On Mon, Aug 19, 2013 at 7:26 AM, David Meredith > wrote: > >>>> Hi all, > >>>> > >>>> Tomorrow, the "strategy" committee is having its first virtual > meeting to > >>>> discuss possible ways in which MEI can be managed in the future. > >>>> > >>>> I will be (tentatively) suggesting that we think about managing it as > a > >>>> W3C working group. And I have in my diary to prepare a short > presentation > >>>> this afternoon about this. (Sychronicity? :) ) > >>>> > >>>> My view is that MEI's volatile and diffuse definition and development > is > >>>> *THE* main reason why there has so far been so little interest in > >>>> developing software to support it. Before developing software to > support a > >>>> particular file format (let's face it, that's basically what MEI is), > a > >>>> software developer needs > >>>> > >>>> 1. a clear definition of what the format is; > >>>> 2. reasonable confidence that his/her software isn't going to become > >>>> obsolete the next time the format's definition is revised; and > >>>> 3. a good idea of how often the format's definition is going to be > >>>> changed, so that they can plan new versions of the software that > supports > >>>> it. > >>>> > >>>> These can best be achieved by establishing MEI as a *standard*, with a > >>>> properly published and managed definition and properly established > >>>> processes for developing this definition to accommodate users' > changing > >>>> needs while keeping volatility and backwards incompatibility to a > minimum > >>>> so that developers aren't scared off. > >>>> > >>>> I'm not completely sure that the W3C route is necessarily the best > one, > >>>> but clearly we want some form of standardisation framework that is: > >>>> > >>>> 1. relatively low-ceremony: we're all volunteers, so we don't have > oceans > >>>> of time and money to spend on keeping MEI alive; > >>>> 2. well-recognized and international so that we maximise the > likelihood of > >>>> people wanting to develop software to support MEI. > >>>> > >>>> If anyone else has experience with this kind of process and would > like to > >>>> contribute to tomorrow's meeting, please talk to Benjamin about it. > >>>> > >>>> I agree with Johannes that decisions about the definition and > development > >>>> of MEI should remain independent of commercial enterprises. MEI > should be > >>>> run by and for the academic community. However, I don't see how > clarifying > >>>> and stabilizing the definition and development of MEI would be in any > >>>> sense detrimental. > >>>> > >>>> Cheers, > >>>> Dave > >>>> > >>>> > >>>> On 19/08/2013 12:40, "Johannes Kepper" wrote: > >>>> > >>>> >two cents from someone who's completely in the dark? > >>>> > > >>>> >I don't like the "vendor" term: To my (non-native english) ears, it > >>>> >sounds a little bit too commercial. It may or may not fit for > MusicXML, > >>>> >but it doesn't seem to fit for us. If there are other tracks, we > should > >>>> >follow them instead. > >>>> > > >>>> >If (S|s)tandard in the mimetype sense means something completely > >>>> >determined, it's not appropriate for us. We shouldn't restrict our > future > >>>> >development by stocking ourselves to one specific version of MEI > which > >>>> >may not be changed easily anymore. I wouldn't even do this for a > defined > >>>> >subset of MEI (like cmn), as it has the potential to cannibalize the > >>>> >community, weakening support for other, more obscure parts of MEI. > >>>> >However, if (S|s)tandard is meant to be more open, I'm fine with > this. > >>>> >For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share > one > >>>> >mimetype? If so, it seems comparable to our situation. > >>>> > > >>>> > > >>>> >best, > >>>> >jo > >>>> > > >>>> > > >>>> > > >>>> > > >>>> >Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg : > >>>> > > >>>> >> Sorry for using the word standard. > >>>> >> > >>>> >> Suppose it is better to describe our business as we are dealers in > >>>> >>methodologies for the description of what is known about pieces of > >>>> >>symbolic music. > >>>> >> > >>>> >> As a long term subscriber to the xml-dev list I'm used to worms, > which > >>>> >>doesn't mean that I like them, or even eat them. > >>>> >> > >>>> >> Sigfrid > >>>> >> > >>>> >> ________________________________________ > >>>> >> Fra: mei-l-bounces at lists.uni-paderborn.de > >>>> >>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew > Hankinson > >>>> >>[andrew.hankinson at mail.mcgill.ca] > >>>> >> Sendt: 19. august 2013 11:51 > >>>> >> Til: Music Encoding Initiative > >>>> >> Emne: Re: [MEI-L] Standards (was: File extensions) > >>>> >> > >>>> >> Oof. That's a can of worms. > >>>> >> > >>>> >> Warning: Lots of opinions to follow. > >>>> >> > >>>> >> If you're creating physical widgets where part A needs to fit with > part > >>>> >>B, big-S Standards can be a great thing. > >>>> >> > >>>> >> For a small and loosely-bound community like MEI, a Standard > wouldn't > >>>> >>really bring much to the table, and, I think, would actually cause > more > >>>> >>harm than good. What do we standardize? The complete ODD file, > including > >>>> >>the parts of the ODD file that are mutually exclusive? (see: > integration > >>>> >>of both mensural and CMN timing modules?) The CMN customization? Any > >>>> >>decision to standardize something will likely exclude a significant > part > >>>> >>of the community. We can't even come to a consensus about which file > >>>> >>extension to use! > >>>> >> > >>>> >> What MEI brings to the world isn't actually an XML schema. I like > to > >>>> >>think that you can express MEI in any formalized structure. XML > brings > >>>> >>the ability to validate and impose constraints, but if XML was to be > >>>> >>eclipsed by another structural language (like SGML was eclipsed by > XML?) > >>>> >>then I think that the intellectual structure of MEI could simply be > >>>> >>transplanted to the new system. > >>>> >> > >>>> >> So, in a roundabout answer to your question: No, I don't think > we're > >>>> >>creating a Standard. I think we're creating a method, and I think > with > >>>> >>time and usage certain parts of this method may emerge to a de-facto > >>>> >>standard, or even, yes, a Standard. But MEI as a whole? I don't > think we > >>>> >>should even think of trying to register this as a Standard. There's > just > >>>> >>too many moving parts. > >>>> >> > >>>> >> A vendor-specific mime type seems to be the most flexible method. > In my > >>>> >>reading about mime type registration, the "x-" prefix was used for > >>>> >>experimental or non-standard use. Since RFC6648, however, this has > been > >>>> >>deprecated. Current best practice, as far as I can tell, says that > >>>> >>non-standards-track mime types should be registered under the > >>>> >>vendor-specific or personal (vanity) track. I would be happy to be > >>>> >>corrected, though -- I'm new at this! > >>>> >> > >>>> >> So, application/vnd.mei+xml, or application/vnd.mei+json, or > >>>> >>application/vnd.mei-common+yaml, or > application/vnd.mei-mensural+candle > >>>> >>[1] --- all of these are possibilities, but trying to go through the > >>>> >>Standardization process for them seems like a lot of work for > little, > >>>> >>no, or even negative gain. > >>>> >> > >>>> >> -Andrew > >>>> >> > >>>> >> [1] http://www.candlescript.org/doc/candle-markup-reference.htm > >>>> >> > >>>> >> On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: > >>>> >> > >>>> >>> I know that, but why do you want it to register it as a vendor > >>>> >>>specific format. > >>>> >>> > >>>> >>> We're creating a standard, arn't we? > >>>> >>> > >>>> >>> Sigge > >>>> >>> ________________________________________ > >>>> >>> Fra: mei-l-bounces at lists.uni-paderborn.de > >>>> >>>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew > >>>> >>>Hankinson [andrew.hankinson at mail.mcgill.ca] > >>>> >>> Sendt: 16. august 2013 23:53 > >>>> >>> Til: Music Encoding Initiative > >>>> >>> Emne: Re: [MEI-L] File extensions > >>>> >>> > >>>> >>> Not quite orthogonal. A web server will serve files with the > specified > >>>> >>>extension as a given mime-type. It's true that you can write the > mime > >>>> >>>type to the header if you're in a web application environment, but > by > >>>> >>>registering a mime type we can provide a method for placing MEI > files > >>>> >>>on a server, and it opening in a default application on the users' > >>>> >>>machine, for example. > >>>> >>> > >>>> >>> This can be especially useful in a mobile environment, where > sometimes > >>>> >>>you have limited control over which application will open a > downloaded > >>>> >>>file. > >>>> >>> > >>>> >>> So, in a web context the extension does matter, since (by > default) the > >>>> >>>web server will serve files with a given extension with a certain > mime > >>>> >>>type. That's the second part of the mime type definition for > servers: > >>>> >>>"application/vnd.mei+xml .mei" maps all .mei files to the > >>>> >>>application/vnd.mei+xml mime type. > >>>> >>> > >>>> >>> Using .xml is fine if you want to open it in an XML editor. > However, > >>>> >>>if we want to open it in a notation editor (dreaming of the future) > >>>> >>>then it's best if we choose .mei now, and then allow the user to > >>>> >>>specify the application that handles it as needed. > >>>> >>> > >>>> >>> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far > as I > >>>> >>>understand, appending vnd. makes the mime type registration process > >>>> >>>much easier, since it doesn't need to go through the standards > bodies > >>>> >>>to be approved. The MusicXML mime type uses the vnd. prefix, > something > >>>> >>>like "application/vnd.recordare-musicxml+xml" So I thought that we > >>>> >>>might go for the easy registration first. It doesn't preclude later > >>>> >>>registration of a more formal mimetype. But here I will defer to > those > >>>> >>>with more experience in the process. > >>>> >>> > >>>> >>> -Andrew > >>>> >>> > >>>> >>> > >>>> >>> On 2013-08-15, at 6:27 PM, Raffaele Viglianti > >>>> >>>> > wrote: > >>>> >>> > >>>> >>> > >>>> >>> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson > >>>> >>> andrew.hankinson at mail.mcgill.ca> > >>>> >>>> wrote: > >>>> >>> > >>>> >>> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type > >>>> >>>seems like a big problem. > >>>> >>> > >>>> >>> application/vnd.mei+xml .mei -> Seems like the best solution, yes? > >>>> >>> > >>>> >>> As far as I know mimetype is orthogonal to file extension, so > even if > >>>> >>>we secure a mimetype application/mei+xml it won't matter if your > file > >>>> >>>has .xml or .mei extension. > >>>> >>> > >>>> >>> I personally don't see an issue with file extension at all. > What's the > >>>> >>>problem with using either .mei or .xml? In a web context all that > >>>> >>>matters is the mimetype, in a OS context, using .xml is generally > going > >>>> >>>to make things easier, but it's not eventually not a big deal. > >>>> >>> > >>>> >>> Raf > >>>> >>> > >>>> >>> > >>>> >>> (the MEI mime type I give is just an example). > >>>> >>> > >>>> >>> -Andrew > >>>> >>> > >>>> >>> > >>>> >>> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > >>>> >>>> > >>>> >>> wrote: > >>>> >>> > >>>> >>>> .txt is a poor choice. Most web servers will deliver that as > >>>> >>>>text/plain which is not what you want. In apache web server there > is a > >>>> >>>>file mime-types which connects extensions to mime types, which > then > >>>> >>>>interacts with users web clients and plug-ins and helper > applications > >>>> >>>> > >>>> >>>> Sigfrid > >>>> >>>> ________________________________________ > >>>> >>>> Fra: > >>>> >>>>mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-pad > >>>> >>>>erborn.de> > >>>> >>>>[mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-pa > >>>> >>>>derborn.de>] på vegne af Andrew Hankinson > >>>> >>>>[andrew.hankinson at mail.mcgill.ca andrew.hankinson at mail.mcgill.ca > >>>> >>>>>] > >>>> >>>> Sendt: 15. august 2013 17:23 > >>>> >>>> Til: Music Encoding Initiative > >>>> >>>> Emne: Re: [MEI-L] File extensions > >>>> >>>> > >>>> >>>> You can sign me up too. > >>>> >>>> > >>>> >>>> Personally, I like .mei. XML could also be thought of as plain > text, > >>>> >>>>so I would argue that we should go with the most specific usage, > >>>> >>>>rather than the most general. We could just go with .txt and be > just > >>>> >>>>as correct as .xml. > >>>> >>>> > >>>> >>>> Either way, though, I think this is an appropriate topic for > putting > >>>> >>>>some guidance in the Guidelines. I'll volunteer to write it, but I > >>>> >>>>would like some way of getting a consensus. > >>>> >>>> > >>>> >>>> Any ideas? An online poll? > >>>> >>>> > >>>> >>>> -Andrew > >>>> >>>> > >>>> >>>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > >>>> >>>> >> > >>>> >>>> wrote: > >>>> >>>> > >>>> >>>>> > >>>> >>>>> Sigge, > >>>> >>>>> > >>>> >>>>> Thanks for being so gracious in your acceptance of my effort to > >>>> >>>>>"volunteer" you. > >>>> >>>>> > >>>> >>>>> There's no rush on this. After Christmas/beginning of 2014 is > fine. > >>>> >>>>> I'm sure you'll find willing volunteers to help you write the > >>>> >>>>>proposal. You can "volunteer" me in return. :-) > >>>> >>>>> > >>>> >>>>> Anyone who wants to participate, please contact Sigge. I hear > he's > >>>> >>>>>starting a list. :-) > >>>> >>>>> > >>>> >>>>> Thanks again, > >>>> >>>>> > >>>> >>>>> -- > >>>> >>>>> 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 virgini > >>>> >>>>>a.edu at lists.uni-paderborn.de> > >>>> >>>>>[mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de virgin > >>>> >>>>>ia.edu at lists.uni-paderborn.de>] on behalf of Sigfrid Lundberg > >>>> >>>>>[slu at kb.dk] > >>>> >>>>> Sent: Thursday, August 15, 2013 10:49 AM > >>>> >>>>> To: Music Encoding Initiative > >>>> >>>>> Subject: Re: [MEI-L] File extensions > >>>> >>>>> > >>>> >>>>> My keyboard is too fast. > >>>> >>>>> > >>>> >>>>> Cannot promise to write it alone and have to discuss it here in > >>>> >>>>>Copenhagen. Not before Christmas, that's for sure > >>>> >>>>> > >>>> >>>>> S > >>>> >>>>> ________________________________________ > >>>> >>>>> Fra: > >>>> >>>>>mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-pa > >>>> >>>>>derborn.de> > >>>> >>>>>[mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-p > >>>> >>>>>aderborn.de>] på vegne af Roland, Perry (pdr4h) > >>>> >>>>>[pdr4h at eservices.virginia.edu pdr4h at eservices.virginia.edu>] > >>>> >>>>> Sendt: 15. august 2013 16:44 > >>>> >>>>> Til: Music Encoding Initiative > >>>> >>>>> Emne: Re: [MEI-L] File extensions > >>>> >>>>> > >>>> >>>>> Hi Sigfrid, > >>>> >>>>> > >>>> >>>>> Sounds like we have a volunteer to lead the way to registering > an > >>>> >>>>>MEI mimetype. :-) > >>>> >>>>> > >>>> >>>>> -- > >>>> >>>>> 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-pa > >>>> >>>>>derborn.de> > >>>> >>>>>[mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-p > >>>> >>>>>aderborn.de>] on behalf of Sigfrid Lundberg > >>>> >>>>>[slu at kb.dk] > >>>> >>>>> Sent: Thursday, August 15, 2013 10:39 AM > >>>> >>>>> To: Music Encoding Initiative > >>>> >>>>> Subject: Re: [MEI-L] File extensions > >>>> >>>>> > >>>> >>>>> Hi, > >>>> >>>>> > >>>> >>>>> I'm using .xml as suffix. Don't really care. > >>>> >>>>> > >>>> >>>>> As I'm a coauthor of RFC6129 ( > http://tools.ietf.org/html/rfc6129) I > >>>> >>>>>have strong opinions on your "by the way" question. Yes, we > should > >>>> >>>>>register a mime type, and it should be application/mei+xml. > Since it > >>>> >>>>>is in the application hierarchy it requires an RFC and some > >>>> >>>>>negotiations with IESG and IETF before one get a line in the > >>>> >>>>>appropriate IANA document. > >>>> >>>>> > >>>> >>>>> Cheers > >>>> >>>>> > >>>> >>>>> Sigfrid > >>>> >>>>> > >>>> >>>>> ________________________________________ > >>>> >>>>> Fra: > >>>> >>>>>mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-pa > >>>> >>>>>derborn.de> > >>>> >>>>>[mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-p > >>>> >>>>>aderborn.de>] på vegne af Andrew Hankinson > >>>> >>>>>[andrew.hankinson at mail.mcgill.ca andrew.hankinson at mail.mcgill.c > >>>> >>>>>a>] > >>>> >>>>> Sendt: 15. august 2013 16:12 > >>>> >>>>> Til: Music Encoding Initiative > >>>> >>>>> Emne: [MEI-L] File extensions > >>>> >>>>> > >>>> >>>>> Hi all, > >>>> >>>>> > >>>> >>>>> Is there a common understanding of what the proper file > extension > >>>> >>>>>for MEI files should be? > >>>> >>>>> > >>>> >>>>> I've been assuming .mei is the "standard", but a > counter-example of > >>>> >>>>>.xml was recently brought to my attention. So, I thought I'd > poll the > >>>> >>>>>collected wisdom and see what others were doing. Are you using > .xml, > >>>> >>>>>.mei, or some other variation on these? > >>>> >>>>> > >>>> >>>>> -Andrew > >>>> >>>>> > >>>> >>>>> ==== > >>>> >>>>> Related: > >>>> >>>>> -- Should we register an actual mimetype? Maybe: > >>>> >>>>>application/vnd.music-encoding+xml ? > >>>> >>>>> > >>>> >>>>> > >>>> >>>>> _______________________________________________ > >>>> >>>>> mei-l mailing list > >>>> >>>>> mei-l at lists.uni-paderborn.de 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 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 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 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 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 > >>> > >>> _______________________________________________ > >>> 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 > > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From kepper at edirom.de Tue Aug 20 10:38:16 2013 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 20 Aug 2013 10:38:16 +0200 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: References: <32748_1376980352_52130D7F_32748_299_1_5F985845-AD73-4825-BEA4-6CBB3E040A96@edirom.de> Message-ID: <80887EC5-CFBF-4B59-BC6F-D2B0B22446C1@edirom.de> +1 Am 20.08.2013 um 10:36 schrieb Laurent Pugin : > One more remark: I can perfectly see the drawback of seeing MEI becoming a standard if this can make it loose some of its flexibility in its development. However, I am pretty sure we all aim at seeing MEI becoming as stable as possible. When developing tools, be they commercial or scholarly, changes in the specifications create extra work. In a way, making well organized and versioned releases as we do now is a way of standardizing it. And we certainly hope to see the frequency of the versions to be as low as possible. Versioning with a standard is also possible, isn't 'it? So to me, the question is more to see if we can find a standardization path or structure that do not create overhead that we can not afford. > > Best, > Laurent > > > On Tue, Aug 20, 2013 at 8:32 AM, Johannes Kepper wrote: > Some more thoughts? > > > We had a proposal on a toolkit for MEI, that would have offered several profiles of MEI for specific tasks, conversions between these profiles, and other common tasks that would have facilitated usage of MEI significantly. The plan was to do this as a group, with almost all projects currently developing for MEI being involved. It appears our proposal wasn't spelled convincingly enough, so it didn't go through. However, the idea is still alive, and we're definitely looking for appropriate tracks to re-submit. > > The main difference to the idea of a core set is that we intentionally had several such core sets. It would be easy to identify just one core subset of MEI that would satisfy the needs of average music software developers. It would probably be something like the cmn module, with a reduced header and little else. Actually, not much has changed here in the last three years. However, such a subset would not satisfy the needs of almost all projects currently involved in MEI. It may or may not be appropriate for corpus analysis, but even there, I'd say it neglects the potential of other MEI modules more appropriate to the purpose. > > So yes, such a core set of MEI is likely to increase software support for MEI. But at the same time, it doesn't buy us much more than our own MusicXML equivalent within the world of MEI. We (as academics) still have to (up|down)convert our data into and out of this subset. In essence, there is little gain compared to the current situation with MusicXML and the converter we provide (please note that Perry is working on the opposite direction back into MusicXML right now). But, making such a core subset a Standard recognized by some Standards organization will effectively freeze development on everything that's inside the Standard. In my daily work, I regularly notice areas in MEI that haven't been used much ever since their invention, which may benefit from a gentle remodelling. When I said that the probable core was stable for some years now, this wasn't completely correct. The one big thing we changed significantly was the treatment of ossia. Are we really in the position to say that no such case will be found in the next few years? Even if so, can we exclude the possibility that changes to one of the more distant modules eventually result in changes to this core? > > So instead of defining and standardizing one core set of MEI, I'm in favor of specifying multiple profiles, each for a specific task. Read the word profile as nothing more than a best practice recommendation when you want to interchange with other applications operating in the same area. Actually, the reason for the little amount of code sharing between our projects is the fact that we all operate on different profiles already. > > I'm very much in favor of providing better / more stable "interfaces" for developers. However, I think it is important to clearly communicate the fact that MEI is more than just a well-defined format for common use cases ? it is a framework that offers a whole realm of encoding options, which need to be selected and specified in order to distill an actually usable format. My point is that by providing a whole set of standards (notice the small s) based on / derived from the MEI framework, it seems more likely that we as the scholarly community keep control over MEI as a whole. We need to find the right tradeoff between widest possible dissemination (also in the commercial world) and continued applicability for our scholarly needs. No one ever said that this would be easy? (but isn't the fact that we're facing this problem already an indication of success?) > > Best, > Johannes > > > > > > > > > Am 19.08.2013 um 23:28 schrieb David Meredith: > > > Some thoughts in response to Andrew's wise words. > > > > 1. I don't see why customizability and standardization are mutually exclusive. I would say that there need to be standardized ways of customizing the language and some relatively stable core subset of the language to allow for interchange and interoperability. > > > > 2. I agree that MEI should be developed independently of any particular software clients. However, I think (at least a part of) it should be standardized and stable enough to allow for large-scale information interchange and interoperability, so that A's software can read (at least some core subset of) all those encodings that B has worked so hard to produce; and so that B can use A's software to process his encodings. Writing converters to and from MEI helps, but if I have to convert that rich MEI file into some lesser format like MusicXML, kern or MIDI before I can use it, then I lose much of the value of having the information in MEI in the first place. We need powerful software the fully supports MEI and this requires MEI to have a certain guaranteed level of definition and stability. > > > > 3. MEI is an XML language. This means it is an information storage and interchange format, not a data-structure. Any reasonably complex piece of application software will read in an MEI file and then represent it internally in some data structure designed specifically for the purpose in hand, that may well bear little resemblance to how the information was stored in the original MEI file. The important thing is that MEI is powerful enough to represent/encode all the information and knowledge about a musical object that users need (or may need). I believe MEI is unique in that it has been developed by people who are extremely knowledgeable about and sensitive to the semantics of music notation of a wide variety of types. This means that it is capable of encoding/representing knowledge and information about music notation that no other format/language can. > > > > 4. I don't think anyone can reasonably disagree with the claim that MEI has (relatively) little software support. So far, we have a small number of groups heroically developing software for their own purposes and (relatively) only modest re-use even between these groups. Compared to, say, MIDI, for example, or even, (dare I say it) MusicXML, MEI has relatively little software support. I believe that if a core subset of the MEI specification were managed as a well-recognized stable standard, then it would attract much more interest from software developers. That said, I strongly agree that the definition and development of MEI should remain firmly in the hands of the academics who use it and NOT be transferred to any commercial enterprises. > > > > 5. Of course, the maintenance and development of MEI does not have to be done by means of an official standardization route such as a W3C Recommendation. However, if MEI does not achieve the status of at least a fairly high-profile *de facto* standard, then I'm concerned that it will never achieve the wide-spread use that I believe it deserves. > > > > Incidentally, there do not currently seem to be any W3C working groups or acknowledged member submissions on music notation. Shouldn't we see this as an opportunity for establishing MEI as the standard for representing music notation (of all types) on the web? > > > > Cheers, > > Dave > > > > > > > > From: Andrew Hankinson > > Reply-To: Music Encoding Initiative > > Date: Monday, 19 August 2013 21:51 > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Standards (was: File extensions) > > > >> I'm just full of opinions today? :) > >> > >> I don't see MEI as a file format. To be a little pedantic, but hopefully make a point: XML is a file format; MEI is a method of arranging objects so that they convey some sort of musical sense. What form that musical sense takes is dependent on what you want to express. What MEI brings to the table that sets it apart from all other encoding systems is a way of doing custom things easily without needing to re-define the parts that you don't care about. In that sense, it's more like a SDK or API than it is to a file format. > >> > >> MEI has always had the "Cart before the Horse" model with respect to developing the encoding independent of any software implementations. I know this was done on purpose, and I think it's because once a software client is involved in the creation of the specification, the implemented features tend to dictate the method of encoding. (Perry can stop me from putting words in his mouth if that's not the case). > >> > >> So I don't agree with Dave's assessment about the lack of interest in developing software support. In fact, I think you would find that there is a lot of interest in developing software for it -- it's just that the software that gets built is for a specific project or purpose, since what we expect from MEI differs from project to project. I came to MEI because it offered a method of encoding OMR; others are using it for digital edition work; some are using it for encoding "close readings" of musical texts, still others are using it for high-level metadata work. This can't all be supported by one client. > >> > >> When I hear that there is "no software support," I think what is meant is that there is no graphical editor that can produce an MEI-encoded file. In that sense, yes, that is somewhat correct. There are other emerging options here, though. The Sibelius MEI plugin is speeding along, thanks to some work by Richard Freedman and his students. The musicxml2mei XSLT is actively developed and constantly enhanced. Craig Sapp's amazing work on transforming other formats to and from MEI has brought MEI to both the KernScores and the Josquin project. Even the MeiSe project gave us some usable graphical software. > >> > >> So while Sibelius, Finale, and MuseScore don't support MEI, the purpose and use of these software packages is often orthogonal to how MEI is actually being used and the software that is actually being developed. I think any attempt at standardization or more rigid specification needs to understand that this is a fundamental feature of MEI, and not a bug that needs to be fixed by stricter definitions. > >> > >> To answer Johannes: There are three "trees" in mime type registration: Standards, Vendor ('vnd.'), and Personal ('prs.'), (otherwise known of as "Vanity.") You can see the mime type registration form here: http://www.iana.org/cgi-bin/mediatypes.pl. > >> > >> The Standards tree is reserved for use by Standards Organizations (W3C, IEEE, ISO, ANSI, etc.) and ownership and control of the mime type is the standards organization, NOT the community that produced the spec. (See: http://tools.ietf.org/html/rfc6838#section-3.1) > >> > >> On the other hand, RFC 6838 says this about Vendor registration: > >> > >> "The vendor tree is used for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly in this context and are considered equivalent. Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree. > >> > >> A registration may be placed in the vendor tree by anyone who needs to interchange files associated with some product or set of products. However, the registration properly belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party in order to correct or update it." > >> > >> http://tools.ietf.org/html/rfc6838#page-6 > >> > >> The third track, Personal, is basically for experimental or internal interchange. It's almost certainly not what we want. > >> > >> So basically, if you want to register a mime type and have it recognized but still retain the freedom to change and modify it without needing to go through a standards body you should go with the Vendor tree. > >> > >> -Andrew > >> > >> On 2013-08-19, at 3:45 PM, Raffaele Viglianti > >> wrote: > >> > >>> I'm not participating in the strategy committee, though I worry about establishing MEI as a W3C working group if that also requires us to come up with a stricter standard that, while keeping the same MEI, it would limit its combinations. > >>> > >>> I'm echoing Johannes' worries of a subset becoming more important than other, perhaps less popular, MEI forms. > >>> > >>> I like very much what Andrew said about MEI: it's a method. I'd say that it's an application of text encoding methods to music. As such, it is not just a file format. > >>> > >>> Application support is important: but flexibility is required to apply text encoding methods and support innovative research. An alternative to boxing MEI within an official standard body is to invest more on the formalization of MEI customization and use, namely ODD. This means a) educating the community to using ODD for describing with both words and elements how they're using MEI; b) creating ODD-parsing applications that can, for example, act as middleware between a project-tailored MEI and a generic MEI application. > >>> > >>> Raf > >>> > >>> > >>> On Mon, Aug 19, 2013 at 7:26 AM, David Meredith wrote: > >>>> Hi all, > >>>> > >>>> Tomorrow, the "strategy" committee is having its first virtual meeting to > >>>> discuss possible ways in which MEI can be managed in the future. > >>>> > >>>> I will be (tentatively) suggesting that we think about managing it as a > >>>> W3C working group. And I have in my diary to prepare a short presentation > >>>> this afternoon about this. (Sychronicity? :) ) > >>>> > >>>> My view is that MEI's volatile and diffuse definition and development is > >>>> *THE* main reason why there has so far been so little interest in > >>>> developing software to support it. Before developing software to support a > >>>> particular file format (let's face it, that's basically what MEI is), a > >>>> software developer needs > >>>> > >>>> 1. a clear definition of what the format is; > >>>> 2. reasonable confidence that his/her software isn't going to become > >>>> obsolete the next time the format's definition is revised; and > >>>> 3. a good idea of how often the format's definition is going to be > >>>> changed, so that they can plan new versions of the software that supports > >>>> it. > >>>> > >>>> These can best be achieved by establishing MEI as a *standard*, with a > >>>> properly published and managed definition and properly established > >>>> processes for developing this definition to accommodate users' changing > >>>> needs while keeping volatility and backwards incompatibility to a minimum > >>>> so that developers aren't scared off. > >>>> > >>>> I'm not completely sure that the W3C route is necessarily the best one, > >>>> but clearly we want some form of standardisation framework that is: > >>>> > >>>> 1. relatively low-ceremony: we're all volunteers, so we don't have oceans > >>>> of time and money to spend on keeping MEI alive; > >>>> 2. well-recognized and international so that we maximise the likelihood of > >>>> people wanting to develop software to support MEI. > >>>> > >>>> If anyone else has experience with this kind of process and would like to > >>>> contribute to tomorrow's meeting, please talk to Benjamin about it. > >>>> > >>>> I agree with Johannes that decisions about the definition and development > >>>> of MEI should remain independent of commercial enterprises. MEI should be > >>>> run by and for the academic community. However, I don't see how clarifying > >>>> and stabilizing the definition and development of MEI would be in any > >>>> sense detrimental. > >>>> > >>>> Cheers, > >>>> Dave > >>>> > >>>> > >>>> On 19/08/2013 12:40, "Johannes Kepper" wrote: > >>>> > >>>> >two cents from someone who's completely in the dark? > >>>> > > >>>> >I don't like the "vendor" term: To my (non-native english) ears, it > >>>> >sounds a little bit too commercial. It may or may not fit for MusicXML, > >>>> >but it doesn't seem to fit for us. If there are other tracks, we should > >>>> >follow them instead. > >>>> > > >>>> >If (S|s)tandard in the mimetype sense means something completely > >>>> >determined, it's not appropriate for us. We shouldn't restrict our future > >>>> >development by stocking ourselves to one specific version of MEI which > >>>> >may not be changed easily anymore. I wouldn't even do this for a defined > >>>> >subset of MEI (like cmn), as it has the potential to cannibalize the > >>>> >community, weakening support for other, more obscure parts of MEI. > >>>> >However, if (S|s)tandard is meant to be more open, I'm fine with this. > >>>> >For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one > >>>> >mimetype? If so, it seems comparable to our situation. > >>>> > > >>>> > > >>>> >best, > >>>> >jo > >>>> > > >>>> > > >>>> > > >>>> > > >>>> >Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg : > >>>> > > >>>> >> Sorry for using the word standard. > >>>> >> > >>>> >> Suppose it is better to describe our business as we are dealers in > >>>> >>methodologies for the description of what is known about pieces of > >>>> >>symbolic music. > >>>> >> > >>>> >> As a long term subscriber to the xml-dev list I'm used to worms, which > >>>> >>doesn't mean that I like them, or even eat them. > >>>> >> > >>>> >> Sigfrid > >>>> >> > >>>> >> ________________________________________ > >>>> >> Fra: mei-l-bounces at lists.uni-paderborn.de > >>>> >>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson > >>>> >>[andrew.hankinson at mail.mcgill.ca] > >>>> >> Sendt: 19. august 2013 11:51 > >>>> >> Til: Music Encoding Initiative > >>>> >> Emne: Re: [MEI-L] Standards (was: File extensions) > >>>> >> > >>>> >> Oof. That's a can of worms. > >>>> >> > >>>> >> Warning: Lots of opinions to follow. > >>>> >> > >>>> >> If you're creating physical widgets where part A needs to fit with part > >>>> >>B, big-S Standards can be a great thing. > >>>> >> > >>>> >> For a small and loosely-bound community like MEI, a Standard wouldn't > >>>> >>really bring much to the table, and, I think, would actually cause more > >>>> >>harm than good. What do we standardize? The complete ODD file, including > >>>> >>the parts of the ODD file that are mutually exclusive? (see: integration > >>>> >>of both mensural and CMN timing modules?) The CMN customization? Any > >>>> >>decision to standardize something will likely exclude a significant part > >>>> >>of the community. We can't even come to a consensus about which file > >>>> >>extension to use! > >>>> >> > >>>> >> What MEI brings to the world isn't actually an XML schema. I like to > >>>> >>think that you can express MEI in any formalized structure. XML brings > >>>> >>the ability to validate and impose constraints, but if XML was to be > >>>> >>eclipsed by another structural language (like SGML was eclipsed by XML?) > >>>> >>then I think that the intellectual structure of MEI could simply be > >>>> >>transplanted to the new system. > >>>> >> > >>>> >> So, in a roundabout answer to your question: No, I don't think we're > >>>> >>creating a Standard. I think we're creating a method, and I think with > >>>> >>time and usage certain parts of this method may emerge to a de-facto > >>>> >>standard, or even, yes, a Standard. But MEI as a whole? I don't think we > >>>> >>should even think of trying to register this as a Standard. There's just > >>>> >>too many moving parts. > >>>> >> > >>>> >> A vendor-specific mime type seems to be the most flexible method. In my > >>>> >>reading about mime type registration, the "x-" prefix was used for > >>>> >>experimental or non-standard use. Since RFC6648, however, this has been > >>>> >>deprecated. Current best practice, as far as I can tell, says that > >>>> >>non-standards-track mime types should be registered under the > >>>> >>vendor-specific or personal (vanity) track. I would be happy to be > >>>> >>corrected, though -- I'm new at this! > >>>> >> > >>>> >> So, application/vnd.mei+xml, or application/vnd.mei+json, or > >>>> >>application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle > >>>> >>[1] --- all of these are possibilities, but trying to go through the > >>>> >>Standardization process for them seems like a lot of work for little, > >>>> >>no, or even negative gain. > >>>> >> > >>>> >> -Andrew > >>>> >> > >>>> >> [1] http://www.candlescript.org/doc/candle-markup-reference.htm > >>>> >> > >>>> >> On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: > >>>> >> > >>>> >>> I know that, but why do you want it to register it as a vendor > >>>> >>>specific format. > >>>> >>> > >>>> >>> We're creating a standard, arn't we? > >>>> >>> > >>>> >>> Sigge > >>>> >>> ________________________________________ > >>>> >>> Fra: mei-l-bounces at lists.uni-paderborn.de > >>>> >>>[mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew > >>>> >>>Hankinson [andrew.hankinson at mail.mcgill.ca] > >>>> >>> Sendt: 16. august 2013 23:53 > >>>> >>> Til: Music Encoding Initiative > >>>> >>> Emne: Re: [MEI-L] File extensions > >>>> >>> > >>>> >>> Not quite orthogonal. A web server will serve files with the specified > >>>> >>>extension as a given mime-type. It's true that you can write the mime > >>>> >>>type to the header if you're in a web application environment, but by > >>>> >>>registering a mime type we can provide a method for placing MEI files > >>>> >>>on a server, and it opening in a default application on the users' > >>>> >>>machine, for example. > >>>> >>> > >>>> >>> This can be especially useful in a mobile environment, where sometimes > >>>> >>>you have limited control over which application will open a downloaded > >>>> >>>file. > >>>> >>> > >>>> >>> So, in a web context the extension does matter, since (by default) the > >>>> >>>web server will serve files with a given extension with a certain mime > >>>> >>>type. That's the second part of the mime type definition for servers: > >>>> >>>"application/vnd.mei+xml .mei" maps all .mei files to the > >>>> >>>application/vnd.mei+xml mime type. > >>>> >>> > >>>> >>> Using .xml is fine if you want to open it in an XML editor. However, > >>>> >>>if we want to open it in a notation editor (dreaming of the future) > >>>> >>>then it's best if we choose .mei now, and then allow the user to > >>>> >>>specify the application that handles it as needed. > >>>> >>> > >>>> >>> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I > >>>> >>>understand, appending vnd. makes the mime type registration process > >>>> >>>much easier, since it doesn't need to go through the standards bodies > >>>> >>>to be approved. The MusicXML mime type uses the vnd. prefix, something > >>>> >>>like "application/vnd.recordare-musicxml+xml" So I thought that we > >>>> >>>might go for the easy registration first. It doesn't preclude later > >>>> >>>registration of a more formal mimetype. But here I will defer to those > >>>> >>>with more experience in the process. > >>>> >>> > >>>> >>> -Andrew > >>>> >>> > >>>> >>> > >>>> >>> On 2013-08-15, at 6:27 PM, Raffaele Viglianti > >>>> >>>> wrote: > >>>> >>> > >>>> >>> > >>>> >>> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson > >>>> >>> > >>>> >>>> wrote: > >>>> >>> > >>>> >>> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type > >>>> >>>seems like a big problem. > >>>> >>> > >>>> >>> application/vnd.mei+xml .mei -> Seems like the best solution, yes? > >>>> >>> > >>>> >>> As far as I know mimetype is orthogonal to file extension, so even if > >>>> >>>we secure a mimetype application/mei+xml it won't matter if your file > >>>> >>>has .xml or .mei extension. > >>>> >>> > >>>> >>> I personally don't see an issue with file extension at all. What's the > >>>> >>>problem with using either .mei or .xml? In a web context all that > >>>> >>>matters is the mimetype, in a OS context, using .xml is generally going > >>>> >>>to make things easier, but it's not eventually not a big deal. > >>>> >>> > >>>> >>> Raf > >>>> >>> > >>>> >>> > >>>> >>> (the MEI mime type I give is just an example). > >>>> >>> > >>>> >>> -Andrew > >>>> >>> > >>>> >>> > >>>> >>> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg > >>>> >>>> > >>>> >>> wrote: > >>>> >>> > >>>> >>>> .txt is a poor choice. Most web servers will deliver that as > >>>> >>>>text/plain which is not what you want. In apache web server there is a > >>>> >>>>file mime-types which connects extensions to mime types, which then > >>>> >>>>interacts with users web clients and plug-ins and helper applications > >>>> >>>> > >>>> >>>> Sigfrid > >>>> >>>> ________________________________________ > >>>> >>>> Fra: > >>>> >>>>mei-l-bounces at lists.uni-paderborn.de >>>> >>>>erborn.de> > >>>> >>>>[mei-l-bounces at lists.uni-paderborn.de >>>> >>>>derborn.de>] på vegne af Andrew Hankinson > >>>> >>>>[andrew.hankinson at mail.mcgill.ca >>>> >>>>>] > >>>> >>>> Sendt: 15. august 2013 17:23 > >>>> >>>> Til: Music Encoding Initiative > >>>> >>>> Emne: Re: [MEI-L] File extensions > >>>> >>>> > >>>> >>>> You can sign me up too. > >>>> >>>> > >>>> >>>> Personally, I like .mei. XML could also be thought of as plain text, > >>>> >>>>so I would argue that we should go with the most specific usage, > >>>> >>>>rather than the most general. We could just go with .txt and be just > >>>> >>>>as correct as .xml. > >>>> >>>> > >>>> >>>> Either way, though, I think this is an appropriate topic for putting > >>>> >>>>some guidance in the Guidelines. I'll volunteer to write it, but I > >>>> >>>>would like some way of getting a consensus. > >>>> >>>> > >>>> >>>> Any ideas? An online poll? > >>>> >>>> > >>>> >>>> -Andrew > >>>> >>>> > >>>> >>>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" > >>>> >>>>> > >>>> >>>> wrote: > >>>> >>>> > >>>> >>>>> > >>>> >>>>> Sigge, > >>>> >>>>> > >>>> >>>>> Thanks for being so gracious in your acceptance of my effort to > >>>> >>>>>"volunteer" you. > >>>> >>>>> > >>>> >>>>> There's no rush on this. After Christmas/beginning of 2014 is fine. > >>>> >>>>> I'm sure you'll find willing volunteers to help you write the > >>>> >>>>>proposal. You can "volunteer" me in return. :-) > >>>> >>>>> > >>>> >>>>> Anyone who wants to participate, please contact Sigge. I hear he's > >>>> >>>>>starting a list. :-) > >>>> >>>>> > >>>> >>>>> Thanks again, > >>>> >>>>> > >>>> >>>>> -- > >>>> >>>>> 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 >>>> >>>>>a.edu at lists.uni-paderborn.de> > >>>> >>>>>[mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de >>>> >>>>>ia.edu at lists.uni-paderborn.de>] on behalf of Sigfrid Lundberg > >>>> >>>>>[slu at kb.dk] > >>>> >>>>> Sent: Thursday, August 15, 2013 10:49 AM > >>>> >>>>> To: Music Encoding Initiative > >>>> >>>>> Subject: Re: [MEI-L] File extensions > >>>> >>>>> > >>>> >>>>> My keyboard is too fast. > >>>> >>>>> > >>>> >>>>> Cannot promise to write it alone and have to discuss it here in > >>>> >>>>>Copenhagen. Not before Christmas, that's for sure > >>>> >>>>> > >>>> >>>>> S > >>>> >>>>> ________________________________________ > >>>> >>>>> Fra: > >>>> >>>>>mei-l-bounces at lists.uni-paderborn.de >>>> >>>>>derborn.de> > >>>> >>>>>[mei-l-bounces at lists.uni-paderborn.de >>>> >>>>>aderborn.de>] på vegne af Roland, Perry (pdr4h) > >>>> >>>>>[pdr4h at eservices.virginia.edu] > >>>> >>>>> Sendt: 15. august 2013 16:44 > >>>> >>>>> Til: Music Encoding Initiative > >>>> >>>>> Emne: Re: [MEI-L] File extensions > >>>> >>>>> > >>>> >>>>> Hi Sigfrid, > >>>> >>>>> > >>>> >>>>> Sounds like we have a volunteer to lead the way to registering an > >>>> >>>>>MEI mimetype. :-) > >>>> >>>>> > >>>> >>>>> -- > >>>> >>>>> 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 >>>> >>>>>derborn.de> > >>>> >>>>>[mei-l-bounces at lists.uni-paderborn.de >>>> >>>>>aderborn.de>] on behalf of Sigfrid Lundberg > >>>> >>>>>[slu at kb.dk] > >>>> >>>>> Sent: Thursday, August 15, 2013 10:39 AM > >>>> >>>>> To: Music Encoding Initiative > >>>> >>>>> Subject: Re: [MEI-L] File extensions > >>>> >>>>> > >>>> >>>>> Hi, > >>>> >>>>> > >>>> >>>>> I'm using .xml as suffix. Don't really care. > >>>> >>>>> > >>>> >>>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I > >>>> >>>>>have strong opinions on your "by the way" question. Yes, we should > >>>> >>>>>register a mime type, and it should be application/mei+xml. Since it > >>>> >>>>>is in the application hierarchy it requires an RFC and some > >>>> >>>>>negotiations with IESG and IETF before one get a line in the > >>>> >>>>>appropriate IANA document. > >>>> >>>>> > >>>> >>>>> Cheers > >>>> >>>>> > >>>> >>>>> Sigfrid > >>>> >>>>> > >>>> >>>>> ________________________________________ > >>>> >>>>> Fra: > >>>> >>>>>mei-l-bounces at lists.uni-paderborn.de >>>> >>>>>derborn.de> > >>>> >>>>>[mei-l-bounces at lists.uni-paderborn.de >>>> >>>>>aderborn.de>] på vegne af Andrew Hankinson > >>>> >>>>>[andrew.hankinson at mail.mcgill.ca >>>> >>>>>a>] > >>>> >>>>> Sendt: 15. august 2013 16:12 > >>>> >>>>> Til: Music Encoding Initiative > >>>> >>>>> Emne: [MEI-L] File extensions > >>>> >>>>> > >>>> >>>>> Hi all, > >>>> >>>>> > >>>> >>>>> Is there a common understanding of what the proper file extension > >>>> >>>>>for MEI files should be? > >>>> >>>>> > >>>> >>>>> I've been assuming .mei is the "standard", but a counter-example of > >>>> >>>>>.xml was recently brought to my attention. So, I thought I'd poll the > >>>> >>>>>collected wisdom and see what others were doing. Are you using .xml, > >>>> >>>>>.mei, or some other variation on these? > >>>> >>>>> > >>>> >>>>> -Andrew > >>>> >>>>> > >>>> >>>>> ==== > >>>> >>>>> Related: > >>>> >>>>> -- Should we register an actual mimetype? Maybe: > >>>> >>>>>application/vnd.music-encoding+xml ? > >>>> >>>>> > >>>> >>>>> > >>>> >>>>> _______________________________________________ > >>>> >>>>> 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 > >>>> >> > >>>> >> > >>>> >> _______________________________________________ > >>>> >> 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 slu at kb.dk Tue Aug 20 10:47:21 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Tue, 20 Aug 2013 08:47:21 +0000 Subject: [MEI-L] Standards (was: File extensions) In-Reply-To: <8556B8EE-29FE-448B-8769-CC7C49962983@edirom.de> References: <5F985845-AD73-4825-BEA4-6CBB3E040A96@edirom.de>, <8556B8EE-29FE-448B-8769-CC7C49962983@edirom.de> Message-ID: <0C090608704AF04E898055296C932B129B827D94@EXCHANGE-01.kb.dk> You can almost have one for all MEI under the sun, but not all. Very old pre xml MEI (if such objects exist under the sun) wouldn't work. (Not well formed) And it could be helpful to restrict the mime type to the MEI that appeared after going camel case. Or have two. The typical use of a mime type is for software sending and receiving messages on the Internet. Such web or mail clients choosing a browser plug-in. E.g., here comes application/vnd.mei+xml (or application/mei+xml, which is still prefer), I'd better use MEI2VexFlow. And besides, I'm no longer interested in this issue. Sigfrid ________________________________________ Fra: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] på vegne af Johannes Kepper [kepper at edirom.de] Sendt: 20. august 2013 10:23 Til: Music Encoding Initiative Emne: Re: [MEI-L] Standards (was: File extensions) After an hour on the car, even more thoughts? Coming back to the question of mime types, I think we all agree that having such a thing would be good. I understand we can head for the standards track (application/mei+xml) or the vendor track (application/vnd.mei+xml). I think Andrew's arguments about keeping control are very similar to the arguments from my last mail, and if the word vendor is really so loosely defined, I'm fine with it. However, I still have one question about the standards track. When all kinds of HTML share a mimetype, can't we get a mimetype for every MEI instance under the sun? If so, would it matter if we change the format? Like HTML, we have means to specify which version one uses, so this shouldn't be a problem, right? I think the mimetype issue is almost completely independent from the question of standardizing MEI itself. Maybe I'm too anxious in this regard, but as Dave pointed out, our resources to work on MEI are not endless. As soon as commercial vendors step in the game, they're not unlikely to put more on the table than we could. I don't think they could overrule us with regard to schema development, but they could establish a de facto standard that fits their needs, but not ours. That said, I'm not at all against the involvement of commercial parties, I just say that we need to be very careful about this, and need to make sure that we don't get ourselves a Trojan Horse (even if it's not supposed to be one). So commercial support for MEI is great, but it has to be clear that MEI is more than just the cmn module, and supporting MEI almost always means supporting a certain subset of MEI. If we communicate this clearly, I'm fine. Best, Johannes Am 20.08.2013 um 08:32 schrieb Johannes Kepper : > Some more thoughts? > > > We had a proposal on a toolkit for MEI, that would have offered several profiles of MEI for specific tasks, conversions between these profiles, and other common tasks that would have facilitated usage of MEI significantly. The plan was to do this as a group, with almost all projects currently developing for MEI being involved. It appears our proposal wasn't spelled convincingly enough, so it didn't go through. However, the idea is still alive, and we're definitely looking for appropriate tracks to re-submit. > > The main difference to the idea of a core set is that we intentionally had several such core sets. It would be easy to identify just one core subset of MEI that would satisfy the needs of average music software developers. It would probably be something like the cmn module, with a reduced header and little else. Actually, not much has changed here in the last three years. However, such a subset would not satisfy the needs of almost all projects currently involved in MEI. It may or may not be appropriate for corpus analysis, but even there, I'd say it neglects the potential of other MEI modules more appropriate to the purpose. > > So yes, such a core set of MEI is likely to increase software support for MEI. But at the same time, it doesn't buy us much more than our own MusicXML equivalent within the world of MEI. We (as academics) still have to (up|down)convert our data into and out of this subset. In essence, there is little gain compared to the current situation with MusicXML and the converter we provide (please note that Perry is working on the opposite direction back into MusicXML right now). But, making such a core subset a Standard recognized by some Standards organization will effectively freeze development on everything that's inside the Standard. In my daily work, I regularly notice areas in MEI that haven't been used much ever since their invention, which may benefit from a gentle remodelling. When I said that the probable core was stable for some years now, this wasn't completely correct. The one big thing we changed significantly was the treatment of ossia. Are we really in the position to say that no such case will be found in the next few years? Even if so, can we exclude the possibility that changes to one of the more distant modules eventually result in changes to this core? > > So instead of defining and standardizing one core set of MEI, I'm in favor of specifying multiple profiles, each for a specific task. Read the word profile as nothing more than a best practice recommendation when you want to interchange with other applications operating in the same area. Actually, the reason for the little amount of code sharing between our projects is the fact that we all operate on different profiles already. > > I'm very much in favor of providing better / more stable "interfaces" for developers. However, I think it is important to clearly communicate the fact that MEI is more than just a well-defined format for common use cases ? it is a framework that offers a whole realm of encoding options, which need to be selected and specified in order to distill an actually usable format. My point is that by providing a whole set of standards (notice the small s) based on / derived from the MEI framework, it seems more likely that we as the scholarly community keep control over MEI as a whole. We need to find the right tradeoff between widest possible dissemination (also in the commercial world) and continued applicability for our scholarly needs. No one ever said that this would be easy? (but isn't the fact that we're facing this problem already an indication of success?) > > Best, > Johannes > > > > > > > > > Am 19.08.2013 um 23:28 schrieb David Meredith: > >> Some thoughts in response to Andrew's wise words. >> >> 1. I don't see why customizability and standardization are mutually exclusive. I would say that there need to be standardized ways of customizing the language and some relatively stable core subset of the language to allow for interchange and interoperability. >> >> 2. I agree that MEI should be developed independently of any particular software clients. However, I think (at least a part of) it should be standardized and stable enough to allow for large-scale information interchange and interoperability, so that A's software can read (at least some core subset of) all those encodings that B has worked so hard to produce; and so that B can use A's software to process his encodings. Writing converters to and from MEI helps, but if I have to convert that rich MEI file into some lesser format like MusicXML, kern or MIDI before I can use it, then I lose much of the value of having the information in MEI in the first place. We need powerful software the fully supports MEI and this requires MEI to have a certain guaranteed level of definition and stability. >> >> 3. MEI is an XML language. This means it is an information storage and interchange format, not a data-structure. Any reasonably complex piece of application software will read in an MEI file and then represent it internally in some data structure designed specifically for the purpose in hand, that may well bear little resemblance to how the information was stored in the original MEI file. The important thing is that MEI is powerful enough to represent/encode all the information and knowledge about a musical object that users need (or may need). I believe MEI is unique in that it has been developed by people who are extremely knowledgeable about and sensitive to the semantics of music notation of a wide variety of types. This means that it is capable of encoding/representing knowledge and information about music notation that no other format/language can. >> >> 4. I don't think anyone can reasonably disagree with the claim that MEI has (relatively) little software support. So far, we have a small number of groups heroically developing software for their own purposes and (relatively) only modest re-use even between these groups. Compared to, say, MIDI, for example, or even, (dare I say it) MusicXML, MEI has relatively little software support. I believe that if a core subset of the MEI specification were managed as a well-recognized stable standard, then it would attract much more interest from software developers. That said, I strongly agree that the definition and development of MEI should remain firmly in the hands of the academics who use it and NOT be transferred to any commercial enterprises. >> >> 5. Of course, the maintenance and development of MEI does not have to be done by means of an official standardization route such as a W3C Recommendation. However, if MEI does not achieve the status of at least a fairly high-profile *de facto* standard, then I'm concerned that it will never achieve the wide-spread use that I believe it deserves. >> >> Incidentally, there do not currently seem to be any W3C working groups or acknowledged member submissions on music notation. Shouldn't we see this as an opportunity for establishing MEI as the standard for representing music notation (of all types) on the web? >> >> Cheers, >> Dave >> >> >> >> From: Andrew Hankinson >> Reply-To: Music Encoding Initiative >> Date: Monday, 19 August 2013 21:51 >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Standards (was: File extensions) >> >>> I'm just full of opinions today? :) >>> >>> I don't see MEI as a file format. To be a little pedantic, but hopefully make a point: XML is a file format; MEI is a method of arranging objects so that they convey some sort of musical sense. What form that musical sense takes is dependent on what you want to express. What MEI brings to the table that sets it apart from all other encoding systems is a way of doing custom things easily without needing to re-define the parts that you don't care about. In that sense, it's more like a SDK or API than it is to a file format. >>> >>> MEI has always had the "Cart before the Horse" model with respect to developing the encoding independent of any software implementations. I know this was done on purpose, and I think it's because once a software client is involved in the creation of the specification, the implemented features tend to dictate the method of encoding. (Perry can stop me from putting words in his mouth if that's not the case). >>> >>> So I don't agree with Dave's assessment about the lack of interest in developing software support. In fact, I think you would find that there is a lot of interest in developing software for it -- it's just that the software that gets built is for a specific project or purpose, since what we expect from MEI differs from project to project. I came to MEI because it offered a method of encoding OMR; others are using it for digital edition work; some are using it for encoding "close readings" of musical texts, still others are using it for high-level metadata work. This can't all be supported by one client. >>> >>> When I hear that there is "no software support," I think what is meant is that there is no graphical editor that can produce an MEI-encoded file. In that sense, yes, that is somewhat correct. There are other emerging options here, though. The Sibelius MEI plugin is speeding along, thanks to some work by Richard Freedman and his students. The musicxml2mei XSLT is actively developed and constantly enhanced. Craig Sapp's amazing work on transforming other formats to and from MEI has brought MEI to both the KernScores and the Josquin project. Even the MeiSe project gave us some usable graphical software. >>> >>> So while Sibelius, Finale, and MuseScore don't support MEI, the purpose and use of these software packages is often orthogonal to how MEI is actually being used and the software that is actually being developed. I think any attempt at standardization or more rigid specification needs to understand that this is a fundamental feature of MEI, and not a bug that needs to be fixed by stricter definitions. >>> >>> To answer Johannes: There are three "trees" in mime type registration: Standards, Vendor ('vnd.'), and Personal ('prs.'), (otherwise known of as "Vanity.") You can see the mime type registration form here: http://www.iana.org/cgi-bin/mediatypes.pl. >>> >>> The Standards tree is reserved for use by Standards Organizations (W3C, IEEE, ISO, ANSI, etc.) and ownership and control of the mime type is the standards organization, NOT the community that produced the spec. (See: http://tools.ietf.org/html/rfc6838#section-3.1) >>> >>> On the other hand, RFC 6838 says this about Vendor registration: >>> >>> "The vendor tree is used for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly in this context and are considered equivalent. Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree. >>> >>> A registration may be placed in the vendor tree by anyone who needs to interchange files associated with some product or set of products. However, the registration properly belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party in order to correct or update it." >>> >>> http://tools.ietf.org/html/rfc6838#page-6 >>> >>> The third track, Personal, is basically for experimental or internal interchange. It's almost certainly not what we want. >>> >>> So basically, if you want to register a mime type and have it recognized but still retain the freedom to change and modify it without needing to go through a standards body you should go with the Vendor tree. >>> >>> -Andrew >>> >>> On 2013-08-19, at 3:45 PM, Raffaele Viglianti >>> wrote: >>> >>>> I'm not participating in the strategy committee, though I worry about establishing MEI as a W3C working group if that also requires us to come up with a stricter standard that, while keeping the same MEI, it would limit its combinations. >>>> >>>> I'm echoing Johannes' worries of a subset becoming more important than other, perhaps less popular, MEI forms. >>>> >>>> I like very much what Andrew said about MEI: it's a method. I'd say that it's an application of text encoding methods to music. As such, it is not just a file format. >>>> >>>> Application support is important: but flexibility is required to apply text encoding methods and support innovative research. An alternative to boxing MEI within an official standard body is to invest more on the formalization of MEI customization and use, namely ODD. This means a) educating the community to using ODD for describing with both words and elements how they're using MEI; b) creating ODD-parsing applications that can, for example, act as middleware between a project-tailored MEI and a generic MEI application. >>>> >>>> Raf >>>> >>>> >>>> On Mon, Aug 19, 2013 at 7:26 AM, David Meredith wrote: >>>>> Hi all, >>>>> >>>>> Tomorrow, the "strategy" committee is having its first virtual meeting to >>>>> discuss possible ways in which MEI can be managed in the future. >>>>> >>>>> I will be (tentatively) suggesting that we think about managing it as a >>>>> W3C working group. And I have in my diary to prepare a short presentation >>>>> this afternoon about this. (Sychronicity? :) ) >>>>> >>>>> My view is that MEI's volatile and diffuse definition and development is >>>>> *THE* main reason why there has so far been so little interest in >>>>> developing software to support it. Before developing software to support a >>>>> particular file format (let's face it, that's basically what MEI is), a >>>>> software developer needs >>>>> >>>>> 1. a clear definition of what the format is; >>>>> 2. reasonable confidence that his/her software isn't going to become >>>>> obsolete the next time the format's definition is revised; and >>>>> 3. a good idea of how often the format's definition is going to be >>>>> changed, so that they can plan new versions of the software that supports >>>>> it. >>>>> >>>>> These can best be achieved by establishing MEI as a *standard*, with a >>>>> properly published and managed definition and properly established >>>>> processes for developing this definition to accommodate users' changing >>>>> needs while keeping volatility and backwards incompatibility to a minimum >>>>> so that developers aren't scared off. >>>>> >>>>> I'm not completely sure that the W3C route is necessarily the best one, >>>>> but clearly we want some form of standardisation framework that is: >>>>> >>>>> 1. relatively low-ceremony: we're all volunteers, so we don't have oceans >>>>> of time and money to spend on keeping MEI alive; >>>>> 2. well-recognized and international so that we maximise the likelihood of >>>>> people wanting to develop software to support MEI. >>>>> >>>>> If anyone else has experience with this kind of process and would like to >>>>> contribute to tomorrow's meeting, please talk to Benjamin about it. >>>>> >>>>> I agree with Johannes that decisions about the definition and development >>>>> of MEI should remain independent of commercial enterprises. MEI should be >>>>> run by and for the academic community. However, I don't see how clarifying >>>>> and stabilizing the definition and development of MEI would be in any >>>>> sense detrimental. >>>>> >>>>> Cheers, >>>>> Dave >>>>> >>>>> >>>>> On 19/08/2013 12:40, "Johannes Kepper" wrote: >>>>> >>>>>> two cents from someone who's completely in the dark? >>>>>> >>>>>> I don't like the "vendor" term: To my (non-native english) ears, it >>>>>> sounds a little bit too commercial. It may or may not fit for MusicXML, >>>>>> but it doesn't seem to fit for us. If there are other tracks, we should >>>>>> follow them instead. >>>>>> >>>>>> If (S|s)tandard in the mimetype sense means something completely >>>>>> determined, it's not appropriate for us. We shouldn't restrict our future >>>>>> development by stocking ourselves to one specific version of MEI which >>>>>> may not be changed easily anymore. I wouldn't even do this for a defined >>>>>> subset of MEI (like cmn), as it has the potential to cannibalize the >>>>>> community, weakening support for other, more obscure parts of MEI. >>>>>> However, if (S|s)tandard is meant to be more open, I'm fine with this. >>>>>> For instance, do HTML3.2, 4.01 (transitional and strict) and 5 share one >>>>>> mimetype? If so, it seems comparable to our situation. >>>>>> >>>>>> >>>>>> best, >>>>>> jo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Am 19.08.2013 um 12:28 schrieb Sigfrid Lundberg : >>>>>> >>>>>>> Sorry for using the word standard. >>>>>>> >>>>>>> Suppose it is better to describe our business as we are dealers in >>>>>>> methodologies for the description of what is known about pieces of >>>>>>> symbolic music. >>>>>>> >>>>>>> As a long term subscriber to the xml-dev list I'm used to worms, which >>>>>>> doesn't mean that I like them, or even eat them. >>>>>>> >>>>>>> Sigfrid >>>>>>> >>>>>>> ________________________________________ >>>>>>> Fra: mei-l-bounces at lists.uni-paderborn.de >>>>>>> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson >>>>>>> [andrew.hankinson at mail.mcgill.ca] >>>>>>> Sendt: 19. august 2013 11:51 >>>>>>> Til: Music Encoding Initiative >>>>>>> Emne: Re: [MEI-L] Standards (was: File extensions) >>>>>>> >>>>>>> Oof. That's a can of worms. >>>>>>> >>>>>>> Warning: Lots of opinions to follow. >>>>>>> >>>>>>> If you're creating physical widgets where part A needs to fit with part >>>>>>> B, big-S Standards can be a great thing. >>>>>>> >>>>>>> For a small and loosely-bound community like MEI, a Standard wouldn't >>>>>>> really bring much to the table, and, I think, would actually cause more >>>>>>> harm than good. What do we standardize? The complete ODD file, including >>>>>>> the parts of the ODD file that are mutually exclusive? (see: integration >>>>>>> of both mensural and CMN timing modules?) The CMN customization? Any >>>>>>> decision to standardize something will likely exclude a significant part >>>>>>> of the community. We can't even come to a consensus about which file >>>>>>> extension to use! >>>>>>> >>>>>>> What MEI brings to the world isn't actually an XML schema. I like to >>>>>>> think that you can express MEI in any formalized structure. XML brings >>>>>>> the ability to validate and impose constraints, but if XML was to be >>>>>>> eclipsed by another structural language (like SGML was eclipsed by XML?) >>>>>>> then I think that the intellectual structure of MEI could simply be >>>>>>> transplanted to the new system. >>>>>>> >>>>>>> So, in a roundabout answer to your question: No, I don't think we're >>>>>>> creating a Standard. I think we're creating a method, and I think with >>>>>>> time and usage certain parts of this method may emerge to a de-facto >>>>>>> standard, or even, yes, a Standard. But MEI as a whole? I don't think we >>>>>>> should even think of trying to register this as a Standard. There's just >>>>>>> too many moving parts. >>>>>>> >>>>>>> A vendor-specific mime type seems to be the most flexible method. In my >>>>>>> reading about mime type registration, the "x-" prefix was used for >>>>>>> experimental or non-standard use. Since RFC6648, however, this has been >>>>>>> deprecated. Current best practice, as far as I can tell, says that >>>>>>> non-standards-track mime types should be registered under the >>>>>>> vendor-specific or personal (vanity) track. I would be happy to be >>>>>>> corrected, though -- I'm new at this! >>>>>>> >>>>>>> So, application/vnd.mei+xml, or application/vnd.mei+json, or >>>>>>> application/vnd.mei-common+yaml, or application/vnd.mei-mensural+candle >>>>>>> [1] --- all of these are possibilities, but trying to go through the >>>>>>> Standardization process for them seems like a lot of work for little, >>>>>>> no, or even negative gain. >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> [1] http://www.candlescript.org/doc/candle-markup-reference.htm >>>>>>> >>>>>>> On 2013-08-19, at 9:18 AM, Sigfrid Lundberg wrote: >>>>>>> >>>>>>>> I know that, but why do you want it to register it as a vendor >>>>>>>> specific format. >>>>>>>> >>>>>>>> We're creating a standard, arn't we? >>>>>>>> >>>>>>>> Sigge >>>>>>>> ________________________________________ >>>>>>>> Fra: mei-l-bounces at lists.uni-paderborn.de >>>>>>>> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew >>>>>>>> Hankinson [andrew.hankinson at mail.mcgill.ca] >>>>>>>> Sendt: 16. august 2013 23:53 >>>>>>>> Til: Music Encoding Initiative >>>>>>>> Emne: Re: [MEI-L] File extensions >>>>>>>> >>>>>>>> Not quite orthogonal. A web server will serve files with the specified >>>>>>>> extension as a given mime-type. It's true that you can write the mime >>>>>>>> type to the header if you're in a web application environment, but by >>>>>>>> registering a mime type we can provide a method for placing MEI files >>>>>>>> on a server, and it opening in a default application on the users' >>>>>>>> machine, for example. >>>>>>>> >>>>>>>> This can be especially useful in a mobile environment, where sometimes >>>>>>>> you have limited control over which application will open a downloaded >>>>>>>> file. >>>>>>>> >>>>>>>> So, in a web context the extension does matter, since (by default) the >>>>>>>> web server will serve files with a given extension with a certain mime >>>>>>>> type. That's the second part of the mime type definition for servers: >>>>>>>> "application/vnd.mei+xml .mei" maps all .mei files to the >>>>>>>> application/vnd.mei+xml mime type. >>>>>>>> >>>>>>>> Using .xml is fine if you want to open it in an XML editor. However, >>>>>>>> if we want to open it in a notation editor (dreaming of the future) >>>>>>>> then it's best if we choose .mei now, and then allow the user to >>>>>>>> specify the application that handles it as needed. >>>>>>>> >>>>>>>> To answer Sigfrid: vnd. is the Vendor-specific mime type. As far as I >>>>>>>> understand, appending vnd. makes the mime type registration process >>>>>>>> much easier, since it doesn't need to go through the standards bodies >>>>>>>> to be approved. The MusicXML mime type uses the vnd. prefix, something >>>>>>>> like "application/vnd.recordare-musicxml+xml" So I thought that we >>>>>>>> might go for the easy registration first. It doesn't preclude later >>>>>>>> registration of a more formal mimetype. But here I will defer to those >>>>>>>> with more experience in the process. >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> >>>>>>>> On 2013-08-15, at 6:27 PM, Raffaele Viglianti >>>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Aug 15, 2013 at 12:02 PM, Andrew Hankinson >>>>>>>> >>>>>>>>> wrote: >>>>>>>> >>>>>>>> application/vnd.mei+xml .xml -> Mapping .xml to the MEI mime type >>>>>>>> seems like a big problem. >>>>>>>> >>>>>>>> application/vnd.mei+xml .mei -> Seems like the best solution, yes? >>>>>>>> >>>>>>>> As far as I know mimetype is orthogonal to file extension, so even if >>>>>>>> we secure a mimetype application/mei+xml it won't matter if your file >>>>>>>> has .xml or .mei extension. >>>>>>>> >>>>>>>> I personally don't see an issue with file extension at all. What's the >>>>>>>> problem with using either .mei or .xml? In a web context all that >>>>>>>> matters is the mimetype, in a OS context, using .xml is generally going >>>>>>>> to make things easier, but it's not eventually not a big deal. >>>>>>>> >>>>>>>> Raf >>>>>>>> >>>>>>>> >>>>>>>> (the MEI mime type I give is just an example). >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> >>>>>>>> On 2013-08-15, at 5:47 PM, Sigfrid Lundberg >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>>> .txt is a poor choice. Most web servers will deliver that as >>>>>>>>> text/plain which is not what you want. In apache web server there is a >>>>>>>>> file mime-types which connects extensions to mime types, which then >>>>>>>>> interacts with users web clients and plug-ins and helper applications >>>>>>>>> >>>>>>>>> Sigfrid >>>>>>>>> ________________________________________ >>>>>>>>> Fra: >>>>>>>>> mei-l-bounces at lists.uni-paderborn.de>>>>>>>> erborn.de> >>>>>>>>> [mei-l-bounces at lists.uni-paderborn.de>>>>>>>> derborn.de>] på vegne af Andrew Hankinson >>>>>>>>> [andrew.hankinson at mail.mcgill.ca>>>>>>>>> ] >>>>>>>>> Sendt: 15. august 2013 17:23 >>>>>>>>> Til: Music Encoding Initiative >>>>>>>>> Emne: Re: [MEI-L] File extensions >>>>>>>>> >>>>>>>>> You can sign me up too. >>>>>>>>> >>>>>>>>> Personally, I like .mei. XML could also be thought of as plain text, >>>>>>>>> so I would argue that we should go with the most specific usage, >>>>>>>>> rather than the most general. We could just go with .txt and be just >>>>>>>>> as correct as .xml. >>>>>>>>> >>>>>>>>> Either way, though, I think this is an appropriate topic for putting >>>>>>>>> some guidance in the Guidelines. I'll volunteer to write it, but I >>>>>>>>> would like some way of getting a consensus. >>>>>>>>> >>>>>>>>> Any ideas? An online poll? >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> On 2013-08-15, at 5:09 PM, "Roland, Perry (pdr4h)" >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sigge, >>>>>>>>>> >>>>>>>>>> Thanks for being so gracious in your acceptance of my effort to >>>>>>>>>> "volunteer" you. >>>>>>>>>> >>>>>>>>>> There's no rush on this. After Christmas/beginning of 2014 is fine. >>>>>>>>>> I'm sure you'll find willing volunteers to help you write the >>>>>>>>>> proposal. You can "volunteer" me in return. :-) >>>>>>>>>> >>>>>>>>>> Anyone who wants to participate, please contact Sigge. I hear he's >>>>>>>>>> starting a list. :-) >>>>>>>>>> >>>>>>>>>> Thanks again, >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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>>>>>>>>> a.edu at lists.uni-paderborn.de> >>>>>>>>>> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de>>>>>>>>> ia.edu at lists.uni-paderborn.de>] on behalf of Sigfrid Lundberg >>>>>>>>>> [slu at kb.dk] >>>>>>>>>> Sent: Thursday, August 15, 2013 10:49 AM >>>>>>>>>> To: Music Encoding Initiative >>>>>>>>>> Subject: Re: [MEI-L] File extensions >>>>>>>>>> >>>>>>>>>> My keyboard is too fast. >>>>>>>>>> >>>>>>>>>> Cannot promise to write it alone and have to discuss it here in >>>>>>>>>> Copenhagen. Not before Christmas, that's for sure >>>>>>>>>> >>>>>>>>>> S >>>>>>>>>> ________________________________________ >>>>>>>>>> Fra: >>>>>>>>>> mei-l-bounces at lists.uni-paderborn.de>>>>>>>>> derborn.de> >>>>>>>>>> [mei-l-bounces at lists.uni-paderborn.de>>>>>>>>> aderborn.de>] på vegne af Roland, Perry (pdr4h) >>>>>>>>>> [pdr4h at eservices.virginia.edu] >>>>>>>>>> Sendt: 15. august 2013 16:44 >>>>>>>>>> Til: Music Encoding Initiative >>>>>>>>>> Emne: Re: [MEI-L] File extensions >>>>>>>>>> >>>>>>>>>> Hi Sigfrid, >>>>>>>>>> >>>>>>>>>> Sounds like we have a volunteer to lead the way to registering an >>>>>>>>>> MEI mimetype. :-) >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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>>>>>>>>> derborn.de> >>>>>>>>>> [mei-l-bounces at lists.uni-paderborn.de>>>>>>>>> aderborn.de>] on behalf of Sigfrid Lundberg >>>>>>>>>> [slu at kb.dk] >>>>>>>>>> Sent: Thursday, August 15, 2013 10:39 AM >>>>>>>>>> To: Music Encoding Initiative >>>>>>>>>> Subject: Re: [MEI-L] File extensions >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I'm using .xml as suffix. Don't really care. >>>>>>>>>> >>>>>>>>>> As I'm a coauthor of RFC6129 (http://tools.ietf.org/html/rfc6129) I >>>>>>>>>> have strong opinions on your "by the way" question. Yes, we should >>>>>>>>>> register a mime type, and it should be application/mei+xml. Since it >>>>>>>>>> is in the application hierarchy it requires an RFC and some >>>>>>>>>> negotiations with IESG and IETF before one get a line in the >>>>>>>>>> appropriate IANA document. >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> >>>>>>>>>> Sigfrid >>>>>>>>>> >>>>>>>>>> ________________________________________ >>>>>>>>>> Fra: >>>>>>>>>> mei-l-bounces at lists.uni-paderborn.de>>>>>>>>> derborn.de> >>>>>>>>>> [mei-l-bounces at lists.uni-paderborn.de>>>>>>>>> aderborn.de>] på vegne af Andrew Hankinson >>>>>>>>>> [andrew.hankinson at mail.mcgill.ca>>>>>>>>> a>] >>>>>>>>>> Sendt: 15. august 2013 16:12 >>>>>>>>>> Til: Music Encoding Initiative >>>>>>>>>> Emne: [MEI-L] File extensions >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Is there a common understanding of what the proper file extension >>>>>>>>>> for MEI files should be? >>>>>>>>>> >>>>>>>>>> I've been assuming .mei is the "standard", but a counter-example of >>>>>>>>>> .xml was recently brought to my attention. So, I thought I'd poll the >>>>>>>>>> collected wisdom and see what others were doing. Are you using .xml, >>>>>>>>>> .mei, or some other variation on these? >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> >>>>>>>>>> ==== >>>>>>>>>> Related: >>>>>>>>>> -- Should we register an actual mimetype? Maybe: >>>>>>>>>> application/vnd.music-encoding+xml ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 dave at titanmusic.com Wed Aug 21 15:28:27 2013 From: dave at titanmusic.com (David Meredith) Date: Wed, 21 Aug 2013 15:28:27 +0200 Subject: [MEI-L] Two fully-funded PhD studentships in machine modelling of musical learning and creativity In-Reply-To: <0C090608704AF04E898055296C932B129B827D94@EXCHANGE-01.kb.dk> Message-ID: Dear MEI list members, I am looking for two students to work with me on their PhDs in the area of machine modelling of musical learning and creativity. The two studentships will be fully funded by a new EU project called "Learning to Create" (Lrn2Cre8). The focus of this project is on the design, implementation and evaluation of systems that learn from examples to compose new music that either successfully simulates an existing musical style or extends an existing style. The two successful candidates will be employed as PhD students within the Department of Architecture, Design and Media Technology at Aalborg University in Denmark. The students will be expected to start 1 October 2014 or as soon as possible thereafter. Further details can be found here: http://www.stillinger.aau.dk/vis-stilling/?vacancy=596594 Please contact me to discuss the position informally before making an application. Note that the deadline for application is 23 September 2014. Kind regards David Meredith From dave at titanmusic.com Wed Aug 21 15:32:16 2013 From: dave at titanmusic.com (David Meredith) Date: Wed, 21 Aug 2013 15:32:16 +0200 Subject: [MEI-L] Wong dates: Re: Two fully-funded PhD studentships in machine modelling of musical learning and creativity In-Reply-To: Message-ID: Please note that the starting date for the two PhD studentships is 1 OCTOBER 2013 and the deadline for application is 23 SEPTEMBER 2013 (not 2014 as stated in my previous post). Sorry for any confusion! Kind regards, David Meredith On 21/08/2013 15:28, "David Meredith" wrote: >Dear MEI list members, > >I am looking for two students to work with me on their PhDs in the area of >machine modelling of musical learning and creativity. The two studentships >will be fully funded by a new EU project called "Learning to Create" >(Lrn2Cre8). The focus of this project is on the design, implementation and >evaluation of systems that learn from examples to compose new music that >either successfully simulates an existing musical style or extends an >existing style. The two successful candidates will be employed as PhD >students within the Department of Architecture, Design and Media >Technology at Aalborg University in Denmark. The students will be expected >to start 1 October 2014 or as soon as possible thereafter. > >Further details can be found here: > >http://www.stillinger.aau.dk/vis-stilling/?vacancy=596594 > >Please contact me to discuss the position informally before making an >application. > >Note that the deadline for application is 23 September 2014. > >Kind regards >David Meredith > > > >_______________________________________________ >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 Aug 21 16:13:48 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 21 Aug 2013 16:13:48 +0200 Subject: [MEI-L] del not member of att.edit Message-ID: <84E79331-BA45-4D02-B402-DF45F89B4B94@edirom.de> Hi list, I have a question for Perry: Apparently is not member of att.edit, which excludes attributes like @cert, @resp and @source. is member of that class. I'm looking forward to an explanation saying the bug is a feature ;-) If it's not convincing, I'm happy to file a report? jo From pdr4h at eservices.virginia.edu Thu Aug 22 04:54:30 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 22 Aug 2013 02:54:30 +0000 Subject: [MEI-L] del not member of att.edit In-Reply-To: <84E79331-BA45-4D02-B402-DF45F89B4B94@edirom.de> References: <84E79331-BA45-4D02-B402-DF45F89B4B94@edirom.de> Message-ID: Hello list, I have an answer for Johannes: The element's lack of membership in att.edit is simply an oversight. Please file a bug report. That is all. Over and out. :-) -- 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, August 21, 2013 10:13 AM To: Music Encoding Initiative Subject: [MEI-L] del not member of att.edit Hi list, I have a question for Perry: Apparently is not member of att.edit, which excludes attributes like @cert, @resp and @source. is member of that class. I'm looking forward to an explanation saying the bug is a feature ;-) If it's not convincing, I'm happy to file a report? jo _______________________________________________ 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 Fri Aug 30 16:00:49 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 30 Aug 2013 14:00:49 +0000 Subject: [MEI-L] Strange Error in ScoreDef Message-ID: Hi all, Does anyone know why I'm getting an error with the following markup? When I go to validate it against the mei-all.rng schema, Oxygen complains 'element staffGrp not allowed here; expected the element end tag' with a red squiggly line under the second staffGrp element. As far as I can see scoreDef can take one or more staffGrp elements, so I'm a bit confused. Any help would be appreciated, -Andrew From pdr4h at eservices.virginia.edu Fri Aug 30 16:09:03 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 30 Aug 2013 14:09:03 +0000 Subject: [MEI-L] Strange Error in ScoreDef In-Reply-To: References: Message-ID: Hi, Andrew, One more level of markup is necessary -- requires a single , which may then contain any number of elements, i.e., -- 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 [andrew.hankinson at mail.mcgill.ca] Sent: Friday, August 30, 2013 10:00 AM To: Music Encoding Initiative Subject: [MEI-L] Strange Error in ScoreDef Hi all, Does anyone know why I'm getting an error with the following markup? When I go to validate it against the mei-all.rng schema, Oxygen complains 'element staffGrp not allowed here; expected the element end tag' with a red squiggly line under the second staffGrp element. As far as I can see scoreDef can take one or more staffGrp elements, so I'm a bit confused. Any help would be appreciated, -Andrew _______________________________________________ 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 Aug 30 16:34:11 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Fri, 30 Aug 2013 14:34:11 +0000 Subject: [MEI-L] Strange Error in ScoreDef In-Reply-To: References: , Message-ID: As a follow-up to my answer to Andrew's question, I want to draw everyone's attention to the mei-all_anyStart schema, which can be useful in isolating problems like this. With this schema any MEI element can be the document element, but to you have to add the MEI namespace for oXygen, i.e., -- 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 Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] Sent: Friday, August 30, 2013 10:09 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Strange Error in ScoreDef Hi, Andrew, One more level of markup is necessary -- requires a single , which may then contain any number of elements, i.e., -- 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 [andrew.hankinson at mail.mcgill.ca] Sent: Friday, August 30, 2013 10:00 AM To: Music Encoding Initiative Subject: [MEI-L] Strange Error in ScoreDef Hi all, Does anyone know why I'm getting an error with the following markup? When I go to validate it against the mei-all.rng schema, Oxygen complains 'element staffGrp not allowed here; expected the element end tag' with a red squiggly line under the second staffGrp element. As far as I can see scoreDef can take one or more staffGrp elements, so I'm a bit confused. Any help would be appreciated, -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 Sep 24 16:41:22 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Tue, 24 Sep 2013 14:41:22 +0000 Subject: [MEI-L] Sibelius Export Plug-In beta testing Message-ID: This summer, thanks to support from Haverford College and the NEH, we've been able to finish developing the Sibelius to MEI export plug-in. I'd like to announce that it's now ready for beta testing. Note that it is only available for Sibelius 7+. For those who just want a downloadable ZIP file I've packaged up a snapshot available here: http://coltrane.music.mcgill.ca/Andrew/sibmei_plugin.zip The development version of the plug-in is available on GitHub: https://github.com/DuChemin/sibmei/tree/MEI2013-tested To install: - Download the plugin and un-zip it. - Navigate to your Sibelius plugin directory. (See here for detailed information: http://www.sibelius.com/download/plugins/index.html?help=install) To use: - Open a Sibelius document or import a MusicXML file. - Go to File->Plug-Ins->Edit Plug-Ins and find the 'sibmei' section. - You can either double-click on the "Export File to MEI" plugin and select Run, or you can set the sibmei plugins to appear in your ribbon. - It will ask you for a name and location to save your file. We would be interested in having you run a few of your files through the plug-in and reporting your results. If possible, you can send me your output files and I can ensure that the plug-in is producing valid MEI. If you find a bug, you can report it on our Issues page (https://github.com/DuChemin/sibmei/issues) or, if you don't have a GitHub account, you can send me an e-mail directly. Special thanks to Micah Walter for making this possible! Questions and comments are always welcome, -Andrew From donbyrd at indiana.edu Mon Sep 30 21:51:32 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Mon, 30 Sep 2013 15:51:32 -0400 Subject: [MEI-L] Camera-ready MEC papers due? Message-ID: <20130930155132.3xykfl0i5ckwso08@webmail.iu.edu> I could swear I got a message a month or so back to the effect that camera-ready versions of MEC papers would be due by 30 September, that is, today! But I can't find it anywhere, including the archive! Does anyone know anything about this? I'll bet someone on this list does :-) . --Don -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington From drizovalero at gmail.com Mon Sep 30 22:07:15 2013 From: drizovalero at gmail.com (drizo) Date: Mon, 30 Sep 2013 22:07:15 +0200 Subject: [MEI-L] Camera-ready MEC papers due? In-Reply-To: <20130930155132.3xykfl0i5ckwso08@webmail.iu.edu> References: <20130930155132.3xykfl0i5ckwso08@webmail.iu.edu> Message-ID: <17EA0941-02BD-49DF-AD44-89FD6EA6B05E@dlsi.ua.es> Hi, I asked a few days a question about the formats of the CR and Johannes Kepper answered me, with Cc: the MEC organizers. Thus, I've sent my camera ready to: Music Encoding Conference Organizers Johannes Kepper -- David El 30/09/2013, a las 21:51, "Byrd, Donald A." escribi?: > I could swear I got a message a month or so back to the effect that camera-ready versions of MEC papers would be due by 30 September, that is, today! But I can't find it anywhere, including the archive! Does anyone know anything about this? I'll bet someone on this list does :-) . > > --Don > > > -- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > Indiana University Bloomington > > > _______________________________________________ > 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: 3620 bytes Desc: not available URL: From donbyrd at indiana.edu Mon Sep 30 22:29:26 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Mon, 30 Sep 2013 16:29:26 -0400 Subject: [MEI-L] Camera-ready MEC papers due? In-Reply-To: <17EA0941-02BD-49DF-AD44-89FD6EA6B05E@dlsi.ua.es> References: <20130930155132.3xykfl0i5ckwso08@webmail.iu.edu> <17EA0941-02BD-49DF-AD44-89FD6EA6B05E@dlsi.ua.es> Message-ID: <20130930162926.glw02yehoggwsk40@webmail.iu.edu> Thanks, David. But speaking of the the format, I've been assuming that it's as described in the template they sent before the conference. Did Johannes suggest otherwise? --DAB On Mon, 30 Sep 2013 22:07:15 +0200, drizo wrote: > Hi, > > I asked a few days a question about the formats of the CR and > Johannes Kepper answered me, with Cc: the MEC organizers. > > Thus, I've sent my camera ready to: > Music Encoding Conference Organizers > Johannes Kepper > > -- David > > > > > El 30/09/2013, a las 21:51, "Byrd, Donald A." escribi?: > >> I could swear I got a message a month or so back to the effect that >> camera-ready versions of MEC papers would be due by 30 September, >> that is, today! But I can't find it anywhere, including the archive! >> Does anyone know anything about this? I'll bet someone on this list >> does :-) . >> >> --Don >> >> >> >> _______________________________________________ >> 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 Visiting Scientist, Research Technologies Indiana University Bloomington From kepper at edirom.de Mon Sep 30 23:25:35 2013 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 30 Sep 2013 23:25:35 +0200 Subject: [MEI-L] Camera-ready MEC papers due? In-Reply-To: <20130930162926.glw02yehoggwsk40@webmail.iu.edu> References: <20130930155132.3xykfl0i5ckwso08@webmail.iu.edu> <17EA0941-02BD-49DF-AD44-89FD6EA6B05E@dlsi.ua.es> <20130930162926.glw02yehoggwsk40@webmail.iu.edu> Message-ID: Dear all, Please excuse any confusion about the submission process. We've been rather busy with running our summer school and other things the last week(s), and are just coming back to the proceedings. Plus, my connectivity is rather limited these days because of technical issues, so please excuse any late and rather brief answer. Your assumptions are right. The due date is today, and I'm trying to bring everything together this week. I will contact those of you that are supposed to deliver and haven't by tomorrow individually. Submitting via conftool or by mail to conference2013 at music-encoding.org (where it ends up in multiple inboxes) is equally fine. I hope it's all clear as mud for the time being ? more information to follow ;-) Best, Johannes Am 30.09.2013 um 22:29 schrieb "Byrd, Donald A." : > Thanks, David. But speaking of the the format, I've been assuming that it's as described in the template they sent before the conference. Did Johannes suggest otherwise? > > --DAB > > > On Mon, 30 Sep 2013 22:07:15 +0200, drizo wrote: > >> Hi, >> >> I asked a few days a question about the formats of the CR and >> Johannes Kepper answered me, with Cc: the MEC organizers. >> >> Thus, I've sent my camera ready to: >> Music Encoding Conference Organizers >> Johannes Kepper >> >> -- David >> >> >> >> >> El 30/09/2013, a las 21:51, "Byrd, Donald A." escribi?: >> >>> I could swear I got a message a month or so back to the effect that >>> camera-ready versions of MEC papers would be due by 30 September, >>> that is, today! But I can't find it anywhere, including the archive! >>> Does anyone know anything about this? I'll bet someone on this list >>> does :-) . >>> >>> --Don >>> >>> >>> >>> _______________________________________________ >>> 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 > Visiting Scientist, Research Technologies > Indiana University Bloomington > > > _______________________________________________ > 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 Oct 16 15:22:39 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Wed, 16 Oct 2013 09:22:39 -0400 Subject: [MEI-L] @color on verse or syl Message-ID: Deal list, Neither verse or syl seem to be members of att.color (which means that the @color attribute is not allowed). Is this by design? If yes, how can I color my lyrics? Otherwise, if we agree that there's no harm in having @color for lyrics, I'll file a feature request. Best, Raf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Wed Oct 16 15:49:22 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 16 Oct 2013 13:49:22 +0000 Subject: [MEI-L] @color on verse or syl In-Reply-To: References: Message-ID: Hi, Raffaele, This is by design. permits , which is a member of att.color. The goal was to limit the number of members of att.color and encourage the use of for such things. The downside to this, of course, is that color has to be specified for each syllable and can't be stated at the level. So, making a member of att.color is probably a good idea. Still, I'd prefer not to do the same with . Please go ahead and file a request. -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Wednesday, October 16, 2013 9:22 AM To: Music Encoding Initiative Subject: [MEI-L] @color on verse or syl Deal list, Neither verse or syl seem to be members of att.color (which means that the @color attribute is not allowed). Is this by design? If yes, how can I color my lyrics? Otherwise, if we agree that there's no harm in having @color for lyrics, I'll file a feature request. Best, Raf -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaeleviglianti at gmail.com Wed Oct 16 20:11:02 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Wed, 16 Oct 2013 14:11:02 -0400 Subject: [MEI-L] Fwd: [globaloutlookDH-l] Fwd: EADH small grants call for proposals In-Reply-To: <26533222-FBB2-4CB5-89F6-D40E229631EE@yahoo.es> References: <26533222-FBB2-4CB5-89F6-D40E229631EE@yahoo.es> Message-ID: For our colleagues in European institutions... ---------- Forwarded message ---------- From: Elena Date: Wed, Oct 16, 2013 at 1:29 PM Subject: [globaloutlookDH-l] Fwd: EADH small grants call for proposals To: Global Outlook Inicio del mensaje reenviado: *De:* Elena Gonzalez-Blanco *Fecha:* 16 de octubre de 2013 17:00:32 GMT+02:00 *Para:* "globaloutlookdh-l at uleth.ca" *Asunto:* *EADH small grants call for proposals* EADH Small Grants: Call for Proposals The European Association for the Digital Humanities (EADH) hereby invites submissions for small grants to support Digital Humanities activities. The call is open to anyone active in Digital Humanities, although projects with an institutional or thematic connection to Europe will be prioritized. Furthermore, the EADH sees the development of linguistically and culturally focused Digital Humanities groups and associations around Europe as a very positive development, for individual professionals as well as for the field as a whole. As such, we particularly welcome initiatives proposed or endorsed by Europe-based national and regional DH organisations. Submissions are expected to be in the range of ? 800 to ? 2,000. The total amount available in this call is ? 15,000. Successful awardees will be expected to write a short report on their activities during the lifetime of the grant. Information about previously successful grant applications can be found at: http://www.allc.org/support/previously-supported-activities More about the aims of EADH grants can be found in the ?General description of EADH calls for workshops and projects? at: http://www.allc.org/research/allc-support The format for proposals is described fully at: http://www.allc.org/research/allc-supported-workshops-and-projects/allc-calls-workshop-and-project-support#3 The maximum length of a proposal is three pages, including a cover sheet with title, one paragraph summary, total amount requested and a list of proposers, including affiliations and email addresses. The usual Terms and Conditions restricting submissions to registered EADH-members, do NOT apply to this call. Proposals (and any enquiries) should be sent to l.isaksen [at] soton.ac.uk by 17 November, 2013. Please note that as applications usually exceed the number of grants available late submissions cannot be considered. Notification of the results will be sent on 20 December 2013 at the latest. Leif Isaksen, on behalf of the The EADH Small Grants Committee Claire Clivaz Karina van Dalen-Oskam Elena Gonzalez-Blanco Leif Isaksen -- Elena Gonz?lez-Blanco Garc?a Dpto. de Literatura Espa?ola y Teor?a de la Literatura, Despacho 722 Facultad de Filolog?a, UNED Paseo Senda del Rey 7 28040 MADRID tel. 91 3986873 _______________________________________________ globaloutlookdh-l mailing list globaloutlookdh-l at uleth.ca http://listserv.uleth.ca/mailman/listinfo/globaloutlookdh-l You are currently subscribed to this list in NON-digest mode. This means you receive every message as it is posted. If this represents too much traffic, you can also subscribe in DIGEST mode. This sends out a single email once a day containing the entire day's postings. To change your settings go to http://listserv.uleth.ca/mailman/options/globaloutlookdh-l You can request a password reminder from this page if you have forgotten yours. -------------- next part -------------- An HTML attachment was scrubbed... URL: From slu at kb.dk Tue Oct 29 13:26:59 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Tue, 29 Oct 2013 12:26:59 +0000 Subject: [MEI-L] mup & lilypond et al. Message-ID: <0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk> Hi all of you, I've been working on a project which involves automatic generation of scores from an eXist native XML database containing musical segments. I've coded a MEI generator in the XQuery language, and the result is then translated into mup and from there to either PDF or MIDI. I'm working in MEI 2010-05 but are looking for a way forward to more modern MEI and higher quality PDF or even better SVG. Please find generated xml, pdf and midi attached (if it survives the listserv, they are miniscule and shouldn't hur bandwidth) Suggestions. Should I go for MEI 2013, and I suppose Lilypond? Any other ideas? The system has to run batch server side on a Linux server. Any opinions? Sigfrid -------------- next part -------------- A non-text attachment was scrubbed... Name: tune.mid Type: audio/midi Size: 5219 bytes Desc: tune.mid URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tune.pdf Type: application/pdf Size: 16594 bytes Desc: tune.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tune.xml Type: text/xml Size: 47160 bytes Desc: tune.xml URL: From kepper at edirom.de Tue Oct 29 13:42:18 2013 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 29 Oct 2013 13:42:18 +0100 Subject: [MEI-L] mup & lilypond et al. In-Reply-To: <0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk> References: <0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk> Message-ID: <6B8A013A-BE8F-4094-A440-40115B957690@edirom.de> Hi Sigge, I started work on a translator to abc, ultimately targeting to abcjs, which is a javascript library for rendering (and editing) abc-encoded music notation. I suspect the rendering algorithms are coming from MusicTeX, but I'm not absolutely sure about that. The output is clearly inferior to many other rendering systems, but roughly compares to VexFlow. Some things that VexFlow can do aren't possible with abcjs and vice versa. We use this library for proof-reading our files. We transform our MEI files within eXist into an abc string, which is than sent to the user's browser and rendered there. abcjs also has a MIDI output, but I haven't used that yet. I wanted to set up a demo page before announcing this on MEI-L, but the code is already online at https://github.com/Edirom/mei2abc If you think this is a viable option for your project, we can certainly discuss how to improve it, and I can point you to a page utilizing it (not public yet, sorry). Best, Johannes Am 29.10.2013 um 13:26 schrieb Sigfrid Lundberg : > Hi all of you, > > I've been working on a project which involves automatic generation of scores from an eXist native XML database containing musical segments. I've coded a MEI generator in the XQuery language, and the result is then translated into mup and from there to either PDF or MIDI. I'm working in MEI 2010-05 but are looking for a way forward to more modern MEI and higher quality PDF or even better SVG. > > Please find generated xml, pdf and midi attached (if it survives the listserv, they are miniscule and shouldn't hur bandwidth) > > Suggestions. Should I go for MEI 2013, and I suppose Lilypond? Any other ideas? The system has to run batch server side on a Linux server. > > Any opinions? > > Sigfrid _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From slu at kb.dk Tue Oct 29 13:52:06 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Tue, 29 Oct 2013 12:52:06 +0000 Subject: [MEI-L] mup & lilypond et al. In-Reply-To: <6B8A013A-BE8F-4094-A440-40115B957690@edirom.de> References: <0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk>, <6B8A013A-BE8F-4094-A440-40115B957690@edirom.de> Message-ID: <0C090608704AF04E898055296C932B12FFE4CFCB@EXCHANGE-03.kb.dk> Interesting option! Even the mei2vexflow system requires a transform to the level that it can be parsed by html parsers like jquery. We have an external gateway which does the mup, midi and pdf. Old fashion CGI Sigge ________________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Johannes Kepper [kepper at edirom.de] Sendt: 29. oktober 2013 13:42 Til: Music Encoding Initiative Emne: Re: [MEI-L] mup & lilypond et al. Hi Sigge, I started work on a translator to abc, ultimately targeting to abcjs, which is a javascript library for rendering (and editing) abc-encoded music notation. I suspect the rendering algorithms are coming from MusicTeX, but I'm not absolutely sure about that. The output is clearly inferior to many other rendering systems, but roughly compares to VexFlow. Some things that VexFlow can do aren't possible with abcjs and vice versa. We use this library for proof-reading our files. We transform our MEI files within eXist into an abc string, which is than sent to the user's browser and rendered there. abcjs also has a MIDI output, but I haven't used that yet. I wanted to set up a demo page before announcing this on MEI-L, but the code is already online at https://github.com/Edirom/mei2abc If you think this is a viable option for your project, we can certainly discuss how to improve it, and I can point you to a page utilizing it (not public yet, sorry). Best, Johannes Am 29.10.2013 um 13:26 schrieb Sigfrid Lundberg : > Hi all of you, > > I've been working on a project which involves automatic generation of scores from an eXist native XML database containing musical segments. I've coded a MEI generator in the XQuery language, and the result is then translated into mup and from there to either PDF or MIDI. I'm working in MEI 2010-05 but are looking for a way forward to more modern MEI and higher quality PDF or even better SVG. > > Please find generated xml, pdf and midi attached (if it survives the listserv, they are miniscule and shouldn't hur bandwidth) > > Suggestions. Should I go for MEI 2013, and I suppose Lilypond? Any other ideas? The system has to run batch server side on a Linux server. > > Any opinions? > > Sigfrid _______________________________________________ > 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 lxpugin at gmail.com Tue Oct 29 16:02:18 2013 From: lxpugin at gmail.com (Laurent Pugin) Date: Tue, 29 Oct 2013 16:02:18 +0100 Subject: [MEI-L] Page-based encoding Message-ID: Hi, Here are a few thoughts for having a page-based encoding option in MEI. The idea is to make it possible to encode the positioning of elements directly in the content tree. This can be useful in some uses of MEI where the encoding represents one single source with one image per page. It is typically the case with OMR, where the data is conceptually organized by pages related to specific input images. Another use can be to create overlay images to be displayed on top of a facsimile image where the position of each symbols needs to be encoded. Whilst I am aware that anything that can be represented with a page-base module could probably also be represented with the current stage of MEI with a facsimile tree and references, the page-based module would make it much simpler. It would also not preclude having at the same time a facsimile tree with references if necessary. A page-base organization for specifying the position directly in the content encoding tree requires two things. 1) The ability to encode the document (pages) structure as the main tree, and 2) the ability to specify positioning. 1) For the document structure to be encoded, we need to have page and system elements. The content of a score becomes a list of /page. Each /page contains a list of /system. In un-measure music /system contains a list of /staff. In measured music, we can imagine a) /system containing a list of /staff containing a list of /measure (and then /layer), or b) /system containing a list of /measure containing a list of /staff. Solution a) seems more natural to me (if we think how music is written on paper, we first have staves and then add measure). Solution b) has the advantage of being closer to the standard MEI focusing on content. This needs to be discussed. 2) For the positioning, we need to add attributes the elements that can have a position. Basically, any element with the @facs. We can solve this by making the att.facsimile class member of att.coordinated. This provides us with the necessary @ulx, @uly, etc. for specifying the position. We also need to specify to which image the position refers to. A simple approach is to add a @surface to /page. As mentioned before, all this does not preclude to use the standard @facs and facsimile tree scheme at the same time, for example if a higher resolution image needs to be added for specific elements. We also need to have a @unit in /page and presumably also be able to specify if the positioning is absolute or relative. Another point to be discussed it if we want to keep this in the score subtree or if such encoding could be put into another subtree. One option would be a /pages element at the same level of /parts and /score. In other word, this would be a third representation option in MEI. I already made a customization for unmeasured music and I am willing to do one for measured music for option a) or b) and when we agree where to put it. The sample file attached for unmeasured music was generated from the OMR output of Aruspix. Best, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: page-based-measured-a.mei Type: application/octet-stream Size: 13854 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: page-based-measured-b.mei Type: application/octet-stream Size: 18496 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: page-based-unmeasured.mei Type: application/octet-stream Size: 33851 bytes Desc: not available URL: From craigsapp at gmail.com Tue Oct 29 17:40:57 2013 From: craigsapp at gmail.com (Craig Sapp) Date: Tue, 29 Oct 2013 09:40:57 -0700 Subject: [MEI-L] mup & lilypond et al. In-Reply-To: <0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk> References: <0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk> Message-ID: Hi Sigfrid, Here is the result you desire, a high-quality SVG image (displayed inline depending on your mail reader/browser, otherwise see the .svg attachment): [image: Inline images 1] Generation of such an image could be automated, but probably too complex to deal with for a small project. It would also involve CGI interfacing to the DOS version of SCORE via dosemu: http://wiki.ccarh.org/wiki/Dosemu Also, you would need to use Wine http://en.wikipedia.org/wiki/Wine_(software) to run a Windows command-line program to automatically adjust beam angles/heights using a program called BEAM written by Tom Brodhead: http://home.comcast.net/~tom.brodhead And a ruby script to convert SCORE EPS files into SVG: https://github.com/th-we/seps2svg For full automation, three manual operations were needed to generate the above example: (1) layout -- I copied the layout that you gave. Automated layout in SCORE is possible, but that would add moderatly to the complexity. (2) vertical placement of measure tags. I put the tags at vertical step 15 in SCORE, and adjust them higher by hand when they collided with the music. This would be relatively simple to automate. (3) note offsets such as in measure 7 LH would need to be automated. Also relatively simple. The most difficult measure to automatically typeset would be measure 9 (first full measure of the second system). Presumably you chose to do the cross staff beaming of notes rather than MUP? And would this instruction be encoded in the MEI data? MUP had two difficulties in this measure: (1) attaching notes correctly to the beam, and (2) raising the rests to accommodate the notes. This will cause problems for most all automatic typesetting programs. Lilypond will give slightly higher-quality results than MUP but not by a large amount. The main advantage of lilypond is that it can handle a wide range of musical symbols as well as be able to handle slightly more complex music than MUP can. Lilypond is reasonably fast but probably slower than MUP. Lilypond can output SVG images. MUP can also be used to generate SVG images by sending the PostScript output through GhostScript or inkscape. Both lilypond and MUP SVG output will be very messy looking in terms of the code because both of them do not calculate the SVG data directly, but send through an external library/program. Abcm2ps (ABC+) will give a slightly lower quality result. The cross-staff notation of measure 9 cannot be handled by ABC+ or abcm2ps (as far as I am aware). The main advantage of abcm2ps printing (via a GCI interface) is that it is very fast (implemented in C). I don't know the quality/behavior of the JavaScript interface to abc. Using abcm2ps (http://moinejf.free.fr) would be similar to MUP, and SVG output could be done through GhostScript or inkscape. Vexflow I cannot imagine can handle music of this complexity. Someone who uses vexflow can post this example generated by vexflow to prove me wrong :-). -=+Craig On 29 October 2013 05:26, Sigfrid Lundberg wrote: > > I've been working on a project which involves automatic generation of scores from an eXist native XML database containing musical segments. I've coded a MEI generator in the XQuery language, and the result is then translated into mup and from there to either PDF or MIDI. I'm working in MEI 2010-05 but are looking for a way forward to more modern MEI and higher quality PDF or even better SVG. > > Please find generated xml, pdf and midi attached (if it survives the listserv, they are miniscule and shouldn't hur bandwidth) > > Suggestions. Should I go for MEI 2013, and I suppose Lilypond? Any other ideas? The system has to run batch server side on a Linux server. > > Any opinions? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kaleid.svg Type: image/svg+xml Size: 99033 bytes Desc: not available URL: From craigsapp at gmail.com Tue Oct 29 18:14:53 2013 From: craigsapp at gmail.com (Craig Sapp) Date: Tue, 29 Oct 2013 10:14:53 -0700 Subject: [MEI-L] mup & lilypond et al. In-Reply-To: References: <0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk> Message-ID: Hi Everyone, I had a report that the SVG image got totally dropped via at least one mailing list/browser/mail program path, so attached in the SVG image from my previous email in a ZIP attachment. -=+Craig On 29 October 2013 09:40, Craig Sapp wrote: > Hi Sigfrid, > > Here is the result you desire, a high-quality SVG image (displayed inline > depending on your mail reader/browser, otherwise see the .svg attachment): > > [image: Inline images 1] > > Generation of such an image could be automated, but probably too complex > to deal with for a small project. It would also involve CGI interfacing to > the DOS version of SCORE via dosemu: > http://wiki.ccarh.org/wiki/Dosemu > Also, you would need to use Wine > http://en.wikipedia.org/wiki/Wine_(software) to run a Windows > command-line program to automatically adjust beam angles/heights using a > program called BEAM written by Tom Brodhead: > http://home.comcast.net/~tom.brodhead > And a ruby script to convert SCORE EPS files into SVG: > https://github.com/th-we/seps2svg > > For full automation, three manual operations were needed to generate the > above example: > (1) layout -- I copied the layout that you gave. Automated layout in > SCORE is possible, but that would add moderatly to the complexity. > (2) vertical placement of measure tags. I put the tags at vertical step > 15 in SCORE, and adjust them higher by hand when they collided with the > music. This would be relatively simple to automate. > (3) note offsets such as in measure 7 LH would need to be automated. Also > relatively simple. > > The most difficult measure to automatically typeset would be measure 9 > (first full measure of the second system). Presumably you chose to do the > cross staff beaming of notes rather than MUP? And would this instruction > be encoded in the MEI data? MUP had two difficulties in this measure: (1) > attaching notes correctly to the beam, and (2) raising the rests to > accommodate the notes. This will cause problems for most all automatic > typesetting programs. > > Lilypond will give slightly higher-quality results than MUP but not by a > large amount. The main advantage of lilypond is that it can handle a wide > range of musical symbols as well as be able to handle slightly more complex > music than MUP can. Lilypond is reasonably fast but probably slower than > MUP. Lilypond can output SVG images. MUP can also be used to generate SVG > images by sending the PostScript output through GhostScript or inkscape. > Both lilypond and MUP SVG output will be very messy looking in terms of > the code because both of them do not calculate the SVG data directly, but > send through an external library/program. > > Abcm2ps (ABC+) will give a slightly lower quality result. The cross-staff > notation of measure 9 cannot be handled by ABC+ or abcm2ps (as far as I am > aware). The main advantage of abcm2ps printing (via a GCI interface) is > that it is very fast (implemented in C). I don't know the quality/behavior > of the JavaScript interface to abc. Using abcm2ps (http://moinejf.free.fr) > would be similar to MUP, and SVG output could be done through GhostScript > or inkscape. > > Vexflow I cannot imagine can handle music of this complexity. Someone who > uses vexflow can post this example generated by vexflow to prove me wrong > :-). > > > -=+Craig > > > On 29 October 2013 05:26, Sigfrid Lundberg wrote: > > > > I've been working on a project which involves automatic generation of > scores from an eXist native XML database containing musical segments. I've > coded a MEI generator in the XQuery language, and the result is then > translated into mup and from there to either PDF or MIDI. I'm working in > MEI 2010-05 but are looking for a way forward to more modern MEI and higher > quality PDF or even better SVG. > > > > Please find generated xml, pdf and midi attached (if it survives the > listserv, they are miniscule and shouldn't hur bandwidth) > > > > Suggestions. Should I go for MEI 2013, and I suppose Lilypond? Any other > ideas? The system has to run batch server side on a Linux server. > > > > Any opinions? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kaleid.svg Type: image/svg+xml Size: 99033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: kaleid.zip Type: application/zip Size: 17417 bytes Desc: not available URL: From drizovalero at gmail.com Wed Oct 30 17:20:43 2013 From: drizovalero at gmail.com (drizo) Date: Wed, 30 Oct 2013 17:20:43 +0100 Subject: [MEI-L] mup & lilypond et al. In-Reply-To: References: <0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk> Message-ID: Hi, I?ll trying to find the report without success. John S. Gourlay. ``Spacing a Line of Music, '' Technical Report OSU-CISRC-10/87-TR35, Department of Computer and Information Science, The Ohio State University, 1987. Do you know where can I download it? Thank you in advance, David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3620 bytes Desc: not available URL: From laurent at music.mcgill.ca Wed Oct 30 17:33:36 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Wed, 30 Oct 2013 17:33:36 +0100 Subject: [MEI-L] mup & lilypond et al. In-Reply-To: <24575_1383049653_526FA9B5_24575_6_3_0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk> References: <24575_1383049653_526FA9B5_24575_6_3_0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk> Message-ID: Hi Sigfrid, I am currently working on packing a command-line tool for converted (some) MEI to SVG. It might be interesting for you, I'll keep you posted on this. Two questions regarding the encoding of the example at measure 9: 1) Why do you encode the two first rests in a separate layer? 2) On the second staff, for the cross-staff notes where you use an @staff="1", don't we need also a @layer with this? Best, Laurent On Tue, Oct 29, 2013 at 1:26 PM, Sigfrid Lundberg wrote: > Hi all of you, > > I've been working on a project which involves automatic generation of > scores from an eXist native XML database containing musical segments. I've > coded a MEI generator in the XQuery language, and the result is then > translated into mup and from there to either PDF or MIDI. I'm working in > MEI 2010-05 but are looking for a way forward to more modern MEI and higher > quality PDF or even better SVG. > > Please find generated xml, pdf and midi attached (if it survives the > listserv, they are miniscule and shouldn't hur bandwidth) > > Suggestions. Should I go for MEI 2013, and I suppose Lilypond? Any other > ideas? The system has to run batch server side on a Linux server. > > Any opinions? > > Sigfrid > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From slu at kb.dk Wed Oct 30 21:45:02 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Wed, 30 Oct 2013 20:45:02 +0000 Subject: [MEI-L] mup & lilypond et al. In-Reply-To: References: <24575_1383049653_526FA9B5_24575_6_3_0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk>, Message-ID: Hi Laurent, Interesting with your svg translator! Layers were the way to encode parallell events that worked with mei2mup. Since there aren't multiple voices in the target staff I didn't use that. However, the only justification I have is that it works. Yours Sigfrid Skickat fr?n Samsung Tablet Laurent Pugin skrev: Hi Sigfrid, I am currently working on packing a command-line tool for converted (some) MEI to SVG. It might be interesting for you, I'll keep you posted on this. Two questions regarding the encoding of the example at measure 9: 1) Why do you encode the two first rests in a separate layer? 2) On the second staff, for the cross-staff notes where you use an @staff="1", don't we need also a @layer with this? Best, Laurent On Tue, Oct 29, 2013 at 1:26 PM, Sigfrid Lundberg > wrote: Hi all of you, I've been working on a project which involves automatic generation of scores from an eXist native XML database containing musical segments. I've coded a MEI generator in the XQuery language, and the result is then translated into mup and from there to either PDF or MIDI. I'm working in MEI 2010-05 but are looking for a way forward to more modern MEI and higher quality PDF or even better SVG. Please find generated xml, pdf and midi attached (if it survives the listserv, they are miniscule and shouldn't hur bandwidth) Suggestions. Should I go for MEI 2013, and I suppose Lilypond? Any other ideas? The system has to run batch server side on a Linux server. Any opinions? Sigfrid _______________________________________________ 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: From kepper at edirom.de Thu Oct 31 09:44:49 2013 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 31 Oct 2013 09:44:49 +0100 Subject: [MEI-L] =?windows-1252?q?save_the_date_=96_Music_Encoding_Confere?= =?windows-1252?q?nce_2014?= Message-ID: <29E8EEB3-A601-4260-84A1-E754B3C9B5EC@edirom.de> Dear all, I'm happy to let you know that things are moving forward quickly, and we'll be able to host a successing Music Encoding Conference at UVA in Charlottesville. Perry and I are proud and grateful to say that Giuliano Di Bacco is chairing the Program Committee. While we're still resolving some organizational issues, we wanted to give the MEI community a head start by giving you the most important dates by now, whereas the official call for papers will be announced early next week. The schedule will be tight (again?), so prepare yourself and save the date(s). All organizational details will follow with the official call, which will go out to other listservs as well (please don't forward this mail yet, since some have specific rules on repeated submissions, like AMS ? we'll let you know when to start advertising this publicly). Here are the dates important at this point: The conference will be held from on 21-23 May 2014 in Charlottesville, with pre-conference workshops on 20 May. Submission deadline will be by the end of the year. Notification of acceptance will be early February. --- We're looking forward to an inspiring conference and meeting with all of you in Charlottesville, Giuliano, Perry and Johannes From slu at kb.dk Thu Oct 31 09:55:32 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Thu, 31 Oct 2013 08:55:32 +0000 Subject: [MEI-L] mup & lilypond et al. In-Reply-To: References: <0C090608704AF04E898055296C932B12FFE4CFAE@EXCHANGE-03.kb.dk>, Message-ID: <0C090608704AF04E898055296C932B12FFF23D0B@EXCHANGE-03.kb.dk> Thanks Craig for useful info about SCORE, mup, abc and other stuff. And I hadn't heard about inkscape either. Thanks for that one :) Sigfrid ________________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Craig Sapp [craigsapp at gmail.com] Sendt: 29. oktober 2013 17:40 Til: Music Encoding Initiative Emne: Re: [MEI-L] mup & lilypond et al. Hi Sigfrid, Here is the result you desire, a high-quality SVG image (displayed inline depending on your mail reader/browser, otherwise see the .svg attachment): Generation of such an image could be automated, but probably too complex to deal with for a small project. It would also involve CGI interfacing to the DOS version of SCORE via dosemu: http://wiki.ccarh.org/wiki/Dosemu Also, you would need to use Wine http://en.wikipedia.org/wiki/Wine_(software) to run a Windows command-line program to automatically adjust beam angles/heights using a program called BEAM written by Tom Brodhead: http://home.comcast.net/~tom.brodhead And a ruby script to convert SCORE EPS files into SVG: https://github.com/th-we/seps2svg For full automation, three manual operations were needed to generate the above example: (1) layout -- I copied the layout that you gave. Automated layout in SCORE is possible, but that would add moderatly to the complexity. (2) vertical placement of measure tags. I put the tags at vertical step 15 in SCORE, and adjust them higher by hand when they collided with the music. This would be relatively simple to automate. (3) note offsets such as in measure 7 LH would need to be automated. Also relatively simple. The most difficult measure to automatically typeset would be measure 9 (first full measure of the second system). Presumably you chose to do the cross staff beaming of notes rather than MUP? And would this instruction be encoded in the MEI data? MUP had two difficulties in this measure: (1) attaching notes correctly to the beam, and (2) raising the rests to accommodate the notes. This will cause problems for most all automatic typesetting programs. Lilypond will give slightly higher-quality results than MUP but not by a large amount. The main advantage of lilypond is that it can handle a wide range of musical symbols as well as be able to handle slightly more complex music than MUP can. Lilypond is reasonably fast but probably slower than MUP. Lilypond can output SVG images. MUP can also be used to generate SVG images by sending the PostScript output through GhostScript or inkscape. Both lilypond and MUP SVG output will be very messy looking in terms of the code because both of them do not calculate the SVG data directly, but send through an external library/program. Abcm2ps (ABC+) will give a slightly lower quality result. The cross-staff notation of measure 9 cannot be handled by ABC+ or abcm2ps (as far as I am aware). The main advantage of abcm2ps printing (via a GCI interface) is that it is very fast (implemented in C). I don't know the quality/behavior of the JavaScript interface to abc. Using abcm2ps (http://moinejf.free.fr) would be similar to MUP, and SVG output could be done through GhostScript or inkscape. Vexflow I cannot imagine can handle music of this complexity. Someone who uses vexflow can post this example generated by vexflow to prove me wrong :-). -=+Craig On 29 October 2013 05:26, Sigfrid Lundberg > wrote: > > I've been working on a project which involves automatic generation of scores from an eXist native XML database containing musical segments. I've coded a MEI generator in the XQuery language, and the result is then translated into mup and from there to either PDF or MIDI. I'm working in MEI 2010-05 but are looking for a way forward to more modern MEI and higher quality PDF or even better SVG. > > Please find generated xml, pdf and midi attached (if it survives the listserv, they are miniscule and shouldn't hur bandwidth) > > Suggestions. Should I go for MEI 2013, and I suppose Lilypond? Any other ideas? The system has to run batch server side on a Linux server. > > Any opinions? From raffaeleviglianti at gmail.com Thu Oct 31 20:52:21 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 31 Oct 2013 15:52:21 -0400 Subject: [MEI-L] Page-based encoding In-Reply-To: References: Message-ID: Hi Laurent, thanks for sharing this, a few comments: On Tue, Oct 29, 2013 at 11:02 AM, Laurent Pugin wrote: > > > 1) For the document structure to be encoded, we need to have page and > system elements. The content of a score becomes a list of /page. Each /page > contains a list of /system. In un-measure music /system contains a list of > /staff. In measured music, we can imagine a) /system containing a list of > /staff containing a list of /measure (and then /layer), or b) /system > containing a list of /measure containing a list of /staff. Solution a) > seems more natural to me (if we think how music is written on paper, we > first have staves and then add measure). Solution b) has the advantage of > being closer to the standard MEI focusing on content. This needs to be > discussed. > It makes sense that when the page hierarchy is flipped, the system hierarchy gets flipped as well, so that you can encode layout data on systems too. Though I don't think the same logic applies to staff and measure so I'd be tempted to go with b), because it would make switching between a page-based encoding and a "standard" encoding easier. > > > 2) For the positioning, we need to add attributes the elements that can > have a position. Basically, any element with the @facs. We can solve this > by making the att.facsimile class member of att.coordinated. This provides > us with the necessary @ulx, @uly, etc. for specifying the position. We also > need to specify to which image the position refers to. A simple approach is > to add a @surface to /page. As mentioned before, all this does not preclude > to use the standard @facs and facsimile tree scheme at the same time, for > example if a higher resolution image needs to be added for specific > elements. We also need to have a @unit in /page and presumably also be able > to specify if the positioning is absolute or relative. > +1. Those would be good to have around even outside of a page-based module, I think. > > > Another point to be discussed it if we want to keep this in the score > subtree or if such encoding could be put into another subtree. One option > would be a /pages element at the same level of /parts and /score. In other > word, this would be a third representation option in MEI. > > > Yes, I'd keep it in a different subtree, so that content can be linked in the same file if necessary. In general: I see why this approach to encoding is useful, though if we make it part of MEI, we should make quite clear when it's ok to encode in page-based fashion and when it's not. Basically we should discourage this approach unless it's required for specific (scholarly, justifiable) reasons. Raf > I already made a customization for unmeasured music and I am willing to do > one for measured music for option a) or b) and when we agree where to put > it. The sample file attached for unmeasured music was generated from the > OMR output of Aruspix. > > > Best, > > Laurent > > > > > > _______________________________________________ > 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: From laurent at music.mcgill.ca Sat Nov 2 08:41:42 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Sat, 2 Nov 2013 08:41:42 +0100 Subject: [MEI-L] Page-based encoding In-Reply-To: <4727_1383249182_5272B51D_4727_19_1_CAMyHAnNbRaP2n+Pqf0QbcSk_5WDFkEZhx=PJu4PtxaBcvz2f8Q@mail.gmail.com> References: <4727_1383249182_5272B51D_4727_19_1_CAMyHAnNbRaP2n+Pqf0QbcSk_5WDFkEZhx=PJu4PtxaBcvz2f8Q@mail.gmail.com> Message-ID: Hi Raffaele, Thanks for you comments, more below On Thu, Oct 31, 2013 at 8:52 PM, Raffaele Viglianti < raffaeleviglianti at gmail.com> wrote: > Hi Laurent, thanks for sharing this, a few comments: > > On Tue, Oct 29, 2013 at 11:02 AM, Laurent Pugin wrote: > > >> >> >> 1) For the document structure to be encoded, we need to have page and >> system elements. The content of a score becomes a list of /page. Each /page >> contains a list of /system. In un-measure music /system contains a list of >> /staff. In measured music, we can imagine a) /system containing a list of >> /staff containing a list of /measure (and then /layer), or b) /system >> containing a list of /measure containing a list of /staff. Solution a) >> seems more natural to me (if we think how music is written on paper, we >> first have staves and then add measure). Solution b) has the advantage of >> being closer to the standard MEI focusing on content. This needs to be >> discussed. >> > > It makes sense that when the page hierarchy is flipped, the system > hierarchy gets flipped as well, so that you can encode layout data on > systems too. Though I don't think the same logic applies to staff and > measure so I'd be tempted to go with b), because it would make switching > between a page-based encoding and a "standard" encoding easier. > I think this is the most difficult thing to decide. Your point makes sense and it would indeed make it easier to adopt. Any other opinion on this? Shall we have both options? > > >> >> >> 2) For the positioning, we need to add attributes the elements that can >> have a position. Basically, any element with the @facs. We can solve this >> by making the att.facsimile class member of att.coordinated. This provides >> us with the necessary @ulx, @uly, etc. for specifying the position. We also >> need to specify to which image the position refers to. A simple approach is >> to add a @surface to /page. As mentioned before, all this does not preclude >> to use the standard @facs and facsimile tree scheme at the same time, for >> example if a higher resolution image needs to be added for specific >> elements. We also need to have a @unit in /page and presumably also be able >> to specify if the positioning is absolute or relative. >> > > +1. Those would be good to have around even outside of a page-based > module, I think. > > >> >> >> Another point to be discussed it if we want to keep this in the score >> subtree or if such encoding could be put into another subtree. One option >> would be a /pages element at the same level of /parts and /score. In other >> word, this would be a third representation option in MEI. >> >> >> > Yes, I'd keep it in a different subtree, so that content can be linked in > the same file if necessary. > I agree. I do it for the next version of the customization. > > In general: I see why this approach to encoding is useful, though if we > make it part of MEI, we should make quite clear when it's ok to encode in > page-based fashion and when it's not. Basically we should discourage this > approach unless it's required for specific (scholarly, justifiable) > reasons. > Agree too. I am sure people won't use it unless necessary ;-) Laurent > > Raf > > > >> I already made a customization for unmeasured music and I am willing to >> do one for measured music for option a) or b) and when we agree where to >> put it. The sample file attached for unmeasured music was generated from >> the OMR output of Aruspix. >> >> >> Best, >> >> 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 > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From esfield at stanford.edu Tue Nov 5 03:14:06 2013 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Mon, 4 Nov 2013 18:14:06 -0800 (PST) Subject: [MEI-L] Page-based encoding In-Reply-To: References: <4727_1383249182_5272B51D_4727_19_1_CAMyHAnNbRaP2n+Pqf0QbcSk_5WDFkEZhx=PJu4PtxaBcvz2f8Q@mail.gmail.com> Message-ID: Reading this discussion caused me inadvertently to think of a few repertories that might be flipped in other ways: 1. Benedetto Marcello psalm settings based on music from Hebrew liturgy. He attempted to render the music right to left. As you can see, a modern rendering introduces lots of complexity to the process of character formation. 2. Calvinist psalters used in Turkey (current research by a young German colleague), where the nature of the text has features similar to, but not exactly the same as, those in Marcello, such as text underlay in Turkish script. Granted MEI is not likely to be called upon to deal with these kinds of cases in the foreseeable future, but since flippability is under discussion, it may be worth thinking about the general issue of extensibility at every tier-notes, lyrics, staff, system. Best regards, Eleanor Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ +1/ 650 725-9242 From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Saturday, November 02, 2013 12:42 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Page-based encoding Hi Raffaele, Thanks for you comments, more below On Thu, Oct 31, 2013 at 8:52 PM, Raffaele Viglianti wrote: Hi Laurent, thanks for sharing this, a few comments: On Tue, Oct 29, 2013 at 11:02 AM, Laurent Pugin wrote: 1) For the document structure to be encoded, we need to have page and system elements. The content of a score becomes a list of /page. Each /page contains a list of /system. In un-measure music /system contains a list of /staff. In measured music, we can imagine a) /system containing a list of /staff containing a list of /measure (and then /layer), or b) /system containing a list of /measure containing a list of /staff. Solution a) seems more natural to me (if we think how music is written on paper, we first have staves and then add measure). Solution b) has the advantage of being closer to the standard MEI focusing on content. This needs to be discussed. It makes sense that when the page hierarchy is flipped, the system hierarchy gets flipped as well, so that you can encode layout data on systems too. Though I don't think the same logic applies to staff and measure so I'd be tempted to go with b), because it would make switching between a page-based encoding and a "standard" encoding easier. I think this is the most difficult thing to decide. Your point makes sense and it would indeed make it easier to adopt. Any other opinion on this? Shall we have both options? 2) For the positioning, we need to add attributes the elements that can have a position. Basically, any element with the @facs. We can solve this by making the att.facsimile class member of att.coordinated. This provides us with the necessary @ulx, @uly, etc. for specifying the position. We also need to specify to which image the position refers to. A simple approach is to add a @surface to /page. As mentioned before, all this does not preclude to use the standard @facs and facsimile tree scheme at the same time, for example if a higher resolution image needs to be added for specific elements. We also need to have a @unit in /page and presumably also be able to specify if the positioning is absolute or relative. +1. Those would be good to have around even outside of a page-based module, I think. Another point to be discussed it if we want to keep this in the score subtree or if such encoding could be put into another subtree. One option would be a /pages element at the same level of /parts and /score. In other word, this would be a third representation option in MEI. Yes, I'd keep it in a different subtree, so that content can be linked in the same file if necessary. I agree. I do it for the next version of the customization. In general: I see why this approach to encoding is useful, though if we make it part of MEI, we should make quite clear when it's ok to encode in page-based fashion and when it's not. Basically we should discourage this approach unless it's required for specific (scholarly, justifiable) reasons. Agree too. I am sure people won't use it unless necessary ;-) Laurent Raf I already made a customization for unmeasured music and I am willing to do one for measured music for option a) or b) and when we agree where to put it. The sample file attached for unmeasured music was generated from the OMR output of Aruspix. Best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 29183 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Thu Nov 7 21:39:40 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 7 Nov 2013 20:39:40 +0000 Subject: [MEI-L] Music Encoding Conference 2014 Call for Papers Message-ID: Please excuse cross-posting and distribute widely. For the program committee and local organizers, -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ____________________________________________________ You are cordially invited to participate in the Music Encoding Conference, which will be held 21-23 May 2014 (with pre-conference workshops on 20 May) at the University of Virginia in Charlottesville, Virginia, U.S.A. The quest for a coherent and universal system for the digital representation of music notation has been pursued for decades and the recent accomplishments of the Music Encoding Initiative have garnered a great deal of attention in a wide range of music scholarship and in the broader digital humanities. The encoding of symbolic music data opens new research paths to traditional music studies (from editing to analysis) and computational musicology, and constitutes a foundational tool for music bibliography and librarianship. This conference aims to gather specialists in all these areas, to discuss the current state of modeling, generation and use of music encoding, to exchange experiences, and to forge collaborations. Proposals for papers, posters, panel discussions, and pre-conference workshops are encouraged. Suggested topics include, but are not limited to: ? music encoding as a theoretical approach for research ? methodologies for encoding, music editing, description and analysis ? rendering of symbolic music data in audio and graphical forms ? relationships between symbolic music data, encoded text, and facsimile images ? capture, interchange, and re-purposing of music data and metadata ? ontologies, authority files, and linked data in music encoding and description ? additional topics relevant to music encoding, editing, and description The deadline for all submissions is 31 December 2013. PDF or Word-compatible files are preferred. All submissions must include: ? name(s) of author(s) ? title ? abstract ? current or most recent institutional affiliation of author(s) and e-mail address ? proposal type: paper, poster, session, or workshop For paper and poster proposals, abstracts of no more than 1000 words, including relevant bibliographic references, are requested. Please also include a short statement regarding your current interests related to music encoding. Panel session proposals, describing the topic and nature of the session and including short biographies of the participants, must be no longer than 2000 words. Proposals for half- or full-day pre-conference workshops, to be held on May 20th, should include the workshop?s proposed duration, as well as its logistical and technical requirements. All accepted papers, posters, and panel sessions will be included in the conference proceedings, tentatively scheduled to be published by the end of 2014. In accordance with feedback from participants in last year's conference, all activities will take place within a single track. Additional details regarding registration, accommodations, etc. will be announced on the conference webpage (http://music-encoding.org/conference/2014). Important dates: ? 31 December 2013: Deadline for abstract submissions ? 7 February 2014: Notification of acceptance of submissions ? 20 May 2014: Pre-conference workshops ? 21-24 May 2014: Conference ? 31 July 2014: Deadline for submission of full papers for conference proceedings ? December 2014: Publication of conference proceedings If you have any questions, please e-mail conference2014 at music-encoding.org. Program Committee ? Giuliano Di Bacco, Indiana University, chair (Local) Organizers ? Perry Roland, University of Virginia ? Sarah Wells, University of Virginia ? Johannes Kepper, Universit?t Paderborn ? Daniel R?wenstrunk, Universit?t Paderborn From laurent at music.mcgill.ca Fri Nov 8 15:52:39 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Fri, 8 Nov 2013 12:52:39 -0200 Subject: [MEI-L] Page-based encoding In-Reply-To: <5579_1383617670_52785485_5579_167_1_abd0b663.00001bb0.0000006e@CCARH-ADM-2.su.win.stanford.edu> References: <4727_1383249182_5272B51D_4727_19_1_CAMyHAnNbRaP2n+Pqf0QbcSk_5WDFkEZhx=PJu4PtxaBcvz2f8Q@mail.gmail.com> <5579_1383617670_52785485_5579_167_1_abd0b663.00001bb0.0000006e@CCARH-ADM-2.su.win.stanford.edu> Message-ID: Hi Eleanor, This is fascinating example! It is indeed very challenging and would require more thinking. Perry just mentioned to me that TEI has a way to deals with right-to-left writing - not surprisingly. This might be a good place to look at as a starting point. However, I would suggest to make this a separate discussion thread so we do not loose focus. I hope you are OK with this. In the meantime, I have uploaded to the incubator an updated version of the customization with two examples (measured and un-measured). Following Raffaele's comment, I created a separate /pages element for this so we could have a page-based encoding together with a traditional score-based encoding. The example of measured music follows the option b) with staves within measures (i.e., unflipped) that keeps the page-based representation closer to the standard MEI one. We could potentially allow both, but I am not sure how to do this in the customization. We would also certainly need a schematron rule to forbid a mix of them. I am not sure if the ways things are redefined in the customization is appropriate. This goes beyond my knowledge of ODD, sorry about this. However, the example files are valid and it seems to work. https://code.google.com/p/mei-incubator/source/browse/#svn%2Fpage-based Best, Laurent On Tue, Nov 5, 2013 at 12:14 AM, Eleanor Selfridge-Field < esfield at stanford.edu> wrote: > Reading this discussion caused me inadvertently to think of a few > repertories that might be flipped in other ways: > > > > 1. Benedetto Marcello psalm settings based on music from Hebrew > liturgy. He attempted to render the music right to left. As you can see, > a modern rendering introduces lots of complexity to the process of > character formation. > > > > > > 2. Calvinist psalters used in Turkey (current research by a young > German colleague), where the nature of the text has features similar to, > but not exactly the same as, those in Marcello, such as text underlay in > Turkish script. > > > > > > Granted MEI is not likely to be called upon to deal with these kinds of > cases in the foreseeable future, but since flippability is under > discussion, it may be worth thinking about the general issue of > extensibility at every tier?notes, lyrics, staff, system. > > > > Best regards, > > > > Eleanor > > > > > > Eleanor Selfridge-Field > Consulting Professor, Music (and, by courtesy, Symbolic Systems) > Braun Music Center #129 > Stanford University > Stanford, CA 94305-3076, USA > http://www.stanford.edu/~esfield/ +1/ 650 725-9242 > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Laurent Pugin > *Sent:* Saturday, November 02, 2013 12:42 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Page-based encoding > > > > Hi Raffaele, > > > > Thanks for you comments, more below > > > > On Thu, Oct 31, 2013 at 8:52 PM, Raffaele Viglianti < > raffaeleviglianti at gmail.com> wrote: > > Hi Laurent, thanks for sharing this, a few comments: > > > > On Tue, Oct 29, 2013 at 11:02 AM, Laurent Pugin wrote: > > > > > > 1) For the document structure to be encoded, we need to have page and > system elements. The content of a score becomes a list of /page. Each /page > contains a list of /system. In un-measure music /system contains a list of > /staff. In measured music, we can imagine a) /system containing a list of > /staff containing a list of /measure (and then /layer), or b) /system > containing a list of /measure containing a list of /staff. Solution a) > seems more natural to me (if we think how music is written on paper, we > first have staves and then add measure). Solution b) has the advantage of > being closer to the standard MEI focusing on content. This needs to be > discussed. > > > > It makes sense that when the page hierarchy is flipped, the system > hierarchy gets flipped as well, so that you can encode layout data on > systems too. Though I don't think the same logic applies to staff and > measure so I'd be tempted to go with b), because it would make switching > between a page-based encoding and a "standard" encoding easier. > > > > I think this is the most difficult thing to decide. Your point makes sense > and it would indeed make it easier to adopt. Any other opinion on this? > Shall we have both options? > > > > > > > > 2) For the positioning, we need to add attributes the elements that can > have a position. Basically, any element with the @facs. We can solve this > by making the att.facsimile class member of att.coordinated. This provides > us with the necessary @ulx, @uly, etc. for specifying the position. We also > need to specify to which image the position refers to. A simple approach is > to add a @surface to /page. As mentioned before, all this does not preclude > to use the standard @facs and facsimile tree scheme at the same time, for > example if a higher resolution image needs to be added for specific > elements. We also need to have a @unit in /page and presumably also be able > to specify if the positioning is absolute or relative. > > > > +1. Those would be good to have around even outside of a page-based > module, I think. > > > > > > Another point to be discussed it if we want to keep this in the score > subtree or if such encoding could be put into another subtree. One option > would be a /pages element at the same level of /parts and /score. In other > word, this would be a third representation option in MEI. > > > > > > Yes, I'd keep it in a different subtree, so that content can be linked in > the same file if necessary. > > > > I agree. I do it for the next version of the customization. > > > > > > In general: I see why this approach to encoding is useful, though if we > make it part of MEI, we should make quite clear when it's ok to encode in > page-based fashion and when it's not. Basically we should discourage this > approach unless it's required for specific (scholarly, justifiable) > reasons. > > > > Agree too. I am sure people won't use it unless necessary ;-) > > > > Laurent > > > > > > Raf > > > > > > I already made a customization for unmeasured music and I am willing to do > one for measured music for option a) or b) and when we agree where to put > it. The sample file attached for unmeasured music was generated from the > OMR output of Aruspix. > > > > Best, > > 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 > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: -------------- section suivante -------------- Une pi?ce jointe autre que texte a ?t? nettoy?e... Nom: image001.jpg Type: image/jpeg Taille: 29183 octets Desc: non disponible URL: From stadler at edirom.de Tue Nov 19 12:11:44 2013 From: stadler at edirom.de (Peter Stadler) Date: Tue, 19 Nov 2013 12:11:44 +0100 Subject: [MEI-L] Google Code deprecating downloads Message-ID: From January 15, 2014, Google will no longer offer the ability to create new downloads: http://google-opensource.blogspot.de/2013/05/a-change-to-google-code-download-service.html As far as I can see, the MEI schema files (and more?) are served from there, so we should look for another download location and move the files there. One could as well move to GitHub with the whole repository ? Best Peter -- Peter Stadler Carl-Maria-von-Weber-Gesamtausgabe Arbeitsstelle Detmold Gartenstr. 20 D-32756 Detmold Tel. +49 5231 975-665 Fax: +49 5231 975-668 stadler at weber-gesamtausgabe.de www.weber-gesamtausgabe.de -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 455 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From pdr4h at eservices.virginia.edu Tue Nov 19 15:46:57 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 19 Nov 2013 14:46:57 +0000 Subject: [MEI-L] Google Code deprecating downloads In-Reply-To: References: Message-ID: Hi Peter, Thanks for the heads-up. This is a real disappointment. This change in Google's policy makes it difficult to use GoogleCode as the "one-stop" for MEI development and distribution. There has already been some discussion about moving the development of MEI-related tools to github, so it may not be a big jump to move everything there. Still, doesn't github require the use of a tarball for downloadables? Ugh. That places too large a burden on a person of non-developer-type persuasion who just wants to get the PDF of the Guidelines or someone like me who just wants to point to a web-accessible copy of one of the schemas in MEI documents. -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Peter Stadler [stadler at edirom.de] Sent: Tuesday, November 19, 2013 6:11 AM To: Music Encoding Initiative Subject: [MEI-L] Google Code deprecating downloads >From January 15, 2014, Google will no longer offer the ability to create new downloads: http://google-opensource.blogspot.de/2013/05/a-change-to-google-code-download-service.html As far as I can see, the MEI schema files (and more?) are served from there, so we should look for another download location and move the files there. One could as well move to GitHub with the whole repository ? Best Peter -- Peter Stadler Carl-Maria-von-Weber-Gesamtausgabe Arbeitsstelle Detmold Gartenstr. 20 D-32756 Detmold Tel. +49 5231 975-665 Fax: +49 5231 975-668 stadler at weber-gesamtausgabe.de www.weber-gesamtausgabe.de From pdr4h at eservices.virginia.edu Tue Nov 19 16:10:34 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 19 Nov 2013 15:10:34 +0000 Subject: [MEI-L] Google Code deprecating downloads In-Reply-To: References: Message-ID: This is a possible solution -- Comment by bperry... at gmail.com, Aug 13, 2013 The reasoning of eliminating the Downloads totally escapes me. The proposed solution by Google is pretty silly and solves nothing given that you can access files in your repository through direct links to the files - EXACTLY the same way links to the Downloads files works. All that has changed is that maintaining the downloadable files and using direct links to downloadable files is now much less convenient for the project maintainers and there is not a way to get the total download count. So here is a better solution than Google's proposed solution that does not involve using Google Drive AND still keeps the download files in your project repository so they can be easily managed by all the project team. Simply create a "Downloads" directory in your repository. Then create a wiki page for downloading your files. You can then place any files you want to make available in your new "Downloads" directory (which is now part of the Repo). You can add whatever text you want to the wiki "Downloads" page and put in the direct link in your repo to the download file. If you don't know how to get the link, then simply browse your source tree until you get to the file, click on it, then look over on the right and copy the link location for the "View raw file" link. If you are ambitious enough you can even add the SHA1 checksum to the wiki page. You now have a wiki page that allows downloading your files. You can even put links to your wiki "Downloads" wiki page on your Project Summary/Home page or add it as link to your links section on the Summary/Home page. The downside is you have update that wiki page each time you add a file to the "Downloads" directory if you want to provide a direct download link to the file. So there you have it. A way to continue offering Downloads and direct links that keeps the download files with the project, that all project administrators can use, and no messing with Google Drive. --- bill We already have the schemas in the repo, just not the Guidelines PDF, so this could work for us. I just created a "Download Test" page in the Wiki that appears to work fine. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Peter > Stadler > Sent: Tuesday, November 19, 2013 6:12 AM > To: Music Encoding Initiative > Subject: [MEI-L] Google Code deprecating downloads > > From January 15, 2014, Google will no longer offer the ability to create new > downloads: > > http://google-opensource.blogspot.de/2013/05/a-change-to-google-code- > download-service.html > > As far as I can see, the MEI schema files (and more?) are served from there, so > we should look for another download location and move the files there. One > could as well move to GitHub with the whole repository ... > > Best > Peter > > > -- > Peter Stadler > Carl-Maria-von-Weber-Gesamtausgabe > Arbeitsstelle Detmold > Gartenstr. 20 > D-32756 Detmold > Tel. +49 5231 975-665 > Fax: +49 5231 975-668 > stadler at weber-gesamtausgabe.de > www.weber-gesamtausgabe.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hankinson at mail.mcgill.ca Tue Nov 19 16:16:11 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Tue, 19 Nov 2013 15:16:11 +0000 Subject: [MEI-L] Google Code deprecating downloads In-Reply-To: <15826_1384872439_528B79F6_15826_11_1_BBCC497C40D85642B90E9F94FC30343D32B51187@grant1.eservices.virginia.edu> References: <15826_1384872439_528B79F6_15826_11_1_BBCC497C40D85642B90E9F94FC30343D32B51187@grant1.eservices.virginia.edu> Message-ID: <23A807FD-C300-4267-999D-AAE1243EEF06@mail.mcgill.ca> GitHub has ?Releases? which allows you to download a copy of the code in either tar.gz or .zip format. For example, we have a number of releases for Diva.js: https://github.com/DDMAL/diva.js/releases The only issue with this is that it?s a bit hidden, and not very obvious to non-developer types. A possible solution would be to post the ?canonical? link to the released .zip file on the music-encoding website. -Andrew On Nov 19, 2013, at 3:46 PM, Roland, Perry (pdr4h) wrote: > Hi Peter, > > Thanks for the heads-up. This is a real disappointment. This change in Google's policy makes it difficult to use GoogleCode as the "one-stop" for MEI development and distribution. > > There has already been some discussion about moving the development of MEI-related tools to github, so it may not be a big jump to move everything there. Still, doesn't github require the use of a tarball for downloadables? Ugh. That places too large a burden on a person of non-developer-type persuasion who just wants to get the PDF of the Guidelines or someone like me who just wants to point to a web-accessible copy of one of the schemas in MEI documents. > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Peter Stadler [stadler at edirom.de] > Sent: Tuesday, November 19, 2013 6:11 AM > To: Music Encoding Initiative > Subject: [MEI-L] Google Code deprecating downloads > > From January 15, 2014, Google will no longer offer the ability to create new downloads: > > http://google-opensource.blogspot.de/2013/05/a-change-to-google-code-download-service.html > > As far as I can see, the MEI schema files (and more?) are served from there, so we should look for another download location and move the files there. One could as well move to GitHub with the whole repository ? > > Best > Peter > > > -- > Peter Stadler > Carl-Maria-von-Weber-Gesamtausgabe > Arbeitsstelle Detmold > Gartenstr. 20 > D-32756 Detmold > Tel. +49 5231 975-665 > Fax: +49 5231 975-668 > stadler at weber-gesamtausgabe.de > www.weber-gesamtausgabe.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 Tue Nov 19 16:20:06 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 19 Nov 2013 15:20:06 +0000 Subject: [MEI-L] Google Code deprecating downloads In-Reply-To: References: Message-ID: It seems that files inside tags are individually address-able. For example, this statement in the prolog of an MEI instance will allow validation in oXygen - I can also open the Relax file in oXygen without being prompted for my repo login credentials. So, I believe the "crisis" can be averted. I still don't understand the policy shift, though. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry (pdr4h) Sent: Tuesday, November 19, 2013 10:11 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Google Code deprecating downloads This is a possible solution -- Comment by bperry... at gmail.com, Aug 13, 2013 The reasoning of eliminating the Downloads totally escapes me. The proposed solution by Google is pretty silly and solves nothing given that you can access files in your repository through direct links to the files - EXACTLY the same way links to the Downloads files works. All that has changed is that maintaining the downloadable files and using direct links to downloadable files is now much less convenient for the project maintainers and there is not a way to get the total download count. So here is a better solution than Google's proposed solution that does not involve using Google Drive AND still keeps the download files in your project repository so they can be easily managed by all the project team. Simply create a "Downloads" directory in your repository. Then create a wiki page for downloading your files. You can then place any files you want to make available in your new "Downloads" directory (which is now part of the Repo). You can add whatever text you want to the wiki "Downloads" page and put in the direct link in your repo to the download file. If you don't know how to get the link, then simply browse your source tree until you get to the file, click on it, then look over on the right and copy the link location for the "View raw file" link. If you are ambitious enough you can even add the SHA1 checksum to the wiki page. You now have a wiki page that allows downloading your files. You can even put links to your wiki "Downloads" wiki page on your Project Summary/Home page or add it as link to your links section on the Summary/Home page. The downside is you have update that wiki page each time you add a file to the "Downloads" directory if you want to provide a direct download link to the file. So there you have it. A way to continue offering Downloads and direct links that keeps the download files with the project, that all project administrators can use, and no messing with Google Drive. --- bill We already have the schemas in the repo, just not the Guidelines PDF, so this could work for us. I just created a "Download Test" page in the Wiki that appears to work fine. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Peter > Stadler > Sent: Tuesday, November 19, 2013 6:12 AM > To: Music Encoding Initiative > Subject: [MEI-L] Google Code deprecating downloads > > From January 15, 2014, Google will no longer offer the ability to create new > downloads: > > http://google-opensource.blogspot.de/2013/05/a-change-to-google-code- > download-service.html > > As far as I can see, the MEI schema files (and more?) are served from there, so > we should look for another download location and move the files there. One > could as well move to GitHub with the whole repository ... > > Best > Peter > > > -- > Peter Stadler > Carl-Maria-von-Weber-Gesamtausgabe > Arbeitsstelle Detmold > Gartenstr. 20 > D-32756 Detmold > Tel. +49 5231 975-665 > Fax: +49 5231 975-668 > stadler at weber-gesamtausgabe.de > www.weber-gesamtausgabe.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaeleviglianti at gmail.com Tue Nov 19 16:22:43 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 19 Nov 2013 10:22:43 -0500 Subject: [MEI-L] Google Code deprecating downloads In-Reply-To: References: Message-ID: What Andrew said. Also, using GitHub "releases" could give us a consistent way of tracking and distributing MEI releases. Were GitHub to disappear, their releases are nothing more than Git tags, so they could be migrated without too much hassle. Raf On Tue, Nov 19, 2013 at 10:20 AM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > > > It seems that files inside tags are individually address-able. For > example, this statement in the prolog of an MEI instance will allow > validation in oXygen ? > > > > http://music-encoding.googlecode.com/svn/tags/MEI2013_v2.1.0/schemata/mei-all.rng" > type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0 > "?> > > > > I can also open the Relax file in oXygen without being prompted for my > repo login credentials. > > > > So, I believe the ?crisis? can be averted. I still don?t understand the > policy shift, though. > > > > -- > > p. > > > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Roland, Perry (pdr4h) > *Sent:* Tuesday, November 19, 2013 10:11 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Google Code deprecating downloads > > > > This is a possible solution -- > > > > Comment by bperry... at gmail.com, Aug 13, 2013 > > > > The reasoning of eliminating the Downloads totally escapes me. The > proposed solution by Google is pretty silly and solves nothing given that > you can access files in your repository through direct links to the files - > EXACTLY the same way links to the Downloads files works. All that has > changed is that maintaining the downloadable files and using direct links > to downloadable files is now much less convenient for the project > maintainers and there is not a way to get the total download count. > > > > So here is a better solution than Google's proposed solution that does not > involve using Google Drive AND still keeps the download files in your > project repository so they can be easily managed by all the project team. > > > > Simply create a "Downloads" directory in your repository. Then create a > wiki page for downloading your files. You can then place any files you want > to make available in your new "Downloads" directory (which is now part of > the Repo). You can add whatever text you want to the wiki "Downloads" page > and put in the direct link in your repo to the download file. If you don't > know how to get the link, then simply browse your source tree until you get > to the file, click on it, then look over on the right and copy the link > location for the "View raw file" link. If you are ambitious enough you can > even add the SHA1 checksum to the wiki page. > > > > You now have a wiki page that allows downloading your files. You can even > put links to your wiki "Downloads" wiki page on your Project Summary/Home > page or add it as link to your links section on the Summary/Home page. The > downside is you have update that wiki page each time you add a file to the > "Downloads" directory if you want to provide a direct download link to the > file. > > > > So there you have it. A way to continue offering Downloads and direct > links that keeps the download files with the project, that all project > administrators can use, and no messing with Google Drive. > > > > --- bill > > > > We already have the schemas in the repo, just not the Guidelines PDF, so > this could work for us. I just created a ?Download Test? page in the Wiki > that appears to work fine. > > > > -- > > p. > > > > > > > -----Original Message----- > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] > On Behalf Of Peter > > > Stadler > > > Sent: Tuesday, November 19, 2013 6:12 AM > > > To: Music Encoding Initiative > > > Subject: [MEI-L] Google Code deprecating downloads > > > > > > From January 15, 2014, Google will no longer offer the ability to create > new > > > downloads: > > > > > > http://google-opensource.blogspot.de/2013/05/a-change-to-google-code- > > > download-service.html > > > > > > As far as I can see, the MEI schema files (and more?) are served from > there, so > > > we should look for another download location and move the files there. > One > > > could as well move to GitHub with the whole repository ? > > > > > > Best > > > Peter > > > > > > > > > -- > > > Peter Stadler > > > Carl-Maria-von-Weber-Gesamtausgabe > > > Arbeitsstelle Detmold > > > Gartenstr. 20 > > > D-32756 Detmold > > > Tel. +49 5231 975-665 > > > Fax: +49 5231 975-668 > > > stadler at weber-gesamtausgabe.de > > > www.weber-gesamtausgabe.de > > > > _______________________________________________ > 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: From pdr4h at eservices.virginia.edu Tue Nov 19 16:24:06 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 19 Nov 2013 15:24:06 +0000 Subject: [MEI-L] Google Code deprecating downloads In-Reply-To: <23A807FD-C300-4267-999D-AAE1243EEF06@mail.mcgill.ca> References: <15826_1384872439_528B79F6_15826_11_1_BBCC497C40D85642B90E9F94FC30343D32B51187@grant1.eservices.virginia.edu>, <23A807FD-C300-4267-999D-AAE1243EEF06@mail.mcgill.ca> Message-ID: That could work too. Actually, you've hit on my primary objection to github -- it's too cryptic for the non-developers among us, including me. -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sent: Tuesday, November 19, 2013 10:16 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Google Code deprecating downloads GitHub has ?Releases? which allows you to download a copy of the code in either tar.gz or .zip format. For example, we have a number of releases for Diva.js: https://github.com/DDMAL/diva.js/releases The only issue with this is that it?s a bit hidden, and not very obvious to non-developer types. A possible solution would be to post the ?canonical? link to the released .zip file on the music-encoding website. -Andrew On Nov 19, 2013, at 3:46 PM, Roland, Perry (pdr4h) wrote: > Hi Peter, > > Thanks for the heads-up. This is a real disappointment. This change in Google's policy makes it difficult to use GoogleCode as the "one-stop" for MEI development and distribution. > > There has already been some discussion about moving the development of MEI-related tools to github, so it may not be a big jump to move everything there. Still, doesn't github require the use of a tarball for downloadables? Ugh. That places too large a burden on a person of non-developer-type persuasion who just wants to get the PDF of the Guidelines or someone like me who just wants to point to a web-accessible copy of one of the schemas in MEI documents. > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Peter Stadler [stadler at edirom.de] > Sent: Tuesday, November 19, 2013 6:11 AM > To: Music Encoding Initiative > Subject: [MEI-L] Google Code deprecating downloads > > From January 15, 2014, Google will no longer offer the ability to create new downloads: > > http://google-opensource.blogspot.de/2013/05/a-change-to-google-code-download-service.html > > As far as I can see, the MEI schema files (and more?) are served from there, so we should look for another download location and move the files there. One could as well move to GitHub with the whole repository ? > > Best > Peter > > > -- > Peter Stadler > Carl-Maria-von-Weber-Gesamtausgabe > Arbeitsstelle Detmold > Gartenstr. 20 > D-32756 Detmold > Tel. +49 5231 975-665 > Fax: +49 5231 975-668 > stadler at weber-gesamtausgabe.de > www.weber-gesamtausgabe.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 stadler at edirom.de Tue Nov 19 17:38:27 2013 From: stadler at edirom.de (Peter Stadler) Date: Tue, 19 Nov 2013 17:38:27 +0100 Subject: [MEI-L] Google Code deprecating downloads In-Reply-To: References: Message-ID: Am 19.11.2013 um 16:22 schrieb Raffaele Viglianti : > What Andrew said. Also, using GitHub "releases" could give us a consistent way of tracking and distributing MEI releases. Were GitHub to disappear, their releases are nothing more than Git tags, so they could be migrated without too much hassle. Yes and no. When creating a git tag (and pushing it to GitHub) it shows up as a GitHub release. But, you can add additional binaries and a change log that goes ?beyond Git artifacts? [1]. Just wanted to mention though I still prefer that option ? This GoogleCodeWiki hack seems a little bit too hacky to me but we could simply provide downloads directly from music-encoding.org as well. There are currently four files in the downloads section from GoogleCode ? that should be manageable?! As I understand the "Change to Google Code Download Service? it only affects this downloads section, not the repository. Best Peter [1] https://github.com/blog/1547-release-your-software -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 455 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From pdr4h at eservices.virginia.edu Tue Nov 19 18:07:10 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 19 Nov 2013 17:07:10 +0000 Subject: [MEI-L] Google Code deprecating downloads In-Reply-To: References: , Message-ID: We're already providing downloads from music-encoding.org. For individual files, links point a location inside a tag, e.g., http://music-encoding.googlecode.com/svn/tags/MEI2013_v2.1.0/schemata/mei-CMN.rng, but for a "package" of files, links point to files in the download area, e.g., http://music-encoding.googlecode.com/files/MEI2013_v2.1.0.zip. It's the last kind that's going to become problematic. Putting the ZIP file inside the repo and then making it part of a tag makes it accessible. Maintaining the links at music-encoding should be manage-able. -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Peter Stadler [stadler at edirom.de] Sent: Tuesday, November 19, 2013 11:38 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Google Code deprecating downloads Am 19.11.2013 um 16:22 schrieb Raffaele Viglianti : > What Andrew said. Also, using GitHub "releases" could give us a consistent way of tracking and distributing MEI releases. Were GitHub to disappear, their releases are nothing more than Git tags, so they could be migrated without too much hassle. Yes and no. When creating a git tag (and pushing it to GitHub) it shows up as a GitHub release. But, you can add additional binaries and a change log that goes ?beyond Git artifacts? [1]. Just wanted to mention though I still prefer that option ? This GoogleCodeWiki hack seems a little bit too hacky to me but we could simply provide downloads directly from music-encoding.org as well. There are currently four files in the downloads section from GoogleCode ? that should be manageable?! As I understand the "Change to Google Code Download Service? it only affects this downloads section, not the repository. Best Peter [1] https://github.com/blog/1547-release-your-software From andrew.hankinson at mail.mcgill.ca Wed Nov 20 02:30:46 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 20 Nov 2013 01:30:46 +0000 Subject: [MEI-L] Google Code deprecating downloads In-Reply-To: <9824_1384880844_528B9ACC_9824_146_5_BBCC497C40D85642B90E9F94FC30343D32B52340@grant1.eservices.virginia.edu> References: , <9824_1384880844_528B9ACC_9824_146_5_BBCC497C40D85642B90E9F94FC30343D32B52340@grant1.eservices.virginia.edu> Message-ID: <810C65C9-24DA-414C-8CE2-7F593DF3E92E@mail.mcgill.ca> Perry, I hear you about GitHub and non-developer types. There?s a quite a bit of ?lingo? associated with git & GitHub. If we do switch platforms, we must ensure everyone is comfortable with the switch and the changes in lingo. I would voice some opposition to placing the .zip files in the Subversion repository. Since ZIP files are binary files, version control systems (including Git) don?t deal with them very well. They can?t track the changes in these files, so every change to a binary file means that an entirely new copy of the file is tracked by the subversion system. Since the release file is already ~9MB, multiple copies of this file, along with the code, will make the Subversion repository grow pretty quickly. As the repository grows, this will slow down both checking out and committing. I also don?t think this has any inherent advantages. If we want to provide a way to access the releases of MEI without asking people to understand the lingo of any repository platform, there could be nothing clearer than a big ?Download? button on the front page of music-encoding.org, with the files hosted on the project?s web server, rather than in the Google Code repository. On Nov 19, 2013, at 6:07 PM, Roland, Perry (pdr4h) wrote: > We're already providing downloads from music-encoding.org. > > For individual files, links point a location inside a tag, e.g., http://music-encoding.googlecode.com/svn/tags/MEI2013_v2.1.0/schemata/mei-CMN.rng, but for a "package" of files, links point to files in the download area, e.g., http://music-encoding.googlecode.com/files/MEI2013_v2.1.0.zip. > > It's the last kind that's going to become problematic. Putting the ZIP file inside the repo and then making it part of a tag makes it accessible. Maintaining the links at music-encoding should be manage-able. > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Peter Stadler [stadler at edirom.de] > Sent: Tuesday, November 19, 2013 11:38 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Google Code deprecating downloads > > Am 19.11.2013 um 16:22 schrieb Raffaele Viglianti : > >> What Andrew said. Also, using GitHub "releases" could give us a consistent way of tracking and distributing MEI releases. Were GitHub to disappear, their releases are nothing more than Git tags, so they could be migrated without too much hassle. > Yes and no. When creating a git tag (and pushing it to GitHub) it shows up as a GitHub release. But, you can add additional binaries and a change log that goes ?beyond Git artifacts? [1]. Just wanted to mention though I still prefer that option ? > > This GoogleCodeWiki hack seems a little bit too hacky to me but we could simply provide downloads directly from music-encoding.org as well. There are currently four files in the downloads section from GoogleCode ? that should be manageable?! As I understand the "Change to Google Code Download Service? it only affects this downloads section, not the repository. > > Best > Peter > > > [1] https://github.com/blog/1547-release-your-software > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From andrew.hankinson at gmail.com Tue Nov 26 16:15:33 2013 From: andrew.hankinson at gmail.com (Andrew Hankinson) Date: Tue, 26 Nov 2013 16:15:33 +0100 Subject: [MEI-L] Sibelius MEI Plugin 1.0 Released Message-ID: <72342A88-D998-4167-99E2-B4FBD0AD1094@gmail.com> I?m pleased to announce the release of SibMEI 1.0, a Sibelius to MEI plugin. Currently it only exports to MEI from Sibelius (no import). Special thanks to Micah Walter for his work on it this summer. You can download it from the GitHub ?Releases? page: https://github.com/DuChemin/sibmei/releases To install: ? Download the plugin (either .zip or .tar.gz) ? Quit Sibelius if you have it open ? Place the ?sibmei? folder in your Sibelius plugins folder. See this page for help on how to find this folder on your system: http://www.sibelius.com/download/plugins/index.html?help=install ? Restart Sibelius. The plugin should be available in your Plugins drop down bar. To use, simply choose ?Export to MEI? from your plugins list. If you find any bugs, please help out by filing an issue on the GitHub Bug Tracker: https://github.com/DuChemin/sibmei/issues. The development of this plugin was supported by two organizations: ? The Centre for Interdisciplinary Research in Music Media and Technology (CIRMMT) sponsored the initial development through a visiting research position at the University of Virginia; ? The DuChemin Project, led by Richard Freedman at Haverford College and funded by grants from the NEH and Haverford College, sponsored further development in the summer of 2013. Please let me know if you have any questions or comments. -Andrew From kepper at edirom.de Tue Nov 26 16:19:07 2013 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 26 Nov 2013 16:19:07 +0100 Subject: [MEI-L] Sibelius MEI Plugin 1.0 Released In-Reply-To: <72342A88-D998-4167-99E2-B4FBD0AD1094@gmail.com> References: <72342A88-D998-4167-99E2-B4FBD0AD1094@gmail.com> Message-ID: Hi Andrew, that's great news for MEI ? congratulations to you and your team. I'll definitely have a look at it asap. Best, Johannes Am 26.11.2013 um 16:15 schrieb Andrew Hankinson : > I?m pleased to announce the release of SibMEI 1.0, a Sibelius to MEI plugin. Currently it only exports to MEI from Sibelius (no import). Special thanks to Micah Walter for his work on it this summer. > > You can download it from the GitHub ?Releases? page: https://github.com/DuChemin/sibmei/releases > > To install: > > ? Download the plugin (either .zip or .tar.gz) > ? Quit Sibelius if you have it open > ? Place the ?sibmei? folder in your Sibelius plugins folder. See this page for help on how to find this folder on your system: http://www.sibelius.com/download/plugins/index.html?help=install > ? Restart Sibelius. The plugin should be available in your Plugins drop down bar. > > To use, simply choose ?Export to MEI? from your plugins list. > > If you find any bugs, please help out by filing an issue on the GitHub Bug Tracker: https://github.com/DuChemin/sibmei/issues. > > The development of this plugin was supported by two organizations: > > ? The Centre for Interdisciplinary Research in Music Media and Technology (CIRMMT) sponsored the initial development through a visiting research position at the University of Virginia; > > ? The DuChemin Project, led by Richard Freedman at Haverford College and funded by grants from the NEH and Haverford College, sponsored further development in the summer of 2013. > > Please let me know if you have any questions or comments. > > -Andrew > _______________________________________________ > 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 Nov 26 16:28:10 2013 From: rfreedma at haverford.edu (Richard Freedman) Date: Tue, 26 Nov 2013 10:28:10 -0500 Subject: [MEI-L] Sibelius MEI Plugin 1.0 Released In-Reply-To: References: <72342A88-D998-4167-99E2-B4FBD0AD1094@gmail.com> Message-ID: Just a quick follow-up to Andrew's announcement: Micah Walter's work this past summer was made possible by generous funding from Haverford College's Faculty Research Fund. I am grateful for this support, and also to Andrew for his expert review of Micah's labor. We are using the new plug-in and some other tools as part of the Du Chemin Lost Voices project. Expect to see some announcements about significant improvements to our site in by the start of the new year. All best, Richard -- Richard Freedman John C. Whitehead Professor of Music Haverford College Haverford, PA 19041 610-896-1007 610-896-4902 (fax) http://www.haverford.edu/faculty/rfreedma -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Tue Nov 26 16:38:58 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 26 Nov 2013 15:38:58 +0000 Subject: [MEI-L] Sibelius MEI Plugin 1.0 Released In-Reply-To: References: <72342A88-D998-4167-99E2-B4FBD0AD1094@gmail.com> , Message-ID: I haven't actually put it into action yet because I don't own/use Sibelius, but this is excellent news! I've seen an example of the export and I'm very pleased to say "it validates!" Must ... buy ... Sibelius :-) -- 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 [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Richard Freedman [rfreedma at haverford.edu] Sent: Tuesday, November 26, 2013 10:28 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Sibelius MEI Plugin 1.0 Released Just a quick follow-up to Andrew's announcement: Micah Walter's work this past summer was made possible by generous funding from Haverford College's Faculty Research Fund. I am grateful for this support, and also to Andrew for his expert review of Micah's labor. We are using the new plug-in and some other tools as part of the Du Chemin Lost Voices project. Expect to see some announcements about significant improvements to our site in by the start of the new year. All best, Richard -- Richard Freedman John C. Whitehead Professor of Music Haverford College Haverford, PA 19041 610-896-1007 610-896-4902 (fax) http://www.haverford.edu/faculty/rfreedma -------------- next part -------------- An HTML attachment was scrubbed... URL: From zolaemil at gmail.com Tue Nov 26 17:47:57 2013 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Tue, 26 Nov 2013 17:47:57 +0100 Subject: [MEI-L] Reconstructed parts In-Reply-To: References: <511097838.2262229.1374625509450.JavaMail.root@stanford.edu> <854947E4-F820-4212-B774-3E3624D830B9@haverford.edu> Message-ID: Hi All, Please let me pick up this thread again! I am joining Micah's efforts in the project where we are dealing with reconstructed voices. I may be over-complicating the issue, but my thought was to use *within* the : This way we could also strongly encoded the fact that the "material is supplied by the transcriber or editor in place of text which cannot be read [...] because of physical damage". Or do you think it's too much? And perhaps redundant if type="reconstruction" is added to the element? Any opinion? Thanks Zoltan 2013/7/25 Roland, Perry (pdr4h) > Hi Micah, > > To quote the Guidelines, "@type characterizes the element in some sense, > using any convenient classification scheme or typology." The attributes > @type and @subtype provide a kind of ad hoc extension and restriction > mechanism, so the values can be anything you want. Of course, the downside > is you can't expect others to utilize the same values you've chosen. > There's only one instance where @type is reserved -- on -- > strictly to mimic TEI's use of @type is its element. > > -- > 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 Micah Walter [ > mwalter at haverford.edu] > Sent: Thursday, July 25, 2013 11:18 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Reconstructed parts > > > Another idea: Would be a good way to clarify > the purpose of the reading? Or is @type reserved for another use? > > > -Micah > > > > > > On 24 July 2013, at 09:14, Raffaele Viglianti > wrote: > > > Hi Perry, > > > Good point, your solution makes perfect sense. I'm stuck with the idea > that rdg = another physical source, but there's no need to be this strict, > especially if @source and @resp can distinguish two different uses. So +1 > to app/rdg for Micah's case. > > > Raffaele > > > > On Tue, Jul 23, 2013 at 10:25 PM, Roland, Perry (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > Hello all, > > I believe this situation is addressed in section 12.3 of the TEI > Guidelines, "Using Apparatus Elements in Transcriptions" ( > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCTR) -- > > "It is often desirable to record different transcriptions of one stretch > of text. These variant transcriptions may be grouped within a single app > element. An application may then construct different ?views? of the > transcription by extraction of the appropriate variant readings from the > apparatus elements embedded in the transcription." > > The example provided > > Virginite is grete > > perfectio > > > > > perfectio > un > > perfectiou > n > > > > isn't music, of course, but it's applicable to Micah's question. Because > the elements have no @wit attribute (@source in MEI), they are not > tied to a particular witness/source document. In other words, each of the > readings here is a conjecture/reconstruction by the person identified as > responsible (ES, FJF, and PGR). > > Applying this principle to Micah's example, we arrive at the following MEI > markup -- > > > > > > > > > > > > > > > > > > > > > > Of course, this is only one method. There's nothing wrong with Raffaele's > suggestion. But using in a transcriptional context is simple and > keeps us from inventing more and more elements for smaller and smaller > return. Since MEI permits within , this markup keeps us from > having to repeat , which could lead to processing issues. Of > course, there's no rule that says these different 'views' have to come from > different people, so this markup also addresses Eleanor's example of > multiple reconstructions by the same editor. > > -- > 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 Eleanor > Selfridge-Field [esfield at stanford.edu] > Sent: Tuesday, July 23, 2013 8:25 PM > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Reconstructed parts > > Hi, All, > > Micah is addressing an important need of musicologists, and it touches on > an area that is probably irrelevant to TEI. I'm only perplexed about the > word "choice". This is not about differing opinions. It could incur in a > situation in which the editor proposes two or more realizations of lost > material. (an important court case in France recently addressed this > subject. The new material was understood to constitute new authorship, in > contrast to the 1725 music otherwise present.) > > To be clear, one would have to say "proposed completion/realization." or > something similar. Basso continuo realizations are similarly editorial > creations. In both cases the added material is normally typeset in small > notes, so unambiguous tags may do double duty in the future. > > Best regards, > > Eleanor Selfridge- Field > esfield at stanford.edu > > > > > > > > > xmlns:w="urn:schemas-microsoft-com:office:word" > xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" > xmlns="http://www.w3.org/TR/REC-html40"> > > /* Style Definitions */p.MsoNormal, p.MsoAutoSig, li.MsoNormal, > div.MsoNormal {margin:0cm; margin-bottom:.0001pt;}@page WordSection1 > {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; > mso-header-margin:36.0pt; mso-footer-margin:36.0pt; > mso-paper-source:0;}div.WordSection1 {page:WordSection1;} > > > > > > Eleanor Selfridge-Field > > Consulting Professor, Music (and, by courtesy, Symbolic Systems) > > Braun Music Center #129 > > Stanford University > > Stanford, CA 94305-3076, USA > > http://www.stanford.edu/~esfield/ > > > > > > > > > > > ----- Original Message ----- > From: Raffaele Viglianti > To: Music Encoding Initiative > Sent: Tue, 23 Jul 2013 12:14:26 -0700 (PDT) > Subject: Re: [MEI-L] Reconstructed parts > > Hi Micah, > > The debate around seems to keep going :) As it is defined now, > only deals with editorial "clarifications" of some text on a > source, either by correction, regularization, expansion. > This is in line with the TEI use of and I think it should stay > like this. > > Nonetheless, there seems to be a need for a more generic "alternative" > element, and it might be worth talking about this more and perhaps look at > TEI's (which, btw, is not widely used as far as I know) > http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT. > > For your case, I'd suggest to more simply make full use of and > its attributes. > > > > > > > > > > This encodes strongly, as it were, that there are two different opinions > because of supplied/@resp. And it encodes weakly that they are exclusive > because of staff/@n. I wish there were a way to encode the exclusivity more > strongly, but I don't think there's a way of doing so without tag abuse at > the moment. > > Hope this helps, > Raffaele > > > > > On Tue, Jul 23, 2013 at 2:41 PM, Micah Walter > wrote: > > > Hello, folks, > > > > I have a question about encoding reconstructed parts. The project I'm > > working on contains complete works that are missing entire parts, as two > of > > the parts are contained in a second partbook that is now lost. > > > > Different reconstructions are of course possible, and so I'd like to use > > the tag. Is the following, then, a reasonable encoding? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > Micah Walter > > > > _______________________________________________ > > 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: From pdr4h at eservices.virginia.edu Tue Nov 26 20:14:22 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 26 Nov 2013 19:14:22 +0000 Subject: [MEI-L] Reconstructed parts In-Reply-To: References: <511097838.2262229.1374625509450.JavaMail.root@stanford.edu> <854947E4-F820-4212-B774-3E3624D830B9@haverford.edu> , Message-ID: Hi Zoltan, There's nothing wrong with using within . Not using means you have to rely on the absence of @source on to communicate that the material in the is an editorial conjecture. Either way is acceptable, but using is less ambiguous. Using also provides a method for capturing the evidence for the supplied material; that is, via the @evidence attribute. Using this attribute with one of the suggested values ('internal', 'external', 'conjecture') is more reliable than using more generic attributes; that is, @type (on rdg) and/or @reason (on supplied). In the following example, I used the value 'internal' because the supplied material is derived from the content in the extant parts. Best wishes, -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of K?m?ves Zolt?n [zolaemil at gmail.com] Sent: Tuesday, November 26, 2013 11:47 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Reconstructed parts Hi All, Please let me pick up this thread again! I am joining Micah's efforts in the project where we are dealing with reconstructed voices. I may be over-complicating the issue, but my thought was to use within the : This way we could also strongly encoded the fact that the "material is supplied by the transcriber or editor in place of text which cannot be read [...] because of physical damage". Or do you think it's too much? And perhaps redundant if type="reconstruction" is added to the element? Any opinion? Thanks Zoltan 2013/7/25 Roland, Perry (pdr4h) > Hi Micah, To quote the Guidelines, "@type characterizes the element in some sense, using any convenient classification scheme or typology." The attributes @type and @subtype provide a kind of ad hoc extension and restriction mechanism, so the values can be anything you want. Of course, the downside is you can't expect others to utilize the same values you've chosen. There's only one instance where @type is reserved -- on -- strictly to mimic TEI's use of @type is its element. -- 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 Micah Walter [mwalter at haverford.edu] Sent: Thursday, July 25, 2013 11:18 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Reconstructed parts Another idea: Would be a good way to clarify the purpose of the reading? Or is @type reserved for another use? -Micah On 24 July 2013, at 09:14, Raffaele Viglianti > wrote: Hi Perry, Good point, your solution makes perfect sense. I'm stuck with the idea that rdg = another physical source, but there's no need to be this strict, especially if @source and @resp can distinguish two different uses. So +1 to app/rdg for Micah's case. Raffaele On Tue, Jul 23, 2013 at 10:25 PM, Roland, Perry (pdr4h) > wrote: Hello all, I believe this situation is addressed in section 12.3 of the TEI Guidelines, "Using Apparatus Elements in Transcriptions" (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCTR) -- "It is often desirable to record different transcriptions of one stretch of text. These variant transcriptions may be grouped within a single app element. An application may then construct different ?views? of the transcription by extraction of the appropriate variant readings from the apparatus elements embedded in the transcription." The example provided Virginite is grete perfectio perfectio un perfectiou n isn't music, of course, but it's applicable to Micah's question. Because the elements have no @wit attribute (@source in MEI), they are not tied to a particular witness/source document. In other words, each of the readings here is a conjecture/reconstruction by the person identified as responsible (ES, FJF, and PGR). Applying this principle to Micah's example, we arrive at the following MEI markup -- Of course, this is only one method. There's nothing wrong with Raffaele's suggestion. But using in a transcriptional context is simple and keeps us from inventing more and more elements for smaller and smaller return. Since MEI permits within , this markup keeps us from having to repeat , which could lead to processing issues. Of course, there's no rule that says these different 'views' have to come from different people, so this markup also addresses Eleanor's example of multiple reconstructions by the same editor. -- 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 Eleanor Selfridge-Field [esfield at stanford.edu] Sent: Tuesday, July 23, 2013 8:25 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Reconstructed parts Hi, All, Micah is addressing an important need of musicologists, and it touches on an area that is probably irrelevant to TEI. I'm only perplexed about the word "choice". This is not about differing opinions. It could incur in a situation in which the editor proposes two or more realizations of lost material. (an important court case in France recently addressed this subject. The new material was understood to constitute new authorship, in contrast to the 1725 music otherwise present.) To be clear, one would have to say "proposed completion/realization." or something similar. Basso continuo realizations are similarly editorial creations. In both cases the added material is normally typeset in small notes, so unambiguous tags may do double duty in the future. Best regards, Eleanor Selfridge- Field esfield at stanford.edu /* Style Definitions */p.MsoNormal, p.MsoAutoSig, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt;}@page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;}div.WordSection1 {page:WordSection1;} Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ ----- Original Message ----- From: Raffaele Viglianti > To: Music Encoding Initiative > Sent: Tue, 23 Jul 2013 12:14:26 -0700 (PDT) Subject: Re: [MEI-L] Reconstructed parts Hi Micah, The debate around seems to keep going :) As it is defined now, only deals with editorial "clarifications" of some text on a source, either by correction, regularization, expansion. This is in line with the TEI use of and I think it should stay like this. Nonetheless, there seems to be a need for a more generic "alternative" element, and it might be worth talking about this more and perhaps look at TEI's (which, btw, is not widely used as far as I know) http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT. For your case, I'd suggest to more simply make full use of and its attributes. This encodes strongly, as it were, that there are two different opinions because of supplied/@resp. And it encodes weakly that they are exclusive because of staff/@n. I wish there were a way to encode the exclusivity more strongly, but I don't think there's a way of doing so without tag abuse at the moment. Hope this helps, Raffaele On Tue, Jul 23, 2013 at 2:41 PM, Micah Walter > wrote: > Hello, folks, > > I have a question about encoding reconstructed parts. The project I'm > working on contains complete works that are missing entire parts, as two of > the parts are contained in a second partbook that is now lost. > > Different reconstructions are of course possible, and so I'd like to use > the tag. Is the following, then, a reasonable encoding? > > > > > > > > > > > > > > > > > > > Thanks, > Micah Walter > > _______________________________________________ > 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: From stadler at edirom.de Wed Nov 27 11:02:27 2013 From: stadler at edirom.de (Peter Stadler) Date: Wed, 27 Nov 2013 11:02:27 +0100 Subject: [MEI-L] Fwd: [MUSIC-IR] Public release of MelodyShape, a Library and Tool for Symbolic Melodic Similarity References: Message-ID: Dear all, if you've seen this post yourself please excuse the noise. Anyway, that looks like an interesting tool and it would probably make a good (student) project to add a filter for supporting MEI files natively. (At present *symbolic* means MIDI) Best Peter Anfang der weitergeleiteten Nachricht: > Von: Juli?n Urbano > Betreff: [MUSIC-IR] Public release of MelodyShape, a Library and Tool for Symbolic Melodic Similarity > Datum: 27. November 2013 05:45:02 MEZ > An: MIR mailing list > > Hi all > > I'm very glad to announce the first public release of MelodyShape, a library and tool for Symbolic Melodic Similarity: https://code.google.com/p/melody-shape/ > > This is a public implementation of the algorithms that obtained the best results in the MIREX SMS task in 2010, 2011, 2012 and 2013. > > It is open source and entirely written in Java, so everybody is free to play with it anywhere. > As of now, version 1.0 includes a nice command line tool to try it out quickly with your MIDI files. There is also a user manual in PDF. > As a quick example to see what you can do, here is an excerpt of the help message: > > usage: melodyshape-1.0 -q -c -a [-k ] [-l] [-t ] [-v] [-vv] [-h] > -q path to the query melody or melodies. > -c path to the collection of documents. > -a algorithm to run: > - 2010-domain, 2010-pitchderiv, 2010-shape > - 2011-shape, 2011-pitch, 2011-time > - 2012-shapeh, 2012-shapel, 2012-shapeg, 2012-time, 2012-shapetime > - 2013-shapeh, 2013-time, 2013-shapetime > -k number of documents to retrieve. > -l show results in a single line (omits similarity scores). > -t run a fixed number of threads. > -v verbose, to stderr. > -vv verbose a lot, to stderr. > -h show this help message. > > Hope somebody finds it useful. > Comments and suggestions are most welcome! > > Cheers, > Juli?n > > -- > Juli?n Urbano > Universitat Pompeu Fabra > Roc Boronat, 138 ? Tanger Building, room 55.308 > 08018 Barcelona, Spain > + 34 93 542 2176 > Homepage: http://julian-urbano.info > Twitter: @julian_urbano > > ------------- > List reminder: > ------------- > 0. ISMIR 2014 will take place in Taipei (Taiwan), 27-31 October 2014. The web site of the conference is at http://ismir2014.ismir.net/ > 1. Please do not send HTML documents to the list > 2. Please do not send attachments (pictures, Word, etc.) to the list > 3. Please do not send commercial ads to the list > 4. Reuse of email addresses found on the list for unsolicited mail is forbidden > 5. To unsubscribe, mail to "listserv at ircam.fr" the following text: unsub music-ir or login to http://listes.ircam.fr/ > 6. For assistance, mail to "music-ir-request at listes.ircam.fr". > 7. The archives of the list are at http://listes.ircam.fr/ > 8. The collective web sites of the ISMIR conferences and all past proceedings are at http://www.ismir.net/ > > > > > > > > > > > > > > > > > > -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 455 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From zolaemil at gmail.com Thu Nov 28 10:18:17 2013 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Thu, 28 Nov 2013 10:18:17 +0100 Subject: [MEI-L] Experimental app rendering variants Message-ID: Hello, I realise I haven't posted this here yet, but surely some of you may find the following page and article interesting: meiView is an experimental application I've developed using MEI-to-VexFlow and here is a recently published blog post at MITHabout how it's been done. Best Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Thu Nov 28 10:34:40 2013 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 28 Nov 2013 10:34:40 +0100 Subject: [MEI-L] Experimental app rendering variants In-Reply-To: References: Message-ID: Hi Zoltan, that?s fantastic ? thanks for sharing. I?ll definitely dive deeper into this (as soon as time allows, though). Best regards, Johannes Am 28.11.2013 um 10:18 schrieb K?m?ves Zolt?n : > Hello, > > I realise I haven't posted this here yet, but surely some of you may find the following page and article interesting: > > meiView is an experimental application I've developed using MEI-to-VexFlow and here is a recently published blog post at MITH about how it's been done. > > Best > Zoltan > _______________________________________________ > 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 Sat Nov 30 02:24:26 2013 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Fri, 29 Nov 2013 17:24:26 -0800 (PST) Subject: [MEI-L] Experimental app rendering variants In-Reply-To: References: Message-ID: <599832081.1225717.1385774666084.JavaMail.zimbra@stanford.edu> The sample score looks wonderful. In fact for the display of small discrepancies between sources it is hard to imagine a better interface. Eleanor Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ +1/ 650 725-9242 ----- Original Message ----- From: "K?m?ves Zolt?n" To: "Music Encoding Initiative" Sent: Thursday, November 28, 2013 1:18:17 AM Subject: [MEI-L] Experimental app rendering variants Hello, I realise I haven't posted this here yet, but surely some of you may find the following page and article interesting: meiView is an experimental application I've developed using MEI-to-VexFlow and here is a recently published blog post at MITH about how it's been done. Best Zoltan _______________________________________________ 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: From zolaemil at gmail.com Tue Dec 10 11:33:56 2013 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Tue, 10 Dec 2013 11:33:56 +0100 Subject: [MEI-L] declaring identifiers Message-ID: Dea MEI Experts, In the Guidelines I read the following: *@resp captures information regarding responsibility for some aspect of the text's creation, transcription, editing, or encoding. Its value must point to one or more identifiers declared in the document header.* Could someone explain how I can *declare* an identifier in the header? Or point me to the relevant section in the Guidelines where it is explained? Thanks a lot Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Tue Dec 10 12:11:35 2013 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 10 Dec 2013 12:11:35 +0100 Subject: [MEI-L] declaring identifiers In-Reply-To: References: Message-ID: <7A07FB20-E37E-4E15-9C9D-D581944C8DC9@edirom.de> Hi Zolt?n, in the header, you can do something like: Zolt?n K?m?ves which you can refer to from the body like so: But that is just one example, and many other possibilities wait for your exploration ;-) Best, Johannes Am 10.12.2013 um 11:33 schrieb K?m?ves Zolt?n : > Dea MEI Experts, > > In the Guidelines I read the following: > @resp captures information regarding responsibility for some aspect of the text's creation, transcription, editing, or encoding. Its value must point to one or more identifiers declared in the document header. > > Could someone explain how I can declare an identifier in the header? Or point me to the relevant section in the Guidelines where it is explained? > Thanks a lot > Zoltan > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l Dr. Johannes Kepper BMBF-Projekt "Freisch?tz Digital" Musikwiss. Seminar Detmold / Paderborn Gartenstra?e 20 32756 Detmold Tel. +49 5231 975669 Mail: kepper at edirom.de -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From zolaemil at gmail.com Tue Dec 10 13:26:34 2013 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Tue, 10 Dec 2013 13:26:34 +0100 Subject: [MEI-L] declaring identifiers In-Reply-To: <7A07FB20-E37E-4E15-9C9D-D581944C8DC9@edirom.de> References: <7A07FB20-E37E-4E15-9C9D-D581944C8DC9@edirom.de> Message-ID: Hi Johannes, That's great, so I understand that *declaration* is when the ID is used as the value of an xml:id attribute somewhere in the document. Is this a good definition of "ID declarations"? Zoltan 2013/12/10 Johannes Kepper > Hi Zolt?n, > > in the header, you can do something like: > > > Zolt?n K?m?ves > > > which you can refer to from the body like so: > > > > > > > > > > > But that is just one example, and many other possibilities wait for your > exploration ;-) > > Best, > Johannes > > > > > > > Am 10.12.2013 um 11:33 schrieb K?m?ves Zolt?n : > > > Dea MEI Experts, > > > > In the Guidelines I read the following: > > @resp captures information regarding responsibility for some aspect of > the text's creation, transcription, editing, or encoding. Its value must > point to one or more identifiers declared in the document header. > > > > Could someone explain how I can declare an identifier in the header? Or > point me to the relevant section in the Guidelines where it is explained? > > Thanks a lot > > Zoltan > > _______________________________________________ > > mei-l mailing list > > mei-l at lists.uni-paderborn.de > > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > Dr. Johannes Kepper > BMBF-Projekt "Freisch?tz Digital" > > Musikwiss. Seminar Detmold / Paderborn > Gartenstra?e 20 > 32756 Detmold > > Tel. +49 5231 975669 > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Tue Dec 10 13:39:08 2013 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 10 Dec 2013 13:39:08 +0100 Subject: [MEI-L] declaring identifiers In-Reply-To: References: <7A07FB20-E37E-4E15-9C9D-D581944C8DC9@edirom.de> Message-ID: <683EE2CB-87FF-4A3B-AC85-25EC7256DC24@edirom.de> Hi Zolt?n, that?s precisely the meaning. You declare / assign an ID by using the @xml:id attribute. From hereon, you can refer to this ID using the anyURI data type. As long as you stay in the same file, that results in hash + ID value: "#ZK". (However, you could even point to a different file, in case you wanted to separate music and metadata (or notes and slurs, or?): @resp="../someFolder/header.xml#ZK". But this is certainly quite advanced?) Best, Johannes Am 10.12.2013 um 13:26 schrieb K?m?ves Zolt?n : > Hi Johannes, > > That's great, so I understand that declaration is when the ID is used as the value of an xml:id attribute somewhere in the document. Is this a good definition of "ID declarations"? > > Zoltan > > > 2013/12/10 Johannes Kepper > Hi Zolt?n, > > in the header, you can do something like: > > > Zolt?n K?m?ves > > > which you can refer to from the body like so: > > > > > > > > > > > But that is just one example, and many other possibilities wait for your exploration ;-) > > Best, > Johannes > > > > > > > Am 10.12.2013 um 11:33 schrieb K?m?ves Zolt?n : > > > Dea MEI Experts, > > > > In the Guidelines I read the following: > > @resp captures information regarding responsibility for some aspect of the text's creation, transcription, editing, or encoding. Its value must point to one or more identifiers declared in the document header. > > > > Could someone explain how I can declare an identifier in the header? Or point me to the relevant section in the Guidelines where it is explained? > > Thanks a lot > > Zoltan > > _______________________________________________ > > mei-l mailing list > > mei-l at lists.uni-paderborn.de > > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > Dr. Johannes Kepper > BMBF-Projekt "Freisch?tz Digital" > > Musikwiss. Seminar Detmold / Paderborn > Gartenstra?e 20 > 32756 Detmold > > Tel. +49 5231 975669 > 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 Dr. Johannes Kepper BMBF-Projekt "Freisch?tz Digital" Musikwiss. Seminar Detmold / Paderborn Gartenstra?e 20 32756 Detmold Tel. +49 5231 975669 Mail: kepper at edirom.de -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From zolaemil at gmail.com Tue Dec 10 13:55:33 2013 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Tue, 10 Dec 2013 13:55:33 +0100 Subject: [MEI-L] declaring identifiers In-Reply-To: <683EE2CB-87FF-4A3B-AC85-25EC7256DC24@edirom.de> References: <7A07FB20-E37E-4E15-9C9D-D581944C8DC9@edirom.de> <683EE2CB-87FF-4A3B-AC85-25EC7256DC24@edirom.de> Message-ID: Dear Johannes, thanks a lot for the detailed explanation! Best Zoltan 2013/12/10 Johannes Kepper > Hi Zolt?n, > > that?s precisely the meaning. You declare / assign an ID by using the > @xml:id attribute. From hereon, you can refer to this ID using the anyURI > data type. As long as you stay in the same file, that results in hash + ID > value: "#ZK". > > (However, you could even point to a different file, in case you wanted to > separate music and metadata (or notes and slurs, or?): > @resp="../someFolder/header.xml#ZK". But this is certainly quite advanced?) > > Best, > Johannes > > > > > Am 10.12.2013 um 13:26 schrieb K?m?ves Zolt?n : > > > Hi Johannes, > > > > That's great, so I understand that declaration is when the ID is used as > the value of an xml:id attribute somewhere in the document. Is this a good > definition of "ID declarations"? > > > > Zoltan > > > > > > 2013/12/10 Johannes Kepper > > Hi Zolt?n, > > > > in the header, you can do something like: > > > > > > Zolt?n K?m?ves > > > > > > which you can refer to from the body like so: > > > > > > > > > > > > > > > > > > > > > > But that is just one example, and many other possibilities wait for your > exploration ;-) > > > > Best, > > Johannes > > > > > > > > > > > > > > Am 10.12.2013 um 11:33 schrieb K?m?ves Zolt?n : > > > > > Dea MEI Experts, > > > > > > In the Guidelines I read the following: > > > @resp captures information regarding responsibility for some aspect of > the text's creation, transcription, editing, or encoding. Its value must > point to one or more identifiers declared in the document header. > > > > > > Could someone explain how I can declare an identifier in the header? > Or point me to the relevant section in the Guidelines where it is explained? > > > Thanks a lot > > > Zoltan > > > _______________________________________________ > > > mei-l mailing list > > > mei-l at lists.uni-paderborn.de > > > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > Dr. Johannes Kepper > > BMBF-Projekt "Freisch?tz Digital" > > > > Musikwiss. Seminar Detmold / Paderborn > > Gartenstra?e 20 > > 32756 Detmold > > > > Tel. +49 5231 975669 > > 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 > > Dr. Johannes Kepper > BMBF-Projekt "Freisch?tz Digital" > > Musikwiss. Seminar Detmold / Paderborn > Gartenstra?e 20 > 32756 Detmold > > Tel. +49 5231 975669 > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lxpugin at gmail.com Tue Dec 10 14:25:03 2013 From: lxpugin at gmail.com (Laurent Pugin) Date: Tue, 10 Dec 2013 14:25:03 +0100 Subject: [MEI-L] StaffGrp Message-ID: Hi, I have question regarding the @symbol in staffGrp with the value "brace" (or "bracket"). Does it implies a line to be rendered as well or not? In the examples given in the documentation, most cases with a brace containing all staves, there is usually one single staffGrp (with symbol="brace"), whereas with orchestral score, we usually have one staffGrp with symbol="line" and then sub staffGrps with symbol="brace". http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.pdf http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.xml http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.pdf http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.xml How can we clarify this? Should we allow something like "braceWithLine" as possible value? Best, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent at music.mcgill.ca Tue Dec 10 14:31:30 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Tue, 10 Dec 2013 14:31:30 +0100 Subject: [MEI-L] StaffGrp Message-ID: Hi, I have question regarding the @symbol in staffGrp with the value "brace" (or "bracket"). Does it implies a line to be rendered as well or not? In the examples given in the documentation, most cases with a brace containing all staves, there is usually one single staffGrp (with symbol="brace"), whereas with orchestral score, we usually have one staffGrp with symbol="line" and then sub staffGrps with symbol="brace". http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.pdf http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.xml http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.pdf http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.xml How can we clarify this? Should we allow something like "braceWithLine" as possible value? Best, Laurent -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From andrew.hankinson at mail.mcgill.ca Tue Dec 10 14:45:22 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Tue, 10 Dec 2013 13:45:22 +0000 Subject: [MEI-L] StaffGrp In-Reply-To: <16687_1386681934_52A7164E_16687_160_1_CAJ306Hb49Y8BQowfxxGTK918tbGkT1oJ0cThSxM7_u3r8W1v5Q@mail.gmail.com> References: <16687_1386681934_52A7164E_16687_160_1_CAJ306Hb49Y8BQowfxxGTK918tbGkT1oJ0cThSxM7_u3r8W1v5Q@mail.gmail.com> Message-ID: <608F1E2B-0656-4398-B913-0458FCD4ACC7@mail.mcgill.ca> Hi Laurent, If you have an inner group with @symbol=line and an outer one with @symbol=brace it?s pretty unambiguous. Are you thinking braceWithLine just to eliminate one level of hierarchy? -Andrew On Dec 10, 2013, at 8:25 AM, Laurent Pugin > wrote: Hi, I have question regarding the @symbol in staffGrp with the value "brace" (or "bracket"). Does it implies a line to be rendered as well or not? In the examples given in the documentation, most cases with a brace containing all staves, there is usually one single staffGrp (with symbol="brace"), whereas with orchestral score, we usually have one staffGrp with symbol="line" and then sub staffGrps with symbol="brace". http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.pdf http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.xml http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.pdf http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.xml How can we clarify this? Should we allow something like "braceWithLine" as possible value? Best, Laurent _______________________________________________ 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: From laurent at music.mcgill.ca Tue Dec 10 15:09:35 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Tue, 10 Dec 2013 15:09:35 +0100 Subject: [MEI-L] StaffGrp In-Reply-To: <25600_1386683132_52A71AFC_25600_25_1_608F1E2B-0656-4398-B913-0458FCD4ACC7@mail.mcgill.ca> References: <16687_1386681934_52A7164E_16687_160_1_CAJ306Hb49Y8BQowfxxGTK918tbGkT1oJ0cThSxM7_u3r8W1v5Q@mail.gmail.com> <25600_1386683132_52A71AFC_25600_25_1_608F1E2B-0656-4398-B913-0458FCD4ACC7@mail.mcgill.ca> Message-ID: I was wondering what to expect with the examples where we have only one level with @symbol=brace. As you are saying, this seems ambiguous because I am pretty sure we would expect this to represent a brace and a line. So the proposal of braceWithLine is to eliminate the ambiguity if we don't want to have two levels. I am fine with two levels too. Laurent On Tue, Dec 10, 2013 at 2:45 PM, Andrew Hankinson < andrew.hankinson at mail.mcgill.ca> wrote: > Hi Laurent, > > If you have an inner group with @symbol=line and an outer one with > @symbol=brace it?s pretty unambiguous. Are you thinking braceWithLine just > to eliminate one level of hierarchy? > > -Andrew > > On Dec 10, 2013, at 8:25 AM, Laurent Pugin wrote: > > Hi, > > I have question regarding the @symbol in staffGrp with the value "brace" > (or "bracket"). Does it implies a line to be rendered as well or not? > > In the examples given in the documentation, most cases with a brace > containing all staves, there is usually one single staffGrp (with > symbol="brace"), whereas with orchestral score, we usually have one > staffGrp with symbol="line" and then sub staffGrps with symbol="brace". > > > http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.pdf > > http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.xml > > > http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.pdf > > http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.xml > > How can we clarify this? Should we allow something like "braceWithLine" > as possible value? > > Best, > 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 > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From kepper at edirom.de Tue Dec 10 15:16:28 2013 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 10 Dec 2013 15:16:28 +0100 Subject: [MEI-L] StaffGrp In-Reply-To: References: <16687_1386681934_52A7164E_16687_160_1_CAJ306Hb49Y8BQowfxxGTK918tbGkT1oJ0cThSxM7_u3r8W1v5Q@mail.gmail.com> <25600_1386683132_52A71AFC_25600_25_1_608F1E2B-0656-4398-B913-0458FCD4ACC7@mail.mcgill.ca> Message-ID: Hi Laurent, thanks for raising this issue. Please keep in mind that we have the possibility of changing the samples when they don't match the recommendations. I'm pretty confident that there are lots of subtle issues hidden both in the spec and in the samples, and we will have to address them whenever we spot one. In this situation, I guess I have a slight preference for the additional attribute value, since logically (whatever that means) there is only one group of staves, denoted by both a line and a brace. Other opinions? Johannes Am 10.12.2013 um 15:09 schrieb Laurent Pugin : > I was wondering what to expect with the examples where we have only one level with @symbol=brace. As you are saying, this seems ambiguous because I am pretty sure we would expect this to represent a brace and a line. So the proposal of braceWithLine is to eliminate the ambiguity if we don't want to have two levels. I am fine with two levels too. > > Laurent > > > On Tue, Dec 10, 2013 at 2:45 PM, Andrew Hankinson wrote: > Hi Laurent, > > If you have an inner group with @symbol=line and an outer one with @symbol=brace it?s pretty unambiguous. Are you thinking braceWithLine just to eliminate one level of hierarchy? > > -Andrew > > On Dec 10, 2013, at 8:25 AM, Laurent Pugin wrote: > >> Hi, >> >> I have question regarding the @symbol in staffGrp with the value "brace" (or "bracket"). Does it implies a line to be rendered as well or not? >> >> In the examples given in the documentation, most cases with a brace containing all staves, there is usually one single staffGrp (with symbol="brace"), whereas with orchestral score, we usually have one staffGrp with symbol="line" and then sub staffGrps with symbol="brace". >> >> http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.pdf >> http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.xml >> >> http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.pdf >> http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.xml >> >> How can we clarify this? Should we allow something like "braceWithLine" as possible value? >> >> Best, >> 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 Dr. Johannes Kepper BMBF-Projekt "Freisch?tz Digital" Musikwiss. Seminar Detmold / Paderborn Gartenstra?e 20 32756 Detmold Tel. +49 5231 975669 Mail: kepper at edirom.de -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From pdr4h at eservices.virginia.edu Tue Dec 10 15:21:00 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 10 Dec 2013 14:21:00 +0000 Subject: [MEI-L] StaffGrp In-Reply-To: <608F1E2B-0656-4398-B913-0458FCD4ACC7@mail.mcgill.ca> References: <16687_1386681934_52A7164E_16687_160_1_CAJ306Hb49Y8BQowfxxGTK918tbGkT1oJ0cThSxM7_u3r8W1v5Q@mail.gmail.com>, <608F1E2B-0656-4398-B913-0458FCD4ACC7@mail.mcgill.ca> Message-ID: Hi Laurent, The outermost staffGrp functions as a kind of "root element" for the set of staffGrp definitions. Only it, not the inner ones, should have the @symbol="line" attribute -- this controls whether the score has a line at the left edge of the staves or not. The "inner" staffGrp elements then use @symbol to indicate how the group's staves are connected. With this in mind, *without the outer group, as in the Ahle example, no line should be drawn.* There appears, ahem, to be a coding error in the MEI file. :-) It's a mistake repeated in nearly all the examples for solo keyboard and maybe (I have checked thoroughly) in those for solo voice and keyboard accompaniment. I think there's no easy way to prevent this error, since staffGrp is used for both the outer container and the contained groups. A simple thing that might help would be to create a schematron rule that restricts @symbol="line" to the outer group only. This way, if one were concerned about the connecting line, the only way to get it would be to properly nest the staffGrp elements. 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sent: Tuesday, December 10, 2013 8:45 AM To: Music Encoding Initiative Subject: Re: [MEI-L] StaffGrp Hi Laurent, If you have an inner group with @symbol=line and an outer one with @symbol=brace it?s pretty unambiguous. Are you thinking braceWithLine just to eliminate one level of hierarchy? -Andrew On Dec 10, 2013, at 8:25 AM, Laurent Pugin > wrote: Hi, I have question regarding the @symbol in staffGrp with the value "brace" (or "bracket"). Does it implies a line to be rendered as well or not? In the examples given in the documentation, most cases with a brace containing all staves, there is usually one single staffGrp (with symbol="brace"), whereas with orchestral score, we usually have one staffGrp with symbol="line" and then sub staffGrps with symbol="brace". http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.pdf http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.xml http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.pdf http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.xml How can we clarify this? Should we allow something like "braceWithLine" as possible value? Best, Laurent _______________________________________________ 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: From pdr4h at eservices.virginia.edu Tue Dec 10 15:24:29 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 10 Dec 2013 14:24:29 +0000 Subject: [MEI-L] StaffGrp In-Reply-To: References: <16687_1386681934_52A7164E_16687_160_1_CAJ306Hb49Y8BQowfxxGTK918tbGkT1oJ0cThSxM7_u3r8W1v5Q@mail.gmail.com>, <608F1E2B-0656-4398-B913-0458FCD4ACC7@mail.mcgill.ca>, Message-ID: Sorry, I meant to say that I *have not* checked the sample collection thoroughly for this issue. Johannes is correct -- we have the power to change the examples when they don't match the guidelines. But I'm also not certain that the guidelines are perfectly clear about this issue since they were developed along with the examples. Never fear, though -- we have the power to change the guidelines as well! :-) -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] Sent: Tuesday, December 10, 2013 9:21 AM To: Music Encoding Initiative Subject: Re: [MEI-L] StaffGrp Hi Laurent, The outermost staffGrp functions as a kind of "root element" for the set of staffGrp definitions. Only it, not the inner ones, should have the @symbol="line" attribute -- this controls whether the score has a line at the left edge of the staves or not. The "inner" staffGrp elements then use @symbol to indicate how the group's staves are connected. With this in mind, *without the outer group, as in the Ahle example, no line should be drawn.* There appears, ahem, to be a coding error in the MEI file. :-) It's a mistake repeated in nearly all the examples for solo keyboard and maybe (I have checked thoroughly) in those for solo voice and keyboard accompaniment. I think there's no easy way to prevent this error, since staffGrp is used for both the outer container and the contained groups. A simple thing that might help would be to create a schematron rule that restricts @symbol="line" to the outer group only. This way, if one were concerned about the connecting line, the only way to get it would be to properly nest the staffGrp elements. 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sent: Tuesday, December 10, 2013 8:45 AM To: Music Encoding Initiative Subject: Re: [MEI-L] StaffGrp Hi Laurent, If you have an inner group with @symbol=line and an outer one with @symbol=brace it?s pretty unambiguous. Are you thinking braceWithLine just to eliminate one level of hierarchy? -Andrew On Dec 10, 2013, at 8:25 AM, Laurent Pugin > wrote: Hi, I have question regarding the @symbol in staffGrp with the value "brace" (or "bracket"). Does it implies a line to be rendered as well or not? In the examples given in the documentation, most cases with a brace containing all staves, there is usually one single staffGrp (with symbol="brace"), whereas with orchestral score, we usually have one staffGrp with symbol="line" and then sub staffGrps with symbol="brace". http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.pdf http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.xml http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.pdf http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.xml How can we clarify this? Should we allow something like "braceWithLine" as possible value? Best, Laurent _______________________________________________ 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: From pdr4h at eservices.virginia.edu Tue Dec 10 15:26:26 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 10 Dec 2013 14:26:26 +0000 Subject: [MEI-L] StaffGrp In-Reply-To: References: <16687_1386681934_52A7164E_16687_160_1_CAJ306Hb49Y8BQowfxxGTK918tbGkT1oJ0cThSxM7_u3r8W1v5Q@mail.gmail.com> <25600_1386683132_52A71AFC_25600_25_1_608F1E2B-0656-4398-B913-0458FCD4ACC7@mail.mcgill.ca> , Message-ID: There may be only one group of staves visible on the page, but in MEI there need to be 2 staffGrp elements. That is, if you want to capture the lefthand line connecting the staves. -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Tuesday, December 10, 2013 9:16 AM To: Music Encoding Initiative Subject: Re: [MEI-L] StaffGrp Hi Laurent, thanks for raising this issue. Please keep in mind that we have the possibility of changing the samples when they don't match the recommendations. I'm pretty confident that there are lots of subtle issues hidden both in the spec and in the samples, and we will have to address them whenever we spot one. In this situation, I guess I have a slight preference for the additional attribute value, since logically (whatever that means) there is only one group of staves, denoted by both a line and a brace. Other opinions? Johannes Am 10.12.2013 um 15:09 schrieb Laurent Pugin : > I was wondering what to expect with the examples where we have only one level with @symbol=brace. As you are saying, this seems ambiguous because I am pretty sure we would expect this to represent a brace and a line. So the proposal of braceWithLine is to eliminate the ambiguity if we don't want to have two levels. I am fine with two levels too. > > Laurent > > > On Tue, Dec 10, 2013 at 2:45 PM, Andrew Hankinson wrote: > Hi Laurent, > > If you have an inner group with @symbol=line and an outer one with @symbol=brace it?s pretty unambiguous. Are you thinking braceWithLine just to eliminate one level of hierarchy? > > -Andrew > > On Dec 10, 2013, at 8:25 AM, Laurent Pugin wrote: > >> Hi, >> >> I have question regarding the @symbol in staffGrp with the value "brace" (or "bracket"). Does it implies a line to be rendered as well or not? >> >> In the examples given in the documentation, most cases with a brace containing all staves, there is usually one single staffGrp (with symbol="brace"), whereas with orchestral score, we usually have one staffGrp with symbol="line" and then sub staffGrps with symbol="brace". >> >> http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.pdf >> http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.xml >> >> http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.pdf >> http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.xml >> >> How can we clarify this? Should we allow something like "braceWithLine" as possible value? >> >> Best, >> 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 Dr. Johannes Kepper BMBF-Projekt "Freisch?tz Digital" Musikwiss. Seminar Detmold / Paderborn Gartenstra?e 20 32756 Detmold Tel. +49 5231 975669 Mail: kepper at edirom.de From laurent at music.mcgill.ca Tue Dec 10 15:34:23 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Tue, 10 Dec 2013 15:34:23 +0100 Subject: [MEI-L] StaffGrp In-Reply-To: <23216_1386685272_52A72358_23216_179_3_BBCC497C40D85642B90E9F94FC30343D32B54E72@grant1.eservices.virginia.edu> References: <16687_1386681934_52A7164E_16687_160_1_CAJ306Hb49Y8BQowfxxGTK918tbGkT1oJ0cThSxM7_u3r8W1v5Q@mail.gmail.com> <608F1E2B-0656-4398-B913-0458FCD4ACC7@mail.mcgill.ca> <23216_1386685272_52A72358_23216_179_3_BBCC497C40D85642B90E9F94FC30343D32B54E72@grant1.eservices.virginia.edu> Message-ID: The examples are a great resource, and this is really a small issue! I am fine with either way for fixing it. Laurent On Tue, Dec 10, 2013 at 3:21 PM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > Hi Laurent, > > > > The outermost staffGrp functions as a kind of "root element" for the set > of staffGrp definitions. Only it, not the inner ones, should have the > @symbol="line" attribute -- this controls whether the score has a line at > the left edge of the staves or not. The "inner" staffGrp elements then use > @symbol to indicate how the group's staves are connected. > > > > With this in mind, *without the outer group, as in the Ahle example, no > line should be drawn.* There appears, ahem, to be a coding error in the > MEI file. :-) It's a mistake repeated in nearly all the examples for solo > keyboard and maybe (I have checked thoroughly) in those for solo voice and > keyboard accompaniment. > > > > I think there's no easy way to prevent this error, since staffGrp is used > for both the outer container and the contained groups. A simple thing that > might help would be to create a schematron rule that restricts > @symbol="line" to the outer group only. This way, if one were concerned > about the connecting line, the only way to get it would be to properly nest > the staffGrp elements. > > > > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew > Hankinson [andrew.hankinson at mail.mcgill.ca] > *Sent:* Tuesday, December 10, 2013 8:45 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] StaffGrp > > Hi Laurent, > > If you have an inner group with @symbol=line and an outer one with > @symbol=brace it?s pretty unambiguous. Are you thinking braceWithLine just > to eliminate one level of hierarchy? > > -Andrew > > On Dec 10, 2013, at 8:25 AM, Laurent Pugin wrote: > > Hi, > > I have question regarding the @symbol in staffGrp with the value "brace" > (or "bracket"). Does it implies a line to be rendered as well or not? > > In the examples given in the documentation, most cases with a brace > containing all staves, there is usually one single staffGrp (with > symbol="brace"), whereas with orchestral score, we usually have one > staffGrp with symbol="line" and then sub staffGrps with symbol="brace". > > > http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.pdf > > http://www.music-encoding.org/sampleCollection/encodings/Ahle_Jesu_meines_Herzens_Freud.xml > > > http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.pdf > > http://www.music-encoding.org/sampleCollection/encodings/Hummel_Concerto_for_trumpet.xml > > How can we clarify this? Should we allow something like "braceWithLine" > as possible value? > > Best, > 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 > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From zupftom at googlemail.com Wed Dec 11 13:21:32 2013 From: zupftom at googlemail.com (TW) Date: Wed, 11 Dec 2013 13:21:32 +0100 Subject: [MEI-L] Thin brackets in orchestral scores Message-ID: Laurent's post made me wonder whether we might be missing an additional value for staffGrp/@symbol for the thin bracket that is used for sub-groups in orchestral scores[1]. Looking at some PDFs in the sample collection I didn't see anything like that (I didn't look through all of them). Thomas [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf From laurent at music.mcgill.ca Wed Dec 11 14:39:05 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Wed, 11 Dec 2013 14:39:05 +0100 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: <2437_1386764511_52A858DE_2437_71_1_CAEB1mApuHg2gbKGAAZiS46ObdXa=MVNU1H-v=Fm1wsA=OLr6ww@mail.gmail.com> References: <2437_1386764511_52A858DE_2437_71_1_CAEB1mApuHg2gbKGAAZiS46ObdXa=MVNU1H-v=Fm1wsA=OLr6ww@mail.gmail.com> Message-ID: You are right, I think it is missing. There are actually a few of them in the examples, at least there is this one (however with no representation in the encoding) http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf Laurent On Wed, Dec 11, 2013 at 1:21 PM, TW wrote: > Laurent's post made me wonder whether we might be missing an > additional value for staffGrp/@symbol for the thin bracket that is > used for sub-groups in orchestral scores[1]. Looking at some PDFs in > the sample collection I didn't see anything like that (I didn't look > through all of them). > > Thomas > > > [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From kepper at edirom.de Wed Dec 11 14:47:33 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 11 Dec 2013 14:47:33 +0100 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: References: <2437_1386764511_52A858DE_2437_71_1_CAEB1mApuHg2gbKGAAZiS46ObdXa=MVNU1H-v=Fm1wsA=OLr6ww@mail.gmail.com> Message-ID: The reason why I feel slightly uneasy with this all is that it seems that we seem to enter the land of a music typesetting program here. In my ignorance about such details, I would probably encode that as a line, and ignore the fact that it is connected on both ends. In manuscripts, there would probably be no difference between this and either brackets or lines. But maybe you're right, and we should include the additional value. @Perry, do I remember correctly that you spotted some values in MusicXML not currently supported by MEI anyway? Is this an opportunity to revise them? jo Am 11.12.2013 um 14:39 schrieb Laurent Pugin : > You are right, I think it is missing. > > There are actually a few of them in the examples, at least there is this one (however with no representation in the encoding) > http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf > > Laurent > > > > On Wed, Dec 11, 2013 at 1:21 PM, TW wrote: > Laurent's post made me wonder whether we might be missing an > additional value for staffGrp/@symbol for the thin bracket that is > used for sub-groups in orchestral scores[1]. Looking at some PDFs in > the sample collection I didn't see anything like that (I didn't look > through all of them). > > Thomas > > > [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf > > _______________________________________________ > 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 Dr. Johannes Kepper BMBF-Projekt "Freisch?tz Digital" Musikwiss. Seminar Detmold / Paderborn Gartenstra?e 20 32756 Detmold Tel. +49 5231 975669 Mail: kepper at edirom.de -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From raffaeleviglianti at gmail.com Wed Dec 11 15:20:31 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Wed, 11 Dec 2013 09:20:31 -0500 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: References: <2437_1386764511_52A858DE_2437_71_1_CAEB1mApuHg2gbKGAAZiS46ObdXa=MVNU1H-v=Fm1wsA=OLr6ww@mail.gmail.com> Message-ID: I also feel a bit uneasy about this. Should we not encode what the bracket indicates (a subgroup) rather than the fact that there is a bracket of some sort? Raf On Wed, Dec 11, 2013 at 8:47 AM, Johannes Kepper wrote: > The reason why I feel slightly uneasy with this all is that it seems that > we seem to enter the land of a music typesetting program here. In my > ignorance about such details, I would probably encode that as a line, and > ignore the fact that it is connected on both ends. In manuscripts, there > would probably be no difference between this and either brackets or lines. > But maybe you're right, and we should include the additional value. @Perry, > do I remember correctly that you spotted some values in MusicXML not > currently supported by MEI anyway? Is this an opportunity to revise them? > > jo > > > > Am 11.12.2013 um 14:39 schrieb Laurent Pugin : > > > You are right, I think it is missing. > > > > There are actually a few of them in the examples, at least there is this > one (however with no representation in the encoding) > > > http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf > > > > Laurent > > > > > > > > On Wed, Dec 11, 2013 at 1:21 PM, TW wrote: > > Laurent's post made me wonder whether we might be missing an > > additional value for staffGrp/@symbol for the thin bracket that is > > used for sub-groups in orchestral scores[1]. Looking at some PDFs in > > the sample collection I didn't see anything like that (I didn't look > > through all of them). > > > > Thomas > > > > > > [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf > > > > _______________________________________________ > > 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 > > Dr. Johannes Kepper > BMBF-Projekt "Freisch?tz Digital" > > Musikwiss. Seminar Detmold / Paderborn > Gartenstra?e 20 > 32756 Detmold > > Tel. +49 5231 975669 > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Wed Dec 11 15:25:10 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 11 Dec 2013 15:25:10 +0100 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: References: <2437_1386764511_52A858DE_2437_71_1_CAEB1mApuHg2gbKGAAZiS46ObdXa=MVNU1H-v=Fm1wsA=OLr6ww@mail.gmail.com> Message-ID: <38B51469-F48C-4B9E-ADC0-B17FA9DC86D0@edirom.de> Of course you need to use a nested staffGrp to encode the fact of a subgroup ? otherwise you wouldn't have the means to place a @symbol. So when you plan to encode the graphics, you need to encode the meaning in the first place? Am 11.12.2013 um 15:20 schrieb Raffaele Viglianti : > I also feel a bit uneasy about this. Should we not encode what the bracket indicates (a subgroup) rather than the fact that there is a bracket of some sort? > > Raf > > > On Wed, Dec 11, 2013 at 8:47 AM, Johannes Kepper wrote: > The reason why I feel slightly uneasy with this all is that it seems that we seem to enter the land of a music typesetting program here. In my ignorance about such details, I would probably encode that as a line, and ignore the fact that it is connected on both ends. In manuscripts, there would probably be no difference between this and either brackets or lines. But maybe you're right, and we should include the additional value. @Perry, do I remember correctly that you spotted some values in MusicXML not currently supported by MEI anyway? Is this an opportunity to revise them? > > jo > > > > Am 11.12.2013 um 14:39 schrieb Laurent Pugin : > > > You are right, I think it is missing. > > > > There are actually a few of them in the examples, at least there is this one (however with no representation in the encoding) > > http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf > > > > Laurent > > > > > > > > On Wed, Dec 11, 2013 at 1:21 PM, TW wrote: > > Laurent's post made me wonder whether we might be missing an > > additional value for staffGrp/@symbol for the thin bracket that is > > used for sub-groups in orchestral scores[1]. Looking at some PDFs in > > the sample collection I didn't see anything like that (I didn't look > > through all of them). > > > > Thomas > > > > > > [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf > > > > _______________________________________________ > > 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 > > Dr. Johannes Kepper > BMBF-Projekt "Freisch?tz Digital" > > Musikwiss. Seminar Detmold / Paderborn > Gartenstra?e 20 > 32756 Detmold > > Tel. +49 5231 975669 > 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 -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From pdr4h at eservices.virginia.edu Wed Dec 11 15:58:09 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 11 Dec 2013 14:58:09 +0000 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: References: <2437_1386764511_52A858DE_2437_71_1_CAEB1mApuHg2gbKGAAZiS46ObdXa=MVNU1H-v=Fm1wsA=OLr6ww@mail.gmail.com> , Message-ID: The "land of music typesetting" is always nearby, not unlike a 4th dimension hovering around us and within us. :-) Intellectual content and presentation are always difficult to separate. But try we must. There are already issues in the tracker related to @symbol -- nos. 180 & 182. >From issue #180 -- "The top and bottom components of a bracket can be rendered as curved (similar to Unicode #x1D115) or straight (similar to Unicode #x0005B). The simplest method of dealing with this distinction is to add "bracketsq" (bracket square) to the values allowed by @symbol. "bracket" will continue to be used for the usual, curved musical bracket. The documentation should be edited to make the distinction clear." I won't attempt to reproduce #182 here, but it covers the selection of a value for @symbol that captures a line (often fairly wide) used to group systems instead of a brace or bracket. There's an image in #182 that illustrates various grouping symbols. Neither the so-called square bracket nor the wide-line-grouping-symbol can be encoded using @symbol="line" since that value is already reserved for the line connecting the staves at their left edge. I'm partial to the value "rule", but I'm open to suggestions. I see no harm in adding generic values like this to MEI because they are what I like to call "rendering hints" for the intellectual content -- in this case the staff group. But obviously this mechanism is not optimal for capturing all the visual details of the symbol, such as line width, color, position, etc. I am somewhat trepidatious about going too far down that road, at the end of which MEI becomes a re-definition of SVG. :-) Yes, there are still things to add to MEI. And, yes, this is an opportunity to do so. Now, if there were only more hours in the day ... -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Wednesday, December 11, 2013 8:47 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Thin brackets in orchestral scores The reason why I feel slightly uneasy with this all is that it seems that we seem to enter the land of a music typesetting program here. In my ignorance about such details, I would probably encode that as a line, and ignore the fact that it is connected on both ends. In manuscripts, there would probably be no difference between this and either brackets or lines. But maybe you're right, and we should include the additional value. @Perry, do I remember correctly that you spotted some values in MusicXML not currently supported by MEI anyway? Is this an opportunity to revise them? jo Am 11.12.2013 um 14:39 schrieb Laurent Pugin : > You are right, I think it is missing. > > There are actually a few of them in the examples, at least there is this one (however with no representation in the encoding) > http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf > > Laurent > > > > On Wed, Dec 11, 2013 at 1:21 PM, TW wrote: > Laurent's post made me wonder whether we might be missing an > additional value for staffGrp/@symbol for the thin bracket that is > used for sub-groups in orchestral scores[1]. Looking at some PDFs in > the sample collection I didn't see anything like that (I didn't look > through all of them). > > Thomas > > > [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf > > _______________________________________________ > 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 Dr. Johannes Kepper BMBF-Projekt "Freisch?tz Digital" Musikwiss. Seminar Detmold / Paderborn Gartenstra?e 20 32756 Detmold Tel. +49 5231 975669 Mail: kepper at edirom.de From kepper at edirom.de Wed Dec 11 16:02:52 2013 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 11 Dec 2013 16:02:52 +0100 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: References: <2437_1386764511_52A858DE_2437_71_1_CAEB1mApuHg2gbKGAAZiS46ObdXa=MVNU1H-v=Fm1wsA=OLr6ww@mail.gmail.com> , Message-ID: <823D1ED0-29D1-4F47-A0CA-EB6DBE5AD370@edirom.de> While there is certainly no harm in adding a well-defined set of additional attribute values, the risk I see is that the distinction between these values gets harder every time, eventually watering down their expressiveness in terms of interchange. I'm not saying we're reaching that point here, I'm just saying that we should be careful? Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) : > The "land of music typesetting" is always nearby, not unlike a 4th dimension hovering around us and within us. :-) Intellectual content and presentation are always difficult to separate. But try we must. > > There are already issues in the tracker related to @symbol -- nos. 180 & 182. > > From issue #180 -- "The top and bottom components of a bracket can be rendered as curved (similar to Unicode #x1D115) or straight (similar to Unicode #x0005B). The simplest method of dealing with this distinction is to add "bracketsq" (bracket square) to the values allowed by @symbol. "bracket" will continue to be used for the usual, curved musical bracket. The documentation should be edited to make the distinction clear." > > I won't attempt to reproduce #182 here, but it covers the selection of a value for @symbol that captures a line (often fairly wide) used to group systems instead of a brace or bracket. There's an image in #182 that illustrates various grouping symbols. > > Neither the so-called square bracket nor the wide-line-grouping-symbol can be encoded using @symbol="line" since that value is already reserved for the line connecting the staves at their left edge. I'm partial to the value "rule", but I'm open to suggestions. > > I see no harm in adding generic values like this to MEI because they are what I like to call "rendering hints" for the intellectual content -- in this case the staff group. But obviously this mechanism is not optimal for capturing all the visual details of the symbol, such as line width, color, position, etc. I am somewhat trepidatious about going too far down that road, at the end of which MEI becomes a re-definition of SVG. :-) > > Yes, there are still things to add to MEI. And, yes, this is an opportunity to do so. Now, if there were only more hours in the day ... > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] > Sent: Wednesday, December 11, 2013 8:47 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > The reason why I feel slightly uneasy with this all is that it seems that we seem to enter the land of a music typesetting program here. In my ignorance about such details, I would probably encode that as a line, and ignore the fact that it is connected on both ends. In manuscripts, there would probably be no difference between this and either brackets or lines. But maybe you're right, and we should include the additional value. @Perry, do I remember correctly that you spotted some values in MusicXML not currently supported by MEI anyway? Is this an opportunity to revise them? > > jo > > > > Am 11.12.2013 um 14:39 schrieb Laurent Pugin : > >> You are right, I think it is missing. >> >> There are actually a few of them in the examples, at least there is this one (however with no representation in the encoding) >> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >> >> Laurent >> >> >> >> On Wed, Dec 11, 2013 at 1:21 PM, TW wrote: >> Laurent's post made me wonder whether we might be missing an >> additional value for staffGrp/@symbol for the thin bracket that is >> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >> the sample collection I didn't see anything like that (I didn't look >> through all of them). >> >> Thomas >> >> >> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >> >> _______________________________________________ >> 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 > > Dr. Johannes Kepper > BMBF-Projekt "Freisch?tz Digital" > > Musikwiss. Seminar Detmold / Paderborn > Gartenstra?e 20 > 32756 Detmold > > Tel. +49 5231 975669 > 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 -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From pdr4h at eservices.virginia.edu Wed Dec 11 16:13:25 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 11 Dec 2013 15:13:25 +0000 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: <823D1ED0-29D1-4F47-A0CA-EB6DBE5AD370@edirom.de> References: <2437_1386764511_52A858DE_2437_71_1_CAEB1mApuHg2gbKGAAZiS46ObdXa=MVNU1H-v=Fm1wsA=OLr6ww@mail.gmail.com> , , <823D1ED0-29D1-4F47-A0CA-EB6DBE5AD370@edirom.de> Message-ID: Yes, caution is advised. -- 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 [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Wednesday, December 11, 2013 10:02 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Thin brackets in orchestral scores While there is certainly no harm in adding a well-defined set of additional attribute values, the risk I see is that the distinction between these values gets harder every time, eventually watering down their expressiveness in terms of interchange. I'm not saying we're reaching that point here, I'm just saying that we should be careful? Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) : > The "land of music typesetting" is always nearby, not unlike a 4th dimension hovering around us and within us. :-) Intellectual content and presentation are always difficult to separate. But try we must. > > There are already issues in the tracker related to @symbol -- nos. 180 & 182. > > From issue #180 -- "The top and bottom components of a bracket can be rendered as curved (similar to Unicode #x1D115) or straight (similar to Unicode #x0005B). The simplest method of dealing with this distinction is to add "bracketsq" (bracket square) to the values allowed by @symbol. "bracket" will continue to be used for the usual, curved musical bracket. The documentation should be edited to make the distinction clear." > > I won't attempt to reproduce #182 here, but it covers the selection of a value for @symbol that captures a line (often fairly wide) used to group systems instead of a brace or bracket. There's an image in #182 that illustrates various grouping symbols. > > Neither the so-called square bracket nor the wide-line-grouping-symbol can be encoded using @symbol="line" since that value is already reserved for the line connecting the staves at their left edge. I'm partial to the value "rule", but I'm open to suggestions. > > I see no harm in adding generic values like this to MEI because they are what I like to call "rendering hints" for the intellectual content -- in this case the staff group. But obviously this mechanism is not optimal for capturing all the visual details of the symbol, such as line width, color, position, etc. I am somewhat trepidatious about going too far down that road, at the end of which MEI becomes a re-definition of SVG. :-) > > Yes, there are still things to add to MEI. And, yes, this is an opportunity to do so. Now, if there were only more hours in the day ... > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] > Sent: Wednesday, December 11, 2013 8:47 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > The reason why I feel slightly uneasy with this all is that it seems that we seem to enter the land of a music typesetting program here. In my ignorance about such details, I would probably encode that as a line, and ignore the fact that it is connected on both ends. In manuscripts, there would probably be no difference between this and either brackets or lines. But maybe you're right, and we should include the additional value. @Perry, do I remember correctly that you spotted some values in MusicXML not currently supported by MEI anyway? Is this an opportunity to revise them? > > jo > > > > Am 11.12.2013 um 14:39 schrieb Laurent Pugin : > >> You are right, I think it is missing. >> >> There are actually a few of them in the examples, at least there is this one (however with no representation in the encoding) >> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >> >> Laurent >> >> >> >> On Wed, Dec 11, 2013 at 1:21 PM, TW wrote: >> Laurent's post made me wonder whether we might be missing an >> additional value for staffGrp/@symbol for the thin bracket that is >> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >> the sample collection I didn't see anything like that (I didn't look >> through all of them). >> >> Thomas >> >> >> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >> >> _______________________________________________ >> 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 > > Dr. Johannes Kepper > BMBF-Projekt "Freisch?tz Digital" > > Musikwiss. Seminar Detmold / Paderborn > Gartenstra?e 20 > 32756 Detmold > > Tel. +49 5231 975669 > 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 laurent at music.mcgill.ca Wed Dec 11 18:45:39 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Wed, 11 Dec 2013 18:45:39 +0100 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: <18085_1386774817_52A88120_18085_172_1_BBCC497C40D85642B90E9F94FC30343D32B551E4@grant1.eservices.virginia.edu> References: <2437_1386764511_52A858DE_2437_71_1_CAEB1mApuHg2gbKGAAZiS46ObdXa=MVNU1H-v=Fm1wsA=OLr6ww@mail.gmail.com> <823D1ED0-29D1-4F47-A0CA-EB6DBE5AD370@edirom.de> <18085_1386774817_52A88120_18085_172_1_BBCC497C40D85642B90E9F94FC30343D32B551E4@grant1.eservices.virginia.edu> Message-ID: It seems to me that adding "bracketsq" as a possible value would be an appropriate addition. I don't think this particular case should necessary open up a discussion on what is just typesetting or not. Laurent On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > Yes, caution is advised. > > -- > 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 [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on > behalf of Johannes Kepper [kepper at edirom.de] > Sent: Wednesday, December 11, 2013 10:02 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > While there is certainly no harm in adding a well-defined set of > additional attribute values, the risk I see is that the distinction between > these values gets harder every time, eventually watering down their > expressiveness in terms of interchange. I'm not saying we're reaching that > point here, I'm just saying that we should be careful? > > > > Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) < > pdr4h at eservices.virginia.edu>: > > > The "land of music typesetting" is always nearby, not unlike a 4th > dimension hovering around us and within us. :-) Intellectual content and > presentation are always difficult to separate. But try we must. > > > > There are already issues in the tracker related to @symbol -- nos. 180 & > 182. > > > > From issue #180 -- "The top and bottom components of a bracket can be > rendered as curved (similar to Unicode #x1D115) or straight (similar to > Unicode #x0005B). The simplest method of dealing with this distinction is > to add "bracketsq" (bracket square) to the values allowed by @symbol. > "bracket" will continue to be used for the usual, curved musical bracket. > The documentation should be edited to make the distinction clear." > > > > I won't attempt to reproduce #182 here, but it covers the selection of a > value for @symbol that captures a line (often fairly wide) used to group > systems instead of a brace or bracket. There's an image in #182 that > illustrates various grouping symbols. > > > > Neither the so-called square bracket nor the wide-line-grouping-symbol > can be encoded using @symbol="line" since that value is already reserved > for the line connecting the staves at their left edge. I'm partial to the > value "rule", but I'm open to suggestions. > > > > I see no harm in adding generic values like this to MEI because they are > what I like to call "rendering hints" for the intellectual content -- in > this case the staff group. But obviously this mechanism is not optimal for > capturing all the visual details of the symbol, such as line width, color, > position, etc. I am somewhat trepidatious about going too far down that > road, at the end of which MEI becomes a re-definition of SVG. :-) > > > > Yes, there are still things to add to MEI. And, yes, this is an > opportunity to do so. Now, if there were only more hours in the day ... > > > > -- > > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of > Johannes Kepper [kepper at edirom.de] > > Sent: Wednesday, December 11, 2013 8:47 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > > > The reason why I feel slightly uneasy with this all is that it seems > that we seem to enter the land of a music typesetting program here. In my > ignorance about such details, I would probably encode that as a line, and > ignore the fact that it is connected on both ends. In manuscripts, there > would probably be no difference between this and either brackets or lines. > But maybe you're right, and we should include the additional value. @Perry, > do I remember correctly that you spotted some values in MusicXML not > currently supported by MEI anyway? Is this an opportunity to revise them? > > > > jo > > > > > > > > Am 11.12.2013 um 14:39 schrieb Laurent Pugin : > > > >> You are right, I think it is missing. > >> > >> There are actually a few of them in the examples, at least there is > this one (however with no representation in the encoding) > >> > http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf > >> > >> Laurent > >> > >> > >> > >> On Wed, Dec 11, 2013 at 1:21 PM, TW wrote: > >> Laurent's post made me wonder whether we might be missing an > >> additional value for staffGrp/@symbol for the thin bracket that is > >> used for sub-groups in orchestral scores[1]. Looking at some PDFs in > >> the sample collection I didn't see anything like that (I didn't look > >> through all of them). > >> > >> Thomas > >> > >> > >> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf > >> > >> _______________________________________________ > >> 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 > > > > Dr. Johannes Kepper > > BMBF-Projekt "Freisch?tz Digital" > > > > Musikwiss. Seminar Detmold / Paderborn > > Gartenstra?e 20 > > 32756 Detmold > > > > Tel. +49 5231 975669 > > 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 > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From zolaemil at gmail.com Wed Dec 11 20:06:26 2013 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Wed, 11 Dec 2013 20:06:26 +0100 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: References: <2437_1386764511_52A858DE_2437_71_1_CAEB1mApuHg2gbKGAAZiS46ObdXa=MVNU1H-v=Fm1wsA=OLr6ww@mail.gmail.com> <823D1ED0-29D1-4F47-A0CA-EB6DBE5AD370@edirom.de> <18085_1386774817_52A88120_18085_172_1_BBCC497C40D85642B90E9F94FC30343D32B551E4@grant1.eservices.virginia.edu> Message-ID: Hello, Would you mind to read my crazy thoughts about this issue? I'm just curious what you people think of my thinking. I think the "intellectual content" in this case isn't so much how the connecting symbols look, but the fact that the symbols are *different*. The current values of @symbol already bear some sort of graphical information, I think. The problem arose now, because it seems that the current set of values don't provide a *complete" classification (that is, in some cases there's no value which describes the symbol's graphical shape appropriately). But of course, it's impossible to provide a complete classification without degrading the markup to SVG. If we accept that the intellectual content is the *difference* between the connecting symbols, then the proper separation of the "intellectual content" from it's graphical representation would be to use a set of values something like this: "symbol1", "symbol2", "symbol3", etc. If one wanted to capture more info about their "look and feel", one could use some pointing mechanism to point to a different element that records the graphical info (possibly even pointing to an external SVG...) I know, it's a crazy abstraction. And it may be way too abstract compared to its practical use, and we could be better off adding a handful of carefully defined values. Zoltan 2013/12/11 Laurent Pugin > It seems to me that adding "bracketsq" as a possible value would be an > appropriate addition. I don't think this particular case should necessary > open up a discussion on what is just typesetting or not. > > Laurent > > > On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > >> Yes, caution is advised. >> >> >> -- >> 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 [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on >> behalf of Johannes Kepper [kepper at edirom.de] >> Sent: Wednesday, December 11, 2013 10:02 AM >> >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> While there is certainly no harm in adding a well-defined set of >> additional attribute values, the risk I see is that the distinction between >> these values gets harder every time, eventually watering down their >> expressiveness in terms of interchange. I'm not saying we're reaching that >> point here, I'm just saying that we should be careful? >> >> >> >> Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) < >> pdr4h at eservices.virginia.edu>: >> >> > The "land of music typesetting" is always nearby, not unlike a 4th >> dimension hovering around us and within us. :-) Intellectual content and >> presentation are always difficult to separate. But try we must. >> > >> > There are already issues in the tracker related to @symbol -- nos. 180 >> & 182. >> > >> > From issue #180 -- "The top and bottom components of a bracket can be >> rendered as curved (similar to Unicode #x1D115) or straight (similar to >> Unicode #x0005B). The simplest method of dealing with this distinction is >> to add "bracketsq" (bracket square) to the values allowed by @symbol. >> "bracket" will continue to be used for the usual, curved musical bracket. >> The documentation should be edited to make the distinction clear." >> > >> > I won't attempt to reproduce #182 here, but it covers the selection of >> a value for @symbol that captures a line (often fairly wide) used to group >> systems instead of a brace or bracket. There's an image in #182 that >> illustrates various grouping symbols. >> > >> > Neither the so-called square bracket nor the wide-line-grouping-symbol >> can be encoded using @symbol="line" since that value is already reserved >> for the line connecting the staves at their left edge. I'm partial to the >> value "rule", but I'm open to suggestions. >> > >> > I see no harm in adding generic values like this to MEI because they >> are what I like to call "rendering hints" for the intellectual content -- >> in this case the staff group. But obviously this mechanism is not optimal >> for capturing all the visual details of the symbol, such as line width, >> color, position, etc. I am somewhat trepidatious about going too far down >> that road, at the end of which MEI becomes a re-definition of SVG. :-) >> > >> > Yes, there are still things to add to MEI. And, yes, this is an >> opportunity to do so. Now, if there were only more hours in the day ... >> > >> > -- >> > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of >> Johannes Kepper [kepper at edirom.de] >> > Sent: Wednesday, December 11, 2013 8:47 AM >> > To: Music Encoding Initiative >> > Subject: Re: [MEI-L] Thin brackets in orchestral scores >> > >> > The reason why I feel slightly uneasy with this all is that it seems >> that we seem to enter the land of a music typesetting program here. In my >> ignorance about such details, I would probably encode that as a line, and >> ignore the fact that it is connected on both ends. In manuscripts, there >> would probably be no difference between this and either brackets or lines. >> But maybe you're right, and we should include the additional value. @Perry, >> do I remember correctly that you spotted some values in MusicXML not >> currently supported by MEI anyway? Is this an opportunity to revise them? >> > >> > jo >> > >> > >> > >> > Am 11.12.2013 um 14:39 schrieb Laurent Pugin : >> > >> >> You are right, I think it is missing. >> >> >> >> There are actually a few of them in the examples, at least there is >> this one (however with no representation in the encoding) >> >> >> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >> >> >> >> Laurent >> >> >> >> >> >> >> >> On Wed, Dec 11, 2013 at 1:21 PM, TW wrote: >> >> Laurent's post made me wonder whether we might be missing an >> >> additional value for staffGrp/@symbol for the thin bracket that is >> >> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >> >> the sample collection I didn't see anything like that (I didn't look >> >> through all of them). >> >> >> >> Thomas >> >> >> >> >> >> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >> >> >> >> _______________________________________________ >> >> 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 >> > >> > Dr. Johannes Kepper >> > BMBF-Projekt "Freisch?tz Digital" >> > >> > Musikwiss. Seminar Detmold / Paderborn >> > Gartenstra?e 20 >> > 32756 Detmold >> > >> > Tel. +49 5231 975669 >> > 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 >> >> > > _______________________________________________ > 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: From andrew.hankinson at mail.mcgill.ca Wed Dec 11 20:45:10 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 11 Dec 2013 19:45:10 +0000 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: <18969_1386788828_52A8B7D6_18969_20_6_CAOwwundyOU0p5x-GsDRc-fSUf6fOyeTHj=yjyWx59Nyh0GZxAg@mail.gmail.com> References: <2437_1386764511_52A858DE_2437_71_1_CAEB1mApuHg2gbKGAAZiS46ObdXa=MVNU1H-v=Fm1wsA=OLr6ww@mail.gmail.com> <823D1ED0-29D1-4F47-A0CA-EB6DBE5AD370@edirom.de> <18085_1386774817_52A88120_18085_172_1_BBCC497C40D85642B90E9F94FC30343D32B551E4@grant1.eservices.virginia.edu> <18969_1386788828_52A8B7D6_18969_20_6_CAOwwundyOU0p5x-GsDRc-fSUf6fOyeTHj=yjyWx59Nyh0GZxAg@mail.gmail.com> Message-ID: <493323F7-7B85-4D61-90DE-0E942AEADFE1@mail.mcgill.ca> The intellectual content (?logical domain?) is the groups of staves, not the symbol. On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n > wrote: Hello, Would you mind to read my crazy thoughts about this issue? I'm just curious what you people think of my thinking. I think the "intellectual content" in this case isn't so much how the connecting symbols look, but the fact that the symbols are *different*. The current values of @symbol already bear some sort of graphical information, I think. The problem arose now, because it seems that the current set of values don't provide a *complete" classification (that is, in some cases there's no value which describes the symbol's graphical shape appropriately). But of course, it's impossible to provide a complete classification without degrading the markup to SVG. If we accept that the intellectual content is the *difference* between the connecting symbols, then the proper separation of the "intellectual content" from it's graphical representation would be to use a set of values something like this: "symbol1", "symbol2", "symbol3", etc. If one wanted to capture more info about their "look and feel", one could use some pointing mechanism to point to a different element that records the graphical info (possibly even pointing to an external SVG...) I know, it's a crazy abstraction. And it may be way too abstract compared to its practical use, and we could be better off adding a handful of carefully defined values. Zoltan 2013/12/11 Laurent Pugin > It seems to me that adding "bracketsq" as a possible value would be an appropriate addition. I don't think this particular case should necessary open up a discussion on what is just typesetting or not. Laurent On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) > wrote: Yes, caution is advised. -- 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 [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Wednesday, December 11, 2013 10:02 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Thin brackets in orchestral scores While there is certainly no harm in adding a well-defined set of additional attribute values, the risk I see is that the distinction between these values gets harder every time, eventually watering down their expressiveness in terms of interchange. I'm not saying we're reaching that point here, I'm just saying that we should be careful? Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) >: > The "land of music typesetting" is always nearby, not unlike a 4th dimension hovering around us and within us. :-) Intellectual content and presentation are always difficult to separate. But try we must. > > There are already issues in the tracker related to @symbol -- nos. 180 & 182. > > From issue #180 -- "The top and bottom components of a bracket can be rendered as curved (similar to Unicode #x1D115) or straight (similar to Unicode #x0005B). The simplest method of dealing with this distinction is to add "bracketsq" (bracket square) to the values allowed by @symbol. "bracket" will continue to be used for the usual, curved musical bracket. The documentation should be edited to make the distinction clear." > > I won't attempt to reproduce #182 here, but it covers the selection of a value for @symbol that captures a line (often fairly wide) used to group systems instead of a brace or bracket. There's an image in #182 that illustrates various grouping symbols. > > Neither the so-called square bracket nor the wide-line-grouping-symbol can be encoded using @symbol="line" since that value is already reserved for the line connecting the staves at their left edge. I'm partial to the value "rule", but I'm open to suggestions. > > I see no harm in adding generic values like this to MEI because they are what I like to call "rendering hints" for the intellectual content -- in this case the staff group. But obviously this mechanism is not optimal for capturing all the visual details of the symbol, such as line width, color, position, etc. I am somewhat trepidatious about going too far down that road, at the end of which MEI becomes a re-definition of SVG. :-) > > Yes, there are still things to add to MEI. And, yes, this is an opportunity to do so. Now, if there were only more hours in the day ... > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] > Sent: Wednesday, December 11, 2013 8:47 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > The reason why I feel slightly uneasy with this all is that it seems that we seem to enter the land of a music typesetting program here. In my ignorance about such details, I would probably encode that as a line, and ignore the fact that it is connected on both ends. In manuscripts, there would probably be no difference between this and either brackets or lines. But maybe you're right, and we should include the additional value. @Perry, do I remember correctly that you spotted some values in MusicXML not currently supported by MEI anyway? Is this an opportunity to revise them? > > jo > > > > Am 11.12.2013 um 14:39 schrieb Laurent Pugin >: > >> You are right, I think it is missing. >> >> There are actually a few of them in the examples, at least there is this one (however with no representation in the encoding) >> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >> >> Laurent >> >> >> >> On Wed, Dec 11, 2013 at 1:21 PM, TW > wrote: >> Laurent's post made me wonder whether we might be missing an >> additional value for staffGrp/@symbol for the thin bracket that is >> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >> the sample collection I didn't see anything like that (I didn't look >> through all of them). >> >> Thomas >> >> >> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >> >> _______________________________________________ >> 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 > > Dr. Johannes Kepper > BMBF-Projekt "Freisch?tz Digital" > > Musikwiss. Seminar Detmold / Paderborn > Gartenstra?e 20 > 32756 Detmold > > Tel. +49 5231 975669 > 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 _______________________________________________ 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: From zolaemil at gmail.com Wed Dec 11 23:10:11 2013 From: zolaemil at gmail.com (=?utf-8?Q?Zolt=C3=A1n_K=C5=91m=C3=ADves?=) Date: Wed, 11 Dec 2013 23:10:11 +0100 Subject: [MEI-L] Thin brackets in orchestral scores Message-ID: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> Hi Andrew, The grouping of staves is captured by the staffGrp elements without specifying @symbol. @symbol captures additional information. I talk about this additional content. Zoltan -----Original Message----- From: "Andrew Hankinson" Sent: ?2013.?12.?11. 20:45 To: "Music Encoding Initiative" Subject: Re: [MEI-L] Thin brackets in orchestral scores The intellectual content (?logical domain?) is the groups of staves, not the symbol. On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n wrote: Hello, Would you mind to read my crazy thoughts about this issue? I'm just curious what you people think of my thinking. I think the "intellectual content" in this case isn't so much how the connecting symbols look, but the fact that the symbols are *different*. The current values of @symbol already bear some sort of graphical information, I think. The problem arose now, because it seems that the current set of values don't provide a *complete" classification (that is, in some cases there's no value which describes the symbol's graphical shape appropriately). But of course, it's impossible to provide a complete classification without degrading the markup to SVG. If we accept that the intellectual content is the *difference* between the connecting symbols, then the proper separation of the "intellectual content" from it's graphical representation would be to use a set of values something like this: "symbol1", "symbol2", "symbol3", etc. If one wanted to capture more info about their "look and feel", one could use some pointing mechanism to point to a different element that records the graphical info (possibly even pointing to an external SVG...) I know, it's a crazy abstraction. And it may be way too abstract compared to its practical use, and we could be better off adding a handful of carefully defined values. Zoltan 2013/12/11 Laurent Pugin It seems to me that adding "bracketsq" as a possible value would be an appropriate addition. I don't think this particular case should necessary open up a discussion on what is just typesetting or not. Laurent On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) wrote: Yes, caution is advised. -- 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 [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Wednesday, December 11, 2013 10:02 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Thin brackets in orchestral scores While there is certainly no harm in adding a well-defined set of additional attribute values, the risk I see is that the distinction between these values gets harder every time, eventually watering down their expressiveness in terms of interchange. I'm not saying we're reaching that point here, I'm just saying that we should be careful? Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) : > The "land of music typesetting" is always nearby, not unlike a 4th dimension hovering around us and within us. :-) Intellectual content and presentation are always difficult to separate. But try we must. > > There are already issues in the tracker related to @symbol -- nos. 180 & 182. > > From issue #180 -- "The top and bottom components of a bracket can be rendered as curved (similar to Unicode #x1D115) or straight (similar to Unicode #x0005B). The simplest method of dealing with this distinction is to add "bracketsq" (bracket square) to the values allowed by @symbol. "bracket" will continue to be used for the usual, curved musical bracket. The documentation should be edited to make the distinction clear." > > I won't attempt to reproduce #182 here, but it covers the selection of a value for @symbol that captures a line (often fairly wide) used to group systems instead of a brace or bracket. There's an image in #182 that illustrates various grouping symbols. > > Neither the so-called square bracket nor the wide-line-grouping-symbol can be encoded using @symbol="line" since that value is already reserved for the line connecting the staves at their left edge. I'm partial to the value "rule", but I'm open to suggestions. > > I see no harm in adding generic values like this to MEI because they are what I like to call "rendering hints" for the intellectual content -- in this case the staff group. But obviously this mechanism is not optimal for capturing all the visual details of the symbol, such as line width, color, position, etc. I am somewhat trepidatious about going too far down that road, at the end of which MEI becomes a re-definition of SVG. :-) > > Yes, there are still things to add to MEI. And, yes, this is an opportunity to do so. Now, if there were only more hours in the day ... > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] > Sent: Wednesday, December 11, 2013 8:47 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > The reason why I feel slightly uneasy with this all is that it seems that we seem to enter the land of a music typesetting program here. In my ignorance about such details, I would probably encode that as a line, and ignore the fact that it is connected on both ends. In manuscripts, there would probably be no difference between this and either brackets or lines. But maybe you're right, and we should include the additional value. @Perry, do I remember correctly that you spotted some values in MusicXML not currently supported by MEI anyway? Is this an opportunity to revise them? > > jo > > > > Am 11.12.2013 um 14:39 schrieb Laurent Pugin : > >> You are right, I think it is missing. >> >> There are actually a few of them in the examples, at least there is this one (however with no representation in the encoding) >> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >> >> Laurent >> >> >> >> On Wed, Dec 11, 2013 at 1:21 PM, TW wrote: >> Laurent's post made me wonder whether we might be missing an >> additional value for staffGrp/@symbol for the thin bracket that is >> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >> the sample collection I didn't see anything like that (I didn't look >> through all of them). >> >> Thomas >> >> >> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >> >> _______________________________________________ >> 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 > > Dr. Johannes Kepper > BMBF-Projekt "Freisch?tz Digital" > > Musikwiss. Seminar Detmold / Paderborn > Gartenstra?e 20 > 32756 Detmold > > Tel. +49 5231 975669 > 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 _______________________________________________ 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: From pdr4h at eservices.virginia.edu Wed Dec 11 23:40:52 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 11 Dec 2013 22:40:52 +0000 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> Message-ID: Hi Zoltan, Some elements (but not ) already allow @altsym, which contains a pointer to a element that, in turn, contains instructions on how to "draw" the symbol. This area of the schema has not been exercised much and could therefore use a lot of work. However, I think could be extended to contain SVG, PostScript, etc. Turning to how this would work with , the @altsym attribute doesn't actually belong on . It's the visual characteristics of we're trying to capture, not those of . I believe this is what Andrew's comment was intended to mean. So, instead of , , which can be a child of , should bear @altsym, e.g., Although sometimes it can't be avoided, it's generally bad practice to use attributes to describe other attributes. The usual way to handle this is to "promote" an attribute to element status and then give it its own attributes. That's what is doing. The element, however, still has the @symbol attribute with the same values as when it's used on . In effect, is short-hand for . In other words, as in several places in MEI, it's possible to use attributes for less-detail-oriented encodings (for example, when you don't care what the brace looks like), but use elements when you do. -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Zolt?n K?m?ves [zolaemil at gmail.com] Sent: Wednesday, December 11, 2013 5:10 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Thin brackets in orchestral scores Hi Andrew, The grouping of staves is captured by the staffGrp elements without specifying @symbol. @symbol captures additional information. I talk about this additional content. Zoltan ________________________________ From: Andrew Hankinson Sent: ?2013.?12.?11. 20:45 To: Music Encoding Initiative Subject: Re: [MEI-L] Thin brackets in orchestral scores The intellectual content (?logical domain?) is the groups of staves, not the symbol. On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n > wrote: Hello, Would you mind to read my crazy thoughts about this issue? I'm just curious what you people think of my thinking. I think the "intellectual content" in this case isn't so much how the connecting symbols look, but the fact that the symbols are *different*. The current values of @symbol already bear some sort of graphical information, I think. The problem arose now, because it seems that the current set of values don't provide a *complete" classification (that is, in some cases there's no value which describes the symbol's graphical shape appropriately). But of course, it's impossible to provide a complete classification without degrading the markup to SVG. If we accept that the intellectual content is the *difference* between the connecting symbols, then the proper separation of the "intellectual content" from it's graphical representation would be to use a set of values something like this: "symbol1", "symbol2", "symbol3", etc. If one wanted to capture more info about their "look and feel", one could use some pointing mechanism to point to a different element that records the graphical info (possibly even pointing to an external SVG...) I know, it's a crazy abstraction. And it may be way too abstract compared to its practical use, and we could be better off adding a handful of carefully defined values. Zoltan 2013/12/11 Laurent Pugin > It seems to me that adding "bracketsq" as a possible value would be an appropriate addition. I don't think this particular case should necessary open up a discussion on what is just typesetting or not. Laurent On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) > wrote: Yes, caution is advised. -- 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 [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Wednesday, December 11, 2013 10:02 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Thin brackets in orchestral scores While there is certainly no harm in adding a well-defined set of additional attribute values, the risk I see is that the distinction between these values gets harder every time, eventually watering down their expressiveness in terms of interchange. I'm not saying we're reaching that point here, I'm just saying that we should be careful? Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) >: > The "land of music typesetting" is always nearby, not unlike a 4th dimension hovering around us and within us. :-) Intellectual content and presentation are always difficult to separate. But try we must. > > There are already issues in the tracker related to @symbol -- nos. 180 & 182. > > From issue #180 -- "The top and bottom components of a bracket can be rendered as curved (similar to Unicode #x1D115) or straight (similar to Unicode #x0005B). The simplest method of dealing with this distinction is to add "bracketsq" (bracket square) to the values allowed by @symbol. "bracket" will continue to be used for the usual, curved musical bracket. The documentation should be edited to make the distinction clear." > > I won't attempt to reproduce #182 here, but it covers the selection of a value for @symbol that captures a line (often fairly wide) used to group systems instead of a brace or bracket. There's an image in #182 that illustrates various grouping symbols. > > Neither the so-called square bracket nor the wide-line-grouping-symbol can be encoded using @symbol="line" since that value is already reserved for the line connecting the staves at their left edge. I'm partial to the value "rule", but I'm open to suggestions. > > I see no harm in adding generic values like this to MEI because they are what I like to call "rendering hints" for the intellectual content -- in this case the staff group. But obviously this mechanism is not optimal for capturing all the visual details of the symbol, such as line width, color, position, etc. I am somewhat trepidatious about going too far down that road, at the end of which MEI becomes a re-definition of SVG. :-) > > Yes, there are still things to add to MEI. And, yes, this is an opportunity to do so. Now, if there were only more hours in the day ... > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] > Sent: Wednesday, December 11, 2013 8:47 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > The reason why I feel slightly uneasy with this all is that it seems that we seem to enter the land of a music typesetting program here. In my ignorance about such details, I would probably encode that as a line, and ignore the fact that it is connected on both ends. In manuscripts, there would probably be no difference between this and either brackets or lines. But maybe you're right, and we should include the additional value. @Perry, do I remember correctly that you spotted some values in MusicXML not currently supported by MEI anyway? Is this an opportunity to revise them? > > jo > > > > Am 11.12.2013 um 14:39 schrieb Laurent Pugin >: > >> You are right, I think it is missing. >> >> There are actually a few of them in the examples, at least there is this one (however with no representation in the encoding) >> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >> >> Laurent >> >> >> >> On Wed, Dec 11, 2013 at 1:21 PM, TW > wrote: >> Laurent's post made me wonder whether we might be missing an >> additional value for staffGrp/@symbol for the thin bracket that is >> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >> the sample collection I didn't see anything like that (I didn't look >> through all of them). >> >> Thomas >> >> >> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >> >> _______________________________________________ >> 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 > > Dr. Johannes Kepper > BMBF-Projekt "Freisch?tz Digital" > > Musikwiss. Seminar Detmold / Paderborn > Gartenstra?e 20 > 32756 Detmold > > Tel. +49 5231 975669 > 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 _______________________________________________ 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: From zolaemil at gmail.com Thu Dec 12 10:30:43 2013 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Thu, 12 Dec 2013 10:30:43 +0100 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> Message-ID: Hi Perry, It makes sense to separately encode the visual characteristics in a child element, such as . Forgive me for my ignorance about the existence of this element! However, I contemplate the problem of having too few values for @symbol. Consider the following statement: "there are N different symbols used in the score that connect groups of staves". How would you encode the staff groups if N>=4? Thanks Zoltan 2013/12/11 Roland, Perry (pdr4h) > Hi Zoltan, > > > > Some elements (but not ) already allow @altsym, which contains a > pointer to a element that, in turn, contains instructions on > how to "draw" the symbol. This area of the schema has not been exercised > much and could therefore use a lot of work. However, I think > could be extended to contain SVG, PostScript, etc. > > > > Turning to how this would work with , the @altsym attribute > doesn't actually belong on . It's the visual characteristics of > we're trying to capture, not those of . I believe this > is what Andrew's comment was intended to mean. So, instead of > , , which can be a child of , should bear > @altsym, e.g., > > > > > > > > > > > > > Although sometimes it can't be avoided, it's generally bad practice to use > attributes to describe other attributes. The usual way to handle this is > to "promote" an attribute to element status and then give it its own > attributes. That's what is doing. > > > > The element, however, still has the @symbol attribute with the > same values as when it's used on . In effect, > > > > > > > > is short-hand for > > > > . > > > > In other words, as in several places in MEI, it's possible to use > attributes for less-detail-oriented encodings (for example, when you don't > care what the brace looks like), but use elements when you do. > > > > -- > > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Zolt?n > K?m?ves [zolaemil at gmail.com] > *Sent:* Wednesday, December 11, 2013 5:10 PM > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Thin brackets in orchestral scores > > Hi Andrew, > > The grouping of staves is captured by the staffGrp elements without > specifying @symbol. @symbol captures additional information. I talk about > this additional content. > > Zoltan > ------------------------------ > From: Andrew Hankinson > Sent: 2013.12.11. 20:45 > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > The intellectual content (?logical domain?) is the groups of staves, not > the symbol. > > On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n wrote: > > Hello, > > Would you mind to read my crazy thoughts about this issue? I'm just > curious what you people think of my thinking. > > I think the "intellectual content" in this case isn't so much how the > connecting symbols look, but the fact that the symbols are *different*. > > The current values of @symbol already bear some sort of graphical > information, I think. The problem arose now, because it seems that the > current set of values don't provide a *complete" classification (that is, > in some cases there's no value which describes the symbol's graphical shape > appropriately). But of course, it's impossible to provide a complete > classification without degrading the markup to SVG. > > If we accept that the intellectual content is the *difference* between > the connecting symbols, then the proper separation of the "intellectual > content" from it's graphical representation would be to use a set of values > something like this: > > "symbol1", > "symbol2", > "symbol3", > etc. > > If one wanted to capture more info about their "look and feel", one > could use some pointing mechanism to point to a different element that > records the graphical info (possibly even pointing to an external SVG...) > > I know, it's a crazy abstraction. And it may be way too abstract > compared to its practical use, and we could be better off adding a handful > of carefully defined values. > > Zoltan > > > > > > 2013/12/11 Laurent Pugin > >> It seems to me that adding "bracketsq" as a possible value would be an >> appropriate addition. I don't think this particular case should necessary >> open up a discussion on what is just typesetting or not. >> >> Laurent >> >> >> On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) < >> pdr4h at eservices.virginia.edu> wrote: >> >>> Yes, caution is advised. >>> >>> >>> -- >>> 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 [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] >>> on behalf of Johannes Kepper [kepper at edirom.de] >>> Sent: Wednesday, December 11, 2013 10:02 AM >>> >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> >>> While there is certainly no harm in adding a well-defined set of >>> additional attribute values, the risk I see is that the distinction between >>> these values gets harder every time, eventually watering down their >>> expressiveness in terms of interchange. I'm not saying we're reaching that >>> point here, I'm just saying that we should be careful? >>> >>> >>> >>> Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) < >>> pdr4h at eservices.virginia.edu>: >>> >>> > The "land of music typesetting" is always nearby, not unlike a 4th >>> dimension hovering around us and within us. :-) Intellectual content and >>> presentation are always difficult to separate. But try we must. >>> > >>> > There are already issues in the tracker related to @symbol -- nos. 180 >>> & 182. >>> > >>> > From issue #180 -- "The top and bottom components of a bracket can be >>> rendered as curved (similar to Unicode #x1D115) or straight (similar to >>> Unicode #x0005B). The simplest method of dealing with this distinction is >>> to add "bracketsq" (bracket square) to the values allowed by @symbol. >>> "bracket" will continue to be used for the usual, curved musical bracket. >>> The documentation should be edited to make the distinction clear." >>> > >>> > I won't attempt to reproduce #182 here, but it covers the selection of >>> a value for @symbol that captures a line (often fairly wide) used to group >>> systems instead of a brace or bracket. There's an image in #182 that >>> illustrates various grouping symbols. >>> > >>> > Neither the so-called square bracket nor the wide-line-grouping-symbol >>> can be encoded using @symbol="line" since that value is already reserved >>> for the line connecting the staves at their left edge. I'm partial to the >>> value "rule", but I'm open to suggestions. >>> > >>> > I see no harm in adding generic values like this to MEI because they >>> are what I like to call "rendering hints" for the intellectual content -- >>> in this case the staff group. But obviously this mechanism is not optimal >>> for capturing all the visual details of the symbol, such as line width, >>> color, position, etc. I am somewhat trepidatious about going too far down >>> that road, at the end of which MEI becomes a re-definition of SVG. :-) >>> > >>> > Yes, there are still things to add to MEI. And, yes, this is an >>> opportunity to do so. Now, if there were only more hours in the day ... >>> > >>> > -- >>> > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of >>> Johannes Kepper [kepper at edirom.de] >>> > Sent: Wednesday, December 11, 2013 8:47 AM >>> > To: Music Encoding Initiative >>> > Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> > >>> > The reason why I feel slightly uneasy with this all is that it seems >>> that we seem to enter the land of a music typesetting program here. In my >>> ignorance about such details, I would probably encode that as a line, and >>> ignore the fact that it is connected on both ends. In manuscripts, there >>> would probably be no difference between this and either brackets or lines. >>> But maybe you're right, and we should include the additional value. @Perry, >>> do I remember correctly that you spotted some values in MusicXML not >>> currently supported by MEI anyway? Is this an opportunity to revise them? >>> > >>> > jo >>> > >>> > >>> > >>> > Am 11.12.2013 um 14:39 schrieb Laurent Pugin >> >: >>> > >>> >> You are right, I think it is missing. >>> >> >>> >> There are actually a few of them in the examples, at least there is >>> this one (however with no representation in the encoding) >>> >> >>> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >>> >> >>> >> Laurent >>> >> >>> >> >>> >> >>> >> On Wed, Dec 11, 2013 at 1:21 PM, TW wrote: >>> >> Laurent's post made me wonder whether we might be missing an >>> >> additional value for staffGrp/@symbol for the thin bracket that is >>> >> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >>> >> the sample collection I didn't see anything like that (I didn't look >>> >> through all of them). >>> >> >>> >> Thomas >>> >> >>> >> >>> >> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >>> >> >>> >> _______________________________________________ >>> >> 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 >>> > >>> > Dr. Johannes Kepper >>> > BMBF-Projekt "Freisch?tz Digital" >>> > >>> > Musikwiss. Seminar Detmold / Paderborn >>> > Gartenstra?e 20 >>> > 32756 Detmold >>> > >>> > Tel. +49 5231 975669 >>> > 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 >>> >>> >> >> _______________________________________________ >> 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: From andrew.hankinson at mail.mcgill.ca Thu Dec 12 13:51:53 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Thu, 12 Dec 2013 12:51:53 +0000 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> Message-ID: Hi Zoltan, There is no limit to the number of nested staff groups. However, if you have more than four nested staff groups, each with its own bracket style, your engraver should be fired! :) @symbol is simply meant to indicate that there is a ?generic? bracket, brace, or line present. This is to give a visual hint, but not a visual definition, to any software parsing the MEI file. Do you have any examples of connecting symbols that are not one of these? (Beyond those previously discussed by Laurent?) -Andrew On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n > wrote: Hi Perry, It makes sense to separately encode the visual characteristics in a child element, such as . Forgive me for my ignorance about the existence of this element! However, I contemplate the problem of having too few values for @symbol. Consider the following statement: "there are N different symbols used in the score that connect groups of staves". How would you encode the staff groups if N>=4? Thanks Zoltan 2013/12/11 Roland, Perry (pdr4h) > Hi Zoltan, Some elements (but not ) already allow @altsym, which contains a pointer to a element that, in turn, contains instructions on how to "draw" the symbol. This area of the schema has not been exercised much and could therefore use a lot of work. However, I think could be extended to contain SVG, PostScript, etc. Turning to how this would work with , the @altsym attribute doesn't actually belong on . It's the visual characteristics of we're trying to capture, not those of . I believe this is what Andrew's comment was intended to mean. So, instead of , , which can be a child of , should bear @altsym, e.g., Although sometimes it can't be avoided, it's generally bad practice to use attributes to describe other attributes. The usual way to handle this is to "promote" an attribute to element status and then give it its own attributes. That's what is doing. The element, however, still has the @symbol attribute with the same values as when it's used on . In effect, is short-hand for . In other words, as in several places in MEI, it's possible to use attributes for less-detail-oriented encodings (for example, when you don't care what the brace looks like), but use elements when you do. -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Zolt?n K?m?ves [zolaemil at gmail.com] Sent: Wednesday, December 11, 2013 5:10 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Thin brackets in orchestral scores Hi Andrew, The grouping of staves is captured by the staffGrp elements without specifying @symbol. @symbol captures additional information. I talk about this additional content. Zoltan ________________________________ From: Andrew Hankinson Sent: 2013.12.11. 20:45 To: Music Encoding Initiative Subject: Re: [MEI-L] Thin brackets in orchestral scores The intellectual content (?logical domain?) is the groups of staves, not the symbol. On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n > wrote: Hello, Would you mind to read my crazy thoughts about this issue? I'm just curious what you people think of my thinking. I think the "intellectual content" in this case isn't so much how the connecting symbols look, but the fact that the symbols are *different*. The current values of @symbol already bear some sort of graphical information, I think. The problem arose now, because it seems that the current set of values don't provide a *complete" classification (that is, in some cases there's no value which describes the symbol's graphical shape appropriately). But of course, it's impossible to provide a complete classification without degrading the markup to SVG. If we accept that the intellectual content is the *difference* between the connecting symbols, then the proper separation of the "intellectual content" from it's graphical representation would be to use a set of values something like this: "symbol1", "symbol2", "symbol3", etc. If one wanted to capture more info about their "look and feel", one could use some pointing mechanism to point to a different element that records the graphical info (possibly even pointing to an external SVG...) I know, it's a crazy abstraction. And it may be way too abstract compared to its practical use, and we could be better off adding a handful of carefully defined values. Zoltan 2013/12/11 Laurent Pugin > It seems to me that adding "bracketsq" as a possible value would be an appropriate addition. I don't think this particular case should necessary open up a discussion on what is just typesetting or not. Laurent On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) > wrote: Yes, caution is advised. -- 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 [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Wednesday, December 11, 2013 10:02 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Thin brackets in orchestral scores While there is certainly no harm in adding a well-defined set of additional attribute values, the risk I see is that the distinction between these values gets harder every time, eventually watering down their expressiveness in terms of interchange. I'm not saying we're reaching that point here, I'm just saying that we should be careful? Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) >: > The "land of music typesetting" is always nearby, not unlike a 4th dimension hovering around us and within us. :-) Intellectual content and presentation are always difficult to separate. But try we must. > > There are already issues in the tracker related to @symbol -- nos. 180 & 182. > > From issue #180 -- "The top and bottom components of a bracket can be rendered as curved (similar to Unicode #x1D115) or straight (similar to Unicode #x0005B). The simplest method of dealing with this distinction is to add "bracketsq" (bracket square) to the values allowed by @symbol. "bracket" will continue to be used for the usual, curved musical bracket. The documentation should be edited to make the distinction clear." > > I won't attempt to reproduce #182 here, but it covers the selection of a value for @symbol that captures a line (often fairly wide) used to group systems instead of a brace or bracket. There's an image in #182 that illustrates various grouping symbols. > > Neither the so-called square bracket nor the wide-line-grouping-symbol can be encoded using @symbol="line" since that value is already reserved for the line connecting the staves at their left edge. I'm partial to the value "rule", but I'm open to suggestions. > > I see no harm in adding generic values like this to MEI because they are what I like to call "rendering hints" for the intellectual content -- in this case the staff group. But obviously this mechanism is not optimal for capturing all the visual details of the symbol, such as line width, color, position, etc. I am somewhat trepidatious about going too far down that road, at the end of which MEI becomes a re-definition of SVG. :-) > > Yes, there are still things to add to MEI. And, yes, this is an opportunity to do so. Now, if there were only more hours in the day ... > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] > Sent: Wednesday, December 11, 2013 8:47 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > The reason why I feel slightly uneasy with this all is that it seems that we seem to enter the land of a music typesetting program here. In my ignorance about such details, I would probably encode that as a line, and ignore the fact that it is connected on both ends. In manuscripts, there would probably be no difference between this and either brackets or lines. But maybe you're right, and we should include the additional value. @Perry, do I remember correctly that you spotted some values in MusicXML not currently supported by MEI anyway? Is this an opportunity to revise them? > > jo > > > > Am 11.12.2013 um 14:39 schrieb Laurent Pugin >: > >> You are right, I think it is missing. >> >> There are actually a few of them in the examples, at least there is this one (however with no representation in the encoding) >> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >> >> Laurent >> >> >> >> On Wed, Dec 11, 2013 at 1:21 PM, TW > wrote: >> Laurent's post made me wonder whether we might be missing an >> additional value for staffGrp/@symbol for the thin bracket that is >> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >> the sample collection I didn't see anything like that (I didn't look >> through all of them). >> >> Thomas >> >> >> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >> >> _______________________________________________ >> 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 > > Dr. Johannes Kepper > BMBF-Projekt "Freisch?tz Digital" > > Musikwiss. Seminar Detmold / Paderborn > Gartenstra?e 20 > 32756 Detmold > > Tel. +49 5231 975669 > 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 _______________________________________________ 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: From donbyrd at indiana.edu Thu Dec 12 19:21:30 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Thu, 12 Dec 2013 13:21:30 -0500 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> Message-ID: <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> Leaving aside nesting and details like thinness, as far as I know, the _only_ symbols ever used to connect staves or groups of staves in CWMN are (1) curly braces, (2) square brackets, and (3) a thin line -- the last being used only to connect all the staves of a system. If there are others, I'd love to see an example. --Don On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson wrote: > Hi Zoltan, > > There is no limit to the number of nested staff groups. However, if > you have more than four nested staff groups, each with its own > bracket style, your engraver should be fired! :) > > @symbol is simply meant to indicate that there is a ?generic? > bracket, brace, or line present. This is to give a visual hint, but > not a visual definition, to any software parsing the MEI file. Do you > have any examples of connecting symbols that are not one of these? > (Beyond those previously discussed by Laurent?) > > -Andrew > > On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n > > wrote: > > Hi Perry, > > It makes sense to separately encode the visual characteristics in a > child element, such as . Forgive me for my ignorance about > the existence of this element! > > However, I contemplate the problem of having too few values for @symbol. > > Consider the following statement: "there are N different symbols used > in the score that connect groups of staves". How would you encode the > staff groups if N>=4? > > Thanks > Zoltan > > > 2013/12/11 Roland, Perry (pdr4h) > > > > Hi Zoltan, > > > > Some elements (but not ) already allow @altsym, which > contains a pointer to a element that, in turn, contains > instructions on how to "draw" the symbol. This area of the schema > has not been exercised much and could therefore use a lot of work. > However, I think could be extended to contain SVG, > PostScript, etc. > > > > Turning to how this would work with , the @altsym attribute > doesn't actually belong on . It's the visual > characteristics of we're trying to capture, not those of > . I believe this is what Andrew's comment was intended to > mean. So, instead of , , which can be a child of > , should bear @altsym, e.g., > > > > > > > > > > > > > Although sometimes it can't be avoided, it's generally bad practice > to use attributes to describe other attributes. The usual way to > handle this is to "promote" an attribute to element status and then > give it its own attributes. That's what is doing. > > > > The element, however, still has the @symbol attribute with > the same values as when it's used on . In effect, > > > > > > > > is short-hand for > > > > . > > > > In other words, as in several places in MEI, it's possible to use > attributes for less-detail-oriented encodings (for example, when you > don't care what the brace looks like), but use elements when you do. > > > > -- > > 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 > [mei-l-bounces at lists.uni-paderborn.de] on behalf of Zolt?n > K?m?ves > [zolaemil at gmail.com] > Sent: Wednesday, December 11, 2013 5:10 PM > > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > Hi Andrew, > > The grouping of staves is captured by the staffGrp elements without > specifying @symbol. @symbol captures additional information. I talk > about this additional content. > > Zoltan > ________________________________ > From: Andrew Hankinson > Sent: 2013.12.11. 20:45 > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > The intellectual content (?logical domain?) is the groups of staves, > not the symbol. > > On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n > > wrote: > > Hello, > > Would you mind to read my crazy thoughts about this issue? I'm just > curious what you people think of my thinking. > > I think the "intellectual content" in this case isn't so much how the > connecting symbols look, but the fact that the symbols are > *different*. > > The current values of @symbol already bear some sort of graphical > information, I think. The problem arose now, because it seems that > the current set of values don't provide a *complete" classification > (that is, in some cases there's no value which describes the symbol's > graphical shape appropriately). But of course, it's impossible to > provide a complete classification without degrading the markup to SVG. > > If we accept that the intellectual content is the *difference* > between the connecting symbols, then the proper separation of the > "intellectual content" from it's graphical representation would be to > use a set of values something like this: > > "symbol1", > "symbol2", > "symbol3", > etc. > > If one wanted to capture more info about their "look and feel", one > could use some pointing mechanism to point to a different element > that records the graphical info (possibly even pointing to an > external SVG...) > > I know, it's a crazy abstraction. And it may be way too abstract > compared to its practical use, and we could be better off adding a > handful of carefully defined values. > > Zoltan > > > > > > 2013/12/11 Laurent Pugin > > > It seems to me that adding "bracketsq" as a possible value would be > an appropriate addition. I don't think this particular case should > necessary open up a discussion on what is just typesetting or not. > > Laurent > > > On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) > > > wrote: > Yes, caution is advised. > > > -- > 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 > [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Johannes > Kepper > [kepper at edirom.de] > Sent: Wednesday, December 11, 2013 10:02 AM > > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > While there is certainly no harm in adding a well-defined set of > additional attribute values, the risk I see is that the distinction > between these values gets harder every time, eventually watering down > their expressiveness in terms of interchange. I'm not saying we're > reaching that point here, I'm just saying that we should be careful? > > > > Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) > >: > >> The "land of music typesetting" is always nearby, not unlike a 4th >> dimension hovering around us and within us. :-) Intellectual >> content and presentation are always difficult to separate. But try >> we must. >> >> There are already issues in the tracker related to @symbol -- nos. >> 180 & 182. >> >> From issue #180 -- "The top and bottom components of a bracket can >> be rendered as curved (similar to Unicode #x1D115) or straight >> (similar to Unicode #x0005B). The simplest method of dealing with >> this distinction is to add "bracketsq" (bracket square) to the >> values allowed by @symbol. "bracket" will continue to be used for >> the usual, curved musical bracket. The documentation should be >> edited to make the distinction clear." >> >> I won't attempt to reproduce #182 here, but it covers the selection >> of a value for @symbol that captures a line (often fairly wide) used >> to group systems instead of a brace or bracket. There's an image in >> #182 that illustrates various grouping symbols. >> >> Neither the so-called square bracket nor the >> wide-line-grouping-symbol can be encoded using @symbol="line" since >> that value is already reserved for the line connecting the staves at >> their left edge. I'm partial to the value "rule", but I'm open to >> suggestions. >> >> I see no harm in adding generic values like this to MEI because they >> are what I like to call "rendering hints" for the intellectual >> content -- in this case the staff group. But obviously this >> mechanism is not optimal for capturing all the visual details of the >> symbol, such as line width, color, position, etc. I am somewhat >> trepidatious about going too far down that road, at the end of which >> MEI becomes a re-definition of SVG. :-) >> >> Yes, there are still things to add to MEI. And, yes, this is an >> opportunity to do so. Now, if there were only more hours in the day >> ... >> >> -- >> 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 >> [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes >> Kepper >> [kepper at edirom.de] >> Sent: Wednesday, December 11, 2013 8:47 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> The reason why I feel slightly uneasy with this all is that it seems >> that we seem to enter the land of a music typesetting program here. >> In my ignorance about such details, I would probably encode that as >> a line, and ignore the fact that it is connected on both ends. In >> manuscripts, there would probably be no difference between this and >> either brackets or lines. But maybe you're right, and we should >> include the additional value. @Perry, do I remember correctly that >> you spotted some values in MusicXML not currently supported by MEI >> anyway? Is this an opportunity to revise them? >> >> jo >> >> >> >> Am 11.12.2013 um 14:39 schrieb Laurent Pugin >> >: >> >>> You are right, I think it is missing. >>> >>> There are actually a few of them in the examples, at least there is >>> this one (however with no representation in the encoding) >>> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >>> >>> Laurent >>> >>> >>> >>> On Wed, Dec 11, 2013 at 1:21 PM, TW >>> > wrote: >>> Laurent's post made me wonder whether we might be missing an >>> additional value for staffGrp/@symbol for the thin bracket that is >>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >>> the sample collection I didn't see anything like that (I didn't look >>> through all of them). >>> >>> Thomas >>> >>> >>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >>> >>> _______________________________________________ >>> 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 >> >> Dr. Johannes Kepper >> BMBF-Projekt "Freisch?tz Digital" >> >> Musikwiss. Seminar Detmold / Paderborn >> Gartenstra?e 20 >> 32756 Detmold >> >> Tel. +49 5231 975669 >> 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 > > > > _______________________________________________ > 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 > > -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington From mwalter at haverford.edu Thu Dec 12 19:52:46 2013 From: mwalter at haverford.edu (Micah Walter) Date: Thu, 12 Dec 2013 13:52:46 -0500 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> Message-ID: As far as I understand, there are three, not counting "thin line" as described here. "Thin line" seems to have no meaning; it simply connects all the staves in the system. I think the thrust of this discussion is the "thin square" bracket, which in addition to the commonly seen bracket and brace is sometimes used to join two very closely related staves (e.g. violin 1 and violin 2). This can be seen in the Tchaikovsky and Berlioz scores that began the thread. If it is decided this does represent a different meaning than the square and curly groupers, it should be included. Here's a link to Lilypond's possibilities (three, besides the "thin line" that encompasses the whole system): http://lsr.dsi.unimi.it/LSR/Item?id=397 On Thu, Dec 12, 2013 at 1:21 PM, Byrd, Donald A. wrote: > Leaving aside nesting and details like thinness, as far as I know, the > _only_ symbols ever used to connect staves or groups of staves in CWMN are > (1) curly braces, (2) square brackets, and (3) a thin line -- the last > being used only to connect all the staves of a system. If there are others, > I'd love to see an example. > > --Don > > > > On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson < > andrew.hankinson at mail.mcgill.ca> wrote: > > Hi Zoltan, >> >> There is no limit to the number of nested staff groups. However, if >> you have more than four nested staff groups, each with its own >> bracket style, your engraver should be fired! :) >> >> @symbol is simply meant to indicate that there is a ?generic? >> >> bracket, brace, or line present. This is to give a visual hint, but >> not a visual definition, to any software parsing the MEI file. Do you >> have any examples of connecting symbols that are not one of these? >> (Beyond those previously discussed by Laurent?) >> >> -Andrew >> >> On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n >> >> > wrote: >> >> Hi Perry, >> >> It makes sense to separately encode the visual characteristics in a >> child element, such as . Forgive me for my ignorance about >> the existence of this element! >> >> However, I contemplate the problem of having too few values for @symbol. >> >> Consider the following statement: "there are N different symbols used >> in the score that connect groups of staves". How would you encode the >> staff groups if N>=4? >> >> Thanks >> Zoltan >> >> >> 2013/12/11 Roland, Perry (pdr4h) >> > >> >> >> Hi Zoltan, >> >> >> >> Some elements (but not ) already allow @altsym, which >> contains a pointer to a element that, in turn, contains >> instructions on how to "draw" the symbol. This area of the schema >> has not been exercised much and could therefore use a lot of work. >> However, I think could be extended to contain SVG, >> PostScript, etc. >> >> >> >> Turning to how this would work with , the @altsym attribute >> doesn't actually belong on . It's the visual >> characteristics of we're trying to capture, not those of >> . I believe this is what Andrew's comment was intended to >> mean. So, instead of , , which can be a child of >> , should bear @altsym, e.g., >> >> >> >> >> >> >> >> > >> >> >> >> >> Although sometimes it can't be avoided, it's generally bad practice >> to use attributes to describe other attributes. The usual way to >> handle this is to "promote" an attribute to element status and then >> give it its own attributes. That's what is doing. >> >> >> >> The element, however, still has the @symbol attribute with >> the same values as when it's used on . In effect, >> >> >> >> >> >> >> >> is short-hand for >> >> >> >> . >> >> >> >> In other words, as in several places in MEI, it's possible to use >> attributes for less-detail-oriented encodings (for example, when you >> don't care what the brace looks like), but use elements when you do. >> >> >> >> -- >> >> 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 >> [mei-l-bounces at lists.uni-paderborn.de> bounces at lists.uni-paderborn.de>] on behalf of Zolt?n K?m?ves >> [zolaemil at gmail.com] >> >> Sent: Wednesday, December 11, 2013 5:10 PM >> >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> Hi Andrew, >> >> The grouping of staves is captured by the staffGrp elements without >> specifying @symbol. @symbol captures additional information. I talk >> about this additional content. >> >> Zoltan >> ________________________________ >> From: Andrew Hankinson >> Sent: 2013.12.11. 20:45 >> To: Music Encoding Initiative >> >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> The intellectual content (?logical domain?) is the groups of staves, >> not the symbol. >> >> On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n >> >> > wrote: >> >> Hello, >> >> Would you mind to read my crazy thoughts about this issue? I'm just >> curious what you people think of my thinking. >> >> I think the "intellectual content" in this case isn't so much how the >> connecting symbols look, but the fact that the symbols are >> *different*. >> >> The current values of @symbol already bear some sort of graphical >> information, I think. The problem arose now, because it seems that >> the current set of values don't provide a *complete" classification >> (that is, in some cases there's no value which describes the symbol's >> graphical shape appropriately). But of course, it's impossible to >> provide a complete classification without degrading the markup to SVG. >> >> If we accept that the intellectual content is the *difference* >> between the connecting symbols, then the proper separation of the >> "intellectual content" from it's graphical representation would be to >> use a set of values something like this: >> >> "symbol1", >> "symbol2", >> "symbol3", >> etc. >> >> If one wanted to capture more info about their "look and feel", one >> could use some pointing mechanism to point to a different element >> that records the graphical info (possibly even pointing to an >> external SVG...) >> >> I know, it's a crazy abstraction. And it may be way too abstract >> compared to its practical use, and we could be better off adding a >> handful of carefully defined values. >> >> Zoltan >> >> >> >> >> >> 2013/12/11 Laurent Pugin >> > >> >> It seems to me that adding "bracketsq" as a possible value would be >> an appropriate addition. I don't think this particular case should >> necessary open up a discussion on what is just typesetting or not. >> >> Laurent >> >> >> On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) >> > >> >> wrote: >> Yes, caution is advised. >> >> >> -- >> 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 >> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de> virginia.edu at lists.uni-paderborn.de>] on behalf of Johannes Kepper >> [kepper at edirom.de] >> >> Sent: Wednesday, December 11, 2013 10:02 AM >> >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> While there is certainly no harm in adding a well-defined set of >> additional attribute values, the risk I see is that the distinction >> between these values gets harder every time, eventually watering down >> their expressiveness in terms of interchange. I'm not saying we're >> reaching that point here, I'm just saying that we should be careful? >> >> >> >> >> Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) >> >: >> >> The "land of music typesetting" is always nearby, not unlike a 4th >>> dimension hovering around us and within us. :-) Intellectual >>> content and presentation are always difficult to separate. But try >>> we must. >>> >>> There are already issues in the tracker related to @symbol -- nos. >>> 180 & 182. >>> >>> From issue #180 -- "The top and bottom components of a bracket can >>> be rendered as curved (similar to Unicode #x1D115) or straight >>> (similar to Unicode #x0005B). The simplest method of dealing with >>> this distinction is to add "bracketsq" (bracket square) to the >>> values allowed by @symbol. "bracket" will continue to be used for >>> the usual, curved musical bracket. The documentation should be >>> edited to make the distinction clear." >>> >>> I won't attempt to reproduce #182 here, but it covers the selection >>> of a value for @symbol that captures a line (often fairly wide) used >>> to group systems instead of a brace or bracket. There's an image in >>> #182 that illustrates various grouping symbols. >>> >>> Neither the so-called square bracket nor the >>> wide-line-grouping-symbol can be encoded using @symbol="line" since >>> that value is already reserved for the line connecting the staves at >>> their left edge. I'm partial to the value "rule", but I'm open to >>> suggestions. >>> >>> I see no harm in adding generic values like this to MEI because they >>> are what I like to call "rendering hints" for the intellectual >>> content -- in this case the staff group. But obviously this >>> mechanism is not optimal for capturing all the visual details of the >>> symbol, such as line width, color, position, etc. I am somewhat >>> trepidatious about going too far down that road, at the end of which >>> MEI becomes a re-definition of SVG. :-) >>> >>> Yes, there are still things to add to MEI. And, yes, this is an >>> opportunity to do so. Now, if there were only more hours in the day >>> ... >>> >>> -- >>> 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 >>> [mei-l-bounces at lists.uni-paderborn.de>> bounces at lists.uni-paderborn.de>] on behalf of Johannes Kepper >>> [kepper at edirom.de] >>> >>> Sent: Wednesday, December 11, 2013 8:47 AM >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> >>> The reason why I feel slightly uneasy with this all is that it seems >>> that we seem to enter the land of a music typesetting program here. >>> In my ignorance about such details, I would probably encode that as >>> a line, and ignore the fact that it is connected on both ends. In >>> manuscripts, there would probably be no difference between this and >>> either brackets or lines. But maybe you're right, and we should >>> include the additional value. @Perry, do I remember correctly that >>> you spotted some values in MusicXML not currently supported by MEI >>> anyway? Is this an opportunity to revise them? >>> >>> jo >>> >>> >>> >>> Am 11.12.2013 um 14:39 schrieb Laurent Pugin >>> >: >>> >>> You are right, I think it is missing. >>>> >>>> There are actually a few of them in the examples, at least there is >>>> this one (however with no representation in the encoding) >>>> http://www.music-encoding.org/sampleCollection/encodings/ >>>> Berlioz_Symphony_op25.pdf >>>> >>>> Laurent >>>> >>>> >>>> >>>> On Wed, Dec 11, 2013 at 1:21 PM, TW >>>> > wrote: >>>> Laurent's post made me wonder whether we might be missing an >>>> additional value for staffGrp/@symbol for the thin bracket that is >>>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >>>> the sample collection I didn't see anything like that (I didn't look >>>> through all of them). >>>> >>>> Thomas >>>> >>>> >>>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> >>> Dr. Johannes Kepper >>> BMBF-Projekt "Freisch?tz Digital" >>> >>> Musikwiss. Seminar Detmold / Paderborn >>> Gartenstra?e 20 >>> 32756 Detmold >>> >>> Tel. +49 5231 975669 >>> 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 >> >> >> >> _______________________________________________ >> 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 >> >> >> > > > -- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > Indiana University Bloomington > > > > _______________________________________________ > 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: From pdr4h at eservices.virginia.edu Thu Dec 12 20:10:27 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 12 Dec 2013 19:10:27 +0000 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> , <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> Message-ID: Hi Don, Finale provides 6 options in its "Group Attributes" dialog box. See http://www.finalemusic.com/usermanuals/finale2012win/content/finale/GROUPDLG.htm. I think "bracket" accurately describes options 3, 5, & 6 (from the left), "brace" being used for option 4. I can't say that I've seen any other symbols "in the wild". (NB -- My mention of Finale doesn't constitute any kind of endorsement. It's just that its documentation is easily accessible.) MEI currently offers only "none", "brace", "bracket", and "line" as possibilities, where "line" is reserved for the thin line connecting the score/system staves. These are sufficient to capture the broad categories of symbols, but they (especially "bracket") don't provide much in the way of visual detail. The question is, how/where should that detail be located? My solution is to add "rule" and "bracketsq", representing Finale options 2 and 6, respectively. This expands the level of visual detail encapsulated in the @symbol attribute, but still doesn't differentiate between options 3 and 5 or capture "typographical" features (so-called 'hook' shape, color, line width, etc.). However, it does provide the same level of granularity as MusicXML, enhancing loss-less conversion to/from MEI. Of course, multiple typographical details can't be captured in a single attribute value. And it's bad practice to add more attributes to to comment on the value in @symbol. So, recording those details necessitates a child of with its own attributes. Those attributes can then be used to describe the symbol in greater detail or point to a precise rendition stored elsewhere. This mechanism can be used for any symbol used to group staves, if someone does find an example outside the usual ones you mention, for instance in a manuscript score. Not exactly what you asked for, but helpful nonetheless I hope, -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, Donald A. [donbyrd at indiana.edu] Sent: Thursday, December 12, 2013 1:21 PM To: mei-l at lists.uni-paderborn.de Subject: Re: [MEI-L] Thin brackets in orchestral scores Leaving aside nesting and details like thinness, as far as I know, the _only_ symbols ever used to connect staves or groups of staves in CWMN are (1) curly braces, (2) square brackets, and (3) a thin line -- the last being used only to connect all the staves of a system. If there are others, I'd love to see an example. --Don On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson wrote: > Hi Zoltan, > > There is no limit to the number of nested staff groups. However, if > you have more than four nested staff groups, each with its own > bracket style, your engraver should be fired! :) > > @symbol is simply meant to indicate that there is a ?generic? > bracket, brace, or line present. This is to give a visual hint, but > not a visual definition, to any software parsing the MEI file. Do you > have any examples of connecting symbols that are not one of these? > (Beyond those previously discussed by Laurent?) > > -Andrew > > On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n > > wrote: > > Hi Perry, > > It makes sense to separately encode the visual characteristics in a > child element, such as . Forgive me for my ignorance about > the existence of this element! > > However, I contemplate the problem of having too few values for @symbol. > > Consider the following statement: "there are N different symbols used > in the score that connect groups of staves". How would you encode the > staff groups if N>=4? > > Thanks > Zoltan > > > 2013/12/11 Roland, Perry (pdr4h) > > > > Hi Zoltan, > > > > Some elements (but not ) already allow @altsym, which > contains a pointer to a element that, in turn, contains > instructions on how to "draw" the symbol. This area of the schema > has not been exercised much and could therefore use a lot of work. > However, I think could be extended to contain SVG, > PostScript, etc. > > > > Turning to how this would work with , the @altsym attribute > doesn't actually belong on . It's the visual > characteristics of we're trying to capture, not those of > . I believe this is what Andrew's comment was intended to > mean. So, instead of , , which can be a child of > , should bear @altsym, e.g., > > > > > > > > > > > > > Although sometimes it can't be avoided, it's generally bad practice > to use attributes to describe other attributes. The usual way to > handle this is to "promote" an attribute to element status and then > give it its own attributes. That's what is doing. > > > > The element, however, still has the @symbol attribute with > the same values as when it's used on . In effect, > > > > > > > > is short-hand for > > > > . > > > > In other words, as in several places in MEI, it's possible to use > attributes for less-detail-oriented encodings (for example, when you > don't care what the brace looks like), but use elements when you do. > > > > -- > > 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 > [mei-l-bounces at lists.uni-paderborn.de] on behalf of Zolt?n > K?m?ves > [zolaemil at gmail.com] > Sent: Wednesday, December 11, 2013 5:10 PM > > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > Hi Andrew, > > The grouping of staves is captured by the staffGrp elements without > specifying @symbol. @symbol captures additional information. I talk > about this additional content. > > Zoltan > ________________________________ > From: Andrew Hankinson > Sent: 2013.12.11. 20:45 > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > The intellectual content (?logical domain?) is the groups of staves, > not the symbol. > > On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n > > wrote: > > Hello, > > Would you mind to read my crazy thoughts about this issue? I'm just > curious what you people think of my thinking. > > I think the "intellectual content" in this case isn't so much how the > connecting symbols look, but the fact that the symbols are > *different*. > > The current values of @symbol already bear some sort of graphical > information, I think. The problem arose now, because it seems that > the current set of values don't provide a *complete" classification > (that is, in some cases there's no value which describes the symbol's > graphical shape appropriately). But of course, it's impossible to > provide a complete classification without degrading the markup to SVG. > > If we accept that the intellectual content is the *difference* > between the connecting symbols, then the proper separation of the > "intellectual content" from it's graphical representation would be to > use a set of values something like this: > > "symbol1", > "symbol2", > "symbol3", > etc. > > If one wanted to capture more info about their "look and feel", one > could use some pointing mechanism to point to a different element > that records the graphical info (possibly even pointing to an > external SVG...) > > I know, it's a crazy abstraction. And it may be way too abstract > compared to its practical use, and we could be better off adding a > handful of carefully defined values. > > Zoltan > > > > > > 2013/12/11 Laurent Pugin > > > It seems to me that adding "bracketsq" as a possible value would be > an appropriate addition. I don't think this particular case should > necessary open up a discussion on what is just typesetting or not. > > Laurent > > > On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) > > > wrote: > Yes, caution is advised. > > > -- > 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 > [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Johannes > Kepper > [kepper at edirom.de] > Sent: Wednesday, December 11, 2013 10:02 AM > > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > While there is certainly no harm in adding a well-defined set of > additional attribute values, the risk I see is that the distinction > between these values gets harder every time, eventually watering down > their expressiveness in terms of interchange. I'm not saying we're > reaching that point here, I'm just saying that we should be careful? > > > > Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) > >: > >> The "land of music typesetting" is always nearby, not unlike a 4th >> dimension hovering around us and within us. :-) Intellectual >> content and presentation are always difficult to separate. But try >> we must. >> >> There are already issues in the tracker related to @symbol -- nos. >> 180 & 182. >> >> From issue #180 -- "The top and bottom components of a bracket can >> be rendered as curved (similar to Unicode #x1D115) or straight >> (similar to Unicode #x0005B). The simplest method of dealing with >> this distinction is to add "bracketsq" (bracket square) to the >> values allowed by @symbol. "bracket" will continue to be used for >> the usual, curved musical bracket. The documentation should be >> edited to make the distinction clear." >> >> I won't attempt to reproduce #182 here, but it covers the selection >> of a value for @symbol that captures a line (often fairly wide) used >> to group systems instead of a brace or bracket. There's an image in >> #182 that illustrates various grouping symbols. >> >> Neither the so-called square bracket nor the >> wide-line-grouping-symbol can be encoded using @symbol="line" since >> that value is already reserved for the line connecting the staves at >> their left edge. I'm partial to the value "rule", but I'm open to >> suggestions. >> >> I see no harm in adding generic values like this to MEI because they >> are what I like to call "rendering hints" for the intellectual >> content -- in this case the staff group. But obviously this >> mechanism is not optimal for capturing all the visual details of the >> symbol, such as line width, color, position, etc. I am somewhat >> trepidatious about going too far down that road, at the end of which >> MEI becomes a re-definition of SVG. :-) >> >> Yes, there are still things to add to MEI. And, yes, this is an >> opportunity to do so. Now, if there were only more hours in the day >> ... >> >> -- >> 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 >> [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes >> Kepper >> [kepper at edirom.de] >> Sent: Wednesday, December 11, 2013 8:47 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> The reason why I feel slightly uneasy with this all is that it seems >> that we seem to enter the land of a music typesetting program here. >> In my ignorance about such details, I would probably encode that as >> a line, and ignore the fact that it is connected on both ends. In >> manuscripts, there would probably be no difference between this and >> either brackets or lines. But maybe you're right, and we should >> include the additional value. @Perry, do I remember correctly that >> you spotted some values in MusicXML not currently supported by MEI >> anyway? Is this an opportunity to revise them? >> >> jo >> >> >> >> Am 11.12.2013 um 14:39 schrieb Laurent Pugin >> >: >> >>> You are right, I think it is missing. >>> >>> There are actually a few of them in the examples, at least there is >>> this one (however with no representation in the encoding) >>> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >>> >>> Laurent >>> >>> >>> >>> On Wed, Dec 11, 2013 at 1:21 PM, TW >>> > wrote: >>> Laurent's post made me wonder whether we might be missing an >>> additional value for staffGrp/@symbol for the thin bracket that is >>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >>> the sample collection I didn't see anything like that (I didn't look >>> through all of them). >>> >>> Thomas >>> >>> >>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >>> >>> _______________________________________________ >>> 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 >> >> Dr. Johannes Kepper >> BMBF-Projekt "Freisch?tz Digital" >> >> Musikwiss. Seminar Detmold / Paderborn >> Gartenstra?e 20 >> 32756 Detmold >> >> Tel. +49 5231 975669 >> 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 > > > > _______________________________________________ > 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 > > -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington _______________________________________________ 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 Thu Dec 12 20:22:53 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 12 Dec 2013 14:22:53 -0500 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> Message-ID: On Thu, Dec 12, 2013 at 2:10 PM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > So, recording those details necessitates a child of > with its own attributes. Those attributes can then be used to describe the > symbol in greater detail or point to a precise rendition stored elsewhere. > I would keep the options as limited as possible. Micah is right: we should introduce a new symbol only if it translates to a different function, otherwise MEI should not bother: we are not doing typesetting (even while we acknowledge it as a 4th, hovering, dimension). Wouldn't it be best having other standards pointing at a semantic MEI elements to provide a rendition, rather than adding a pointing mechanisms from MEI? Example MEI: these staves are grouped. This group has and id "grp1" Other system: the class "stave brackets" has to be rendered according to this routine. Apply it to MEI element #grp1. Also, #grp1 is a special case, so tweak this parameter a bit. I feel strongly that MEI ought to be fully agnostic of the "other system" in the example. Raf > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, > Donald A. [donbyrd at indiana.edu] > Sent: Thursday, December 12, 2013 1:21 PM > To: mei-l at lists.uni-paderborn.de > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > Leaving aside nesting and details like thinness, as far as I know, the > _only_ symbols ever used to connect staves or groups of staves in CWMN > are (1) curly braces, (2) square brackets, and (3) a thin line -- the > last being used only to connect all the staves of a system. If there > are others, I'd love to see an example. > > --Don > > > On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson > wrote: > > > Hi Zoltan, > > > > There is no limit to the number of nested staff groups. However, if > > you have more than four nested staff groups, each with its own > > bracket style, your engraver should be fired! :) > > > > @symbol is simply meant to indicate that there is a ?generic? > > bracket, brace, or line present. This is to give a visual hint, but > > not a visual definition, to any software parsing the MEI file. Do you > > have any examples of connecting symbols that are not one of these? > > (Beyond those previously discussed by Laurent?) > > > > -Andrew > > > > On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n > > > wrote: > > > > Hi Perry, > > > > It makes sense to separately encode the visual characteristics in a > > child element, such as . Forgive me for my ignorance about > > the existence of this element! > > > > However, I contemplate the problem of having too few values for @symbol. > > > > Consider the following statement: "there are N different symbols used > > in the score that connect groups of staves". How would you encode the > > staff groups if N>=4? > > > > Thanks > > Zoltan > > > > > > 2013/12/11 Roland, Perry (pdr4h) > > > > > > > Hi Zoltan, > > > > > > > > Some elements (but not ) already allow @altsym, which > > contains a pointer to a element that, in turn, contains > > instructions on how to "draw" the symbol. This area of the schema > > has not been exercised much and could therefore use a lot of work. > > However, I think could be extended to contain SVG, > > PostScript, etc. > > > > > > > > Turning to how this would work with , the @altsym attribute > > doesn't actually belong on . It's the visual > > characteristics of we're trying to capture, not those of > > . I believe this is what Andrew's comment was intended to > > mean. So, instead of , , which can be a child of > > , should bear @altsym, e.g., > > > > > > > > > > > > > > > > > > > > > > > > > > > Although sometimes it can't be avoided, it's generally bad practice > > to use attributes to describe other attributes. The usual way to > > handle this is to "promote" an attribute to element status and then > > give it its own attributes. That's what is doing. > > > > > > > > The element, however, still has the @symbol attribute with > > the same values as when it's used on . In effect, > > > > > > > > > > > > > > > > is short-hand for > > > > > > > > . > > > > > > > > In other words, as in several places in MEI, it's possible to use > > attributes for less-detail-oriented encodings (for example, when you > > don't care what the brace looks like), but use elements when you do. > > > > > > > > -- > > > > 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 > > [mei-l-bounces at lists.uni-paderborn.de mei-l-bounces at lists.uni-paderborn.de>] on behalf of Zolt?n > > K?m?ves > > [zolaemil at gmail.com] > > Sent: Wednesday, December 11, 2013 5:10 PM > > > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > > > Hi Andrew, > > > > The grouping of staves is captured by the staffGrp elements without > > specifying @symbol. @symbol captures additional information. I talk > > about this additional content. > > > > Zoltan > > ________________________________ > > From: Andrew Hankinson > > Sent: 2013.12.11. 20:45 > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > > > The intellectual content (?logical domain?) is the groups of staves, > > not the symbol. > > > > On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n > > > wrote: > > > > Hello, > > > > Would you mind to read my crazy thoughts about this issue? I'm just > > curious what you people think of my thinking. > > > > I think the "intellectual content" in this case isn't so much how the > > connecting symbols look, but the fact that the symbols are > > *different*. > > > > The current values of @symbol already bear some sort of graphical > > information, I think. The problem arose now, because it seems that > > the current set of values don't provide a *complete" classification > > (that is, in some cases there's no value which describes the symbol's > > graphical shape appropriately). But of course, it's impossible to > > provide a complete classification without degrading the markup to SVG. > > > > If we accept that the intellectual content is the *difference* > > between the connecting symbols, then the proper separation of the > > "intellectual content" from it's graphical representation would be to > > use a set of values something like this: > > > > "symbol1", > > "symbol2", > > "symbol3", > > etc. > > > > If one wanted to capture more info about their "look and feel", one > > could use some pointing mechanism to point to a different element > > that records the graphical info (possibly even pointing to an > > external SVG...) > > > > I know, it's a crazy abstraction. And it may be way too abstract > > compared to its practical use, and we could be better off adding a > > handful of carefully defined values. > > > > Zoltan > > > > > > > > > > > > 2013/12/11 Laurent Pugin > > > > > It seems to me that adding "bracketsq" as a possible value would be > > an appropriate addition. I don't think this particular case should > > necessary open up a discussion on what is just typesetting or not. > > > > Laurent > > > > > > On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) > > > > > wrote: > > Yes, caution is advised. > > > > > > -- > > 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 > > [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de virginia.edu at lists.uni-paderborn.de>] on behalf of Johannes > > Kepper > > [kepper at edirom.de] > > Sent: Wednesday, December 11, 2013 10:02 AM > > > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > > > While there is certainly no harm in adding a well-defined set of > > additional attribute values, the risk I see is that the distinction > > between these values gets harder every time, eventually watering down > > their expressiveness in terms of interchange. I'm not saying we're > > reaching that point here, I'm just saying that we should be careful? > > > > > > > > Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) > > >: > > > >> The "land of music typesetting" is always nearby, not unlike a 4th > >> dimension hovering around us and within us. :-) Intellectual > >> content and presentation are always difficult to separate. But try > >> we must. > >> > >> There are already issues in the tracker related to @symbol -- nos. > >> 180 & 182. > >> > >> From issue #180 -- "The top and bottom components of a bracket can > >> be rendered as curved (similar to Unicode #x1D115) or straight > >> (similar to Unicode #x0005B). The simplest method of dealing with > >> this distinction is to add "bracketsq" (bracket square) to the > >> values allowed by @symbol. "bracket" will continue to be used for > >> the usual, curved musical bracket. The documentation should be > >> edited to make the distinction clear." > >> > >> I won't attempt to reproduce #182 here, but it covers the selection > >> of a value for @symbol that captures a line (often fairly wide) used > >> to group systems instead of a brace or bracket. There's an image in > >> #182 that illustrates various grouping symbols. > >> > >> Neither the so-called square bracket nor the > >> wide-line-grouping-symbol can be encoded using @symbol="line" since > >> that value is already reserved for the line connecting the staves at > >> their left edge. I'm partial to the value "rule", but I'm open to > >> suggestions. > >> > >> I see no harm in adding generic values like this to MEI because they > >> are what I like to call "rendering hints" for the intellectual > >> content -- in this case the staff group. But obviously this > >> mechanism is not optimal for capturing all the visual details of the > >> symbol, such as line width, color, position, etc. I am somewhat > >> trepidatious about going too far down that road, at the end of which > >> MEI becomes a re-definition of SVG. :-) > >> > >> Yes, there are still things to add to MEI. And, yes, this is an > >> opportunity to do so. Now, if there were only more hours in the day > >> ... > >> > >> -- > >> 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 > >> [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, December 11, 2013 8:47 AM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] Thin brackets in orchestral scores > >> > >> The reason why I feel slightly uneasy with this all is that it seems > >> that we seem to enter the land of a music typesetting program here. > >> In my ignorance about such details, I would probably encode that as > >> a line, and ignore the fact that it is connected on both ends. In > >> manuscripts, there would probably be no difference between this and > >> either brackets or lines. But maybe you're right, and we should > >> include the additional value. @Perry, do I remember correctly that > >> you spotted some values in MusicXML not currently supported by MEI > >> anyway? Is this an opportunity to revise them? > >> > >> jo > >> > >> > >> > >> Am 11.12.2013 um 14:39 schrieb Laurent Pugin > >> >: > >> > >>> You are right, I think it is missing. > >>> > >>> There are actually a few of them in the examples, at least there is > >>> this one (however with no representation in the encoding) > >>> > http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf > >>> > >>> Laurent > >>> > >>> > >>> > >>> On Wed, Dec 11, 2013 at 1:21 PM, TW > >>> > wrote: > >>> Laurent's post made me wonder whether we might be missing an > >>> additional value for staffGrp/@symbol for the thin bracket that is > >>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in > >>> the sample collection I didn't see anything like that (I didn't look > >>> through all of them). > >>> > >>> Thomas > >>> > >>> > >>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf > >>> > >>> _______________________________________________ > >>> 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 > >> > >> Dr. Johannes Kepper > >> BMBF-Projekt "Freisch?tz Digital" > >> > >> Musikwiss. Seminar Detmold / Paderborn > >> Gartenstra?e 20 > >> 32756 Detmold > >> > >> Tel. +49 5231 975669 > >> 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 > > > > > > > > _______________________________________________ > > 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 > > > > > > > > -- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Thu Dec 12 21:21:35 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 12 Dec 2013 20:21:35 +0000 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> , Message-ID: Hi Raffaele, > Example > MEI: these staves are grouped. This group has and id "grp1" > Other system: the class "stave brackets" has to be rendered according to this routine. Apply > it to MEI element #grp1. Also, #grp1 is a special case, so tweak this parameter a bit. > I feel strongly that MEI ought to be fully agnostic of the "other system" in the example. I agree with you. In so far as it's practical, MEI should remain agnostic about many things. However, as yet there is nothing like CSS for music notation, so we're left to deal with a wide range of so-called "other systems" for rendition. I regard the attribute values we've been discussing as parameters to those other systems. This is why I refer to them as "hints". I don't think, however, we can ignore those cases where the encoder has a very definite symbol in mind and wishes to provide an exemplar, e.g., in the case of so-called "non-standard" symbols. We should also keep in mind the possibility of MEI functioning as an intermediate representation *between systems* at a level beyond "there's a bracket here, draw one of your choosing". While, as Zoltan said, MEI != SVG, I believe there are cases where the possibility of passing a precise rendition to a down-stream application would be very useful. The combination of @altsym and provides for these cases. Since it aims to standardize the musical symbol repertoire, I believe a SMuFL codepoint could be appropriate content of , similar to the way Unicode codepoints can be referenced by TEI elements. SVG, PostScript, or other graphic description languages could also be appropriate content. I don't characterize this as "degrading MEI to SVG" (one of my new favorite phrases), but rather as practical employment of existing standards. I also don't think it diminishes MEI's level of/commitment to agnosticism. -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Thursday, December 12, 2013 2:22 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Thin brackets in orchestral scores On Thu, Dec 12, 2013 at 2:10 PM, Roland, Perry (pdr4h) > wrote: So, recording those details necessitates a child of with its own attributes. Those attributes can then be used to describe the symbol in greater detail or point to a precise rendition stored elsewhere. I would keep the options as limited as possible. Micah is right: we should introduce a new symbol only if it translates to a different function, otherwise MEI should not bother: we are not doing typesetting (even while we acknowledge it as a 4th, hovering, dimension). Wouldn't it be best having other standards pointing at a semantic MEI elements to provide a rendition, rather than adding a pointing mechanisms from MEI? Example MEI: these staves are grouped. This group has and id "grp1" Other system: the class "stave brackets" has to be rendered according to this routine. Apply it to MEI element #grp1. Also, #grp1 is a special case, so tweak this parameter a bit. I feel strongly that MEI ought to be fully agnostic of the "other system" in the example. Raf -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, Donald A. [donbyrd at indiana.edu] Sent: Thursday, December 12, 2013 1:21 PM To: mei-l at lists.uni-paderborn.de Subject: Re: [MEI-L] Thin brackets in orchestral scores Leaving aside nesting and details like thinness, as far as I know, the _only_ symbols ever used to connect staves or groups of staves in CWMN are (1) curly braces, (2) square brackets, and (3) a thin line -- the last being used only to connect all the staves of a system. If there are others, I'd love to see an example. --Don On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson > wrote: > Hi Zoltan, > > There is no limit to the number of nested staff groups. However, if > you have more than four nested staff groups, each with its own > bracket style, your engraver should be fired! :) > > @symbol is simply meant to indicate that there is a ?generic? > bracket, brace, or line present. This is to give a visual hint, but > not a visual definition, to any software parsing the MEI file. Do you > have any examples of connecting symbols that are not one of these? > (Beyond those previously discussed by Laurent?) > > -Andrew > > On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n > >> wrote: > > Hi Perry, > > It makes sense to separately encode the visual characteristics in a > child element, such as . Forgive me for my ignorance about > the existence of this element! > > However, I contemplate the problem of having too few values for @symbol. > > Consider the following statement: "there are N different symbols used > in the score that connect groups of staves". How would you encode the > staff groups if N>=4? > > Thanks > Zoltan > > > 2013/12/11 Roland, Perry (pdr4h) > >> > > Hi Zoltan, > > > > Some elements (but not ) already allow @altsym, which > contains a pointer to a element that, in turn, contains > instructions on how to "draw" the symbol. This area of the schema > has not been exercised much and could therefore use a lot of work. > However, I think could be extended to contain SVG, > PostScript, etc. > > > > Turning to how this would work with , the @altsym attribute > doesn't actually belong on . It's the visual > characteristics of we're trying to capture, not those of > . I believe this is what Andrew's comment was intended to > mean. So, instead of , , which can be a child of > , should bear @altsym, e.g., > > > > > > > > > > > > > Although sometimes it can't be avoided, it's generally bad practice > to use attributes to describe other attributes. The usual way to > handle this is to "promote" an attribute to element status and then > give it its own attributes. That's what is doing. > > > > The element, however, still has the @symbol attribute with > the same values as when it's used on . In effect, > > > > > > > > is short-hand for > > > > . > > > > In other words, as in several places in MEI, it's possible to use > attributes for less-detail-oriented encodings (for example, when you > don't care what the brace looks like), but use elements when you do. > > > > -- > > 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 > [mei-l-bounces at lists.uni-paderborn.de>] on behalf of Zolt?n > K?m?ves > [zolaemil at gmail.com>] > Sent: Wednesday, December 11, 2013 5:10 PM > > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > Hi Andrew, > > The grouping of staves is captured by the staffGrp elements without > specifying @symbol. @symbol captures additional information. I talk > about this additional content. > > Zoltan > ________________________________ > From: Andrew Hankinson> > Sent: 2013.12.11. 20:45 > To: Music Encoding Initiative> > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > The intellectual content (?logical domain?) is the groups of staves, > not the symbol. > > On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n > >> wrote: > > Hello, > > Would you mind to read my crazy thoughts about this issue? I'm just > curious what you people think of my thinking. > > I think the "intellectual content" in this case isn't so much how the > connecting symbols look, but the fact that the symbols are > *different*. > > The current values of @symbol already bear some sort of graphical > information, I think. The problem arose now, because it seems that > the current set of values don't provide a *complete" classification > (that is, in some cases there's no value which describes the symbol's > graphical shape appropriately). But of course, it's impossible to > provide a complete classification without degrading the markup to SVG. > > If we accept that the intellectual content is the *difference* > between the connecting symbols, then the proper separation of the > "intellectual content" from it's graphical representation would be to > use a set of values something like this: > > "symbol1", > "symbol2", > "symbol3", > etc. > > If one wanted to capture more info about their "look and feel", one > could use some pointing mechanism to point to a different element > that records the graphical info (possibly even pointing to an > external SVG...) > > I know, it's a crazy abstraction. And it may be way too abstract > compared to its practical use, and we could be better off adding a > handful of carefully defined values. > > Zoltan > > > > > > 2013/12/11 Laurent Pugin > >> > It seems to me that adding "bracketsq" as a possible value would be > an appropriate addition. I don't think this particular case should > necessary open up a discussion on what is just typesetting or not. > > Laurent > > > On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) > >> > wrote: > Yes, caution is advised. > > > -- > 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 > [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de>] on behalf of Johannes > Kepper > [kepper at edirom.de>] > Sent: Wednesday, December 11, 2013 10:02 AM > > To: Music Encoding Initiative > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > While there is certainly no harm in adding a well-defined set of > additional attribute values, the risk I see is that the distinction > between these values gets harder every time, eventually watering down > their expressiveness in terms of interchange. I'm not saying we're > reaching that point here, I'm just saying that we should be careful? > > > > Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) > >>: > >> The "land of music typesetting" is always nearby, not unlike a 4th >> dimension hovering around us and within us. :-) Intellectual >> content and presentation are always difficult to separate. But try >> we must. >> >> There are already issues in the tracker related to @symbol -- nos. >> 180 & 182. >> >> From issue #180 -- "The top and bottom components of a bracket can >> be rendered as curved (similar to Unicode #x1D115) or straight >> (similar to Unicode #x0005B). The simplest method of dealing with >> this distinction is to add "bracketsq" (bracket square) to the >> values allowed by @symbol. "bracket" will continue to be used for >> the usual, curved musical bracket. The documentation should be >> edited to make the distinction clear." >> >> I won't attempt to reproduce #182 here, but it covers the selection >> of a value for @symbol that captures a line (often fairly wide) used >> to group systems instead of a brace or bracket. There's an image in >> #182 that illustrates various grouping symbols. >> >> Neither the so-called square bracket nor the >> wide-line-grouping-symbol can be encoded using @symbol="line" since >> that value is already reserved for the line connecting the staves at >> their left edge. I'm partial to the value "rule", but I'm open to >> suggestions. >> >> I see no harm in adding generic values like this to MEI because they >> are what I like to call "rendering hints" for the intellectual >> content -- in this case the staff group. But obviously this >> mechanism is not optimal for capturing all the visual details of the >> symbol, such as line width, color, position, etc. I am somewhat >> trepidatious about going too far down that road, at the end of which >> MEI becomes a re-definition of SVG. :-) >> >> Yes, there are still things to add to MEI. And, yes, this is an >> opportunity to do so. Now, if there were only more hours in the day >> ... >> >> -- >> 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 >> [mei-l-bounces at lists.uni-paderborn.de>] on behalf of Johannes >> Kepper >> [kepper at edirom.de>] >> Sent: Wednesday, December 11, 2013 8:47 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> The reason why I feel slightly uneasy with this all is that it seems >> that we seem to enter the land of a music typesetting program here. >> In my ignorance about such details, I would probably encode that as >> a line, and ignore the fact that it is connected on both ends. In >> manuscripts, there would probably be no difference between this and >> either brackets or lines. But maybe you're right, and we should >> include the additional value. @Perry, do I remember correctly that >> you spotted some values in MusicXML not currently supported by MEI >> anyway? Is this an opportunity to revise them? >> >> jo >> >> >> >> Am 11.12.2013 um 14:39 schrieb Laurent Pugin >> >>: >> >>> You are right, I think it is missing. >>> >>> There are actually a few of them in the examples, at least there is >>> this one (however with no representation in the encoding) >>> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >>> >>> Laurent >>> >>> >>> >>> On Wed, Dec 11, 2013 at 1:21 PM, TW >>> >> wrote: >>> Laurent's post made me wonder whether we might be missing an >>> additional value for staffGrp/@symbol for the thin bracket that is >>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >>> the sample collection I didn't see anything like that (I didn't look >>> through all of them). >>> >>> Thomas >>> >>> >>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >>> >>> _______________________________________________ >>> 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 >> >> Dr. Johannes Kepper >> BMBF-Projekt "Freisch?tz Digital" >> >> Musikwiss. Seminar Detmold / Paderborn >> Gartenstra?e 20 >> 32756 Detmold >> >> Tel. +49 5231 975669 >> 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 > > > > _______________________________________________ > 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 > > -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent at music.mcgill.ca Thu Dec 12 22:19:47 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Thu, 12 Dec 2013 22:19:47 +0100 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: <13820_1386879719_52AA1AE6_13820_326_4_BBCC497C40D85642B90E9F94FC30343D32B554B5@grant1.eservices.virginia.edu> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <13820_1386879719_52AA1AE6_13820_326_4_BBCC497C40D85642B90E9F94FC30343D32B554B5@grant1.eservices.virginia.edu> Message-ID: Hi Raffaele, I agree we should keep the list of options as short as possible, and I don't think there is any intention here to extend it widely. The line between what has a different function and what it "just" representation in music notation is always difficulty to draw ;-) I am not sure there is a deep functional difference between brace and bracket, but I might be wrong. Laurent On Thu, Dec 12, 2013 at 9:21 PM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > Hi Raffaele, > > > > Example > > MEI: these staves are grouped. This group has and id "grp1" > > Other system: the class "stave brackets" has to be rendered according to > this routine. Apply > > it to MEI element #grp1. Also, #grp1 is a special case, so tweak this > parameter a bit. > > I feel strongly that MEI ought to be fully agnostic of the "other > system" in the example. > > I agree with you. In so far as it's practical, MEI should remain agnostic > about many things. However, as yet there is nothing like CSS for music > notation, so we're left to deal with a wide range of so-called "other > systems" for rendition. I regard the attribute values we've been > discussing as parameters to those other systems. This is why I refer to > them as "hints". > > I don't think, however, we can ignore those cases where the encoder has a > very definite symbol in mind and wishes to provide an exemplar, e.g., in > the case of so-called "non-standard" symbols. We should also keep in mind > the possibility of MEI functioning as an intermediate representation > *between systems* at a level beyond "there's a bracket here, draw one of > your choosing". While, as Zoltan said, MEI != SVG, I believe there are > cases where the possibility of passing a precise rendition to a down-stream > application would be very useful. The combination of @altsym and > provides for these cases. > > Since it aims to standardize the musical symbol repertoire, I believe a > SMuFL codepoint could be appropriate content of , similar to the > way Unicode codepoints can be referenced by TEI elements. SVG, > PostScript, or other graphic description languages could also be > appropriate content. > > I don't characterize this as "degrading MEI to SVG" (one of my new > favorite phrases), but rather as practical employment of existing > standards. I also don't think it diminishes MEI's level of/commitment > to agnosticism. > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of > Raffaele Viglianti [raffaeleviglianti at gmail.com] > *Sent:* Thursday, December 12, 2013 2:22 PM > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Thin brackets in orchestral scores > > On Thu, Dec 12, 2013 at 2:10 PM, Roland, Perry (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: >> >> >> So, recording those details necessitates a child of >> with its own attributes. Those attributes can then be used to describe the >> symbol in greater detail or point to a precise rendition stored elsewhere. >> > > I would keep the options as limited as possible. Micah is right: we > should introduce a new symbol only if it translates to a different > function, otherwise MEI should not bother: we are not doing typesetting > (even while we acknowledge it as a 4th, hovering, dimension). > > Wouldn't it be best having other standards pointing at a semantic MEI > elements to provide a rendition, rather than adding a pointing mechanisms > from MEI? > > Example > MEI: these staves are grouped. This group has and id "grp1" > Other system: the class "stave brackets" has to be rendered according to > this routine. Apply it to MEI element #grp1. Also, #grp1 is a special case, > so tweak this parameter a bit. > > I feel strongly that MEI ought to be fully agnostic of the "other > system" in the example. > > Raf > > > >> >> -- >> 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, >> Donald A. [donbyrd at indiana.edu] >> Sent: Thursday, December 12, 2013 1:21 PM >> To: mei-l at lists.uni-paderborn.de >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> Leaving aside nesting and details like thinness, as far as I know, the >> _only_ symbols ever used to connect staves or groups of staves in CWMN >> are (1) curly braces, (2) square brackets, and (3) a thin line -- the >> last being used only to connect all the staves of a system. If there >> are others, I'd love to see an example. >> >> --Don >> >> >> On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson >> wrote: >> >> > Hi Zoltan, >> > >> > There is no limit to the number of nested staff groups. However, if >> > you have more than four nested staff groups, each with its own >> > bracket style, your engraver should be fired! :) >> > >> > @symbol is simply meant to indicate that there is a ?generic? >> > bracket, brace, or line present. This is to give a visual hint, but >> > not a visual definition, to any software parsing the MEI file. Do you >> > have any examples of connecting symbols that are not one of these? >> > (Beyond those previously discussed by Laurent?) >> > >> > -Andrew >> > >> > On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n >> > > wrote: >> > >> > Hi Perry, >> > >> > It makes sense to separately encode the visual characteristics in a >> > child element, such as . Forgive me for my ignorance about >> > the existence of this element! >> > >> > However, I contemplate the problem of having too few values for @symbol. >> > >> > Consider the following statement: "there are N different symbols used >> > in the score that connect groups of staves". How would you encode the >> > staff groups if N>=4? >> > >> > Thanks >> > Zoltan >> > >> > >> > 2013/12/11 Roland, Perry (pdr4h) >> > > >> > >> > Hi Zoltan, >> > >> > >> > >> > Some elements (but not ) already allow @altsym, which >> > contains a pointer to a element that, in turn, contains >> > instructions on how to "draw" the symbol. This area of the schema >> > has not been exercised much and could therefore use a lot of work. >> > However, I think could be extended to contain SVG, >> > PostScript, etc. >> > >> > >> > >> > Turning to how this would work with , the @altsym attribute >> > doesn't actually belong on . It's the visual >> > characteristics of we're trying to capture, not those of >> > . I believe this is what Andrew's comment was intended to >> > mean. So, instead of , , which can be a child of >> > , should bear @altsym, e.g., >> > >> > >> > >> > >> > >> > >> > >> > > > >> > >> > >> > >> > >> > Although sometimes it can't be avoided, it's generally bad practice >> > to use attributes to describe other attributes. The usual way to >> > handle this is to "promote" an attribute to element status and then >> > give it its own attributes. That's what is doing. >> > >> > >> > >> > The element, however, still has the @symbol attribute with >> > the same values as when it's used on . In effect, >> > >> > >> > >> > >> > >> > >> > >> > is short-hand for >> > >> > >> > >> > . >> > >> > >> > >> > In other words, as in several places in MEI, it's possible to use >> > attributes for less-detail-oriented encodings (for example, when you >> > don't care what the brace looks like), but use elements when you do. >> > >> > >> > >> > -- >> > >> > 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 >> > [mei-l-bounces at lists.uni-paderborn.de> mei-l-bounces at lists.uni-paderborn.de>] on behalf of Zolt?n >> > K?m?ves >> > [zolaemil at gmail.com] >> > Sent: Wednesday, December 11, 2013 5:10 PM >> > >> > To: Music Encoding Initiative >> > Subject: Re: [MEI-L] Thin brackets in orchestral scores >> > >> > Hi Andrew, >> > >> > The grouping of staves is captured by the staffGrp elements without >> > specifying @symbol. @symbol captures additional information. I talk >> > about this additional content. >> > >> > Zoltan >> > ________________________________ >> > From: Andrew Hankinson >> > Sent: 2013.12.11. 20:45 >> > To: Music Encoding Initiative >> > Subject: Re: [MEI-L] Thin brackets in orchestral scores >> > >> > The intellectual content (?logical domain?) is the groups of staves, >> > not the symbol. >> > >> > On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n >> > > wrote: >> > >> > Hello, >> > >> > Would you mind to read my crazy thoughts about this issue? I'm just >> > curious what you people think of my thinking. >> > >> > I think the "intellectual content" in this case isn't so much how the >> > connecting symbols look, but the fact that the symbols are >> > *different*. >> > >> > The current values of @symbol already bear some sort of graphical >> > information, I think. The problem arose now, because it seems that >> > the current set of values don't provide a *complete" classification >> > (that is, in some cases there's no value which describes the symbol's >> > graphical shape appropriately). But of course, it's impossible to >> > provide a complete classification without degrading the markup to SVG. >> > >> > If we accept that the intellectual content is the *difference* >> > between the connecting symbols, then the proper separation of the >> > "intellectual content" from it's graphical representation would be to >> > use a set of values something like this: >> > >> > "symbol1", >> > "symbol2", >> > "symbol3", >> > etc. >> > >> > If one wanted to capture more info about their "look and feel", one >> > could use some pointing mechanism to point to a different element >> > that records the graphical info (possibly even pointing to an >> > external SVG...) >> > >> > I know, it's a crazy abstraction. And it may be way too abstract >> > compared to its practical use, and we could be better off adding a >> > handful of carefully defined values. >> > >> > Zoltan >> > >> > >> > >> > >> > >> > 2013/12/11 Laurent Pugin >> > > >> > It seems to me that adding "bracketsq" as a possible value would be >> > an appropriate addition. I don't think this particular case should >> > necessary open up a discussion on what is just typesetting or not. >> > >> > Laurent >> > >> > >> > On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) >> > > >> > wrote: >> > Yes, caution is advised. >> > >> > >> > -- >> > 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 >> > [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de> virginia.edu at lists.uni-paderborn.de>] on behalf of Johannes >> > Kepper >> > [kepper at edirom.de] >> > Sent: Wednesday, December 11, 2013 10:02 AM >> > >> > To: Music Encoding Initiative >> > Subject: Re: [MEI-L] Thin brackets in orchestral scores >> > >> > While there is certainly no harm in adding a well-defined set of >> > additional attribute values, the risk I see is that the distinction >> > between these values gets harder every time, eventually watering down >> > their expressiveness in terms of interchange. I'm not saying we're >> > reaching that point here, I'm just saying that we should be careful? >> > >> > >> > >> > Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) >> > >: >> > >> >> The "land of music typesetting" is always nearby, not unlike a 4th >> >> dimension hovering around us and within us. :-) Intellectual >> >> content and presentation are always difficult to separate. But try >> >> we must. >> >> >> >> There are already issues in the tracker related to @symbol -- nos. >> >> 180 & 182. >> >> >> >> From issue #180 -- "The top and bottom components of a bracket can >> >> be rendered as curved (similar to Unicode #x1D115) or straight >> >> (similar to Unicode #x0005B). The simplest method of dealing with >> >> this distinction is to add "bracketsq" (bracket square) to the >> >> values allowed by @symbol. "bracket" will continue to be used for >> >> the usual, curved musical bracket. The documentation should be >> >> edited to make the distinction clear." >> >> >> >> I won't attempt to reproduce #182 here, but it covers the selection >> >> of a value for @symbol that captures a line (often fairly wide) used >> >> to group systems instead of a brace or bracket. There's an image in >> >> #182 that illustrates various grouping symbols. >> >> >> >> Neither the so-called square bracket nor the >> >> wide-line-grouping-symbol can be encoded using @symbol="line" since >> >> that value is already reserved for the line connecting the staves at >> >> their left edge. I'm partial to the value "rule", but I'm open to >> >> suggestions. >> >> >> >> I see no harm in adding generic values like this to MEI because they >> >> are what I like to call "rendering hints" for the intellectual >> >> content -- in this case the staff group. But obviously this >> >> mechanism is not optimal for capturing all the visual details of the >> >> symbol, such as line width, color, position, etc. I am somewhat >> >> trepidatious about going too far down that road, at the end of which >> >> MEI becomes a re-definition of SVG. :-) >> >> >> >> Yes, there are still things to add to MEI. And, yes, this is an >> >> opportunity to do so. Now, if there were only more hours in the day >> >> ... >> >> >> >> -- >> >> 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 >> >> [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, December 11, 2013 8:47 AM >> >> To: Music Encoding Initiative >> >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> >> >> The reason why I feel slightly uneasy with this all is that it seems >> >> that we seem to enter the land of a music typesetting program here. >> >> In my ignorance about such details, I would probably encode that as >> >> a line, and ignore the fact that it is connected on both ends. In >> >> manuscripts, there would probably be no difference between this and >> >> either brackets or lines. But maybe you're right, and we should >> >> include the additional value. @Perry, do I remember correctly that >> >> you spotted some values in MusicXML not currently supported by MEI >> >> anyway? Is this an opportunity to revise them? >> >> >> >> jo >> >> >> >> >> >> >> >> Am 11.12.2013 um 14:39 schrieb Laurent Pugin >> >> >: >> >> >> >>> You are right, I think it is missing. >> >>> >> >>> There are actually a few of them in the examples, at least there is >> >>> this one (however with no representation in the encoding) >> >>> >> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >> >>> >> >>> Laurent >> >>> >> >>> >> >>> >> >>> On Wed, Dec 11, 2013 at 1:21 PM, TW >> >>> > wrote: >> >>> Laurent's post made me wonder whether we might be missing an >> >>> additional value for staffGrp/@symbol for the thin bracket that is >> >>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >> >>> the sample collection I didn't see anything like that (I didn't look >> >>> through all of them). >> >>> >> >>> Thomas >> >>> >> >>> >> >>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> >> Dr. Johannes Kepper >> >> BMBF-Projekt "Freisch?tz Digital" >> >> >> >> Musikwiss. Seminar Detmold / Paderborn >> >> Gartenstra?e 20 >> >> 32756 Detmold >> >> >> >> Tel. +49 5231 975669 >> >> 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 >> > >> > >> > >> > _______________________________________________ >> > 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 >> > >> > >> >> >> >> -- >> Donald Byrd >> Woodrow Wilson Indiana Teaching Fellow >> Adjunct Associate Professor of Informatics >> Visiting Scientist, Research Technologies >> 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 >> > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From donbyrd at indiana.edu Fri Dec 13 04:12:55 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Thu, 12 Dec 2013 22:12:55 -0500 Subject: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. In-Reply-To: References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> , <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> Message-ID: <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> Thanks, Perry. I was thinking of #3 and #5 as being basically square brackets, but they're really not that square :-) . I don't think I've seen any other shapes "in the wild" either. --DAB On Thu, 12 Dec 2013 19:10:27 +0000, "Roland, Perry (pdr4h)" wrote: > Hi Don, > > Finale provides 6 options in its "Group Attributes" dialog box. See > http://www.finalemusic.com/usermanuals/finale2012win/content/finale/GROUPDLG.htm. I think "bracket" accurately describes options 3, 5, & 6 (from the left), "brace" being used for option 4. I can't say that I've seen any other symbols "in > the > wild". > > (NB -- My mention of Finale doesn't constitute any kind of > endorsement. It's just that its documentation is easily accessible.) > > MEI currently offers only "none", "brace", "bracket", and "line" as > possibilities, where "line" is reserved for the thin line connecting > the score/system staves. These are sufficient to capture the broad > categories of symbols, but they (especially "bracket") don't provide > much in the way of visual detail. The question is, how/where should > that detail be located? > > My solution is to add "rule" and "bracketsq", representing Finale > options 2 and 6, respectively. This expands the level of visual > detail encapsulated in the @symbol attribute, but still doesn't > differentiate between options 3 and 5 or capture "typographical" > features (so-called 'hook' shape, color, line width, etc.). However, > it does provide the same level of granularity as MusicXML, enhancing > loss-less conversion to/from MEI. > > Of course, multiple typographical details can't be captured in a > single attribute value. And it's bad practice to add more attributes > to to comment on the value in @symbol. So, recording > those details necessitates a child of with its > own attributes. Those attributes can then be used to describe the > symbol in greater detail or point to a precise rendition stored > elsewhere. This mechanism can be used for any symbol used to group > staves, if someone does find an example outside the usual ones you > mention, for instance in a manuscript score. > > Not exactly what you asked for, but helpful nonetheless I hope, > > -- > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, > Donald A. [donbyrd at indiana.edu] > Sent: Thursday, December 12, 2013 1:21 PM > To: mei-l at lists.uni-paderborn.de > Subject: Re: [MEI-L] Thin brackets in orchestral scores > > Leaving aside nesting and details like thinness, as far as I know, the > _only_ symbols ever used to connect staves or groups of staves in CWMN > are (1) curly braces, (2) square brackets, and (3) a thin line -- the > last being used only to connect all the staves of a system. If there > are others, I'd love to see an example. > > --Don > > > On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson > wrote: > >> Hi Zoltan, >> >> There is no limit to the number of nested staff groups. However, if >> you have more than four nested staff groups, each with its own >> bracket style, your engraver should be fired! :) >> >> @symbol is simply meant to indicate that there is a ?generic? >> bracket, brace, or line present. This is to give a visual hint, but >> not a visual definition, to any software parsing the MEI file. Do you >> have any examples of connecting symbols that are not one of these? >> (Beyond those previously discussed by Laurent?) >> >> -Andrew >> >> On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n >> > wrote: >> >> Hi Perry, >> >> It makes sense to separately encode the visual characteristics in a >> child element, such as . Forgive me for my ignorance about >> the existence of this element! >> >> However, I contemplate the problem of having too few values for @symbol. >> >> Consider the following statement: "there are N different symbols used >> in the score that connect groups of staves". How would you encode the >> staff groups if N>=4? >> >> Thanks >> Zoltan >> >> >> 2013/12/11 Roland, Perry (pdr4h) >> > >> >> Hi Zoltan, >> >> >> >> Some elements (but not ) already allow @altsym, which >> contains a pointer to a element that, in turn, contains >> instructions on how to "draw" the symbol. This area of the schema >> has not been exercised much and could therefore use a lot of work. >> However, I think could be extended to contain SVG, >> PostScript, etc. >> >> >> >> Turning to how this would work with , the @altsym attribute >> doesn't actually belong on . It's the visual >> characteristics of we're trying to capture, not those of >> . I believe this is what Andrew's comment was intended to >> mean. So, instead of , , which can be a child of >> , should bear @altsym, e.g., >> >> >> >> >> >> >> >> > >> >> >> >> >> Although sometimes it can't be avoided, it's generally bad practice >> to use attributes to describe other attributes. The usual way to >> handle this is to "promote" an attribute to element status and then >> give it its own attributes. That's what is doing. >> >> >> >> The element, however, still has the @symbol attribute with >> the same values as when it's used on . In effect, >> >> >> >> >> >> >> >> is short-hand for >> >> >> >> . >> >> >> >> In other words, as in several places in MEI, it's possible to use >> attributes for less-detail-oriented encodings (for example, when you >> don't care what the brace looks like), but use elements when you do. >> >> >> >> -- >> >> 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 >> [mei-l-bounces at lists.uni-paderborn.de] on behalf >> of >> Zolt?n >> K?m?ves >> [zolaemil at gmail.com] >> Sent: Wednesday, December 11, 2013 5:10 PM >> >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> Hi Andrew, >> >> The grouping of staves is captured by the staffGrp elements without >> specifying @symbol. @symbol captures additional information. I talk >> about this additional content. >> >> Zoltan >> ________________________________ >> From: Andrew Hankinson >> Sent: 2013.12.11. 20:45 >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> The intellectual content (?logical domain?) is the groups of staves, >> not the symbol. >> >> On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n >> > wrote: >> >> Hello, >> >> Would you mind to read my crazy thoughts about this issue? I'm just >> curious what you people think of my thinking. >> >> I think the "intellectual content" in this case isn't so much how the >> connecting symbols look, but the fact that the symbols are >> *different*. >> >> The current values of @symbol already bear some sort of graphical >> information, I think. The problem arose now, because it seems that >> the current set of values don't provide a *complete" classification >> (that is, in some cases there's no value which describes the symbol's >> graphical shape appropriately). But of course, it's impossible to >> provide a complete classification without degrading the markup to SVG. >> >> If we accept that the intellectual content is the *difference* >> between the connecting symbols, then the proper separation of the >> "intellectual content" from it's graphical representation would be to >> use a set of values something like this: >> >> "symbol1", >> "symbol2", >> "symbol3", >> etc. >> >> If one wanted to capture more info about their "look and feel", one >> could use some pointing mechanism to point to a different element >> that records the graphical info (possibly even pointing to an >> external SVG...) >> >> I know, it's a crazy abstraction. And it may be way too abstract >> compared to its practical use, and we could be better off adding a >> handful of carefully defined values. >> >> Zoltan >> >> >> >> >> >> 2013/12/11 Laurent Pugin >> > >> It seems to me that adding "bracketsq" as a possible value would be >> an appropriate addition. I don't think this particular case should >> necessary open up a discussion on what is just typesetting or not. >> >> Laurent >> >> >> On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) >> > >> wrote: >> Yes, caution is advised. >> >> >> -- >> 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 >> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf >> of >> Johannes >> Kepper >> [kepper at edirom.de] >> Sent: Wednesday, December 11, 2013 10:02 AM >> >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> While there is certainly no harm in adding a well-defined set of >> additional attribute values, the risk I see is that the distinction >> between these values gets harder every time, eventually watering down >> their expressiveness in terms of interchange. I'm not saying we're >> reaching that point here, I'm just saying that we should be careful? >> >> >> >> Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) >> >: >> >>> The "land of music typesetting" is always nearby, not unlike a 4th >>> dimension hovering around us and within us. :-) Intellectual >>> content and presentation are always difficult to separate. But try >>> we must. >>> >>> There are already issues in the tracker related to @symbol -- nos. >>> 180 & 182. >>> >>> From issue #180 -- "The top and bottom components of a bracket can >>> be rendered as curved (similar to Unicode #x1D115) or straight >>> (similar to Unicode #x0005B). The simplest method of dealing with >>> this distinction is to add "bracketsq" (bracket square) to the >>> values allowed by @symbol. "bracket" will continue to be used for >>> the usual, curved musical bracket. The documentation should be >>> edited to make the distinction clear." >>> >>> I won't attempt to reproduce #182 here, but it covers the selection >>> of a value for @symbol that captures a line (often fairly wide) used >>> to group systems instead of a brace or bracket. There's an image in >>> #182 that illustrates various grouping symbols. >>> >>> Neither the so-called square bracket nor the >>> wide-line-grouping-symbol can be encoded using @symbol="line" since >>> that value is already reserved for the line connecting the staves at >>> their left edge. I'm partial to the value "rule", but I'm open to >>> suggestions. >>> >>> I see no harm in adding generic values like this to MEI because they >>> are what I like to call "rendering hints" for the intellectual >>> content -- in this case the staff group. But obviously this >>> mechanism is not optimal for capturing all the visual details of the >>> symbol, such as line width, color, position, etc. I am somewhat >>> trepidatious about going too far down that road, at the end of which >>> MEI becomes a re-definition of SVG. :-) >>> >>> Yes, there are still things to add to MEI. And, yes, this is an >>> opportunity to do so. Now, if there were only more hours in the day >>> ... >>> >>> -- >>> 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 >>> [mei-l-bounces at lists.uni-paderborn.de] on behalf >>> of >>> Johannes >>> Kepper >>> [kepper at edirom.de] >>> Sent: Wednesday, December 11, 2013 8:47 AM >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> >>> The reason why I feel slightly uneasy with this all is that it seems >>> that we seem to enter the land of a music typesetting program here. >>> In my ignorance about such details, I would probably encode that as >>> a line, and ignore the fact that it is connected on both ends. In >>> manuscripts, there would probably be no difference between this and >>> either brackets or lines. But maybe you're right, and we should >>> include the additional value. @Perry, do I remember correctly that >>> you spotted some values in MusicXML not currently supported by MEI >>> anyway? Is this an opportunity to revise them? >>> >>> jo >>> >>> >>> >>> Am 11.12.2013 um 14:39 schrieb Laurent Pugin >>> >: >>> >>>> You are right, I think it is missing. >>>> >>>> There are actually a few of them in the examples, at least there is >>>> this one (however with no representation in the encoding) >>>> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >>>> >>>> Laurent >>>> >>>> >>>> >>>> On Wed, Dec 11, 2013 at 1:21 PM, TW >>>> > wrote: >>>> Laurent's post made me wonder whether we might be missing an >>>> additional value for staffGrp/@symbol for the thin bracket that is >>>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >>>> the sample collection I didn't see anything like that (I didn't look >>>> through all of them). >>>> >>>> Thomas >>>> >>>> >>>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >>>> >>>> _______________________________________________ >>>> 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 >>> >>> Dr. Johannes Kepper >>> BMBF-Projekt "Freisch?tz Digital" >>> >>> Musikwiss. Seminar Detmold / Paderborn >>> Gartenstra?e 20 >>> 32756 Detmold >>> >>> Tel. +49 5231 975669 >>> 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 >> >> >> >> _______________________________________________ >> 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 > -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington From donbyrd at indiana.edu Fri Dec 13 04:23:47 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Thu, 12 Dec 2013 22:23:47 -0500 Subject: [MEI-L] thin [& other] brackets [& braces] in orchestral scores In-Reply-To: References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <13820_1386879719_52AA1AE6_13820_326_4_BBCC497C40D85642B90E9F94FC30343D32B554B5@grant1.eservices.virginia.edu> Message-ID: <20131212222347.trvwbi36k8wg0084@webmail.iu.edu> First, I should revise my claim earlier today that the only possible shapes are square brackets, (curly) braces, and a single line to include squarish brackets with flared ends. (The "curly" for braces can be omitted; I believe braces are curly by definition.) And yes, some square brackets are thinner than others :-) . I just looked thru a bunch of orchestral scores on my shelf -- Bach, Beethoven, Berg, Berlioz, Debussy, Elgar, Haydn, Hindemith, Mahler, Mendelssohn, Mozart, Rimsky-Korsakov, Schoenberg, Schumann, Stravinsky, and Tchaikovsky. I also checked Elaine Gould's _Behind Bars_, which claims -- probably justifiably -- to be "the definitive guide to music notation". I've always thought that the differences in shapes are purely a matter of style and carry no information whatever; both the scores I looked at and what Gould says support that. Though there_are_ standard practices -- e.g., if a single instrument has multiple staves, they're generally connected with a brace, and never with a square bracket. Braces _may_ be used to group, e.g., 1st and 2nd violins, but square brackets (perhaps with flared ends, perhaps thin) are preferred nowadays. --DAB On Thu, 12 Dec 2013 22:19:47 +0100, Laurent Pugin wrote: > Hi Raffaele, > > I agree we should keep the list of options as short as possible, and I > don't think there is any intention here to extend it widely. The line > between what has a different function and what it "just" representation in > music notation is always difficulty to draw ;-) I am not sure there is a > deep functional difference between brace and bracket, but I might be wrong. > > Laurent > > > On Thu, Dec 12, 2013 at 9:21 PM, Roland, Perry (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > >> Hi Raffaele, >> >> >> > Example >> > MEI: these staves are grouped. This group has and id "grp1" >> > Other system: the class "stave brackets" has to be rendered according to >> this routine. Apply >> > it to MEI element #grp1. Also, #grp1 is a special case, so tweak this >> parameter a bit. >> > I feel strongly that MEI ought to be fully agnostic of the "other >> system" in the example. >> >> I agree with you. In so far as it's practical, MEI should remain agnostic >> about many things. However, as yet there is nothing like CSS for music >> notation, so we're left to deal with a wide range of so-called "other >> systems" for rendition. I regard the attribute values we've been >> discussing as parameters to those other systems. This is why I refer to >> them as "hints". >> >> I don't think, however, we can ignore those cases where the encoder has a >> very definite symbol in mind and wishes to provide an exemplar, e.g., in >> the case of so-called "non-standard" symbols. We should also keep in mind >> the possibility of MEI functioning as an intermediate representation >> *between systems* at a level beyond "there's a bracket here, draw one of >> your choosing". While, as Zoltan said, MEI != SVG, I believe there are >> cases where the possibility of passing a precise rendition to a down-stream >> application would be very useful. The combination of @altsym and >> provides for these cases. >> >> Since it aims to standardize the musical symbol repertoire, I believe a >> SMuFL codepoint could be appropriate content of , similar to the >> way Unicode codepoints can be referenced by TEI elements. SVG, >> PostScript, or other graphic description languages could also be >> appropriate content. >> >> I don't characterize this as "degrading MEI to SVG" (one of my new >> favorite phrases), but rather as practical employment of existing >> standards. I also don't think it diminishes MEI's level of/commitment >> to agnosticism. >> >> -- >> 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of >> Raffaele Viglianti [raffaeleviglianti at gmail.com] >> *Sent:* Thursday, December 12, 2013 2:22 PM >> >> *To:* Music Encoding Initiative >> *Subject:* Re: [MEI-L] Thin brackets in orchestral scores >> >> On Thu, Dec 12, 2013 at 2:10 PM, Roland, Perry (pdr4h) < >> pdr4h at eservices.virginia.edu> wrote: >>> >>> >>> So, recording those details necessitates a child of >>> with its own attributes. Those attributes can then be used to describe the >>> symbol in greater detail or point to a precise rendition stored elsewhere. >>> >> >> I would keep the options as limited as possible. Micah is right: we >> should introduce a new symbol only if it translates to a different >> function, otherwise MEI should not bother: we are not doing typesetting >> (even while we acknowledge it as a 4th, hovering, dimension). >> >> Wouldn't it be best having other standards pointing at a semantic MEI >> elements to provide a rendition, rather than adding a pointing mechanisms >> from MEI? >> >> Example >> MEI: these staves are grouped. This group has and id "grp1" >> Other system: the class "stave brackets" has to be rendered according to >> this routine. Apply it to MEI element #grp1. Also, #grp1 is a special case, >> so tweak this parameter a bit. >> >> I feel strongly that MEI ought to be fully agnostic of the "other >> system" in the example. >> >> Raf >> >> >> >>> >>> -- >>> 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, >>> Donald A. [donbyrd at indiana.edu] >>> Sent: Thursday, December 12, 2013 1:21 PM >>> To: mei-l at lists.uni-paderborn.de >>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> >>> Leaving aside nesting and details like thinness, as far as I know, the >>> _only_ symbols ever used to connect staves or groups of staves in CWMN >>> are (1) curly braces, (2) square brackets, and (3) a thin line -- the >>> last being used only to connect all the staves of a system. If there >>> are others, I'd love to see an example. >>> >>> --Don >>> >>> >>> On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson >>> wrote: >>> >>> > Hi Zoltan, >>> > >>> > There is no limit to the number of nested staff groups. However, if >>> > you have more than four nested staff groups, each with its own >>> > bracket style, your engraver should be fired! :) >>> > >>> > @symbol is simply meant to indicate that there is a ?generic? >>> > bracket, brace, or line present. This is to give a visual hint, but >>> > not a visual definition, to any software parsing the MEI file. Do you >>> > have any examples of connecting symbols that are not one of these? >>> > (Beyond those previously discussed by Laurent?) >>> > >>> > -Andrew >>> > >>> > On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n >>> > > wrote: >>> > >>> > Hi Perry, >>> > >>> > It makes sense to separately encode the visual characteristics in a >>> > child element, such as . Forgive me for my ignorance about >>> > the existence of this element! >>> > >>> > However, I contemplate the problem of having too few values for @symbol. >>> > >>> > Consider the following statement: "there are N different symbols used >>> > in the score that connect groups of staves". How would you encode the >>> > staff groups if N>=4? >>> > >>> > Thanks >>> > Zoltan >>> > >>> > >>> > 2013/12/11 Roland, Perry (pdr4h) >>> > > >>> > >>> > Hi Zoltan, >>> > >>> > >>> > >>> > Some elements (but not ) already allow @altsym, which >>> > contains a pointer to a element that, in turn, contains >>> > instructions on how to "draw" the symbol. This area of the schema >>> > has not been exercised much and could therefore use a lot of work. >>> > However, I think could be extended to contain SVG, >>> > PostScript, etc. >>> > >>> > >>> > >>> > Turning to how this would work with , the @altsym attribute >>> > doesn't actually belong on . It's the visual >>> > characteristics of we're trying to capture, not those of >>> > . I believe this is what Andrew's comment was intended to >>> > mean. So, instead of , , which can be a child of >>> > , should bear @altsym, e.g., >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >>> > >>> > >>> > >>> > >>> > Although sometimes it can't be avoided, it's generally bad practice >>> > to use attributes to describe other attributes. The usual way to >>> > handle this is to "promote" an attribute to element status and then >>> > give it its own attributes. That's what is doing. >>> > >>> > >>> > >>> > The element, however, still has the @symbol attribute with >>> > the same values as when it's used on . In effect, >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > is short-hand for >>> > >>> > >>> > >>> > . >>> > >>> > >>> > >>> > In other words, as in several places in MEI, it's possible to use >>> > attributes for less-detail-oriented encodings (for example, when you >>> > don't care what the brace looks like), but use elements when you do. >>> > >>> > >>> > >>> > -- >>> > >>> > 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 >>> > [mei-l-bounces at lists.uni-paderborn.de>> mei-l-bounces at lists.uni-paderborn.de>] on behalf of Zolt?n >>> > K?m?ves >>> > [zolaemil at gmail.com] >>> > Sent: Wednesday, December 11, 2013 5:10 PM >>> > >>> > To: Music Encoding Initiative >>> > Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> > >>> > Hi Andrew, >>> > >>> > The grouping of staves is captured by the staffGrp elements without >>> > specifying @symbol. @symbol captures additional information. I talk >>> > about this additional content. >>> > >>> > Zoltan >>> > ________________________________ >>> > From: Andrew Hankinson >>> > Sent: 2013.12.11. 20:45 >>> > To: Music Encoding Initiative >>> > Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> > >>> > The intellectual content (?logical domain?) is the groups of staves, >>> > not the symbol. >>> > >>> > On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n >>> > > wrote: >>> > >>> > Hello, >>> > >>> > Would you mind to read my crazy thoughts about this issue? I'm just >>> > curious what you people think of my thinking. >>> > >>> > I think the "intellectual content" in this case isn't so much how the >>> > connecting symbols look, but the fact that the symbols are >>> > *different*. >>> > >>> > The current values of @symbol already bear some sort of graphical >>> > information, I think. The problem arose now, because it seems that >>> > the current set of values don't provide a *complete" classification >>> > (that is, in some cases there's no value which describes the symbol's >>> > graphical shape appropriately). But of course, it's impossible to >>> > provide a complete classification without degrading the markup to SVG. >>> > >>> > If we accept that the intellectual content is the *difference* >>> > between the connecting symbols, then the proper separation of the >>> > "intellectual content" from it's graphical representation would be to >>> > use a set of values something like this: >>> > >>> > "symbol1", >>> > "symbol2", >>> > "symbol3", >>> > etc. >>> > >>> > If one wanted to capture more info about their "look and feel", one >>> > could use some pointing mechanism to point to a different element >>> > that records the graphical info (possibly even pointing to an >>> > external SVG...) >>> > >>> > I know, it's a crazy abstraction. And it may be way too abstract >>> > compared to its practical use, and we could be better off adding a >>> > handful of carefully defined values. >>> > >>> > Zoltan >>> > >>> > >>> > >>> > >>> > >>> > 2013/12/11 Laurent Pugin >>> > > >>> > It seems to me that adding "bracketsq" as a possible value would be >>> > an appropriate addition. I don't think this particular case should >>> > necessary open up a discussion on what is just typesetting or not. >>> > >>> > Laurent >>> > >>> > >>> > On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) >>> > > >>> > wrote: >>> > Yes, caution is advised. >>> > >>> > >>> > -- >>> > 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 >>> > [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de>> virginia.edu at lists.uni-paderborn.de>] on behalf of Johannes >>> > Kepper >>> > [kepper at edirom.de] >>> > Sent: Wednesday, December 11, 2013 10:02 AM >>> > >>> > To: Music Encoding Initiative >>> > Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> > >>> > While there is certainly no harm in adding a well-defined set of >>> > additional attribute values, the risk I see is that the distinction >>> > between these values gets harder every time, eventually watering down >>> > their expressiveness in terms of interchange. I'm not saying we're >>> > reaching that point here, I'm just saying that we should be careful? >>> > >>> > >>> > >>> > Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) >>> > >: >>> > >>> >> The "land of music typesetting" is always nearby, not unlike a 4th >>> >> dimension hovering around us and within us. :-) Intellectual >>> >> content and presentation are always difficult to separate. But try >>> >> we must. >>> >> >>> >> There are already issues in the tracker related to @symbol -- nos. >>> >> 180 & 182. >>> >> >>> >> From issue #180 -- "The top and bottom components of a bracket can >>> >> be rendered as curved (similar to Unicode #x1D115) or straight >>> >> (similar to Unicode #x0005B). The simplest method of dealing with >>> >> this distinction is to add "bracketsq" (bracket square) to the >>> >> values allowed by @symbol. "bracket" will continue to be used for >>> >> the usual, curved musical bracket. The documentation should be >>> >> edited to make the distinction clear." >>> >> >>> >> I won't attempt to reproduce #182 here, but it covers the selection >>> >> of a value for @symbol that captures a line (often fairly wide) used >>> >> to group systems instead of a brace or bracket. There's an image in >>> >> #182 that illustrates various grouping symbols. >>> >> >>> >> Neither the so-called square bracket nor the >>> >> wide-line-grouping-symbol can be encoded using @symbol="line" since >>> >> that value is already reserved for the line connecting the staves at >>> >> their left edge. I'm partial to the value "rule", but I'm open to >>> >> suggestions. >>> >> >>> >> I see no harm in adding generic values like this to MEI because they >>> >> are what I like to call "rendering hints" for the intellectual >>> >> content -- in this case the staff group. But obviously this >>> >> mechanism is not optimal for capturing all the visual details of the >>> >> symbol, such as line width, color, position, etc. I am somewhat >>> >> trepidatious about going too far down that road, at the end of which >>> >> MEI becomes a re-definition of SVG. :-) >>> >> >>> >> Yes, there are still things to add to MEI. And, yes, this is an >>> >> opportunity to do so. Now, if there were only more hours in the day >>> >> ... >>> >> >>> >> -- >>> >> 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 >>> >> [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, December 11, 2013 8:47 AM >>> >> To: Music Encoding Initiative >>> >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> >> >>> >> The reason why I feel slightly uneasy with this all is that it seems >>> >> that we seem to enter the land of a music typesetting program here. >>> >> In my ignorance about such details, I would probably encode that as >>> >> a line, and ignore the fact that it is connected on both ends. In >>> >> manuscripts, there would probably be no difference between this and >>> >> either brackets or lines. But maybe you're right, and we should >>> >> include the additional value. @Perry, do I remember correctly that >>> >> you spotted some values in MusicXML not currently supported by MEI >>> >> anyway? Is this an opportunity to revise them? >>> >> >>> >> jo >>> >> >>> >> >>> >> >>> >> Am 11.12.2013 um 14:39 schrieb Laurent Pugin >>> >> >: >>> >> >>> >>> You are right, I think it is missing. >>> >>> >>> >>> There are actually a few of them in the examples, at least there is >>> >>> this one (however with no representation in the encoding) >>> >>> >>> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >>> >>> >>> >>> Laurent >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Dec 11, 2013 at 1:21 PM, TW >>> >>> > wrote: >>> >>> Laurent's post made me wonder whether we might be missing an >>> >>> additional value for staffGrp/@symbol for the thin bracket that is >>> >>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >>> >>> the sample collection I didn't see anything like that (I didn't look >>> >>> through all of them). >>> >>> >>> >>> Thomas >>> >>> >>> >>> >>> >>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >> >>> >> Dr. Johannes Kepper >>> >> BMBF-Projekt "Freisch?tz Digital" >>> >> >>> >> Musikwiss. Seminar Detmold / Paderborn >>> >> Gartenstra?e 20 >>> >> 32756 Detmold >>> >> >>> >> Tel. +49 5231 975669 >>> >> 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 >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> > >>> > >>> >>> >>> >>> -- >>> Donald Byrd >>> Woodrow Wilson Indiana Teaching Fellow >>> Adjunct Associate Professor of Informatics >>> Visiting Scientist, Research Technologies >>> 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 >>> >> >> >> _______________________________________________ >> 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 Visiting Scientist, Research Technologies Indiana University Bloomington From laurent at music.mcgill.ca Fri Dec 13 09:33:18 2013 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Fri, 13 Dec 2013 09:33:18 +0100 Subject: [MEI-L] Thin brackets in orchestral scores In-Reply-To: References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <13820_1386879719_52AA1AE6_13820_326_4_BBCC497C40D85642B90E9F94FC30343D32B554B5@grant1.eservices.virginia.edu> Message-ID: Don: yes, this makes sense. Historically, we can probably argue that brackets became the standard practice for grouping instruments as the consequence of being more convenient to print, especially with many staves - whereas braces are easier to write by hand. In handwritten manuscripts, we most of the time find braces including for orchestral scores. As an example, the autograph of Bach's mass in B-minor has braces for grouping any set of instruments/voices when there is more than one system on the page - otherwise there is nothing. In the first prints of the mass, we will find brackets. Actually, even in the very first printed scores in the late 16th or early 17h centuries, where anything is used to represent grouping of the system (most of the time there is nothing), a line or a bracket is mostly used. And we can see brackets in 18th century keyboard music prints printed in typography, again because this was probably easier to print. Braces remained in use and became a standard practice for grouping two or three staves, indeed most of the time for instruments written on multiple staves. Thin square brackets are obviously a later addition in large orchestral scores. One example http://pds.lib.harvard.edu/pds/view/17525736 Laurent On Thu, Dec 12, 2013 at 10:19 PM, Laurent Pugin wrote: > Hi Raffaele, > > I agree we should keep the list of options as short as possible, and I > don't think there is any intention here to extend it widely. The line > between what has a different function and what it "just" representation in > music notation is always difficulty to draw ;-) I am not sure there is a > deep functional difference between brace and bracket, but I might be wrong. > > Laurent > > > On Thu, Dec 12, 2013 at 9:21 PM, Roland, Perry (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > >> Hi Raffaele, >> >> >> > Example >> > MEI: these staves are grouped. This group has and id "grp1" >> > Other system: the class "stave brackets" has to be rendered according >> to this routine. Apply >> > it to MEI element #grp1. Also, #grp1 is a special case, so tweak this >> parameter a bit. >> > I feel strongly that MEI ought to be fully agnostic of the "other >> system" in the example. >> >> I agree with you. In so far as it's practical, MEI should remain >> agnostic about many things. However, as yet there is nothing like CSS for >> music notation, so we're left to deal with a wide range of so-called "other >> systems" for rendition. I regard the attribute values we've been >> discussing as parameters to those other systems. This is why I refer to >> them as "hints". >> >> I don't think, however, we can ignore those cases where the encoder has a >> very definite symbol in mind and wishes to provide an exemplar, e.g., in >> the case of so-called "non-standard" symbols. We should also keep in mind >> the possibility of MEI functioning as an intermediate representation >> *between systems* at a level beyond "there's a bracket here, draw one of >> your choosing". While, as Zoltan said, MEI != SVG, I believe there are >> cases where the possibility of passing a precise rendition to a down-stream >> application would be very useful. The combination of @altsym and >> provides for these cases. >> >> Since it aims to standardize the musical symbol repertoire, I believe a >> SMuFL codepoint could be appropriate content of , similar to the >> way Unicode codepoints can be referenced by TEI elements. SVG, >> PostScript, or other graphic description languages could also be >> appropriate content. >> >> I don't characterize this as "degrading MEI to SVG" (one of my new >> favorite phrases), but rather as practical employment of existing >> standards. I also don't think it diminishes MEI's level of/commitment >> to agnosticism. >> >> -- >> 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of >> Raffaele Viglianti [raffaeleviglianti at gmail.com] >> *Sent:* Thursday, December 12, 2013 2:22 PM >> >> *To:* Music Encoding Initiative >> *Subject:* Re: [MEI-L] Thin brackets in orchestral scores >> >> On Thu, Dec 12, 2013 at 2:10 PM, Roland, Perry (pdr4h) < >> pdr4h at eservices.virginia.edu> wrote: >>> >>> >>> So, recording those details necessitates a child of >>> with its own attributes. Those attributes can then be used to describe the >>> symbol in greater detail or point to a precise rendition stored elsewhere. >>> >> >> I would keep the options as limited as possible. Micah is right: we >> should introduce a new symbol only if it translates to a different >> function, otherwise MEI should not bother: we are not doing typesetting >> (even while we acknowledge it as a 4th, hovering, dimension). >> >> Wouldn't it be best having other standards pointing at a semantic MEI >> elements to provide a rendition, rather than adding a pointing mechanisms >> from MEI? >> >> Example >> MEI: these staves are grouped. This group has and id "grp1" >> Other system: the class "stave brackets" has to be rendered according to >> this routine. Apply it to MEI element #grp1. Also, #grp1 is a special case, >> so tweak this parameter a bit. >> >> I feel strongly that MEI ought to be fully agnostic of the "other >> system" in the example. >> >> Raf >> >> >> >>> >>> -- >>> 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, >>> Donald A. [donbyrd at indiana.edu] >>> Sent: Thursday, December 12, 2013 1:21 PM >>> To: mei-l at lists.uni-paderborn.de >>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> >>> Leaving aside nesting and details like thinness, as far as I know, the >>> _only_ symbols ever used to connect staves or groups of staves in CWMN >>> are (1) curly braces, (2) square brackets, and (3) a thin line -- the >>> last being used only to connect all the staves of a system. If there >>> are others, I'd love to see an example. >>> >>> --Don >>> >>> >>> On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson >>> wrote: >>> >>> > Hi Zoltan, >>> > >>> > There is no limit to the number of nested staff groups. However, if >>> > you have more than four nested staff groups, each with its own >>> > bracket style, your engraver should be fired! :) >>> > >>> > @symbol is simply meant to indicate that there is a ?generic? >>> > bracket, brace, or line present. This is to give a visual hint, but >>> > not a visual definition, to any software parsing the MEI file. Do you >>> > have any examples of connecting symbols that are not one of these? >>> > (Beyond those previously discussed by Laurent?) >>> > >>> > -Andrew >>> > >>> > On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n >>> > > wrote: >>> > >>> > Hi Perry, >>> > >>> > It makes sense to separately encode the visual characteristics in a >>> > child element, such as . Forgive me for my ignorance about >>> > the existence of this element! >>> > >>> > However, I contemplate the problem of having too few values for >>> @symbol. >>> > >>> > Consider the following statement: "there are N different symbols used >>> > in the score that connect groups of staves". How would you encode the >>> > staff groups if N>=4? >>> > >>> > Thanks >>> > Zoltan >>> > >>> > >>> > 2013/12/11 Roland, Perry (pdr4h) >>> > > >>> > >>> > Hi Zoltan, >>> > >>> > >>> > >>> > Some elements (but not ) already allow @altsym, which >>> > contains a pointer to a element that, in turn, contains >>> > instructions on how to "draw" the symbol. This area of the schema >>> > has not been exercised much and could therefore use a lot of work. >>> > However, I think could be extended to contain SVG, >>> > PostScript, etc. >>> > >>> > >>> > >>> > Turning to how this would work with , the @altsym attribute >>> > doesn't actually belong on . It's the visual >>> > characteristics of we're trying to capture, not those of >>> > . I believe this is what Andrew's comment was intended to >>> > mean. So, instead of , , which can be a child of >>> > , should bear @altsym, e.g., >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >>> > >>> > >>> > >>> > >>> > Although sometimes it can't be avoided, it's generally bad practice >>> > to use attributes to describe other attributes. The usual way to >>> > handle this is to "promote" an attribute to element status and then >>> > give it its own attributes. That's what is doing. >>> > >>> > >>> > >>> > The element, however, still has the @symbol attribute with >>> > the same values as when it's used on . In effect, >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > is short-hand for >>> > >>> > >>> > >>> > . >>> > >>> > >>> > >>> > In other words, as in several places in MEI, it's possible to use >>> > attributes for less-detail-oriented encodings (for example, when you >>> > don't care what the brace looks like), but use elements when you do. >>> > >>> > >>> > >>> > -- >>> > >>> > 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 >>> > [mei-l-bounces at lists.uni-paderborn.de>> mei-l-bounces at lists.uni-paderborn.de>] on behalf of Zolt?n >>> > K?m?ves >>> > [zolaemil at gmail.com] >>> > Sent: Wednesday, December 11, 2013 5:10 PM >>> > >>> > To: Music Encoding Initiative >>> > Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> > >>> > Hi Andrew, >>> > >>> > The grouping of staves is captured by the staffGrp elements without >>> > specifying @symbol. @symbol captures additional information. I talk >>> > about this additional content. >>> > >>> > Zoltan >>> > ________________________________ >>> > From: Andrew Hankinson >>> > Sent: 2013.12.11. 20:45 >>> > To: Music Encoding Initiative >>> > Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> > >>> > The intellectual content (?logical domain?) is the groups of staves, >>> > not the symbol. >>> > >>> > On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n >>> > > wrote: >>> > >>> > Hello, >>> > >>> > Would you mind to read my crazy thoughts about this issue? I'm just >>> > curious what you people think of my thinking. >>> > >>> > I think the "intellectual content" in this case isn't so much how the >>> > connecting symbols look, but the fact that the symbols are >>> > *different*. >>> > >>> > The current values of @symbol already bear some sort of graphical >>> > information, I think. The problem arose now, because it seems that >>> > the current set of values don't provide a *complete" classification >>> > (that is, in some cases there's no value which describes the symbol's >>> > graphical shape appropriately). But of course, it's impossible to >>> > provide a complete classification without degrading the markup to SVG. >>> > >>> > If we accept that the intellectual content is the *difference* >>> > between the connecting symbols, then the proper separation of the >>> > "intellectual content" from it's graphical representation would be to >>> > use a set of values something like this: >>> > >>> > "symbol1", >>> > "symbol2", >>> > "symbol3", >>> > etc. >>> > >>> > If one wanted to capture more info about their "look and feel", one >>> > could use some pointing mechanism to point to a different element >>> > that records the graphical info (possibly even pointing to an >>> > external SVG...) >>> > >>> > I know, it's a crazy abstraction. And it may be way too abstract >>> > compared to its practical use, and we could be better off adding a >>> > handful of carefully defined values. >>> > >>> > Zoltan >>> > >>> > >>> > >>> > >>> > >>> > 2013/12/11 Laurent Pugin >>> > > >>> > It seems to me that adding "bracketsq" as a possible value would be >>> > an appropriate addition. I don't think this particular case should >>> > necessary open up a discussion on what is just typesetting or not. >>> > >>> > Laurent >>> > >>> > >>> > On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) >>> > > >>> > wrote: >>> > Yes, caution is advised. >>> > >>> > >>> > -- >>> > 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 >>> > [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de>> virginia.edu at lists.uni-paderborn.de>] on behalf of Johannes >>> > Kepper >>> > [kepper at edirom.de] >>> > Sent: Wednesday, December 11, 2013 10:02 AM >>> > >>> > To: Music Encoding Initiative >>> > Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> > >>> > While there is certainly no harm in adding a well-defined set of >>> > additional attribute values, the risk I see is that the distinction >>> > between these values gets harder every time, eventually watering down >>> > their expressiveness in terms of interchange. I'm not saying we're >>> > reaching that point here, I'm just saying that we should be careful? >>> > >>> > >>> > >>> > Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) >>> > >: >>> > >>> >> The "land of music typesetting" is always nearby, not unlike a 4th >>> >> dimension hovering around us and within us. :-) Intellectual >>> >> content and presentation are always difficult to separate. But try >>> >> we must. >>> >> >>> >> There are already issues in the tracker related to @symbol -- nos. >>> >> 180 & 182. >>> >> >>> >> From issue #180 -- "The top and bottom components of a bracket can >>> >> be rendered as curved (similar to Unicode #x1D115) or straight >>> >> (similar to Unicode #x0005B). The simplest method of dealing with >>> >> this distinction is to add "bracketsq" (bracket square) to the >>> >> values allowed by @symbol. "bracket" will continue to be used for >>> >> the usual, curved musical bracket. The documentation should be >>> >> edited to make the distinction clear." >>> >> >>> >> I won't attempt to reproduce #182 here, but it covers the selection >>> >> of a value for @symbol that captures a line (often fairly wide) used >>> >> to group systems instead of a brace or bracket. There's an image in >>> >> #182 that illustrates various grouping symbols. >>> >> >>> >> Neither the so-called square bracket nor the >>> >> wide-line-grouping-symbol can be encoded using @symbol="line" since >>> >> that value is already reserved for the line connecting the staves at >>> >> their left edge. I'm partial to the value "rule", but I'm open to >>> >> suggestions. >>> >> >>> >> I see no harm in adding generic values like this to MEI because they >>> >> are what I like to call "rendering hints" for the intellectual >>> >> content -- in this case the staff group. But obviously this >>> >> mechanism is not optimal for capturing all the visual details of the >>> >> symbol, such as line width, color, position, etc. I am somewhat >>> >> trepidatious about going too far down that road, at the end of which >>> >> MEI becomes a re-definition of SVG. :-) >>> >> >>> >> Yes, there are still things to add to MEI. And, yes, this is an >>> >> opportunity to do so. Now, if there were only more hours in the day >>> >> ... >>> >> >>> >> -- >>> >> 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 >>> >> [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, December 11, 2013 8:47 AM >>> >> To: Music Encoding Initiative >>> >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> >> >>> >> The reason why I feel slightly uneasy with this all is that it seems >>> >> that we seem to enter the land of a music typesetting program here. >>> >> In my ignorance about such details, I would probably encode that as >>> >> a line, and ignore the fact that it is connected on both ends. In >>> >> manuscripts, there would probably be no difference between this and >>> >> either brackets or lines. But maybe you're right, and we should >>> >> include the additional value. @Perry, do I remember correctly that >>> >> you spotted some values in MusicXML not currently supported by MEI >>> >> anyway? Is this an opportunity to revise them? >>> >> >>> >> jo >>> >> >>> >> >>> >> >>> >> Am 11.12.2013 um 14:39 schrieb Laurent Pugin >>> >> >: >>> >> >>> >>> You are right, I think it is missing. >>> >>> >>> >>> There are actually a few of them in the examples, at least there is >>> >>> this one (however with no representation in the encoding) >>> >>> >>> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >>> >>> >>> >>> Laurent >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Dec 11, 2013 at 1:21 PM, TW >>> >>> > wrote: >>> >>> Laurent's post made me wonder whether we might be missing an >>> >>> additional value for staffGrp/@symbol for the thin bracket that is >>> >>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >>> >>> the sample collection I didn't see anything like that (I didn't look >>> >>> through all of them). >>> >>> >>> >>> Thomas >>> >>> >>> >>> >>> >>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >> >>> >> Dr. Johannes Kepper >>> >> BMBF-Projekt "Freisch?tz Digital" >>> >> >>> >> Musikwiss. Seminar Detmold / Paderborn >>> >> Gartenstra?e 20 >>> >> 32756 Detmold >>> >> >>> >> Tel. +49 5231 975669 >>> >> 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 >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> > >>> > >>> >>> >>> >>> -- >>> Donald Byrd >>> Woodrow Wilson Indiana Teaching Fellow >>> Adjunct Associate Professor of Informatics >>> Visiting Scientist, Research Technologies >>> 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 >>> >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >> >> > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From veit at weber-gesamtausgabe.de Sun Dec 15 00:38:29 2013 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Sun, 15 Dec 2013 00:38:29 +0100 Subject: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. In-Reply-To: <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> , <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> Message-ID: <52ACEBF5.8010602@weber-gesamtausgabe.de> Only a short "a parte": The form of the "thin square brackets" (Finale's option 6) is very often to be found (not only in Berlioz' example) in new Schott-Scores (e.g. in the new Schumann Complete edition). In the Weber edition we use them only in a very few special cases (I don't like them really...) Thanks for the interesting discussion! and best greetings, Joachim Am 13.12.13 04:12, schrieb Byrd, Donald A.: > Thanks, Perry. I was thinking of #3 and #5 as being basically square > brackets, but they're really not that square :-) . I don't think I've > seen any other shapes "in the wild" either. > > --DAB > > > On Thu, 12 Dec 2013 19:10:27 +0000, "Roland, Perry (pdr4h)" > wrote: > >> Hi Don, >> >> Finale provides 6 options in its "Group Attributes" dialog box. See >> http://www.finalemusic.com/usermanuals/finale2012win/content/finale/GROUPDLG.htm. >> I think "bracket" accurately describes options 3, 5, & 6 (from the >> left), "brace" being used for option 4. I can't say that I've seen >> any other symbols "in the >> wild". >> >> (NB -- My mention of Finale doesn't constitute any kind of >> endorsement. It's just that its documentation is easily accessible.) >> >> MEI currently offers only "none", "brace", "bracket", and "line" as >> possibilities, where "line" is reserved for the thin line connecting >> the score/system staves. These are sufficient to capture the broad >> categories of symbols, but they (especially "bracket") don't provide >> much in the way of visual detail. The question is, how/where should >> that detail be located? >> >> My solution is to add "rule" and "bracketsq", representing Finale >> options 2 and 6, respectively. This expands the level of visual >> detail encapsulated in the @symbol attribute, but still doesn't >> differentiate between options 3 and 5 or capture "typographical" >> features (so-called 'hook' shape, color, line width, etc.). However, >> it does provide the same level of granularity as MusicXML, enhancing >> loss-less conversion to/from MEI. >> >> Of course, multiple typographical details can't be captured in a >> single attribute value. And it's bad practice to add more attributes >> to to comment on the value in @symbol. So, recording >> those details necessitates a child of with its >> own attributes. Those attributes can then be used to describe the >> symbol in greater detail or point to a precise rendition stored >> elsewhere. This mechanism can be used for any symbol used to group >> staves, if someone does find an example outside the usual ones you >> mention, for instance in a manuscript score. >> >> Not exactly what you asked for, but helpful nonetheless I hope, >> >> -- >> 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, >> Donald A. [donbyrd at indiana.edu] >> Sent: Thursday, December 12, 2013 1:21 PM >> To: mei-l at lists.uni-paderborn.de >> Subject: Re: [MEI-L] Thin brackets in orchestral scores >> >> Leaving aside nesting and details like thinness, as far as I know, the >> _only_ symbols ever used to connect staves or groups of staves in CWMN >> are (1) curly braces, (2) square brackets, and (3) a thin line -- the >> last being used only to connect all the staves of a system. If there >> are others, I'd love to see an example. >> >> --Don >> >> >> On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson >> wrote: >> >>> Hi Zoltan, >>> >>> There is no limit to the number of nested staff groups. However, if >>> you have more than four nested staff groups, each with its own >>> bracket style, your engraver should be fired! :) >>> >>> @symbol is simply meant to indicate that there is a ?generic? >>> bracket, brace, or line present. This is to give a visual hint, but >>> not a visual definition, to any software parsing the MEI file. Do you >>> have any examples of connecting symbols that are not one of these? >>> (Beyond those previously discussed by Laurent?) >>> >>> -Andrew >>> >>> On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n >>> > wrote: >>> >>> Hi Perry, >>> >>> It makes sense to separately encode the visual characteristics in a >>> child element, such as . Forgive me for my ignorance about >>> the existence of this element! >>> >>> However, I contemplate the problem of having too few values for >>> @symbol. >>> >>> Consider the following statement: "there are N different symbols used >>> in the score that connect groups of staves". How would you encode the >>> staff groups if N>=4? >>> >>> Thanks >>> Zoltan >>> >>> >>> 2013/12/11 Roland, Perry (pdr4h) >>> > >>> >>> Hi Zoltan, >>> >>> >>> >>> Some elements (but not ) already allow @altsym, which >>> contains a pointer to a element that, in turn, contains >>> instructions on how to "draw" the symbol. This area of the schema >>> has not been exercised much and could therefore use a lot of work. >>> However, I think could be extended to contain SVG, >>> PostScript, etc. >>> >>> >>> >>> Turning to how this would work with , the @altsym attribute >>> doesn't actually belong on . It's the visual >>> characteristics of we're trying to capture, not those of >>> . I believe this is what Andrew's comment was intended to >>> mean. So, instead of , , which can be a child of >>> , should bear @altsym, e.g., >>> >>> >>> >>> >>> >>> >>> >>> >> >>> >>> >>> >>> >>> Although sometimes it can't be avoided, it's generally bad practice >>> to use attributes to describe other attributes. The usual way to >>> handle this is to "promote" an attribute to element status and then >>> give it its own attributes. That's what is doing. >>> >>> >>> >>> The element, however, still has the @symbol attribute with >>> the same values as when it's used on . In effect, >>> >>> >>> >>> >>> >>> >>> >>> is short-hand for >>> >>> >>> >>> . >>> >>> >>> >>> In other words, as in several places in MEI, it's possible to use >>> attributes for less-detail-oriented encodings (for example, when you >>> don't care what the brace looks like), but use elements when you do. >>> >>> >>> >>> -- >>> >>> 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 >>> [mei-l-bounces at lists.uni-paderborn.de] >>> on behalf of >>> Zolt?n >>> K?m?ves >>> [zolaemil at gmail.com] >>> Sent: Wednesday, December 11, 2013 5:10 PM >>> >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> >>> Hi Andrew, >>> >>> The grouping of staves is captured by the staffGrp elements without >>> specifying @symbol. @symbol captures additional information. I talk >>> about this additional content. >>> >>> Zoltan >>> ________________________________ >>> From: Andrew Hankinson >>> Sent: 2013.12.11. 20:45 >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> >>> The intellectual content (?logical domain?) is the groups of staves, >>> not the symbol. >>> >>> On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n >>> > wrote: >>> >>> Hello, >>> >>> Would you mind to read my crazy thoughts about this issue? I'm just >>> curious what you people think of my thinking. >>> >>> I think the "intellectual content" in this case isn't so much how the >>> connecting symbols look, but the fact that the symbols are >>> *different*. >>> >>> The current values of @symbol already bear some sort of graphical >>> information, I think. The problem arose now, because it seems that >>> the current set of values don't provide a *complete" classification >>> (that is, in some cases there's no value which describes the symbol's >>> graphical shape appropriately). But of course, it's impossible to >>> provide a complete classification without degrading the markup to SVG. >>> >>> If we accept that the intellectual content is the *difference* >>> between the connecting symbols, then the proper separation of the >>> "intellectual content" from it's graphical representation would be to >>> use a set of values something like this: >>> >>> "symbol1", >>> "symbol2", >>> "symbol3", >>> etc. >>> >>> If one wanted to capture more info about their "look and feel", one >>> could use some pointing mechanism to point to a different element >>> that records the graphical info (possibly even pointing to an >>> external SVG...) >>> >>> I know, it's a crazy abstraction. And it may be way too abstract >>> compared to its practical use, and we could be better off adding a >>> handful of carefully defined values. >>> >>> Zoltan >>> >>> >>> >>> >>> >>> 2013/12/11 Laurent Pugin >>> > >>> It seems to me that adding "bracketsq" as a possible value would be >>> an appropriate addition. I don't think this particular case should >>> necessary open up a discussion on what is just typesetting or not. >>> >>> Laurent >>> >>> >>> On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) >>> > >>> wrote: >>> Yes, caution is advised. >>> >>> >>> -- >>> 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 >>> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] >>> on behalf of >>> Johannes >>> Kepper >>> [kepper at edirom.de] >>> Sent: Wednesday, December 11, 2013 10:02 AM >>> >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> >>> While there is certainly no harm in adding a well-defined set of >>> additional attribute values, the risk I see is that the distinction >>> between these values gets harder every time, eventually watering down >>> their expressiveness in terms of interchange. I'm not saying we're >>> reaching that point here, I'm just saying that we should be careful? >>> >>> >>> >>> Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) >>> >: >>> >>>> The "land of music typesetting" is always nearby, not unlike a 4th >>>> dimension hovering around us and within us. :-) Intellectual >>>> content and presentation are always difficult to separate. But try >>>> we must. >>>> >>>> There are already issues in the tracker related to @symbol -- nos. >>>> 180 & 182. >>>> >>>> From issue #180 -- "The top and bottom components of a bracket can >>>> be rendered as curved (similar to Unicode #x1D115) or straight >>>> (similar to Unicode #x0005B). The simplest method of dealing with >>>> this distinction is to add "bracketsq" (bracket square) to the >>>> values allowed by @symbol. "bracket" will continue to be used for >>>> the usual, curved musical bracket. The documentation should be >>>> edited to make the distinction clear." >>>> >>>> I won't attempt to reproduce #182 here, but it covers the selection >>>> of a value for @symbol that captures a line (often fairly wide) used >>>> to group systems instead of a brace or bracket. There's an image in >>>> #182 that illustrates various grouping symbols. >>>> >>>> Neither the so-called square bracket nor the >>>> wide-line-grouping-symbol can be encoded using @symbol="line" since >>>> that value is already reserved for the line connecting the staves at >>>> their left edge. I'm partial to the value "rule", but I'm open to >>>> suggestions. >>>> >>>> I see no harm in adding generic values like this to MEI because they >>>> are what I like to call "rendering hints" for the intellectual >>>> content -- in this case the staff group. But obviously this >>>> mechanism is not optimal for capturing all the visual details of the >>>> symbol, such as line width, color, position, etc. I am somewhat >>>> trepidatious about going too far down that road, at the end of which >>>> MEI becomes a re-definition of SVG. :-) >>>> >>>> Yes, there are still things to add to MEI. And, yes, this is an >>>> opportunity to do so. Now, if there were only more hours in the day >>>> ... >>>> >>>> -- >>>> 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 >>>> [mei-l-bounces at lists.uni-paderborn.de] >>>> on behalf of >>>> Johannes >>>> Kepper >>>> [kepper at edirom.de] >>>> Sent: Wednesday, December 11, 2013 8:47 AM >>>> To: Music Encoding Initiative >>>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>>> >>>> The reason why I feel slightly uneasy with this all is that it seems >>>> that we seem to enter the land of a music typesetting program here. >>>> In my ignorance about such details, I would probably encode that as >>>> a line, and ignore the fact that it is connected on both ends. In >>>> manuscripts, there would probably be no difference between this and >>>> either brackets or lines. But maybe you're right, and we should >>>> include the additional value. @Perry, do I remember correctly that >>>> you spotted some values in MusicXML not currently supported by MEI >>>> anyway? Is this an opportunity to revise them? >>>> >>>> jo >>>> >>>> >>>> >>>> Am 11.12.2013 um 14:39 schrieb Laurent Pugin >>>> >: >>>> >>>>> You are right, I think it is missing. >>>>> >>>>> There are actually a few of them in the examples, at least there is >>>>> this one (however with no representation in the encoding) >>>>> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >>>>> >>>>> >>>>> Laurent >>>>> >>>>> >>>>> >>>>> On Wed, Dec 11, 2013 at 1:21 PM, TW >>>>> > wrote: >>>>> Laurent's post made me wonder whether we might be missing an >>>>> additional value for staffGrp/@symbol for the thin bracket that is >>>>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >>>>> the sample collection I didn't see anything like that (I didn't look >>>>> through all of them). >>>>> >>>>> Thomas >>>>> >>>>> >>>>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> Dr. Johannes Kepper >>>> BMBF-Projekt "Freisch?tz Digital" >>>> >>>> Musikwiss. Seminar Detmold / Paderborn >>>> Gartenstra?e 20 >>>> 32756 Detmold >>>> >>>> Tel. +49 5231 975669 >>>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > Indiana University Bloomington > > > _______________________________________________ > 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 : From donbyrd at indiana.edu Sun Dec 15 16:30:49 2013 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Sun, 15 Dec 2013 10:30:49 -0500 Subject: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. In-Reply-To: <52ACEBF5.8010602@weber-gesamtausgabe.de> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> , <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> <52ACEBF5.8010602@weber-gesamtausgabe.de> Message-ID: <20131215103049.sajs4i8v4k480w4k@webmail.iu.edu> Looking through a couple of dozens scores again -- none recent Schott editions -- the only instances I found of thin square brackets were in Symphony of Psalms (Boosey & Hawkes) and Prelude ? l'Apres-midi d'un Faune (in Norton Scores, unidentified edition but I suspect Durand). --DAB On Sun, 15 Dec 2013 00:38:29 +0100, Joachim Veit wrote: > Only a short "a parte": > The form of the "thin square brackets" (Finale's option 6) is very > often to be found (not only in Berlioz' example) in new Schott-Scores > (e.g. in the new Schumann Complete edition). In the Weber edition we > use them only in a very few special cases (I don't like them > really...) > Thanks for the interesting discussion! and best greetings, > Joachim > > > Am 13.12.13 04:12, schrieb Byrd, Donald A.: >> Thanks, Perry. I was thinking of #3 and #5 as being basically square >> brackets, but they're really not that square :-) . I don't think >> I've seen any other shapes "in the wild" either. >> >> --DAB >> >> >> On Thu, 12 Dec 2013 19:10:27 +0000, "Roland, Perry (pdr4h)" >> wrote: >> >>> Hi Don, >>> >>> Finale provides 6 options in its "Group Attributes" dialog box. See >>> http://www.finalemusic.com/usermanuals/finale2012win/content/finale/GROUPDLG.htm. I think "bracket" accurately describes options 3, 5, & 6 (from the left), "brace" being used for option 4. I can't say that I've seen any other symbols >>> "in >>> the >>> wild". >>> >>> (NB -- My mention of Finale doesn't constitute any kind of >>> endorsement. It's just that its documentation is easily accessible.) >>> >>> MEI currently offers only "none", "brace", "bracket", and "line" as >>> possibilities, where "line" is reserved for the thin line connecting >>> the score/system staves. These are sufficient to capture the broad >>> categories of symbols, but they (especially "bracket") don't provide >>> much in the way of visual detail. The question is, how/where should >>> that detail be located? >>> >>> My solution is to add "rule" and "bracketsq", representing Finale >>> options 2 and 6, respectively. This expands the level of visual >>> detail encapsulated in the @symbol attribute, but still doesn't >>> differentiate between options 3 and 5 or capture "typographical" >>> features (so-called 'hook' shape, color, line width, etc.). However, >>> it does provide the same level of granularity as MusicXML, enhancing >>> loss-less conversion to/from MEI. >>> >>> Of course, multiple typographical details can't be captured in a >>> single attribute value. And it's bad practice to add more attributes >>> to to comment on the value in @symbol. So, recording >>> those details necessitates a child of with its >>> own attributes. Those attributes can then be used to describe the >>> symbol in greater detail or point to a precise rendition stored >>> elsewhere. This mechanism can be used for any symbol used to group >>> staves, if someone does find an example outside the usual ones you >>> mention, for instance in a manuscript score. >>> >>> Not exactly what you asked for, but helpful nonetheless I hope, >>> >>> -- >>> 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, >>> Donald A. [donbyrd at indiana.edu] >>> Sent: Thursday, December 12, 2013 1:21 PM >>> To: mei-l at lists.uni-paderborn.de >>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>> >>> Leaving aside nesting and details like thinness, as far as I know, the >>> _only_ symbols ever used to connect staves or groups of staves in CWMN >>> are (1) curly braces, (2) square brackets, and (3) a thin line -- the >>> last being used only to connect all the staves of a system. If there >>> are others, I'd love to see an example. >>> >>> --Don >>> >>> >>> On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson >>> wrote: >>> >>>> Hi Zoltan, >>>> >>>> There is no limit to the number of nested staff groups. However, if >>>> you have more than four nested staff groups, each with its own >>>> bracket style, your engraver should be fired! :) >>>> >>>> @symbol is simply meant to indicate that there is a ?generic? >>>> bracket, brace, or line present. This is to give a visual hint, but >>>> not a visual definition, to any software parsing the MEI file. Do you >>>> have any examples of connecting symbols that are not one of these? >>>> (Beyond those previously discussed by Laurent?) >>>> >>>> -Andrew >>>> >>>> On Dec 12, 2013, at 4:30 AM, K?m?ves Zolt?n >>>> > wrote: >>>> >>>> Hi Perry, >>>> >>>> It makes sense to separately encode the visual characteristics in a >>>> child element, such as . Forgive me for my ignorance about >>>> the existence of this element! >>>> >>>> However, I contemplate the problem of having too few values for @symbol. >>>> >>>> Consider the following statement: "there are N different symbols used >>>> in the score that connect groups of staves". How would you encode the >>>> staff groups if N>=4? >>>> >>>> Thanks >>>> Zoltan >>>> >>>> >>>> 2013/12/11 Roland, Perry (pdr4h) >>>> > >>>> >>>> Hi Zoltan, >>>> >>>> >>>> >>>> Some elements (but not ) already allow @altsym, which >>>> contains a pointer to a element that, in turn, contains >>>> instructions on how to "draw" the symbol. This area of the schema >>>> has not been exercised much and could therefore use a lot of work. >>>> However, I think could be extended to contain SVG, >>>> PostScript, etc. >>>> >>>> >>>> >>>> Turning to how this would work with , the @altsym attribute >>>> doesn't actually belong on . It's the visual >>>> characteristics of we're trying to capture, not those of >>>> . I believe this is what Andrew's comment was intended to >>>> mean. So, instead of , , which can be a child of >>>> , should bear @altsym, e.g., >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> Although sometimes it can't be avoided, it's generally bad practice >>>> to use attributes to describe other attributes. The usual way to >>>> handle this is to "promote" an attribute to element status and then >>>> give it its own attributes. That's what is doing. >>>> >>>> >>>> >>>> The element, however, still has the @symbol attribute with >>>> the same values as when it's used on . In effect, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> is short-hand for >>>> >>>> >>>> >>>> . >>>> >>>> >>>> >>>> In other words, as in several places in MEI, it's possible to use >>>> attributes for less-detail-oriented encodings (for example, when you >>>> don't care what the brace looks like), but use elements when you do. >>>> >>>> >>>> >>>> -- >>>> >>>> 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 >>>> [mei-l-bounces at lists.uni-paderborn.de] on >>>> behalf >>>> of >>>> Zolt?n >>>> K?m?ves >>>> [zolaemil at gmail.com] >>>> Sent: Wednesday, December 11, 2013 5:10 PM >>>> >>>> To: Music Encoding Initiative >>>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>>> >>>> Hi Andrew, >>>> >>>> The grouping of staves is captured by the staffGrp elements without >>>> specifying @symbol. @symbol captures additional information. I talk >>>> about this additional content. >>>> >>>> Zoltan >>>> ________________________________ >>>> From: Andrew Hankinson >>>> Sent: 2013.12.11. 20:45 >>>> To: Music Encoding Initiative >>>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>>> >>>> The intellectual content (?logical domain?) is the groups of staves, >>>> not the symbol. >>>> >>>> On Dec 11, 2013, at 2:06 PM, K?m?ves Zolt?n >>>> > wrote: >>>> >>>> Hello, >>>> >>>> Would you mind to read my crazy thoughts about this issue? I'm just >>>> curious what you people think of my thinking. >>>> >>>> I think the "intellectual content" in this case isn't so much how the >>>> connecting symbols look, but the fact that the symbols are >>>> *different*. >>>> >>>> The current values of @symbol already bear some sort of graphical >>>> information, I think. The problem arose now, because it seems that >>>> the current set of values don't provide a *complete" classification >>>> (that is, in some cases there's no value which describes the symbol's >>>> graphical shape appropriately). But of course, it's impossible to >>>> provide a complete classification without degrading the markup to SVG. >>>> >>>> If we accept that the intellectual content is the *difference* >>>> between the connecting symbols, then the proper separation of the >>>> "intellectual content" from it's graphical representation would be to >>>> use a set of values something like this: >>>> >>>> "symbol1", >>>> "symbol2", >>>> "symbol3", >>>> etc. >>>> >>>> If one wanted to capture more info about their "look and feel", one >>>> could use some pointing mechanism to point to a different element >>>> that records the graphical info (possibly even pointing to an >>>> external SVG...) >>>> >>>> I know, it's a crazy abstraction. And it may be way too abstract >>>> compared to its practical use, and we could be better off adding a >>>> handful of carefully defined values. >>>> >>>> Zoltan >>>> >>>> >>>> >>>> >>>> >>>> 2013/12/11 Laurent Pugin >>>> > >>>> It seems to me that adding "bracketsq" as a possible value would be >>>> an appropriate addition. I don't think this particular case should >>>> necessary open up a discussion on what is just typesetting or not. >>>> >>>> Laurent >>>> >>>> >>>> On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h) >>>> > >>>> wrote: >>>> Yes, caution is advised. >>>> >>>> >>>> -- >>>> 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 >>>> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on >>>> behalf >>>> of >>>> Johannes >>>> Kepper >>>> [kepper at edirom.de] >>>> Sent: Wednesday, December 11, 2013 10:02 AM >>>> >>>> To: Music Encoding Initiative >>>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>>> >>>> While there is certainly no harm in adding a well-defined set of >>>> additional attribute values, the risk I see is that the distinction >>>> between these values gets harder every time, eventually watering down >>>> their expressiveness in terms of interchange. I'm not saying we're >>>> reaching that point here, I'm just saying that we should be careful? >>>> >>>> >>>> >>>> Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h) >>>> >: >>>> >>>>> The "land of music typesetting" is always nearby, not unlike a 4th >>>>> dimension hovering around us and within us. :-) Intellectual >>>>> content and presentation are always difficult to separate. But try >>>>> we must. >>>>> >>>>> There are already issues in the tracker related to @symbol -- nos. >>>>> 180 & 182. >>>>> >>>>> From issue #180 -- "The top and bottom components of a bracket can >>>>> be rendered as curved (similar to Unicode #x1D115) or straight >>>>> (similar to Unicode #x0005B). The simplest method of dealing with >>>>> this distinction is to add "bracketsq" (bracket square) to the >>>>> values allowed by @symbol. "bracket" will continue to be used for >>>>> the usual, curved musical bracket. The documentation should be >>>>> edited to make the distinction clear." >>>>> >>>>> I won't attempt to reproduce #182 here, but it covers the selection >>>>> of a value for @symbol that captures a line (often fairly wide) used >>>>> to group systems instead of a brace or bracket. There's an image in >>>>> #182 that illustrates various grouping symbols. >>>>> >>>>> Neither the so-called square bracket nor the >>>>> wide-line-grouping-symbol can be encoded using @symbol="line" since >>>>> that value is already reserved for the line connecting the staves at >>>>> their left edge. I'm partial to the value "rule", but I'm open to >>>>> suggestions. >>>>> >>>>> I see no harm in adding generic values like this to MEI because they >>>>> are what I like to call "rendering hints" for the intellectual >>>>> content -- in this case the staff group. But obviously this >>>>> mechanism is not optimal for capturing all the visual details of the >>>>> symbol, such as line width, color, position, etc. I am somewhat >>>>> trepidatious about going too far down that road, at the end of which >>>>> MEI becomes a re-definition of SVG. :-) >>>>> >>>>> Yes, there are still things to add to MEI. And, yes, this is an >>>>> opportunity to do so. Now, if there were only more hours in the day >>>>> ... >>>>> >>>>> -- >>>>> 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 >>>>> [mei-l-bounces at lists.uni-paderborn.de] on >>>>> behalf >>>>> of >>>>> Johannes >>>>> Kepper >>>>> [kepper at edirom.de] >>>>> Sent: Wednesday, December 11, 2013 8:47 AM >>>>> To: Music Encoding Initiative >>>>> Subject: Re: [MEI-L] Thin brackets in orchestral scores >>>>> >>>>> The reason why I feel slightly uneasy with this all is that it seems >>>>> that we seem to enter the land of a music typesetting program here. >>>>> In my ignorance about such details, I would probably encode that as >>>>> a line, and ignore the fact that it is connected on both ends. In >>>>> manuscripts, there would probably be no difference between this and >>>>> either brackets or lines. But maybe you're right, and we should >>>>> include the additional value. @Perry, do I remember correctly that >>>>> you spotted some values in MusicXML not currently supported by MEI >>>>> anyway? Is this an opportunity to revise them? >>>>> >>>>> jo >>>>> >>>>> >>>>> >>>>> Am 11.12.2013 um 14:39 schrieb Laurent Pugin >>>>> >: >>>>> >>>>>> You are right, I think it is missing. >>>>>> >>>>>> There are actually a few of them in the examples, at least there is >>>>>> this one (however with no representation in the encoding) >>>>>> http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf >>>>>> Laurent >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 11, 2013 at 1:21 PM, TW >>>>>> > wrote: >>>>>> Laurent's post made me wonder whether we might be missing an >>>>>> additional value for staffGrp/@symbol for the thin bracket that is >>>>>> used for sub-groups in orchestral scores[1]. Looking at some PDFs in >>>>>> the sample collection I didn't see anything like that (I didn't look >>>>>> through all of them). >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>> [1] see e.g. http://notengrafik.com/pdf/examples/Tchaikovsky.pdf >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> Dr. Johannes Kepper >>>>> BMBF-Projekt "Freisch?tz Digital" >>>>> >>>>> Musikwiss. Seminar Detmold / Paderborn >>>>> Gartenstra?e 20 >>>>> 32756 Detmold >>>>> >>>>> Tel. +49 5231 975669 >>>>> 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 >>> > -- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington From pdr4h at eservices.virginia.edu Mon Dec 16 16:09:09 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 16 Dec 2013 15:09:09 +0000 Subject: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. In-Reply-To: <20131215103049.sajs4i8v4k480w4k@webmail.iu.edu> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> , <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> <52ACEBF5.8010602@weber-gesamtausgabe.de>, <20131215103049.sajs4i8v4k480w4k@webmail.iu.edu> Message-ID: Thinking about Laurent's original question a little more, I've come to realize that my original thinking on staff grouping was, well, misguided. I now think that instead of reserving @symbol="line" for the left-hand, staff-connecting line, another attribute should be added to (or even on ) to capture the presence of this line. This eliminates the need for nested elements as well as the need to change any existing software. This new attribute (I'm still casting about for a name) should take a value of true or false depending on the presence/absence of the connecting line. Of course, this attribute can only make sense when it's on the outermost . This is a good argument for pushing it up a level to . Doing that eliminates the need for schematron rules or reliance on convention to enforce good practice. The existing @symbol attribute with a value of "line" can be used (as in MusicXML) to describe the presence of a wide line used as the grouping symbol. Of course, the Guidelines will need to be changed to reflect these changes. I'm aware that changes like this, that is, keeping the same markup but changing its meaning, are dangerous. But sometimes it's the simplest, and indeed the best, solution. Humbly, -- 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 Mon Dec 16 22:28:20 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 16 Dec 2013 21:28:20 +0000 Subject: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. In-Reply-To: <635_1387206568_52AF17A7_635_169_5_BBCC497C40D85642B90E9F94FC30343D32B5594F@grant1.eservices.virginia.edu> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> , <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> <52ACEBF5.8010602@weber-gesamtausgabe.de>, <20131215103049.sajs4i8v4k480w4k@webmail.iu.edu> <635_1387206568_52AF17A7_635_169_5_BBCC497C40D85642B90E9F94FC30343D32B5594F@grant1.eservices.virginia.edu> Message-ID: <2F13A2F8-9012-44A0-8F4F-B4D45F0D550F@mail.mcgill.ca> Two clarifying questions: 1) You wouldn?t be talking about eliminating all nested , would you? 2) Why would you bump this up to ? How would that eliminate the need for schematron rules? (Keeping the symbol on seems a bit more explicit to me.) For reference, Sibelius refers to the first line as the ?Initial barline?, not as a grouping symbol. You can en/disable showing this, but interestingly disabling the initial barline also hides any brackets associated with the group. If you re-enable the barline, it will show the bracket or brace. On Dec 16, 2013, at 10:09 AM, Roland, Perry (pdr4h) wrote: > > Thinking about Laurent's original question a little more, I've come to realize that my original thinking on staff grouping was, well, misguided. > > I now think that instead of reserving @symbol="line" for the left-hand, staff-connecting line, another attribute should be added to (or even on ) to capture the presence of this line. This eliminates the need for nested elements as well as the need to change any existing software. > > This new attribute (I'm still casting about for a name) should take a value of true or false depending on the presence/absence of the connecting line. Of course, this attribute can only make sense when it's on the outermost . This is a good argument for pushing it up a level to . Doing that eliminates the need for schematron rules or reliance on convention to enforce good practice. > > The existing @symbol attribute with a value of "line" can be used (as in MusicXML) to describe the presence of a wide line used as the grouping symbol. Of course, the Guidelines will need to be changed to reflect these changes. > > I'm aware that changes like this, that is, keeping the same markup but changing its meaning, are dangerous. But sometimes it's the simplest, and indeed the best, solution. > > Humbly, > > -- > 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 From raffaeleviglianti at gmail.com Mon Dec 16 23:14:28 2013 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Mon, 16 Dec 2013 17:14:28 -0500 Subject: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. In-Reply-To: <2F13A2F8-9012-44A0-8F4F-B4D45F0D550F@mail.mcgill.ca> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> <52ACEBF5.8010602@weber-gesamtausgabe.de> <20131215103049.sajs4i8v4k480w4k@webmail.iu.edu> <635_1387206568_52AF17A7_635_169_5_BBCC497C40D85642B90E9F94FC30343D32B5594F@grant1.eservices.virginia.edu> <2F13A2F8-9012-44A0-8F4F-B4D45F0D550F@mail.mcgill.ca> Message-ID: Let's assume that we add the extra attribute on scoreDef to specify the presence/absence of this line. Shouldn't we then think of a way to specify whether barlines are drawn continuously between staves or not? Or whether stems are extended through beams or not (e.g. French beams)? I still think that if the line means some sort of grouping (or if the encoder thinks so), let there be an extra staffGrp. If it's only a convention / editing house style, then it shouldn't matter for MEI, like French beams don't matter at the moment. Though someone may want to study the evolution of beam typesetting in Alsace-Lorraine and whether local musicians switched between French and German style... I'm making things up just to point out that any mark on the page is not "semantic" until we decide it is. Raf On Mon, Dec 16, 2013 at 4:28 PM, Andrew Hankinson < andrew.hankinson at mail.mcgill.ca> wrote: > Two clarifying questions: > > 1) You wouldn?t be talking about eliminating all nested , > would you? > 2) Why would you bump this up to ? How would that eliminate > the need for schematron rules? (Keeping the symbol on seems a > bit more explicit to me.) > > For reference, Sibelius refers to the first line as the ?Initial barline?, > not as a grouping symbol. You can en/disable showing this, but > interestingly disabling the initial barline also hides any brackets > associated with the group. If you re-enable the barline, it will show the > bracket or brace. > > > On Dec 16, 2013, at 10:09 AM, Roland, Perry (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > > Thinking about Laurent's original question a little more, I've come to > realize that my original thinking on staff grouping was, well, misguided. > > > > I now think that instead of reserving @symbol="line" for the left-hand, > staff-connecting line, another attribute should be added to (or > even on ) to capture the presence of this line. This eliminates > the need for nested elements as well as the need to change any > existing software. > > > > This new attribute (I'm still casting about for a name) should take a > value of true or false depending on the presence/absence of the connecting > line. Of course, this attribute can only make sense when it's on the > outermost . This is a good argument for pushing it up a level to > . Doing that eliminates the need for schematron rules or > reliance on convention to enforce good practice. > > > > The existing @symbol attribute with a value of "line" can be used (as in > MusicXML) to describe the presence of a wide line used as the grouping > symbol. Of course, the Guidelines will need to be changed to reflect these > changes. > > > > I'm aware that changes like this, that is, keeping the same markup but > changing its meaning, are dangerous. But sometimes it's the simplest, and > indeed the best, solution. > > > > Humbly, > > > > -- > > 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 > > > _______________________________________________ > 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: From pdr4h at eservices.virginia.edu Mon Dec 16 23:42:43 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 16 Dec 2013 22:42:43 +0000 Subject: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. In-Reply-To: <2F13A2F8-9012-44A0-8F4F-B4D45F0D550F@mail.mcgill.ca> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> , <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> <52ACEBF5.8010602@weber-gesamtausgabe.de>, <20131215103049.sajs4i8v4k480w4k@webmail.iu.edu> <635_1387206568_52AF17A7_635_169_5_BBCC497C40D85642B90E9F94FC30343D32B5594F@grant1.eservices.virginia.edu>, <2F13A2F8-9012-44A0-8F4F-B4D45F0D550F@mail.mcgill.ca> Message-ID: Hi Andrew, 1. No, no, I'm not talking about eliminating all nesting. 2. If the new @initialbarline (following Sibelius' name) attribute is placed on , it only makes sense on the outer . Therefore, a schematron rule is probably called for in order to prevent its use on other elements. On the other hand, if @initialbarline is placed on , its effect is global (or until another element is encountered); hence, no need for the schematron rule. At this point, I'm happy with placing it in one or the other location, but not both. I don't know if it's more explicit or not, but putting the attribute on requires fewer changes, none of which are technically backwardly incompatible. The change, however, is semantically incompatible because it changes the meaning of the existing markup. Luckily, there aren't a lot of MEI instances to break. :-) Sibelius' behavior with regard to the initial line seems somewhat strange, but I think not treating the initial line as a grouping symbol makes sense. This is the essence of my change of heart. -- 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 [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sent: Monday, December 16, 2013 4:28 PM To: Music Encoding Initiative Subject: Re: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. Two clarifying questions: 1) You wouldn?t be talking about eliminating all nested , would you? 2) Why would you bump this up to ? How would that eliminate the need for schematron rules? (Keeping the symbol on seems a bit more explicit to me.) For reference, Sibelius refers to the first line as the ?Initial barline?, not as a grouping symbol. You can en/disable showing this, but interestingly disabling the initial barline also hides any brackets associated with the group. If you re-enable the barline, it will show the bracket or brace. On Dec 16, 2013, at 10:09 AM, Roland, Perry (pdr4h) wrote: > > Thinking about Laurent's original question a little more, I've come to realize that my original thinking on staff grouping was, well, misguided. > > I now think that instead of reserving @symbol="line" for the left-hand, staff-connecting line, another attribute should be added to (or even on ) to capture the presence of this line. This eliminates the need for nested elements as well as the need to change any existing software. > > This new attribute (I'm still casting about for a name) should take a value of true or false depending on the presence/absence of the connecting line. Of course, this attribute can only make sense when it's on the outermost . This is a good argument for pushing it up a level to . Doing that eliminates the need for schematron rules or reliance on convention to enforce good practice. > > The existing @symbol attribute with a value of "line" can be used (as in MusicXML) to describe the presence of a wide line used as the grouping symbol. Of course, the Guidelines will need to be changed to reflect these changes. > > I'm aware that changes like this, that is, keeping the same markup but changing its meaning, are dangerous. But sometimes it's the simplest, and indeed the best, solution. > > Humbly, > > -- > 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 _______________________________________________ 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 Dec 17 00:43:05 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 16 Dec 2013 23:43:05 +0000 Subject: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. In-Reply-To: References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> <52ACEBF5.8010602@weber-gesamtausgabe.de> <20131215103049.sajs4i8v4k480w4k@webmail.iu.edu> <635_1387206568_52AF17A7_635_169_5_BBCC497C40D85642B90E9F94FC30343D32B5594F@grant1.eservices.virginia.edu> <2F13A2F8-9012-44A0-8F4F-B4D45F0D550F@mail.mcgill.ca>, Message-ID: Hi Raf, There already is a way to indicate if barlines are drawn continuously between staves -- the @barthru attribute on . But that's unimportant with regard to your main point, I believe. The connecting line does indicate "some kind of grouping", but the issue is that sometimes we need to record two properties of the outermost group -- whether there's a connecting line and the brace, bracket, etc. used. Obviously, this can't be done with a single attribute. One solution is to expand the hierarchy, placing @symbol="line" on the outer group, and @symbol="bracket" on the inner one. But this is overly complex. I think a better solution is to provide a new attribute for indicating the presence of the connecting line. Reduced complexity makes this new approach more likely to be used and processed correctly. Having decided we need another attribute, where do we put it? We could allow it on also, but without a schematron rule to limit its use to only the outer group, syntactically it can occur on any staff group, which could lead to confusion again. A different approach is to allow it to occur on the parent of the outer ; that is, on , as I explained in my previous message. If it is placed on , then it is an optional visual property of the score that gets inherited by the outermost staff group. No matter where the presence of the connecting line is recorded, it's still a visual property of the outermost staff group. -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Monday, December 16, 2013 5:14 PM To: Music Encoding Initiative Subject: Re: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. Let's assume that we add the extra attribute on scoreDef to specify the presence/absence of this line. Shouldn't we then think of a way to specify whether barlines are drawn continuously between staves or not? Or whether stems are extended through beams or not (e.g. French beams)? I still think that if the line means some sort of grouping (or if the encoder thinks so), let there be an extra staffGrp. If it's only a convention / editing house style, then it shouldn't matter for MEI, like French beams don't matter at the moment. Though someone may want to study the evolution of beam typesetting in Alsace-Lorraine and whether local musicians switched between French and German style... I'm making things up just to point out that any mark on the page is not "semantic" until we decide it is. Raf On Mon, Dec 16, 2013 at 4:28 PM, Andrew Hankinson > wrote: Two clarifying questions: 1) You wouldn?t be talking about eliminating all nested , would you? 2) Why would you bump this up to ? How would that eliminate the need for schematron rules? (Keeping the symbol on seems a bit more explicit to me.) For reference, Sibelius refers to the first line as the ?Initial barline?, not as a grouping symbol. You can en/disable showing this, but interestingly disabling the initial barline also hides any brackets associated with the group. If you re-enable the barline, it will show the bracket or brace. On Dec 16, 2013, at 10:09 AM, Roland, Perry (pdr4h) > wrote: > > Thinking about Laurent's original question a little more, I've come to realize that my original thinking on staff grouping was, well, misguided. > > I now think that instead of reserving @symbol="line" for the left-hand, staff-connecting line, another attribute should be added to (or even on ) to capture the presence of this line. This eliminates the need for nested elements as well as the need to change any existing software. > > This new attribute (I'm still casting about for a name) should take a value of true or false depending on the presence/absence of the connecting line. Of course, this attribute can only make sense when it's on the outermost . This is a good argument for pushing it up a level to . Doing that eliminates the need for schematron rules or reliance on convention to enforce good practice. > > The existing @symbol attribute with a value of "line" can be used (as in MusicXML) to describe the presence of a wide line used as the grouping symbol. Of course, the Guidelines will need to be changed to reflect these changes. > > I'm aware that changes like this, that is, keeping the same markup but changing its meaning, are dangerous. But sometimes it's the simplest, and indeed the best, solution. > > Humbly, > > -- > 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 _______________________________________________ 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: From esfield at stanford.edu Tue Dec 17 02:15:33 2013 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Mon, 16 Dec 2013 17:15:33 -0800 (PST) Subject: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. In-Reply-To: References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> , <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> <52ACEBF5.8010602@weber-gesamtausgabe.de>, <20131215103049.sajs4i8v4k480w4k@webmail.iu.edu> Message-ID: <78d42e88.000018f0.00000024@CCARH-ADM-2.su.win.stanford.edu> Thinking about Perry's latest view prompts me to ask a question that may be redundant. In our typesetting we assume a relationship between these much discussed staff groups and the implications for barring throughout a score. Some vertical lines in staff groups are continuous from top to bottom of a system, but some (especially for things like obbligato instruments or a chorus in a mainly orchestral work) may not be. Do these various nesting schemes have any "generative" implications for how to coding continues? Barring systems vary somewhat by publisher and national tradition. Some publishers do not continue what I'll call "measure bars" (running unbroken from top to bottom of a system) across all systems, but the ways in which they are broken up is somewhat variable and may depend also on the complex of instruments/voices in force. Then there are Mensurstriche (editions of Renaissance music), where the barlines never cross a clef but instead run from the bottom line of one clef to the top line of one underneath. This is not usually detectable from the presentation of the initial staff group. I realize that all these points fall outside the emphasis on source description, but they are real and frequent issues in getting from most encoding systems to something useable. On the other hand, anyone using MEI to make a new edition may be guided by publishers' requirements irrespective of the source coding. Eleanor Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ +1/ 650 725-9242 -----Original Message----- From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry (pdr4h) Sent: Monday, December 16, 2013 7:09 AM To: Music Encoding Initiative Subject: Re: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. Thinking about Laurent's original question a little more, I've come to realize that my original thinking on staff grouping was, well, misguided. I now think that instead of reserving @symbol="line" for the left-hand, staff-connecting line, another attribute should be added to (or even on ) to capture the presence of this line. This eliminates the need for nested elements as well as the need to change any existing software. This new attribute (I'm still casting about for a name) should take a value of true or false depending on the presence/absence of the connecting line. Of course, this attribute can only make sense when it's on the outermost . This is a good argument for pushing it up a level to . Doing that eliminates the need for schematron rules or reliance on convention to enforce good practice. The existing @symbol attribute with a value of "line" can be used (as in MusicXML) to describe the presence of a wide line used as the grouping symbol. Of course, the Guidelines will need to be changed to reflect these changes. I'm aware that changes like this, that is, keeping the same markup but changing its meaning, are dangerous. But sometimes it's the simplest, and indeed the best, solution. Humbly, -- 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 From andrew.hankinson at mail.mcgill.ca Tue Dec 17 02:29:08 2013 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Tue, 17 Dec 2013 01:29:08 +0000 Subject: [MEI-L] thru barlines [WAS: bracketing] In-Reply-To: <21475_1387242950_52AFA5C6_21475_83_1_78d42e88.000018f0.00000024@CCARH-ADM-2.su.win.stanford.edu> References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> , <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> <52ACEBF5.8010602@weber-gesamtausgabe.de>, <20131215103049.sajs4i8v4k480w4k@webmail.iu.edu> <21475_1387242950_52AFA5C6_21475_83_1_78d42e88.000018f0.00000024@CCARH-ADM-2.su.win.stanford.edu> Message-ID: Hi Eleanor, Both the scoreDef and staffGrp elements can have the ?@barthru? attribute, which can be true or false. This is meant to encode whether the bar line continues vertically through the group (through the inter-staff area) or not. I?m not entirely sure how this would be interpreted in the second case you mention, however. I have also seen bar lines that only fall between the inter-staff space, not through the staves themselves, but I?m not sure how we would encode that. If there?s no satisfactory method, we can create an issue on Google Code and make the changes to the schema. Thanks! -Andrew On Dec 16, 2013, at 8:15 PM, Eleanor Selfridge-Field wrote: > Thinking about Perry's latest view prompts me to ask a question that may > be redundant. In our typesetting we assume a relationship between these > much discussed staff groups and the implications for barring throughout a > score. Some vertical lines in staff groups are continuous from top to > bottom of a system, but some (especially for things like obbligato > instruments or a chorus in a mainly orchestral work) may not be. Do these > various nesting schemes have any "generative" implications for how to > coding continues? > > Barring systems vary somewhat by publisher and national tradition. Some > publishers do not continue what I'll call "measure bars" (running unbroken > from top to bottom of a system) across all systems, but the ways in which > they are broken up is somewhat variable and may depend also on the complex > of instruments/voices in force. > > Then there are Mensurstriche (editions of Renaissance music), where the > barlines never cross a clef but instead run from the bottom line of one > clef to the top line of one underneath. This is not usually detectable > from the presentation of the initial staff group. > > I realize that all these points fall outside the emphasis on source > description, but they are real and frequent issues in getting from most > encoding systems to something useable. On the other hand, anyone using > MEI to make a new edition may be guided by publishers' requirements > irrespective of the source coding. > > Eleanor > > > > > Eleanor Selfridge-Field > Consulting Professor, Music (and, by courtesy, Symbolic Systems) > Braun Music Center #129 > Stanford University > Stanford, CA 94305-3076, USA > http://www.stanford.edu/~esfield/ +1/ 650 725-9242 > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Roland, Perry (pdr4h) > Sent: Monday, December 16, 2013 7:09 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. > > > Thinking about Laurent's original question a little more, I've come to > realize that my original thinking on staff grouping was, well, misguided. > > I now think that instead of reserving @symbol="line" for the left-hand, > staff-connecting line, another attribute should be added to (or > even on ) to capture the presence of this line. This eliminates > the need for nested elements as well as the need to change any > existing software. > > This new attribute (I'm still casting about for a name) should take a > value of true or false depending on the presence/absence of the connecting > line. Of course, this attribute can only make sense when it's on the > outermost . This is a good argument for pushing it up a level > to . Doing that eliminates the need for schematron rules or > reliance on convention to enforce good practice. > > The existing @symbol attribute with a value of "line" can be used (as in > MusicXML) to describe the presence of a wide line used as the grouping > symbol. Of course, the Guidelines will need to be changed to reflect > these changes. > > I'm aware that changes like this, that is, keeping the same markup but > changing its meaning, are dangerous. But sometimes it's the simplest, and > indeed the best, solution. > > Humbly, > > -- > 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 > > _______________________________________________ > 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 Dec 17 06:35:07 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 17 Dec 2013 05:35:07 +0000 Subject: [MEI-L] thru barlines [WAS: bracketing] In-Reply-To: References: <52a8e2e7.03670e0a.4dfc.5c43@mx.google.com> <26974_1386840711_52A98287_26974_403_1_CAOwwuncreLte3uYGNxDAHEhvG3946zquhLRZbsEy5gnCVXB9NQ@mail.gmail.com> , <20131212132130.6rnwu3zd0gkoog8k@webmail.iu.edu> <20131212221255.cavzm8fvcc880g4g@webmail.iu.edu> <52ACEBF5.8010602@weber-gesamtausgabe.de>, <20131215103049.sajs4i8v4k480w4k@webmail.iu.edu> <21475_1387242950_52AFA5C6_21475_83_1_78d42e88.000018f0.00000024@CCARH-ADM-2.su.win.stanford.edu>, Message-ID: Hi Eleanor & Andrew, In addition to @barthru, there are other attributes that contribute to the specification of bar lines -- @barplace and @taktplace. These attributes work together (they sort of "cascade") to fully describe the various combinations of bar line properties. @barplace takes the values "staff", "mensur", and "takt". This attribute determines the general placement of bar lines. There's no explicit default, but CMN assumes the "staff" value. That is, bar lines are drawn across the staves. More about this in a moment. A value of "mensur" (abbreviation of "Mensurstriche") indicates that the bar lines are drawn *between the staves*; that is, as Eleanor described, from the bottom line of one staff to the top line of the one below. For example, a system of 4 staves will have bar lines between staves 1 and 2, between staves 2 and 3, and between staves 3 and 4. Currently, these attributes are available only on , , and . So, there's no method for specifying mensuration bar lines for a subset of adjacent staves. However, I think this can be accomplished by allowing @barplace and @taktplace on. An argument could even be made that they should be moved from to . As you might expect, @taktplace is only useful when @barplace = 'takt'. @taktplace takes a value between 0 and 2 times the number of staff lines. On a 5-line staff, the value '1' indicates a "tick mark" through the bottom line, '9' a mark through the top line. Typically, the so-called "takt" bar line is drawn at the same place for each measure and in all the staves, but when it's not, @barline can be explicitly set on each or element. I'll skip the detailed explanation of the use of for now, but it should be used in mensural notation (instead of ), even if the bar lines "line up" across all the staves. Returning to CMN, @barthru assumes a value of 'staff' for @barplace and adds information about which staves are crossed by the bar lines. Any other value of @barplace makes @barthru meaningless. Said the other way around, @barthru precludes any value for @barplace except 'staff', so @barplace isn't necessary in the presence of @barthru. That's why I haven't mentioned it before in the discussion of CMN bar lines and staff groups. Since they can occur on and , these attributes are independent of the initial connecting line and grouping symbol given on , so it's possible to group a set of 4 staves, record that there is an initial connecting line and brace, and still indicate Mensurstriche bar lines for the remainder of the notation -- Sorry for the long-winded response, but I thought some folks here might want the (more or less) complete picture. 12:30am, must ... sleep ... now, -- 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sent: Monday, December 16, 2013 8:29 PM To: Music Encoding Initiative Subject: Re: [MEI-L] thru barlines [WAS: bracketing] Hi Eleanor, Both the scoreDef and staffGrp elements can have the ?@barthru? attribute, which can be true or false. This is meant to encode whether the bar line continues vertically through the group (through the inter-staff area) or not. I?m not entirely sure how this would be interpreted in the second case you mention, however. I have also seen bar lines that only fall between the inter-staff space, not through the staves themselves, but I?m not sure how we would encode that. If there?s no satisfactory method, we can create an issue on Google Code and make the changes to the schema. Thanks! -Andrew On Dec 16, 2013, at 8:15 PM, Eleanor Selfridge-Field wrote: > Thinking about Perry's latest view prompts me to ask a question that may > be redundant. In our typesetting we assume a relationship between these > much discussed staff groups and the implications for barring throughout a > score. Some vertical lines in staff groups are continuous from top to > bottom of a system, but some (especially for things like obbligato > instruments or a chorus in a mainly orchestral work) may not be. Do these > various nesting schemes have any "generative" implications for how to > coding continues? > > Barring systems vary somewhat by publisher and national tradition. Some > publishers do not continue what I'll call "measure bars" (running unbroken > from top to bottom of a system) across all systems, but the ways in which > they are broken up is somewhat variable and may depend also on the complex > of instruments/voices in force. > > Then there are Mensurstriche (editions of Renaissance music), where the > barlines never cross a clef but instead run from the bottom line of one > clef to the top line of one underneath. This is not usually detectable > from the presentation of the initial staff group. > > I realize that all these points fall outside the emphasis on source > description, but they are real and frequent issues in getting from most > encoding systems to something useable. On the other hand, anyone using > MEI to make a new edition may be guided by publishers' requirements > irrespective of the source coding. > > Eleanor > > > > > Eleanor Selfridge-Field > Consulting Professor, Music (and, by courtesy, Symbolic Systems) > Braun Music Center #129 > Stanford University > Stanford, CA 94305-3076, USA > http://www.stanford.edu/~esfield/ +1/ 650 725-9242 > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Roland, Perry (pdr4h) > Sent: Monday, December 16, 2013 7:09 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc. > > > Thinking about Laurent's original question a little more, I've come to > realize that my original thinking on staff grouping was, well, misguided. > > I now think that instead of reserving @symbol="line" for the left-hand, > staff-connecting line, another attribute should be added to (or > even on ) to capture the presence of this line. This eliminates > the need for nested elements as well as the need to change any > existing software. > > This new attribute (I'm still casting about for a name) should take a > value of true or false depending on the presence/absence of the connecting > line. Of course, this attribute can only make sense when it's on the > outermost . This is a good argument for pushing it up a level > to . Doing that eliminates the need for schematron rules or > reliance on convention to enforce good practice. > > The existing @symbol attribute with a value of "line" can be used (as in > MusicXML) to describe the presence of a wide line used as the grouping > symbol. Of course, the Guidelines will need to be changed to reflect > these changes. > > I'm aware that changes like this, that is, keeping the same markup but > changing its meaning, are dangerous. But sometimes it's the simplest, and > indeed the best, solution. > > Humbly, > > -- > 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 > > _______________________________________________ > 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 slu at kb.dk Wed Dec 18 13:16:25 2013 From: slu at kb.dk (Sigfrid Lundberg) Date: Wed, 18 Dec 2013 12:16:25 +0000 Subject: [MEI-L] ... and some other elements... Message-ID: <0C090608704AF04E898055296C932B12011BF3BBD7@EXCHANGE-03.kb.dk> ... and many other elements have (it is just that projectDesc is an issue for one of our projects today) allow textual content within

...

. However it does not allow
...
though, and in particular it does not allow .... Why is that? And what is the best solution if my text is long enough to benefit from a bit of a structure? Yours Sigfrid From pdr4h at eservices.virginia.edu Wed Dec 18 21:55:38 2013 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 18 Dec 2013 20:55:38 +0000 Subject: [MEI-L] ... and some other elements... In-Reply-To: <0C090608704AF04E898055296C932B12011BF3BBD7@EXCHANGE-03.kb.dk> References: <0C090608704AF04E898055296C932B12011BF3BBD7@EXCHANGE-03.kb.dk> Message-ID: Hi Sigfrid, The element does allow "a bit of structure"; that is, it allows a text organized as an ordered set of paragraphs. It's designed that way because anything more complex probably belongs in music/front or music/back instead. The same philosophy applies in the case of the other elements that share this model. It's true that does not allow , but it does permit @label, which is sufficient unless your heading contains presentational markup, such as sub- or superscripts, font changes, etc. I'm not opposed to allowing within -- I'd just ask that you create a ticket in the tracker (https://code.google.com/p/music-encoding/issues) to remind me of this issue for the next release. Best wishes, -- 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 [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Sigfrid Lundberg [slu at kb.dk] Sent: Wednesday, December 18, 2013 7:16 AM To: Music Encoding Initiative Subject: [MEI-L] ... and some other elements... ... and many other elements have (it is just that projectDesc is an issue for one of our projects today) allow textual content within

...

. However it does not allow
...
though, and in particular it does not allow .... Why is that? And what is the best solution if my text is long enough to benefit from a bit of a structure? Yours Sigfrid _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From richard at rjlewis.me.uk Thu Dec 19 12:28:58 2013 From: richard at rjlewis.me.uk (Richard Lewis) Date: Thu, 19 Dec 2013 11:28:58 +0000 Subject: [MEI-L] Funding Opportunity: Transforming Musicology Mini-Projects Message-ID: <8538lpgjut.wl%richard@rjlewis.me.uk> RESEARCH FUNDING OPPORTUNITY Call for Mini-Projects Transforming Musicology is a large-scale research project, funded under the AHRC's Digital Transformations scheme, seeking to explore the transformation of musicology through the application of software tools such as are emerging from research in Music Information Retrieval. See: http://www.transforming-musicology.org We invite applications for mini-projects to contribute to this research. Applications may come from academic staff at UK institutions which are entitled to apply for AHRC funding (see http://www.ahrc.ac.uk/Funding-Opportunities/Research-funding/RFG/Eligibility/Pages/Eligibility.aspx for the AHRC's eligibility criteria). We aim to fund four mini-projects, each at the level of approximately ?50,000. The deadline for applications is midnight on 21 March 2014. Projects and Application Process Mini-projects must * Conduct research on a clearly defined musicological question using digital technology; * Communicate with other teams in the Transforming Musicology project, at least by making regular posts to the project's website; * Produce at least of the following research outputs o A contribution to the final Transforming Musicology workshop, to be held in July 2016, with accompanying documentation, o A contribution to an edited book; * Contribute to the project's web-site and Semantic Web infrastructure; * Start between 1 June and 1 October 2014; * Finish by 31 March 2015. Applications should be made by e-mail to Alan Marsden at Lancaster University (a.marsden at lancaster.ac.uk). An application should consist of a single pdf document with the following sections (broadly similar to the components of a typical AHRC application): * Title of the intended mini-project * Intended starting date and duration * Name, post, institution and contact details of the lead investigator * Name(s), post(s), institution(s) and role(s) of any other members of the research team. Teams may include members yet to be appointed, in which case an indication of the qualifications, skills and background sought in the appointee should be given. Teams may include individuals outside the UK, but their costs other than occasional visits to the UK must be met from other sources. * Objectives of the project (up to 4000 characters) * Summary of the project (up to 4000 characters) * Budget (total sum between ?40,000 and ?60,000) * Letter of support from the Head of the lead investigator's department * Case for Support (up to four A4 pages), containing the following o Musicological research questions to be investigated o Research context o Aims and objectives o Research methods, including what digital tools and materials are to be used, and how, and a provisional timetable. If materials will need to be digitised, give details of how this is to be done. o Fit to the Transforming Musicology project. How will this research be transformative for musicology? How will the mini-project feed into the overall project's Semantic Web infrastructure? * Justification of resources (one A4 page) * Curriculum Vitae of each team member (one A4 page each) * Publications of each team member (not necessarily a complete list, one A4 page each) * Any other supporting material (visual evidence, warrants of contribution in kind, external support, etc.) (up to four A4 pages) Projects will be selected on the following criteria * Is the programme of research sound? * Are the musicological objectives clear and realistic? * Are the technical means clear and realistic? * How transformative for musicology is the project likely to be? * The degree to which the project will expand the areas of musicology represented in the Transforming Musicology project. * The scope for contribution to the Semantic Web infrastructure. * The skills and track record of the research team. * Value for money. Applications from teams including early-career researchers and women are particularly welcome. In order to make best use of the available resources, we reserve the right to fund mini-projects according to a budget varied from that in the application. Formal collaboration agreements between Lancaster University and the institutions participating in each mini-project will be required before any mini-project can start. Project costs may either include indirect costs, in which case funding will be 80% of full economic costs, mimicking the typical basis of AHRC funding, or projects may include only direct costs and be funded at 100%. Final decision on admissible costs will be made by staff at Lancaster University. For the purposes of these mini-projects, musicology is defined broadly as the study of music, and it explicitly includes ethnomusicology, music theory and analysis. On the other hand, studies whose objective is the creation or dissemination of music are excluded. Any project whose primary objective is performance, composition, education, or the facilitation of any of these, is excluded. Before you apply ... We encourage those interested in bidding to carry out a mini-project to discuss their plans in advance with Alan Marsden or another member of the Transforming Musicology team. We anticipate that projects will involve partners who are computer scientists or technologists as well as musicologists. While we cannot guarantee to find appropriate partners, we are willing to make efforts to put potential partners in touch with each other. Pre-Application Exploratory Event, 12 February, Lancaster To assist in fostering good bids, an event will be held at Lancaster University on Wednesday 12 February 2014. Anyone entitled to bid for a mini-project (see above) may attend the event, subject to a limit on overall numbers. To reserve a place, please contact Alan Marsden (a.marsden at lancaster.ac.uk). Preference will be given to those who send a compelling 'expression of interest' (see below) by 17 January. The event will include the following: * A presentation about the Transforming Musicology project, its aims, rationale and components * A presentation on how the Transforming Musicology project plans to use Semantic Web technology * A presentation of some previous musicological research using digital technology and of some of the technologies available * An opportunity for participants to air their interests and seek research partners * An opportunity to ask questions about the Transforming Musicology project, about the mini-projects, and about the bidding process. To help us in planning the event, we ask that attendees send an expression of interest to Alan Marsden (a.marsden at lancaster.ac.uk) by Friday 17 January. Expressions of interest will be one page of A4 and take one of two forms, either primarily musicological or primarily technological. A musicological expression of interest will give * The name and contact details of the person attending the event; * An outline of the musicological question or questions you are interested in investigating; * A brief description of the research materials you might use, and whether or not they are already in digital form; * How you believe digital technology will contribute to answering the musicological questions. A technological expression of interest will give * The name and contact details of the person attending the event; * An outline of a digital technology or resource in which you are an expert; * How you believe that technology or resource might contribute to transforming musicology. From gdibacco at indiana.edu Sat Dec 21 22:54:42 2013 From: gdibacco at indiana.edu (Di Bacco, Giuliano) Date: Sat, 21 Dec 2013 16:54:42 -0500 Subject: [MEI-L] Music Encoding Conference 2014 Message-ID: <20131221165442.8ru4so9g0c4kg444@webmail.iu.edu> Dear all, On behalf of the organizers and of the program committee I am glad too announce that it is now possible to submit proposals for the Music Encoding Conference 2014. Please follow the directions published at the address http://music-encoding.org/conference/submission2014. Registration is required in order to use ConfTool, but only for those who did not register for the 2013 conference. Please note that the deadline for submission has been extended to 7 January 2014, so you don't have to rush. I take this opportunity to wish you all a great Christmas and happy new year! Giuliano -- GIULIANO DI BACCO Director, Center for the History of Music Theory and Literature Indiana University Jacobs School of Music Bloomington, IN 47405 - USA www.chmtl.indiana.edu Links: ------ [1] http://www.chmtl.indiana.edu From F.Wiering at uu.nl Mon Dec 23 10:50:08 2013 From: F.Wiering at uu.nl (Frans Wiering) Date: Mon, 23 Dec 2013 10:50:08 +0100 Subject: [MEI-L] Digital Musicology and Music Information Retrieval: a very short questionnaire Message-ID: <52B80750.8000705@uu.nl> Dear all, A couple of weeks ago I posted a short questionnaire about Digital Musicology and Music Information Retrieval at http://bit.ly/1kFRkGB. The aim is to discover what the current needs, technical or otherwise, in (Digital) musicology are. How could these be translated into MIR research challenges that we could hope to see solutions for in the next few ISMIRs? I have already received quite a few very interesting replies, but as always in data-driven research, more is better. So please use a few minutes of your Christmas holiday to think about these questions and fill out the questionnaire. Your answers will help me to formulate a number of musicological 'Grand Challenges' to MIR. Many thanks Frans Wiering Chair of the IMS Study Group on Digital Musicology -- --------------------------------------------------------------------- dr. Frans Wiering e-mail: F.Wiering at uu.nl --------------------------------------------------------------------- Utrecht University Department of Information and Computing Sciences (ICS) Buys Ballot Building, office 482 Princetonplein 5, De Uithof PO Box 80.089 NL-3508 TB Utrecht tel: +31-30-2536335 www: http://www.uu.nl/medewerkers/FWiering ---------------------------------------------------------------------