[If this is considered too off-topic for this list, please ignore this
mail. My main point has still something to do with ConTeXt, but I guess
this discussion shouldn't be continued on the list.]
On 07/22/2012 08:07 PM, Pablo Rodríguez wrote:
And to explain that a bit: it's not merely "ugly." If all you want
is
the printed book, you don't care about the ugliness and simply
code this way to get the desired output. However, we are in the
21st century. We should be beyond the point where a critical
edition is the printed text, we should think of the typeset
result as just one way of representing the logical structure of
the edition. With a syntax as the one Wolfgang shows above, it is
difficult for most parsers to understand what is meant. Which
means most ways of representing such a structure will fail
because it's not a consistent logical construct. And yes, as
Pablo pointed out, TEI itself hasn't reached a clear conclusion
on such points, and they are specialists who have been working on
these problems for quite a while...
Thomas, many thanks for your reply.
You are the real expert on this topic. I don't really know why there
are so many people from TEI working on textual variants, but my guess
is that this might be also related to the different needs each of
them might face for each kind of texts. Probably the needs to
critically edit an ancient Greek or Latin author might differ with
the ones for an early modern (or even contemporary) English or German
author.
I'm not an expert at all, but I'm trying to put together a research
project that would help us make some progress here. But your assumption
is basically correct: there are many different philologies with
different habits and norms, and TEI has to take that into account.
There is another issue that I would like to discuss. My question is
what changes in a critical edition with no page model. I don't mean
that critical editions need to be printed (it isn't a paper-based
model), but I'm not so sure they can be properly represented without
a page model. So, if I'm not wrong, it isn't only a question of data
representation, but it is related to the logic of the text structure
itself.
Some have characterized the electronic text as infinite, in
opposition to a page-based text that by definition finite. XML is a
good example of a human-readable text, but this human-readability is
relevant because of a prior machine-readability. XML is meaningful
and useful for non-coders as source code to generate a
human-understandable representation of text.
Footnotes can be displayed not using a page model, because reference
is on both the body and the note texts. A hyperlink is the right way
to link each other. So, an infinite text is not a problem. The
footnote doesn't need to be on the same page (as in a printed book),
because there is a way to go to the note and back to the text (as on
the physical book).
But linenotes are different. The reference is on the note, but not
on the body. The same line can have many linenotes. And the same word
or passage can be referenced in more than one apparatus
simultaneously. Linenotes work on a page model, because all relevant
information is given at a glance. Looking at a page, one knows which
words of text passages have relevant information on the
apparatus(es). Using the model of the infinite text, there are some
issues, unless one reconstructs the page model on a screen model (I
mean, that each portion of body text displayed in the screen has also
the apparatus(es) included on that same screen). These issues are:
which words or text passages have additional information, how to
distinguish between references to different apparatuses and how to
access to each of these different apparatuses. Maybe marking the text
with different features might be a way to distinguish them (colors,
underline or a mixture of both). And enabling contextual information
is the way to workaround these issues. But I wonder how this is
really helpful in practice.
Sorry, but I'm afraid I'm a bit skeptical about this. Probably I'm
wrong, but I think it will take some time before having an ePub file
containing the electronic version of a critical edition.
I think you misunderstand. I'm absolutely not interested in epub. I'm
not arguing against printed output per se
(or electronic representations of printed output such as pdf). But it
has severe limitations that we need to transcend. I take as an example
the text that I'm currently re-reading, Ovid's Metamorphoses in the new
edition by R. Tarrant, published in 2004. There are more than 400
complete medieval manuscripts of this text. As things stand now, with a
printed edition, no editor can investigate all of them. No editor can
record in his apparatus the readings of all the manuscripts he has
consulted. No editor can record all the data of the secondary
transmission (quotations, allusions, translations etc.) But Tarrant has
certainly much more information available than he can include in his
edition. Some of it is published in his articles and books, some of it
is included in the private collations of manuscripts which he produced
in order to produce his edition. When he finishes his career and (I
hesitate to write this since he's a friend of mine) his life, most of
this will be lost forever.
Now I describe the way I would like to see a critical edition of Ovid's
Metamorphoses organized: there is a single huge database (as things
stand now, most probably an xml file) which contains every reading in
every manuscript. This file resides in some sort of version control
repository, let's say it uses git. Scholars have write access to this
repository and are constantly filling in new information. Some sort of
peer review process decides which changes will be pushed to the master
repository. Proper markup allows them to fill in anything they consider
important: questions of transmission and textual criticism, grammatical,
metrical, linguistic points. Every single passage is linked against
images of all the manuscripts, so if you're reading this on a device
with access to the web, one click will bring up a picture of the
corresponding passage in every manuscript you want. If you want to see
the text of manuscript X, one click will give you that text. Or the text
and apparatus of all 15th-century manuscripts in French libraries. Or
all lines displaying a certain metrical structure. (That's why the
proper xml structure is so important.) I'm absolutely convinced that
having this information in this sort of format will allow us to make
huge progress in textual criticism (think of the programs that simulate
evolutionary development in biomedicine and apply those to our database!)
This does not mean that printed editions will become useless. If an
accomplished scholar with years of experience in Ovid wants to publish
his edition, he will simply pull the repository at a given moment, he
will then decide what will go into his text and his apparatus (i don't
think that machines will ever be any better than human beings with
regard to critical judgment), and he will then have the result printed.
But again: the printed book will only be a representation of the
information, it will not be identical to the information. With the
proper tools, an editor can decide what this representation should look
like, and that's where considerations about several apparatuses, note
types, indexes and the organization of information come into play. And
that's the area where I see ConTeXt playing an important role because of
its powerful potential to process xml, to produce interactive documents,
to combine text and illustrations.
For the time being, this is a dream, but I'm optimistic we will approach
this dream, slowly, but steadily. In order to do this, however, we have
to understand that the printed book is just a tool, not the end in itself.
All best
Thomas
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
