From zolaemil at gmail.com Sun Jan 5 12:43:02 2014 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Sun, 5 Jan 2014 12:43:02 +0100 Subject: [MEI-L] Grouping of s Message-ID: Hello All and Happy New Year, There's been a discussion about how to group together elements in the past ( http://list-archives.org/2012/07/15/mei-l-lists-uni-paderborn-de/more-precise-app-s/f/7456812281and http://list-archives.org/2012/07/23/mei-l-lists-uni-paderborn-de/antw-more-precise-app-s/f/3141983676) and I'd like to follow up a bit on the topic. I understand there's been a number of suggestions, one of the last ones being: This seems a very suitable solution to the problem, but here's my question. With this practice it's possible to define overlapping groupings: I might be shortsighted, but I cannot think of a much meaningful use case for this scenario. Do you think such encoding should be forbidden/discouraged? Or perhaps someone can pinpoint a meaningful use case? Thanks Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdibacco at indiana.edu Tue Jan 7 00:00:28 2014 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Mon, 06 Jan 2014 18:00:28 -0500 Subject: [MEI-L] Music Encoding Conference 2014, deadline extended Message-ID: <52CB358C.6000405@indiana.edu> An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Tue Jan 7 00:55:04 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 6 Jan 2014 23:55:04 +0000 Subject: [MEI-L] Grouping of s In-Reply-To: References: Message-ID: Hi Zoltan, You're probably right that there is no meaning in creating overlapping groups, but I've often found that when I thought there could never be a good reason for something, an example of just such a thing arose later. "There are more things in Heaven and Earth ..." :) So, I believe the best policy is to allow a wide range of practice until it causes a problem. Best wishes for a happy and prosperous new year, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kom?ves Zolt?n Sent: Sunday, January 05, 2014 6:43 AM To: Music Encoding Initiative Subject: [MEI-L] Grouping of s Hello All and Happy New Year, There's been a discussion about how to group together elements in the past (http://list-archives.org/2012/07/15/mei-l-lists-uni-paderborn-de/more-precise-app-s/f/7456812281 and http://list-archives.org/2012/07/23/mei-l-lists-uni-paderborn-de/antw-more-precise-app-s/f/3141983676) and I'd like to follow up a bit on the topic. I understand there's been a number of suggestions, one of the last ones being: This seems a very suitable solution to the problem, but here's my question. With this practice it's possible to define overlapping groupings: I might be shortsighted, but I cannot think of a much meaningful use case for this scenario. Do you think such encoding should be forbidden/discouraged? Or perhaps someone can pinpoint a meaningful use case? Thanks Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: From veit at weber-gesamtausgabe.de Thu Jan 16 11:32:16 2014 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Thu, 16 Jan 2014 11:32:16 +0100 Subject: [MEI-L] Job Offer In-Reply-To: References: Message-ID: <52D7B530.5090704@weber-gesamtausgabe.de> Dear all, please let us announce a new project funded by the Academy of Sciences and Literature at Mainz called "Beethoven's Werkstatt", which will heavily be based on MEI! This new project leads to several job opportunities as offered in the appendix. We should be very grateful to you for disseminating this job offer or for informing suitable possible applicants about this new project. Beeing as merry as a lark about the possibility to have a 16 years project working on this really fascinating topic, with best greetings, Bernhard Appel and Joachim Veit -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : Beethovens_Werkstatt.pdf Dateityp : other/pdf Dateigr??e : 210973 bytes Beschreibung: nicht verf?gbar URL : -------------- 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 raffaeleviglianti at gmail.com Thu Jan 16 15:23:10 2014 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 16 Jan 2014 09:23:10 -0500 Subject: [MEI-L] Job Offer In-Reply-To: <52D7B530.5090704@weber-gesamtausgabe.de> References: <52D7B530.5090704@weber-gesamtausgabe.de> Message-ID: Hello, This looks like an amazing project! Congratulations on securing funding for it. Is there a link to the PDF online, or a webpage for these posts? It would make it easier to share on social media. (The MEI-L archive seem to kill off the pdf attachment). All the best, Raff On Thu, Jan 16, 2014 at 5:32 AM, Joachim Veit wrote: > Dear all, > please let us announce a new project funded by the Academy of Sciences and > Literature at Mainz called "Beethoven's Werkstatt", which will heavily be > based on MEI! > This new project leads to several job opportunities as offered in the > appendix. > We should be very grateful to you for disseminating this job offer or for > informing suitable possible applicants about this new project. > Beeing as merry as a lark about the possibility to have a 16 years project > working on this really fascinating topic, > with best greetings, > Bernhard Appel and Joachim Veit > > > _______________________________________________ > 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 Jan 16 15:43:49 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 16 Jan 2014 14:43:49 +0000 Subject: [MEI-L] Job Offer In-Reply-To: <52D7B530.5090704@weber-gesamtausgabe.de> References: <52D7B530.5090704@weber-gesamtausgabe.de> Message-ID: Dear Joachim, Congratulations! No one should see it, ever, but I'm dancing here in C'ville in response to the happy news. :-) -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Joachim Veit > Sent: Thursday, January 16, 2014 5:32 AM > To: mei-l at lists.uni-paderborn.de > Subject: [MEI-L] Job Offer > > Dear all, > please let us announce a new project funded by the Academy of Sciences > and Literature at Mainz called "Beethoven's Werkstatt", which will heavily > be based on MEI! > This new project leads to several job opportunities as offered in the > appendix. > We should be very grateful to you for disseminating this job offer or for > informing suitable possible applicants about this new project. > Beeing as merry as a lark about the possibility to have a 16 years project > working on this really fascinating topic, with best greetings, Bernhard Appel > and Joachim Veit From veit at weber-gesamtausgabe.de Thu Jan 16 15:50:10 2014 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Thu, 16 Jan 2014 15:50:10 +0100 Subject: [MEI-L] Job Offer In-Reply-To: References: <52D7B530.5090704@weber-gesamtausgabe.de> Message-ID: <52D7F1A2.2080300@weber-gesamtausgabe.de> Hi Raffaele, at the moment, please have a look at: http://www.beethoven-haus-bonn.de/sixcms/detail.php/83875/aktuelles_detail_de We shall try to put it on a webpage with a direct link. But first: Happy and successful new year to you!!! Please excuse that I did not respond your e-Mails from a few days ago - as a matter of course, you can send me all things to check in which you think that I may be of any help!! Concerning the list, please give a some hours more - it's absolutely terrible at the moment because we shall have a presentation of our idea of a center called: Music - Edition - Media (with about 10 new jobs...!!!!) next week and we have trial-presentations at the moment with a lot of discussions. We are beyond the last six ones which have the opportunity to gain one of the three possible grants - that's absolutely terrific and so leasure time goes to zero for the next few days!! Thanks and best greetings, Joachim Am 16.01.14 15:23, schrieb Raffaele Viglianti: > Hello, > > This looks like an amazing project! Congratulations on securing > funding for it. > > Is there a link to the PDF online, or a webpage for these posts? It > would make it easier to share on social media. (The MEI-L archive seem > to kill off the pdf attachment). > > All the best, > Raff > > > On Thu, Jan 16, 2014 at 5:32 AM, Joachim Veit > > wrote: > > Dear all, > please let us announce a new project funded by the Academy of > Sciences and Literature at Mainz called "Beethoven's Werkstatt", > which will heavily be based on MEI! > This new project leads to several job opportunities as offered in > the appendix. > We should be very grateful to you for disseminating this job offer > or for informing suitable possible applicants about this new project. > Beeing as merry as a lark about the possibility to have a 16 years > project working on this really fascinating topic, > with best greetings, > Bernhard Appel and Joachim Veit > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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: -------------- 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 stadler at edirom.de Thu Jan 16 17:37:09 2014 From: stadler at edirom.de (Peter Stadler) Date: Thu, 16 Jan 2014 17:37:09 +0100 Subject: [MEI-L] Job Offer In-Reply-To: <52D7F1A2.2080300@weber-gesamtausgabe.de> References: <52D7B530.5090704@weber-gesamtausgabe.de> <52D7F1A2.2080300@weber-gesamtausgabe.de> Message-ID: <3EEE085F-642B-4F77-B2A2-C68F1C948C66@edirom.de> Another direct link to the pdf: http://www.zv.uni-paderborn.de/fileadmin/zv/dez4/4-4/stellenangebote/aktuelleAusschreibungen/BeethovensWerkstatt.pdf Best Peter Am 16.01.2014 um 15:50 schrieb Joachim Veit : > Hi Raffaele, > at the moment, please have a look at: http://www.beethoven-haus-bonn.de/sixcms/detail.php/83875/aktuelles_detail_de > We shall try to put it on a webpage with a direct link. > But first: Happy and successful new year to you!!! Please excuse that I did not respond your e-Mails from a few days ago - as a matter of course, you can send me all things to check in which you think that I may be of any help!! Concerning the list, please give a some hours more - it's absolutely terrible at the moment because we shall have a presentation of our idea of a center called: Music - Edition - Media (with about 10 new jobs...!!!!) next week and we have trial-presentations at the moment with a lot of discussions. We are beyond the last six ones which have the opportunity to gain one of the three possible grants - that's absolutely terrific and so leasure time goes to zero for the next few days!! > > Thanks and best greetings, > Joachim > > > Am 16.01.14 15:23, schrieb Raffaele Viglianti: >> Hello, >> >> This looks like an amazing project! Congratulations on securing funding for it. >> >> Is there a link to the PDF online, or a webpage for these posts? It would make it easier to share on social media. (The MEI-L archive seem to kill off the pdf attachment). >> >> All the best, >> Raff >> >> >> On Thu, Jan 16, 2014 at 5:32 AM, Joachim Veit wrote: >> Dear all, >> please let us announce a new project funded by the Academy of Sciences and Literature at Mainz called "Beethoven's Werkstatt", which will heavily be based on MEI! >> This new project leads to several job opportunities as offered in the appendix. >> We should be very grateful to you for disseminating this job offer or for informing suitable possible applicants about this new project. >> Beeing as merry as a lark about the possibility to have a 16 years project working on this really fascinating topic, >> with best greetings, >> Bernhard Appel and Joachim Veit >> >> -------------- 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 esteban.hernandez.castello at uni-hamburg.de Thu Jan 16 17:51:04 2014 From: esteban.hernandez.castello at uni-hamburg.de (=?iso-8859-1?Q?Esteban_Hern=E1ndez_Castell=F3?=) Date: Thu, 16 Jan 2014 17:51:04 +0100 Subject: [MEI-L] Job Offer In-Reply-To: <52D7B530.5090704@weber-gesamtausgabe.de> References: <52D7B530.5090704@weber-gesamtausgabe.de> Message-ID: <5101F2FE-F887-4A96-9594-CCF48932F22C@uni-hamburg.de> Wonderful project. We will disseminate the information. Best regards and, of course, CONGRATULATIONS !! Esteban Hern?ndez Castell? El 16/01/2014, a las 11:32, Joachim Veit escribi?: > Dear all, > please let us announce a new project funded by the Academy of Sciences and Literature at Mainz called "Beethoven's Werkstatt", which will heavily be based on MEI! > This new project leads to several job opportunities as offered in the appendix. > We should be very grateful to you for disseminating this job offer or for informing suitable possible applicants about this new project. > Beeing as merry as a lark about the possibility to have a 16 years project working on this really fascinating topic, > with best greetings, > Bernhard Appel and Joachim Veit > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l Dr. Esteban Hern?ndez Castell? Institut f?r Historische Musikwissenschaft Neue Rabenstr. 13 20354 Hamburg ------------ pr?xima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From laurent at music.mcgill.ca Fri Jan 31 15:30:52 2014 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Fri, 31 Jan 2014 15:30:52 +0100 Subject: [MEI-L] Tuplets Message-ID: Hi, Is there a stylesheet (MEIron?) for transforming tuplets encoded with timeSpan elements into tuplet elements? Thanks! Laurent -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From stadler at edirom.de Tue Feb 4 09:29:55 2014 From: stadler at edirom.de (Peter Stadler) Date: Tue, 4 Feb 2014 09:29:55 +0100 Subject: [MEI-L] Fwd: First Call for papers for TEI Conference at Northwestern, October 22-24 References: Message-ID: <810DAAA2-809B-49DB-AAB5-FEF5FD00B700@edirom.de> Dear all, some of you may already seen this call for papers but may I nonetheless direct your attention to point 3: "We will welcome submissions about TEI and MEI in the context of music in a digital world.? This looks like a very explicit invitation to the MEI community, so please spread this call widely and consider a submission! All the best Peter Anfang der weitergeleiteten Nachricht: > Von: Martin Mueller > Betreff: First Call for papers for TEI Conference at Northwestern, October 22-24 > Datum: 3. Februar 2014 20:39:57 MEZ > An: TEI-L at LISTSERV.BROWN.EDU > Antwort an: Martin Mueller > > Dear Colleague, > > This is a first call for submissions of papers and posters for the 2014 > TEI meeting, which will be held at Northwestern University, October 22-24, > 2014. Northwestern is located in Evanston, a northern suburb of Chicago > with excellent public transportation to Chicago's "Loop." > > The deadline for submissions will be April 30, 2014. More soon about the > details of the submission process. As in previous years, we welcome > submissions on anything plausibly related to the Text Encoding Initiative, > but we have a special interest in the following topics: > > 1. The TEI is about text "encoding," but encoded texts need to be > "decoded" by readers who put the encoding to various uses, increasingly > with the aid of digital tools of one kind or another. What is the > scholarly value added by encoding? What can people do with TEI encoded > texts (and what have they done) that they could not otherwise do or have > done? > > 2. In 2015 some 25,000 TEI-encoded Text Creation Partnership (TCP) texts > printed before 1700 will be released into the public domain, and another > 45,000 texts will be released in the five years to follow, producing by > 2020 a deduplicated, structurally encoded, and open source library of just > about every English book printed before 1800. This is a very > consequential event for the documentary infrastructure of Early Modern > Studies in the Anglophone world. It is also an important event for the > TEI. > > 3. As announced earlier, the TEI meeting will partly overlap and share > some programming with the Chicago Digital Humanities and Computer Science > Colloquium, a lively regional conference. Music will be one of its > featured topics and may be a good topic for shared programming. We will > welcome submissions about TEI and MEI in the context of music in a digital > world. > > > We have not yet decided on keynote speakers, and I would very much welcome > off-line suggestions about suitable candidates. > > With best wishes > > Martin Mueller > Chair, Programming Committee, TEI Conference 2014 > Professor emeritus of English and Classics > Northwestern University -- 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 T.Crawford at gold.ac.uk Tue Feb 4 10:41:58 2014 From: T.Crawford at gold.ac.uk (Tim Crawford) Date: Tue, 4 Feb 2014 09:41:58 +0000 Subject: [MEI-L] Media-Eval task Message-ID: <1433b37fddd74ceea10585d03b92dcbe@AM3PR04MB337.eurprd04.prod.outlook.com> Dear MEI-list, Richard Sutcliffe, Tim Crawford, Ed Hovy and Deane Root are proposing a task at MediaEval 2014 which might be of interest to members of this group. It is a combination of natural language processing and musical score analysis. Participants each build a computer system over the coming months which can take as input a natural language noun phrase (e.g. 'harmonic perfect fifth') and a short classical music score in machine-readable form (e.g. J.S. Bach, Suite No. 3 in C Major for Cello, BWV 1009, Sarabande) and return an answer stating the location of the requested feature (e.g. 'Bar 206'). The proposal can be found at this URL: http://doc.gold.ac.uk/~mas01tc/camerata.pdf Results will be compared in October in Barcelona. Would you be interested in taking part or do you know anyone who might be? If so we wonder if you could consider going to https://www.surveymonkey.com/s/mediaeval2014, within it going to task number two - Camerata -, say you are interested in participating and then submit the questionnaire. The level of interest decides whether it will go ahead. Best wishes, Tim Crawford -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Wed Feb 5 20:27:53 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 5 Feb 2014 19:27:53 +0000 Subject: [MEI-L] Tuplets In-Reply-To: References: Message-ID: Hi Laurent, There's no stylesheet just for this purpose that I'm aware of. However, there is code in the MusicXML2MEI stylesheet that handles this. In fact, at the point that it gets called, there's an MEI -> MEI "conversion" going on. So, you should be able to excerpt that bit of code to do what you want. -- p. From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Friday, January 31, 2014 9:31 AM To: MEI-list Subject: [MEI-L] Tuplets Hi, Is there a stylesheet (MEIron?) for transforming tuplets encoded with timeSpan elements into tuplet elements? Thanks! Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent at music.mcgill.ca Wed Feb 5 22:32:25 2014 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Wed, 5 Feb 2014 22:32:25 +0100 Subject: [MEI-L] Tuplets In-Reply-To: <5379_1391628492_52F290CB_5379_274_1_BBCC497C40D85642B90E9F94FC30343D7000A43F@reagan.eservices.virginia.edu> References: <5379_1391628492_52F290CB_5379_274_1_BBCC497C40D85642B90E9F94FC30343D7000A43F@reagan.eservices.virginia.edu> Message-ID: Thank you for this. I'll look into it. Laurent On Wed, Feb 5, 2014 at 8:27 PM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > Hi Laurent, > > > > There's no stylesheet just for this purpose that I'm aware of. However, > there is code in the MusicXML2MEI stylesheet that handles this. In fact, > at the point that it gets called, there's an MEI -> MEI "conversion" going > on. So, you should be able to excerpt that bit of code to do what you > want. > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces+pdr4h= > virginia.edu at lists.uni-paderborn.de] *On Behalf Of *Laurent Pugin > *Sent:* Friday, January 31, 2014 9:31 AM > *To:* MEI-list > *Subject:* [MEI-L] Tuplets > > > > Hi, > > > > Is there a stylesheet (MEIron?) for transforming tuplets encoded with > timeSpan elements into tuplet elements? > > > > Thanks! > > Laurent > > _______________________________________________ > 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 gdibacco at indiana.edu Fri Feb 28 00:21:19 2014 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Thu, 27 Feb 2014 18:21:19 -0500 Subject: [MEI-L] Music Encoding Conference -- Latest Message-ID: <530FC86F.1060208@indiana.edu> An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Thu Mar 6 21:18:33 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 6 Mar 2014 20:18:33 +0000 Subject: [MEI-L] MEI for long-term preservation Message-ID: Hello everyone, Periodically topics arise on the MusicXML mailing list that I hope subscribers to this list would finding interesting as well. Recently, a thread regarding long-term preservation of musical works began with the question -- > Isn't it time for Congress to initiate a challenge on using XML to preserve > works of music? This could include works in the public domain and > protected works that will ultimately end up in the public domain. > Additionally, all works submitted could be used in research and possibly > made available during infringement litigation. I think most of us would agree that this would indeed be a very good thing to do. And I hope that (nearly) all of us would also agree that MEI (the format) is an excellent choice for such an undertaking. Furthermore, I hope that MEI (the organization) can play a role in creating a suitable answer to the question. So, let's start a conversation here -- What technical or political issues does MEI (the format & the organization) need to address/overcome to make this a reality? (I believe that someone from the Library of Congress will attend the conference, so I hope this will also lead to some face-to-face discussion in Charlottesville.) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Thu Mar 6 21:29:55 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 6 Mar 2014 20:29:55 +0000 Subject: [MEI-L] MEI for long-term preservation In-Reply-To: References: Message-ID: Hi again, Look below for the latest message in the MusicXML list thread I mentioned earlier. I think Andrew does an excellent job here of pointing out specific benefits of MEI so I won't attempt to embellish his remarks. Interesting questions raised by the messages Andrew is responding to include - What is the definition/nature/usefulness of a "comprehensive" representation? - Can an XML representation function as the "native format" for a notation editor? - Is it possible to create a conceptual model of notation that editors can share even if they implement it differently? - Can different notational "styles" (Neume, Mensural, and CWMN) be accommodated by the same model? - If not, why not? - What role does "validity" play in a notation format? - Can there be different notions of "validity" at the same time or at different points in the lifecycle of a notated musical object? - How can a model be "interchange-able" and extensible at the same time? And probably at least a thousand more. :-) I'm aware that attempts to answer questions like these can seem like discussing how many angels fit on the head of a pin (or "pin-headed angels" as we refer to them at UVA). But these are precisely the questions that most need answering and MEI (again, the format and the organization) can address. MEI's rise has not been as meteoric as that of MusicXML, nor is it as widely known, but I think MEI is in a position to confront and resolve these thorny issues at least as well as other approaches and probably better due to its design and the people working on it. Best wishes, -- p. > -----Original Message----- > From: Andrew Hankinson [mailto:andrew.hankinson at gmail.com] > Sent: Wednesday, March 05, 2014 2:56 PM > To: musicxml at makemusic.com > Subject: Re: [MusicXML] Library of Congress data challenge > > Any attempt at creating a "standardized" archival format for music notation > should also take into account that music notation itself is not standardized. > There are as many exceptions as there are rules in music notation. Don Byrd > maintains a list of what he calls "extremes" even within Common Music > Notation itself [1] that would be a challenge for any representation to store > in a structured and comprehensive manner. Even beyond these extremes, > there are hundreds, if not thousands, of examples of music notation that > feature unique symbols, or symbols that have different meanings, or circular > staves, irregular rhythms, and strange performance instructions. > > I believe this is why some communities *choose* not to use MusicXML, as > noted by Michael himself. Since MusicXML is an interchange format > specifically designed for representing conventional Western notation > between CWMN editors, it excludes many other systems of notation that, > while not as popular as CWMN, are still important to the communities that > work with them. Musicologists may choose to pursue other formats since > the implicit meaning of the notation in non-measured mensural music in > pre-modern musical works is fundamentally incompatible with structures > for representing modern notation when you're talking about ensuring that > the encoding is faithful to the notation and the music, and not necessarily > to the structures required by the file format. > > In other words, choosing any single non-comprehensive format as a long- > term archival format excludes the storage and representation of certain > musical materials. That's what makes this problem such a tough nut to > crack. Having software that reads and writes notation files is but one edge > of a two-edged sword. The other edge is ensuring that the representation is > faithful to the structure of the notation itself, in whatever form it was > meant to take. You cannot faithfully represent the underlying musical > structures of Gregorian chant in a system (any system) designed to > represent CWMN, or vice versa. Your choices are to either create a system > so generic that you represent the lowest common feature (e.g., pitch and > duration, which is what makes MIDI so flexible but not so expressive) OR > you choose to focus on accurately representing some features at the > expense of not representing others (which is what makes formats like > MusicXML expressive, but not always flexible). > > [1] http://www.informatics.indiana.edu/donbyrd/CMNExtremes.htm > > > On Mar 5, 2014, at 2:11 PM, David Webber > > wrote: > > > From: Mogens Lundholm > > > >> A very interresting and important discussion. My point of view is that > > music-xml should be the native format of music-writing programs and > > players and readers. I.e. you should be able to open and save > > directly - no import and export (MuseScore is terrible). If some thing is > > missing in Music Xml, then add it. < > > > > Unfortunately this will not work. > > > > 1. Software designers design their software very differently, and for > example Mozart's internal representation of notation is very different from > that of MusicXML. (And I'm sure this is true of other software.) So for > import and export a time consuming conversion is done. This would not > work for everyday saving and loading of files. > > > > 2. There is all sorts of non-obvious information that programs can store, > which MusicXML doesn't - and for general purposes probably doesn't want > to. For one arcane example: Mozart has a number of anchor points on the > page. The 'Composed by' text is anchored to a point at the right margin just > above the music, which is to say it knows that this is its anchor point and it > knows how far away from that point it is. You can edit the right margin > width and the top margin, and this text entry automatically just stays where > it is relative to the top right of the music. Other text entries (title, header, > footer, and other miscellaneous text) have other anchor points. MusicXML > just stores a distance from the bottom left of the page. When importing, I > know where on the page any piece of text should go, but not where it > should best be anchored. I wouldn't expect to demand that all other > programs should define and use anchor points the way I do, and so I > wouldn't expect MusicXML to store this information. > > > > 3. You can't expect developers to wait to improve their programs until > requests to the Finale people (a competitor!) get exactly the right nodes > added to the MusicXML spec. > > > >> Davids comments are very intreresting - I also had my fun with the > > -command. And do not like the -command. But now > > these problems are solved, so this is past.< > > > > Solved for me too, but it took a lot of code! > > > >> Midi could work - but unrealistic to collect people to define > > approvements. Just look at the attempt described in the book "Beyond > Midi" > > to define a command for Clef.< > > > > Yes - MIDI isn't and never was a notation format. It doesn't even have > crotchets and quavers: just notes which last so many milliseconds and have > gaps in the sequence for articulation (or overlap). > > > >> I like the idea of a Music XML format checker: There must be a title, > > > > Why? Some people just want to save untitled jottings in files. > > > >> there must be names on the voices/instruments, verse lyrics must be > numbered > > 1,2,3,4,5 etc, must be within song. > > Also there should be number of test-files that a program must pass.< > > > > Why? Suppose you get a MusicXML file which doesn't pass the test? Do > you just put up a sign saying "Sorry this file is illegal" or do you do your best > to import it and get it maybe 95% right? I would argue the latter. [It would > be nice to test for legality but not, I think, essential.] > > > >> The next statements are obvious - but nevertheless not according the > any > > music program I know > >> ... > >> 2. If the program can change a Music XML file, it must preserve > > commands not known to the program > > > > This is not possible. If you edit a piece of music, then some of the things > stored in the original, which you didn't know about, will have become > implicitly invalid. You cannot know which or why, and so you cannot re- > export them and expect a valid MusicXML file. > > > >> ... > > > > So, in summary: nice try but I'm afraid this can't work. While someone > might rise to the challenge of writing a program for which MusicXML is the > native format, that is quite a different proposition from trying to write the > best music editor you can. This is why MusicXML will always primarily be an > exchange format. > > > > Dave > > > > David Webber > > Mozart Music Software > > http://www.mozart.co.uk/ > > > > ----------------------------------------------------------------------------- > > Post your message to the list by sending it to musicxml at makemusic.com. > > > > To contact the list owner, send your message to > > musicxml-list-owner at makemusic.com. > > > > To unsubscribe, switch to/from digest, get on/off vacation, or change your > email address, click here. > > > list.com/u?ln=musicxml&nm=andrew.hankinson%40gmail.com> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Tue Mar 11 15:56:55 2014 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 11 Mar 2014 15:56:55 +0100 Subject: [MEI-L] Conference Schedule Message-ID: <97687DD8-2A69-4348-8DFD-CE77F5C2A385@edirom.de> Dear Music Encoders, we're pleased to announce the schedule for the Music Encoding Conference in Charlottesville. It is available from http://music-encoding.org/conference/schedule2014 Please note that the schedule you see there is provisional and may still change. That said, we think it is quite stable already, and we don't expect major changes. A prospective update will include the titles of poster presentations. Hope to see many of you in Charlottesville. For the PC / organizers, Johannes -------------- 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 dave at titanmusic.com Tue Mar 11 16:20:41 2014 From: dave at titanmusic.com (David Meredith) Date: Tue, 11 Mar 2014 16:20:41 +0100 Subject: [MEI-L] Conference Schedule In-Reply-To: <97687DD8-2A69-4348-8DFD-CE77F5C2A385@edirom.de> References: <97687DD8-2A69-4348-8DFD-CE77F5C2A385@edirom.de> Message-ID: Hi, Giuliano told me to expect our paper on "CriticalEd" to be a poster, but I see it has been scheduled as an oral presentation. Just wanted to check this was not an error before I tell Caspar to go and make some slides :) Cheers, Dave -----Original Message----- From: Johannes Kepper Reply-To: Music Encoding Initiative Date: Tuesday, 11 March 2014 15:56 To: Music Encoding Initiative Subject: [MEI-L] Conference Schedule >Dear Music Encoders, > >we're pleased to announce the schedule for the Music Encoding Conference >in Charlottesville. It is available from > >http://music-encoding.org/conference/schedule2014 > > >Please note that the schedule you see there is provisional and may still >change. That said, we think it is quite stable already, and we don't >expect major changes. A prospective update will include the titles of >poster presentations. > >Hope to see many of you in Charlottesville. > >For the PC / organizers, >Johannes >_______________________________________________ >mei-l mailing list >mei-l at lists.uni-paderborn.de >https://lists.uni-paderborn.de/mailman/listinfo/mei-l From pdr4h at eservices.virginia.edu Wed Mar 12 19:27:07 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 12 Mar 2014 18:27:07 +0000 Subject: [MEI-L] Berlin Wall Coming to U.Va. Grounds Message-ID: Some of you may be interested to hear that a section of the Berlin Wall is being installed near the conference venue this week. Visit http://news.virginia.edu/content/berlin-wall-coming-uva-grounds for more details. -- 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 pdr4h at eservices.virginia.edu Tue Mar 18 15:24:05 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 18 Mar 2014 14:24:05 +0000 Subject: [MEI-L] Music Encoding Conference call for late-breaking submissions Message-ID: With apologies for duplicate postings. The Music Encoding Conference Charlottesville, Virginia 20-23 May 2014 https://music-encoding.org/conference The Program Committee announces that "late-breaking" poster submissions will be accepted until *April 14th*. "Late-breaking" posters usually aim to present research projects under development or results that were not available at the time of the original call for submissions. New submissions will be subject to the same review process as before. Please visit https://music-encoding.org/conference/submission for more details. Authors of accepted posters will be notified on or before *24 April* and will need to register by *30 April*. We won't be able to grant any extension. If you have any questions, please contact conference2013 at music-encoding.org. -- 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 bohl at edirom.de Thu Mar 20 15:12:25 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 20 Mar 2014 15:12:25 +0100 Subject: [MEI-L] MEI for long-term preservation In-Reply-To: References: Message-ID: <532AF749.3020606@edirom.de> Hi all, hi Perry, thanks for bringing this interesting discussion to MEI-L, too! Andrew definitely has been doing a great job, and not only on MusicXML list but also elsewhere: <%3Chttp://www.sibeliusblog.com/news/mei-plug-in-released-for-sibelius/%3E> @Andrew: Thanks!! From a political perspective one might argue that MEI needs: - to spread the word, and awareness about its existence. Also and this might prove a bit hard in non-scholarly circles. Tools might help here ;-) - provide stability and backwards compatibility, or at least the tools to do up-conversions. For archival purposes the long term perspective is essential.This could mean: * to provide a (more) stable branch for MEI for certain repertories (e.g. PVG [piano-voice-guitar]) * to somehow define the current stability of certain modules, * provide a module specific tool reference (if you want to do this or that use module X being supported by tools T, U, and V or the like) * improve the guidelines, e.g. with descriptive use cases, interlinking of sections, etc. * create a development plan, and not only communicate what has been changed but what shall be changed in the future (best with some approximated "deadlines") This was just a quick brainstorming, not too well thought of but maybe worth the discussion ;-) 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 06.03.2014 21:18, schrieb Roland, Perry (pdr4h): > > Hello everyone, > > Periodically topics arise on the MusicXML mailing list that I hope > subscribers to this list would finding interesting as well. Recently, > a thread regarding long-term preservation of musical works began with > the question -- > > > Isn't it time for Congress to initiate a challenge on using XML to > preserve > > works of music? This could include works in the public domain and > > protected works that will ultimately end up in the public domain. > > Additionally, all works submitted could be used in research and > possibly > > made available during infringement litigation. > > I think most of us would agree that this would indeed be a very good > thing to do. And I hope that (nearly) all of us would also agree that > MEI (the format) is an excellent choice for such an undertaking. > Furthermore, I hope that MEI (the organization) can play a role in > creating a suitable answer to the question. > > So, let's start a conversation here -- What technical or political > issues does MEI (the format & the organization) need to > address/overcome to make this a reality? > > (I believe that someone from the Library of Congress will attend the > conference, so I hope this will also lead to some face-to-face > discussion in Charlottesville.) > > 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 > > > > _______________________________________________ > 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 nikolaos.beer at uni-paderborn.de Mon Mar 24 17:22:28 2014 From: nikolaos.beer at uni-paderborn.de (Nikolaos Beer) Date: Mon, 24 Mar 2014 17:22:28 +0100 Subject: [MEI-L] New version of MEI Score Editor Message-ID: <91F1EBC4-CF17-41F1-86C4-EE7F1ECFEB3C@uni-paderborn.de> Dear list members, I am pleased to announce a new version of MEI Score Editor (MEISE) on sourceforge for OS X and Windows: https://sourceforge.net/projects/meise/ Some notes on this version: - exclusive support for MEI 2013 - basic improvements of note rendering capabilities (e.g. clefs, key signatures and notes with respect to (given) clef lines, new glyphs for articulation signs) - processing and rendering of nested section and ending elements - drawing and allocation of elements with respect to linked IDs (e.g. fermata, dynamic signs, ties, slurs) - drawing notes in chords with respect to durations - harmonization of note rendering and user interface between the Mac and the Windows version - stability improvements when editing element attributes - preparation for the rendering of octave clefs and grace notes (attributes can be edited within the Properties View) Known problems: - endings without number brackets - some incorrect positioned articulation signs in the Windows version - incorrect synchronization of note rendering in time between staves Documentation: You can find installation instructions and the program documentation in the project's wiki space on sourceforge: https://sourceforge.net/p/meise/wiki/Home/ If you are interested in Use Case and Workflow Descriptions you are invited to the (english) MEISE pages at the DARIAH-DE web portal: https://de.dariah.eu/mei-score-editor. Future perspectives: Starting this March, the development of MEISE will be funded for two more years within the second funding phase of DARIAH-DE, which is the German part of the EU eHumanities research project Digital Research Infrastructure for the Arts and Humanities. It is funded by the German Federal Ministry of Education and Research (http://de.dariah.eu or http://www.dariah.eu). The development of MEISE is part of DARIAH-DE Cluster 6: Scholarly Annotations ? Services and Applications. We are looking forward to presenting our plans for MEISE at the MEC 2014 in Charlottesville in May. I want to thank Daniel R?wenstrunk for many hints with the MEISE source code and Maja Hartwig for preparing the documentation. If you have any questions please feel free to contact me. Best regards Niko Beer ___________________________________ Nikolaos Beer M.A. Wissenschaftlicher Mitarbeiter BMBF-Projekt ?DARIAH-DE? und Verbundstelle Musikedition Universit?t Paderborn Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D-32756 Detmold Fon: +49 - (0)5231 - 975 - 669 @: nikolaos.beer at uni-paderborn.de -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From andrew.hankinson at mail.mcgill.ca Mon Mar 24 17:29:43 2014 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 24 Mar 2014 16:29:43 +0000 Subject: [MEI-L] New version of MEI Score Editor In-Reply-To: <11414_1395678167_53305BD7_11414_219_1_91F1EBC4-CF17-41F1-86C4-EE7F1ECFEB3C@uni-paderborn.de> References: <11414_1395678167_53305BD7_11414_219_1_91F1EBC4-CF17-41F1-86C4-EE7F1ECFEB3C@uni-paderborn.de> Message-ID: <64B2C15E-F1BD-4C4D-9D89-7F6DA4E92AF7@mail.mcgill.ca> Congrats Niko! It looks great. -Andrew On Mar 24, 2014, at 12:22 PM, Nikolaos Beer > wrote: Dear list members, I am pleased to announce a new version of MEI Score Editor (MEISE) on sourceforge for OS X and Windows: https://sourceforge.net/projects/meise/ Some notes on this version: - exclusive support for MEI 2013 - basic improvements of note rendering capabilities (e.g. clefs, key signatures and notes with respect to (given) clef lines, new glyphs for articulation signs) - processing and rendering of nested section and ending elements - drawing and allocation of elements with respect to linked IDs (e.g. fermata, dynamic signs, ties, slurs) - drawing notes in chords with respect to durations - harmonization of note rendering and user interface between the Mac and the Windows version - stability improvements when editing element attributes - preparation for the rendering of octave clefs and grace notes (attributes can be edited within the Properties View) Known problems: - endings without number brackets - some incorrect positioned articulation signs in the Windows version - incorrect synchronization of note rendering in time between staves Documentation: You can find installation instructions and the program documentation in the project's wiki space on sourceforge: https://sourceforge.net/p/meise/wiki/Home/ If you are interested in Use Case and Workflow Descriptions you are invited to the (english) MEISE pages at the DARIAH-DE web portal: https://de.dariah.eu/mei-score-editor. Future perspectives: Starting this March, the development of MEISE will be funded for two more years within the second funding phase of DARIAH-DE, which is the German part of the EU eHumanities research project Digital Research Infrastructure for the Arts and Humanities. It is funded by the German Federal Ministry of Education and Research (http://de.dariah.eu or http://www.dariah.eu). The development of MEISE is part of DARIAH-DE Cluster 6: Scholarly Annotations ? Services and Applications. We are looking forward to presenting our plans for MEISE at the MEC 2014 in Charlottesville in May. I want to thank Daniel R?wenstrunk for many hints with the MEISE source code and Maja Hartwig for preparing the documentation. If you have any questions please feel free to contact me. Best regards Niko Beer ___________________________________ Nikolaos Beer M.A. Wissenschaftlicher Mitarbeiter BMBF-Projekt ?DARIAH-DE? und Verbundstelle Musikedition Universit?t Paderborn Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D-32756 Detmold Fon: +49 - (0)5231 - 975 - 669 @: nikolaos.beer at uni-paderborn.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 nikolaos.beer at uni-paderborn.de Wed Mar 26 13:43:23 2014 From: nikolaos.beer at uni-paderborn.de (Nikolaos Beer) Date: Wed, 26 Mar 2014 13:43:23 +0100 Subject: [MEI-L] Save the date: Edirom-Summer-School 2014 Message-ID: <73194C3F-B6FF-4205-9DD8-798BFA5C0118@uni-paderborn.de> Dear colleagues, please let me inform you about this year's Edirom-Summer-School (ESS) which will take place 8 to 12 September 2014 at the Heinz Nixdorf Institute of the University of Paderborn, Germany. After last two years' successful cooperation with the german eHumanities project DARIAH-DE, we are proud to announce that this year ESS will officially be co-organized by the Virtual Research Group Edirom (University of Paderborn) and DARIAH-DE. The scope of courses 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 editorial or library purposes, up to courses dealing with more advanced topics in these fields. The Edirom User Forum again will give opportunity of exchange between current and (potential) future users of the Edirom Tools. This year, we are happy to announce the possibility to apply for a student bursary within the scope of the EADH's Small Grant Program (http://eadh.org) to support ESS attendance for one student. Further information about the ESS's program schedule, registration and application for the student bursary will be provided in April 2014 on the ESS Website at http://ess.uni-paderborn.de. We would like to ask you to forward this announcement to any other persons of interest. In case of any questions about the ESS 2014, please feel free to contact the organization team at ess at edirom.de. The Virtual Research Group Edirom is based at the Musicology Seminar Detmold/Paderborn, which is a co-faculty of the University of Paderborn and the Hochschule f?r Musik Detmold. Please find further information at http://www.edirom.de. DARIAH-DE is the German part of the EU eHumanities research project Digital Research Infrastructure for the Arts and Humanities. It is funded by the German Federal Ministry of Education and Research. Please find further information at http://de.dariah.eu. For the ESS organization team Nikolaos Beer ___________________________________ Nikolaos Beer M.A. Wissenschaftlicher Mitarbeiter BMBF-Projekt ?DARIAH-DE? und Verbundstelle Musikedition Universit?t Paderborn Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D-32756 Detmold Fon: +49 - (0)5231 - 975 - 669 @: nikolaos.beer at uni-paderborn.de -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From kepper at edirom.de Wed Apr 2 11:39:16 2014 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 2 Apr 2014 11:39:16 +0200 Subject: [MEI-L] history of sources / items Message-ID: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> Dear list, while discussing the upcoming Weber Werkverzeichnis (Weber's work catalogue) with Kristina Richts and Joachim Veit, I can't remember why we dropped the element from sources and items? We have it on works and expressions, but not on these two. However, it might be interested to write something about the creation of a source (which is not the same as the provenance, which is available). Can someone please remind me of our argument to drop it? Otherwise, it would be a fault that we might want to correct? Btw., seems to be equally hidden (you can get it from source at source/physDesc/physMedium/bibl?). Best, Johannes -------------- 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 atge at kb.dk Wed Apr 2 12:01:15 2014 From: atge at kb.dk (Axel Teich Geertinger) Date: Wed, 2 Apr 2014 10:01:15 +0000 Subject: [MEI-L] history of sources / items In-Reply-To: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> Message-ID: <0D96D5D1-83E6-43BC-BD63-95DE8F30C45C@kb.dk> Hi Johannes/Kristina/Joachim As far as I remember was not actively dropped from source and item, it just never has been implemented. Introducing it could be a good idea indeed. In that context I would like to call to mind the question about the element again, now placed in . It has been suggested moving it to , but placing it in a history element seems even better to me. But yes, that would break backward compatibility :-( Best wishes, Axel Den 02/04/2014 kl. 11.39 skrev "Johannes Kepper" : > Dear list, > > while discussing the upcoming Weber Werkverzeichnis (Weber's work catalogue) with Kristina Richts and Joachim Veit, I can't remember why we dropped the element from sources and items? We have it on works and expressions, but not on these two. However, it might be interested to write something about the creation of a source (which is not the same as the provenance, which is available). Can someone please remind me of our argument to drop it? Otherwise, it would be a fault that we might want to correct? > > Btw., seems to be equally hidden (you can get it from source at source/physDesc/physMedium/bibl?). > > Best, > 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 Apr 2 15:13:30 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Wed, 02 Apr 2014 15:13:30 +0200 Subject: [MEI-L] Proposals MEI Strategy Development Group Message-ID: <533C0CFA.4040106@edirom.de> Dear MEI-L, after Music Encoding Conference 2013 MEI Strategy Development Group (MEI-Strat) was formed in order to elaborate proposals for future organization of MEI community. During the past months we have been working in order to start discussion on potential future forms of organizing MEI community. Now with the Music Encoding Conference 2014 being just around the corner it seems appropriate to start discussion on this subject matter, as we hope to distil a common community consensus on what might be new and openly communicated structures of MEI. Furthermore we intend to prepare presenations and a basis for further discussion for this year's conference (May 20-23 in Charlottesville, VA). ==A short disclaimer== Please be aware that anything in the proposal is indicative and subject to discussion, be it the individual proposals in general, or specific details, e.g. the length of terms for elected members. ==Words of thank== We thank the MEI community for the possibility to work on this subject matter, and for the confidence in our group! I personally like to thank all collaborators for their time, effort and good thoughts all of which were provided on expense of their private free time! ==The Discussion== The document containing our proposals is openly available online via google-Drive (no login required). Although modification of the text is not possible comments may be inserted by anyone with the link. Feel free to provide your identity when commenting or just submit anonymously. Of course it is not intended to discuss all raised topics in the document. A lively discussion on MEI-L would be warmly welcome so bring anything of interest to discussion there! ==The Document== https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing With many thanks to all collaborators, for the MEI Strategy Development Group, Benajmin 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 *********************************************************** From kepper at edirom.de Wed Apr 2 15:45:40 2014 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 2 Apr 2014 15:45:40 +0200 Subject: [MEI-L] Proposals MEI Strategy Development Group In-Reply-To: <533C0CFA.4040106@edirom.de> References: <533C0CFA.4040106@edirom.de> Message-ID: <96987F49-BC05-411F-A8BF-121C9A96B92F@edirom.de> Dear community, Thanks Benni for bringing this up. I hope everyone in the community recognizes the effort that went into the preparation of these proposals. The best reply by the community would now be a lively discussion. Thus, I encourage everyone to speak up. Do these proposals reflect your personal views on and hopes for MEI? If not, how could they be modified? What else would you like to see? Have they missed something? MEI is a community project, and as such, it is up to the community to define the rules of it. It is certainly no one's intention to overregulate things, but last year in Mainz, we felt that there should be a more transparent model for MEI. Now is the time to discuss. There is no right or wrong, there are just arguments? I know that this is going to be hard work, but both the strategy group and the other interim group installed last year would really love to reach a consensus on this, instead of voting. This is only possible if we put all arguments out there. I'm sure someone will feed summaries of the Google Doc comments into the MEI-L discussion on a regular basis, but please use both channels to have a say on this. We hope to reach a consensus before or at the conference (about seven weeks ahead). I hope this schedule keeps us all focussed, and we manage to set up simple and clear rules for the future organization of MEI. Best, Johannes (not the keeper, but the Kepper) Am 02.04.2014 um 15:13 schrieb Benjamin Wolff Bohl : > Dear MEI-L, > > after Music Encoding Conference 2013 MEI Strategy Development Group (MEI-Strat) was formed in order to elaborate proposals for future organization of MEI community. During the past months we have been working in order to start discussion on potential future forms of organizing MEI community. > > Now with the Music Encoding Conference 2014 being just around the corner it seems appropriate to start discussion on this subject matter, as we hope to distil a common community consensus on what might be new and openly communicated structures of MEI. Furthermore we intend to prepare presenations and a basis for further discussion for this year's conference (May 20-23 in Charlottesville, VA). > > ==A short disclaimer== > Please be aware that anything in the proposal is indicative and subject to discussion, be it the individual proposals in general, or specific details, e.g. the length of terms for elected members. > > ==Words of thank== > We thank the MEI community for the possibility to work on this subject matter, and for the confidence in our group! > I personally like to thank all collaborators for their time, effort and good thoughts all of which were provided on expense of their private free time! > > ==The Discussion== > The document containing our proposals is openly available online via google-Drive (no login required). Although modification of the text is not possible comments may be inserted by anyone with the link. Feel free to provide your identity when commenting or just submit anonymously. > Of course it is not intended to discuss all raised topics in the document. A lively discussion on MEI-L would be warmly welcome so bring anything of interest to discussion there! > > ==The Document== > https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing > > > With many thanks to all collaborators, > for the MEI Strategy Development Group, > Benajmin 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 > *********************************************************** > > > _______________________________________________ > 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 esfield at stanford.edu Thu Apr 3 02:50:17 2014 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Wed, 2 Apr 2014 17:50:17 -0700 (PDT) Subject: [MEI-L] history of sources / items In-Reply-To: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> Message-ID: <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu> "Provenance" is a standard item in catalogues of works in manuscript, but it has a range of meanings, all of which might comfortable fit within "history". It sometimes identifies previously owners but equally often it refers to a physical location (city, institution, performing group et al.). 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 Johannes Kepper Sent: Wednesday, April 02, 2014 2:39 AM To: Music Encoding Initiative Subject: [MEI-L] history of sources / items Dear list, while discussing the upcoming Weber Werkverzeichnis (Weber's work catalogue) with Kristina Richts and Joachim Veit, I can't remember why we dropped the element from sources and items? We have it on works and expressions, but not on these two. However, it might be interested to write something about the creation of a source (which is not the same as the provenance, which is available). Can someone please remind me of our argument to drop it? Otherwise, it would be a fault that we might want to correct. Btw., seems to be equally hidden (you can get it from source at source/physDesc/physMedium/bibl.). Best, Johannes From kepper at edirom.de Thu Apr 3 11:16:01 2014 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 3 Apr 2014 11:16:01 +0200 Subject: [MEI-L] history of sources / items In-Reply-To: <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu> References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu> Message-ID: I was hoping to get a reply from Perry, especially since I think this dates back to the days before FRBR, when there were work and source elements. expression and item just inherited their standard models with little modifications, so I'm not surprised about their behavior. However, I also prefer to add a history element to source and item, and moving provenance in there seems like a logical modification then. I wouldn't worry too much about backward compatibility. I think we're past the point where we'd have to make huge changes to the model, and little modifications should require only little modifications in software. Also, providing a XSLT to go back and forth between MEI2013 and MEI201x is not an issue, so that people could use whatever is most appropriate to them. This might result in putting the history somewhere nested into a notesStmt when going back to 2013, but so be it? I remember discussions about structured vs. prose-based content models for a number of elements, among them bibl and annot. Does this relate to the initial question, and should we revise it as well? Johannes Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field : > "Provenance" is a standard item in catalogues of works in manuscript, but > it has a range of meanings, all of which might comfortable fit within > "history". It sometimes identifies previously owners but equally often it > refers to a physical location (city, institution, performing group et > al.). > > 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 > Johannes Kepper > Sent: Wednesday, April 02, 2014 2:39 AM > To: Music Encoding Initiative > Subject: [MEI-L] history of sources / items > > Dear list, > > while discussing the upcoming Weber Werkverzeichnis (Weber's work > catalogue) with Kristina Richts and Joachim Veit, I can't remember why we > dropped the element from sources and items? We have it on works > and expressions, but not on these two. However, it might be interested to > write something about the creation of a source (which is not the same as > the provenance, which is available). Can someone please remind me of our > argument to drop it? Otherwise, it would be a fault that we might want to > correct. > > Btw., seems to be equally hidden (you can get it from source at > source/physDesc/physMedium/bibl.). > > 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 : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From pdr4h at eservices.virginia.edu Thu Apr 3 15:10:48 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 3 Apr 2014 13:10:48 +0000 Subject: [MEI-L] history of sources / items In-Reply-To: References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu>, Message-ID: Johannes, Sorry for arriving late to the party. :-) The element wasn't provided in source (manifestation) and item in order to encourage the use of work/history or expression/history. The assumption was that what folks often have to say about a manifestation or item is really about the work and expression anyway. A notesStmt/annot element (perhaps with a label of "history" in this case) can be used as a "catch all" to capture any information not easily shoe-horned into the other available elements in work, expression, source, and item. But, since the models of source and item are essentially lists of optional children, it's also not difficult to add in all these places without creating any backwards compatibility problems. Before doing so, however, I'd like to know more about what you'd like to say about source and/or item history that makes this necessary. I'm not in favor of moving inside because doing this would mean breaking compatibility. It would also make provenance available inside work, expression, and source (e.g., work/history/provenance) where its presence could lead to abuse. What exactly is the provenance (that is, the custodial history) of a work or expression? I don't there is such a thing. I don't understand what problem you're having with inside . Are you looking to provide bibliographic citations for whatever arguments you present in ? I need more information, please. -- p. __________________________ Perry Roland 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: Thursday, April 03, 2014 5:16 AM To: Music Encoding Initiative Subject: Re: [MEI-L] history of sources / items I was hoping to get a reply from Perry, especially since I think this dates back to the days before FRBR, when there were work and source elements. expression and item just inherited their standard models with little modifications, so I'm not surprised about their behavior. However, I also prefer to add a history element to source and item, and moving provenance in there seems like a logical modification then. I wouldn't worry too much about backward compatibility. I think we're past the point where we'd have to make huge changes to the model, and little modifications should require only little modifications in software. Also, providing a XSLT to go back and forth between MEI2013 and MEI201x is not an issue, so that people could use whatever is most appropriate to them. This might result in putting the history somewhere nested into a notesStmt when going back to 2013, but so be it? I remember discussions about structured vs. prose-based content models for a number of elements, among them bibl and annot. Does this relate to the initial question, and should we revise it as well? Johannes Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field : > "Provenance" is a standard item in catalogues of works in manuscript, but > it has a range of meanings, all of which might comfortable fit within > "history". It sometimes identifies previously owners but equally often it > refers to a physical location (city, institution, performing group et > al.). > > 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 > Johannes Kepper > Sent: Wednesday, April 02, 2014 2:39 AM > To: Music Encoding Initiative > Subject: [MEI-L] history of sources / items > > Dear list, > > while discussing the upcoming Weber Werkverzeichnis (Weber's work > catalogue) with Kristina Richts and Joachim Veit, I can't remember why we > dropped the element from sources and items? We have it on works > and expressions, but not on these two. However, it might be interested to > write something about the creation of a source (which is not the same as > the provenance, which is available). Can someone please remind me of our > argument to drop it? Otherwise, it would be a fault that we might want to > correct. > > Btw., seems to be equally hidden (you can get it from source at > source/physDesc/physMedium/bibl.). > > Best, > Johannes > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From pdr4h at eservices.virginia.edu Thu Apr 3 15:21:05 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 3 Apr 2014 13:21:05 +0000 Subject: [MEI-L] history of sources / items In-Reply-To: <0D96D5D1-83E6-43BC-BD63-95DE8F30C45C@kb.dk> References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de>, <0D96D5D1-83E6-43BC-BD63-95DE8F30C45C@kb.dk> Message-ID: Hi Axel, You're right -- it's not that was actively dropped, it was never included in the first place. I'm not averse to adding it, but I'd like to hear a good argument for doing it first. Can you give me an example of what's not possible now that adding would fix? Perhaps it was a bad choice of name, but wasn't intended to be a summary of all the physical locations that an item has/had during its lifespan. That's what is for. is only for an item's *current* location; that is, its holding institution and shelf mark. I think it's important to separate the two (as they frequently are in library practice). And, as you observe, munging them together now would cause compatibility problems. So, I don't see a good reason to open that can of worms. -- p. __________________________ Perry Roland 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 Axel Teich Geertinger [atge at kb.dk] Sent: Wednesday, April 02, 2014 6:01 AM To: Music Encoding Initiative Subject: Re: [MEI-L] history of sources / items Hi Johannes/Kristina/Joachim As far as I remember was not actively dropped from source and item, it just never has been implemented. Introducing it could be a good idea indeed. In that context I would like to call to mind the question about the element again, now placed in . It has been suggested moving it to , but placing it in a history element seems even better to me. But yes, that would break backward compatibility :-( Best wishes, Axel Den 02/04/2014 kl. 11.39 skrev "Johannes Kepper" : > Dear list, > > while discussing the upcoming Weber Werkverzeichnis (Weber's work catalogue) with Kristina Richts and Joachim Veit, I can't remember why we dropped the element from sources and items? We have it on works and expressions, but not on these two. However, it might be interested to write something about the creation of a source (which is not the same as the provenance, which is available). Can someone please remind me of our argument to drop it? Otherwise, it would be a fault that we might want to correct? > > Btw., seems to be equally hidden (you can get it from source at source/physDesc/physMedium/bibl?). > > 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 kepper at edirom.de Thu Apr 3 15:26:19 2014 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 3 Apr 2014 15:26:19 +0200 Subject: [MEI-L] history of sources / items In-Reply-To: References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu>, Message-ID: <6D36A4E3-B604-48BE-81A7-E13B023CEC1C@edirom.de> Am 03.04.2014 um 15:10 schrieb Roland, Perry D. (pdr4h) : > Johannes, > > Sorry for arriving late to the party. :-) > > The element wasn't provided in source (manifestation) and item in order to encourage the use of work/history or expression/history. The assumption was that what folks often have to say about a manifestation or item is really about the work and expression anyway. Sometimes you have a copy, and you would like to tell the story behind it ? why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI? > > A notesStmt/annot element (perhaps with a label of "history" in this case) can be used as a "catch all" to capture any information not easily shoe-horned into the other available elements in work, expression, source, and item. But, since the models of source and item are essentially lists of optional children, it's also not difficult to add in all these places without creating any backwards compatibility problems. Before doing so, however, I'd like to know more about what you'd like to say about source and/or item history that makes this necessary. > > I'm not in favor of moving inside because doing this would mean breaking compatibility. It would also make provenance available inside work, expression, and source (e.g., work/history/provenance) where its presence could lead to abuse. What exactly is the provenance (that is, the custodial history) of a work or expression? I don't there is such a thing. Well, I see your point, and I agree with that. There is certainly no provenance of a work or expression. The kind of information someone would be looking for is about the transmission of the work, which should go into history. However, I still think that might be a better parent for than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression? > > I don't understand what problem you're having with inside . Are you looking to provide bibliographic citations for whatever arguments you present in ? I need more information, please. I have no problem with bibl inside source, except that it isn't allowed. I'd like to be able to put in literature about a specific source (like a review of a printed edition etc.), that's it. The current means to get a bibl into source seem to be too complicated? Hth, Johannes Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > -- > p. > > __________________________ > Perry Roland > 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: Thursday, April 03, 2014 5:16 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] history of sources / items > > I was hoping to get a reply from Perry, especially since I think this dates back to the days before FRBR, when there were work and source elements. expression and item just inherited their standard models with little modifications, so I'm not surprised about their behavior. > > However, I also prefer to add a history element to source and item, and moving provenance in there seems like a logical modification then. I wouldn't worry too much about backward compatibility. I think we're past the point where we'd have to make huge changes to the model, and little modifications should require only little modifications in software. Also, providing a XSLT to go back and forth between MEI2013 and MEI201x is not an issue, so that people could use whatever is most appropriate to them. This might result in putting the history somewhere nested into a notesStmt when going back to 2013, but so be it? > > I remember discussions about structured vs. prose-based content models for a number of elements, among them bibl and annot. Does this relate to the initial question, and should we revise it as well? > > > Johannes > Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > > > Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field : > >> "Provenance" is a standard item in catalogues of works in manuscript, but >> it has a range of meanings, all of which might comfortable fit within >> "history". It sometimes identifies previously owners but equally often it >> refers to a physical location (city, institution, performing group et >> al.). >> >> 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 >> Johannes Kepper >> Sent: Wednesday, April 02, 2014 2:39 AM >> To: Music Encoding Initiative >> Subject: [MEI-L] history of sources / items >> >> Dear list, >> >> while discussing the upcoming Weber Werkverzeichnis (Weber's work >> catalogue) with Kristina Richts and Joachim Veit, I can't remember why we >> dropped the element from sources and items? We have it on works >> and expressions, but not on these two. However, it might be interested to >> write something about the creation of a source (which is not the same as >> the provenance, which is available). Can someone please remind me of our >> argument to drop it? Otherwise, it would be a fault that we might want to >> correct. >> >> Btw., seems to be equally hidden (you can get it from source at >> source/physDesc/physMedium/bibl.). >> >> 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 -------------- 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 veit at weber-gesamtausgabe.de Thu Apr 3 15:27:07 2014 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Thu, 03 Apr 2014 15:27:07 +0200 Subject: [MEI-L] history of sources / items In-Reply-To: References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu>, Message-ID: <533D61AB.8090603@weber-gesamtausgabe.de> Hi Perry, please wait a while and you will have a file with our problems with history, so that will no longer be a mystery! Till later, Joachim Am 03.04.14 15:10, schrieb Roland, Perry D. (pdr4h): > Johannes, > > Sorry for arriving late to the party. :-) > > The element wasn't provided in source (manifestation) and item in order to encourage the use of work/history or expression/history. The assumption was that what folks often have to say about a manifestation or item is really about the work and expression anyway. > > A notesStmt/annot element (perhaps with a label of "history" in this case) can be used as a "catch all" to capture any information not easily shoe-horned into the other available elements in work, expression, source, and item. But, since the models of source and item are essentially lists of optional children, it's also not difficult to add in all these places without creating any backwards compatibility problems. Before doing so, however, I'd like to know more about what you'd like to say about source and/or item history that makes this necessary. > > I'm not in favor of moving inside because doing this would mean breaking compatibility. It would also make provenance available inside work, expression, and source (e.g., work/history/provenance) where its presence could lead to abuse. What exactly is the provenance (that is, the custodial history) of a work or expression? I don't there is such a thing. > > I don't understand what problem you're having with inside . Are you looking to provide bibliographic citations for whatever arguments you present in ? I need more information, please. > > -- > p. > > __________________________ > Perry Roland > 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: Thursday, April 03, 2014 5:16 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] history of sources / items > > I was hoping to get a reply from Perry, especially since I think this dates back to the days before FRBR, when there were work and source elements. expression and item just inherited their standard models with little modifications, so I'm not surprised about their behavior. > > However, I also prefer to add a history element to source and item, and moving provenance in there seems like a logical modification then. I wouldn't worry too much about backward compatibility. I think we're past the point where we'd have to make huge changes to the model, and little modifications should require only little modifications in software. Also, providing a XSLT to go back and forth between MEI2013 and MEI201x is not an issue, so that people could use whatever is most appropriate to them. This might result in putting the history somewhere nested into a notesStmt when going back to 2013, but so be it? > > I remember discussions about structured vs. prose-based content models for a number of elements, among them bibl and annot. Does this relate to the initial question, and should we revise it as well? > > > Johannes > Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > > > Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field : > >> "Provenance" is a standard item in catalogues of works in manuscript, but >> it has a range of meanings, all of which might comfortable fit within >> "history". It sometimes identifies previously owners but equally often it >> refers to a physical location (city, institution, performing group et >> al.). >> >> 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 >> Johannes Kepper >> Sent: Wednesday, April 02, 2014 2:39 AM >> To: Music Encoding Initiative >> Subject: [MEI-L] history of sources / items >> >> Dear list, >> >> while discussing the upcoming Weber Werkverzeichnis (Weber's work >> catalogue) with Kristina Richts and Joachim Veit, I can't remember why we >> dropped the element from sources and items? We have it on works >> and expressions, but not on these two. However, it might be interested to >> write something about the creation of a source (which is not the same as >> the provenance, which is available). Can someone please remind me of our >> argument to drop it? Otherwise, it would be a fault that we might want to >> correct. >> >> Btw., seems to be equally hidden (you can get it from source at >> source/physDesc/physMedium/bibl.). >> >> 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 -------------- 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 veit at weber-gesamtausgabe.de Thu Apr 3 16:05:48 2014 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Thu, 03 Apr 2014 16:05:48 +0200 Subject: [MEI-L] history of sources / items In-Reply-To: <6D36A4E3-B604-48BE-81A7-E13B023CEC1C@edirom.de> References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu>, <6D36A4E3-B604-48BE-81A7-E13B023CEC1C@edirom.de> Message-ID: <533D6ABC.2060803@weber-gesamtausgabe.de> Hi Perry, I try to include a few comments - for more details we have to look again in Kristina's work/sources/items-files... Best greetings, Joachim Am 03.04.14 15:26, schrieb Johannes Kepper: > Am 03.04.2014 um 15:10 schrieb Roland, Perry D. (pdr4h) : > >> Johannes, >> >> Sorry for arriving late to the party. :-) >> >> The element wasn't provided in source (manifestation) and item in order to encourage the use of work/history or expression/history. The assumption was that what folks often have to say about a manifestation or item is really about the work and expression anyway. > Sometimes you have a copy, and you would like to tell the story behind it -- why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI... Example: We have the Vienna copy of the Freischuetz - with a lot of contemporary and later changes, and we have the "history" of the production of the copy itself as well as a lot of informations about the later changes in Vienna. It's a kind of "history" for this special item (not really for the work!). So (in an ideal world...;-) ) we want to describe this "history" with the use of, e.g., paragraphs, lists, dates, normative data etc. etc. In order to have flexible possibilities the notesStmt/annot element is too restrictive - but maybe you will suggest: please write a separate book .... :-( > A notesStmt/annot element (perhaps with a label of "history" in this case) can be used as a "catch all" to capture any information not easily shoe-horned into the other available elements in work, expression, source, and item. But, since the models of source and item are essentially lists of optional children, it's also not difficult to add in all these places without creating any backwards compatibility problems. Before doing so, however, I'd like to know more about what you'd like to say about source and/or item history that makes this necessary. > > I'm not in favor of moving inside because doing this would mean breaking compatibility. It would also make provenance available inside work, expression, and source (e.g., work/history/provenance) where its presence could lead to abuse. What exactly is the provenance (that is, the custodial history) of a work or expression? I don't there is such a thing. > Well, I see your point, and I agree with that. There is certainly no provenance of a work or expression. The kind of information someone would be looking for is about the transmission of the work, which should go into history. However, I still think that might be a better parent for than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression... "Provenance" has a clear meaning, I think, and naturally has nothing to do with work (or expression) but only with item (or a special source). If denotes today's place for an item this is clearer in my eyes than only mentioning this within . But often has clear connections with because stamps and librarian's or auctioneer's entries are often mentioned in this context. But this is always the history of "handing down" of the item/source not the history of what "happened" to the item/manuscript while laying on Perry's desk for some years...;-) > I don't understand what problem you're having with inside . Are you looking to provide bibliographic citations for whatever arguments you present in ? I need more information, please. > I have no problem with bibl inside source, except that it isn't allowed. I'd like to be able to put in literature about a specific source (like a review of a printed edition etc.), that's it. The current means to get a bibl into source seem to be too complicated... > > Hth, > Johannes > Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > >> -- >> p. >> >> __________________________ >> Perry Roland >> 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: Thursday, April 03, 2014 5:16 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] history of sources / items >> >> I was hoping to get a reply from Perry, especially since I think this dates back to the days before FRBR, when there were work and source elements. expression and item just inherited their standard models with little modifications, so I'm not surprised about their behavior. >> >> However, I also prefer to add a history element to source and item, and moving provenance in there seems like a logical modification then. I wouldn't worry too much about backward compatibility. I think we're past the point where we'd have to make huge changes to the model, and little modifications should require only little modifications in software. Also, providing a XSLT to go back and forth between MEI2013 and MEI201x is not an issue, so that people could use whatever is most appropriate to them. This might result in putting the history somewhere nested into a notesStmt when going back to 2013, but so be it... >> >> I remember discussions about structured vs. prose-based content models for a number of elements, among them bibl and annot. Does this relate to the initial question, and should we revise it as well? >> >> >> Johannes >> Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. >> >> >> >> Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field : >> >>> "Provenance" is a standard item in catalogues of works in manuscript, but >>> it has a range of meanings, all of which might comfortable fit within >>> "history". It sometimes identifies previously owners but equally often it >>> refers to a physical location (city, institution, performing group et >>> al.). >>> >>> 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 >>> Johannes Kepper >>> Sent: Wednesday, April 02, 2014 2:39 AM >>> To: Music Encoding Initiative >>> Subject: [MEI-L] history of sources / items >>> >>> Dear list, >>> >>> while discussing the upcoming Weber Werkverzeichnis (Weber's work >>> catalogue) with Kristina Richts and Joachim Veit, I can't remember why we >>> dropped the element from sources and items? We have it on works >>> and expressions, but not on these two. However, it might be interested to >>> write something about the creation of a source (which is not the same as >>> the provenance, which is available). Can someone please remind me of our >>> argument to drop it? Otherwise, it would be a fault that we might want to >>> correct. >>> >>> Btw., seems to be equally hidden (you can get it from source at >>> source/physDesc/physMedium/bibl.). >>> >>> 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 -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: -------------- 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 pdr4h at eservices.virginia.edu Thu Apr 3 17:59:47 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 3 Apr 2014 15:59:47 +0000 Subject: [MEI-L] history of sources / items In-Reply-To: <6D36A4E3-B604-48BE-81A7-E13B023CEC1C@edirom.de> References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu>, , <6D36A4E3-B604-48BE-81A7-E13B023CEC1C@edirom.de> Message-ID: Johannes and Joachim, > Sometimes you have a copy, and you would like to tell the story behind it ? why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI? I understand your motivation better, but is not the thing you're looking for (ala Obi-wan Kenobi). is intended to hold a *brief* statement of the circumstances of creation. That's why it's content model is very restrictive: It's nothing more than a string with and thrown in to capture important dates and places. You could think of as the "quick and dirty" or "headline" version of the content that follows it. For more "essay-like" content, you can use the other possible children of history; i.e., eventList and p. But contrary to what Joachim said, the most "book-like" and least restrictive model is actually that of : This allows just about everything under the sun! On the issue of , what I hear you saying is that you'd like its content model to be more like that of , something like: where the members of model.textcomponentLike are: lgLike - lg listLike - biblList, eventList, list pLike -p quoteLike - quote tableLike - table or perhaps where the membership of model.divLike is just
and members of model.divLike and model.textcomponentLike are permitted as content of
or making into a more div-Like container that can wrap other components and divs (which is how you can get section headings). These modifications will also address your need to include a list of bibliographic citations within . Going farther, we could even drop from , moving any content in former versions of MEI to subordinate

elements. This would eliminate the privileging of data-like uses of . > I still think that might be a better parent for than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression? was a convenient place to locate since in library land, as Joachim confirms, "provenance> often has clear connections with because stamps and librarian's or auctioneer's entries are often mentioned in this context." But there's no reason why it should remain there if there's a compelling reason to move it. We could move up a level into itself rather than placing it inside and then making available inside . Taking this approach would put where it needs to be (on ) and not everywhere can occur; that is, , , and (should we decide to allow there too). It also maintains separation between the history of "handing down" (quoting Joachim) of the item and the production history of the item, which is the proper content for /. 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 Johannes Kepper [kepper at edirom.de] Sent: Thursday, April 03, 2014 9:26 AM To: Music Encoding Initiative Subject: Re: [MEI-L] history of sources / items Am 03.04.2014 um 15:10 schrieb Roland, Perry D. (pdr4h) : > Johannes, > > Sorry for arriving late to the party. :-) > > The element wasn't provided in source (manifestation) and item in order to encourage the use of work/history or expression/history. The assumption was that what folks often have to say about a manifestation or item is really about the work and expression anyway. Sometimes you have a copy, and you would like to tell the story behind it ? why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI? > > A notesStmt/annot element (perhaps with a label of "history" in this case) can be used as a "catch all" to capture any information not easily shoe-horned into the other available elements in work, expression, source, and item. But, since the models of source and item are essentially lists of optional children, it's also not difficult to add in all these places without creating any backwards compatibility problems. Before doing so, however, I'd like to know more about what you'd like to say about source and/or item history that makes this necessary. > > I'm not in favor of moving inside because doing this would mean breaking compatibility. It would also make provenance available inside work, expression, and source (e.g., work/history/provenance) where its presence could lead to abuse. What exactly is the provenance (that is, the custodial history) of a work or expression? I don't there is such a thing. Well, I see your point, and I agree with that. There is certainly no provenance of a work or expression. The kind of information someone would be looking for is about the transmission of the work, which should go into history. However, I still think that might be a better parent for than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression? > > I don't understand what problem you're having with inside . Are you looking to provide bibliographic citations for whatever arguments you present in ? I need more information, please. I have no problem with bibl inside source, except that it isn't allowed. I'd like to be able to put in literature about a specific source (like a review of a printed edition etc.), that's it. The current means to get a bibl into source seem to be too complicated? Hth, Johannes Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > -- > p. > > __________________________ > Perry Roland > 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: Thursday, April 03, 2014 5:16 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] history of sources / items > > I was hoping to get a reply from Perry, especially since I think this dates back to the days before FRBR, when there were work and source elements. expression and item just inherited their standard models with little modifications, so I'm not surprised about their behavior. > > However, I also prefer to add a history element to source and item, and moving provenance in there seems like a logical modification then. I wouldn't worry too much about backward compatibility. I think we're past the point where we'd have to make huge changes to the model, and little modifications should require only little modifications in software. Also, providing a XSLT to go back and forth between MEI2013 and MEI201x is not an issue, so that people could use whatever is most appropriate to them. This might result in putting the history somewhere nested into a notesStmt when going back to 2013, but so be it? > > I remember discussions about structured vs. prose-based content models for a number of elements, among them bibl and annot. Does this relate to the initial question, and should we revise it as well? > > > Johannes > Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > > > Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field : > >> "Provenance" is a standard item in catalogues of works in manuscript, but >> it has a range of meanings, all of which might comfortable fit within >> "history". It sometimes identifies previously owners but equally often it >> refers to a physical location (city, institution, performing group et >> al.). >> >> 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 >> Johannes Kepper >> Sent: Wednesday, April 02, 2014 2:39 AM >> To: Music Encoding Initiative >> Subject: [MEI-L] history of sources / items >> >> Dear list, >> >> while discussing the upcoming Weber Werkverzeichnis (Weber's work >> catalogue) with Kristina Richts and Joachim Veit, I can't remember why we >> dropped the element from sources and items? We have it on works >> and expressions, but not on these two. However, it might be interested to >> write something about the creation of a source (which is not the same as >> the provenance, which is available). Can someone please remind me of our >> argument to drop it? Otherwise, it would be a fault that we might want to >> correct. >> >> Btw., seems to be equally hidden (you can get it from source at >> source/physDesc/physMedium/bibl.). >> >> 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 veit at weber-gesamtausgabe.de Thu Apr 3 21:32:26 2014 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Thu, 03 Apr 2014 21:32:26 +0200 Subject: [MEI-L] history of sources / items In-Reply-To: References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu>, , <6D36A4E3-B604-48BE-81A7-E13B023CEC1C@edirom.de> Message-ID: <533DB74A.7060100@weber-gesamtausgabe.de> Dear Perry, thank you very much for these details and excuse my misunderstanding of the possibilities of "annotation"!! Indeed your proposal to transfer the possibiliies of to would be excellent in my eyes because - at least in our case - the history will be so detailed that seems to be semantically inadequate (at least if we consent that the content of an essay should not be hidden in the footnotes but in the main text...;-) ). And with

we should have the opportunity to squeeze al things in which are hidden in the 27 corners of our project... Waiting for the discussion with Kristina and Johannes tomorrow, meanwhile with cordial thanks and best greetings, Joachim Am 03.04.14 17:59, schrieb Roland, Perry D. (pdr4h): > Johannes and Joachim, > >> Sometimes you have a copy, and you would like to tell the story behind it ? why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI? > I understand your motivation better, but is not the thing you're looking for (ala Obi-wan Kenobi). is intended to hold a *brief* statement of the circumstances of creation. That's why it's content model is very restrictive: > > > > > > > > > > It's nothing more than a string with and thrown in to capture important dates and places. You could think of as the "quick and dirty" or "headline" version of the content that follows it. > > For more "essay-like" content, you can use the other possible children of history; i.e., eventList and p. > > > > > > > > > > > > > > > But contrary to what Joachim said, the most "book-like" and least restrictive model is actually that of : > > > > > > > > > > > > This allows just about everything under the sun! > > On the issue of , what I hear you saying is that you'd like its content model to be more like that of , something like: > > > > > > > > > > > > > > where the members of model.textcomponentLike are: > > lgLike - lg > listLike - biblList, eventList, list > pLike -p > quoteLike - quote > tableLike - table > > or perhaps > > > > > > > > > > > > where the membership of model.divLike is just
and members of model.divLike and model.textcomponentLike are permitted as content of
> > or > > > > > > > > > > > > > > > making into a more div-Like container that can wrap other components and divs (which is how you can get section headings). > > These modifications will also address your need to include a list of bibliographic citations within . > > Going farther, we could even drop from , moving any content in former versions of MEI to subordinate

elements. This would eliminate the privileging of data-like uses of . > >> I still think that might be a better parent for than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression? > was a convenient place to locate since in library land, as Joachim confirms, "provenance> often has clear connections with because stamps and librarian's or auctioneer's entries are often mentioned in this context." But there's no reason why it should remain there if there's a compelling reason to move it. > > We could move up a level into itself rather than placing it inside and then making available inside . Taking this approach would put where it needs to be (on ) and not everywhere can occur; that is, , , and (should we decide to allow there too). It also maintains separation between the history of "handing down" (quoting Joachim) of the item and the production history of the item, which is the proper content for /. > > 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 Johannes Kepper [kepper at edirom.de] > Sent: Thursday, April 03, 2014 9:26 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] history of sources / items > > Am 03.04.2014 um 15:10 schrieb Roland, Perry D. (pdr4h) : > >> Johannes, >> >> Sorry for arriving late to the party. :-) >> >> The element wasn't provided in source (manifestation) and item in order to encourage the use of work/history or expression/history. The assumption was that what folks often have to say about a manifestation or item is really about the work and expression anyway. > Sometimes you have a copy, and you would like to tell the story behind it ? why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI? > >> A notesStmt/annot element (perhaps with a label of "history" in this case) can be used as a "catch all" to capture any information not easily shoe-horned into the other available elements in work, expression, source, and item. But, since the models of source and item are essentially lists of optional children, it's also not difficult to add in all these places without creating any backwards compatibility problems. Before doing so, however, I'd like to know more about what you'd like to say about source and/or item history that makes this necessary. >> >> I'm not in favor of moving inside because doing this would mean breaking compatibility. It would also make provenance available inside work, expression, and source (e.g., work/history/provenance) where its presence could lead to abuse. What exactly is the provenance (that is, the custodial history) of a work or expression? I don't there is such a thing. > Well, I see your point, and I agree with that. There is certainly no provenance of a work or expression. The kind of information someone would be looking for is about the transmission of the work, which should go into history. However, I still think that might be a better parent for than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression? > >> I don't understand what problem you're having with inside . Are you looking to provide bibliographic citations for whatever arguments you present in ? I need more information, please. > I have no problem with bibl inside source, except that it isn't allowed. I'd like to be able to put in literature about a specific source (like a review of a printed edition etc.), that's it. The current means to get a bibl into source seem to be too complicated? > > Hth, > Johannes > Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > >> -- >> p. >> >> __________________________ >> Perry Roland >> 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: Thursday, April 03, 2014 5:16 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] history of sources / items >> >> I was hoping to get a reply from Perry, especially since I think this dates back to the days before FRBR, when there were work and source elements. expression and item just inherited their standard models with little modifications, so I'm not surprised about their behavior. >> >> However, I also prefer to add a history element to source and item, and moving provenance in there seems like a logical modification then. I wouldn't worry too much about backward compatibility. I think we're past the point where we'd have to make huge changes to the model, and little modifications should require only little modifications in software. Also, providing a XSLT to go back and forth between MEI2013 and MEI201x is not an issue, so that people could use whatever is most appropriate to them. This might result in putting the history somewhere nested into a notesStmt when going back to 2013, but so be it? >> >> I remember discussions about structured vs. prose-based content models for a number of elements, among them bibl and annot. Does this relate to the initial question, and should we revise it as well? >> >> >> Johannes >> Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. >> >> >> >> Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field : >> >>> "Provenance" is a standard item in catalogues of works in manuscript, but >>> it has a range of meanings, all of which might comfortable fit within >>> "history". It sometimes identifies previously owners but equally often it >>> refers to a physical location (city, institution, performing group et >>> al.). >>> >>> 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 >>> Johannes Kepper >>> Sent: Wednesday, April 02, 2014 2:39 AM >>> To: Music Encoding Initiative >>> Subject: [MEI-L] history of sources / items >>> >>> Dear list, >>> >>> while discussing the upcoming Weber Werkverzeichnis (Weber's work >>> catalogue) with Kristina Richts and Joachim Veit, I can't remember why we >>> dropped the element from sources and items? We have it on works >>> and expressions, but not on these two. However, it might be interested to >>> write something about the creation of a source (which is not the same as >>> the provenance, which is available). Can someone please remind me of our >>> argument to drop it? Otherwise, it would be a fault that we might want to >>> correct. >>> >>> Btw., seems to be equally hidden (you can get it from source at >>> source/physDesc/physMedium/bibl.). >>> >>> 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 -------------- 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 bohl at edirom.de Fri Apr 4 11:03:37 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 04 Apr 2014 11:03:37 +0200 Subject: [MEI-L] history of sources / items In-Reply-To: <533DB74A.7060100@weber-gesamtausgabe.de> References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu>, , <6D36A4E3-B604-48BE-81A7-E13B023CEC1C@edirom.de> <533DB74A.7060100@weber-gesamtausgabe.de> Message-ID: <533E7569.7060004@edirom.de> Dear all, not that I have too much experience in cataloguing sources or writing verbose source description, but it might help to have a look at the TEI way of doing things. Some nice example applications concerning manuscripts were presented during the Edirom-Summer-School 2013 by Torsten Scha?an. The Herzog August Bibliothek has their TEI code available on-line, see for example: http://diglib.hab.de/?db=mss&list=ms&id=27-2-aug-2f&catalog=Lesser&mode=xml Just my to code-points ;-) 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 03.04.2014 21:32, schrieb Joachim Veit: > Dear Perry, > thank you very much for these details and excuse > my misunderstanding of the possibilities of "annotation"!! > Indeed your proposal to transfer the possibiliies of to > would be excellent in my eyes because - at least in our case > - the history will be so detailed that seems to be > semantically inadequate (at least if we consent that the content of an > essay should not be hidden in the footnotes but in the main text...;-) ). > And with

we should have the opportunity to squeeze al things in > which are hidden in the 27 corners of our project... > Waiting for the discussion with Kristina and Johannes tomorrow, > meanwhile with cordial thanks and best greetings, > Joachim > > > Am 03.04.14 17:59, schrieb Roland, Perry D. (pdr4h): >> Johannes and Joachim, >> >>> Sometimes you have a copy, and you would like to tell the story >>> behind it -- why it has been copied, under which conditions it >>> happened, etc. Basically, I want to get hold of for >>> source (and maybe item, even though I think this might be less >>> important). Of course, people may confuse the histories of works and >>> sources, but this doesn't explain why there shouldn't be a source >>> history in MEI... >> I understand your motivation better, but is not the thing >> you're looking for (ala Obi-wan Kenobi). is intended to >> hold a *brief* statement of the circumstances of creation. That's >> why it's content model is very restrictive: >> >> >> >> >> >> >> >> >> >> It's nothing more than a string with and thrown in >> to capture important dates and places. You could think of >> as the "quick and dirty" or "headline" version of the content that >> follows it. >> >> For more "essay-like" content, you can use the other possible >> children of history; i.e., eventList and p. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> But contrary to what Joachim said, the most "book-like" and least >> restrictive model is actually that of : >> >> >> >> >> >> >> >> >> >> >> >> This allows just about everything under the sun! >> >> On the issue of , what I hear you saying is that you'd like >> its content model to be more like that of , something like: >> >> >> >> >> >> >> >> >> >> >> >> >> >> where the members of model.textcomponentLike are: >> >> lgLike - lg >> listLike - biblList, eventList, list >> pLike -p >> quoteLike - quote >> tableLike - table >> >> or perhaps >> >> >> >> >> >> >> >> >> >> >> >> where the membership of model.divLike is just
and members of >> model.divLike and model.textcomponentLike are permitted as content of >>
>> >> or >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> making into a more div-Like container that can wrap other >> components and divs (which is how you can get section headings). >> >> These modifications will also address your need to include a list of >> bibliographic citations within . >> >> Going farther, we could even drop from , moving >> any content in former versions of MEI to subordinate

elements. >> This would eliminate the privileging of data-like uses of . >> >>> I still think that might be a better parent for >>> than . We agree that the provenance of an >>> item is not part of the physical description, do we? I'm not saying >>> we must move it to history, but I wonder if we could, possibly with >>> additional means to prevent it from showing up on work and >>> expression... >> was a convenient place to locate since in >> library land, as Joachim confirms, "provenance> often has clear >> connections with because stamps and librarian's or >> auctioneer's entries are often mentioned in this context." But >> there's no reason why it should remain there if there's a compelling >> reason to move it. >> >> We could move up a level into itself rather than >> placing it inside and then making available >> inside . Taking this approach would put where it >> needs to be (on ) and not everywhere can occur; that >> is, , , and (should we decide to allow >> there too). It also maintains separation between the >> history of "handing down" (quoting Joachim) of the item and the >> production history of the item, which is the proper content for >> /. >> >> 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 >> Johannes Kepper [kepper at edirom.de] >> Sent: Thursday, April 03, 2014 9:26 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] history of sources / items >> >> Am 03.04.2014 um 15:10 schrieb Roland, Perry D. (pdr4h) >> : >> >>> Johannes, >>> >>> Sorry for arriving late to the party. :-) >>> >>> The element wasn't provided in source (manifestation) and >>> item in order to encourage the use of work/history or >>> expression/history. The assumption was that what folks often have >>> to say about a manifestation or item is really about the work and >>> expression anyway. >> Sometimes you have a copy, and you would like to tell the story >> behind it -- why it has been copied, under which conditions it >> happened, etc. Basically, I want to get hold of for source >> (and maybe item, even though I think this might be less important). >> Of course, people may confuse the histories of works and sources, but >> this doesn't explain why there shouldn't be a source history in MEI... >> >>> A notesStmt/annot element (perhaps with a label of "history" in this >>> case) can be used as a "catch all" to capture any information not >>> easily shoe-horned into the other available elements in work, >>> expression, source, and item. But, since the models of source and >>> item are essentially lists of optional children, it's also not >>> difficult to add in all these places without creating any >>> backwards compatibility problems. Before doing so, however, I'd >>> like to know more about what you'd like to say about source and/or >>> item history that makes this necessary. >>> >>> I'm not in favor of moving inside because >>> doing this would mean breaking compatibility. It would also make >>> provenance available inside work, expression, and source (e.g., >>> work/history/provenance) where its presence could lead to abuse. >>> What exactly is the provenance (that is, the custodial history) of a >>> work or expression? I don't there is such a thing. >> Well, I see your point, and I agree with that. There is certainly no >> provenance of a work or expression. The kind of information someone >> would be looking for is about the transmission of the work, which >> should go into history. However, I still think that might >> be a better parent for than . We agree that >> the provenance of an item is not part of the physical description, do >> we? I'm not saying we must move it to history, but I wonder if we >> could, possibly with additional means to prevent it from showing up >> on work and expression... >> >>> I don't understand what problem you're having with inside >>> . Are you looking to provide bibliographic citations for >>> whatever arguments you present in ? I need more >>> information, please. >> I have no problem with bibl inside source, except that it isn't >> allowed. I'd like to be able to put in literature about a specific >> source (like a review of a printed edition etc.), that's it. The >> current means to get a bibl into source seem to be too complicated... >> >> Hth, >> Johannes >> Ceterum censeo, don't forget to discuss the MEI organization, either >> here on MEI-L or at http://bit.ly/1hDyq4X. >> >> >>> -- >>> p. >>> >>> __________________________ >>> Perry Roland >>> 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: Thursday, April 03, 2014 5:16 AM >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] history of sources / items >>> >>> I was hoping to get a reply from Perry, especially since I think >>> this dates back to the days before FRBR, when there were work and >>> source elements. expression and item just inherited their standard >>> models with little modifications, so I'm not surprised about their >>> behavior. >>> >>> However, I also prefer to add a history element to source and item, >>> and moving provenance in there seems like a logical modification >>> then. I wouldn't worry too much about backward compatibility. I >>> think we're past the point where we'd have to make huge changes to >>> the model, and little modifications should require only little >>> modifications in software. Also, providing a XSLT to go back and >>> forth between MEI2013 and MEI201x is not an issue, so that people >>> could use whatever is most appropriate to them. This might result in >>> putting the history somewhere nested into a notesStmt when going >>> back to 2013, but so be it... >>> >>> I remember discussions about structured vs. prose-based content >>> models for a number of elements, among them bibl and annot. Does >>> this relate to the initial question, and should we revise it as well? >>> >>> >>> Johannes >>> Ceterum censeo, don't forget to discuss the MEI organization, either >>> here on MEI-L or at http://bit.ly/1hDyq4X. >>> >>> >>> >>> Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field >>> : >>> >>>> "Provenance" is a standard item in catalogues of works in >>>> manuscript, but >>>> it has a range of meanings, all of which might comfortable fit within >>>> "history". It sometimes identifies previously owners but equally >>>> often it >>>> refers to a physical location (city, institution, performing group et >>>> al.). >>>> >>>> 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 >>>> Johannes Kepper >>>> Sent: Wednesday, April 02, 2014 2:39 AM >>>> To: Music Encoding Initiative >>>> Subject: [MEI-L] history of sources / items >>>> >>>> Dear list, >>>> >>>> while discussing the upcoming Weber Werkverzeichnis (Weber's work >>>> catalogue) with Kristina Richts and Joachim Veit, I can't remember >>>> why we >>>> dropped the element from sources and items? We have it on >>>> works >>>> and expressions, but not on these two. However, it might be >>>> interested to >>>> write something about the creation of a source (which is not the >>>> same as >>>> the provenance, which is available). Can someone please remind me >>>> of our >>>> argument to drop it? Otherwise, it would be a fault that we might >>>> want to >>>> correct. >>>> >>>> Btw., seems to be equally hidden (you can get it from source at >>>> source/physDesc/physMedium/bibl.). >>>> >>>> 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 -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From atge at kb.dk Fri Apr 4 11:57:59 2014 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 4 Apr 2014 09:57:59 +0000 Subject: [MEI-L] history of sources / items In-Reply-To: <533E7569.7060004@edirom.de> References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu>, , <6D36A4E3-B604-48BE-81A7-E13B023CEC1C@edirom.de> <533DB74A.7060100@weber-gesamtausgabe.de> <533E7569.7060004@edirom.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D101184BFE9E@EXCHANGE-03.kb.dk> Hi Benjamin, Perry, & all I notice that is a child of the manuscript description's element in TEI. That does make sense to me, as the manuscript's history may roughly be divided into its creation and its transmission. However I see your point, Perry, that in our case, making available within would be nonsense in the context of work and expression (and possibly even in source, but only when using the FRBR module, in which case belongs at item level). Provenance is related to both history and physical location, as it may be regarded as the item's historical record of physical locations or owners. That is why I brought it up in this discussion, and also why I brought it up a couple of years ago in a discussion about . I am not sure I can see any can of worms hidden here, but of course I don't know what has been discussed elsewhere. My reason for starting the discussion back in December 2012 was that I noticed that was moved out of but was not. I never understood why was left in . I am perfectly aware, of course, that only describes an item's current location, not previous ones. I have no particular preferences whether should be a child of , , or be their sibling. The latter option may very well be the best solution, making and siblings as they were originally, but now in the context of or instead of . In the physical description of an item, where it is now, provenance information appears - at least to me - even more out of place than the information on the item's current location. I am sorry if this opens some unwanted discussions, but actually I don't see this as very problematic, just as something we forgot :-) Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl Sendt: 4. april 2014 11:04 Til: mei-l at lists.uni-paderborn.de Emne: Re: [MEI-L] history of sources / items Dear all, not that I have too much experience in cataloguing sources or writing verbose source description, but it might help to have a look at the TEI way of doing things. Some nice example applications concerning manuscripts were presented during the Edirom-Summer-School 2013 by Torsten Scha?an. The Herzog August Bibliothek has their TEI code available on-line, see for example: http://diglib.hab.de/?db=mss&list=ms&id=27-2-aug-2f&catalog=Lesser&mode=xml Just my to code-points ;-) 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 03.04.2014 21:32, schrieb Joachim Veit: Dear Perry, thank you very much for these details and excuse my misunderstanding of the possibilities of "annotation"!! Indeed your proposal to transfer the possibiliies of to would be excellent in my eyes because - at least in our case - the history will be so detailed that seems to be semantically inadequate (at least if we consent that the content of an essay should not be hidden in the footnotes but in the main text...;-) ). And with

we should have the opportunity to squeeze al things in which are hidden in the 27 corners of our project... Waiting for the discussion with Kristina and Johannes tomorrow, meanwhile with cordial thanks and best greetings, Joachim Am 03.04.14 17:59, schrieb Roland, Perry D. (pdr4h): Johannes and Joachim, Sometimes you have a copy, and you would like to tell the story behind it - why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI... I understand your motivation better, but is not the thing you're looking for (ala Obi-wan Kenobi). is intended to hold a *brief* statement of the circumstances of creation. That's why it's content model is very restrictive: It's nothing more than a string with and thrown in to capture important dates and places. You could think of as the "quick and dirty" or "headline" version of the content that follows it. For more "essay-like" content, you can use the other possible children of history; i.e., eventList and p. But contrary to what Joachim said, the most "book-like" and least restrictive model is actually that of : This allows just about everything under the sun! On the issue of , what I hear you saying is that you'd like its content model to be more like that of , something like: where the members of model.textcomponentLike are: lgLike - lg listLike - biblList, eventList, list pLike -p quoteLike - quote tableLike - table or perhaps where the membership of model.divLike is just
and members of model.divLike and model.textcomponentLike are permitted as content of
or making into a more div-Like container that can wrap other components and divs (which is how you can get section headings). These modifications will also address your need to include a list of bibliographic citations within . Going farther, we could even drop from , moving any content in former versions of MEI to subordinate

elements. This would eliminate the privileging of data-like uses of . I still think that might be a better parent for than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression... was a convenient place to locate since in library land, as Joachim confirms, "provenance> often has clear connections with because stamps and librarian's or auctioneer's entries are often mentioned in this context." But there's no reason why it should remain there if there's a compelling reason to move it. We could move up a level into itself rather than placing it inside and then making available inside . Taking this approach would put where it needs to be (on ) and not everywhere can occur; that is, , , and (should we decide to allow there too). It also maintains separation between the history of "handing down" (quoting Joachim) of the item and the production history of the item, which is the proper content for /. 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 Johannes Kepper [kepper at edirom.de] Sent: Thursday, April 03, 2014 9:26 AM To: Music Encoding Initiative Subject: Re: [MEI-L] history of sources / items Am 03.04.2014 um 15:10 schrieb Roland, Perry D. (pdr4h) : Johannes, Sorry for arriving late to the party. :-) The element wasn't provided in source (manifestation) and item in order to encourage the use of work/history or expression/history. The assumption was that what folks often have to say about a manifestation or item is really about the work and expression anyway. Sometimes you have a copy, and you would like to tell the story behind it - why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI... A notesStmt/annot element (perhaps with a label of "history" in this case) can be used as a "catch all" to capture any information not easily shoe-horned into the other available elements in work, expression, source, and item. But, since the models of source and item are essentially lists of optional children, it's also not difficult to add in all these places without creating any backwards compatibility problems. Before doing so, however, I'd like to know more about what you'd like to say about source and/or item history that makes this necessary. I'm not in favor of moving inside because doing this would mean breaking compatibility. It would also make provenance available inside work, expression, and source (e.g., work/history/provenance) where its presence could lead to abuse. What exactly is the provenance (that is, the custodial history) of a work or expression? I don't there is such a thing. Well, I see your point, and I agree with that. There is certainly no provenance of a work or expression. The kind of information someone would be looking for is about the transmission of the work, which should go into history. However, I still think that might be a better parent for than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression... I don't understand what problem you're having with inside . Are you looking to provide bibliographic citations for whatever arguments you present in ? I need more information, please. I have no problem with bibl inside source, except that it isn't allowed. I'd like to be able to put in literature about a specific source (like a review of a printed edition etc.), that's it. The current means to get a bibl into source seem to be too complicated... Hth, Johannes Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. -- p. __________________________ Perry Roland 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: Thursday, April 03, 2014 5:16 AM To: Music Encoding Initiative Subject: Re: [MEI-L] history of sources / items I was hoping to get a reply from Perry, especially since I think this dates back to the days before FRBR, when there were work and source elements. expression and item just inherited their standard models with little modifications, so I'm not surprised about their behavior. However, I also prefer to add a history element to source and item, and moving provenance in there seems like a logical modification then. I wouldn't worry too much about backward compatibility. I think we're past the point where we'd have to make huge changes to the model, and little modifications should require only little modifications in software. Also, providing a XSLT to go back and forth between MEI2013 and MEI201x is not an issue, so that people could use whatever is most appropriate to them. This might result in putting the history somewhere nested into a notesStmt when going back to 2013, but so be it... I remember discussions about structured vs. prose-based content models for a number of elements, among them bibl and annot. Does this relate to the initial question, and should we revise it as well? Johannes Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field : "Provenance" is a standard item in catalogues of works in manuscript, but it has a range of meanings, all of which might comfortable fit within "history". It sometimes identifies previously owners but equally often it refers to a physical location (city, institution, performing group et al.). 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 Johannes Kepper Sent: Wednesday, April 02, 2014 2:39 AM To: Music Encoding Initiative Subject: [MEI-L] history of sources / items Dear list, while discussing the upcoming Weber Werkverzeichnis (Weber's work catalogue) with Kristina Richts and Joachim Veit, I can't remember why we dropped the element from sources and items? We have it on works and expressions, but not on these two. However, it might be interested to write something about the creation of a source (which is not the same as the provenance, which is available). Can someone please remind me of our argument to drop it? Otherwise, it would be a fault that we might want to correct. Btw., seems to be equally hidden (you can get it from source at source/physDesc/physMedium/bibl.). 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 Fri Apr 4 13:22:04 2014 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 4 Apr 2014 13:22:04 +0200 Subject: [MEI-L] history of sources / items In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D101184BFE9E@EXCHANGE-03.kb.dk> References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu>, , <6D36A4E3-B604-48BE-81A7-E13B023CEC1C@edirom.de> <533DB74A.7060100@weber-gesamtausgabe.de> <533E7569.7060004@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D101184BFE9E@EXCHANGE-03.kb.dk> Message-ID: <9C3E35EF-8558-45B2-9732-4F8176B79C78@edirom.de> Hi Axel, thanks for this statement. It ensures me of my own doubts about the current solution. I agree that for items (and / or sources, depending on the use of FRBR), should be the sum of transmission and creation / modifications to the item. The library stamps are just a physical manifestation of that, and we clearly want to link them to the corresponding information within the element, but this doesn't turn the provenance of an item into a physical description. In TEI, is also a child of (which in turn is a child of the manuscript description ). In sum, I guess I would prefer something like item physDesc physLoc history provenance creation {other history content} I left out the other elements available in all these places to keep this example simple. I fully understand Perry's warning about making provenance part of history, but we used Schematron in other places to prevent unwanted side effects like this, so I don't think this has to be a showstopper. Regarding the data model suggestions by Perry, I think we may have to step back a bit and take a broader approach. The models of and various other elements are somewhat "undecided" from my perspective. Especially for , I know various projects that use it for structured data by typing its child elements. The model itself suggests prose content, though. I think we have a similar problem with . What I would suggest is that we seek volunteers to identify all such cases. We should then (or maybe in advance) take a decision for a general approach to these questions. I'm in favor of having / and / side by side, but that's only my personal take on this, and I'm open for arguments. In any case, I think we need a consistent behavior that should be explained somewhere in the Guidelines? Best, Johannes Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. Am 04.04.2014 um 11:57 schrieb Axel Teich Geertinger : > Hi Benjamin, Perry, & all > > I notice that is a child of the manuscript description?s element in TEI. That does make sense to me, as the manuscript?s history may roughly be divided into its creation and its transmission. However I see your point, Perry, that in our case, making available within would be nonsense in the context of work and expression (and possibly even in source, but only when using the FRBR module, in which case belongs at item level). > Provenance is related to both history and physical location, as it may be regarded as the item?s historical record of physical locations or owners. That is why I brought it up in this discussion, and also why I brought it up a couple of years ago in a discussion about . I am not sure I can see any can of worms hidden here, but of course I don?t know what has been discussed elsewhere. My reason for starting the discussion back in December 2012 was that I noticed that was moved out of but was not. I never understood why was left in . > I am perfectly aware, of course, that only describes an item?s current location, not previous ones. I have no particular preferences whether should be a child of , , or be their sibling. The latter option may very well be the best solution, making and siblings as they were originally, but now in the context of or instead of . In the physical description of an item, where it is now, provenance information appears ? at least to me ? even more out of place than the information on the item?s current location. > I am sorry if this opens some unwanted discussions, but actually I don?t see this as very problematic, just as something we forgot :-) > > Best, > Axel > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Benjamin Wolff Bohl > Sendt: 4. april 2014 11:04 > Til: mei-l at lists.uni-paderborn.de > Emne: Re: [MEI-L] history of sources / items > > Dear all, > > not that I have too much experience in cataloguing sources or writing verbose source description, but it might help to have a look at the TEI way of doing things. Some nice example applications concerning manuscripts were presented during the Edirom-Summer-School 2013 by Torsten Scha?an. > > The Herzog August Bibliothek has their TEI code available on-line, see for example: > http://diglib.hab.de/?db=mss&list=ms&id=27-2-aug-2f&catalog=Lesser&mode=xml > > Just my to code-points ;-) > 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 03.04.2014 21:32, schrieb Joachim Veit: > Dear Perry, > thank you very much for these details and excuse my misunderstanding of the possibilities of "annotation"!! > Indeed your proposal to transfer the possibiliies of to would be excellent in my eyes because - at least in our case - the history will be so detailed that seems to be semantically inadequate (at least if we consent that the content of an essay should not be hidden in the footnotes but in the main text...;-) ). > And with

we should have the opportunity to squeeze al things in which are hidden in the 27 corners of our project... > Waiting for the discussion with Kristina and Johannes tomorrow, > meanwhile with cordial thanks and best greetings, > Joachim > > > Am 03.04.14 17:59, schrieb Roland, Perry D. (pdr4h): > > Johannes and Joachim, > > > Sometimes you have a copy, and you would like to tell the story behind it ? why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI? > I understand your motivation better, but is not the thing you're looking for (ala Obi-wan Kenobi). is intended to hold a *brief* statement of the circumstances of creation. That's why it's content model is very restrictive: > > > > > > > > > > It's nothing more than a string with and thrown in to capture important dates and places. You could think of as the "quick and dirty" or "headline" version of the content that follows it. > > For more "essay-like" content, you can use the other possible children of history; i.e., eventList and p. > > > > > > > > > > > > > > > But contrary to what Joachim said, the most "book-like" and least restrictive model is actually that of : > > > > > > > > > > > > This allows just about everything under the sun! > > On the issue of , what I hear you saying is that you'd like its content model to be more like that of , something like: > > > > > > > > > > > > > > where the members of model.textcomponentLike are: > > lgLike - lg > listLike - biblList, eventList, list > pLike -p > quoteLike - quote > tableLike - table > > or perhaps > > > > > > > > > > > > where the membership of model.divLike is just
and members of model.divLike and model.textcomponentLike are permitted as content of
> > or > > > > > > > > > > > > > > > making into a more div-Like container that can wrap other components and divs (which is how you can get section headings). > > These modifications will also address your need to include a list of bibliographic citations within . > > Going farther, we could even drop from , moving any content in former versions of MEI to subordinate

elements. This would eliminate the privileging of data-like uses of . > > > I still think that might be a better parent for than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression? > was a convenient place to locate since in library land, as Joachim confirms, "provenance> often has clear connections with because stamps and librarian's or auctioneer's entries are often mentioned in this context." But there's no reason why it should remain there if there's a compelling reason to move it. > > We could move up a level into itself rather than placing it inside and then making available inside . Taking this approach would put where it needs to be (on ) and not everywhere can occur; that is, , , and (should we decide to allow there too). It also maintains separation between the history of "handing down" (quoting Joachim) of the item and the production history of the item, which is the proper content for /. > > 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 Johannes Kepper [kepper at edirom.de] > Sent: Thursday, April 03, 2014 9:26 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] history of sources / items > > Am 03.04.2014 um 15:10 schrieb Roland, Perry D. (pdr4h) : > > > Johannes, > > Sorry for arriving late to the party. :-) > > The element wasn't provided in source (manifestation) and item in order to encourage the use of work/history or expression/history. The assumption was that what folks often have to say about a manifestation or item is really about the work and expression anyway. > Sometimes you have a copy, and you would like to tell the story behind it ? why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI? > > > A notesStmt/annot element (perhaps with a label of "history" in this case) can be used as a "catch all" to capture any information not easily shoe-horned into the other available elements in work, expression, source, and item. But, since the models of source and item are essentially lists of optional children, it's also not difficult to add in all these places without creating any backwards compatibility problems. Before doing so, however, I'd like to know more about what you'd like to say about source and/or item history that makes this necessary. > > I'm not in favor of moving inside because doing this would mean breaking compatibility. It would also make provenance available inside work, expression, and source (e.g., work/history/provenance) where its presence could lead to abuse. What exactly is the provenance (that is, the custodial history) of a work or expression? I don't there is such a thing. > Well, I see your point, and I agree with that. There is certainly no provenance of a work or expression. The kind of information someone would be looking for is about the transmission of the work, which should go into history. However, I still think that might be a better parent for than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression? > > > I don't understand what problem you're having with inside . Are you looking to provide bibliographic citations for whatever arguments you present in ? I need more information, please. > I have no problem with bibl inside source, except that it isn't allowed. I'd like to be able to put in literature about a specific source (like a review of a printed edition etc.), that's it. The current means to get a bibl into source seem to be too complicated? > > Hth, > Johannes > Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > > > -- > p. > > __________________________ > Perry Roland > 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: Thursday, April 03, 2014 5:16 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] history of sources / items > > I was hoping to get a reply from Perry, especially since I think this dates back to the days before FRBR, when there were work and source elements. expression and item just inherited their standard models with little modifications, so I'm not surprised about their behavior. > > However, I also prefer to add a history element to source and item, and moving provenance in there seems like a logical modification then. I wouldn't worry too much about backward compatibility. I think we're past the point where we'd have to make huge changes to the model, and little modifications should require only little modifications in software. Also, providing a XSLT to go back and forth between MEI2013 and MEI201x is not an issue, so that people could use whatever is most appropriate to them. This might result in putting the history somewhere nested into a notesStmt when going back to 2013, but so be it? > > I remember discussions about structured vs. prose-based content models for a number of elements, among them bibl and annot. Does this relate to the initial question, and should we revise it as well? > > > Johannes > Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > > > Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field : > > > "Provenance" is a standard item in catalogues of works in manuscript, but > it has a range of meanings, all of which might comfortable fit within > "history". It sometimes identifies previously owners but equally often it > refers to a physical location (city, institution, performing group et > al.). > > 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 > Johannes Kepper > Sent: Wednesday, April 02, 2014 2:39 AM > To: Music Encoding Initiative > Subject: [MEI-L] history of sources / items > > Dear list, > > while discussing the upcoming Weber Werkverzeichnis (Weber's work > catalogue) with Kristina Richts and Joachim Veit, I can't remember why we > dropped the element from sources and items? We have it on works > and expressions, but not on these two. However, it might be interested to > write something about the creation of a source (which is not the same as > the provenance, which is available). Can someone please remind me of our > argument to drop it? Otherwise, it would be a fault that we might want to > correct. > > Btw., seems to be equally hidden (you can get it from source at > source/physDesc/physMedium/bibl.). > > 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 -------------- 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 atge at kb.dk Fri Apr 4 13:48:27 2014 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 4 Apr 2014 11:48:27 +0000 Subject: [MEI-L] history of sources / items In-Reply-To: <9C3E35EF-8558-45B2-9732-4F8176B79C78@edirom.de> References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu>, , <6D36A4E3-B604-48BE-81A7-E13B023CEC1C@edirom.de> <533DB74A.7060100@weber-gesamtausgabe.de> <533E7569.7060004@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D101184BFE9E@EXCHANGE-03.kb.dk> <9C3E35EF-8558-45B2-9732-4F8176B79C78@edirom.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D101184BFFB2@EXCHANGE-03.kb.dk> Hi Johannes If relying on schematron to avoid confusion or abuse is acceptable, +1 for the structure you are suggesting. Also +1 for making div-like as Perry suggests. /axel -----Oprindelig meddelelse----- Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Johannes Kepper Sendt: 4. april 2014 13:22 Til: Music Encoding Initiative Emne: Re: [MEI-L] history of sources / items Hi Axel, thanks for this statement. It ensures me of my own doubts about the current solution. I agree that for items (and / or sources, depending on the use of FRBR), should be the sum of transmission and creation / modifications to the item. The library stamps are just a physical manifestation of that, and we clearly want to link them to the corresponding information within the element, but this doesn't turn the provenance of an item into a physical description. In TEI, is also a child of (which in turn is a child of the manuscript description ). In sum, I guess I would prefer something like item physDesc physLoc history provenance creation {other history content} I left out the other elements available in all these places to keep this example simple. I fully understand Perry's warning about making provenance part of history, but we used Schematron in other places to prevent unwanted side effects like this, so I don't think this has to be a showstopper. Regarding the data model suggestions by Perry, I think we may have to step back a bit and take a broader approach. The models of and various other elements are somewhat "undecided" from my perspective. Especially for , I know various projects that use it for structured data by typing its child elements. The model itself suggests prose content, though. I think we have a similar problem with . What I would suggest is that we seek volunteers to identify all such cases. We should then (or maybe in advance) take a decision for a general approach to these questions. I'm in favor of having / and / side by side, but that's only my personal take on this, and I'm open for arguments. In any case, I think we need a consistent behavior that should be explained somewhere in the Guidelines. Best, Johannes Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. Am 04.04.2014 um 11:57 schrieb Axel Teich Geertinger : > Hi Benjamin, Perry, & all > > I notice that is a child of the manuscript description's element in TEI. That does make sense to me, as the manuscript's history may roughly be divided into its creation and its transmission. However I see your point, Perry, that in our case, making available within would be nonsense in the context of work and expression (and possibly even in source, but only when using the FRBR module, in which case belongs at item level). > Provenance is related to both history and physical location, as it may be regarded as the item's historical record of physical locations or owners. That is why I brought it up in this discussion, and also why I brought it up a couple of years ago in a discussion about . I am not sure I can see any can of worms hidden here, but of course I don't know what has been discussed elsewhere. My reason for starting the discussion back in December 2012 was that I noticed that was moved out of but was not. I never understood why was left in . > I am perfectly aware, of course, that only describes an item's current location, not previous ones. I have no particular preferences whether should be a child of , , or be their sibling. The latter option may very well be the best solution, making and siblings as they were originally, but now in the context of or instead of . In the physical description of an item, where it is now, provenance information appears - at least to me - even more out of place than the information on the item's current location. > I am sorry if this opens some unwanted discussions, but actually I > don't see this as very problematic, just as something we forgot :-) > > Best, > Axel > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > Benjamin Wolff Bohl > Sendt: 4. april 2014 11:04 > Til: mei-l at lists.uni-paderborn.de > Emne: Re: [MEI-L] history of sources / items > > Dear all, > > not that I have too much experience in cataloguing sources or writing verbose source description, but it might help to have a look at the TEI way of doing things. Some nice example applications concerning manuscripts were presented during the Edirom-Summer-School 2013 by Torsten Scha?an. > > The Herzog August Bibliothek has their TEI code available on-line, see for example: > http://diglib.hab.de/?db=mss&list=ms&id=27-2-aug-2f&catalog=Lesser&mod > e=xml > > Just my to code-points ;-) > 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 03.04.2014 21:32, schrieb Joachim Veit: > Dear Perry, > thank you very much for these details and excuse my misunderstanding of the possibilities of "annotation"!! > Indeed your proposal to transfer the possibiliies of to would be excellent in my eyes because - at least in our case - the history will be so detailed that seems to be semantically inadequate (at least if we consent that the content of an essay should not be hidden in the footnotes but in the main text...;-) ). > And with

we should have the opportunity to squeeze al things in which are hidden in the 27 corners of our project... > Waiting for the discussion with Kristina and Johannes tomorrow, > meanwhile with cordial thanks and best greetings, Joachim > > > Am 03.04.14 17:59, schrieb Roland, Perry D. (pdr4h): > > Johannes and Joachim, > > > Sometimes you have a copy, and you would like to tell the story behind > it - why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI. I understand your motivation better, but is not the thing you're looking for (ala Obi-wan Kenobi). is intended to hold a *brief* statement of the circumstances of creation. That's why it's content model is very restrictive: > > > > > > > > > > It's nothing more than a string with and thrown in to capture important dates and places. You could think of as the "quick and dirty" or "headline" version of the content that follows it. > > For more "essay-like" content, you can use the other possible children of history; i.e., eventList and p. > > > > > > > > > > > > > > > But contrary to what Joachim said, the most "book-like" and least restrictive model is actually that of : > > > > > > > > > > > > This allows just about everything under the sun! > > On the issue of , what I hear you saying is that you'd like its content model to be more like that of , something like: > > > > > > > > > > > > > > where the members of model.textcomponentLike are: > > lgLike - lg > listLike - biblList, eventList, list > pLike -p > quoteLike - quote > tableLike - table > > or perhaps > > > > > > > > > > > > where the membership of model.divLike is just
and members of > model.divLike and model.textcomponentLike are permitted as content of >
> > or > > > > > > > > > > > > > > > making into a more div-Like container that can wrap other components and divs (which is how you can get section headings). > > These modifications will also address your need to include a list of bibliographic citations within . > > Going farther, we could even drop from , moving any content in former versions of MEI to subordinate

elements. This would eliminate the privileging of data-like uses of . > > > I still think that might be a better parent for > than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression. was a convenient place to locate since in library land, as Joachim confirms, "provenance> often has clear connections with because stamps and librarian's or auctioneer's entries are often mentioned in this context." But there's no reason why it should remain there if there's a compelling reason to move it. > > We could move up a level into itself rather than placing it inside and then making available inside . Taking this approach would put where it needs to be (on ) and not everywhere can occur; that is, , , and (should we decide to allow there too). It also maintains separation between the history of "handing down" (quoting Joachim) of the item and the production history of the item, which is the proper content for /. > > 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 > Johannes Kepper [kepper at edirom.de] > Sent: Thursday, April 03, 2014 9:26 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] history of sources / items > > Am 03.04.2014 um 15:10 schrieb Roland, Perry D. (pdr4h) : > > > Johannes, > > Sorry for arriving late to the party. :-) > > The element wasn't provided in source (manifestation) and item in order to encourage the use of work/history or expression/history. The assumption was that what folks often have to say about a manifestation or item is really about the work and expression anyway. > Sometimes you have a copy, and you would like to tell the story behind > it - why it has been copied, under which conditions it happened, etc. > Basically, I want to get hold of for source (and maybe > item, even though I think this might be less important). Of course, > people may confuse the histories of works and sources, but this > doesn't explain why there shouldn't be a source history in MEI. > > > A notesStmt/annot element (perhaps with a label of "history" in this case) can be used as a "catch all" to capture any information not easily shoe-horned into the other available elements in work, expression, source, and item. But, since the models of source and item are essentially lists of optional children, it's also not difficult to add in all these places without creating any backwards compatibility problems. Before doing so, however, I'd like to know more about what you'd like to say about source and/or item history that makes this necessary. > > I'm not in favor of moving inside because doing this would mean breaking compatibility. It would also make provenance available inside work, expression, and source (e.g., work/history/provenance) where its presence could lead to abuse. What exactly is the provenance (that is, the custodial history) of a work or expression? I don't there is such a thing. > Well, I see your point, and I agree with that. There is certainly no > provenance of a work or expression. The kind of information someone > would be looking for is about the transmission of the work, which > should go into history. However, I still think that might be > a better parent for than . We agree that the > provenance of an item is not part of the physical description, do we? > I'm not saying we must move it to history, but I wonder if we could, > possibly with additional means to prevent it from showing up on work > and expression. > > > I don't understand what problem you're having with inside . Are you looking to provide bibliographic citations for whatever arguments you present in ? I need more information, please. > I have no problem with bibl inside source, except that it isn't > allowed. I'd like to be able to put in literature about a specific > source (like a review of a printed edition etc.), that's it. The > current means to get a bibl into source seem to be too complicated. > > Hth, > Johannes > Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > > > -- > p. > > __________________________ > Perry Roland > 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: Thursday, April 03, 2014 5:16 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] history of sources / items > > I was hoping to get a reply from Perry, especially since I think this dates back to the days before FRBR, when there were work and source elements. expression and item just inherited their standard models with little modifications, so I'm not surprised about their behavior. > > However, I also prefer to add a history element to source and item, > and moving provenance in there seems like a logical modification then. > I wouldn't worry too much about backward compatibility. I think we're > past the point where we'd have to make huge changes to the model, and > little modifications should require only little modifications in > software. Also, providing a XSLT to go back and forth between MEI2013 > and MEI201x is not an issue, so that people could use whatever is most > appropriate to them. This might result in putting the history > somewhere nested into a notesStmt when going back to 2013, but so be > it. > > I remember discussions about structured vs. prose-based content models for a number of elements, among them bibl and annot. Does this relate to the initial question, and should we revise it as well? > > > Johannes > Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > > > Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field : > > > "Provenance" is a standard item in catalogues of works in manuscript, > but it has a range of meanings, all of which might comfortable fit > within "history". It sometimes identifies previously owners but > equally often it refers to a physical location (city, institution, > performing group et al.). > > 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 > Johannes Kepper > Sent: Wednesday, April 02, 2014 2:39 AM > To: Music Encoding Initiative > Subject: [MEI-L] history of sources / items > > Dear list, > > while discussing the upcoming Weber Werkverzeichnis (Weber's work > catalogue) with Kristina Richts and Joachim Veit, I can't remember why > we dropped the element from sources and items? We have it on > works and expressions, but not on these two. However, it might be > interested to write something about the creation of a source (which is > not the same as the provenance, which is available). Can someone > please remind me of our argument to drop it? Otherwise, it would be a > fault that we might want to correct. > > Btw., seems to be equally hidden (you can get it from source at > source/physDesc/physMedium/bibl.). > > 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 lukas.christensen at uibk.ac.at Fri Apr 4 14:23:02 2014 From: lukas.christensen at uibk.ac.at (Lukas Christensen) Date: Fri, 04 Apr 2014 14:23:02 +0200 Subject: [MEI-L] LinkedIn Group Message-ID: <533EA426.2050000@uibk.ac.at> Dear members of the MEI-L group, I took the liberty to open up a group in LinkedIn called "Music Encoding Initiative (MEI)" for better networking among scholars inside this social platform (so far there are no other MEI or TEI groups). Since I'm "just" a regular member of the MEI-L mailing list, there are a few questions/comments I have: Would it be possible to use the logo from the official website for the group? If so, is there one with a higher resolution? For now, the group and all of its contents will only be visible to members. There is the possibility to open up the group so everyone on the web (or just everyone within LinkedIn) has access to it. This is something that needs to be discussed. Please let me know what you think about this whole idea. Hopefully I'm not stepping on anyone?s toes... Best regards, Lukas Christensen -- Lukas Christensen PhD Candidate, Assistant Editor of Acta Musicologica Department of Music University of Innsbruck Karl-Sch?nherr-Str. 3 A-6020 Innsbruck Austria Web: http://acta-musicologica.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 947 bytes Desc: OpenPGP digital signature URL: From andrew.hankinson at mail.mcgill.ca Fri Apr 4 14:34:41 2014 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 4 Apr 2014 12:34:41 +0000 Subject: [MEI-L] LinkedIn Group In-Reply-To: <25910_1396614093_533EA3CD_25910_36_1_533EA426.2050000@uibk.ac.at> References: <25910_1396614093_533EA3CD_25910_36_1_533EA426.2050000@uibk.ac.at> Message-ID: I?m all for this, Lukas. I think this is great for visibility and outreach. Thanks for taking the initiative. As moderator of the group, you should make sure to point people to this mailing list since this is where most community participation occurs. If you notice a question or statement in your group that isn?t being answered, you should make sure that they know that it?s probably better asked here. I don?t think it?s a bad thing that there are multiple places for discussion, but I would hope that it will encourage others to participate in the ?official? channels. There?s a PNG of the logo in the SVN repository. https://code.google.com/p/music-encoding/source/browse/trunk/source/guidelines/Images/meilogo.png -Andrew On Apr 4, 2014, at 8:23 AM, Lukas Christensen wrote: > Dear members of the MEI-L group, > > I took the liberty to open up a group in LinkedIn called "Music Encoding > Initiative (MEI)" for better networking among scholars inside this > social platform (so far there are no other MEI or TEI groups). > > Since I'm "just" a regular member of the MEI-L mailing list, there are a > few questions/comments I have: > > Would it be possible to use the logo from the official website for the > group? If so, is there one with a higher resolution? > > For now, the group and all of its contents will only be visible to > members. There is the possibility to open up the group so everyone on > the web (or just everyone within LinkedIn) has access to it. This is > something that needs to be discussed. > > Please let me know what you think about this whole idea. Hopefully I'm > not stepping on anyone?s toes... > > Best regards, > Lukas Christensen > > -- > Lukas Christensen > PhD Candidate, Assistant Editor of Acta Musicologica > > Department of Music > University of Innsbruck > Karl-Sch?nherr-Str. 3 > A-6020 Innsbruck > Austria > > Web: http://acta-musicologica.net > > _______________________________________________ > 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 Apr 4 15:49:16 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 4 Apr 2014 13:49:16 +0000 Subject: [MEI-L] LinkedIn Group In-Reply-To: References: <25910_1396614093_533EA3CD_25910_36_1_533EA426.2050000@uibk.ac.at>, Message-ID: +1 to everything Andrew said. :-) -- p. __________________________ Perry Roland 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: Friday, April 04, 2014 8:34 AM To: Music Encoding Initiative Subject: Re: [MEI-L] LinkedIn Group I?m all for this, Lukas. I think this is great for visibility and outreach. Thanks for taking the initiative. As moderator of the group, you should make sure to point people to this mailing list since this is where most community participation occurs. If you notice a question or statement in your group that isn?t being answered, you should make sure that they know that it?s probably better asked here. I don?t think it?s a bad thing that there are multiple places for discussion, but I would hope that it will encourage others to participate in the ?official? channels. There?s a PNG of the logo in the SVN repository. https://code.google.com/p/music-encoding/source/browse/trunk/source/guidelines/Images/meilogo.png -Andrew On Apr 4, 2014, at 8:23 AM, Lukas Christensen wrote: > Dear members of the MEI-L group, > > I took the liberty to open up a group in LinkedIn called "Music Encoding > Initiative (MEI)" for better networking among scholars inside this > social platform (so far there are no other MEI or TEI groups). > > Since I'm "just" a regular member of the MEI-L mailing list, there are a > few questions/comments I have: > > Would it be possible to use the logo from the official website for the > group? If so, is there one with a higher resolution? > > For now, the group and all of its contents will only be visible to > members. There is the possibility to open up the group so everyone on > the web (or just everyone within LinkedIn) has access to it. This is > something that needs to be discussed. > > Please let me know what you think about this whole idea. Hopefully I'm > not stepping on anyone?s toes... > > Best regards, > Lukas Christensen > > -- > Lukas Christensen > PhD Candidate, Assistant Editor of Acta Musicologica > > Department of Music > University of Innsbruck > Karl-Sch?nherr-Str. 3 > A-6020 Innsbruck > Austria > > Web: http://acta-musicologica.net > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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 lukas.christensen at uibk.ac.at Fri Apr 4 16:03:10 2014 From: lukas.christensen at uibk.ac.at (Lukas Christensen) Date: Fri, 04 Apr 2014 16:03:10 +0200 Subject: [MEI-L] LinkedIn Group In-Reply-To: References: <25910_1396614093_533EA3CD_25910_36_1_533EA426.2050000@uibk.ac.at> Message-ID: <533EBB9E.6090802@uibk.ac.at> Thank you for your comments, Andrew and Perry! I will add a sticky with a link to the mailing list (and maybe also some other links) soon. -Lukas Am 04.04.14 14:34, schrieb Andrew Hankinson: > I?m all for this, Lukas. I think this is great for visibility and outreach. Thanks for taking the initiative. > > As moderator of the group, you should make sure to point people to this mailing list since this is where most community participation occurs. If you notice a question or statement in your group that isn?t being answered, you should make sure that they know that it?s probably better asked here. > > I don?t think it?s a bad thing that there are multiple places for discussion, but I would hope that it will encourage others to participate in the ?official? channels. > > There?s a PNG of the logo in the SVN repository. > > https://code.google.com/p/music-encoding/source/browse/trunk/source/guidelines/Images/meilogo.png > > -Andrew > > On Apr 4, 2014, at 8:23 AM, Lukas Christensen wrote: > >> Dear members of the MEI-L group, >> >> I took the liberty to open up a group in LinkedIn called "Music Encoding >> Initiative (MEI)" for better networking among scholars inside this >> social platform (so far there are no other MEI or TEI groups). >> >> Since I'm "just" a regular member of the MEI-L mailing list, there are a >> few questions/comments I have: >> >> Would it be possible to use the logo from the official website for the >> group? If so, is there one with a higher resolution? >> >> For now, the group and all of its contents will only be visible to >> members. There is the possibility to open up the group so everyone on >> the web (or just everyone within LinkedIn) has access to it. This is >> something that needs to be discussed. >> >> Please let me know what you think about this whole idea. Hopefully I'm >> not stepping on anyone?s toes... >> >> Best regards, >> Lukas Christensen >> >> -- >> Lukas Christensen >> PhD Candidate, Assistant Editor of Acta Musicologica >> >> Department of Music >> University of Innsbruck >> Karl-Sch?nherr-Str. 3 >> A-6020 Innsbruck >> Austria >> >> Web: http://acta-musicologica.net >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 947 bytes Desc: OpenPGP digital signature URL: From pdr4h at eservices.virginia.edu Fri Apr 4 16:35:09 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 4 Apr 2014 14:35:09 +0000 Subject: [MEI-L] history of sources / items In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D101184BFFB2@EXCHANGE-03.kb.dk> References: <95F54444-76A1-4A15-A03D-1FB2B718DE66@edirom.de> <4ab03c6b.00001174.0000001c@CCARH-ADM-2.su.win.stanford.edu>, , <6D36A4E3-B604-48BE-81A7-E13B023CEC1C@edirom.de> <533DB74A.7060100@weber-gesamtausgabe.de> <533E7569.7060004@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D101184BFE9E@EXCHANGE-03.kb.dk> <9C3E35EF-8558-45B2-9732-4F8176B79C78@edirom.de>, <0B6F63F59F405E4C902DFE2C2329D0D101184BFFB2@EXCHANGE-03.kb.dk> Message-ID: We crossed the Rubicon into the Land of Schematron a long time ago, but I think non-schematron alternatives should be examined first. If a situation can be handled without resorting to a second-level of parsing, it's better in my opinion. But, I also recognize the usefulness of contextual rules. So, if history/provenance is the consensus, it's fine with me. Regarding the model of (and by extension, and even ), I must say that I don't see it as a "problem". If some uses of require unstructured (prose) and others more structured content, that's ok -- the latter can be conceived of as a subset of the first and can be easily accommodated, by formal or informal means; that is, by creation of a customization that enforces the use of a subset of the content of or just agreeing not to use the elements that aren't useful. I'm not sure the creation of is a good idea or even possible. What should a structured annotation look like? Wouldn't each project/use case have a different take on that? Where does this stop -- will we have and ? is the equivalent to the TEI element and there's no structured TEI that I'm aware of. If there are specialized uses for , then they should be examined on a case-by-case basis and specialized elements created (with unstructured or structured content as necessary). I'm not sure if it's stated explicitly in the Guidelines, but this approach is inherent in the structure of MEI itself (that's what all those elements are for!) and the use of ODD. I have similar thoughts about and . It's my experience that the usefulness of is inversely proportion to the amount of structure imposed by it. Even so, I can see the utility of a data-centric element, but it's not something I want to take on right now. Any volunteers? -- p. __________________________ Perry Roland 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 Axel Teich Geertinger [atge at kb.dk] Sent: Friday, April 04, 2014 7:48 AM To: Music Encoding Initiative Subject: Re: [MEI-L] history of sources / items Hi Johannes If relying on schematron to avoid confusion or abuse is acceptable, +1 for the structure you are suggesting. Also +1 for making div-like as Perry suggests. /axel -----Oprindelig meddelelse----- Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Johannes Kepper Sendt: 4. april 2014 13:22 Til: Music Encoding Initiative Emne: Re: [MEI-L] history of sources / items Hi Axel, thanks for this statement. It ensures me of my own doubts about the current solution. I agree that for items (and / or sources, depending on the use of FRBR), should be the sum of transmission and creation / modifications to the item. The library stamps are just a physical manifestation of that, and we clearly want to link them to the corresponding information within the element, but this doesn't turn the provenance of an item into a physical description. In TEI, is also a child of (which in turn is a child of the manuscript description ). In sum, I guess I would prefer something like item physDesc physLoc history provenance creation {other history content} I left out the other elements available in all these places to keep this example simple. I fully understand Perry's warning about making provenance part of history, but we used Schematron in other places to prevent unwanted side effects like this, so I don't think this has to be a showstopper. Regarding the data model suggestions by Perry, I think we may have to step back a bit and take a broader approach. The models of and various other elements are somewhat "undecided" from my perspective. Especially for , I know various projects that use it for structured data by typing its child elements. The model itself suggests prose content, though. I think we have a similar problem with . What I would suggest is that we seek volunteers to identify all such cases. We should then (or maybe in advance) take a decision for a general approach to these questions. I'm in favor of having / and / side by side, but that's only my personal take on this, and I'm open for arguments. In any case, I think we need a consistent behavior that should be explained somewhere in the Guidelines. Best, Johannes Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. Am 04.04.2014 um 11:57 schrieb Axel Teich Geertinger : > Hi Benjamin, Perry, & all > > I notice that is a child of the manuscript description's element in TEI. That does make sense to me, as the manuscript's history may roughly be divided into its creation and its transmission. However I see your point, Perry, that in our case, making available within would be nonsense in the context of work and expression (and possibly even in source, but only when using the FRBR module, in which case belongs at item level). > Provenance is related to both history and physical location, as it may be regarded as the item's historical record of physical locations or owners. That is why I brought it up in this discussion, and also why I brought it up a couple of years ago in a discussion about . I am not sure I can see any can of worms hidden here, but of course I don't know what has been discussed elsewhere. My reason for starting the discussion back in December 2012 was that I noticed that was moved out of but was not. I never understood why was left in . > I am perfectly aware, of course, that only describes an item's current location, not previous ones. I have no particular preferences whether should be a child of , , or be their sibling. The latter option may very well be the best solution, making and siblings as they were originally, but now in the context of or instead of . In the physical description of an item, where it is now, provenance information appears - at least to me - even more out of place than the information on the item's current location. > I am sorry if this opens some unwanted discussions, but actually I > don't see this as very problematic, just as something we forgot :-) > > Best, > Axel > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > Benjamin Wolff Bohl > Sendt: 4. april 2014 11:04 > Til: mei-l at lists.uni-paderborn.de > Emne: Re: [MEI-L] history of sources / items > > Dear all, > > not that I have too much experience in cataloguing sources or writing verbose source description, but it might help to have a look at the TEI way of doing things. Some nice example applications concerning manuscripts were presented during the Edirom-Summer-School 2013 by Torsten Scha?an. > > The Herzog August Bibliothek has their TEI code available on-line, see for example: > http://diglib.hab.de/?db=mss&list=ms&id=27-2-aug-2f&catalog=Lesser&mod > e=xml > > Just my to code-points ;-) > 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 03.04.2014 21:32, schrieb Joachim Veit: > Dear Perry, > thank you very much for these details and excuse my misunderstanding of the possibilities of "annotation"!! > Indeed your proposal to transfer the possibiliies of to would be excellent in my eyes because - at least in our case - the history will be so detailed that seems to be semantically inadequate (at least if we consent that the content of an essay should not be hidden in the footnotes but in the main text...;-) ). > And with

we should have the opportunity to squeeze al things in which are hidden in the 27 corners of our project... > Waiting for the discussion with Kristina and Johannes tomorrow, > meanwhile with cordial thanks and best greetings, Joachim > > > Am 03.04.14 17:59, schrieb Roland, Perry D. (pdr4h): > > Johannes and Joachim, > > > Sometimes you have a copy, and you would like to tell the story behind > it - why it has been copied, under which conditions it happened, etc. Basically, I want to get hold of for source (and maybe item, even though I think this might be less important). Of course, people may confuse the histories of works and sources, but this doesn't explain why there shouldn't be a source history in MEI. I understand your motivation better, but is not the thing you're looking for (ala Obi-wan Kenobi). is intended to hold a *brief* statement of the circumstances of creation. That's why it's content model is very restrictive: > > > > > > > > > > It's nothing more than a string with and thrown in to capture important dates and places. You could think of as the "quick and dirty" or "headline" version of the content that follows it. > > For more "essay-like" content, you can use the other possible children of history; i.e., eventList and p. > > > > > > > > > > > > > > > But contrary to what Joachim said, the most "book-like" and least restrictive model is actually that of : > > > > > > > > > > > > This allows just about everything under the sun! > > On the issue of , what I hear you saying is that you'd like its content model to be more like that of , something like: > > > > > > > > > > > > > > where the members of model.textcomponentLike are: > > lgLike - lg > listLike - biblList, eventList, list > pLike -p > quoteLike - quote > tableLike - table > > or perhaps > > > > > > > > > > > > where the membership of model.divLike is just
and members of > model.divLike and model.textcomponentLike are permitted as content of >
> > or > > > > > > > > > > > > > > > making into a more div-Like container that can wrap other components and divs (which is how you can get section headings). > > These modifications will also address your need to include a list of bibliographic citations within . > > Going farther, we could even drop from , moving any content in former versions of MEI to subordinate

elements. This would eliminate the privileging of data-like uses of . > > > I still think that might be a better parent for > than . We agree that the provenance of an item is not part of the physical description, do we? I'm not saying we must move it to history, but I wonder if we could, possibly with additional means to prevent it from showing up on work and expression. was a convenient place to locate since in library land, as Joachim confirms, "provenance> often has clear connections with because stamps and librarian's or auctioneer's entries are often mentioned in this context." But there's no reason why it should remain there if there's a compelling reason to move it. > > We could move up a level into itself rather than placing it inside and then making available inside . Taking this approach would put where it needs to be (on ) and not everywhere can occur; that is, , , and (should we decide to allow there too). It also maintains separation between the history of "handing down" (quoting Joachim) of the item and the production history of the item, which is the proper content for /. > > 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 > Johannes Kepper [kepper at edirom.de] > Sent: Thursday, April 03, 2014 9:26 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] history of sources / items > > Am 03.04.2014 um 15:10 schrieb Roland, Perry D. (pdr4h) : > > > Johannes, > > Sorry for arriving late to the party. :-) > > The element wasn't provided in source (manifestation) and item in order to encourage the use of work/history or expression/history. The assumption was that what folks often have to say about a manifestation or item is really about the work and expression anyway. > Sometimes you have a copy, and you would like to tell the story behind > it - why it has been copied, under which conditions it happened, etc. > Basically, I want to get hold of for source (and maybe > item, even though I think this might be less important). Of course, > people may confuse the histories of works and sources, but this > doesn't explain why there shouldn't be a source history in MEI. > > > A notesStmt/annot element (perhaps with a label of "history" in this case) can be used as a "catch all" to capture any information not easily shoe-horned into the other available elements in work, expression, source, and item. But, since the models of source and item are essentially lists of optional children, it's also not difficult to add in all these places without creating any backwards compatibility problems. Before doing so, however, I'd like to know more about what you'd like to say about source and/or item history that makes this necessary. > > I'm not in favor of moving inside because doing this would mean breaking compatibility. It would also make provenance available inside work, expression, and source (e.g., work/history/provenance) where its presence could lead to abuse. What exactly is the provenance (that is, the custodial history) of a work or expression? I don't there is such a thing. > Well, I see your point, and I agree with that. There is certainly no > provenance of a work or expression. The kind of information someone > would be looking for is about the transmission of the work, which > should go into history. However, I still think that might be > a better parent for than . We agree that the > provenance of an item is not part of the physical description, do we? > I'm not saying we must move it to history, but I wonder if we could, > possibly with additional means to prevent it from showing up on work > and expression. > > > I don't understand what problem you're having with inside . Are you looking to provide bibliographic citations for whatever arguments you present in ? I need more information, please. > I have no problem with bibl inside source, except that it isn't > allowed. I'd like to be able to put in literature about a specific > source (like a review of a printed edition etc.), that's it. The > current means to get a bibl into source seem to be too complicated. > > Hth, > Johannes > Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > > > -- > p. > > __________________________ > Perry Roland > 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: Thursday, April 03, 2014 5:16 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] history of sources / items > > I was hoping to get a reply from Perry, especially since I think this dates back to the days before FRBR, when there were work and source elements. expression and item just inherited their standard models with little modifications, so I'm not surprised about their behavior. > > However, I also prefer to add a history element to source and item, > and moving provenance in there seems like a logical modification then. > I wouldn't worry too much about backward compatibility. I think we're > past the point where we'd have to make huge changes to the model, and > little modifications should require only little modifications in > software. Also, providing a XSLT to go back and forth between MEI2013 > and MEI201x is not an issue, so that people could use whatever is most > appropriate to them. This might result in putting the history > somewhere nested into a notesStmt when going back to 2013, but so be > it. > > I remember discussions about structured vs. prose-based content models for a number of elements, among them bibl and annot. Does this relate to the initial question, and should we revise it as well? > > > Johannes > Ceterum censeo, don't forget to discuss the MEI organization, either here on MEI-L or at http://bit.ly/1hDyq4X. > > > > Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field : > > > "Provenance" is a standard item in catalogues of works in manuscript, > but it has a range of meanings, all of which might comfortable fit > within "history". It sometimes identifies previously owners but > equally often it refers to a physical location (city, institution, > performing group et al.). > > 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 > Johannes Kepper > Sent: Wednesday, April 02, 2014 2:39 AM > To: Music Encoding Initiative > Subject: [MEI-L] history of sources / items > > Dear list, > > while discussing the upcoming Weber Werkverzeichnis (Weber's work > catalogue) with Kristina Richts and Joachim Veit, I can't remember why > we dropped the element from sources and items? We have it on > works and expressions, but not on these two. However, it might be > interested to write something about the creation of a source (which is > not the same as the provenance, which is available). Can someone > please remind me of our argument to drop it? Otherwise, it would be a > fault that we might want to correct. > > Btw., seems to be equally hidden (you can get it from source at > source/physDesc/physMedium/bibl.). > > 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 bohl at edirom.de Fri Apr 4 17:35:39 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 04 Apr 2014 17:35:39 +0200 Subject: [MEI-L] LinkedIn Group In-Reply-To: <533EBB9E.6090802@uibk.ac.at> References: <25910_1396614093_533EA3CD_25910_36_1_533EA426.2050000@uibk.ac.at> <533EBB9E.6090802@uibk.ac.at> Message-ID: <533ED14B.9090605@edirom.de> +1 again! *********************************************************** 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 04.04.2014 16:03, schrieb Lukas Christensen: > Thank you for your comments, Andrew and Perry! > I will add a sticky with a link to the mailing list (and maybe also some > other links) soon. > > -Lukas > > > Am 04.04.14 14:34, schrieb Andrew Hankinson: >> I'm all for this, Lukas. I think this is great for visibility and outreach. Thanks for taking the initiative. >> >> As moderator of the group, you should make sure to point people to this mailing list since this is where most community participation occurs. If you notice a question or statement in your group that isn't being answered, you should make sure that they know that it's probably better asked here. >> >> I don't think it's a bad thing that there are multiple places for discussion, but I would hope that it will encourage others to participate in the "official" channels. >> >> There's a PNG of the logo in the SVN repository. >> >> https://code.google.com/p/music-encoding/source/browse/trunk/source/guidelines/Images/meilogo.png >> >> -Andrew >> >> On Apr 4, 2014, at 8:23 AM, Lukas Christensen wrote: >> >>> Dear members of the MEI-L group, >>> >>> I took the liberty to open up a group in LinkedIn called "Music Encoding >>> Initiative (MEI)" for better networking among scholars inside this >>> social platform (so far there are no other MEI or TEI groups). >>> >>> Since I'm "just" a regular member of the MEI-L mailing list, there are a >>> few questions/comments I have: >>> >>> Would it be possible to use the logo from the official website for the >>> group? If so, is there one with a higher resolution? >>> >>> For now, the group and all of its contents will only be visible to >>> members. There is the possibility to open up the group so everyone on >>> the web (or just everyone within LinkedIn) has access to it. This is >>> something that needs to be discussed. >>> >>> Please let me know what you think about this whole idea. Hopefully I'm >>> not stepping on anyone's toes... >>> >>> Best regards, >>> Lukas Christensen >>> >>> -- >>> Lukas Christensen >>> PhD Candidate, Assistant Editor of Acta Musicologica >>> >>> Department of Music >>> University of Innsbruck >>> Karl-Sch?nherr-Str. 3 >>> A-6020 Innsbruck >>> Austria >>> >>> Web: http://acta-musicologica.net >>> >>> _______________________________________________ >>> mei-l mailing list >>> mei-l at lists.uni-paderborn.de >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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 lukas.christensen at uibk.ac.at Sat Apr 5 08:39:15 2014 From: lukas.christensen at uibk.ac.at (Lukas Christensen) Date: Sat, 05 Apr 2014 08:39:15 +0200 Subject: [MEI-L] LinkedIn Group In-Reply-To: <533ED14B.9090605@edirom.de> References: <25910_1396614093_533EA3CD_25910_36_1_533EA426.2050000@uibk.ac.at> <533EBB9E.6090802@uibk.ac.at> <533ED14B.9090605@edirom.de> Message-ID: <533FA513.8080303@uibk.ac.at> Could a link to the group also be added to the MEI website (e.g. under "Support")? The direct link would be: http://linkedin.com/groups?gid=7492329 Here's also the code for the LinkedIn symbol in combination with a text: View the Music Encoding Initiative (MEI) groupView the Music Encoding Initiative (MEI) group Best regards, Lukas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 947 bytes Desc: OpenPGP digital signature URL: From slu at kb.dk Tue Apr 8 12:31:22 2014 From: slu at kb.dk (Sigfrid Lundberg) Date: Tue, 8 Apr 2014 10:31:22 +0000 Subject: [MEI-L] Proposals MEI Strategy Development Group In-Reply-To: <533C0CFA.4040106@edirom.de> References: <533C0CFA.4040106@edirom.de> Message-ID: <0C090608704AF04E898055296C932B12011CAD41BD@EXCHANGE-03.kb.dk> Hi Benjamin and all other contributors to the strategy document! Thanks for good work! I have to say that I'm leaning towards the A alternative, or something close to it. The reason for that is that the MEI guidelines is our most important product (and I suppose that it will be so for years to come). Hence I think that the technical committee is needed as the maintainer of that document and as an entity that assumes the responsibility for its development. I'm not sure the board should have that responsibility. There are people who have the capacities needed for work both in a board and being a guideline editor, but perhaps not simultaneously? A gambit for a discussion from between an XML query and a transform. Yours, Sigfrid ________________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Benjamin Wolff Bohl [bohl at edirom.de] Sendt: 2. april 2014 15:13 Til: Music Encoding Initiative Emne: [MEI-L] Proposals MEI Strategy Development Group Dear MEI-L, after Music Encoding Conference 2013 MEI Strategy Development Group (MEI-Strat) was formed in order to elaborate proposals for future organization of MEI community. During the past months we have been working in order to start discussion on potential future forms of organizing MEI community. Now with the Music Encoding Conference 2014 being just around the corner it seems appropriate to start discussion on this subject matter, as we hope to distil a common community consensus on what might be new and openly communicated structures of MEI. Furthermore we intend to prepare presenations and a basis for further discussion for this year's conference (May 20-23 in Charlottesville, VA). ==A short disclaimer== Please be aware that anything in the proposal is indicative and subject to discussion, be it the individual proposals in general, or specific details, e.g. the length of terms for elected members. ==Words of thank== We thank the MEI community for the possibility to work on this subject matter, and for the confidence in our group! I personally like to thank all collaborators for their time, effort and good thoughts all of which were provided on expense of their private free time! ==The Discussion== The document containing our proposals is openly available online via google-Drive (no login required). Although modification of the text is not possible comments may be inserted by anyone with the link. Feel free to provide your identity when commenting or just submit anonymously. Of course it is not intended to discuss all raised topics in the document. A lively discussion on MEI-L would be warmly welcome so bring anything of interest to discussion there! ==The Document== https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing With many thanks to all collaborators, for the MEI Strategy Development Group, Benajmin 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 *********************************************************** _______________________________________________ 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 Apr 9 01:57:40 2014 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 8 Apr 2014 19:57:40 -0400 Subject: [MEI-L] Proposals MEI Strategy Development Group In-Reply-To: <0C090608704AF04E898055296C932B12011CAD41BD@EXCHANGE-03.kb.dk> References: <533C0CFA.4040106@edirom.de> <0C090608704AF04E898055296C932B12011CAD41BD@EXCHANGE-03.kb.dk> Message-ID: Hello everyone, Many thanks to the Strategy Development Group - you all clearly put a lot of effort into producing a well organized and clear document. I left a few specific comments on the document itself. In general, I prefer Model B: it's lean and reflects well the size of the community. It also keeps the focus on the Guidelines and releases, which I agree with Sigfrid are the most important product of this community. I feel model B will allows us to move forward without having to jump through too many administrative hoops, while tasking people with essential admin responsibilities. The idea of institutional sponsorship from Model A is good, though it might need some clearer bylaws. Model C, while innovative, feels like it's imposing a structure to interest groups that should just happen naturally. I see this as being ultimately counterproductive, partly because it's kind of predictable that one or two groups will always have the bigger cut, simply because of what MEI offers. Thanks again for all you work! Raff On Tue, Apr 8, 2014 at 6:31 AM, Sigfrid Lundberg wrote: > Hi Benjamin and all other contributors to the strategy document! > > Thanks for good work! > > I have to say that I'm leaning towards the A alternative, or something > close to it. The reason for that is that the MEI guidelines is our most > important product (and I suppose that it will be so for years to come). > Hence I think that the technical committee is needed as the maintainer of > that document and as an entity that assumes the responsibility for its > development. I'm not sure the board should have that responsibility. There > are people who have the capacities needed for work both in a board and > being a guideline editor, but perhaps not simultaneously? > > A gambit for a discussion from between an XML query and a transform. > > Yours, > > Sigfrid > > ________________________________________ > Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af > Benjamin Wolff Bohl [bohl at edirom.de] > Sendt: 2. april 2014 15:13 > Til: Music Encoding Initiative > Emne: [MEI-L] Proposals MEI Strategy Development Group > > Dear MEI-L, > > after Music Encoding Conference 2013 MEI Strategy Development Group > (MEI-Strat) was formed in order to elaborate proposals for future > organization of MEI community. During the past months we have been > working in order to start discussion on potential future forms of > organizing MEI community. > > Now with the Music Encoding Conference 2014 being just around the corner > it seems appropriate to start discussion on this subject matter, as we > hope to distil a common community consensus on what might be new and > openly communicated structures of MEI. Furthermore we intend to prepare > presenations and a basis for further discussion for this year's > conference (May 20-23 in Charlottesville, VA). > > ==A short disclaimer== > Please be aware that anything in the proposal is indicative and subject > to discussion, be it the individual proposals in general, or specific > details, e.g. the length of terms for elected members. > > ==Words of thank== > We thank the MEI community for the possibility to work on this subject > matter, and for the confidence in our group! > I personally like to thank all collaborators for their time, effort and > good thoughts all of which were provided on expense of their private > free time! > > ==The Discussion== > The document containing our proposals is openly available online via > google-Drive (no login required). Although modification of the text is > not possible comments may be inserted by anyone with the link. Feel free > to provide your identity when commenting or just submit anonymously. > Of course it is not intended to discuss all raised topics in the > document. A lively discussion on MEI-L would be warmly welcome so bring > anything of interest to discussion there! > > ==The Document== > > https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing > > > With many thanks to all collaborators, > for the MEI Strategy Development Group, > Benajmin 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 > *********************************************************** > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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 Thu Apr 10 12:40:36 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 10 Apr 2014 12:40:36 +0200 Subject: [MEI-L] Proposals MEI Strategy Development Group In-Reply-To: References: <533C0CFA.4040106@edirom.de> <0C090608704AF04E898055296C932B12011CAD41BD@EXCHANGE-03.kb.dk> Message-ID: <53467524.5000503@edirom.de> Dear all, thanks for starting discussion on the proposals! For some short replies and digest of the comments in the googleDoc: The Guidelines definitely are the most important product of MEI, together with the schema. An it sounds wise not to overload the production of these documents with organizational / bureaucratic matters. I think this is something everybody should keep in mind ;-) Institutional Membership seems to have a lot of potential discussion. her e are some questions to help us get clear what MEI wants: - 1) A general question that could be raised in this context is whether the idea of Institutional Membership should be an issue not tied to a specific model but of general interest for MEI and thus any future model of its organization? - 2) Designating three levels of Institutional Membership with respective increase of fees should result in more than just a label. This only motivates to support with the lowest membership and even if wanted it might get hard to argue to spend more money if it doesn't bring more benefits. - 3) Should Institutional Members (of any level or just highest level) have a seat in the Board? Should these be allowed the right to vote or not - 4) If institutional Memberships allow for a voting seat in the Board, how avoid the risk of buying control over MEI? - 5) Why not tie the fees for Institutional Membership to the size of the institution an d their annual budget? > Model C, while innovative, feels like it's imposing a structure to > interest groups that should just happen naturally. I see this as being > ultimately counterproductive, partly because it's kind of predictable > that one or two groups will always have the bigger cut, simply because > of what MEI offers. I'm not sure what you mean with "such things". The general statements concerning Interest Groups impose the structure to them. The idea of Model C in this context is that in contrary to having exclusively Board members form the groups with the "bigger cut" it allows smaller groups to participate in the Board, not least because the ratios for sending group members to the Board is in favour of smaller groups. 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 09.04.2014 01:57, schrieb Raffaele Viglianti: > Hello everyone, > > Many thanks to the Strategy Development Group - you all clearly put a > lot of effort into producing a well organized and clear document. > > I left a few specific comments on the document itself. In general, I > prefer Model B: it's lean and reflects well the size of the community. > It also keeps the focus on the Guidelines and releases, which I agree > with Sigfrid are the most important product of this community. I feel > model B will allows us to move forward without having to jump through > too many administrative hoops, while tasking people with essential > admin responsibilities. The idea of institutional sponsorship from > Model A is good, though it might need some clearer bylaws. Model C, > while innovative, feels like it's imposing a structure to interest > groups that should just happen naturally. I see this as being > ultimately counterproductive, partly because it's kind of predictable > that one or two groups will always have the bigger cut, simply because > of what MEI offers. > > Thanks again for all you work! > Raff > > > On Tue, Apr 8, 2014 at 6:31 AM, Sigfrid Lundberg > wrote: > > Hi Benjamin and all other contributors to the strategy document! > > Thanks for good work! > > I have to say that I'm leaning towards the A alternative, or > something close to it. The reason for that is that the MEI > guidelines is our most important product (and I suppose that it > will be so for years to come). Hence I think that the technical > committee is needed as the maintainer of that document and as an > entity that assumes the responsibility for its development. I'm > not sure the board should have that responsibility. There are > people who have the capacities needed for work both in a board and > being a guideline editor, but perhaps not simultaneously? > > A gambit for a discussion from between an XML query and a transform. > > Yours, > > Sigfrid > > ________________________________________ > Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de > ] på vegne af > Benjamin Wolff Bohl [bohl at edirom.de ] > Sendt: 2. april 2014 15:13 > Til: Music Encoding Initiative > Emne: [MEI-L] Proposals MEI Strategy Development Group > > Dear MEI-L, > > after Music Encoding Conference 2013 MEI Strategy Development Group > (MEI-Strat) was formed in order to elaborate proposals for future > organization of MEI community. During the past months we have been > working in order to start discussion on potential future forms of > organizing MEI community. > > Now with the Music Encoding Conference 2014 being just around the > corner > it seems appropriate to start discussion on this subject matter, as we > hope to distil a common community consensus on what might be new and > openly communicated structures of MEI. Furthermore we intend to > prepare > presenations and a basis for further discussion for this year's > conference (May 20-23 in Charlottesville, VA). > > ==A short disclaimer== > Please be aware that anything in the proposal is indicative and > subject > to discussion, be it the individual proposals in general, or specific > details, e.g. the length of terms for elected members. > > ==Words of thank== > We thank the MEI community for the possibility to work on this subject > matter, and for the confidence in our group! > I personally like to thank all collaborators for their time, > effort and > good thoughts all of which were provided on expense of their private > free time! > > ==The Discussion== > The document containing our proposals is openly available online via > google-Drive (no login required). Although modification of the text is > not possible comments may be inserted by anyone with the link. > Feel free > to provide your identity when commenting or just submit anonymously. > Of course it is not intended to discuss all raised topics in the > document. A lively discussion on MEI-L would be warmly welcome so > bring > anything of interest to discussion there! > > ==The Document== > https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing > > > With many thanks to all collaborators, > for the MEI Strategy Development Group, > Benajmin 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 > *********************************************************** > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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 Thu Apr 10 22:25:07 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 10 Apr 2014 20:25:07 +0000 Subject: [MEI-L] Round table: From scholar to user via MEI Message-ID: Dear colleagues, On behalf of the program committee, I am pleased to announce a round table discussion on digital editing and publishing efforts and libraries. The round table is part of the Music Encoding Conference 2014, taking place in Charlottesville, May 20-23. Please join us for what promises to be a lively discussion. Visit music-encoding.org/conference for more information. Registration for the conference closes on April 20, so don't delay. Thanks in advance for widely disseminating this notice. Hope to see you in Charlottesville, ________________________________________________________________________________________________________ >From scholar to user via MEI: Digital editing and publishing vis-?-vis library ways and means Organizer and Moderator: Eleanor Selfridge-Field, Professor of Music and Symbolic Systems, CCARH, Stanford University As the first fruits of hybrid (paper and digital) critical editions appear, many music librarians are perplexed. This round table is devoted to grounding a dialogue involving scholars, editors, publishers, librarians, and readers. None of these constituencies has control over any other, a fact that is sometimes lost in conversations within any one of them. In the hope of restoring accurate communication between communities, our round table will set out as clearly as possible the advantages that digital and hybrid editions offer with a view towards promoting a balanced discussion in which all parties understand and respect the needs of others. The round table will feature three representatives for each of the two communities of ?providers? and ?end-users?: * Mauro Calcagno, Associate Professor of Music at the University of Pennsylvania and director of the Marenzio Project * Norbert Dubowy, musicologist, co-editor of OPERA: Spektrum des europ?ischen Musiktheaters in Einzeleditionen (Goethe-Universit?t, Frankfurt am Main, Germany) * Douglas Woodfill-Harris, U.S. representative of B?renreiter GmbH, the publisher of hybrid editions (including the OPERA series) and a large number of Gesamtausgaben **** * Daniel Boomhower, musicologist, Head of Reader Services, Music Division, Library of Congress (Washington, DC) and Chair of the RISM-USA Committee * Philip Ponella, Head of the William and Gayle Cook Music Library and Director of Music Information Technology Services at Indiana University, Bloomington * Federica Riva, Librarian of the Conservatorio di Musica Luigi Cherubini (Florence, Italy), which hosts a manuscript digitization project (16th- through 20th-century sources); President of IAML-Italy; formerly Chair of the IAML Copyright Committee Each part with conclude with a brief interchange among the panelists. The final 20 minutes is open to questions, comments, and proposals from the audience. -- 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 veit at weber-gesamtausgabe.de Thu Apr 10 22:25:19 2014 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Thu, 10 Apr 2014 22:25:19 +0200 Subject: [MEI-L] Proposals MEI Strategy Development Group In-Reply-To: <53467524.5000503@edirom.de> References: <533C0CFA.4040106@edirom.de> <0C090608704AF04E898055296C932B12011CAD41BD@EXCHANGE-03.kb.dk> <53467524.5000503@edirom.de> Message-ID: <5346FE2F.5030503@weber-gesamtausgabe.de> Dear Benjamin, thanks a lot for summing up part of the discussion! Without voting for A or B at the moment, only a few remarks concerning Institutional membership interspersed in your text: Hoping that the discussion continues, Joachim Am 10.04.14 12:40, schrieb Benjamin Wolff Bohl: > Dear all, > thanks for starting discussion on the proposals! > > For some short replies and digest of the comments in the googleDoc: > > The Guidelines definitely are the most important product of MEI, > together with the schema. An it sounds wise not to overload the > production of these documents with organizational / bureaucratic > matters. I think this is something everybody should keep in mind ;-) > > Institutional Membership seems to have a lot of potential discussion. > her e are some questions to help us get clear what MEI wants: > - 1) A general question that could be raised in this context is > whether the idea of Institutional Membership should be an issue not > tied to a specific model but of general interest for MEI and thus any > future model of its organization? > > - 2) Designating three levels of Institutional Membership with > respective increase of fees should result in more than just a label. > This only motivates to support with the lowest membership and even if > wanted it might get hard to argue to spend more money if it doesn't > bring more benefits. > > - 3) Should Institutional Members (of any level or just highest level) > have a seat in the Board? Should these be allowed the right to vote or not > I think the danger you describe in the following point 4 is an > important argument against seats in the Board. The system of buying > votes or seats is extremely un-democratic. We should accept that an > Institutional Member has one vote as each individual member and try to > find other means of "award" for such fine institutions who are willing > to promote the MEI community. So I very much sympathize with your > proposal under 5) (which is the "TEI" one). We should also avoid - if there will be an individual fee on the long term - that institutions spending, e.g., 500 $ see this as paying for their 200 individual members. That's no problem at the moment at all - but perspectively. So I plea for treating individual and institutional members alike - at least concerning their rights to vote or being elected. > - 4) If institutional Memberships allow for a voting seat in the > Board, how avoid the risk of buying control over MEI? > > - 5) Why not tie the fees for Institutional Membership to the size of > the institution an d their annual budget? > > >> Model C, while innovative, feels like it's imposing a structure to >> interest groups that should just happen naturally. I see this as >> being ultimately counterproductive, partly because it's kind of >> predictable that one or two groups will always have the bigger cut, >> simply because of what MEI offers. > > I'm not sure what you mean with "such things". The general statements > concerning Interest Groups impose the structure to them. The idea of > Model C in this context is that in contrary to having exclusively > Board members form the groups with the "bigger cut" it allows smaller > groups to participate in the Board, not least because the ratios for > sending group members to the Board is in favour of smaller groups. Imagine we have 15 interest groups (whow, fine!!....) - all should send a member in the Board? How should such a big board operate? > > > 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 09.04.2014 01:57, schrieb Raffaele Viglianti: >> Hello everyone, >> >> Many thanks to the Strategy Development Group - you all clearly put a >> lot of effort into producing a well organized and clear document. >> >> I left a few specific comments on the document itself. In general, I >> prefer Model B: it's lean and reflects well the size of the >> community. It also keeps the focus on the Guidelines and releases, >> which I agree with Sigfrid are the most important product of this >> community. I feel model B will allows us to move forward without >> having to jump through too many administrative hoops, while tasking >> people with essential admin responsibilities. The idea of >> institutional sponsorship from Model A is good, though it might need >> some clearer bylaws. Model C, while innovative, feels like it's >> imposing a structure to interest groups that should just happen >> naturally. I see this as being ultimately counterproductive, partly >> because it's kind of predictable that one or two groups will always >> have the bigger cut, simply because of what MEI offers. >> >> Thanks again for all you work! >> Raff >> >> >> On Tue, Apr 8, 2014 at 6:31 AM, Sigfrid Lundberg > > wrote: >> >> Hi Benjamin and all other contributors to the strategy document! >> >> Thanks for good work! >> >> I have to say that I'm leaning towards the A alternative, or >> something close to it. The reason for that is that the MEI >> guidelines is our most important product (and I suppose that it >> will be so for years to come). Hence I think that the technical >> committee is needed as the maintainer of that document and as an >> entity that assumes the responsibility for its development. I'm >> not sure the board should have that responsibility. There are >> people who have the capacities needed for work both in a board >> and being a guideline editor, but perhaps not simultaneously? >> >> A gambit for a discussion from between an XML query and a transform. >> >> Yours, >> >> Sigfrid >> >> ________________________________________ >> Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de >> ] på vegne af >> Benjamin Wolff Bohl [bohl at edirom.de ] >> Sendt: 2. april 2014 15:13 >> Til: Music Encoding Initiative >> Emne: [MEI-L] Proposals MEI Strategy Development Group >> >> Dear MEI-L, >> >> after Music Encoding Conference 2013 MEI Strategy Development Group >> (MEI-Strat) was formed in order to elaborate proposals for future >> organization of MEI community. During the past months we have been >> working in order to start discussion on potential future forms of >> organizing MEI community. >> >> Now with the Music Encoding Conference 2014 being just around the >> corner >> it seems appropriate to start discussion on this subject matter, >> as we >> hope to distil a common community consensus on what might be new and >> openly communicated structures of MEI. Furthermore we intend to >> prepare >> presenations and a basis for further discussion for this year's >> conference (May 20-23 in Charlottesville, VA). >> >> ==A short disclaimer== >> Please be aware that anything in the proposal is indicative and >> subject >> to discussion, be it the individual proposals in general, or specific >> details, e.g. the length of terms for elected members. >> >> ==Words of thank== >> We thank the MEI community for the possibility to work on this >> subject >> matter, and for the confidence in our group! >> I personally like to thank all collaborators for their time, >> effort and >> good thoughts all of which were provided on expense of their private >> free time! >> >> ==The Discussion== >> The document containing our proposals is openly available online via >> google-Drive (no login required). Although modification of the >> text is >> not possible comments may be inserted by anyone with the link. >> Feel free >> to provide your identity when commenting or just submit anonymously. >> Of course it is not intended to discuss all raised topics in the >> document. A lively discussion on MEI-L would be warmly welcome so >> bring >> anything of interest to discussion there! >> >> ==The Document== >> https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing >> >> >> With many thanks to all collaborators, >> for the MEI Strategy Development Group, >> Benajmin 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 >> *********************************************************** >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >> >> >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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: -------------- 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 Thu Apr 10 23:17:27 2014 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Thu, 10 Apr 2014 14:17:27 -0700 (PDT) Subject: [MEI-L] Proposals MEI Strategy Development Group In-Reply-To: <53467524.5000503@edirom.de> References: <533C0CFA.4040106@edirom.de> <0C090608704AF04E898055296C932B12011CAD41BD@EXCHANGE-03.kb.dk> <53467524.5000503@edirom.de> Message-ID: <3edc6fdb.00001818.00000012@CCARH-ADM-2.su.win.stanford.edu> One thing that can be tricky about institutional memberships at various levels in the US is that schools within an institution have budgets that are set independently. Here at Stanford the Medical, Law, and Business Schools are heavily endowed, but the School of Humanities and Sciences (might be Arts and Sciences elsewhere) has very little loose change in its budget. For MEI this is not a matter to be concerned with for now, but when MusicXML was first associated with WWW3, there was no way to comment on official proposals without an institutional affiliation (minimum subscription: $10,000). Stanford as a university did not have a membership. MEI should for now look to music libraries and possibly to other academic organizations for memberships. Usually in the US institutional membership provides an institution with a journal that is published three or four times a year, an online forum, and other benefits. The typical institutional membership rate is 20%-30% higher than the individual rate. 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+esfield=stanford.edu at lists.uni-paderborn.de] On Behalf Of Benjamin Wolff Bohl Sent: Thursday, April 10, 2014 3:41 AM To: mei-l at lists.uni-paderborn.de Subject: Re: [MEI-L] Proposals MEI Strategy Development Group Dear all, thanks for starting discussion on the proposals! For some short replies and digest of the comments in the googleDoc: The Guidelines definitely are the most important product of MEI, together with the schema. An it sounds wise not to overload the production of these documents with organizational / bureaucratic matters. I think this is something everybody should keep in mind ;-) Institutional Membership seems to have a lot of potential discussion. her e are some questions to help us get clear what MEI wants: - 1) A general question that could be raised in this context is whether the idea of Institutional Membership should be an issue not tied to a specific model but of general interest for MEI and thus any future model of its organization? - 2) Designating three levels of Institutional Membership with respective increase of fees should result in more than just a label. This only motivates to support with the lowest membership and even if wanted it might get hard to argue to spend more money if it doesn't bring more benefits. - 3) Should Institutional Members (of any level or just highest level) have a seat in the Board? Should these be allowed the right to vote or not - 4) If institutional Memberships allow for a voting seat in the Board, how avoid the risk of buying control over MEI? - 5) Why not tie the fees for Institutional Membership to the size of the institution an d their annual budget? Model C, while innovative, feels like it's imposing a structure to interest groups that should just happen naturally. I see this as being ultimately counterproductive, partly because it's kind of predictable that one or two groups will always have the bigger cut, simply because of what MEI offers. I'm not sure what you mean with "such things". The general statements concerning Interest Groups impose the structure to them. The idea of Model C in this context is that in contrary to having exclusively Board members form the groups with the "bigger cut" it allows smaller groups to participate in the Board, not least because the ratios for sending group members to the Board is in favour of smaller groups. 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 09.04.2014 01:57, schrieb Raffaele Viglianti: Hello everyone, Many thanks to the Strategy Development Group - you all clearly put a lot of effort into producing a well organized and clear document. I left a few specific comments on the document itself. In general, I prefer Model B: it's lean and reflects well the size of the community. It also keeps the focus on the Guidelines and releases, which I agree with Sigfrid are the most important product of this community. I feel model B will allows us to move forward without having to jump through too many administrative hoops, while tasking people with essential admin responsibilities. The idea of institutional sponsorship from Model A is good, though it might need some clearer bylaws. Model C, while innovative, feels like it's imposing a structure to interest groups that should just happen naturally. I see this as being ultimately counterproductive, partly because it's kind of predictable that one or two groups will always have the bigger cut, simply because of what MEI offers. Thanks again for all you work! Raff On Tue, Apr 8, 2014 at 6:31 AM, Sigfrid Lundberg wrote: Hi Benjamin and all other contributors to the strategy document! Thanks for good work! I have to say that I'm leaning towards the A alternative, or something close to it. The reason for that is that the MEI guidelines is our most important product (and I suppose that it will be so for years to come). Hence I think that the technical committee is needed as the maintainer of that document and as an entity that assumes the responsibility for its development. I'm not sure the board should have that responsibility. There are people who have the capacities needed for work both in a board and being a guideline editor, but perhaps not simultaneously? A gambit for a discussion from between an XML query and a transform. Yours, Sigfrid ________________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Benjamin Wolff Bohl [bohl at edirom.de] Sendt: 2. april 2014 15:13 Til: Music Encoding Initiative Emne: [MEI-L] Proposals MEI Strategy Development Group Dear MEI-L, after Music Encoding Conference 2013 MEI Strategy Development Group (MEI-Strat) was formed in order to elaborate proposals for future organization of MEI community. During the past months we have been working in order to start discussion on potential future forms of organizing MEI community. Now with the Music Encoding Conference 2014 being just around the corner it seems appropriate to start discussion on this subject matter, as we hope to distil a common community consensus on what might be new and openly communicated structures of MEI. Furthermore we intend to prepare presenations and a basis for further discussion for this year's conference (May 20-23 in Charlottesville, VA). ==A short disclaimer== Please be aware that anything in the proposal is indicative and subject to discussion, be it the individual proposals in general, or specific details, e.g. the length of terms for elected members. ==Words of thank== We thank the MEI community for the possibility to work on this subject matter, and for the confidence in our group! I personally like to thank all collaborators for their time, effort and good thoughts all of which were provided on expense of their private free time! ==The Discussion== The document containing our proposals is openly available online via google-Drive (no login required). Although modification of the text is not possible comments may be inserted by anyone with the link. Feel free to provide your identity when commenting or just submit anonymously. Of course it is not intended to discuss all raised topics in the document. A lively discussion on MEI-L would be warmly welcome so bring anything of interest to discussion there! ==The Document== https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUf qzeQs/edit?usp=sharing With many thanks to all collaborators, for the MEI Strategy Development Group, Benajmin 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 *********************************************************** _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/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 Fri Apr 11 21:21:55 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 11 Apr 2014 19:21:55 +0000 Subject: [MEI-L] =?windows-1252?q?=91Kings_of_Freedom=92_Art_to_be_Unveile?= =?windows-1252?q?d_Friday_at_Berlin_Wall_Installation?= Message-ID: For those coming for the conference, here's more info about the Berlin Wall installation at UVA -- https://news.virginia.edu/content/kings-freedom-art-be-unveiled-friday-berlin-wall-installation -- 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 jason.stoessel at une.edu.au Mon Apr 14 07:38:36 2014 From: jason.stoessel at une.edu.au (Jason Stoessel) Date: Mon, 14 Apr 2014 15:38:36 +1000 Subject: [MEI-L] NeoScribe Message-ID: Dear MEI listers Please allow me to introduce myself. My name is Jason Stoessel. I hold a PhD in music, with a specialisation in late 14th/early 15th century music, music notation and musical cultures. I also have a keen interest in computer programming (undoubtedly full of bad habits as an autodidact), and once made a small living from it before pursuing my music research interests. You can find some of my research publications on academia.edu, and I maintain a blog at jjstoessel dot wordpress dot com (remove the ?dots? to obtain the correct URL). I would like to share briefly some work that John Stinson (director the La Trobe Medieval Music Database) and I have been doing to convert a large body of encoded music notation from Stinson?s proprietary Scribe program to a new MEI-compliant data schema that we call NeoScribe. Scribe was developed between 1984 and 1996 to encode every meaningful mark on a page of medieval music notation (mostly 14th century chant and mensural notation) and in many ways remains unparalleled in its capabilities. Despite its age and granted that it needs to be replaced with a more current user interface metaphor, Scribe still runs effectively on DOS Box. While MEI already has modules that partly support the encoding of chant notation and mensural music notation, we soon discovered that they were not sufficient for encapsulating the range of music notation data present in Scribe data files. A new module that extends the "Neume Notation" and "Mensural Notation" modules of MEI was required. One thing that encouraged us in this endeavour is the stated view of the MEI project team that MEI's modular nature invited researchers to add other modules that addressed their specific requirements. Stinson and I presented a paper at the Digital Humanities Australasia 2014 conference entitled "Towards an Open Access Standard for Encoded Medieval Music Notation: NeoScribeXML? which details some of our efforts to date. Further details can be found on my blog listed above. To date we have produced a command line tool for converting Scribe files to NeoScribe files. A copy of the open source code for this tool can be found on GitHub, http://github.com/jjstoessel/Scribe2NeoScribe. We are not making any claims that this initial release of alpha version software is fit for widespread use and that the data it currently produces reflects the eventual definition of the MEI NeoScribe schema. It is untested alpha software. A beta release will occur in the next 12 months or so, including documentation for the new NeoScribe schema for those happy to wait. While the original user base of Scribe was small, we anticipate the Scribe2NeoScribe tool will be beneficial to the owners of additional data encoded by musicologists who have used Scribe in the past, and perhaps to data curators who might wish to make old data once again useful and able to be read on modern computers. In the near future, we expect to be able to provide the MEI NeoScribe data for some 6000 pieces of music. Presently we are working towards ensuring that existing Scribe data is full encapsulated in NeoScribe and that some further extensions of mensural notation are incorporated to deal with the innovations of the late fourteenth century, including its multiplicities of note shapes. We are considering how this might be integrated with other projects like the SMuFL which now includes a comprehensive layer of glyphs for mensural notation. Good regards, Jason Stoessel -- Dr Jason Stoessel 2013-14 International Research Visitor (Oxford University) Balzan Programme in Musicology "Towards a Global History of Music" -- 2014 Associate Investigator ARC Centre of Excellence for the History of Emotions -- Adjunct Research Fellow School of Arts Faculty of Arts and Sciences University of New England ARMIDALE NSW 2351 jason.stoessel at une.edu.au Skype ID: jjstoessel FaceTime: jason.stoessel at gmail.com UK Mobile: 07741 796 686 Overseas Mobile: +37257 087 172 From andrew.hankinson at mail.mcgill.ca Mon Apr 14 14:12:37 2014 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 14 Apr 2014 12:12:37 +0000 Subject: [MEI-L] NeoScribe In-Reply-To: <11288_1397453941_534B7475_11288_282_2_E5D83DDC-4073-4AA5-8289-9EF5255BBF1C@une.edu.au> References: <11288_1397453941_534B7475_11288_282_2_E5D83DDC-4073-4AA5-8289-9EF5255BBF1C@une.edu.au> Message-ID: <08D0F115-1832-4A16-A173-2E5F88CCD058@mail.mcgill.ca> Hi Jason, Welcome! Your work looks fantastic. When it?s ready, I?d be interested to see your ODD customizations. We?re (slowly) working on updating the neume notation module, so I?m sure you would have some valuable experiences to share. Cheers, -Andrew On Apr 14, 2014, at 1:38 AM, Jason Stoessel wrote: > Dear MEI listers > > Please allow me to introduce myself. My name is Jason Stoessel. I hold a PhD in music, with a specialisation in late 14th/early 15th century music, music notation and musical cultures. I also have a keen interest in computer programming (undoubtedly full of bad habits as an autodidact), and once made a small living from it before pursuing my music research interests. You can find some of my research publications on academia.edu, and I maintain a blog at jjstoessel dot wordpress dot com (remove the ?dots? to obtain the correct URL). > > I would like to share briefly some work that John Stinson (director the La Trobe Medieval Music Database) and I have been doing to convert a large body of encoded music notation from Stinson?s proprietary Scribe program to a new MEI-compliant data schema that we call NeoScribe. Scribe was developed between 1984 and 1996 to encode every meaningful mark on a page of medieval music notation (mostly 14th century chant and mensural notation) and in many ways remains unparalleled in its capabilities. Despite its age and granted that it needs to be replaced with a more current user interface metaphor, Scribe still runs effectively on DOS Box. While MEI already has modules that partly support the encoding of chant notation and mensural music notation, we soon discovered that they were not sufficient for encapsulating the range of music notation data present in Scribe data files. A new module that extends the "Neume Notation" and "Mensural Notation" modules of MEI was required. One thing that encouraged us in this endeavour is the stated view of the MEI project team that MEI's modular nature invited researchers to add other modules that addressed their specific requirements. Stinson and I presented a paper at the Digital Humanities Australasia 2014 conference entitled "Towards an Open Access Standard for Encoded Medieval Music Notation: NeoScribeXML? which details some of our efforts to date. Further details can be found on my blog listed above. > > To date we have produced a command line tool for converting Scribe files to NeoScribe files. A copy of the open source code for this tool can be found on GitHub, http://github.com/jjstoessel/Scribe2NeoScribe. We are not making any claims that this initial release of alpha version software is fit for widespread use and that the data it currently produces reflects the eventual definition of the MEI NeoScribe schema. It is untested alpha software. A beta release will occur in the next 12 months or so, including documentation for the new NeoScribe schema for those happy to wait. While the original user base of Scribe was small, we anticipate the Scribe2NeoScribe tool will be beneficial to the owners of additional data encoded by musicologists who have used Scribe in the past, and perhaps to data curators who might wish to make old data once again useful and able to be read on modern computers. > > In the near future, we expect to be able to provide the MEI NeoScribe data for some 6000 pieces of music. Presently we are working towards ensuring that existing Scribe data is full encapsulated in NeoScribe and that some further extensions of mensural notation are incorporated to deal with the innovations of the late fourteenth century, including its multiplicities of note shapes. We are considering how this might be integrated with other projects like the SMuFL which now includes a comprehensive layer of glyphs for mensural notation. > > Good regards, > > Jason Stoessel > > -- > Dr Jason Stoessel > 2013-14 International Research Visitor (Oxford University) > Balzan Programme in Musicology > "Towards a Global History of Music" > -- > 2014 Associate Investigator > ARC Centre of Excellence for the History of Emotions > -- > Adjunct Research Fellow > School of Arts > Faculty of Arts and Sciences > University of New England > ARMIDALE NSW 2351 > jason.stoessel at une.edu.au > Skype ID: jjstoessel > FaceTime: jason.stoessel at gmail.com > UK Mobile: 07741 796 686 > Overseas Mobile: +37257 087 172 > > > _______________________________________________ > 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 Apr 14 17:18:45 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 14 Apr 2014 15:18:45 +0000 Subject: [MEI-L] Music Encoding Conference call for late-breaking submissions In-Reply-To: References: Message-ID: Dear colleagues, This is a friendly reminder that today is the deadline for late-breaking poster submissions for the 2014 Music Encoding Conference. Hope to see you in Charlottesville, -- p. __________________________ Perry Roland 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, March 18, 2014 10:24 AM To: mei-l at lists.uni-paderborn.de Subject: [MEI-L] Music Encoding Conference call for late-breaking submissions With apologies for duplicate postings. The Music Encoding Conference Charlottesville, Virginia 20-23 May 2014 https://music-encoding.org/conference The Program Committee announces that "late-breaking" poster submissions will be accepted until *April 14th*. "Late-breaking" posters usually aim to present research projects under development or results that were not available at the time of the original call for submissions. New submissions will be subject to the same review process as before. Please visit https://music-encoding.org/conference/submission for more details. Authors of accepted posters will be notified on or before *24 April* and will need to register by *30 April*. We won't be able to grant any extension. If you have any questions, please contact conference2013 at music-encoding.org. -- 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 pdr4h at eservices.virginia.edu Mon Apr 14 22:07:35 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 14 Apr 2014 20:07:35 +0000 Subject: [MEI-L] Music Encoding Conference late-breaking submissions Message-ID: Dear colleagues, My apologies for hammering away at this, but it appears a problem in our ConfTool installation has been rejecting submissions. The problem should be fixed now. We have extended the deadline for late-breaking submissions until April 18 at midnight. Thank you for your patience. As always, please mail conference2014 at music-encoding.org with questions. -- p. __________________________ 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 Mon Apr 14 22:48:12 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 14 Apr 2014 20:48:12 +0000 Subject: [MEI-L] Music Encoding Conference late-breaking submissions Message-ID: Dear friends, My apologies for hammering away at this, but it appears a problem in our ConfTool installation has been rejecting submissions. The problem should be fixed now. We have extended the deadline for late-breaking submissions until April 18 at midnight. Thank you for your patience. As always, please mail conference2014 at music-encoding.org with questions. -- p. __________________________ 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 Wed Apr 16 12:11:52 2014 From: zupftom at googlemail.com (TW) Date: Wed, 16 Apr 2014 12:11:52 +0200 Subject: [MEI-L] NeoScribe In-Reply-To: References: Message-ID: Dear Jason, it's great to hear about more active projects working with neumatic notation and MEI. For the Corpus monodicum project[1] (lead by the Universit?t W?rzburg and the Akademie der Wissenschaften Mainz), we developed a transcription tool called mono:di[2] at Notengrafik Berlin[3] that is based on the current MEI Neumes module created by Stefan Morent. I'm intending to send a separate mail about this software to MEI-L shortly. We, too, were about to create a modification of the Neumes module which we'd like to use in the next version of our software. It will be some time until we'll be starting work on this next version. This has lead me to procrastinate discussing suggestions for how the Neumes module could be modified (which I feel guilty about as I already announced/promised this some time ago). Is it possible to access the encoded music from the La Trobe Medieval Music Database? Also, is there a way of accessing the Scribe software or at least some of its documentation? I'd love to see some sample of your MEI encoded chants. I'll ask Corpus monodicum editors whether it's possible to share a sample of our data as well, ideally with some facsimile (if legally possible). I'd suggest taking this opportunity and actually start a discussion about how the Neumes module should evolve. To prevent any further procrastination on my side, I'm setting myself May 7th as the date for providing suggestions in the form of commented samples and/or an ODD. Looking forward to learning more about your work Thomas Weber [1] http://corpus-monodicum.de/ [2] https://monodi.corpus-monodicum.de/ [3] http://notengrafik.com/ 2014-04-14 7:38 GMT+02:00 Jason Stoessel : > Dear MEI listers > > Please allow me to introduce myself. My name is Jason Stoessel. I hold a PhD in music, with a specialisation in late 14th/early 15th century music, music notation and musical cultures. I also have a keen interest in computer programming (undoubtedly full of bad habits as an autodidact), and once made a small living from it before pursuing my music research interests. You can find some of my research publications on academia.edu, and I maintain a blog at jjstoessel dot wordpress dot com (remove the ?dots? to obtain the correct URL). > > I would like to share briefly some work that John Stinson (director the La Trobe Medieval Music Database) and I have been doing to convert a large body of encoded music notation from Stinson?s proprietary Scribe program to a new MEI-compliant data schema that we call NeoScribe. Scribe was developed between 1984 and 1996 to encode every meaningful mark on a page of medieval music notation (mostly 14th century chant and mensural notation) and in many ways remains unparalleled in its capabilities. Despite its age and granted that it needs to be replaced with a more current user interface metaphor, Scribe still runs effectively on DOS Box. While MEI already has modules that partly support the encoding of chant notation and mensural music notation, we soon discovered that they were not sufficient for encapsulating the range of music notation data present in Scribe data files. A new module that extends the "Neume Notation" and "Mensural Notation" modules of MEI was required. One thing that encouraged us in this endeavour is the stated view of the MEI project team that MEI's modular nature invited researchers to add other modules that addressed their specific requirements. Stinson and I presented a paper at the Digital Humanities Australasia 2014 conference entitled "Towards an Open Access Standard for Encoded Medieval Music Notation: NeoScribeXML? which details some of our efforts to date. Further details can be found on my blog listed above. > > To date we have produced a command line tool for converting Scribe files to NeoScribe files. A copy of the open source code for this tool can be found on GitHub, http://github.com/jjstoessel/Scribe2NeoScribe. We are not making any claims that this initial release of alpha version software is fit for widespread use and that the data it currently produces reflects the eventual definition of the MEI NeoScribe schema. It is untested alpha software. A beta release will occur in the next 12 months or so, including documentation for the new NeoScribe schema for those happy to wait. While the original user base of Scribe was small, we anticipate the Scribe2NeoScribe tool will be beneficial to the owners of additional data encoded by musicologists who have used Scribe in the past, and perhaps to data curators who might wish to make old data once again useful and able to be read on modern computers. > > In the near future, we expect to be able to provide the MEI NeoScribe data for some 6000 pieces of music. Presently we are working towards ensuring that existing Scribe data is full encapsulated in NeoScribe and that some further extensions of mensural notation are incorporated to deal with the innovations of the late fourteenth century, including its multiplicities of note shapes. We are considering how this might be integrated with other projects like the SMuFL which now includes a comprehensive layer of glyphs for mensural notation. > > Good regards, > > Jason Stoessel > > -- > Dr Jason Stoessel > 2013-14 International Research Visitor (Oxford University) > Balzan Programme in Musicology > "Towards a Global History of Music" > -- > 2014 Associate Investigator > ARC Centre of Excellence for the History of Emotions > -- > Adjunct Research Fellow > School of Arts > Faculty of Arts and Sciences > University of New England > ARMIDALE NSW 2351 > jason.stoessel at une.edu.au > Skype ID: jjstoessel > FaceTime: jason.stoessel at gmail.com > UK Mobile: 07741 796 686 > Overseas Mobile: +37257 087 172 > > > _______________________________________________ > 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 18 01:42:27 2014 From: zupftom at googlemail.com (TW) Date: Fri, 18 Apr 2014 01:42:27 +0200 Subject: [MEI-L] mono:di 1.0 Message-ID: Dear MEI community, TL;DR summary: We invite you to launch Chrome or Firefox and try mono:di 1.0: https://monodi.corpus-monodicum.de/ Consult the Workflow section on the help page for a quick introduction. Most important to know: Music entry is highly keyboard centric and text has to be input before music. Long version: Thanks for taking the time ;-). I'd like to give a report on the state of mono:di[1], the transcription software of the Corpus monodicum project[2]. After some delays last year before we eventually were able to enter the test phase, it's successfully been in production use since the beginning of this year and has been used to input several thousand lines of transcriptions of neumatic notation. Corpus monodicum is an editorial project sponsored by the Akademie der Wissenschaften und der Literatur, Mainz[3], housed at the Institut f?r Musikforschung, Universit?t W?rzburg[4]. Corpus monodicum produces scholarly editions of the Latin-texted, medieval monophonic repertories?both sacred and secular?that form the historical foundation of European music, but have thus far been under-represented in musicological scholarship. Notengrafik Berlin[5] was commissioned to create an input tool that would - make inputting the special type of notation which was chosen for transcriptions much more efficient than with common notation software, - yield MEI data that could be used for typesetting the printed edition and - be suitable for building a digital edition. >From the start, we planned a multi-stage development process. In the first development phase we concentrated on implementing essential functionality allowing editors to input data efficiently that could be used for creating the first printed volumes. We're very pleased that editors indeed praise the efficiency of entry. Currently, the typesetting process is being prepared. We will use Score as a workbench for our purpose-built spacing and layout algorithms that are the result of an intensive and ambitious discussion on typographic detail between Corpus monodicum and Notengrafik Berlin. After typesetting the first volumes, we hope to enter the next development phase where we want to improve usability based on experience with mono:di 1.0, add some functionality, prepare for requirements of upcoming volumes covering other genres and improve the encoding scheme to make it more semantically accurate and less pragmatically rough-and-ready. We also want to improve code quality and, of course, eliminate remaining bugs and teething troubles. Although mono:di is tailored to the needs of Corpus monodicum, we invite everybody to try it[1]. To keep development effort spent on cross-browser issues low, mono:di only supports Chrome and Firefox browsers. Please consult the Workflow section of mono:di's help page for an introduction on how to use it. (An important point to notice is: In contrast to conventional notation software, text is input first and music is attached to the text, not the other way round.) We will not give user accounts to people outside the project, but thanks to modern web technology, mono:di can be used as an offline web app, storing your music in the browser's local storage. This was implemented for enabling editors to work with mono:di even when they do not have internet access, e.g. when working "in the field" where network connection might be unreliable or not available to them. We will be releasing the source code of mono:di under BSD conditions in a few weeks. Distribution of the transcriptions will initially be exclusive to the publisher of the printed volumes. Probably 2-3 years after each print publication, the MEI data of the respective volume will be released to the public in form of a digital edition. I'm intending to provide sample data soon, though. Please feel free to ask any questions about the project and the software, but I'll only be able to answer them in about 10 days. With the best wishes for Easter Thomas [1] https://monodi.corpus-monodicum.de/ [2] http://www.adwmainz.de/projekte/corpus-monodicum-die-einstimmige-musik-des-lateinischen-mittelalters-gattungen-werkbestaende-kontexte/ [3] http://www.adwmainz.de/ [4] http://www.musikwissenschaft.uni-wuerzburg.de/ [5] http://notengrafik.com/ From jason.stoessel at une.edu.au Fri Apr 18 03:59:04 2014 From: jason.stoessel at une.edu.au (Jason Stoessel) Date: Fri, 18 Apr 2014 11:59:04 +1000 Subject: [MEI-L] NeoScribe In-Reply-To: References: Message-ID: <12CD834B-6339-4BF4-909C-E5F13B2FB01E@une.edu.au> Dear Thomas, Many thanks for your note and for sharing your work on the Corpus monodicum project. I very interested to see your mono:di online tool - perhaps we should talk some more. It certainly would also be beneficial to look collectively at extensions to the Neumes module. We expect to have some sample files and a more developed ODD after your northern summer ? too much on my calendar until after then. We are also working towards a new instance of the Medieval Music Database which will feature searchable and downloadable MEI files, but these things take time. Say ?Hi? to David Catalunya at the Corpus monodicum project if you have the opportunity. Best wishes, Jason -- Dr Jason Stoessel 2013-14 International Research Visitor (Oxford University) Balzan Programme in Musicology "Towards a Global History of Music" -- 2014 Associate Investigator ARC Centre of Excellence for the History of Emotions -- Adjunct Research Fellow School of Arts Faculty of Arts and Sciences University of New England ARMIDALE NSW 2351 jason.stoessel at une.edu.au Skype ID: jjstoessel FaceTime: jason.stoessel at gmail.com UK Mobile: 07741 796 686 Overseas Mobile: +37257 087 172 On 16 Apr 2014, at 8:11 pm, TW wrote: > Dear Jason, > > it's great to hear about more active projects working with neumatic > notation and MEI. For the Corpus monodicum project[1] (lead by the > Universit?t W?rzburg and the Akademie der Wissenschaften Mainz), we > developed a transcription tool called mono:di[2] at Notengrafik > Berlin[3] that is based on the current MEI Neumes module created by > Stefan Morent. I'm intending to send a separate mail about this > software to MEI-L shortly. > > We, too, were about to create a modification of the Neumes module > which we'd like to use in the next version of our software. It will > be some time until we'll be starting work on this next version. This > has lead me to procrastinate discussing suggestions for how the Neumes > module could be modified (which I feel guilty about as I already > announced/promised this some time ago). > > Is it possible to access the encoded music from the La Trobe Medieval > Music Database? Also, is there a way of accessing the Scribe software > or at least some of its documentation? > > I'd love to see some sample of your MEI encoded chants. I'll ask > Corpus monodicum editors whether it's possible to share a sample of > our data as well, ideally with some facsimile (if legally possible). > > I'd suggest taking this opportunity and actually start a discussion > about how the Neumes module should evolve. To prevent any further > procrastination on my side, I'm setting myself May 7th as the date for > providing suggestions in the form of commented samples and/or an ODD. > > Looking forward to learning more about your work > Thomas Weber > > > [1] http://corpus-monodicum.de/ > [2] https://monodi.corpus-monodicum.de/ > [3] http://notengrafik.com/ > > > > 2014-04-14 7:38 GMT+02:00 Jason Stoessel : >> Dear MEI listers >> >> Please allow me to introduce myself. My name is Jason Stoessel. I hold a PhD in music, with a specialisation in late 14th/early 15th century music, music notation and musical cultures. I also have a keen interest in computer programming (undoubtedly full of bad habits as an autodidact), and once made a small living from it before pursuing my music research interests. You can find some of my research publications on academia.edu, and I maintain a blog at jjstoessel dot wordpress dot com (remove the ?dots? to obtain the correct URL). >> >> I would like to share briefly some work that John Stinson (director the La Trobe Medieval Music Database) and I have been doing to convert a large body of encoded music notation from Stinson?s proprietary Scribe program to a new MEI-compliant data schema that we call NeoScribe. Scribe was developed between 1984 and 1996 to encode every meaningful mark on a page of medieval music notation (mostly 14th century chant and mensural notation) and in many ways remains unparalleled in its capabilities. Despite its age and granted that it needs to be replaced with a more current user interface metaphor, Scribe still runs effectively on DOS Box. While MEI already has modules that partly support the encoding of chant notation and mensural music notation, we soon discovered that they were not sufficient for encapsulating the range of music notation data present in Scribe data files. A new module that extends the "Neume Notation" and "Mensural Notation" modules of MEI was required. One thing that encouraged us in this endeavour is the stated view of the MEI project team that MEI's modular nature invited researchers to add other modules that addressed their specific requirements. Stinson and I presented a paper at the Digital Humanities Australasia 2014 conference entitled "Towards an Open Access Standard for Encoded Medieval Music Notation: NeoScribeXML? which details some of our efforts to date. Further details can be found on my blog listed above. >> >> To date we have produced a command line tool for converting Scribe files to NeoScribe files. A copy of the open source code for this tool can be found on GitHub, http://github.com/jjstoessel/Scribe2NeoScribe. We are not making any claims that this initial release of alpha version software is fit for widespread use and that the data it currently produces reflects the eventual definition of the MEI NeoScribe schema. It is untested alpha software. A beta release will occur in the next 12 months or so, including documentation for the new NeoScribe schema for those happy to wait. While the original user base of Scribe was small, we anticipate the Scribe2NeoScribe tool will be beneficial to the owners of additional data encoded by musicologists who have used Scribe in the past, and perhaps to data curators who might wish to make old data once again useful and able to be read on modern computers. >> >> In the near future, we expect to be able to provide the MEI NeoScribe data for some 6000 pieces of music. Presently we are working towards ensuring that existing Scribe data is full encapsulated in NeoScribe and that some further extensions of mensural notation are incorporated to deal with the innovations of the late fourteenth century, including its multiplicities of note shapes. We are considering how this might be integrated with other projects like the SMuFL which now includes a comprehensive layer of glyphs for mensural notation. >> >> Good regards, >> >> Jason Stoessel >> >> -- >> Dr Jason Stoessel >> 2013-14 International Research Visitor (Oxford University) >> Balzan Programme in Musicology >> "Towards a Global History of Music" >> -- >> 2014 Associate Investigator >> ARC Centre of Excellence for the History of Emotions >> -- >> Adjunct Research Fellow >> School of Arts >> Faculty of Arts and Sciences >> University of New England >> ARMIDALE NSW 2351 >> jason.stoessel at une.edu.au >> Skype ID: jjstoessel >> FaceTime: jason.stoessel at gmail.com >> UK Mobile: 07741 796 686 >> Overseas Mobile: +37257 087 172 >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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 richard at rjlewis.me.uk Sat May 3 11:53:34 2014 From: richard at rjlewis.me.uk (Richard Lewis) Date: Sat, 03 May 2014 10:53:34 +0100 Subject: [MEI-L] Job: Digital humanities/musicology at Oxford e-Research Centre Message-ID: <87a9azp4rl.wl%richard@rjlewis.me.uk> JOB ADVERTISEMENT With apologies for cross posting. Research Associate - ElEPH?T and Transforming Musicology Oxford e-Research Centre, Oxford Grade 7: ?29,837 - ?36,661 p.a. http://www.transforming-musicology.org/news/2014-05-02_research-associate-elephat-and-transforming-musicology/ We are seeking a Research Associate which is a technical role working on Semantic Web and Linked Data technologies that support research in Digital Humanities, specifically for the ElEPH?T and Transforming Musicology projects. These projects share a need for identifying and semantically linking diverse digital resources (images of books OCR-ed text, digital audio, symbolic music representations etc.) and the digital methods and analysis performed over these resources by humanities researchers. The ElEPH?T project, a joint project between the Centre and the Bodleian Digital Libraries, will use Linked Data to create worksets combining digitised content from the large-scale (11 million+ volumes) HathiTrust collection and the fully human-transcribed EEBO-TCP (Early English Books Online - Text Creation Partnership) corpus. These worksets will form the basis for new scholarly investigations of these texts on a large scale and the insights that will emerge from such study. The AHRC funded Transforming Musicology project sets out to bring computational techniques, such as those developed in the Music Information Retrieval (MIR) community, to bear on the discipline of musicology as it evolves and adapts to a digital age. The University of Oxford e-Research Centre leads the creation of a semantic framework for the project which will describe these new digital methods, linking them to the results they produce and the music resources over which analysis has been undertaken, again using Semantic Web and Linked Data approaches, and tackling challenges such as reuse, reproducibility and citation of the methods and data. The closing date for applications is 12.00 noon on 21 May 2014. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis Computing, Goldsmiths' College t: +44 (0)20 7078 5203 @: lewisrichard http://www.transforming-musicology.org/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From kepper at edirom.de Tue May 6 21:18:40 2014 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 6 May 2014 21:18:40 +0200 Subject: [MEI-L] MEI organization Message-ID: <1D6BA401-9D12-41C3-B277-340EF9B6DFBE@edirom.de> Dear all, thanks to those that did respond to the strategy group's proposals. For those who didn't ? it's not too late, please give some feedback and help us to shape the future MEI. You can find the document with the proposals at https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing Since we're approaching the conference, I'd like to ask some questions. - All proposals don't make a statement about the current MEI Council. Was this an intentional decision? If I remember correctly, there was some concern about this group last year. I know that it won't be easy to find a solution for this one, but I think we should address it in one way or the other? - At first glance, it seems that the first proposal triggered most feedback. Would it be a correct observation that most in the community prefer this over the other two _in principle_, but still would like to clarify some details about it? Please don't get me wrong ? I don't want to get rid of the other two proposals, I just want to get a sense of where we are drifting. If you think my impression is wrong (which is perfectly possible), please disagree ? either here on MEI-L or in the document linked above. If you like the other proposals (or aspects of them), please speak up ? the sooner the better. Please remember that the google document gives the possibility of anonymous feedback, if you prefer. Thanks again for your interest and participation. Best, Johannes -------------- 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 bohl at edirom.de Thu May 8 17:01:15 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 08 May 2014 17:01:15 +0200 Subject: [MEI-L] MEI organization In-Reply-To: <1D6BA401-9D12-41C3-B277-340EF9B6DFBE@edirom.de> References: <1D6BA401-9D12-41C3-B277-340EF9B6DFBE@edirom.de> Message-ID: <536B9C3B.4080706@edirom.de> Dear Johannes, thanks for your questions, tah I'll answer below from my personal perspective: Am 06.05.2014 21:18, schrieb Johannes Kepper: > Dear all, > > thanks to those that did respond to the strategy group's proposals. For those who didn't -- it's not too late, please give some feedback and help us to shape the future MEI. You can find the document with the proposals at > > https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing > > Since we're approaching the conference, I'd like to ask some questions. > > - All proposals don't make a statement about the current MEI Council. Was this an intentional decision? If I remember correctly, there was some concern about this group last year. I know that it won't be easy to find a solution for this one, but I think we should address it in one way or the other... This is a great hint, I guess we just missed to articulate anything about this. From my part I always was assuming, that any new Board would replace the "current Council" but others might have another opinion?! > - At first glance, it seems that the first proposal triggered most feedback. Would it be a correct observation that most in the community prefer this over the other two _in principle_, but still would like to clarify some details about it? Please don't get me wrong -- I don't want to get rid of the other two proposals, I just want to get a sense of where we are drifting. If you think my impression is wrong (which is perfectly possible), please disagree -- either here on MEI-L or in the document linked above. If you like the other proposals (or aspects of them), please speak up -- the sooner the better. Please remember that the google document gives the possibility of anonymous feedback, if you prefer. Getting a feeling if general tendencies towards one of the proposals would be indeed very interesting! Nevertheless the comment frequency is not to be taken as general tendency towards one or the other... for example Raffaele shared a quite good argument for Model B over this list: > In general, I prefer Model B: it's lean and reflects well the size of > the community. It also keeps the focus on the Guidelines and releases, > which I agree with Sigfrid are the most important product of this > community. I feel model B will allows us to move forward without > having to jump through too many administrative hoops, while tasking > people with essential admin responsibilities. Maybe we should try come up with a general pros-and-cons list for each Model? Thanks, Benjamin > > > Thanks again for your interest and participation. > 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 HTML-Daten wurde abgetrennt... URL: From gdibacco at indiana.edu Thu May 8 21:27:07 2014 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Thu, 08 May 2014 15:27:07 -0400 Subject: [MEI-L] MEI organization In-Reply-To: <536B9C3B.4080706@edirom.de> References: <1D6BA401-9D12-41C3-B277-340EF9B6DFBE@edirom.de> <536B9C3B.4080706@edirom.de> Message-ID: <536BDA8B.6040705@indiana.edu> An HTML attachment was scrubbed... URL: From atge at kb.dk Fri May 9 10:03:17 2014 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 9 May 2014 08:03:17 +0000 Subject: [MEI-L] MEI organization In-Reply-To: <536BDA8B.6040705@indiana.edu> References: <1D6BA401-9D12-41C3-B277-340EF9B6DFBE@edirom.de> <536B9C3B.4080706@edirom.de> <536BDA8B.6040705@indiana.edu> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1011866AD48@EXCHANGE-02.kb.dk> Dear Johannes and others Thank you for bringing up the question about the current MEI council. I was one of those concerned about its future when we started this discussion last year, because I believe that it is the one of the most valuable resources we have both in terms of development and spreading the word. >From my perspective, all of the proposals imply splitting up the council in a smaller, elected group (the board) while making the rest simply members of the community or general assembly. In order not to lose the engagement and enthusiasm of the current council I think it is crucial to ensure in any future organizational model that the general assembly, which is open to all members, convenes regularly (say, once a year; most conveniently in combination with a conference). This may not have been sufficiently described in the proposals, but I actually think this should be formalized too to make sure the active members of the community get the chance to meet regularly. In my view, the general assembly substitutes the informal work of the current council, while the board takes over the council's formal and administrative functions. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Giuliano Di Bacco Sendt: 8. maj 2014 21:27 Til: Music Encoding Initiative Emne: Re: [MEI-L] MEI organization Also from my personal perspective: 1- I always assumed that the current Council would remain in place until the future Board is installed; 2- the conference is approaching, and I see this as a precious opportunity for both informal and formal discussion. So (at this point) I would wait until the end of it to draw any conclusion. Then the proposals could be fine-tuned and re-submitted for final discussion and approval to the list. As for Benjamin's excellent idea, we could attach a resum? of all pros/cons that people will have expressed so far (I am sure that those members of the Strat-group who will be in Charlottesville would be happy to collect more opinions--certainly I would). Best, Giuliano Benjamin Wolff Bohl wrote on 08/05/2014 11:01: Dear Johannes, thanks for your questions, tah I'll answer below from my personal perspective: Am 06.05.2014 21:18, schrieb Johannes Kepper: Dear all, thanks to those that did respond to the strategy group's proposals. For those who didn't - it's not too late, please give some feedback and help us to shape the future MEI. You can find the document with the proposals at https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing Since we're approaching the conference, I'd like to ask some questions. - All proposals don't make a statement about the current MEI Council. Was this an intentional decision? If I remember correctly, there was some concern about this group last year. I know that it won't be easy to find a solution for this one, but I think we should address it in one way or the other... This is a great hint, I guess we just missed to articulate anything about this. From my part I always was assuming, that any new Board would replace the "current Council" but others might have another opinion?! - At first glance, it seems that the first proposal triggered most feedback. Would it be a correct observation that most in the community prefer this over the other two _in principle_, but still would like to clarify some details about it? Please don't get me wrong - I don't want to get rid of the other two proposals, I just want to get a sense of where we are drifting. If you think my impression is wrong (which is perfectly possible), please disagree - either here on MEI-L or in the document linked above. If you like the other proposals (or aspects of them), please speak up - the sooner the better. Please remember that the google document gives the possibility of anonymous feedback, if you prefer. Getting a feeling if general tendencies towards one of the proposals would be indeed very interesting! Nevertheless the comment frequency is not to be taken as general tendency towards one or the other... for example Raffaele shared a quite good argument for Model B over this list: In general, I prefer Model B: it's lean and reflects well the size of the community. It also keeps the focus on the Guidelines and releases, which I agree with Sigfrid are the most important product of this community. I feel model B will allows us to move forward without having to jump through too many administrative hoops, while tasking people with essential admin responsibilities. Maybe we should try come up with a general pros-and-cons list for each Model? Thanks, Benjamin Thanks again for your interest and participation. Best, Johannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Fri May 9 10:36:43 2014 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 9 May 2014 10:36:43 +0200 Subject: [MEI-L] MEI organization In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D1011866AD48@EXCHANGE-02.kb.dk> References: <1D6BA401-9D12-41C3-B277-340EF9B6DFBE@edirom.de> <536B9C3B.4080706@edirom.de> <536BDA8B.6040705@indiana.edu> <0B6F63F59F405E4C902DFE2C2329D0D1011866AD48@EXCHANGE-02.kb.dk> Message-ID: Dear Axel, thanks for answering. Just to make sure I get it right: All you would like to see is one official meeting of the community per year, but not a separate organizational body with defined ways to enter or leave. This means we would remove the special status from all current council members[1], and just make them members of the General Assembly, which would be nothing more than the group of community members assembling at some venue. There would be no elections, no terms, no organizational requirements. Is this correct? If so, would it be ok for you to have a dedicated Music Encoding Conference only every other year, and a general assembly meeting at some other related venue in the years between? Personally, I'm not sure if we have sufficient oomph to run a full-blown conference every year[2], but it should be fairly easy to organize sessions at MLA, DH, TEI, IMS or other conferences. But of course, if there is sufficient interest in having (and hosting) annual conferences on our own, we can do that as well ;-) Best, Johannes [1] Of course they will always remain honored founding members of the Music Encoding Initiative :-) [2] What I would like to see, though, are more informal developer workshops every year. Do you think this would rule out parts of the community, even if these workshops would be open to anyone? Am 09.05.2014 um 10:03 schrieb Axel Teich Geertinger : > Dear Johannes and others > > Thank you for bringing up the question about the current MEI council. I was one of those concerned about its future when we started this discussion last year, because I believe that it is the one of the most valuable resources we have both in terms of development and spreading the word. > From my perspective, all of the proposals imply splitting up the council in a smaller, elected group (the board) while making the rest simply members of the community or general assembly. In order not to lose the engagement and enthusiasm of the current council I think it is crucial to ensure in any future organizational model that the general assembly, which is open to all members, convenes regularly (say, once a year; most conveniently in combination with a conference). This may not have been sufficiently described in the proposals, but I actually think this should be formalized too to make sure the active members of the community get the chance to meet regularly. In my view, the general assembly substitutes the informal work of the current council, while the board takes over the council?s formal and administrative functions. > > Best, Axel > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Giuliano Di Bacco > Sendt: 8. maj 2014 21:27 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] MEI organization > > > Also from my personal perspective: > 1- I always assumed that the current Council would remain in place until the future Board is installed; > 2- the conference is approaching, and I see this as a precious opportunity for both informal and formal discussion. So (at this point) I would wait until the end of it to draw any conclusion. Then the proposals could be fine-tuned and re-submitted for final discussion and approval to the list. As for Benjamin's excellent idea, we could attach a resum? of all pros/cons that people will have expressed so far (I am sure that those members of the Strat-group who will be in Charlottesville would be happy to collect more opinions--certainly I would). > Best, > Giuliano > > > Benjamin Wolff Bohl wrote on 08/05/2014 11:01: > Dear Johannes, > thanks for your questions, tah I'll answer below from my personal perspective: > > Am 06.05.2014 21:18, schrieb Johannes Kepper: > Dear all, > > thanks to those that did respond to the strategy group's proposals. For those who didn't ? it's not too late, please give some feedback and help us to shape the future MEI. You can find the document with the proposals at > > https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing > > Since we're approaching the conference, I'd like to ask some questions. > > - All proposals don't make a statement about the current MEI Council. Was this an intentional decision? If I remember correctly, there was some concern about this group last year. I know that it won't be easy to find a solution for this one, but I think we should address it in one way or the other? > > This is a great hint, I guess we just missed to articulate anything about this. From my part I always was assuming, that any new Board would replace the "current Council" but others might have another opinion?! > > > - At first glance, it seems that the first proposal triggered most feedback. Would it be a correct observation that most in the community prefer this over the other two _in principle_, but still would like to clarify some details about it? Please don't get me wrong ? I don't want to get rid of the other two proposals, I just want to get a sense of where we are drifting. If you think my impression is wrong (which is perfectly possible), please disagree ? either here on MEI-L or in the document linked above. If you like the other proposals (or aspects of them), please speak up ? the sooner the better. Please remember that the google document gives the possibility of anonymous feedback, if you prefer. > > Getting a feeling if general tendencies towards one of the proposals would be indeed very interesting! Nevertheless the comment frequency is not to be taken as general tendency towards one or the other... for example Raffaele shared a quite good argument for Model B over this list: > > > In general, I prefer Model B: it's lean and reflects well the size of the community. It also keeps the focus on the Guidelines and releases, which I agree with Sigfrid are the most important product of this community. I feel model B will allows us to move forward without having to jump through too many administrative hoops, while tasking people with essential admin responsibilities. > > Maybe we should try come up with a general pros-and-cons list for each Model? > > > Thanks, > Benjamin > > > > > Thanks again for your interest and participation. > 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 : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From atge at kb.dk Fri May 9 10:55:48 2014 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 9 May 2014 08:55:48 +0000 Subject: [MEI-L] MEI organization In-Reply-To: References: <1D6BA401-9D12-41C3-B277-340EF9B6DFBE@edirom.de> <536B9C3B.4080706@edirom.de> <536BDA8B.6040705@indiana.edu> <0B6F63F59F405E4C902DFE2C2329D0D1011866AD48@EXCHANGE-02.kb.dk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1011866AE24@EXCHANGE-02.kb.dk> Hi Johannes One of the things I like about the current council is its relative openness to new members, but of course this is possible only within certain limits as long as the council is also the body responsible for the formal part of the organization. So I think it would be the logical consequence to have this entirely open general assembly to substitute the ever-growing council, which quickly will become too large to work efficiently as the executive board while on the other hand being too limited to accommodate everyone who wants to contribute somehow or participate in the discussions. So yes, as long as the meetings of the general assembly are actively facilitated by the board, I see no need for another organizational body in between the board and the community. I am aware that a dedicated conference every year is not realistic, so of course the annual gathering could be connected to other events. Workshops etc. are also terrific opportunities. Surely we have to be pragmatic in that respect; also, limiting the travels involved by combining events wouldn't hurt. This way, perhaps it would even be possible to have more than one annual MEI-community-related event, some of which may very well have a more local focus. And of course they wouldn't even have to be "official" MEI events organized by the board. I am thinking of events such as your excellent Edirom Summer School :-) Best, Axel -----Oprindelig meddelelse----- Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Johannes Kepper Sendt: 9. maj 2014 10:37 Til: Music Encoding Initiative Emne: Re: [MEI-L] MEI organization Dear Axel, thanks for answering. Just to make sure I get it right: All you would like to see is one official meeting of the community per year, but not a separate organizational body with defined ways to enter or leave. This means we would remove the special status from all current council members[1], and just make them members of the General Assembly, which would be nothing more than the group of community members assembling at some venue. There would be no elections, no terms, no organizational requirements. Is this correct? If so, would it be ok for you to have a dedicated Music Encoding Conference only every other year, and a general assembly meeting at some other related venue in the years between? Personally, I'm not sure if we have sufficient oomph to run a full-blown conference every year[2], but it should be fairly easy to organize sessions at MLA, DH, TEI, IMS or other conferences. But of course, if there is sufficient interest in having (and hosting) annual conferences on our own, we can do that as well ;-) Best, Johannes [1] Of course they will always remain honored founding members of the Music Encoding Initiative :-) [2] What I would like to see, though, are more informal developer workshops every year. Do you think this would rule out parts of the community, even if these workshops would be open to anyone? Am 09.05.2014 um 10:03 schrieb Axel Teich Geertinger : > Dear Johannes and others > > Thank you for bringing up the question about the current MEI council. I was one of those concerned about its future when we started this discussion last year, because I believe that it is the one of the most valuable resources we have both in terms of development and spreading the word. > From my perspective, all of the proposals imply splitting up the council in a smaller, elected group (the board) while making the rest simply members of the community or general assembly. In order not to lose the engagement and enthusiasm of the current council I think it is crucial to ensure in any future organizational model that the general assembly, which is open to all members, convenes regularly (say, once a year; most conveniently in combination with a conference). This may not have been sufficiently described in the proposals, but I actually think this should be formalized too to make sure the active members of the community get the chance to meet regularly. In my view, the general assembly substitutes the informal work of the current council, while the board takes over the council's formal and administrative functions. > > Best, Axel > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > Giuliano Di Bacco > Sendt: 8. maj 2014 21:27 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] MEI organization > > > Also from my personal perspective: > 1- I always assumed that the current Council would remain in place > until the future Board is installed; > 2- the conference is approaching, and I see this as a precious opportunity for both informal and formal discussion. So (at this point) I would wait until the end of it to draw any conclusion. Then the proposals could be fine-tuned and re-submitted for final discussion and approval to the list. As for Benjamin's excellent idea, we could attach a resum? of all pros/cons that people will have expressed so far (I am sure that those members of the Strat-group who will be in Charlottesville would be happy to collect more opinions--certainly I would). > Best, > Giuliano > > > Benjamin Wolff Bohl wrote on 08/05/2014 11:01: > Dear Johannes, > thanks for your questions, tah I'll answer below from my personal perspective: > > Am 06.05.2014 21:18, schrieb Johannes Kepper: > Dear all, > > thanks to those that did respond to the strategy group's proposals. > For those who didn't - it's not too late, please give some feedback > and help us to shape the future MEI. You can find the document with > the proposals at > > https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmt > CSUfqzeQs/edit?usp=sharing > > Since we're approaching the conference, I'd like to ask some questions. > > - All proposals don't make a statement about the current MEI Council. > Was this an intentional decision? If I remember correctly, there was > some concern about this group last year. I know that it won't be easy > to find a solution for this one, but I think we should address it in > one way or the other. > > This is a great hint, I guess we just missed to articulate anything about this. From my part I always was assuming, that any new Board would replace the "current Council" but others might have another opinion?! > > > - At first glance, it seems that the first proposal triggered most feedback. Would it be a correct observation that most in the community prefer this over the other two _in principle_, but still would like to clarify some details about it? Please don't get me wrong - I don't want to get rid of the other two proposals, I just want to get a sense of where we are drifting. If you think my impression is wrong (which is perfectly possible), please disagree - either here on MEI-L or in the document linked above. If you like the other proposals (or aspects of them), please speak up - the sooner the better. Please remember that the google document gives the possibility of anonymous feedback, if you prefer. > > Getting a feeling if general tendencies towards one of the proposals would be indeed very interesting! Nevertheless the comment frequency is not to be taken as general tendency towards one or the other... for example Raffaele shared a quite good argument for Model B over this list: > > > In general, I prefer Model B: it's lean and reflects well the size of the community. It also keeps the focus on the Guidelines and releases, which I agree with Sigfrid are the most important product of this community. I feel model B will allows us to move forward without having to jump through too many administrative hoops, while tasking people with essential admin responsibilities. > > Maybe we should try come up with a general pros-and-cons list for each Model? > > > Thanks, > Benjamin > > > > > Thanks again for your interest and participation. > 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 Fri May 9 11:11:05 2014 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 9 May 2014 11:11:05 +0200 Subject: [MEI-L] MEI organization In-Reply-To: <536BDA8B.6040705@indiana.edu> References: <1D6BA401-9D12-41C3-B277-340EF9B6DFBE@edirom.de> <536B9C3B.4080706@edirom.de> <536BDA8B.6040705@indiana.edu> Message-ID: Hi Giuliano, we're all speaking just for ourselves in this discussion, and I think it's crucial that everyone actually gets, but also feels like he has the same say on this. I also don't want to rush things. If we need the time to discuss, we take the time to discuss. I'm very happy that we entered another round of discussion at this time. I share your argument that the conference is a precious opportunity for discussion. However, I also think it would be a brilliant opportunity to come to conclusions. There is this momentum of a personal meeting, and we all know that after such an event, risk is great that nothing more will happen for the next few weeks. Therefore, I would love to reach some sort of consensus by the end of the conference. As this is probably the most severe decision that the MEI community ever had to make, I would really love to reach a consensus, and not a vote, which always results in someone having lost. Of course this requires everyone interested in the problem to speak up timely, but if someone doesn't share his opinion with the community, this is some kind of statement as well, I think. As I said, I'm not trying to rush things, I'm just curious about the direction we're taking. In my ideal (other say naive) world, we enter the conference with more or less one proposal (which may be a combination of the three we have right now), so that we can use the conference to talk out the important details (e.g. four seats vs. six seats). I don't think we need to come up with final "MEI community bylaws" (this is something the future Board (or whatever it will be called) can work out in greater detail), but we should try to agree on the cornerstones, I think. This won't be easy, especially since we need to make sure that people not in C'ville will get opportunities to participate in the discussion as well, but otherwise I see the risk of having an eternal discussion with virtually no clear end. I'm fine with giving everyone an opportunity to think over what we will have discussed in C'ville for another week or two. Since the current proposals include elections, it is obvious that we don't vote at the time of the conference anyway. But still, we should have a draft at the end of the conference that clearly describes the most important aspects at least. Otherwise, we will discuss about apples and peaches for a very long time? As I said earlier, this is just my personal view, and I absolutely agree that we have to discuss this properly. If our discussions take more time, I'm more than happy if we just take that time. However, I know that some people in this community (including myself) are most efficient when working against a deadline. I'm just afraid that we allow ourselves more time for discussion, which we don't use actively afterwards. The schedule above is nothing more than a proposal, and I see no harm in being late on it ? as long as we're actively working. It seems desirable to me to have an official MEI body that has the authority to decide about future conferences etc. rather sooner than later? Again, just my personal two cents, Johannes Am 08.05.2014 um 21:27 schrieb Giuliano Di Bacco : > > Also from my personal perspective: > 1- I always assumed that the current Council would remain in place until the future Board is installed; > 2- the conference is approaching, and I see this as a precious opportunity for both informal and formal discussion. So (at this point) I would wait until the end of it to draw any conclusion. Then the proposals could be fine-tuned and re-submitted for final discussion and approval to the list. As for Benjamin's excellent idea, we could attach a resum? of all pros/cons that people will have expressed so far (I am sure that those members of the Strat-group who will be in Charlottesville would be happy to collect more opinions--certainly I would). > Best, > Giuliano > > > Benjamin Wolff Bohl wrote on 08/05/2014 11:01: >> Dear Johannes, >> thanks for your questions, tah I'll answer below from my personal perspective: >> >> Am 06.05.2014 21:18, schrieb Johannes Kepper: >>> Dear all, >>> >>> thanks to those that did respond to the strategy group's proposals. For those who didn't ? it's not too late, please give some feedback and help us to shape the future MEI. You can find the document with the proposals at >>> >>> >>> https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing >>> >>> >>> Since we're approaching the conference, I'd like to ask some questions. >>> >>> - All proposals don't make a statement about the current MEI Council. Was this an intentional decision? If I remember correctly, there was some concern about this group last year. I know that it won't be easy to find a solution for this one, but I think we should address it in one way or the other? >>> >> >> This is a great hint, I guess we just missed to articulate anything about this. From my part I always was assuming, that any new Board would replace the "current Council" but others might have another opinion?! >> >>> - At first glance, it seems that the first proposal triggered most feedback. Would it be a correct observation that most in the community prefer this over the other two _in principle_, but still would like to clarify some details about it? Please don't get me wrong ? I don't want to get rid of the other two proposals, I just want to get a sense of where we are drifting. If you think my impression is wrong (which is perfectly possible), please disagree ? either here on MEI-L or in the document linked above. If you like the other proposals (or aspects of them), please speak up ? the sooner the better. Please remember that the google document gives the possibility of anonymous feedback, if you prefer. >> >> Getting a feeling if general tendencies towards one of the proposals would be indeed very interesting! Nevertheless the comment frequency is not to be taken as general tendency towards one or the other... for example Raffaele shared a quite good argument for Model B over this list: >> >>> In general, I prefer Model B: it's lean and reflects well the size of the community. It also keeps the focus on the Guidelines and releases, which I agree with Sigfrid are the most important product of this community. I feel model B will allows us to move forward without having to jump through too many administrative hoops, while tasking people with essential admin responsibilities. >> >> Maybe we should try come up with a general pros-and-cons list for each Model? >> >> >> Thanks, >> Benjamin >> >>> >>> Thanks again for your interest and participation. >>> 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 : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From rfreedma at haverford.edu Fri May 9 15:16:06 2014 From: rfreedma at haverford.edu (Richard Freedman) Date: Fri, 9 May 2014 09:16:06 -0400 Subject: [MEI-L] MEI organization In-Reply-To: <536BDA8B.6040705@indiana.edu> References: <1D6BA401-9D12-41C3-B277-340EF9B6DFBE@edirom.de> <536B9C3B.4080706@edirom.de> <536BDA8B.6040705@indiana.edu> Message-ID: I've looked over the various models proposed on the share document. I think that the "A" model looks to be the most likely to succeed. The Board cannot be too large (as others have noted), or it will not be nimble enough to act upon recommendations that emerge from the various Interest Groups and other ways we have of expressing our views on the project. Two things that are still unclear to me: 1. What reporting system to we imagine from the Board to the membership at large? We note that Interest Groups ought to send their own reports and suggestions to the Board in advance of meetings. What system will we have in place for the Board to offer public reactions to these proposals, or otherwise maintain an archive of near- and long-term projects or policies? 2. How will we in practice elect the at large Board members? By some process of nomination, followed by elections? In my experience, groups need some process of assembling a relatively small list of candidates from who to choose (assuming we want some sort of majority-wins voting). For example: we have a first round of nominations in search of 3 or 4 candidates for each position to be filled. Then we hold instant-run-off elections to select the winners from this short list. (Perhaps this is too early for such detail, but it's worth thinking ahead to what the process might look like, since achieving the sorts of representation we eventually decide upon will in turn depend upon having the right process through which candidates are proposed and elected.) Richard how would we conduct these elections in the case of the at large membership of the board? On Thu, May 8, 2014 at 3:27 PM, Giuliano Di Bacco wrote: > > Also from my personal perspective: > 1- I always assumed that the current Council would remain in place until > the future Board is installed; > 2- the conference is approaching, and I see this as a precious opportunity > for both informal and formal discussion. So (at this point) I would wait > until the end of it to draw any conclusion. Then the proposals could be > fine-tuned and re-submitted for final discussion and approval to the list. > As for Benjamin's excellent idea, we could attach a resum? of all pros/cons > that people will have expressed so far (I am sure that those members of the > Strat-group who will be in Charlottesville would be happy to collect more > opinions--certainly I would). > Best, > Giuliano > > > Benjamin Wolff Bohl wrote on 08/05/2014 11:01: > > Dear Johannes, > thanks for your questions, tah I'll answer below from my personal > perspective: > > Am 06.05.2014 21:18, schrieb Johannes Kepper: > > Dear all, > > thanks to those that did respond to the strategy group's proposals. For those who didn't ? it's not too late, please give some feedback and help us to shape the future MEI. You can find the document with the proposals at > https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing > > Since we're approaching the conference, I'd like to ask some questions. > > - All proposals don't make a statement about the current MEI Council. Was this an intentional decision? If I remember correctly, there was some concern about this group last year. I know that it won't be easy to find a solution for this one, but I think we should address it in one way or the other? > > > This is a great hint, I guess we just missed to articulate anything about > this. From my part I always was assuming, that any new Board would replace > the "current Council" but others might have another opinion?! > > - At first glance, it seems that the first proposal triggered most feedback. Would it be a correct observation that most in the community prefer this over the other two _in principle_, but still would like to clarify some details about it? Please don't get me wrong ? I don't want to get rid of the other two proposals, I just want to get a sense of where we are drifting. If you think my impression is wrong (which is perfectly possible), please disagree ? either here on MEI-L or in the document linked above. If you like the other proposals (or aspects of them), please speak up ? the sooner the better. Please remember that the google document gives the possibility of anonymous feedback, if you prefer. > > > Getting a feeling if general tendencies towards one of the proposals would > be indeed very interesting! Nevertheless the comment frequency is not to be > taken as general tendency towards one or the other... for example Raffaele > shared a quite good argument for Model B over this list: > > In general, I prefer Model B: it's lean and reflects well the size of the > community. It also keeps the focus on the Guidelines and releases, which I > agree with Sigfrid are the most important product of this community. I feel > model B will allows us to move forward without having to jump through too > many administrative hoops, while tasking people with essential admin > responsibilities. > > > Maybe we should try come up with a general pros-and-cons list for each > Model? > > > Thanks, > Benjamin > > > Thanks again for your interest and participation. > Best, > Johannes > > > > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -- Richard Freedman John C. Whitehead Professor of Music Haverford College Haverford, PA 19041 610-896-1007 610-896-4902 (fax) http://www.haverford.edu/faculty/rfreedma -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at rjlewis.me.uk Tue May 13 14:14:24 2014 From: richard at rjlewis.me.uk (Richard Lewis) Date: Tue, 13 May 2014 13:14:24 +0100 Subject: [MEI-L] Linking to Message-ID: <87fvkddgf3.wl%richard@rjlewis.me.uk> Hi there, We're working on encoding some lute tablature and, as well as some lute-specific things we need to deal with, we've actually got stuck with a more general question of how to associate instruments with staffs. If we have some s in an (in in a in the header), how can I indicate that a particular is the line played by one of those s? I know I can add a @label attribute, but I'd prefer to have something that's actually an IDREF. For now, we're looking at putting an @instrID attribute on the itself. Any thoughts? Richard -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis j: ironchicken at jabber.earth.li @: lewisrichard http://www.richardlewis.me.uk/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From kepper at edirom.de Tue May 13 14:17:41 2014 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 13 May 2014 14:17:41 +0200 Subject: [MEI-L] Linking to In-Reply-To: <87fvkddgf3.wl%richard@rjlewis.me.uk> References: <87fvkddgf3.wl%richard@rjlewis.me.uk> Message-ID: Hi Richard, @decls from body to header @data from header to body (but for an unknown reason not available of instrVoice) (sorry for the brief answer) jo Am 13.05.2014 um 14:14 schrieb Richard Lewis : > Hi there, > > We're working on encoding some lute tablature and, as well as some > lute-specific things we need to deal with, we've actually got stuck > with a more general question of how to associate instruments with > staffs. > > If we have some s in an (in > in a in the header), how can I indicate that a particular > is the line played by one of those s? I know I can > add a @label attribute, but I'd prefer to have something that's > actually an IDREF. > > For now, we're looking at putting an @instrID attribute on the > itself. Any thoughts? > > Richard > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Richard Lewis > j: ironchicken at jabber.earth.li > @: lewisrichard > http://www.richardlewis.me.uk/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- 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 richard at rjlewis.me.uk Tue May 13 15:08:04 2014 From: richard at rjlewis.me.uk (Richard Lewis) Date: Tue, 13 May 2014 14:08:04 +0100 Subject: [MEI-L] Linking to In-Reply-To: References: <87fvkddgf3.wl%richard@rjlewis.me.uk> Message-ID: <87egzxddxn.wl%richard@rjlewis.me.uk> Hi Johannes, Oh yes, that makes sense. We don't actually need the header -> body linkage for this, but I suppose it would be good to have @data available on in future. Thanks, Richard At Tue, 13 May 2014 14:17:41 +0200, Johannes Kepper wrote: > Hi Richard, > > @decls from body to header > @data from header to body (but for an unknown reason not available of instrVoice) > > (sorry for the brief answer) > jo > > Am 13.05.2014 um 14:14 schrieb Richard Lewis : > > > Hi there, > > > > We're working on encoding some lute tablature and, as well as some > > lute-specific things we need to deal with, we've actually got stuck > > with a more general question of how to associate instruments with > > staffs. > > > > If we have some s in an (in > > in a in the header), how can I indicate that a particular > > is the line played by one of those s? I know I can > > add a @label attribute, but I'd prefer to have something that's > > actually an IDREF. > > > > For now, we're looking at putting an @instrID attribute on the > > itself. Any thoughts? > > > > Richard -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis j: ironchicken at jabber.earth.li @: lewisrichard http://www.richardlewis.me.uk/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From bohl at edirom.de Wed May 14 14:17:59 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Wed, 14 May 2014 14:17:59 +0200 Subject: [MEI-L] MEI organization In-Reply-To: References: <1D6BA401-9D12-41C3-B277-340EF9B6DFBE@edirom.de> <536B9C3B.4080706@edirom.de> <536BDA8B.6040705@indiana.edu> Message-ID: <53735EF7.2050609@edirom.de> Dear all, many thanks for the lively discussion! Please excuse my late answer, as preparations for MusEC2014 keep me quite busy. BTW: there will be a "_blank" poster on MusEC2014 for developing and discussing ideas, I'd be happy to meet any of you there ;-) Sorry this is quite long but splitting into several mails would not have eased the discussion I guess... feel free to state on single passages. 1.) Reporting System of the Board @Richard: Thanks for bringing up this very crucial issue. According to the white paper the Board should have regular meetings every three months, publish an agenda online prior to the meeting and minutes in a timely manner afterwards. Is there anything to add to this for proper transparency? Maybe the publication should not simply be made somewhere online, but on music-encoding.org and announced via MEI-L! 2.) Electoral Process @Richard: thanks again! This indeed is a very important (also concerning all other organizational decisions), as selecting one or the other electoral process might have great impact on individual chances. Having a first deadline for entering nominations seems plausible as otherwise we would have to rank the whole community :-P As far as I'm concerned I'd welcome the option of self-nomination, as this gives room for personal commitment. When a closed list of candidates is available a voting should take place. Concerning the fact, that anybody on MEI-L would have the right to vote there should be no minimum voter turnout, as this could immobilise MEI. Andrew suggested a ranked ballot voting in a comment in the white paper and I supported this idea. This is quite similar to Richards suggested "instant runoff". Essentially each voter will rank any number of candidates on his ballot, the one(s) with the fewest first-place-votes will be eliminated, and their votes will be redistributed according to the respective second-place-votes on the ballots; this process will be reiterated until the number of candidates matches the number of places. For details see: http://en.wikipedia.org/wiki/Instant-runoff_voting and: https://opavote.appspot.com/results/100002/0 3.) Bylaws We should definitely work out proper bylaws. Some time ago Perry provided me with a nice example from the Forum for Classics, Libraries, and Scholarly Communication (http://www.classicslibrarians.org/about/bylaws/). These are quite compact and could serve as a first starting point for MEI bylaws. MEI Strategy Development Group may certainly help in drafting these bylaws but in the end someone will have to accept them / pass them / vote for them I guess? 4.) Current Council and General Assembly I think I agree with everything that has been said concerning the Current Council and the idea of a General Assembly that has been said in this thread so far. Just to sum up: - The Current Council remains in place as long as the new organizational structures have not been implemented! - After implementing and populating the new Board (e.g. by elections) the Current Council will be dissolved, as participation of former Council Members can take place in the General Assembly. - The General Assembly will be held yearly (be it in connection with a specific MEI conference or in connection with other potentially interesting events/conferences, e.g. as pre-conference) 5.) Implementation procedure As decided last year the Current Council is still in place and we implemented the "Interim Steering Group" (Group A) with Perry Roland, Johannes Kepper, and Gabriele Buschmeier (and Kurt G?rtner) to (amongst others) negotiate the formal collaboration possibilities with the Mainz Academy. MEI Strategy Development Group (Group B) was to elaborate some proposals. If we as community now develop our ideas of a proper form of organizing ourselves I think: first: MEI Strategy Group should update the current porposals to match all the feedback second: call for another round of feedback while all the above groups try to elaborate a first draft of bylaws third: publish first draft of bylaws fourth: Group A & B call for nominations, conduct elections fifth: convene the elected members to the Working Group Music Encoding at the Mainz Academy and dissolve Group A, Group B, and the Current Council seventh: call for Interest Groups eighth: MEI as much as you can ;-) Somewhere in this process the first draft of bylaws might be checked against national law of different countries? Bes 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 09.05.2014 15:16, schrieb Richard Freedman: > I've looked over the various models proposed on the share document. I > think that the "A" model looks to be the most likely to succeed. The > Board cannot be too large (as others have noted), or it will not be > nimble enough to act upon recommendations that emerge from the various > Interest Groups and other ways we have of expressing our views on the > project. > > Two things that are still unclear to me: > > 1. What reporting system to we imagine from the Board to the > membership at large? We note that Interest Groups ought to send their > own reports and suggestions to the Board in advance of meetings. What > system will we have in place for the Board to offer public reactions > to these proposals, or otherwise maintain an archive of near- and > long-term projects or policies? > > 2. How will we in practice elect the at large Board members? By some > process of nomination, followed by elections? In my experience, > groups need some process of assembling a relatively small list of > candidates from who to choose (assuming we want some sort of > majority-wins voting). For example: we have a first round of > nominations in search of 3 or 4 candidates for each position to be > filled. Then we hold instant-run-off elections to select the winners > from this short list. (Perhaps this is too early for such detail, but > it's worth thinking ahead to what the process might look like, since > achieving the sorts of representation we eventually decide upon will > in turn depend upon having the right process through which candidates > are proposed and elected.) > > Richard > > how would we conduct these elections in the case of the at large > membership of the board? > > > On Thu, May 8, 2014 at 3:27 PM, Giuliano Di Bacco > > wrote: > > > Also from my personal perspective: > 1- I always assumed that the current Council would remain in place > until the future Board is installed; > 2- the conference is approaching, and I see this as a precious > opportunity for both informal and formal discussion. So (at this > point) I would wait until the end of it to draw any conclusion. > Then the proposals could be fine-tuned and re-submitted for final > discussion and approval to the list. As for Benjamin's excellent > idea, we could attach a resum? of all pros/cons that people will > have expressed so far (I am sure that those members of the > Strat-group who will be in Charlottesville would be happy to > collect more opinions--certainly I would). > Best, > Giuliano > > > Benjamin Wolff Bohl wrote on 08/05/2014 11:01: >> Dear Johannes, >> thanks for your questions, tah I'll answer below from my personal >> perspective: >> >> Am 06.05.2014 21:18, schrieb Johannes Kepper: >>> Dear all, >>> >>> thanks to those that did respond to the strategy group's proposals. For those who didn't -- it's not too late, please give some feedback and help us to shape the future MEI. You can find the document with the proposals at >>> >>> https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing >>> >>> Since we're approaching the conference, I'd like to ask some questions. >>> >>> - All proposals don't make a statement about the current MEI Council. Was this an intentional decision? If I remember correctly, there was some concern about this group last year. I know that it won't be easy to find a solution for this one, but I think we should address it in one way or the other... >> >> This is a great hint, I guess we just missed to articulate >> anything about this. From my part I always was assuming, that any >> new Board would replace the "current Council" but others might >> have another opinion?! >> >>> - At first glance, it seems that the first proposal triggered most feedback. Would it be a correct observation that most in the community prefer this over the other two _in principle_, but still would like to clarify some details about it? Please don't get me wrong -- I don't want to get rid of the other two proposals, I just want to get a sense of where we are drifting. If you think my impression is wrong (which is perfectly possible), please disagree -- either here on MEI-L or in the document linked above. If you like the other proposals (or aspects of them), please speak up -- the sooner the better. Please remember that the google document gives the possibility of anonymous feedback, if you prefer. >> >> Getting a feeling if general tendencies towards one of the >> proposals would be indeed very interesting! Nevertheless the >> comment frequency is not to be taken as general tendency towards >> one or the other... for example Raffaele shared a quite good >> argument for Model B over this list: >> >>> In general, I prefer Model B: it's lean and reflects well the >>> size of the community. It also keeps the focus on the Guidelines >>> and releases, which I agree with Sigfrid are the most important >>> product of this community. I feel model B will allows us to move >>> forward without having to jump through too many administrative >>> hoops, while tasking people with essential admin responsibilities. >> >> Maybe we should try come up with a general pros-and-cons list for >> each Model? >> >> >> Thanks, >> Benjamin >> >>> Thanks again for your interest and participation. >>> Best, >>> Johannes >>> >>> > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > > -- > Richard Freedman > John C. Whitehead Professor of Music > Haverford College > Haverford, PA 19041 > > 610-896-1007 > 610-896-4902 (fax) > > http://www.haverford.edu/faculty/rfreedma > > > _______________________________________________ > 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 stadler at edirom.de Wed May 14 20:16:26 2014 From: stadler at edirom.de (Peter Stadler) Date: Wed, 14 May 2014 20:16:26 +0200 Subject: [MEI-L] NEH/DFG Bilateral Digital Humanities Program Message-ID: Dear all, you?ve probably seen this already but just in case you missed it: en: http://www.neh.gov/grants/odh/nehdfg-bilateral-digital-humanities-program de: http://www.dfg.de/foerderung/info_wissenschaft/info_wissenschaft_14_20/index.html 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 zolaemil at gmail.com Thu May 15 20:35:35 2014 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Thu, 15 May 2014 19:35:35 +0100 Subject: [MEI-L] Duplicated constraint ids Message-ID: Hi All, I'm having problem with validating against the current release http://music-encoding.googlecode.com/svn/tags/MEI2013_v2.1.0/schemata/mei-CMN.rng in Oxygen 15.2 It finds two duplicated schematron constraint ids: "clef-constraint-Check_clef_position_clef" and "staffDef-constraint-Check_tab_strings". Anyone encountered this before? I cannot find bug report relating to these ids, shall I file one? Best Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Thu May 15 21:57:11 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 15 May 2014 19:57:11 +0000 Subject: [MEI-L] Duplicated constraint ids In-Reply-To: References: Message-ID: Actually, issue #191 addresses these problems. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kom?ves Zolt?n Sent: Thursday, May 15, 2014 2:36 PM To: Music Encoding Initiative Subject: [MEI-L] Duplicated constraint ids Hi All, I'm having problem with validating against the current release http://music-encoding.googlecode.com/svn/tags/MEI2013_v2.1.0/schemata/mei-CMN.rng in Oxygen 15.2 It finds two duplicated schematron constraint ids: "clef-constraint-Check_clef_position_clef" and "staffDef-constraint-Check_tab_strings". Anyone encountered this before? I cannot find bug report relating to these ids, shall I file one? Best Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hankinson at mail.mcgill.ca Fri May 16 02:02:12 2014 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 16 May 2014 00:02:12 +0000 Subject: [MEI-L] Duplicated constraint ids In-Reply-To: <4648_1400183902_53751C5E_4648_128_1_BBCC497C40D85642B90E9F94FC30343D7004DDE2@grant1.eservices.virginia.edu> References: <4648_1400183902_53751C5E_4648_128_1_BBCC497C40D85642B90E9F94FC30343D7004DDE2@grant1.eservices.virginia.edu> Message-ID: It also looks like commits #1198 and #1199 fix this issue in the repository. On May 15, 2014, at 3:57 PM, Roland, Perry D. (pdr4h) > wrote: Actually, issue #191 addresses these problems. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kom?ves Zolt?n Sent: Thursday, May 15, 2014 2:36 PM To: Music Encoding Initiative Subject: [MEI-L] Duplicated constraint ids Hi All, I'm having problem with validating against the current release http://music-encoding.googlecode.com/svn/tags/MEI2013_v2.1.0/schemata/mei-CMN.rng in Oxygen 15.2 It finds two duplicated schematron constraint ids: "clef-constraint-Check_clef_position_clef" and "staffDef-constraint-Check_tab_strings". Anyone encountered this before? I cannot find bug report relating to these ids, shall I file one? 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 K.McAulay at rcs.ac.uk Tue May 20 13:46:15 2014 From: K.McAulay at rcs.ac.uk (Karen McAulay) Date: Tue, 20 May 2014 11:46:15 +0000 Subject: [MEI-L] Query about Chapter 22 Text in MEI Message-ID: Hello, I am your newest list member, so please excuse a very ignorant question! I'm reading about attributes, in 1.1.1 online, and there's a hyperlink to Chapter 22 Text in MEI. (I'm interested in the treatment of prefatory and back elements). However, the link brings up the following error message:- Please excuse, but the resource you're looking for is not available in MEI2013. You're looking for /apps/mei/guidelines/2013/.xml Does this mean the chapter does not exist yet, or has it been moved elsewhere? Very many thanks Karen McAulay Dr. Karen McAulay Music and Academic Services Librarian +44 (0)141 270 8267 (direct) K.McAulay at rcs.ac.uk What's On Feb 14 - June 14 Prospectus Short Courses Prospectus 2013/14 Summer Schools [cid:image001.jpg at 01CF7429.540C3100] [cid:image002.gif at 01CF7429.540C3100] Follow us on Facebook [cid:image003.gif at 01CF7429.540C3100] Follow us on Twitter [cid:image004.jpg at 01CF7429.540C3100] Broadcast - Explore our digital hub -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6657 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1280 bytes Desc: image002.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 1279 bytes Desc: image003.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 18237 bytes Desc: image004.jpg URL: From raffaeleviglianti at gmail.com Tue May 20 16:46:12 2014 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 20 May 2014 10:46:12 -0400 Subject: [MEI-L] Query about Chapter 22 Text in MEI In-Reply-To: References: Message-ID: Dear Karen, Welcome! The link you clicked has a typo in it, which I assume we can fix soon. In the mean time, you can access chapter 22 from the table of contents or go to http://music-encoding.org/documentation/guidelines2013/text Best wishes, Raff On Tue, May 20, 2014 at 7:46 AM, Karen McAulay wrote: > Hello, > > > > I am your newest list member, so please excuse a very ignorant question! > I?m reading about attributes, in 1.1.1 online, and there?s a hyperlink to > Chapter 22 Text in MEI. (I?m interested in the treatment of prefatory and > back elements). However, the link brings up the following error message:- > > ** > > Please excuse, but the resource you're looking for is not available in > MEI2013. > > You're looking for /apps/mei/guidelines/2013/.xml > > > > Does this mean the chapter does not exist yet, or has it been moved > elsewhere? > > > > Very many thanks > > Karen McAulay > > > > *Dr.* *Karen McAulay* > *Music and Academic Services Librarian* > +44 (0)141 270 8267 (direct) > K.McAulay at rcs.ac.uk > > What's On Feb 14 - June 14 > > Prospectus > > *Short Courses Prospectus 2013/14 > * > > Summer Schools > > Follow us on Facebook > Follow us on Twitter > Broadcast - Explore our digital hub > > > _______________________________________________ > 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 K.McAulay at rcs.ac.uk Tue May 20 16:48:01 2014 From: K.McAulay at rcs.ac.uk (Karen McAulay) Date: Tue, 20 May 2014 14:48:01 +0000 Subject: [MEI-L] Query about Chapter 22 Text in MEI In-Reply-To: References: Message-ID: <40f950812f8146eeac486fcd7eca1c68@DB3PR03MB042.eurprd03.prod.outlook.com> Thank you, Raff ? glad to know my query had such a nice, straightforward answer! Best wishes Karen Dr. Karen McAulay Music and Academic Services Librarian +44 (0)141 270 8267 (direct) K.McAulay at rcs.ac.uk What's On Feb 14 - June 14 Prospectus Short Courses Prospectus 2013/14 Summer Schools [cid:image001.jpg at 01CF7442.E0E82ED0] [cid:image002.gif at 01CF7442.E0E82ED0] Follow us on Facebook [cid:image003.gif at 01CF7442.E0E82ED0] Follow us on Twitter [cid:image004.jpg at 01CF7442.E0E82ED0] Broadcast - Explore our digital hub From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: 20 May 2014 15:46 To: Music Encoding Initiative Subject: Re: [MEI-L] Query about Chapter 22 Text in MEI Dear Karen, Welcome! The link you clicked has a typo in it, which I assume we can fix soon. In the mean time, you can access chapter 22 from the table of contents or go to http://music-encoding.org/documentation/guidelines2013/text Best wishes, Raff On Tue, May 20, 2014 at 7:46 AM, Karen McAulay > wrote: Hello, I am your newest list member, so please excuse a very ignorant question! I?m reading about attributes, in 1.1.1 online, and there?s a hyperlink to Chapter 22 Text in MEI. (I?m interested in the treatment of prefatory and back elements). However, the link brings up the following error message:- Please excuse, but the resource you're looking for is not available in MEI2013. You're looking for /apps/mei/guidelines/2013/.xml Does this mean the chapter does not exist yet, or has it been moved elsewhere? Very many thanks Karen McAulay Dr. Karen McAulay Music and Academic Services Librarian +44 (0)141 270 8267 (direct) K.McAulay at rcs.ac.uk What's On Feb 14 - June 14 Prospectus Short Courses Prospectus 2013/14 Summer Schools Follow us on Facebook Follow us on Twitter Broadcast - Explore our digital hub _______________________________________________ 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: 6657 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1280 bytes Desc: image002.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.gif Type: image/gif Size: 1279 bytes Desc: image003.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 18237 bytes Desc: image004.jpg URL: From adrian at holovaty.com Thu May 22 03:43:24 2014 From: adrian at holovaty.com (Adrian Holovaty) Date: Wed, 21 May 2014 20:43:24 -0500 Subject: [MEI-L] Corrected version of Maple Leaf Rag MEI example Message-ID: Hi there, I mentioned this to a few people at the Music Encoding Conference today and wanted to send an email about it before I forgot... The MEI encoding of "Maple Leaf Rag" from http://music-encoding.org/documentation/samples has some bad musical data in it. I spent way too much time trying to figure out whether it was a bug in my reader. :-) I've attached a corrected version. Basically the first few bars had extra notes tacked on the end. More broadly, would there be any interest in hosting these samples on GitHub, so that people could add to the list and fix any errors? I'd be happy to help set that up -- just let me know. I'll be at the conference on Thursday. Cheers, Adrian -- Adrian Holovaty Soundslice: http://www.soundslice.com/ Personal: http://www.holovaty.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Joplin_Maple_leaf_Rag.xml Type: text/xml Size: 345968 bytes Desc: not available URL: From andrew.hankinson at mail.mcgill.ca Thu May 22 04:54:04 2014 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Thu, 22 May 2014 02:54:04 +0000 Subject: [MEI-L] Corrected version of Maple Leaf Rag MEI example In-Reply-To: <16281_1400723033_537D5658_16281_145_1_CABm4ZCS42+whHZaiMQv_RmgUmXX9ERg5k7ZnE7qZhi9CGvcZ3w@mail.gmail.com> References: <16281_1400723033_537D5658_16281_145_1_CABm4ZCS42+whHZaiMQv_RmgUmXX9ERg5k7ZnE7qZhi9CGvcZ3w@mail.gmail.com> Message-ID: <1B7C3E2F-E02B-4834-9EE5-D90BBBE07833@mail.mcgill.ca> Hi Adrian, There?s an ?unofficial? GitHub mirror of the MEI source, including the samples, here: https://github.com/music-encoding/music-encoding If you wanted to submit any corrections in a GitHub Pull Request, I?ll work with the rest of the development team to get them merged in to the SVN repo. Thanks for helping! -Andrew On May 21, 2014, at 9:43 PM, Adrian Holovaty > wrote: Hi there, I mentioned this to a few people at the Music Encoding Conference today and wanted to send an email about it before I forgot... The MEI encoding of "Maple Leaf Rag" from http://music-encoding.org/documentation/samples has some bad musical data in it. I spent way too much time trying to figure out whether it was a bug in my reader. :-) I've attached a corrected version. Basically the first few bars had extra notes tacked on the end. More broadly, would there be any interest in hosting these samples on GitHub, so that people could add to the list and fix any errors? I'd be happy to help set that up -- just let me know. I'll be at the conference on Thursday. Cheers, Adrian -- Adrian Holovaty Soundslice: http://www.soundslice.com/ Personal: http://www.holovaty.com/ _______________________________________________ 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 adrian at holovaty.com Thu May 22 05:20:53 2014 From: adrian at holovaty.com (Adrian Holovaty) Date: Wed, 21 May 2014 23:20:53 -0400 Subject: [MEI-L] Corrected version of Maple Leaf Rag MEI example In-Reply-To: <1B7C3E2F-E02B-4834-9EE5-D90BBBE07833@mail.mcgill.ca> References: <16281_1400723033_537D5658_16281_145_1_CABm4ZCS42+whHZaiMQv_RmgUmXX9ERg5k7ZnE7qZhi9CGvcZ3w@mail.gmail.com> <1B7C3E2F-E02B-4834-9EE5-D90BBBE07833@mail.mcgill.ca> Message-ID: On Wed, May 21, 2014 at 10:54 PM, Andrew Hankinson < andrew.hankinson at mail.mcgill.ca> wrote: > There?s an ?unofficial? GitHub mirror of the MEI source, including the > samples, here: https://github.com/music-encoding/music-encoding > > If you wanted to submit any corrections in a GitHub Pull Request, I?ll > work with the rest of the development team to get them merged in to the SVN > repo. > Sounds good. I've just made a pull request here: https://github.com/music-encoding/music-encoding/pull/1 Any interested parties can see my changes here: https://github.com/adrianholovaty/music-encoding/commit/2dfd86d86f72a86a490fb7453c8c3dbe54544db4 Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: From bohl at edirom.de Thu May 22 09:42:37 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 22 May 2014 09:42:37 +0200 Subject: [MEI-L] MEI Members & Community Strategy Discussion Message-ID: <537DAA6D.305@edirom.de> Dear MEI-L subscribers, please be aware that this year's MEI Members Meeting will be held today after the Closing Remarks of the Music Encoding Conference 2014. As MEI membership is open to anybody please feel cordially invited to join us at 4:30 pm (CST/CDT = 10:30 pm CEST) in the Clemens Library, Room 201 On behalf of the MEI Strategy Development Group I will bring up for face-to-face discussion the potential future community organization models for MEI that have been discussed on MEI-L during the past weeks and are publicly available at: https://docs.google.com/document/d/1IBvbKFM1fo4lwyFnIYnneUhfwTj4DLrAmtCSUfqzeQs/edit?usp=sharing If you cannot join us in person (especially those who are not attending the conference and in Europe) feel free to add your comments to the above document or mail them to MEI-L or to me (even as late as 30 min. before the Session). We'll do our very best to bring up your issues during discussion and keep you informed via MEI-L and Twitter (#MEImm2014). With best regards, Benjamin W. Bohl - Keeper of the MEI Strategy Development Group -- *********************************************************** 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 njp2 at columbia.edu Thu May 22 22:46:03 2014 From: njp2 at columbia.edu (Nick J. Patterson) Date: Thu, 22 May 2014 16:46:03 -0400 Subject: [MEI-L] List of proposed Hack Day projects? Message-ID: Hi, to people attending the Music Encoding Conference - Sorry if I've missed this, but, is there a list somewhere of proposed projects taking place on the Hack Day? Many thanks, /Nick -- Nick Patterson, Music Librarian Music & Arts Library, Columbia University 701 Dodge, 2960 Broadway New York, NY 10027 212-854-8523 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hankinson at mail.mcgill.ca Thu May 22 22:50:29 2014 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Thu, 22 May 2014 20:50:29 +0000 Subject: [MEI-L] List of proposed Hack Day projects? In-Reply-To: <32600_1400791589_537E6224_32600_53_1_CAJWo5pV0m8zMwnskvUP=CEUKBy5V+Pd=Yinnx54uiGZFf5ZBog@mail.gmail.com> References: <32600_1400791589_537E6224_32600_53_1_CAJWo5pV0m8zMwnskvUP=CEUKBy5V+Pd=Yinnx54uiGZFf5ZBog@mail.gmail.com> Message-ID: Hi Nick, The list of projects is here: https://docs.google.com/document/d/17hQaLU_eh_DIe2VBLFyGJBFMD6zTXjX9vmyfl-EM3jE/edit Feel free to add/edit. -Andrew On May 22, 2014, at 4:46 PM, Nick J. Patterson > wrote: Hi, to people attending the Music Encoding Conference - Sorry if I've missed this, but, is there a list somewhere of proposed projects taking place on the Hack Day? Many thanks, /Nick -- Nick Patterson, Music Librarian Music & Arts Library, Columbia University 701 Dodge, 2960 Broadway New York, NY 10027 212-854-8523 _______________________________________________ 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 May 24 07:15:19 2014 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Sat, 24 May 2014 05:15:19 +0000 Subject: [MEI-L] Hosting MEI on GitHub Message-ID: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> Hello, At the MEI Hack Day today we discussed the pros and cons of moving MEI development from Google Code hosting (https://code.google.com/p/music-encoding/) to GitHub. Both of these tools are used to share and collaborate on open source projects. However, it was felt by some that GitHub offers more possibilities for easy collaboration and participation than the Google Code platform, and as such we should consider moving our hosting platform. To see if this was possible we experimented with moving both the code (and its complete version history) and our issue tracker. The results of our testing are available here: https://github.com/music-encoding/music-encoding. All of the code and issues seem to have been migrated without a problem. Before we make the final decision to switch, however, we wanted to put it to the community to gather any questions or comments about this switch, and to give people an opportunity to voice any concerns they may have. After a period of discussion the technical team will make a final decision and notify the community. This will not be a long period of discussion, since it will be hard (and confusing) to manage two issue trackers and repositories, so please do not wait. Thank you, -Andrew From stadler at edirom.de Sat May 24 07:39:08 2014 From: stadler at edirom.de (Peter Stadler) Date: Sat, 24 May 2014 07:39:08 +0200 Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> Message-ID: <1CB9B5E5-6890-4D13-AEB0-D0D6749A5369@edirom.de> +1 for GitHub Peter > Am 24.05.2014 um 07:15 schrieb Andrew Hankinson : > > Hello, > > At the MEI Hack Day today we discussed the pros and cons of moving MEI development from Google Code hosting (https://code.google.com/p/music-encoding/) to GitHub. Both of these tools are used to share and collaborate on open source projects. However, it was felt by some that GitHub offers more possibilities for easy collaboration and participation than the Google Code platform, and as such we should consider moving our hosting platform. > > To see if this was possible we experimented with moving both the code (and its complete version history) and our issue tracker. The results of our testing are available here: https://github.com/music-encoding/music-encoding. All of the code and issues seem to have been migrated without a problem. > > Before we make the final decision to switch, however, we wanted to put it to the community to gather any questions or comments about this switch, and to give people an opportunity to voice any concerns they may have. > > After a period of discussion the technical team will make a final decision and notify the community. This will not be a long period of discussion, since it will be hard (and confusing) to manage two issue trackers and repositories, so please do not wait. > > Thank you, > -Andrew > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From kepper at edirom.de Sat May 24 14:42:18 2014 From: kepper at edirom.de (kepper at edirom.de) Date: Sat, 24 May 2014 14:42:18 +0200 (CEST) Subject: [MEI-L] Report of the user meeting in Charlottesville Message-ID: <1732534175.563644.1400935338825.open-xchange@email.1und1.de> Dear MEI Community, this week, we had a great Music Encoding Conference here in Charlottesville, and those of us who had the opportunity to get here - including myself - were all overwhelmed by the progress that MEI has made since last year. We clearly have a momentum to continue. Consequently, there was huge interest in having another iteration of the conference next year, and we also had an offer to host it in Europe. The offer will have to be confirmed, but watch out for news about this at some later point. We also had a lively discussion about community organization models, and eventually came up with a consensus *among the participants of that meeting*. As head of the Strategy Group that prepared this discussion, Benjamin volunteered to lead the effort to summarize the agreed-upon model in a white paper, which he will send out to the list in the next two weeks or so. Since the goal is a consensus of the whole community, we want all of you to check that model carefully and speak up with potential criticism asap. We will collect feedback and discuss for four weeks. If we have a consensus by then, we will install this model. Otherwise, we will modify the model accordingly and have another four weeks of discussion. While these time spans are somewhat lengthy, they will ensure that everyone has the opportunity to have a say in this. If you don't speak up, we will take your silence as approval. In a separate draft, the Strategy group will also come up with a procedure for the elections. I think it is very important to not conflate the discussion about election processes with the discussion about the organization model itself. Of course, please provide feedback on that one as well. I assume we don't need to have these strict four-week-iterations here. Finally, I want to thank everyone for a great week in Charlottesville. The team here was great - big thanks to Ruth, Sarah and Lucy, who made being here so easy. Thanks to all the authors for all the great papers we had, and to the PC, headed by Giuliano, for putting this program together. Finally, I'd like to thank Perry for the fifteen years of preparation that he invested into this conference. It was a great pleasure, and I'm already looking forward to next year's conference :-) Johannes -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From donbyrd at indiana.edu Sat May 24 19:19:57 2014 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Sat, 24 May 2014 13:19:57 -0400 Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: <1CB9B5E5-6890-4D13-AEB0-D0D6749A5369@edirom.de> References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> <1CB9B5E5-6890-4D13-AEB0-D0D6749A5369@edirom.de> Message-ID: <20140524131957.aqv2dfiroksoc4ks@webmail.iu.edu> +1 more for GitHub. --Don On Sat, 24 May 2014 07:39:08 +0200, Peter Stadler wrote: > +1 for GitHub > > Peter > >> Am 24.05.2014 um 07:15 schrieb Andrew Hankinson >> : >> >> Hello, >> >> At the MEI Hack Day today we discussed the pros and cons of moving >> MEI development from Google Code hosting >> (https://code.google.com/p/music-encoding/) to GitHub. Both of these >> tools are used to share and collaborate on open source projects. >> However, it was felt by some that GitHub offers more possibilities >> for easy collaboration and participation than the Google Code >> platform, and as such we should consider moving our hosting platform. >> >> To see if this was possible we experimented with moving both the >> code (and its complete version history) and our issue tracker. The >> results of our testing are available here: >> https://github.com/music-encoding/music-encoding. All of the code >> and issues seem to have been migrated without a problem. >> >> Before we make the final decision to switch, however, we wanted to >> put it to the community to gather any questions or comments about >> this switch, and to give people an opportunity to voice any concerns >> they may have. >> >> After a period of discussion the technical team will make a final >> decision and notify the community. This will not be a long period of >> discussion, since it will be hard (and confusing) to manage two >> issue trackers and repositories, so please do not wait. >> >> Thank you, >> -Andrew >> >> > > _______________________________________________ > 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 veit at weber-gesamtausgabe.de Sat May 24 21:10:57 2014 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Sat, 24 May 2014 21:10:57 +0200 Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: <20140524131957.aqv2dfiroksoc4ks@webmail.iu.edu> References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> <1CB9B5E5-6890-4D13-AEB0-D0D6749A5369@edirom.de> <20140524131957.aqv2dfiroksoc4ks@webmail.iu.edu> Message-ID: <5380EEC1.8000803@weber-gesamtausgabe.de> and another +1 for GitHub, Joachim Am 24.05.14 19:19, schrieb Byrd, Donald A.: > +1 more for GitHub. --Don > > > On Sat, 24 May 2014 07:39:08 +0200, Peter Stadler > wrote: > >> +1 for GitHub >> >> Peter >> >>> Am 24.05.2014 um 07:15 schrieb Andrew Hankinson >>> : >>> >>> Hello, >>> >>> At the MEI Hack Day today we discussed the pros and cons of moving >>> MEI development from Google Code hosting >>> (https://code.google.com/p/music-encoding/) to GitHub. Both of these >>> tools are used to share and collaborate on open source projects. >>> However, it was felt by some that GitHub offers more possibilities >>> for easy collaboration and participation than the Google Code >>> platform, and as such we should consider moving our hosting platform. >>> >>> To see if this was possible we experimented with moving both the >>> code (and its complete version history) and our issue tracker. The >>> results of our testing are available here: >>> https://github.com/music-encoding/music-encoding. All of the code >>> and issues seem to have been migrated without a problem. >>> >>> Before we make the final decision to switch, however, we wanted to >>> put it to the community to gather any questions or comments about >>> this switch, and to give people an opportunity to voice any concerns >>> they may have. >>> >>> After a period of discussion the technical team will make a final >>> decision and notify the community. This will not be a long period of >>> discussion, since it will be hard (and confusing) to manage two >>> issue trackers and repositories, so please do not wait. >>> >>> Thank you, >>> -Andrew >>> >>> >> >> _______________________________________________ >> 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 adrian at holovaty.com Sat May 24 21:25:41 2014 From: adrian at holovaty.com (Adrian Holovaty) Date: Sat, 24 May 2014 15:25:41 -0400 Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> Message-ID: +1 from me. In case it's helpful, here are my notes about migrating a reasonably large open-source project (Django) to GitHub a few years ago: http://www.holovaty.com/writing/django-github/ Aside from the obvious advantages in usability and collaboration, there are some non-obvious advantages such as the fact that it gives people "credit" for their contributions in an ecosystem that many employers are looking at. Adrian -- Adrian Holovaty Soundslice: http://www.soundslice.com/ Personal: http://www.holovaty.com/ On Sat, May 24, 2014 at 1:15 AM, Andrew Hankinson < andrew.hankinson at mail.mcgill.ca> wrote: > Hello, > > At the MEI Hack Day today we discussed the pros and cons of moving MEI > development from Google Code hosting ( > https://code.google.com/p/music-encoding/) to GitHub. Both of these tools > are used to share and collaborate on open source projects. However, it was > felt by some that GitHub offers more possibilities for easy collaboration > and participation than the Google Code platform, and as such we should > consider moving our hosting platform. > > To see if this was possible we experimented with moving both the code (and > its complete version history) and our issue tracker. The results of our > testing are available here: > https://github.com/music-encoding/music-encoding. All of the code and > issues seem to have been migrated without a problem. > > Before we make the final decision to switch, however, we wanted to put it > to the community to gather any questions or comments about this switch, and > to give people an opportunity to voice any concerns they may have. > > After a period of discussion the technical team will make a final decision > and notify the community. This will not be a long period of discussion, > since it will be hard (and confusing) to manage two issue trackers and > repositories, so please do not wait. > > Thank you, > -Andrew > > > _______________________________________________ > 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 k.annamaria at web.de Sun May 25 12:34:17 2014 From: k.annamaria at web.de (Anna Maria Komprecht) Date: Sun, 25 May 2014 12:34:17 +0200 Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: <5380EEC1.8000803@weber-gesamtausgabe.de> References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> <1CB9B5E5-6890-4D13-AEB0-D0D6749A5369@edirom.de> <20140524131957.aqv2dfiroksoc4ks@webmail.iu.edu> <5380EEC1.8000803@weber-gesamtausgabe.de> Message-ID: <71A2E36A-1C94-4E8B-94F9-C29979FD0772@web.de> +1 for GitHub. Anna > Am 24.05.2014 um 21:10 schrieb Joachim Veit : > > and another +1 for GitHub, > Joachim > > Am 24.05.14 19:19, schrieb Byrd, Donald A.: >> +1 more for GitHub. --Don >> >> >>> On Sat, 24 May 2014 07:39:08 +0200, Peter Stadler wrote: >>> >>> +1 for GitHub >>> >>> Peter >>> >>>> Am 24.05.2014 um 07:15 schrieb Andrew Hankinson >>>> : >>>> >>>> Hello, >>>> >>>> At the MEI Hack Day today we discussed the pros and cons of moving >>>> MEI development from Google Code hosting >>>> (https://code.google.com/p/music-encoding/) to GitHub. Both of these >>>> tools are used to share and collaborate on open source projects. >>>> However, it was felt by some that GitHub offers more possibilities >>>> for easy collaboration and participation than the Google Code >>>> platform, and as such we should consider moving our hosting platform. >>>> >>>> To see if this was possible we experimented with moving both the >>>> code (and its complete version history) and our issue tracker. The >>>> results of our testing are available here: >>>> https://github.com/music-encoding/music-encoding. All of the code >>>> and issues seem to have been migrated without a problem. >>>> >>>> Before we make the final decision to switch, however, we wanted to >>>> put it to the community to gather any questions or comments about >>>> this switch, and to give people an opportunity to voice any concerns >>>> they may have. >>>> >>>> After a period of discussion the technical team will make a final >>>> decision and notify the community. This will not be a long period of >>>> discussion, since it will be hard (and confusing) to manage two >>>> issue trackers and repositories, so please do not wait. >>>> >>>> Thank you, >>>> -Andrew >>> >>> _______________________________________________ >>> 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 klaus.rettinghaus at gmail.com Sun May 25 13:09:06 2014 From: klaus.rettinghaus at gmail.com (Klaus Rettinghaus) Date: Sun, 25 May 2014 13:09:06 +0200 Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: <71A2E36A-1C94-4E8B-94F9-C29979FD0772@web.de> References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> <1CB9B5E5-6890-4D13-AEB0-D0D6749A5369@edirom.de> <20140524131957.aqv2dfiroksoc4ks@webmail.iu.edu> <5380EEC1.8000803@weber-gesamtausgabe.de> <71A2E36A-1C94-4E8B-94F9-C29979FD0772@web.de> Message-ID: +1 for GitHub to bring the family together (TEI, Edirom, MerMEId, Verovio, etc.) Klaus 2014-05-25 12:34 GMT+02:00 Anna Maria Komprecht : > +1 for GitHub. Anna > > > Am 24.05.2014 um 21:10 schrieb Joachim Veit >: > > > > and another +1 for GitHub, > > Joachim > > > > Am 24.05.14 19:19, schrieb Byrd, Donald A.: > >> +1 more for GitHub. --Don > >> > >> > >>> On Sat, 24 May 2014 07:39:08 +0200, Peter Stadler > wrote: > >>> > >>> +1 for GitHub > >>> > >>> Peter > >>> > >>>> Am 24.05.2014 um 07:15 schrieb Andrew Hankinson > >>>> : > >>>> > >>>> Hello, > >>>> > >>>> At the MEI Hack Day today we discussed the pros and cons of moving > >>>> MEI development from Google Code hosting > >>>> (https://code.google.com/p/music-encoding/) to GitHub. Both of these > >>>> tools are used to share and collaborate on open source projects. > >>>> However, it was felt by some that GitHub offers more possibilities > >>>> for easy collaboration and participation than the Google Code > >>>> platform, and as such we should consider moving our hosting platform. > >>>> > >>>> To see if this was possible we experimented with moving both the > >>>> code (and its complete version history) and our issue tracker. The > >>>> results of our testing are available here: > >>>> https://github.com/music-encoding/music-encoding. All of the code > >>>> and issues seem to have been migrated without a problem. > >>>> > >>>> Before we make the final decision to switch, however, we wanted to > >>>> put it to the community to gather any questions or comments about > >>>> this switch, and to give people an opportunity to voice any concerns > >>>> they may have. > >>>> > >>>> After a period of discussion the technical team will make a final > >>>> decision and notify the community. This will not be a long period of > >>>> discussion, since it will be hard (and confusing) to manage two > >>>> issue trackers and repositories, so please do not wait. > >>>> > >>>> Thank you, > >>>> -Andrew > >>> > >>> _______________________________________________ > >>> 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 > -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From roewenstrunk at edirom.de Mon May 26 14:29:56 2014 From: roewenstrunk at edirom.de (=?iso-8859-1?Q?Daniel_R=F6wenstrunk?=) Date: Mon, 26 May 2014 14:29:56 +0200 Subject: [MEI-L] custoMEIzation Message-ID: Hi all, I always wanted to publish the source code of the MEI customization service on GitHub and never found time. But today: https://github.com/Edirom/custoMEIzation There is no way to parameterize the service and there is not enough documentation yet, this is going to come soon. So, feel free to try it, modify it, rehost the service or give feedback on GitHub. Cheers, Daniel -------------- 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 laurent at music.mcgill.ca Mon May 26 15:26:58 2014 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Mon, 26 May 2014 09:26:58 -0400 Subject: [MEI-L] custoMEIzation In-Reply-To: <4140_1401107419_538333DB_4140_114_1_ABE10E67-BD7A-496C-8B00-3EE1DF0A7E60@edirom.de> References: <4140_1401107419_538333DB_4140_114_1_ABE10E67-BD7A-496C-8B00-3EE1DF0A7E60@edirom.de> Message-ID: Hi Daniel, Thanks for this. BTW, I am trying to get a compile ODD output from the customization web-service selecting the 2013 version with mei-all 2013 customization. The output says "Target "odd" does not exist in the project "teitorelaxng". Do you have any idea what is the problem? Laurent On Mon, May 26, 2014 at 8:29 AM, Daniel R?wenstrunk wrote: > Hi all, > > I always wanted to publish the source code of the MEI customization service on GitHub and never found time. > > But today: https://github.com/Edirom/custoMEIzation > > There is no way to parameterize the service and there is not enough documentation yet, this is going to come soon. So, feel free to try it, modify it, rehost the service or give feedback on GitHub. > > > Cheers, Daniel > > _______________________________________________ > 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 Tue May 27 09:43:53 2014 From: roewenstrunk at edirom.de (=?iso-8859-1?Q?Daniel_R=F6wenstrunk?=) Date: Tue, 27 May 2014 09:43:53 +0200 Subject: [MEI-L] custoMEIzation In-Reply-To: <08333B08-CFFE-4E7B-BA82-3878DDFE8DEC@edirom.de> References: <08333B08-CFFE-4E7B-BA82-3878DDFE8DEC@edirom.de> Message-ID: Hi Laurent, I will have a look at this. It seems to be a change in the way the TEI stylesheets work. Daniel > Von: Laurent Pugin > Betreff: Aw: [MEI-L] custoMEIzation > Datum: 26. Mai 2014 15:26:58 MESZ > An: Music Encoding Initiative > Antwort an: Music Encoding Initiative > > Hi Daniel, > > Thanks for this. BTW, I am trying to get a compile ODD output from the > customization web-service selecting the 2013 version with mei-all 2013 > customization. The output says "Target "odd" does not exist in the > project "teitorelaxng". Do you have any idea what is the problem? > > Laurent > > On Mon, May 26, 2014 at 8:29 AM, Daniel R?wenstrunk > wrote: >> Hi all, >> >> I always wanted to publish the source code of the MEI customization service on GitHub and never found time. >> >> But today: https://github.com/Edirom/custoMEIzation >> >> There is no way to parameterize the service and there is not enough documentation yet, this is going to come soon. So, feel free to try it, modify it, rehost the service or give feedback on GitHub. >> >> >> Cheers, Daniel >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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 andrew.hankinson at mail.mcgill.ca Tue May 27 13:50:52 2014 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Tue, 27 May 2014 11:50:52 +0000 Subject: [MEI-L] custoMEIzation In-Reply-To: <11984_1401176698_53844279_11984_11_1_C0604D26-E010-46FB-A856-C13FC6AB2BE6@edirom.de> References: <08333B08-CFFE-4E7B-BA82-3878DDFE8DEC@edirom.de> <11984_1401176698_53844279_11984_11_1_C0604D26-E010-46FB-A856-C13FC6AB2BE6@edirom.de> Message-ID: <1FD7C0B0-4BC5-4435-AACF-E0E499AE4D4F@mail.mcgill.ca> Looking through the source code I can?t see where it?s actually checking out the source code. Is this done with a separate process? On May 27, 2014, at 3:43 AM, Daniel R?wenstrunk wrote: > Hi Laurent, > > I will have a look at this. It seems to be a change in the way the TEI stylesheets work. > > Daniel > > >> Von: Laurent Pugin >> Betreff: Aw: [MEI-L] custoMEIzation >> Datum: 26. Mai 2014 15:26:58 MESZ >> An: Music Encoding Initiative >> Antwort an: Music Encoding Initiative >> >> Hi Daniel, >> >> Thanks for this. BTW, I am trying to get a compile ODD output from the >> customization web-service selecting the 2013 version with mei-all 2013 >> customization. The output says "Target "odd" does not exist in the >> project "teitorelaxng". Do you have any idea what is the problem? >> >> Laurent >> >> On Mon, May 26, 2014 at 8:29 AM, Daniel R?wenstrunk >> wrote: >>> Hi all, >>> >>> I always wanted to publish the source code of the MEI customization service on GitHub and never found time. >>> >>> But today: https://github.com/Edirom/custoMEIzation >>> >>> There is no way to parameterize the service and there is not enough documentation yet, this is going to come soon. So, feel free to try it, modify it, rehost the service or give feedback on GitHub. >>> >>> >>> Cheers, Daniel >>> >>> _______________________________________________ >>> mei-l mailing list >>> mei-l at lists.uni-paderborn.de >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >>> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From esfield at stanford.edu Wed May 28 00:14:52 2014 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Tue, 27 May 2014 15:14:52 -0700 (PDT) Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> Message-ID: <0965bd3c.00000804.0000000b@MUS-MJ00MNV8.stanford.edu> +1 GitHub Eleanor -----Original Message----- From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Friday, May 23, 2014 10:15 PM To: Music Encoding Initiative Subject: [MEI-L] Hosting MEI on GitHub Hello, At the MEI Hack Day today we discussed the pros and cons of moving MEI development from Google Code hosting (https://code.google.com/p/music-encoding/) to GitHub. Both of these tools are used to share and collaborate on open source projects. However, it was felt by some that GitHub offers more possibilities for easy collaboration and participation than the Google Code platform, and as such we should consider moving our hosting platform. To see if this was possible we experimented with moving both the code (and its complete version history) and our issue tracker. The results of our testing are available here: https://github.com/music-encoding/music-encoding. All of the code and issues seem to have been migrated without a problem. Before we make the final decision to switch, however, we wanted to put it to the community to gather any questions or comments about this switch, and to give people an opportunity to voice any concerns they may have. After a period of discussion the technical team will make a final decision and notify the community. This will not be a long period of discussion, since it will be hard (and confusing) to manage two issue trackers and repositories, so please do not wait. Thank you, -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 Wed May 28 20:19:41 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 28 May 2014 18:19:41 +0000 Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: <0965bd3c.00000804.0000000b@MUS-MJ00MNV8.stanford.edu> References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> <0965bd3c.00000804.0000000b@MUS-MJ00MNV8.stanford.edu> Message-ID: I'm not opposed to hosting MEI on GitHub. However, I don't want to rush headlong into the switch. As I see it, there is good reason to stay the current course during the determination of MEI's organizational structure. Once a new Board/Technical Group is in place, it/they/we can take up the GitHub vs. SVN discussion. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Eleanor Selfridge-Field > Sent: Tuesday, May 27, 2014 6:15 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Hosting MEI on GitHub > > +1 GitHub > > Eleanor > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Andrew Hankinson > Sent: Friday, May 23, 2014 10:15 PM > To: Music Encoding Initiative > Subject: [MEI-L] Hosting MEI on GitHub > > Hello, > > At the MEI Hack Day today we discussed the pros and cons of moving MEI > development from Google Code hosting > (https://code.google.com/p/music-encoding/) to GitHub. Both of these tools > are used to share and collaborate on open source projects. However, it was > felt by some that GitHub offers more possibilities for easy collaboration > and participation than the Google Code platform, and as such we should > consider moving our hosting platform. > > To see if this was possible we experimented with moving both the code > (and > its complete version history) and our issue tracker. The results of our > testing are available here: > https://github.com/music-encoding/music-encoding. All of the code and > issues seem to have been migrated without a problem. > > Before we make the final decision to switch, however, we wanted to put it > to the community to gather any questions or comments about this switch, > and to give people an opportunity to voice any concerns they may have. > > After a period of discussion the technical team will make a final decision > and notify the community. This will not be a long period of discussion, > since it will be hard (and confusing) to manage two issue trackers and > repositories, so please do not wait. > > Thank you, > -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 kepper at edirom.de Wed May 28 20:29:34 2014 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 28 May 2014 20:29:34 +0200 Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> <0965bd3c.00000804.0000000b@MUS-MJ00MNV8.stanford.edu> Message-ID: <4710F7F6-659B-4315-8B11-4E6B7229690E@edirom.de> Given that almost everyone argues in favor of moving there, and even Perry says he's not aversed, I think we should go there. But I also think that Perry's argument is important. During the members meeting, Raffaele pointed out that the organizational structure should be reflected into the rights of the versioning system. Therefore, I would second the two of them and suggest to wait with the transition until we have a board in place. This gives us time to prepare both the data and ourselves? just my 2c? Johannes Am 28.05.2014 um 20:19 schrieb Roland, Perry D. (pdr4h) : > > I'm not opposed to hosting MEI on GitHub. However, I don't want to rush headlong into the switch. As I see it, there is good reason to stay the current course during the determination of MEI's organizational structure. Once a new Board/Technical Group is in place, it/they/we can take up the GitHub vs. SVN discussion. > > -- > p. > > > >> -----Original Message----- >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >> Eleanor Selfridge-Field >> Sent: Tuesday, May 27, 2014 6:15 PM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Hosting MEI on GitHub >> >> +1 GitHub >> >> Eleanor >> >> -----Original Message----- >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >> Andrew Hankinson >> Sent: Friday, May 23, 2014 10:15 PM >> To: Music Encoding Initiative >> Subject: [MEI-L] Hosting MEI on GitHub >> >> Hello, >> >> At the MEI Hack Day today we discussed the pros and cons of moving MEI >> development from Google Code hosting >> (https://code.google.com/p/music-encoding/) to GitHub. Both of these tools >> are used to share and collaborate on open source projects. However, it was >> felt by some that GitHub offers more possibilities for easy collaboration >> and participation than the Google Code platform, and as such we should >> consider moving our hosting platform. >> >> To see if this was possible we experimented with moving both the code >> (and >> its complete version history) and our issue tracker. The results of our >> testing are available here: >> https://github.com/music-encoding/music-encoding. All of the code and >> issues seem to have been migrated without a problem. >> >> Before we make the final decision to switch, however, we wanted to put it >> to the community to gather any questions or comments about this switch, >> and to give people an opportunity to voice any concerns they may have. >> >> After a period of discussion the technical team will make a final decision >> and notify the community. This will not be a long period of discussion, >> since it will be hard (and confusing) to manage two issue trackers and >> repositories, so please do not wait. >> >> Thank you, >> -Andrew >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- 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 andrew.hankinson at mail.mcgill.ca Wed May 28 20:54:48 2014 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 28 May 2014 14:54:48 -0400 Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: <5223_1401301787_53862B1B_5223_241_1_4710F7F6-659B-4315-8B11-4E6B7229690E@edirom.de> References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> <0965bd3c.00000804.0000000b@MUS-MJ00MNV8.stanford.edu> <5223_1401301787_53862B1B_5223_241_1_4710F7F6-659B-4315-8B11-4E6B7229690E@edirom.de> Message-ID: <26AF1E0E-1F22-4BC9-B446-EAB80EE58B71@mail.mcgill.ca> Ok. At the moment we have a couple contributions pending on GitHub. Here?s what I would suggest as a way forward: 1) We temporarily disable the GitHub Issues and maintain the Google Code issues as the primary issue tracker. 2) We keep the GitHub account open. It has already been useful in encouraging contributions, and I would not want to lose that. 3) I will ensure that contributions are bi-directional. That is, if someone commits to GitHub, I can contribute it in Google Code, and if a change is made in Subversion, I will update the GitHub account. Obviously #3 is not a long-term solution, but the tools support this type of bi-directional syncing so it?s not a particularly onerous task. -Andrew On May 28, 2014, at 2:29 PM, Johannes Kepper wrote: > Given that almost everyone argues in favor of moving there, and even Perry says he's not aversed, I think we should go there. But I also think that Perry's argument is important. During the members meeting, Raffaele pointed out that the organizational structure should be reflected into the rights of the versioning system. Therefore, I would second the two of them and suggest to wait with the transition until we have a board in place. This gives us time to prepare both the data and ourselves? > > just my 2c? > > Johannes > > > > Am 28.05.2014 um 20:19 schrieb Roland, Perry D. (pdr4h) : > >> >> I'm not opposed to hosting MEI on GitHub. However, I don't want to rush headlong into the switch. As I see it, there is good reason to stay the current course during the determination of MEI's organizational structure. Once a new Board/Technical Group is in place, it/they/we can take up the GitHub vs. SVN discussion. >> >> -- >> p. >> >> >> >>> -----Original Message----- >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >>> Eleanor Selfridge-Field >>> Sent: Tuesday, May 27, 2014 6:15 PM >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] Hosting MEI on GitHub >>> >>> +1 GitHub >>> >>> Eleanor >>> >>> -----Original Message----- >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >>> Andrew Hankinson >>> Sent: Friday, May 23, 2014 10:15 PM >>> To: Music Encoding Initiative >>> Subject: [MEI-L] Hosting MEI on GitHub >>> >>> Hello, >>> >>> At the MEI Hack Day today we discussed the pros and cons of moving MEI >>> development from Google Code hosting >>> (https://code.google.com/p/music-encoding/) to GitHub. Both of these tools >>> are used to share and collaborate on open source projects. However, it was >>> felt by some that GitHub offers more possibilities for easy collaboration >>> and participation than the Google Code platform, and as such we should >>> consider moving our hosting platform. >>> >>> To see if this was possible we experimented with moving both the code >>> (and >>> its complete version history) and our issue tracker. The results of our >>> testing are available here: >>> https://github.com/music-encoding/music-encoding. All of the code and >>> issues seem to have been migrated without a problem. >>> >>> Before we make the final decision to switch, however, we wanted to put it >>> to the community to gather any questions or comments about this switch, >>> and to give people an opportunity to voice any concerns they may have. >>> >>> After a period of discussion the technical team will make a final decision >>> and notify the community. This will not be a long period of discussion, >>> since it will be hard (and confusing) to manage two issue trackers and >>> repositories, so please do not wait. >>> >>> Thank you, >>> -Andrew >>> >>> >>> _______________________________________________ >>> mei-l mailing list >>> mei-l at lists.uni-paderborn.de >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >>> >>> _______________________________________________ >>> mei-l mailing list >>> mei-l at lists.uni-paderborn.de >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From craigsapp at gmail.com Wed May 28 23:48:45 2014 From: craigsapp at gmail.com (Craig Sapp) Date: Wed, 28 May 2014 14:48:45 -0700 Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: <26AF1E0E-1F22-4BC9-B446-EAB80EE58B71@mail.mcgill.ca> References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> <0965bd3c.00000804.0000000b@MUS-MJ00MNV8.stanford.edu> <5223_1401301787_53862B1B_5223_241_1_4710F7F6-659B-4315-8B11-4E6B7229690E@edirom.de> <26AF1E0E-1F22-4BC9-B446-EAB80EE58B71@mail.mcgill.ca> Message-ID: ++ from me :-) I would say that it is best to transfer it, and to put the transfer as far back in time as possible, i.e. do it now so that the change becomes less disruptive in the future. I dislike SVN, and find git acceptable, and combined with GitHub making it quite useful. Music21 saw the light this year -- you can study how they handle it by keeping releases available on GoogleCode, but moving the repository activity to GitHub: https://github.com/cuthbertLab/music21 https://code.google.com/p/music21 In other words, you can keep multiple copies, but only do version control on GitHub -- copying over the contents to GoogleCode as desired at every significant change, such as releases. GitHub has a pretty good system for hosting webpages, here is the new Humdrum documentation website set up at the MEC Hack day by Dan Shanahan fairly quickly from the old documentation website (still under construction): http://www.humdrum.org -=+Craig On 28 May 2014 11:54, Andrew Hankinson wrote: > Ok. > > At the moment we have a couple contributions pending on GitHub. Here?s > what I would suggest as a way forward: > > 1) We temporarily disable the GitHub Issues and maintain the Google Code > issues as the primary issue tracker. > 2) We keep the GitHub account open. It has already been useful in > encouraging contributions, and I would not want to lose that. > 3) I will ensure that contributions are bi-directional. That is, if > someone commits to GitHub, I can contribute it in Google Code, and if a > change is made in Subversion, I will update the GitHub account. > > Obviously #3 is not a long-term solution, but the tools support this type > of bi-directional syncing so it?s not a particularly onerous task. > > -Andrew > > On May 28, 2014, at 2:29 PM, Johannes Kepper wrote: > > > Given that almost everyone argues in favor of moving there, and even > Perry says he's not aversed, I think we should go there. But I also think > that Perry's argument is important. During the members meeting, Raffaele > pointed out that the organizational structure should be reflected into the > rights of the versioning system. Therefore, I would second the two of them > and suggest to wait with the transition until we have a board in place. > This gives us time to prepare both the data and ourselves? > > > > just my 2c? > > > > Johannes > > > > > > > > Am 28.05.2014 um 20:19 schrieb Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu>: > > > >> > >> I'm not opposed to hosting MEI on GitHub. However, I don't want to > rush headlong into the switch. As I see it, there is good reason to stay > the current course during the determination of MEI's organizational > structure. Once a new Board/Technical Group is in place, it/they/we can > take up the GitHub vs. SVN discussion. > >> > >> -- > >> p. > >> > >> > >> > >>> -----Original Message----- > >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > >>> Eleanor Selfridge-Field > >>> Sent: Tuesday, May 27, 2014 6:15 PM > >>> To: Music Encoding Initiative > >>> Subject: Re: [MEI-L] Hosting MEI on GitHub > >>> > >>> +1 GitHub > >>> > >>> Eleanor > >>> > >>> -----Original Message----- > >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > >>> Andrew Hankinson > >>> Sent: Friday, May 23, 2014 10:15 PM > >>> To: Music Encoding Initiative > >>> Subject: [MEI-L] Hosting MEI on GitHub > >>> > >>> Hello, > >>> > >>> At the MEI Hack Day today we discussed the pros and cons of moving MEI > >>> development from Google Code hosting > >>> (https://code.google.com/p/music-encoding/) to GitHub. Both of these > tools > >>> are used to share and collaborate on open source projects. However, it > was > >>> felt by some that GitHub offers more possibilities for easy > collaboration > >>> and participation than the Google Code platform, and as such we should > >>> consider moving our hosting platform. > >>> > >>> To see if this was possible we experimented with moving both the code > >>> (and > >>> its complete version history) and our issue tracker. The results of our > >>> testing are available here: > >>> https://github.com/music-encoding/music-encoding. All of the code and > >>> issues seem to have been migrated without a problem. > >>> > >>> Before we make the final decision to switch, however, we wanted to put > it > >>> to the community to gather any questions or comments about this switch, > >>> and to give people an opportunity to voice any concerns they may have. > >>> > >>> After a period of discussion the technical team will make a final > decision > >>> and notify the community. This will not be a long period of discussion, > >>> since it will be hard (and confusing) to manage two issue trackers and > >>> repositories, so please do not wait. > >>> > >>> Thank you, > >>> -Andrew > >>> > >>> > >>> _______________________________________________ > >>> mei-l mailing list > >>> mei-l at lists.uni-paderborn.de > >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l > >>> > >>> _______________________________________________ > >>> mei-l mailing list > >>> mei-l at lists.uni-paderborn.de > >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l > >> > >> _______________________________________________ > >> mei-l mailing list > >> mei-l at lists.uni-paderborn.de > >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > _______________________________________________ > > mei-l mailing list > > mei-l at lists.uni-paderborn.de > > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Thu May 29 00:51:36 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 28 May 2014 22:51:36 +0000 Subject: [MEI-L] Hosting MEI on GitHub In-Reply-To: References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> <0965bd3c.00000804.0000000b@MUS-MJ00MNV8.stanford.edu> <5223_1401301787_53862B1B_5223_241_1_4710F7F6-659B-4315-8B11-4E6B7229690E@edirom.de> <26AF1E0E-1F22-4BC9-B446-EAB80EE58B71@mail.mcgill.ca> Message-ID: As I see it, no one has yet provided a reason to move to Git and GitHub other than some version of ?I dislike SVN? or ?it?s what everyone is using these days?. It seems to me that SVN and Git perform the same basic function, so the so-called advantages of Git seem to me to be more a matter of personal preference than functional difference and more complicating than helpful since a new vocabulary is required to describe existing processes and functionality. Some say a significant advantage of Git is that it will encourage more participation in the revision of MEI. I?m not sure that will solve more problems than it creates. Is there really a huge group of contributors looking to modify the MEI source whose needs aren?t met by the current system? Even if such a group exists, is it desirable to allow frequent changes to mei-source? One of the reasons for using ODD is to control the modification process so that changes can be reviewed and incorporated after careful thought. If a large group can simply change mei-source.xml file at will, the customization process as test bed loses its effectiveness. The ?do it now so that the change becomes less disruptive in the future? argument sounds a lot like a sales pitch that begins with ?This offer is only good for today?. If it?s a good idea to buy that car or move to Git today, it will still be a good idea tomorrow, next week, or even next year. In fact, the move could become more desirable as time goes on, but we won?t know that until we?ve had some time to think it over. Maintaining multiple repositories seems to me like inviting trouble unless one can guarantee that the information flow is always from GitHub to GoogleCode. I assume that if someone forgets and modifies the SVN repo, at best any changes would be lost and at worst conflicts would be created on a level that could be very difficult to resolve. Even if the workflow can be guaranteed and we don?t care about changes in the SVN repo getting lost, in the ?version on GitHub and copy to GoogleCode? scenario, then GoogleCode becomes redundant. But creating this redundancy solely as an argument to eliminate GoogleCode/SVN isn?t valid logic. If copies cause trouble, don?t make copies. We already have a web presence at music-encoding.org so I fail to see how hosting webpages on GitHub is beneficial. That would simply dilute the recognition of music-encoding.org as the home of MEI. Just my 2 cents, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Craig Sapp Sent: Wednesday, May 28, 2014 5:49 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Hosting MEI on GitHub ++ from me :-) I would say that it is best to transfer it, and to put the transfer as far back in time as possible, i.e. do it now so that the change becomes less disruptive in the future. I dislike SVN, and find git acceptable, and combined with GitHub making it quite useful. Music21 saw the light this year -- you can study how they handle it by keeping releases available on GoogleCode, but moving the repository activity to GitHub: https://github.com/cuthbertLab/music21 https://code.google.com/p/music21 In other words, you can keep multiple copies, but only do version control on GitHub -- copying over the contents to GoogleCode as desired at every significant change, such as releases. GitHub has a pretty good system for hosting webpages, here is the new Humdrum documentation website set up at the MEC Hack day by Dan Shanahan fairly quickly from the old documentation website (still under construction): http://www.humdrum.org -=+Craig On 28 May 2014 11:54, Andrew Hankinson > wrote: Ok. At the moment we have a couple contributions pending on GitHub. Here?s what I would suggest as a way forward: 1) We temporarily disable the GitHub Issues and maintain the Google Code issues as the primary issue tracker. 2) We keep the GitHub account open. It has already been useful in encouraging contributions, and I would not want to lose that. 3) I will ensure that contributions are bi-directional. That is, if someone commits to GitHub, I can contribute it in Google Code, and if a change is made in Subversion, I will update the GitHub account. Obviously #3 is not a long-term solution, but the tools support this type of bi-directional syncing so it?s not a particularly onerous task. -Andrew On May 28, 2014, at 2:29 PM, Johannes Kepper > wrote: > Given that almost everyone argues in favor of moving there, and even Perry says he's not aversed, I think we should go there. But I also think that Perry's argument is important. During the members meeting, Raffaele pointed out that the organizational structure should be reflected into the rights of the versioning system. Therefore, I would second the two of them and suggest to wait with the transition until we have a board in place. This gives us time to prepare both the data and ourselves? > > just my 2c? > > Johannes > > > > Am 28.05.2014 um 20:19 schrieb Roland, Perry D. (pdr4h) >: > >> >> I'm not opposed to hosting MEI on GitHub. However, I don't want to rush headlong into the switch. As I see it, there is good reason to stay the current course during the determination of MEI's organizational structure. Once a new Board/Technical Group is in place, it/they/we can take up the GitHub vs. SVN discussion. >> >> -- >> p. >> >> >> >>> -----Original Message----- >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >>> Eleanor Selfridge-Field >>> Sent: Tuesday, May 27, 2014 6:15 PM >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] Hosting MEI on GitHub >>> >>> +1 GitHub >>> >>> Eleanor >>> >>> -----Original Message----- >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >>> Andrew Hankinson >>> Sent: Friday, May 23, 2014 10:15 PM >>> To: Music Encoding Initiative >>> Subject: [MEI-L] Hosting MEI on GitHub >>> >>> Hello, >>> >>> At the MEI Hack Day today we discussed the pros and cons of moving MEI >>> development from Google Code hosting >>> (https://code.google.com/p/music-encoding/) to GitHub. Both of these tools >>> are used to share and collaborate on open source projects. However, it was >>> felt by some that GitHub offers more possibilities for easy collaboration >>> and participation than the Google Code platform, and as such we should >>> consider moving our hosting platform. >>> >>> To see if this was possible we experimented with moving both the code >>> (and >>> its complete version history) and our issue tracker. The results of our >>> testing are available here: >>> https://github.com/music-encoding/music-encoding. All of the code and >>> issues seem to have been migrated without a problem. >>> >>> Before we make the final decision to switch, however, we wanted to put it >>> to the community to gather any questions or comments about this switch, >>> and to give people an opportunity to voice any concerns they may have. >>> >>> After a period of discussion the technical team will make a final decision >>> and notify the community. This will not be a long period of discussion, >>> since it will be hard (and confusing) to manage two issue trackers and >>> repositories, so please do not wait. >>> >>> Thank you, >>> -Andrew >>> >>> >>> _______________________________________________ >>> mei-l mailing list >>> mei-l at lists.uni-paderborn.de >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >>> >>> _______________________________________________ >>> mei-l mailing list >>> mei-l at lists.uni-paderborn.de >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- next part -------------- An HTML attachment was scrubbed... URL: From veit at weber-gesamtausgabe.de Tue Jun 3 15:09:38 2014 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Tue, 03 Jun 2014 15:09:38 +0200 Subject: [MEI-L] New Position in our Beethoven-project In-Reply-To: <26AF1E0E-1F22-4BC9-B446-EAB80EE58B71@mail.mcgill.ca> References: <90A8E90C-9515-4B03-8337-566B1E6A123F@mail.mcgill.ca> <0965bd3c.00000804.0000000b@MUS-MJ00MNV8.stanford.edu> <5223_1401301787_53862B1B_5223_241_1_4710F7F6-659B-4315-8B11-4E6B7229690E@edirom.de> <26AF1E0E-1F22-4BC9-B446-EAB80EE58B71@mail.mcgill.ca> Message-ID: <538DC912.3050308@weber-gesamtausgabe.de> Hi all, the new project of the Mainz Academy, "Beethovens Werkstatt", is looking for a further member of the editorial staff - please have a look at the appending announcement. Apologies for cross-posting and best greetings Joachim Veit -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : Ausschreibung_BW.pdf Dateityp : application/pdf Dateigr??e : 209689 bytes Beschreibung: nicht verf?gbar URL : -------------- 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 richard at rjlewis.me.uk Tue Jun 3 17:02:32 2014 From: richard at rjlewis.me.uk (Richard Lewis) Date: Tue, 03 Jun 2014 16:02:32 +0100 Subject: [MEI-L] AHRC Doctoral Studentship in Computational Musicology Message-ID: <87egz6ox2v.wl%richard@rjlewis.me.uk> STUDENTSHIP ADVERTISEMENT With apologies for cross posting AHRC Doctoral Studentship in Computational Musicology Award: fees and tax-free stipend at ?15,726 p.a. (inc. of London weighting) Application deadline: Tuesday 1 July 2014 Expected start date: October 2014 We invite applications for a Doctoral Studentship, funded by the Arts and Humanities Research Council, in Computational Musicology, located at Queen Mary University of London, under the supervision of Professor Geraint Wiggins. The studentship is part of the "Transforming Musicology" project, including Goldsmiths, University of London, Queen Mary University of London, the University of Oxford and Lancaster University. This project, led by Prof Tim Crawford in the Computing Department of Goldsmiths, University of London, brings together 15 researchers to effect a Digital Transformation of the discipline of musicology. The aim of the open studentship is to research and develop new methods for the representation of, and inference about, music-theoretic and perceptual aspects of music, based on, but not restricted to, past work by Prof. Wiggins and colleagues. This will be deployed using Semantic Web technology. The studentship will be located in a very rich research environment, first within the Transforming Musicology project, but also within the Computational Creativity Lab at QMUL, and the successful candidate will be encouraged to interact with other researchers in both of these contexts. This studentship, funded by an AHRC Doctoral Training Account, is for fees plus a tax-free stipend starting at ?15,726 per annum. Further details of the AHRC scheme including terms and conditions can be found here: http://www.ahrc.ac.uk/Funding-Opportunities/Postgraduate-funding/Pages/Current-award-holders.aspx Applicants must satisfy the AHRC's UK residence requirements: http://www.ahrc.ac.uk/Funding-Opportunities/Documents/Guide%20to%20Student%20Eligibility.pdf Candidates must have a first class or 2.1 undergraduate degree or equivalent, either with a significant component of music theory, in which case evidence of exceptionally well-developed practical expertise in computing, including programming, will be required, or in computer science or equivalent, in which case evidence of formal training in music theory (e.g. to grade V or equivalent) will be required. Candidates with relevant postgraduate qualifications will be particularly welcome, especially if they are qualified in both music and computer science. Other relevant qualifications and/or areas of expertise include (but are not limited to): artificial intelligence, informatics, formal logic and automated reasoning, musicology, knowledge representation, deductive database theory. The successful applicant may be required to undertake relevant undergraduate and postgraduate interdisciplinary courses as part of the programme of study. Informal enquiries can be made by email to Prof. Geraint Wiggins (geraint.wiggins at qmul.ac.uk). Please note that Prof. Wiggins is unable to advise, prior to interview, whether an applicant is likely to be selected. To apply please follow the on-line process (see http://www.qmul.ac.uk/postgraduate/howtoapply/) by selecting "Electronic Engineering" in the "A-Z list of research opportunities" and following the instructions on the right hand side of the web page. Please note that instead of the 'Research Proposal' we request a 'Statement of Research Interests'. Your Statement of Research Interest should answer two questions: (i) Why are you interested in the proposed area? (ii) What is your experience in the proposed area? Your statement should be brief: no more than 500 words or one side of A4 paper. In addition we would also like you to send a sample of your written work, such as your final year dissertation. More details can be found at: http://www.eecs.qmul.ac.uk/phd/how-to-apply Applications must be received by Tuesday 1 July 2014. Interviews are expected to take place during July 2014. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Richard Lewis Computing, Goldsmiths' College t: +44 (0)20 7078 5203 @: lewisrichard http://www.transforming-musicology.org/ 905C D796 12CD 4C6E CBFB 69DA EFCE DCDF 71D7 D455 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From bohl at edirom.de Thu Jun 5 15:46:50 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 05 Jun 2014 15:46:50 +0200 Subject: [MEI-L] Report from the MEI Members Meeting 2014 Message-ID: <539074CA.8020404@edirom.de> Dear MEI-L, in order to keep everyone informed, here is my short personal report form the MEI Members Meeting 2014 held at the Music Encoding conference 2014 (#MEC2014). ======================================== The Members Meeting was set to be open to the public, and approximately 35 people were attending the session. Two topics were addressed during the meeting: 1) The regularity of the Music Encoding Conference The intention behind this topic was to evaluate general feelings on whether an annual conference would be too ambitious for a community as young as MEI. A bi-annual conference was proposed as alternative. Ideas were put forward to align the Music Encoding Conference with other events or conferences, that a bi-annual conference might result in higher numbers of attendees and that both these ideas could be suitable for potentially limited travel funds of individuals. Nevertheless bi-annual conferences might also prevent submissions as individual researchers or research projects might be in a state not ready for public discussion or already finished before the next conference. With general consensus that the Music Encoding Conference 2014 was a great success, even exceeding expectations, the plenum agreed that an annual conference would be preferable. Individual attendees even announced their willingness to serve as local organizers resp. hosting future conferences. Other events or conferences were nevertheless deemed good opportunities for meetings, workshops or hack days. It was deemed essential, that future conferences should be planned with a sound look ahead considering potential collisions with other events and for the sake of a sound preroll for contributors and organizers. 2) Future Community Organization Discussion about the future organization of the MEI community consumed most of the time available for the Members Meeting and resulted in a very productive discussion and outcome. The plenum agreed on a provisional model based on the recent discussions on MEI-L and came up with a revision procedure for broader community feedback on the model. The model and details about the review procedure have been described and put together be members of the MEI Strategy Development Group and the Interim Steering Group during the past days. The document will be made publicly available in a separate E-Mail. ====================================== With all the 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 *********************************************************** From bohl at edirom.de Thu Jun 5 15:49:47 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 05 Jun 2014 15:49:47 +0200 Subject: [MEI-L] NEW PROPOSAL: MEI community organization Message-ID: <5390757B.1010305@edirom.de> Dear MEI-L:isteners, as announced but a few moments ago in my personal report from the MEI Members Meeting at the Music Encoding Conference 2014, I am happy to announce the publication of the new proposal for MEI community organization and the start of the first public four-week review period. Please visit the following link to add your comments to the googleDoc and feel free to discuss it on this mailinglist. https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2QJdhz8rbF4c3phFw/edit?usp=sharing Wit all the best wishes and in hope of a productive discussion, Benjamin W. Bohl MEI Strategy Development Group - 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 *********************************************************** From pdr4h at eservices.virginia.edu Thu Jun 5 16:13:33 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 5 Jun 2014 14:13:33 +0000 Subject: [MEI-L] NEW PROPOSAL: MEI community organization In-Reply-To: <5390757B.1010305@edirom.de> References: <5390757B.1010305@edirom.de> Message-ID: Thank you, Benni, for putting this together. MEIsters (Game of Thrones, anyone?), now's the time to let your voices be heard. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Benjamin Wolff Bohl > Sent: Thursday, June 05, 2014 9:50 AM > To: Music Encoding Initiative > Subject: [MEI-L] NEW PROPOSAL: MEI community organization > > Dear MEI-L:isteners, > as announced but a few moments ago in my personal report from the MEI > Members Meeting at the Music Encoding Conference 2014, I am happy to > announce the publication of the new proposal for MEI community > organization and the start of the first public four-week review period. > Please visit the following link to add your comments to the googleDoc > and feel free to discuss it on this mailinglist. > https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q > Jdhz8rbF4c3phFw/edit?usp=sharing > > Wit all the best wishes and in hope of a productive discussion, > Benjamin W. Bohl > MEI Strategy Development Group > - 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 > *********************************************************** > > > _______________________________________________ > 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 Jun 9 19:51:43 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 9 Jun 2014 17:51:43 +0000 Subject: [MEI-L] NEW PROPOSAL: MEI community organization In-Reply-To: <5390757B.1010305@edirom.de> References: <5390757B.1010305@edirom.de> Message-ID: Hi Benni, everyone, Of course we're not creating a corporation yet, but I found some aspects of the TEI and ISMIR by-laws to be instructive. So, I've attached copies of those documents with the good parts (IMHO) highlighted. Since they're legal documents, they are more formal than we need at present, but there are still some things it might be beneficial to emulate in the MEI "constitution" (for want of a better word), such as the organization into clearly-defined articles. In addition, some issues are covered that we haven't yet addressed, such as resignation and/or removal of officers and the process for amending the document itself. I'm not advocating for any of the particulars expressed in these documents, not even the so-called "good parts", only the general structure and, in some cases, the language employed. Comments welcomed, -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Benjamin Wolff Bohl > Sent: Thursday, June 05, 2014 9:50 AM > To: Music Encoding Initiative > Subject: [MEI-L] NEW PROPOSAL: MEI community organization > > Dear MEI-L:isteners, > as announced but a few moments ago in my personal report from the MEI > Members Meeting at the Music Encoding Conference 2014, I am happy to > announce the publication of the new proposal for MEI community > organization and the start of the first public four-week review period. > Please visit the following link to add your comments to the googleDoc > and feel free to discuss it on this mailinglist. > https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q > Jdhz8rbF4c3phFw/edit?usp=sharing > > Wit all the best wishes and in hope of a productive discussion, > Benjamin W. Bohl > MEI Strategy Development Group > - 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 > *********************************************************** > > > _______________________________________________ > 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: ismirBylaws.pdf Type: application/pdf Size: 112870 bytes Desc: ismirBylaws.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: teiBylaws.pdf Type: application/pdf Size: 240784 bytes Desc: teiBylaws.pdf URL: From ricksustek at me.com Mon Jun 9 22:20:09 2014 From: ricksustek at me.com (Richard Sustek) Date: Mon, 09 Jun 2014 13:20:09 -0700 Subject: [MEI-L] sample XML files on MEI site start off with incorrect XML Message-ID: <807B9ECA-8A21-4B6B-85FF-06CC9E3FA968@me.com> Hi, Did not look at all files, but every one that I did look at suffers these problems: 1) does not begin with proper XML declaration 2) the href attributes in the xml-model tags are incorrectly using local filesystem, relative paths. These need to be fully formed http URLs. Attempting to open any of these incorrect files in the Score Editor application will yield only an editing window view of the XML itself, i.e., no graphical score representation. Fixing these incorrect lines allows Score Editor to treat the file as expected. Thanks! -Rick From pdr4h at eservices.virginia.edu Mon Jun 9 22:36:01 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 9 Jun 2014 20:36:01 +0000 Subject: [MEI-L] sample XML files on MEI site start off with incorrect XML In-Reply-To: <807B9ECA-8A21-4B6B-85FF-06CC9E3FA968@me.com> References: <807B9ECA-8A21-4B6B-85FF-06CC9E3FA968@me.com> Message-ID: Hi Rick, At some point in the not-too-distant future, the 2012 files should be fixed (or maybe just removed), but for now, the files in /trunk/samples/MEI2013/Music/Complete examples/ have the correct declaration. They also point to the absolute URL http://music-encoding.googlecode.com/svn/tags/MEI2013_v2.1.0/schemata/mei-all.rng. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni- > paderborn.de] On Behalf Of Richard Sustek > Sent: Monday, June 09, 2014 4:20 PM > To: mei-l at lists.uni-paderborn.de > Subject: [MEI-L] sample XML files on MEI site start off with incorrect XML > > Hi, > > Did not look at all files, but every one that I did look at suffers these > problems: > 1) does not begin with proper XML declaration > 2) the href attributes in the xml-model tags are incorrectly using local > filesystem, relative paths. These need to be fully formed http URLs. > > Attempting to open any of these incorrect files in the Score Editor > application will yield only an editing window view of the XML itself, i.e., no > graphical score representation. Fixing these incorrect lines allows Score > Editor to treat the file as expected. > > Thanks! > -Rick > > > _______________________________________________ > 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 Jun 9 22:43:03 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 9 Jun 2014 20:43:03 +0000 Subject: [MEI-L] sample XML files on MEI site start off with incorrect XML In-Reply-To: References: <807B9ECA-8A21-4B6B-85FF-06CC9E3FA968@me.com> Message-ID: Just another quick note -- While the example files point to the MEI "all" schema (which was chosen as the default target of the 2012 -> 2013 conversion), they probably should point to the "CMN" schema instead. This could result in slightly different parsing behavior as mei-CMN is a subset of mei-all. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Roland, Perry D. (pdr4h) > Sent: Monday, June 09, 2014 4:36 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] sample XML files on MEI site start off with incorrect XML > > > Hi Rick, > > At some point in the not-too-distant future, the 2012 files should be fixed > (or maybe just removed), but for now, the files in > /trunk/samples/MEI2013/Music/Complete examples/ have the correct > declaration. They also point to the absolute URL http://music- > encoding.googlecode.com/svn/tags/MEI2013_v2.1.0/schemata/mei-all.rng. > > -- > p. > > > > -----Original Message----- > > From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni- > > paderborn.de] On Behalf Of Richard Sustek > > Sent: Monday, June 09, 2014 4:20 PM > > To: mei-l at lists.uni-paderborn.de > > Subject: [MEI-L] sample XML files on MEI site start off with incorrect XML > > > > Hi, > > > > Did not look at all files, but every one that I did look at suffers these > > problems: > > 1) does not begin with proper XML declaration > > 2) the href attributes in the xml-model tags are incorrectly using local > > filesystem, relative paths. These need to be fully formed http URLs. > > > > Attempting to open any of these incorrect files in the Score Editor > > application will yield only an editing window view of the XML itself, i.e., no > > graphical score representation. Fixing these incorrect lines allows Score > > Editor to treat the file as expected. > > > > Thanks! > > -Rick > > > > > > _______________________________________________ > > mei-l mailing list > > mei-l at lists.uni-paderborn.de > > https://lists.uni-paderborn.de/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 Jun 10 12:53:15 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Tue, 10 Jun 2014 12:53:15 +0200 Subject: [MEI-L] NEW PROPOSAL: MEI community organization In-Reply-To: References: <5390757B.1010305@edirom.de> Message-ID: <5396E39B.6000409@edirom.de> Hi Perry, hi all, thanks for the helpful material! As luck would have it the digital mediavalist list had called for votes on an amendment to its byelaws just as I was finishing the proposal (http://digitalmedievalist.wordpress.com/2014/06/04/dm-byelaws-vote/). A couple of changes I included were inspired by these. And I fully agree with Perry, that we should try to formalize our "constitution" in a similar way. Thanks again Perry! 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 09.06.2014 19:51, schrieb Roland, Perry D. (pdr4h): > Hi Benni, everyone, > > Of course we're not creating a corporation yet, but I found some aspects of the TEI and ISMIR by-laws to be instructive. So, I've attached copies of those documents with the good parts (IMHO) highlighted. > > Since they're legal documents, they are more formal than we need at present, but there are still some things it might be beneficial to emulate in the MEI "constitution" (for want of a better word), such as the organization into clearly-defined articles. In addition, some issues are covered that we haven't yet addressed, such as resignation and/or removal of officers and the process for amending the document itself. > > I'm not advocating for any of the particulars expressed in these documents, not even the so-called "good parts", only the general structure and, in some cases, the language employed. > > Comments welcomed, > > -- > p. > > > >> -----Original Message----- >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >> Benjamin Wolff Bohl >> Sent: Thursday, June 05, 2014 9:50 AM >> To: Music Encoding Initiative >> Subject: [MEI-L] NEW PROPOSAL: MEI community organization >> >> Dear MEI-L:isteners, >> as announced but a few moments ago in my personal report from the MEI >> Members Meeting at the Music Encoding Conference 2014, I am happy to >> announce the publication of the new proposal for MEI community >> organization and the start of the first public four-week review period. >> Please visit the following link to add your comments to the googleDoc >> and feel free to discuss it on this mailinglist. >> https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q >> Jdhz8rbF4c3phFw/edit?usp=sharing >> >> Wit all the best wishes and in hope of a productive discussion, >> Benjamin W. Bohl >> MEI Strategy Development Group >> - 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 >> *********************************************************** >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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 Tue Jun 10 15:21:25 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 10 Jun 2014 13:21:25 +0000 Subject: [MEI-L] NEW PROPOSAL: MEI community organization In-Reply-To: <5396E39B.6000409@edirom.de> References: <5390757B.1010305@edirom.de> <5396E39B.6000409@edirom.de> Message-ID: Hi Benni, Thanks for the pointer. I think the digital medievalist bylaws are very similar to what we're looking for. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Benjamin Wolff Bohl Sent: Tuesday, June 10, 2014 6:53 AM To: mei-l at lists.uni-paderborn.de Subject: Re: [MEI-L] NEW PROPOSAL: MEI community organization Hi Perry, hi all, thanks for the helpful material! As luck would have it the digital mediavalist list had called for votes on an amendment to its byelaws just as I was finishing the proposal (http://digitalmedievalist.wordpress.com/2014/06/04/dm-byelaws-vote/). A couple of changes I included were inspired by these. And I fully agree with Perry, that we should try to formalize our "constitution" in a similar way. Thanks again Perry! 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 09.06.2014 19:51, schrieb Roland, Perry D. (pdr4h): Hi Benni, everyone, Of course we're not creating a corporation yet, but I found some aspects of the TEI and ISMIR by-laws to be instructive. So, I've attached copies of those documents with the good parts (IMHO) highlighted. Since they're legal documents, they are more formal than we need at present, but there are still some things it might be beneficial to emulate in the MEI "constitution" (for want of a better word), such as the organization into clearly-defined articles. In addition, some issues are covered that we haven't yet addressed, such as resignation and/or removal of officers and the process for amending the document itself. I'm not advocating for any of the particulars expressed in these documents, not even the so-called "good parts", only the general structure and, in some cases, the language employed. Comments welcomed, -- p. -----Original Message----- From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Benjamin Wolff Bohl Sent: Thursday, June 05, 2014 9:50 AM To: Music Encoding Initiative Subject: [MEI-L] NEW PROPOSAL: MEI community organization Dear MEI-L:isteners, as announced but a few moments ago in my personal report from the MEI Members Meeting at the Music Encoding Conference 2014, I am happy to announce the publication of the new proposal for MEI community organization and the start of the first public four-week review period. Please visit the following link to add your comments to the googleDoc and feel free to discuss it on this mailinglist. https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q Jdhz8rbF4c3phFw/edit?usp=sharing Wit all the best wishes and in hope of a productive discussion, Benjamin W. Bohl MEI Strategy Development Group - 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 *********************************************************** _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/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 Thu Jun 12 17:16:16 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 12 Jun 2014 17:16:16 +0200 Subject: [MEI-L] future MEI Board Message-ID: <5399C440.5090600@edirom.de> Dear MEI-L::isteners, the current proposal or MEI Community Organization isn't exactly clear about how many members the future Board will have. This is due to the fact that the discussion in Charlottesville wasn't totally explicit about it. At the moment there are three main issues that I would like to forward to the community: 1) odd or even In general do you prefer an odd or even number of voting board members? 2) Host Institution representative In addition to any number of Board members elected from and by the community, the proposal grants a seat to one member of every host institution, designated by the respective institution. At the moment the Academy will be the only Host Institution (Please be aware that this is not about Institutional Membership and an institution can only have this role in MEI on individual agreements with the Board). The question connected to this is whether this designated member of the Board should have equal rights concerning any decision making process of the board, e.g. the right to vote in such decisions or have advisory role only? 3) Number of elected Board members & terms How many elected members should the Board have, and how long should their terms be? In general we decided on staggered/overlapping terms in order to have a number of Board members be elected every year. The two proposed models are: a) 9 elected members serving for three years each, 3 members will be elected each year b) 6 elected members serving either for 2 or 3 years each, resulting in 3 or 2 members being elected each year I'd be very happy to hear community opinions on this! 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 *********************************************************** From pdr4h at eservices.virginia.edu Fri Jun 13 23:26:34 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 13 Jun 2014 21:26:34 +0000 Subject: [MEI-L] future MEI Board In-Reply-To: <5399C440.5090600@edirom.de> References: <5399C440.5090600@edirom.de> Message-ID: Hi Benni, everyone, On point 1 -- I have no preference since the normal modus operandi of the Board should be to arrive at decisions by consensus, not by voting. Regarding point 2 -- Again, I have no preference, but the role of the host institution representative should be spelled out. Since decisions should be made by consensus, I hesitate to say that the host institution rep. should be a voting member. I prefer something like -- "The host institution representative has the same rights in the decision-making process of the Board as other members." On point 3 -- I do have a preference for 6 elected members plus host institution-appointed representatives. I think a 6-member Board can be more efficient. Also, if we ever do get to the point of having resources to do so, reimbursing 6 people's travel expenses is cheaper. :-) -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Benjamin Wolff Bohl > Sent: Thursday, June 12, 2014 11:16 AM > To: Music Encoding Initiative > Subject: [MEI-L] future MEI Board > > Dear MEI-L::isteners, > the current proposal or MEI Community Organization isn't exactly clear > about how many members the future Board will have. This is due to the > fact that the discussion in Charlottesville wasn't totally explicit > about it. > At the moment there are three main issues that I would like to forward > to the community: > > 1) odd or even > In general do you prefer an odd or even number of voting board members? > > 2) Host Institution representative > In addition to any number of Board members elected from and by the > community, the proposal grants a seat to one member of every host > institution, designated by the respective institution. At the moment the > Academy will be the only Host Institution (Please be aware that this is > not about Institutional Membership and an institution can only have this > role in MEI on individual agreements with the Board). > The question connected to this is whether this designated member of the > Board should have equal rights concerning any decision making process of > the board, e.g. the right to vote in such decisions or have advisory > role only? > > 3) Number of elected Board members & terms > How many elected members should the Board have, and how long should > their terms be? > In general we decided on staggered/overlapping terms in order to have a > number of Board members be elected every year. The two proposed models > are: > a) 9 elected members serving for three years each, 3 members will be > elected each year > b) 6 elected members serving either for 2 or 3 years each, resulting in > 3 or 2 members being elected each year > > I'd be very happy to hear community opinions on this! > > 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 > *********************************************************** > > > _______________________________________________ > 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 Jun 15 13:14:47 2014 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Sun, 15 Jun 2014 07:14:47 -0400 Subject: [MEI-L] future MEI Board In-Reply-To: References: <5399C440.5090600@edirom.de> Message-ID: <20140615071447.456sgx9hs8g4004c@webmail.iu.edu> On point 1, aiming for consensus is great, but surely voting will be necessary on occasion, so I think an odd number is preferable. On point 2, I have no opinion. On point 3, I think 6 elected representatives plus institution-appointed representatives is _plenty_ large! ISMIR is a fairly similar organization to I think what we're talking about. I was on the ISMIR Steering Committee until about 2008, with 8 or 9 members, I forget exactly, and that was already a bit cumbersome. And Perry's point about travel $$ makes sense. --Don On Fri, 13 Jun 2014 21:26:34 +0000, "Roland, Perry D. (pdr4h)" wrote: > > Hi Benni, everyone, > > On point 1 -- I have no preference since the normal modus operandi of > the Board should be to arrive at decisions by consensus, not by > voting. > > Regarding point 2 -- Again, I have no preference, but the role of the > host institution representative should be spelled out. Since > decisions should be made by consensus, I hesitate to say that the > host institution rep. should be a voting member. I prefer something > like -- "The host institution representative has the same rights in > the decision-making process of the Board as other members." > > On point 3 -- I do have a preference for 6 elected members plus host > institution-appointed representatives. I think a 6-member Board can > be more efficient. Also, if we ever do get to the point of having > resources to do so, reimbursing 6 people's travel expenses is > cheaper. :-) > > -- > p. > > >> -----Original Message----- >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >> Benjamin Wolff Bohl >> Sent: Thursday, June 12, 2014 11:16 AM >> To: Music Encoding Initiative >> Subject: [MEI-L] future MEI Board >> >> Dear MEI-L::isteners, >> the current proposal or MEI Community Organization isn't exactly clear >> about how many members the future Board will have. This is due to the >> fact that the discussion in Charlottesville wasn't totally explicit >> about it. >> At the moment there are three main issues that I would like to forward >> to the community: >> >> 1) odd or even >> In general do you prefer an odd or even number of voting board members? >> >> 2) Host Institution representative >> In addition to any number of Board members elected from and by the >> community, the proposal grants a seat to one member of every host >> institution, designated by the respective institution. At the moment the >> Academy will be the only Host Institution (Please be aware that this is >> not about Institutional Membership and an institution can only have this >> role in MEI on individual agreements with the Board). >> The question connected to this is whether this designated member of the >> Board should have equal rights concerning any decision making process of >> the board, e.g. the right to vote in such decisions or have advisory >> role only? >> >> 3) Number of elected Board members & terms >> How many elected members should the Board have, and how long should >> their terms be? >> In general we decided on staggered/overlapping terms in order to have a >> number of Board members be elected every year. The two proposed models >> are: >> a) 9 elected members serving for three years each, 3 members will be >> elected each year >> b) 6 elected members serving either for 2 or 3 years each, resulting in >> 3 or 2 members being elected each year >> >> I'd be very happy to hear community opinions on this! >> >> 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 >> *********************************************************** >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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 Mon Jun 16 08:46:20 2014 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Mon, 16 Jun 2014 08:46:20 +0200 Subject: [MEI-L] future MEI Board In-Reply-To: <9981_1402830966_539D8074_9981_45_1_20140615071447.456sgx9hs8g4004c@webmail.iu.edu> References: <5399C440.5090600@edirom.de> <9981_1402830966_539D8074_9981_45_1_20140615071447.456sgx9hs8g4004c@webmail.iu.edu> Message-ID: I also agree with Don that for point 1 we need a voting option (just in case). For the same reason, I think that for point 2 we need to make clear that institution representatives will be non voting members. I can foresee that decisions will be taken by consensus, but again, this has to be in place just in case. On Sun, Jun 15, 2014 at 1:14 PM, Byrd, Donald A. wrote: > On point 1, aiming for consensus is great, but surely voting will be > necessary on occasion, so I think an odd number is preferable. > > On point 2, I have no opinion. > > On point 3, I think 6 elected representatives plus institution-appointed > representatives is _plenty_ large! ISMIR is a fairly similar organization to > I think what we're talking about. I was on the ISMIR Steering Committee > until about 2008, with 8 or 9 members, I forget exactly, and that was > already a bit cumbersome. And Perry's point about travel $$ makes sense. > > --Don > > > > On Fri, 13 Jun 2014 21:26:34 +0000, "Roland, Perry D. (pdr4h)" > wrote: >> >> >> Hi Benni, everyone, >> >> On point 1 -- I have no preference since the normal modus operandi of >> the Board should be to arrive at decisions by consensus, not by >> voting. >> >> Regarding point 2 -- Again, I have no preference, but the role of the >> host institution representative should be spelled out. Since >> decisions should be made by consensus, I hesitate to say that the >> host institution rep. should be a voting member. I prefer something >> like -- "The host institution representative has the same rights in >> the decision-making process of the Board as other members." >> >> On point 3 -- I do have a preference for 6 elected members plus host >> institution-appointed representatives. I think a 6-member Board can >> be more efficient. Also, if we ever do get to the point of having >> resources to do so, reimbursing 6 people's travel expenses is >> cheaper. :-) >> >> -- >> p. >> >> >>> -----Original Message----- >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >>> Benjamin Wolff Bohl >>> Sent: Thursday, June 12, 2014 11:16 AM >>> To: Music Encoding Initiative >>> Subject: [MEI-L] future MEI Board >>> >>> Dear MEI-L::isteners, >>> the current proposal or MEI Community Organization isn't exactly clear >>> about how many members the future Board will have. This is due to the >>> fact that the discussion in Charlottesville wasn't totally explicit >>> about it. >>> At the moment there are three main issues that I would like to forward >>> to the community: >>> >>> 1) odd or even >>> In general do you prefer an odd or even number of voting board members? >>> >>> 2) Host Institution representative >>> In addition to any number of Board members elected from and by the >>> community, the proposal grants a seat to one member of every host >>> institution, designated by the respective institution. At the moment the >>> Academy will be the only Host Institution (Please be aware that this is >>> not about Institutional Membership and an institution can only have this >>> role in MEI on individual agreements with the Board). >>> The question connected to this is whether this designated member of the >>> Board should have equal rights concerning any decision making process of >>> the board, e.g. the right to vote in such decisions or have advisory >>> role only? >>> >>> 3) Number of elected Board members & terms >>> How many elected members should the Board have, and how long should >>> their terms be? >>> In general we decided on staggered/overlapping terms in order to have a >>> number of Board members be elected every year. The two proposed models >>> are: >>> a) 9 elected members serving for three years each, 3 members will be >>> elected each year >>> b) 6 elected members serving either for 2 or 3 years each, resulting in >>> 3 or 2 members being elected each year >>> >>> I'd be very happy to hear community opinions on this! >>> >>> 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 >>> *********************************************************** >>> >>> >>> _______________________________________________ >>> mei-l mailing list >>> mei-l at lists.uni-paderborn.de >>> https://lists.uni-paderborn.de/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 siegert at udk-berlin.de Mon Jun 16 09:38:17 2014 From: siegert at udk-berlin.de (Christine Siegert) Date: Mon, 16 Jun 2014 09:38:17 +0200 Subject: [MEI-L] future MEI Board In-Reply-To: References: <5399C440.5090600@edirom.de> <9981_1402830966_539D8074_9981_45_1_20140615071447.456sgx9hs8g4004c@webmail.iu.edu> Message-ID: I also agree that voting might be necessary sometimes and that the insitutional representatives should only have an advisory function (they can at the same time, be elected, of course). Therefore, I would prefer 9 members instead of 6. All the best, Christine Prof. Dr. Christine Siegert Universit?t der K?nste Berlin Fakult?t Musik, Musikwissenschaft Fasanenstra?e 1B D-10623 Berlin Tel.: +49 (0)30 3185 2318 siegert at udk-berlin.de -----Urspr?ngliche Nachricht----- From: Laurent Pugin Sent: Monday, June 16, 2014 8:46 AM To: Music Encoding Initiative Cc: Roland, Perry D. (pdr4h) Subject: Re: [MEI-L] future MEI Board I also agree with Don that for point 1 we need a voting option (just in case). For the same reason, I think that for point 2 we need to make clear that institution representatives will be non voting members. I can foresee that decisions will be taken by consensus, but again, this has to be in place just in case. On Sun, Jun 15, 2014 at 1:14 PM, Byrd, Donald A. wrote: > On point 1, aiming for consensus is great, but surely voting will be > necessary on occasion, so I think an odd number is preferable. > > On point 2, I have no opinion. > > On point 3, I think 6 elected representatives plus institution-appointed > representatives is _plenty_ large! ISMIR is a fairly similar organization > to > I think what we're talking about. I was on the ISMIR Steering Committee > until about 2008, with 8 or 9 members, I forget exactly, and that was > already a bit cumbersome. And Perry's point about travel $$ makes sense. > > --Don > > > > On Fri, 13 Jun 2014 21:26:34 +0000, "Roland, Perry D. (pdr4h)" > wrote: >> >> >> Hi Benni, everyone, >> >> On point 1 -- I have no preference since the normal modus operandi of >> the Board should be to arrive at decisions by consensus, not by >> voting. >> >> Regarding point 2 -- Again, I have no preference, but the role of the >> host institution representative should be spelled out. Since >> decisions should be made by consensus, I hesitate to say that the >> host institution rep. should be a voting member. I prefer something >> like -- "The host institution representative has the same rights in >> the decision-making process of the Board as other members." >> >> On point 3 -- I do have a preference for 6 elected members plus host >> institution-appointed representatives. I think a 6-member Board can >> be more efficient. Also, if we ever do get to the point of having >> resources to do so, reimbursing 6 people's travel expenses is >> cheaper. :-) >> >> -- >> p. >> >> >>> -----Original Message----- >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >>> Benjamin Wolff Bohl >>> Sent: Thursday, June 12, 2014 11:16 AM >>> To: Music Encoding Initiative >>> Subject: [MEI-L] future MEI Board >>> >>> Dear MEI-L::isteners, >>> the current proposal or MEI Community Organization isn't exactly clear >>> about how many members the future Board will have. This is due to the >>> fact that the discussion in Charlottesville wasn't totally explicit >>> about it. >>> At the moment there are three main issues that I would like to forward >>> to the community: >>> >>> 1) odd or even >>> In general do you prefer an odd or even number of voting board members? >>> >>> 2) Host Institution representative >>> In addition to any number of Board members elected from and by the >>> community, the proposal grants a seat to one member of every host >>> institution, designated by the respective institution. At the moment the >>> Academy will be the only Host Institution (Please be aware that this is >>> not about Institutional Membership and an institution can only have this >>> role in MEI on individual agreements with the Board). >>> The question connected to this is whether this designated member of the >>> Board should have equal rights concerning any decision making process of >>> the board, e.g. the right to vote in such decisions or have advisory >>> role only? >>> >>> 3) Number of elected Board members & terms >>> How many elected members should the Board have, and how long should >>> their terms be? >>> In general we decided on staggered/overlapping terms in order to have a >>> number of Board members be elected every year. The two proposed models >>> are: >>> a) 9 elected members serving for three years each, 3 members will be >>> elected each year >>> b) 6 elected members serving either for 2 or 3 years each, resulting in >>> 3 or 2 members being elected each year >>> >>> I'd be very happy to hear community opinions on this! >>> >>> 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 >>> *********************************************************** >>> >>> >>> _______________________________________________ >>> mei-l mailing list >>> mei-l at lists.uni-paderborn.de >>> https://lists.uni-paderborn.de/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 Tue Jun 17 14:48:20 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 17 Jun 2014 12:48:20 +0000 Subject: [MEI-L] FW: mla-l Digest Sun, 15 Jun 2014 In-Reply-To: <20140615040523.AB505220CC@list-app.uits.indiana.edu> References: <20140615040523.AB505220CC@list-app.uits.indiana.edu> Message-ID: Hi MEI-sters, Thought some might find this announcement interesting. -- p. > -----Original Message----- > Date: Sat, 14 Jun 2014 10:50:23 +0000 > From: "Kamtman, Leslie" > Subject: [MLA-L] SEMLA call for program proposals > > Dear MLA, > > The SEMLA 2014 Program Committee is accepting proposals for > presentations for > the upcoming SEMLA Annual Meeting in Baton Rouge, Louisiana, October 2- > 4, > 2014. The focus will be on experimental music and digital media. > > If you are interested in submitting a presentation proposal for this meeting, > please include a title and a brief abstract of its projected content, and > whether this would fit best into a 30-minute or 45-minute time slot. Please > note that presenters and co-presenters will be required to register for the > SEMLA meeting, even if only for a single day. > > While submissions on any topic are welcome, we are particularly interested > in > presentations on the following topics: > > * Metadata and metadata schemas for music, musical instruments, and > music > technology > * Ontologies and categorization of musics and music artifacts. > * Archival and/or emulation strategies for Electronic music instruments, > software, and programming languages. Music Digital Libraries > * Interfaces and access mechanisms for Music Digital Libraries > * Music Information Retrieval in regards to Music Digital Libraries > * Music data representations, including: manuscripts/scores, audio, > video, > software > > Please submit all proposals to the SEMLA Program Committee Chair, Leslie > Kamtman: kamtml at uncsa.edu > Program Committee: Leslie Kamtman (Chair), Lois Kuyper-Rushing, Leslie > McCall, > Nancy Zavac > > The deadline for submissions is Tuesday, July 15, 2014. > > Best, > > > Leslie E. Kamtman > Music Librarian > Secretary, Faculty Council > University of North Carolina School of the Arts > 1533 S. Main St. > Winston-Salem, NC 27127 > > 336-770-1395 (phone) > 336-770-3271 (fax) > kamtml at uncsa.edu > > > ------------------------------ > > > End of mla-l Digest Sun, 15 Jun 2014 > ********************************************* From christopher at antila.ca Fri Jun 20 16:13:45 2014 From: christopher at antila.ca (Christopher Antila) Date: Fri, 20 Jun 2014 10:13:45 -0400 Subject: [MEI-L] Uniqueness and Consistency of @n for and Message-ID: <1403273625.26621.51.camel@kullervo.adjectivenoun.ca> Greetings to the MEI community! I'm working on a Python module to import MEI files to the "music21" library. I've noticed the MEI Guidelines tend toward flexibility, which is good, but I'd like to request clarification on a couple of edge cases. My questions stem from the nesting of staff and measure objects. In music21, a Part (analogous to ) holds Measure objects (), which in turn hold Voice objects (). Every Part therefore runs continuously from beginning to end. In MEI this is slightly different: a holds a , which holds . Therefore, when importing an MEI , music21 must determine which Part a tag corresponds to, using the @n and @def attributes. But when do those change, and how unique are they? Can I rely on @n attributes shared by a and to be unique within a ? Or should I account for the possibility that the same "source document" staff may have its tag's @n attribute changed by a part-way through the ? Example... is this valid? the only tuba part the same tuba part with a new @n What if we add a new instrument in the second , so the same @n attribute refers to a different / combination at different times? the only tuba part a new clarinet part with previously-used @n the same tuba part with a new @n Also, can I trust that every has an @n that's unique across the whole ? Or is it that a 's @n attribute will be unique only within its context? Example... is this possible? clarinet parts tuba parts Finally, should I account for a situation where the same staff has tags bound to a occasionally with @n and occasionally with @def? Consider this situation: The Guidelines say a tag "should always refer to a element, using either an @n or @def attribute," so I assume the third tag, which has both @n and @def, is not valid (pg.68ff, if you're following along). The Guidelines do show an analogous situation, where a defines both @n and @id, and the following two tags use @def then @n. In the example these tags are separated by "or" in a comment, but this seems like it's only a per-tag "or," not a per-document "or." Thanks in advance for your guidance. I'd be happy to clarify any of these situations. Christopher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From j.schoepf at musikologie.de Fri Jun 20 16:33:15 2014 From: j.schoepf at musikologie.de (=?UTF-8?Q?J=C3=BCrgen_Sch=C3=B6pf?=) Date: Fri, 20 Jun 2014 16:33:15 +0200 (CEST) Subject: [MEI-L] workshops In-Reply-To: <1403273625.26621.51.camel@kullervo.adjectivenoun.ca> References: <1403273625.26621.51.camel@kullervo.adjectivenoun.ca> Message-ID: <1292506630.1342930.1403274795305.open-xchange@omgreatgod.store> Dear Initiative Music Encoders, I am new to the community and list and wonder when and where there will be workshops where I could learn Music Encoding according to the MEI guidelines? Is anything planned already for this and/or next year? Or would you recommend to learn it from the documents only (I have experience with html and LaTeX)? best regards :-J -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From stadler at edirom.de Fri Jun 20 16:43:57 2014 From: stadler at edirom.de (Peter Stadler) Date: Fri, 20 Jun 2014 16:43:57 +0200 Subject: [MEI-L] workshops In-Reply-To: <1292506630.1342930.1403274795305.open-xchange@omgreatgod.store> References: <1403273625.26621.51.camel@kullervo.adjectivenoun.ca> <1292506630.1342930.1403274795305.open-xchange@omgreatgod.store> Message-ID: <823C21C0-B61E-41DF-B009-C99E78E6A284@edirom.de> Dear J?rgen, I think the next upcoming event is the Edirom Summer School (Sept. 8-12) with two (= English and German) introductory classes to MEI and another class (English only) Encoding and Rendering of MEI. Details will soon be available at http://ess.upb.de Best Peter Am 20.06.2014 um 16:33 schrieb J?rgen Sch?pf : > Dear Initiative Music Encoders, > > I am new to the community and list and wonder when and where there will be workshops where I could learn Music Encoding according to the MEI guidelines? > Is anything planned already for this and/or next year? > Or would you recommend to learn it from the documents only (I have experience with html and LaTeX)? > > best regards > :-J > _______________________________________________ > 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 andrew.hankinson at mail.mcgill.ca Fri Jun 20 17:14:36 2014 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 20 Jun 2014 11:14:36 -0400 Subject: [MEI-L] workshops In-Reply-To: <10506_1403274809_53A44636_10506_69_1_1292506630.1342930.1403274795305.open-xchange@omgreatgod.store> References: <1403273625.26621.51.camel@kullervo.adjectivenoun.ca> <10506_1403274809_53A44636_10506_69_1_1292506630.1342930.1403274795305.open-xchange@omgreatgod.store> Message-ID: It?s documentation, not a workshop, but have you seen the MEI 1st tutorials? http://www.music-encoding.org/support/MEI1st -Andrew On Jun 20, 2014, at 10:33 AM, J?rgen Sch?pf wrote: > Dear Initiative Music Encoders, > > I am new to the community and list and wonder when and where there will be workshops where I could learn Music Encoding according to the MEI guidelines? > Is anything planned already for this and/or next year? > Or would you recommend to learn it from the documents only (I have experience with html and LaTeX)? > > best regards > :-J > _______________________________________________ > 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 Jun 24 16:40:22 2014 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Tue, 24 Jun 2014 16:40:22 +0200 Subject: [MEI-L] NEW PROPOSAL: MEI community organization In-Reply-To: References: <5390757B.1010305@edirom.de> <5396E39B.6000409@edirom.de> Message-ID: <65CB652B-20A9-4E7F-A5D2-40E90946E50F@edirom.de> Dear MEI-L:isteners please be aware that the 4 week review period of the new proposal for MEI community organization, will end this Thursday (26 June). Please enter your comments in the document at: https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q or discuss its contents on the list. We will try to include all respective posts in v2 of the document, which will be published ASAP for another 4 week review period. Best wishes, Benjamin *********************************************************** Benjamin Wolff Bohl Wissenschaftlicher Mitarbeiter BMBF Projekt "Freisch?tz Digital" Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstr. 20 D ? 32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 URL: http://www.edirom.de *********************************************************** Am 10.06.2014 um 15:21 schrieb "Roland, Perry D. (pdr4h)" : > > Hi Benni, > > Thanks for the pointer. I think the digital medievalist bylaws are very similar to what we?re looking for. > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Benjamin Wolff Bohl > Sent: Tuesday, June 10, 2014 6:53 AM > To: mei-l at lists.uni-paderborn.de > Subject: Re: [MEI-L] NEW PROPOSAL: MEI community organization > > Hi Perry, > hi all, > > thanks for the helpful material! As luck would have it the digital mediavalist list had called for votes on an amendment to its byelaws just as I was finishing the proposal (http://digitalmedievalist.wordpress.com/2014/06/04/dm-byelaws-vote/). A couple of changes I included were inspired by these. And I fully agree with Perry, that we should try to formalize our "constitution" in a similar way. > > Thanks again Perry! > > 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 09.06.2014 19:51, schrieb Roland, Perry D. (pdr4h): > > Hi Benni, everyone, > > Of course we're not creating a corporation yet, but I found some aspects of the TEI and ISMIR by-laws to be instructive. So, I've attached copies of those documents with the good parts (IMHO) highlighted. > > Since they're legal documents, they are more formal than we need at present, but there are still some things it might be beneficial to emulate in the MEI "constitution" (for want of a better word), such as the organization into clearly-defined articles. In addition, some issues are covered that we haven't yet addressed, such as resignation and/or removal of officers and the process for amending the document itself. > > I'm not advocating for any of the particulars expressed in these documents, not even the so-called "good parts", only the general structure and, in some cases, the language employed. > > Comments welcomed, > > -- > p. > > > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Benjamin Wolff Bohl > Sent: Thursday, June 05, 2014 9:50 AM > To: Music Encoding Initiative > Subject: [MEI-L] NEW PROPOSAL: MEI community organization > > Dear MEI-L:isteners, > as announced but a few moments ago in my personal report from the MEI > Members Meeting at the Music Encoding Conference 2014, I am happy to > announce the publication of the new proposal for MEI community > organization and the start of the first public four-week review period. > Please visit the following link to add your comments to the googleDoc > and feel free to discuss it on this mailinglist. > https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q > Jdhz8rbF4c3phFw/edit?usp=sharing > > Wit all the best wishes and in hope of a productive discussion, > Benjamin W. Bohl > MEI Strategy Development Group > - 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 > *********************************************************** > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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 esfield at stanford.edu Tue Jun 24 22:27:18 2014 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Tue, 24 Jun 2014 13:27:18 -0700 (PDT) Subject: [MEI-L] NEW PROPOSAL: MEI community organization In-Reply-To: <65CB652B-20A9-4E7F-A5D2-40E90946E50F@edirom.de> References: <5390757B.1010305@edirom.de> <5396E39B.6000409@edirom.de> <65CB652B-20A9-4E7F-A5D2-40E90946E50F@edirom.de> Message-ID: <1420098417.3397156.1403641638375.JavaMail.zimbra@stanford.edu> I got a "file does not exist" message when I clicked. Please advise. Eleanor ----- Original Message ----- From: "Benjamin Wolff Bohl" To: "Music Encoding Initiative" Sent: Tuesday, June 24, 2014 7:40:22 AM Subject: Re: [MEI-L] NEW PROPOSAL: MEI community organization Dear MEI-L:isteners please be aware that the 4 week review period of the new proposal for MEI community organization, will end this Thursday (26 June). Please enter your comments in the document at: https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q or discuss its contents on the list. We will try to include all respective posts in v2 of the document, which will be published ASAP for another 4 week review period. Best wishes, Benjamin *********************************************************** Benjamin Wolff Bohl Wissenschaftlicher Mitarbeiter BMBF Projekt "Freisch?tz Digital" Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstr. 20 D ? 32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 URL: http://www.edirom.de *********************************************************** Am 10.06.2014 um 15:21 schrieb "Roland, Perry D. (pdr4h)" < pdr4h at eservices.virginia.edu >: Hi Benni, Thanks for the pointer. I think the digital medievalist bylaws are very similar to what we?re looking for. -- p. From: mei-l [mailto:mei- l-bounces at lists.uni-paderborn.de ] On Behalf Of Benjamin Wolff Bohl Sent: Tuesday, June 10, 2014 6:53 AM To: mei-l at lists.uni-paderborn.de Subject: Re: [MEI-L] NEW PROPOSAL: MEI community organization Hi Perry, hi all, thanks for the helpful material! As luck would have it the digital mediavalist list had called for votes on an amendment to its byelaws just as I was finishing the proposal ( http://digitalmedievalist.wordpress.com/2014/06/04/dm-byelaws-vote/ ). A couple of changes I included were inspired by these. And I fully agree with Perry, that we should try to formalize our "constitution" in a similar way. Thanks again Perry! 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 09.06.2014 19:51, schrieb Roland, Perry D. (pdr4h):

Hi Benni, everyone, Of course we're not creating a corporation yet, but I found some aspects of the TEI and ISMIR by-laws to be instructive.? So, I've attached copies of those documents with the good parts (IMHO) highlighted. Since they're legal documents, they are more formal than we need at present, but there are still some things it might be beneficial to emulate in the MEI "constitution" (for want of a better word), such as the organization into clearly-defined articles.? In addition, some issues are covered that we haven't yet addressed, such as resignation and/or removal of officers and the process for amending the document itself. I'm not advocating for any of the particulars expressed in these documents, not even the so-called "good parts", only the general structure and, in some cases, the language employed. Comments welcomed, -- p.
-----Original Message----- From: mei-l [ mailto:mei-l-bounces at lists.uni-paderborn.de ] On Behalf Of Benjamin Wolff Bohl Sent: Thursday, June 05, 2014 9:50 AM To: Music Encoding Initiative Subject: [MEI-L] NEW PROPOSAL: MEI community organization Dear MEI-L:isteners, as announced but a few moments ago in my personal report from the MEI Members Meeting at the Music Encoding Conference 2014, I am happy to announce the publication of the new proposal for MEI community organization and the start of the first public four-week review period. Please visit the following link to add your comments to the googleDoc and feel free to discuss it on this mailinglist. https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q Jdhz8rbF4c3phFw/edit?usp=sharing Wit all the best wishes and in hope of a productive discussion, Benjamin W. Bohl MEI Strategy Development Group - 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 *********************************************************** _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l
_______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/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 Tue Jun 24 22:37:23 2014 From: stadler at edirom.de (Peter Stadler) Date: Tue, 24 Jun 2014 22:37:23 +0200 Subject: [MEI-L] NEW PROPOSAL: MEI community organization In-Reply-To: <1420098417.3397156.1403641638375.JavaMail.zimbra@stanford.edu> References: <5390757B.1010305@edirom.de> <5396E39B.6000409@edirom.de> <65CB652B-20A9-4E7F-A5D2-40E90946E50F@edirom.de> <1420098417.3397156.1403641638375.JavaMail.zimbra@stanford.edu> Message-ID: <6EE5F660-2475-4129-BAA2-1036DC49FC3C@edirom.de> The link seems to be incomplete. This should work: https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2QJdhz8rbF4c3phFw/edit?usp=sharing Best Peter Am 24.06.2014 um 22:27 schrieb Eleanor Selfridge-Field : > I got a "file does not exist" message when I clicked. > > Please advise. > > Eleanor > > > From: "Benjamin Wolff Bohl" > To: "Music Encoding Initiative" > Sent: Tuesday, June 24, 2014 7:40:22 AM > Subject: Re: [MEI-L] NEW PROPOSAL: MEI community organization > > Dear MEI-L:isteners > > please be aware that the 4 week review period of the new proposal for MEI community organization, will end this Thursday (26 June). > Please enter your comments in the document at: > https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q > > or discuss its contents on the list. > We will try to include all respective posts in v2 of the document, which will be published ASAP for another 4 week review period. > > Best wishes, > Benjamin > > > *********************************************************** > Benjamin Wolff Bohl > Wissenschaftlicher Mitarbeiter > BMBF Projekt "Freisch?tz Digital" > > Musikwissenschaftliches Seminar Detmold/Paderborn > Gartenstr. 20 > D ? 32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > URL: http://www.edirom.de > > *********************************************************** > > Am 10.06.2014 um 15:21 schrieb "Roland, Perry D. (pdr4h)" : > > > Hi Benni, > > Thanks for the pointer. I think the digital medievalist bylaws are very similar to what we?re looking for. > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Benjamin Wolff Bohl > Sent: Tuesday, June 10, 2014 6:53 AM > To: mei-l at lists.uni-paderborn.de > Subject: Re: [MEI-L] NEW PROPOSAL: MEI community organization > > Hi Perry, > hi all, > > thanks for the helpful material! As luck would have it the digital mediavalist list had called for votes on an amendment to its byelaws just as I was finishing the proposal (http://digitalmedievalist.wordpress.com/2014/06/04/dm-byelaws-vote/). A couple of changes I included were inspired by these. And I fully agree with Perry, that we should try to formalize our "constitution" in a similar way. > > Thanks again Perry! > > 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 09.06.2014 19:51, schrieb Roland, Perry D. (pdr4h): > > Hi Benni, everyone, > > Of course we're not creating a corporation yet, but I found some aspects of the TEI and ISMIR by-laws to be instructive. So, I've attached copies of those documents with the good parts (IMHO) highlighted. > > Since they're legal documents, they are more formal than we need at present, but there are still some things it might be beneficial to emulate in the MEI "constitution" (for want of a better word), such as the organization into clearly-defined articles. In addition, some issues are covered that we haven't yet addressed, such as resignation and/or removal of officers and the process for amending the document itself. > > I'm not advocating for any of the particulars expressed in these documents, not even the so-called "good parts", only the general structure and, in some cases, the language employed. > > Comments welcomed, > > -- > p. > > > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Benjamin Wolff Bohl > Sent: Thursday, June 05, 2014 9:50 AM > To: Music Encoding Initiative > Subject: [MEI-L] NEW PROPOSAL: MEI community organization > > Dear MEI-L:isteners, > as announced but a few moments ago in my personal report from the MEI > Members Meeting at the Music Encoding Conference 2014, I am happy to > announce the publication of the new proposal for MEI community > organization and the start of the first public four-week review period. > Please visit the following link to add your comments to the googleDoc > and feel free to discuss it on this mailinglist. > https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q > Jdhz8rbF4c3phFw/edit?usp=sharing > > Wit all the best wishes and in hope of a productive discussion, > Benjamin W. Bohl > MEI Strategy Development Group > - 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 > *********************************************************** > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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 andrew.hankinson at mail.mcgill.ca Tue Jun 24 22:41:23 2014 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Tue, 24 Jun 2014 16:41:23 -0400 Subject: [MEI-L] NEW PROPOSAL: MEI community organization In-Reply-To: <14010_1403641663_53A9DF3F_14010_321_1_1420098417.3397156.1403641638375.JavaMail.zimbra@stanford.edu> References: <5390757B.1010305@edirom.de> <5396E39B.6000409@edirom.de> <65CB652B-20A9-4E7F-A5D2-40E90946E50F@edirom.de> <14010_1403641663_53A9DF3F_14010_321_1_1420098417.3397156.1403641638375.JavaMail.zimbra@stanford.edu> Message-ID: <8AE378D1-425B-4896-9D12-BABCF8F00F17@mail.mcgill.ca> I think the URL was truncated. The full URL is: https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2QJdhz8rbF4c3phFw/edit If that doesn?t work, here?s a shortened version: http://goo.gl/px5aEN -Andrew On Jun 24, 2014, at 4:27 PM, Eleanor Selfridge-Field wrote: > I got a "file does not exist" message when I clicked. > > Please advise. > > Eleanor > > > From: "Benjamin Wolff Bohl" > To: "Music Encoding Initiative" > Sent: Tuesday, June 24, 2014 7:40:22 AM > Subject: Re: [MEI-L] NEW PROPOSAL: MEI community organization > > Dear MEI-L:isteners > > please be aware that the 4 week review period of the new proposal for MEI community organization, will end this Thursday (26 June). > Please enter your comments in the document at: > https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q > > or discuss its contents on the list. > We will try to include all respective posts in v2 of the document, which will be published ASAP for another 4 week review period. > > Best wishes, > Benjamin > > > *********************************************************** > Benjamin Wolff Bohl > Wissenschaftlicher Mitarbeiter > BMBF Projekt "Freisch?tz Digital" > > Musikwissenschaftliches Seminar Detmold/Paderborn > Gartenstr. 20 > D ? 32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > URL: http://www.edirom.de > > *********************************************************** > > Am 10.06.2014 um 15:21 schrieb "Roland, Perry D. (pdr4h)" : > > > Hi Benni, > > Thanks for the pointer. I think the digital medievalist bylaws are very similar to what we?re looking for. > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Benjamin Wolff Bohl > Sent: Tuesday, June 10, 2014 6:53 AM > To: mei-l at lists.uni-paderborn.de > Subject: Re: [MEI-L] NEW PROPOSAL: MEI community organization > > Hi Perry, > hi all, > > thanks for the helpful material! As luck would have it the digital mediavalist list had called for votes on an amendment to its byelaws just as I was finishing the proposal (http://digitalmedievalist.wordpress.com/2014/06/04/dm-byelaws-vote/). A couple of changes I included were inspired by these. And I fully agree with Perry, that we should try to formalize our "constitution" in a similar way. > > Thanks again Perry! > > 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 09.06.2014 19:51, schrieb Roland, Perry D. (pdr4h): > > Hi Benni, everyone, > > Of course we're not creating a corporation yet, but I found some aspects of the TEI and ISMIR by-laws to be instructive. So, I've attached copies of those documents with the good parts (IMHO) highlighted. > > Since they're legal documents, they are more formal than we need at present, but there are still some things it might be beneficial to emulate in the MEI "constitution" (for want of a better word), such as the organization into clearly-defined articles. In addition, some issues are covered that we haven't yet addressed, such as resignation and/or removal of officers and the process for amending the document itself. > > I'm not advocating for any of the particulars expressed in these documents, not even the so-called "good parts", only the general structure and, in some cases, the language employed. > > Comments welcomed, > > -- > p. > > > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Benjamin Wolff Bohl > Sent: Thursday, June 05, 2014 9:50 AM > To: Music Encoding Initiative > Subject: [MEI-L] NEW PROPOSAL: MEI community organization > > Dear MEI-L:isteners, > as announced but a few moments ago in my personal report from the MEI > Members Meeting at the Music Encoding Conference 2014, I am happy to > announce the publication of the new proposal for MEI community > organization and the start of the first public four-week review period. > Please visit the following link to add your comments to the googleDoc > and feel free to discuss it on this mailinglist. > https://docs.google.com/document/d/1ChHjA7BMoURQp3Tsv7n2TnqAYU2Q > Jdhz8rbF4c3phFw/edit?usp=sharing > > Wit all the best wishes and in hope of a productive discussion, > Benjamin W. Bohl > MEI Strategy Development Group > - 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 > *********************************************************** > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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 christopher at antila.ca Wed Jun 25 20:23:13 2014 From: christopher at antila.ca (Christopher Antila) Date: Wed, 25 Jun 2014 14:23:13 -0400 Subject: [MEI-L] Uniqueness and Consistency of @n for and In-Reply-To: <1403273625.26621.51.camel@kullervo.adjectivenoun.ca> References: <1403273625.26621.51.camel@kullervo.adjectivenoun.ca> Message-ID: <1403720593.15375.0.camel@kullervo.adjectivenoun.ca> Hello again! After some contemplation (and more reading), I can answer my own questions. On Fri, 2014-06-20 at 10:13 -0400, Christopher Antila wrote: > Greetings to the MEI community! > > I'm working on a Python module to import MEI files to the "music21" > library. I've noticed the MEI Guidelines tend toward flexibility, which > is good, but I'd like to request clarification on a couple of edge > cases. > > My questions stem from the nesting of staff and measure objects. In > music21, a Part (analogous to ) holds Measure objects > (), which in turn hold Voice objects (). Every Part > therefore runs continuously from beginning to end. In MEI this is > slightly different: a holds a , which holds . > Therefore, when importing an MEI , music21 must determine which > Part a tag corresponds to, using the @n and @def attributes. But > when do those change, and how unique are they? > > Can I rely on @n attributes shared by a and to be > unique within a ? Or should I account for the possibility that > the same "source document" staff may have its tag's @n attribute > changed by a part-way through the ? > > Example... is this valid? > > > the only tuba part > > > > > the same tuba part with a new @n > > > > What if we add a new instrument in the second , so the same @n > attribute refers to a different / combination at > different times? > > > the only tuba part > > > > > a new clarinet part with previously-used > @n > > > the same tuba part with a new @n > > > > Also, can I trust that every has an @n that's unique across the > whole ? Or is it that a 's @n attribute will be unique > only within its context? > > Example... is this possible? > > > clarinet parts > > > > > tuba parts > > > > > > Finally, should I account for a situation where the same staff has > tags bound to a occasionally with @n and occasionally > with @def? > > Consider this situation: > > > > > > The Guidelines say a tag "should always refer to a > element, using either an @n or @def attribute," so I assume the third > tag, which has both @n and @def, is not valid (pg.68ff, if > you're following along). The Guidelines do show an analogous situation, > where a defines both @n and @id, and the following two > tags use @def then @n. In the example these tags are separated > by "or" in a comment, but this seems like it's only a per-tag "or," not > a per-document "or." > > Thanks in advance for your guidance. I'd be happy to clarify any of > these situations. The key is this paragraph from the 2013 MEI Guidelines: "Every must have an @n attribute with an integer as its value. The first occurrence of a with a given number must also indicate the number of staff lines via the @lines attribute." (pg.71) If only the first with an @n value must indicate the number of staff lines, this implies that all the following tags with the same @n attribute will refer to the same source-document staff. Furthermore, it implies that tags "cascade" hierarchically, so a in a is only required to provide the attributes it intends to override from a in a
. Finally, the @n attribute must therefore be unique within its tag-space. Going through my examples: the only tuba part the same tuba part with a new @n This doesn't produce the desired result. The two tags here should be interpreted as different source-document staves. Next example: the only tuba part a new clarinet part with previously-used @n the same tuba part with a new @n This doesn't produce the desired result either. In the second measure, the clarinet part will appear on the same staff as the previous measure's tuba part, and the tuba part will appear on a new staff. Finally, this example: The third tag is invalid because the Guideliness require *either* @n or @def. Both of the other tags are valid and work as expected. I also have a new situation. Consider this: How many lines for each of these tags? Going by XML ID, "a" will have five lines, "b" will have four, and "c" will have five. Is this right? Thanks again for your guidance. Christopher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From nikolaos.beer at uni-paderborn.de Fri Jun 27 13:25:33 2014 From: nikolaos.beer at uni-paderborn.de (Nikolaos Beer) Date: Fri, 27 Jun 2014 13:25:33 +0200 Subject: [MEI-L] =?windows-1252?q?Edirom_Summer_School_2014_=96_Course_Pro?= =?windows-1252?q?gram_and_Registration?= Message-ID: <69E45547-1EFA-44F6-97DF-64593DA6A79A@uni-paderborn.de> Dear colleagues, please let me inform you about the course program and registration deadline (31 July 2014) of this year's Edirom-Summer-School (ESS), which will take place 8 to 12 September 2014 at the Heinz Nixdorf Institute (University of Paderborn, Germany). ESS is co-organized by the Virtual Research Group Edirom (University of Paderborn) and the german eHumanities project DARIAH-DE. The scope of courses (mostly held in german) reaches from introductions to the DARIAH-DE Infrastructure, to Concepts of Digital Music Editions and to the markup standards of the Text Encoding Initiative (TEI) respectively the Music Encoding Initiative (MEI), across working with software tools for editorial purposes (Edirom Tools), up to courses dealing with more advanced topics in these fields like the rendering of MEI encodings. This year two courses will be especially held in english language (MEI Introduction and Rendering MEI). The Edirom User Forum will provide time to get in touch with music edition projects using the Edirom Tools. Students can apply for one student bursary provided by the EADH's Small Grants Program (http://eadh.org) to support ESS attendance. Details about application, ESS course program and registration can be found on the ESS-Website: http://ess.upb.de. In case of any questions concerning ESS2014, please feel free to contact the organization team at ess at edirom.de The Virtual Research Group Edirom is based at the Musicology Seminar Detmold/Paderborn, which is a co-faculty of the University of Paderborn and the Hochschule f?r Musik Detmold. Please find further information at http://www.edirom.de. DARIAH-DE is the German part of the EU eHumanities research project Digital Research Infrastructure for the Arts and Humanities. It is funded by the German Federal Ministry of Education and Research. Please find further information at http://de.dariah.eu. For the ESS organization team Nikolaos Beer ___________________________________ Nikolaos Beer M.A. Wissenschaftlicher Mitarbeiter BMBF-Projekt ?DARIAH-DE? und Verbundstelle Musikedition Universit?t Paderborn Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D-32756 Detmold Fon: +49 - (0)5231 - 975 - 669 @: nikolaos.beer at uni-paderborn.de -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From pdr4h at eservices.virginia.edu Tue Jul 1 18:27:31 2014 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 1 Jul 2014 16:27:31 +0000 Subject: [MEI-L] Uniqueness and Consistency of @n for and In-Reply-To: <1403720593.15375.0.camel@kullervo.adjectivenoun.ca> References: <1403273625.26621.51.camel@kullervo.adjectivenoun.ca>, <1403720593.15375.0.camel@kullervo.adjectivenoun.ca> Message-ID: Hi Christopher, Thanks for taking on this task. A transformation from MEI to Music21 will prove very useful. It seems you've misunderstood the use of . It can be used within , but only for those special cases where some characteristic(s) of the staff changes before the end of the system. In this case, its @n attribute can only take the value of the parent . Generally, it should appear within , which occurs prior to the measures it influences, like so -- etc. When the layout of the score changes, for instance with the addition of a new staff, the element can be used to indicate the new configuration -- Here the score begins with a single staff (labeled 'tuba') and continues with 2 staves (labeled 'clarinet' and 'tuba', respectively). As you can see, the tuba "part" begins on staff 1 and continues on staff 2; therefore, the @n value changes with respect to the "part". No attempt, however, is made via @n on either or to trace the "part". Often, however, a score is "rectangular"; that is, all staves are listed in the initial whether they are immediately used or not -- ... ... Later, only those staves with event-level data need to be enumerated. Here, only the flutes and horns are sounding. The other staves are assumed to be empty -- In these cases, the @n attribute values don't change with respect to a "part". The horn "part" will always appear on staff 14. This is the traditional way of dealing with orchestral scores and is often the method used by computer-based scoring programs. In essence, all staves are always available even if they are not currently visible. In MEI, each of the unused staves can be marked as invisible or scoreDef can carry an @optimize attribute, indicating that unused staves should be hidden programmatically. When each change in score layout is indicated by a element, one must rely on @label attributes (or