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

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110822/7457e624/attachment.html>