tag:blogger.com,1999:blog-8725958.post5460719897448734265..comments2020-03-06T06:12:56.242-05:00Comments on Scriptio Continua: TEI is a text modelling languageAnonymoushttp://www.blogger.com/profile/05582281819129069158noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8725958.post-86876484890610838172013-09-12T17:03:37.255-04:002013-09-12T17:03:37.255-04:00Hi Desmond, really nice to have your input, even a...Hi Desmond, really nice to have your input, even a couple of years later! You seem to say that TEI compatibility is next to impossible, but I don&#39;t think that&#39;s the case. I do think it entails either agreement to work to the same standards or crosswalking between projects, and I certainly agree that it&#39;s not something you get for free. I&#39;d forgotten about that Bamboo paper, but I look at it and giggle a little hysterically at the idea anyone would think TEI structured bibliography is that simple an animal.<br /><br />I think too that it depends what you mean by &quot;interoperable&quot;. I do agree that projects which seem to have the idea that you can take all the TEI texts in the world, throw them into some sort of bin, and then by some automatic process distill something useful from that are being naïve. I don&#39;t really see the point of that sort of project though...<br /><br />Given your background, you&#39;ll understand that the majority of the texts I deal with (papyri and inscriptions) are your exceptions :-).<br /><br />If I understand your last argument, it&#39;s that TEI is useless because you can&#39;t use it to produce some sort of critical hyperedition where every textual variation is recorded and aligned. I don&#39;t think TEI would be very useful for that sort of project. I can imagine having a TEI base text and recording variants as standoff annotations on that base—and in fact I&#39;ve played around with doing that sort of thing to model manuscript collation—but I don&#39;t think doing the whole thing in TEI would be sensible. Actually, I think it would be nutty. And doomed.<br /><br />But that&#39;s not how critical editions work. An edition is a single reading derived from 1-n sources, where the editor chooses to surface only a subset of the source variations, their own conjectures, and those of earlier editors (and only those they consider relevant) in the apparatus, not the text. TEI is perfectly capable of representing that sort of edition, or an edition of a single manuscript. <br /><br />So I think the variance argument is a red herring. TEI has its flaws, and indeed there are serious problems with some of its encoding recommendations. You don&#39;t get free interoperability with it and it&#39;s not suitable for every text-based project. None of that makes it useless though. <br /><br />Thanks again for taking the time to reply to an old blog post! I enjoy thinking about this stuff and would love to continue the discussion.Anonymoushttps://www.blogger.com/profile/05582281819129069158noreply@blogger.comtag:blogger.com,1999:blog-8725958.post-4096707095385591352013-09-12T15:15:38.978-04:002013-09-12T15:15:38.978-04:00I realise this post is really cold now, but I must...I realise this post is really cold now, but I must disagree with your assessment of TEI interoperability: &quot;Compatibility is certainly achievable if both documents follow the same set of conventions&quot; is I think is a tad ambitious. Documents, after all, don&#39;t follow anything. It is people that follow conventions or not and therein lies the problem. <a href="http://www.tei-c.org/About/Archive_new/ETE/Preview/durusau.xml" rel="nofollow">Patrick Durusau points out that there are more than 4 million ways to transcribe a single sentence taken from a printed book using the TEI Guidelines</a>. Given that kind of variation the chance that any two people would encode the same features in the same way is just about zero. As <a href="http://people.lis.illinois.edu/~renear/clip2005.pdf" rel="nofollow">Alan Renear pointed out</a>, a TEI tag added to describe an analog document has a completely different illocutionary force to exactly the same tag created by the author of an electronic document as part of his text. The first tag is pure interpretation, the second is pure fact. So in my view TEI texts cannot ever be interoperable. It&#39;s funny that a lot of people think they ought to be, or act as if they were. If you look at projects like TextGrid or the British version TextGrid VRE, or the TAPAS project you&#39;ll see this assumption underlies the whole project. But it&#39;s a big mistake. You only have to look at <a href="http://jtei.revues.org/787" rel="nofollow">Project Bamboo to see what happens when you try to make TEI texts interoperate</a>. Or the <a href="http://www.tei-c.org/Vault/SC/scg02.html" rel="nofollow">original grant proposal of the TEI</a> where they make interoperability one of their goals, and then abandon it 25 years later. Or the <a href="http://ariadne.northwestern.edu/mmueller/teiletter.pdf" rel="nofollow">chilling assessment of TEI&#39;s uselessness by the chairman of the TEI board</a>. <br />As for your objection to my supposed &quot;assumption that there is a text independent of the editorial apparatus. Maybe there is sometimes, but I can point at many examples where there is no text, as such, only readings. And a reading is, must be, an interpretive exercise.&quot; I guess you are thinking of fragmentary texts - but they are the exception not the rule. I didn&#39;t ever say that you couldn&#39;t annotate a text containing computed variation. What I said was that although computerised comparison could never be perfect it was still far more accurate than manually created variant recording using embedded markup. The reason is that recording variants using XML may seem to give you more freedom but in fact it powerfully restricts the kinds of variation you can record. What about texts with 100 versions? Or major transpositions? Or variations in the markup itself? Or non-hierarchical variation? You soon get tied up in knots trying to represent that in XML so that the automatic collation works out to be much better. Are you really saying that automatic comparison serves no purpose? I think you mean that you want to annotate variation, and you can, but you don&#39;t need embedded markup to do it. A reading that is literally different from some other reading is just differnt. There&#39;s no interpretation required to see that, and having that information to hand has got to be useful.desmondhttps://www.blogger.com/profile/01722159590093138289noreply@blogger.com
http://philomousos.blogspot.com/feeds/5460719897448734265/comments/default
philomousos.blogspot.com
crawl=CC-MAIN-2020-24
11220
application/http; msgtype=response
sha1:CVKGJQVNNGSZGYCHWV3NAK5MZCTAXDU7
<urn:uuid:72cd66e3-1c85-4e76-ae22-8748fcd00523>
2020-05-26T23:49:51Z
142.250.31.132
application/atom+xml
sha1:GUMQG3DQUFMGHD75MEETJ6TWX6TCLMF6
<urn:uuid:1cb0a389-9e5c-4774-a2d8-362d9fdd49da>
http://philomousos.blogspot.com/feeds/5460719897448734265/comments/default
response
<urn:uuid:6de23239-db93-4af1-bdf5-1fdd3f6a4abd>
isPartOf: CC-MAIN-2020-24
publisher: Common Crawl
description: Wide crawl of the web for May/June 2020
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-190.ec2.internal
software: Apache Nutch 1.16 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/