[MEI-L] Lessons from the turmoil in the TEI community

[Johannes Kepper]

Hi Raffaele,

this discussion on TEI-L is indeed very interesting to follow, and I'm almost sure that the TEI will be something different after this incident. Regarding the situation for MEI, I think we're in a completely different position. In this context, MEI is much more straightforward than TEI. There are significantly less choices when building your encoding model – you will not discuss whether to encode a note as <note> or something else like a <fermata>. Terminology is on our side here. It is true that MEI offers lots of choices, for instance regarding articulations. But are they semantically that different? Choosing attributes gives you a quick (but not necessarily dirty) solution. When using the <artic> element, you have to decide if you want to attach it to a timestamp / beat or a note, which admittedly is a semantic difference, but other than that, I would argue that all three solutions address the same issue. They allow a different level of complexity, but there is no semantic difference between them. In my opinion, all differences of this kind can be addressed by what we're calling MEIron*, so I guess MEI can claim to be ready for interchange of music notation, at least from the CMN period. 
Interoperability, as defined in those mails you cite, is surely a harder target to shoot at, but under certain conditions, I would say that MEI also solves that issue. I see bigger problems in MEI in those parts of the specification which are less strict defined / demand a higher level of modelling: The whole critapp and editorial modules are probably more project-specific, as is the header. For those areas, we will want to make sure to provide good documentation in the Guidelines, combined with a set of examples from our current projects as best-practice recommendations. 

All in all, I don't see the same problems in the schema that TEI currently discusses. From an MEI perspective, I would say we may learn more from the policital / organizational debate there. But that's just my rather unreflected first impression. I guess you're right that we all should follow this more closely and think about the consequences for MEI. 

Best,
Johannes





Am 22.08.2011 um 18:03 schrieb Raffaele Viglianti:

> Dear all,
> 
> As you may or may not know, the TEI has been going through some political turmoil over the past two weeks. A political "incident" created some furore in the community, which is now entering a phase of self-reflection on how things work at the TEI consortium and on the standard itself. If you are not following the events, I would invite you to do so because there can be some important potential lessons to be learned so that MEI does not incur in similar problems.
> Discussion is happening mainly on TEI-L (archive: http://listserv.brown.edu/archives/cgi-bin/wa?A0=tei-l ), though it started on Twitter under the hashtag #teiputsch (now abandoned) and continues under #teifuture.
> 
> I would like to bring your attention to the topic of interchange and interoperability, which is being discussed in these days (this recent email by David Birnbaum gives a good summary of the problem: http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1108&L=tei-l&T=0&F=&S=&P=15117 ). What is surfacing is what I usually call "the pride and doom of the TEI", that is the struggle between flexibility of encoding and interchange; between encoding as art form and tool. In other words, the TEI offers many different ways of encoding the same data, with often only subtle semantic differences between the different methods. I think that this is a strong value of TEI, as it makes it able to capture complex textual phenomena as the encoder sees them. On the other hand, there clearly is the risk of making TEI too much of a personal tool, thus isolating projects from one another. Quite a few people commented strongly on this, saying that it undermines the role of TEI for interchange and why should they bother using it in the first place (I was rather surprised to hear this from long-time users of TEI - just another indication that this problem has been lingering for long).
> 
> As you know, MEI is a similar beast and, by design, there are alternative encodings for the same phenomena. I believe that this is an essential feature that should not be abandoned; however I'd like to bring the issue of interchange to your attention. I am confident that it is an issue on top of the agenda already, but the recent events at the TEI may call for a revision, or confirmation, of our work in that sense. Investing in tools like MEIron and libraries like pyMEI since the early stages is, in my opinion, the best way to tackle this issue without loosing flexibility in MEI. Another, perhaps less attractive, solution is to always specify which of alternative encoding mechanisms is the one recommended for the majority of cases.
> 
> Any thoughts?
> 
> Regards,
> Raffaele
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l