The key point to a Canonical Text Service (CTS) is that it is canonical, i.e. it refers to a conventionally 'frozen' archive of texts. Of course, issues arise, because even in a 'canonical' corpus like the classical one the author/work/[section or line] hierarchy is sometimes debatable. For example:
1. Author/work: spurious works (or of dubious authorship).
The "Epistula Sapphus" is traditionally considered part of Ovid's Heroides, but this is disputed: it might be spurious. A CTS would still identify it under the Ovid category.
2. Work: debated distinctions between poems in a sylloge.
Some say that Propertius 2.22 is one poem; others, that it must be divided into 2.22a and 2.22b.
3. Verses: also the 'canonical' order of verses can be changed by scholarly discussion.
Think of verse transposition and the insertion/expunction of verses possibly spurious.
However:
a. In an almost completely 'frozen' corpus like that of classical Greek and Latin texts these phenomena are marginal. To be more precise, they are marginal in contemporary print editions, while they're pretty frequent in manuscripts. But a Canonical Text Service is based on a specific 'canon'. In this case, on the Greek and Latin canon as determined by contemporary philology.
b. The goal of a CTS is not to represent the 'real nature' of texts, their identity, boundaries etc., but to provide a practical protocol to refer to data. In other words, we should be prepared to situations like this: if the Prop. 2.22a/2.22b distinction is widely accepted, we should instruct our software not to assume that the second book has 35 poems just because the last poem of Propertius' second book has a CTS identifier like 2.35. It should not be hard to instruct software to be aware of this. However, it may be hard for us, after a standard has been long established and used, to always remain aware of the conventional nature and specific purpose of our protocols (like CTS URNs). After we model reality, we tend to mistake our models for reality. But this is our fault.
Paolo
|