TEIWiki - User contributions [en]

https://wiki.tei-c.org/api.php?action=feedcontributions&feedformat=atom&user=Mburghart TEIWiki - User contributions [en] 2026-04-19T02:54:59Z User contributions MediaWiki 1.32.0 https://wiki.tei-c.org/index.php?title=Publishing_printed_critical_editions_from_TEI&diff=16421 Publishing printed critical editions from TEI 2018-10-31T00:10:46Z

<p>Mburghart: /* using LaTeX */</p> <hr /> <div>Publishing printed critical editions from TEI encoded files is possible, but requires the use of third-party tools and some specific knowledge. This page aims at providing information on the various ways of producing a camera-ready file, including the usual features of critical editions, i.e. multiple layers of footnotes, and optionally footnotes referencing the line numbers in the text, instead of footnote calls, etc. <br /> <br /> This transformation could be most easily done with XSL FO, but it is unclear whether FO supports the more elaborate options needed in a complex critical edition, like the multiple layers of footnotes or the references to line numbers. Any precision or experience on this welcome. For features unsupported by FO, the recommended solution is to convert the TEI to another format, which allows the publication as wanted. <br /> <br /> <br /> <br /> == TEI to InDesign ==<br /> <br /> http://www.unc.edu/~reedkm/files/TEIPublishingWorkflow_KR.pdf<br /> <br /> InDesign does not support round-tripping (converting back to XML TEI)<br /> <br /> == TEI to PDF / PS ==<br /> <br /> === using LaTeX ===<br /> There are [http://www.tei-c.org/release/doc/tei-xsl-common/profiles/default/latex/to.html TEI to LaTeX stylesheets], with the expectation of processing using XeLaTeX, and they come with a command-line script "teitolatex" for Unix/Linux. But there's a lot more to do there to get the right output.<br /> <br /> ledmac is a LaTeX extension which can be used for this precise purpose. Maybe one can think of using: TEI > XSLT > LaTeX with ledmac > PDF<br /> <br /> Checking this page [http://www.djdekker.net/ledmac/ ''Typesetting Critical Editions with LaTeX''], about ledmac, will provide useful information. <br /> <br /> The [http://teicat.huma-num.fr TEI Critical Apparatus Toolbox] offers a feature with a visual interface guiding users through a transformation of a TEI XML critical edition (parallel segmentation method only) into a PDF, via LaTeX and RELEDMAC. The default transformation can be customised withou any knowledge of LaTeX, but users who know both XSLT and LaTeX also have the option of making advanced changes. <br /> <br /> Example of a printed version of a volume of the Leibniz-Edition (Reihe 8), produced with LaTeX, which can be found as a pdf here: http://nbn-resolving.de/urn:nbn:de:kobv:b4-opus-11675 <br /> Some differences between TUSTEP and LaTeX by comparing the two printed Leibniz volumes:<br /> * TUSTEP can count the lines as well in normal footnotes (margins), whereas LaTeX/ledmac cannot (or at least we haven't found a way to do so). This is however no problem, because you can for example use the package "fnlineno" for that.<br /> * LaTeX has advantages with the math mode, which was extremely helpful in editing the mathematical texts of Leibniz.<br /> <br /> === using ConTeXt ===<br /> ConTeXt is a document processing system which is a TeX macro package created and maintained by Pragma ADE. On ConTeXt wiki (contextgarden) there is a nicely written description of typesetting TEI XML with ConTeXt: [http://wiki.contextgarden.net/TEI_xml] (there is a good succinct description of TEI strenghts and limitations, too).<br /> <br /> === using TUSTEP ===<br /> <br /> Advantage: does the job<br /> <br /> Drawback: very difficult to learn<br /> <br /> The powerful typesetting routines support up to 9 critical apparatuses, layers of footnotes, endnotes, marginal notes, synopses (with individual apparatuses), special characters and character sets etc. A further benefit is that programming and typesetting interact very smoothly and in various directions. Thus, you can enrich the original XML-Markup with page or line references of the printed result automatically, which is useful when electronic and printed editions are supposed to accompany each other. TEI data (as all XML data) can be imported easily into TUSTEP. It treats XML data string based but not as node tree, which might be an advantage and a disadvantage as well. The output is PS or PDF. Therefore TEI > XSLT (to prepare encoding for TUSTEP with XML technologies) > TUSTEP > PDF or TEI <> TUSTEP > PDF are possible workflows respectively. Once the typesetting routine is set up for a specific edition it can be plugged as black box into XML-environments (e.g. Oxygen) to "typeset-on-demand" during XML-encoding.<br /> The shortcomings: Learning TUSTEP is not a walk in the park and there are no prepackaged solutions or patterns or cookbooks. A scholar with no or minor technical background will need support to get things work.<br /> For more information in English see http://www.tustep.uni-tuebingen.de/tustep_eng.html, which covers a list of scholarly edition made with use of TUSTEP. <br /> For editions produced with TUSTEP have a look at http://www.uni-muenster.de/Leibniz/bd_1_1_2009.html or http://www.albertus-magnus-institut.de/MeteoraSpecimen.pdf for example.<br /> <br /> With TUSTEP roundtripping is no problem. Sometimes one just wants to have the information about page- and linebreaks within your outgoing XML, in order to show that information later in an online representation or use it while comparing the output with further witnesses. Then how do you do that? Here you need a system that can give you a XML-output with just that information.<br /> <br /> Just besides, TUSTEP is much more than a publishing system. Within the scope of a critical edition you usually need to enrich data in various forms, compare witnesses, automatically generate apparatuses and indexes etc. TUSTEP even comprises a very powerful scripting language of it's own, Tuscript.<br /> <br /> === using XEP ===<br /> <br /> Advantage: very good<br /> <br /> Drawback: expensive<br /> <br /> http://www.renderx.com/tools/xep.html<br /> <br /> TEI -> XSLT -> XSL:FO -> XEP -> PDF<br /> <br /> Nota: FOP http://xmlgraphics.apache.org/fop/ can be a free alternative, depending on your needs (it does not implement all XSL FO)</div>

Mburghart https://wiki.tei-c.org/index.php?title=Editor_for_teaching_TEI_-_features&diff=15031 Editor for teaching TEI - features 2016-07-11T11:34:23Z

<p>Mburghart: /* 2. Ideally... */</p> <hr /> <div>[[Category:Editing tools]]<br /> __NOTOC__<br /> This is an attempt at listing the minimal set of features that a TEI editor '''used for teaching purposes''' should have.<br /> <br /> === 1. Basic required features ===<br /> 1.1. multiplatform<br /> <br>1.2. validation with Relax NG<br /> <br>1.3. continuous validation<br /> <br>1.4. contextual suggestions (following the schema)<br /> <br>1.5. XSLT 2 transformation (Saxon HE? that would offer XQuery as well)<br /> <br>1.6. easy to use<br /> <br>1.7. free for students (as in beer) <br /> <br>1.8. syntax highlighting for XML (that naturally includes XSLT)<br /> <br>1.9. XPath queries<br /> <br /> === Comments, justification, discussion ===<br /> (please use the hard-set numbers; note that discussion is still running at [[TEI-L]]; everyone is welcome to modify this page)<br /> * Item 1.7. could imply a very moderate bulk licensing fee paid by the institution that provides training; we have to bear in mind that the entire discussion started because of a department refusing to pay regular licensing fees (deemed as too high) for a course that lasts a semester<br /> * "I would move your 2.2 and 2.3 (xpath query and help pop ups) up to the essential category. These are features I use all the time when teaching." (Lou Burnard)<br /> ** just noting that a pop-up is only one of the possibilities (one can imagine a side panel appearing due to a keystroke sequence), but the discussion started originally from how oXygen could be dumbed down; I try to make the lists and considerations here slightly more general ([[User:Piotr Banski|Piotr]])<br /> ** very true Piotr! Whatever the interface, I agree with Lou that it's an important feature. <br /> * 2.5: "From a sustainability perspective, I would add "open-source" to the feature set, maybe in the "2. Ideally..." section. This may not be much pertinent from the short term opportunistic point of view of a student (or a teacher), but may help consolidate tools appropriateness to TEI for the long term, which is what TEI is all about." (Serge Heiden)<br /> * I have moved XPath queries from "Ideally" to "Basic features". In my experience, that's an essential point for students (and people in general). (Marjorie)<br /> * Could we preserve the possibility to use a third-party commercial tool, like Saxon PE, if the users need them and want to acquire them?<br /> <br /> === 2. Ideally... ===<br /> 2.1. free (as in beer) <br /> <br>2.2. Inline documentation (i.e. the little pop-ups with the definition of the element)<br /> <br>2.3. pre-set templates (example?)<br /> <br>2.4. syntax highlighting for XQuery<br /> <br>2.5. open source<br /> <br>2.6. validation with Relax NG '''based on the xml-model PI in the document'''<br /> <br>2.7. possibility to auto-update the TEI schema at each new release<br /> <br /> === 3. Features that can be eliminated from a "teaching editor" in order to decrease its cost ===<br /> 3.1. No XSLT 3 (as a consequence of the fact that no commercial tool such as Saxon PE/EE could be used in such an editor)<br /> <br>3.2. No need for XSLT or XQuery debuggers<br /> <br>3.3. no need for database connectivity<br /> <br>3.4. no need for a built-in SVN (etc.) client<br /> <br>3.5. no need for a Tree Editor such as the one offered by oXygen<br /> <br>3.6. no need for Compare Files/Directories tools <br /> <br>3.7. no need for big-file editor or big-file support in general<br /> <br>3.8. no need for syntax highlighting and editing support for some file types which are not XML-based (JavaScript, CSS, JSON, etc.).<br /> <br /> <br /> === Notes ===<br /> The impetus for establishing the above came from a sub-thread on the [[TEI-L]] list bulleted by the following messages: [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;fcdcab72.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;af28895d.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;83b06464.1607]. The idea is to see whether the community can agree on a single feature set that a dumbed-down commercial editor can implement is a "student version" with an appropriate license.<br /> Or, as Martin Holmes puts it, we want to "arrive at something which would be utterly useless for the likes of me, and quite frustrating for serious users, but perfectly functional for teaching introductory XML encoding classes over a few months."</div>

Mburghart https://wiki.tei-c.org/index.php?title=Editor_for_teaching_TEI_-_features&diff=15030 Editor for teaching TEI - features 2016-07-11T11:32:40Z

<p>Mburghart: /* Comments, justification, discussion */</p> <hr /> <div>[[Category:Editing tools]]<br /> __NOTOC__<br /> This is an attempt at listing the minimal set of features that a TEI editor '''used for teaching purposes''' should have.<br /> <br /> === 1. Basic required features ===<br /> 1.1. multiplatform<br /> <br>1.2. validation with Relax NG<br /> <br>1.3. continuous validation<br /> <br>1.4. contextual suggestions (following the schema)<br /> <br>1.5. XSLT 2 transformation (Saxon HE? that would offer XQuery as well)<br /> <br>1.6. easy to use<br /> <br>1.7. free for students (as in beer) <br /> <br>1.8. syntax highlighting for XML (that naturally includes XSLT)<br /> <br>1.9. XPath queries<br /> <br /> === Comments, justification, discussion ===<br /> (please use the hard-set numbers; note that discussion is still running at [[TEI-L]]; everyone is welcome to modify this page)<br /> * Item 1.7. could imply a very moderate bulk licensing fee paid by the institution that provides training; we have to bear in mind that the entire discussion started because of a department refusing to pay regular licensing fees (deemed as too high) for a course that lasts a semester<br /> * "I would move your 2.2 and 2.3 (xpath query and help pop ups) up to the essential category. These are features I use all the time when teaching." (Lou Burnard)<br /> ** just noting that a pop-up is only one of the possibilities (one can imagine a side panel appearing due to a keystroke sequence), but the discussion started originally from how oXygen could be dumbed down; I try to make the lists and considerations here slightly more general ([[User:Piotr Banski|Piotr]])<br /> ** very true Piotr! Whatever the interface, I agree with Lou that it's an important feature. <br /> * 2.5: "From a sustainability perspective, I would add "open-source" to the feature set, maybe in the "2. Ideally..." section. This may not be much pertinent from the short term opportunistic point of view of a student (or a teacher), but may help consolidate tools appropriateness to TEI for the long term, which is what TEI is all about." (Serge Heiden)<br /> * I have moved XPath queries from "Ideally" to "Basic features". In my experience, that's an essential point for students (and people in general). (Marjorie)<br /> * Could we preserve the possibility to use a third-party commercial tool, like Saxon PE, if the users need them and want to acquire them?<br /> <br /> === 2. Ideally... ===<br /> 2.1. free (as in beer) <br /> <br>2.2. Inline documentation (i.e. the little pop-ups with the definition of the element)<br /> <br>2.3. pre-set templates (example?)<br /> <br>2.4. syntax highlighting for XQuery<br /> <br>2.5. open source<br /> <br>2.6. validation with Relax NG '''based on the xml-model PI in the document'''<br /> <br /> === 3. Features that can be eliminated from a "teaching editor" in order to decrease its cost ===<br /> 3.1. No XSLT 3 (as a consequence of the fact that no commercial tool such as Saxon PE/EE could be used in such an editor)<br /> <br>3.2. No need for XSLT or XQuery debuggers<br /> <br>3.3. no need for database connectivity<br /> <br>3.4. no need for a built-in SVN (etc.) client<br /> <br>3.5. no need for a Tree Editor such as the one offered by oXygen<br /> <br>3.6. no need for Compare Files/Directories tools <br /> <br>3.7. no need for big-file editor or big-file support in general<br /> <br>3.8. no need for syntax highlighting and editing support for some file types which are not XML-based (JavaScript, CSS, JSON, etc.).<br /> <br /> <br /> === Notes ===<br /> The impetus for establishing the above came from a sub-thread on the [[TEI-L]] list bulleted by the following messages: [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;fcdcab72.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;af28895d.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;83b06464.1607]. The idea is to see whether the community can agree on a single feature set that a dumbed-down commercial editor can implement is a "student version" with an appropriate license.<br /> Or, as Martin Holmes puts it, we want to "arrive at something which would be utterly useless for the likes of me, and quite frustrating for serious users, but perfectly functional for teaching introductory XML encoding classes over a few months."</div>

Mburghart https://wiki.tei-c.org/index.php?title=Editor_for_teaching_TEI_-_features&diff=15029 Editor for teaching TEI - features 2016-07-11T11:31:01Z

<p>Mburghart: /* Comments, justification, discussion */</p> <hr /> <div>[[Category:Editing tools]]<br /> __NOTOC__<br /> This is an attempt at listing the minimal set of features that a TEI editor '''used for teaching purposes''' should have.<br /> <br /> === 1. Basic required features ===<br /> 1.1. multiplatform<br /> <br>1.2. validation with Relax NG<br /> <br>1.3. continuous validation<br /> <br>1.4. contextual suggestions (following the schema)<br /> <br>1.5. XSLT 2 transformation (Saxon HE? that would offer XQuery as well)<br /> <br>1.6. easy to use<br /> <br>1.7. free for students (as in beer) <br /> <br>1.8. syntax highlighting for XML (that naturally includes XSLT)<br /> <br>1.9. XPath queries<br /> <br /> === Comments, justification, discussion ===<br /> (please use the hard-set numbers; note that discussion is still running at [[TEI-L]]; everyone is welcome to modify this page)<br /> * Item 1.7. could imply a very moderate bulk licensing fee paid by the institution that provides training; we have to bear in mind that the entire discussion started because of a department refusing to pay regular licensing fees (deemed as too high) for a course that lasts a semester<br /> * "I would move your 2.2 and 2.3 (xpath query and help pop ups) up to the essential category. These are features I use all the time when teaching." (Lou Burnard)<br /> ** just noting that a pop-up is only one of the possibilities (one can imagine a side panel appearing due to a keystroke sequence), but the discussion started originally from how oXygen could be dumbed down; I try to make the lists and considerations here slightly more general ([[User:Piotr Banski|Piotr]])<br /> ** very true Piotr! Whatever the interface, I agree with Lou that it's an important feature. <br /> * 2.5: "From a sustainability perspective, I would add "open-source" to the feature set, maybe in the "2. Ideally..." section. This may not be much pertinent from the short term opportunistic point of view of a student (or a teacher), but may help consolidate tools appropriateness to TEI for the long term, which is what TEI is all about." (Serge Heiden)<br /> * I have moved XPath queries from "Ideally" to "Basic features". In my experience, that's an essential point for students (and people in general). (Marjorie)<br /> <br /> === 2. Ideally... ===<br /> 2.1. free (as in beer) <br /> <br>2.2. Inline documentation (i.e. the little pop-ups with the definition of the element)<br /> <br>2.3. pre-set templates (example?)<br /> <br>2.4. syntax highlighting for XQuery<br /> <br>2.5. open source<br /> <br>2.6. validation with Relax NG '''based on the xml-model PI in the document'''<br /> <br /> === 3. Features that can be eliminated from a "teaching editor" in order to decrease its cost ===<br /> 3.1. No XSLT 3 (as a consequence of the fact that no commercial tool such as Saxon PE/EE could be used in such an editor)<br /> <br>3.2. No need for XSLT or XQuery debuggers<br /> <br>3.3. no need for database connectivity<br /> <br>3.4. no need for a built-in SVN (etc.) client<br /> <br>3.5. no need for a Tree Editor such as the one offered by oXygen<br /> <br>3.6. no need for Compare Files/Directories tools <br /> <br>3.7. no need for big-file editor or big-file support in general<br /> <br>3.8. no need for syntax highlighting and editing support for some file types which are not XML-based (JavaScript, CSS, JSON, etc.).<br /> <br /> <br /> === Notes ===<br /> The impetus for establishing the above came from a sub-thread on the [[TEI-L]] list bulleted by the following messages: [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;fcdcab72.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;af28895d.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;83b06464.1607]. The idea is to see whether the community can agree on a single feature set that a dumbed-down commercial editor can implement is a "student version" with an appropriate license.<br /> Or, as Martin Holmes puts it, we want to "arrive at something which would be utterly useless for the likes of me, and quite frustrating for serious users, but perfectly functional for teaching introductory XML encoding classes over a few months."</div>

Mburghart https://wiki.tei-c.org/index.php?title=Editor_for_teaching_TEI_-_features&diff=15028 Editor for teaching TEI - features 2016-07-11T11:25:41Z

<p>Mburghart: /* 2. Ideally... */</p> <hr /> <div>[[Category:Editing tools]]<br /> __NOTOC__<br /> This is an attempt at listing the minimal set of features that a TEI editor '''used for teaching purposes''' should have.<br /> <br /> === 1. Basic required features ===<br /> 1.1. multiplatform<br /> <br>1.2. validation with Relax NG<br /> <br>1.3. continuous validation<br /> <br>1.4. contextual suggestions (following the schema)<br /> <br>1.5. XSLT 2 transformation (Saxon HE? that would offer XQuery as well)<br /> <br>1.6. easy to use<br /> <br>1.7. free for students (as in beer) <br /> <br>1.8. syntax highlighting for XML (that naturally includes XSLT)<br /> <br>1.9. XPath queries<br /> <br /> === Comments, justification, discussion ===<br /> (please use the hard-set numbers; note that discussion is still running at [[TEI-L]]; everyone is welcome to modify this page)<br /> * Item 1.7. could imply a very moderate bulk licensing fee paid by the institution that provides training; we have to bear in mind that the entire discussion started because of a department refusing to pay regular licensing fees (deemed as too high) for a course that lasts a semester<br /> * "I would move your 2.2 and 2.3 (xpath query and help pop ups) up to the essential category. These are features I use all the time when teaching." (Lou Burnard)<br /> ** just noting that a pop-up is only one of the possibilities (one can imagine a side panel appearing due to a keystroke sequence), but the discussion started originally from how oXygen could be dumbed down; I try to make the lists and considerations here slightly more general ([[User:Piotr Banski|Piotr]])<br /> * 2.6: "From a sustainability perspective, I would add "open-source" to the feature set, maybe in the "2. Ideally..." section. This may not be much pertinent from the short term opportunistic point of view of a student (or a teacher), but may help consolidate tools appropriateness to TEI for the long term, which is what TEI is all about." (Serge Heiden)<br /> <br /> === 2. Ideally... ===<br /> 2.1. free (as in beer) <br /> <br>2.2. Inline documentation (i.e. the little pop-ups with the definition of the element)<br /> <br>2.3. pre-set templates (example?)<br /> <br>2.4. syntax highlighting for XQuery<br /> <br>2.5. open source<br /> <br>2.6. validation with Relax NG '''based on the xml-model PI in the document'''<br /> <br /> === 3. Features that can be eliminated from a "teaching editor" in order to decrease its cost ===<br /> 3.1. No XSLT 3 (as a consequence of the fact that no commercial tool such as Saxon PE/EE could be used in such an editor)<br /> <br>3.2. No need for XSLT or XQuery debuggers<br /> <br>3.3. no need for database connectivity<br /> <br>3.4. no need for a built-in SVN (etc.) client<br /> <br>3.5. no need for a Tree Editor such as the one offered by oXygen<br /> <br>3.6. no need for Compare Files/Directories tools <br /> <br>3.7. no need for big-file editor or big-file support in general<br /> <br>3.8. no need for syntax highlighting and editing support for some file types which are not XML-based (JavaScript, CSS, JSON, etc.).<br /> <br /> <br /> === Notes ===<br /> The impetus for establishing the above came from a sub-thread on the [[TEI-L]] list bulleted by the following messages: [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;fcdcab72.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;af28895d.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;83b06464.1607]. The idea is to see whether the community can agree on a single feature set that a dumbed-down commercial editor can implement is a "student version" with an appropriate license.<br /> Or, as Martin Holmes puts it, we want to "arrive at something which would be utterly useless for the likes of me, and quite frustrating for serious users, but perfectly functional for teaching introductory XML encoding classes over a few months."</div>

Mburghart https://wiki.tei-c.org/index.php?title=Editor_for_teaching_TEI_-_features&diff=15027 Editor for teaching TEI - features 2016-07-11T11:24:53Z

<p>Mburghart: /* 1. Basic required features */</p> <hr /> <div>[[Category:Editing tools]]<br /> __NOTOC__<br /> This is an attempt at listing the minimal set of features that a TEI editor '''used for teaching purposes''' should have.<br /> <br /> === 1. Basic required features ===<br /> 1.1. multiplatform<br /> <br>1.2. validation with Relax NG<br /> <br>1.3. continuous validation<br /> <br>1.4. contextual suggestions (following the schema)<br /> <br>1.5. XSLT 2 transformation (Saxon HE? that would offer XQuery as well)<br /> <br>1.6. easy to use<br /> <br>1.7. free for students (as in beer) <br /> <br>1.8. syntax highlighting for XML (that naturally includes XSLT)<br /> <br>1.9. XPath queries<br /> <br /> === Comments, justification, discussion ===<br /> (please use the hard-set numbers; note that discussion is still running at [[TEI-L]]; everyone is welcome to modify this page)<br /> * Item 1.7. could imply a very moderate bulk licensing fee paid by the institution that provides training; we have to bear in mind that the entire discussion started because of a department refusing to pay regular licensing fees (deemed as too high) for a course that lasts a semester<br /> * "I would move your 2.2 and 2.3 (xpath query and help pop ups) up to the essential category. These are features I use all the time when teaching." (Lou Burnard)<br /> ** just noting that a pop-up is only one of the possibilities (one can imagine a side panel appearing due to a keystroke sequence), but the discussion started originally from how oXygen could be dumbed down; I try to make the lists and considerations here slightly more general ([[User:Piotr Banski|Piotr]])<br /> * 2.6: "From a sustainability perspective, I would add "open-source" to the feature set, maybe in the "2. Ideally..." section. This may not be much pertinent from the short term opportunistic point of view of a student (or a teacher), but may help consolidate tools appropriateness to TEI for the long term, which is what TEI is all about." (Serge Heiden)<br /> <br /> === 2. Ideally... ===<br /> 2.1. free (as in beer) <br /> <br>2.2. XPath query<br /> <br>2.3. Inline documentation (i.e. the little pop-ups with the definition of the element)<br /> <br>2.4. pre-set templates (example?)<br /> <br>2.5. syntax highlighting for XQuery<br /> <br>2.6. open source<br /> <br>2.7. validation with Relax NG '''based on the xml-model PI in the document'''<br /> <br /> <br /> === 3. Features that can be eliminated from a "teaching editor" in order to decrease its cost ===<br /> 3.1. No XSLT 3 (as a consequence of the fact that no commercial tool such as Saxon PE/EE could be used in such an editor)<br /> <br>3.2. No need for XSLT or XQuery debuggers<br /> <br>3.3. no need for database connectivity<br /> <br>3.4. no need for a built-in SVN (etc.) client<br /> <br>3.5. no need for a Tree Editor such as the one offered by oXygen<br /> <br>3.6. no need for Compare Files/Directories tools <br /> <br>3.7. no need for big-file editor or big-file support in general<br /> <br>3.8. no need for syntax highlighting and editing support for some file types which are not XML-based (JavaScript, CSS, JSON, etc.).<br /> <br /> <br /> === Notes ===<br /> The impetus for establishing the above came from a sub-thread on the [[TEI-L]] list bulleted by the following messages: [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;fcdcab72.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;af28895d.1607], [https://listserv.brown.edu/archives/cgi-bin/wa?A2=tei-l;83b06464.1607]. The idea is to see whether the community can agree on a single feature set that a dumbed-down commercial editor can implement is a "student version" with an appropriate license.<br /> Or, as Martin Holmes puts it, we want to "arrive at something which would be utterly useless for the likes of me, and quite frustrating for serious users, but perfectly functional for teaching introductory XML encoding classes over a few months."</div>

Mburghart https://wiki.tei-c.org/index.php?title=EXist&diff=13136 EXist 2014-04-04T00:34:18Z

<p>Mburghart: /* Sample implementations */</p> <hr /> <div>[[Category:Tools]]<br /> <br /> [[Category:Querying tools]]<br /> [[Category:Publishing and delivery tools]]<br /> [[Category:XQuery]]<br /> <br /> == Synopsis ==<br /> <br /> [http://exist-db.org eXist-db] is an open source database management system built using [http://en.wikipedia.org/wiki/XML XML] technology. It stores XML data according to the XML data model and features efficient, index-based XQuery processing.<br /> <br /> eXist-db supports many [http://en.wikipedia.org/wiki/Web_2 Web 2.0] technology standards, making<br /> it an excellent platform for developing web-based applications: <br /> <br /> *Technologies: [http://www.w3.org/TR/xquery-30/ XQuery 3.0], [http://www.w3.org/TR/xpath-30/ XPath 3.0], [http://www.w3.org/TR/xslt20/ XSLT 2.0] (based on [http://www.saxonica.com/ Saxon]), XForms 1.1 (based on [http://www.betterForm.de betterForm], [http://www.orbeon.com Orbeon] or [http://www.agencexml.com/xsltforms XSLTForms]) XProc, JSON and JSONP.<br /> <br /> *Interfaces: [http://en.wikipedia.org/wiki/Representational_State_Transfer REST], [http://exquery.github.io/exquery/exquery-restxq-specification/restxq-1.0-specification.html RESTXQ], [http://www.webdav.org/ WebDAV], [http://www.w3.org/TR/soap/ SOAP], [http://en.wikipedia.org/wiki/XML-RPC XML-RPC], and [http://en.wikipedia.org/wiki/Atom_(standard) Atom Publishing Protocol]<br /> <br /> *XML database specific features: [http://xmldb-org.sourceforge.net/xupdate/index.html XML:DB], [http://xmldb-org.sourceforge.net/xupdate/ XUpdate], [http://exist.sourceforge.net/update_ext.html XQuery update extensions] (to be aligned with the new [http://www.w3.org/TR/xquery-update-10/ XQuery Update Facility 1.0]).<br /> <br /> The 1.4 version added a new full text index based on [http://lucene.apache.org/java/docs/index.html Apache Lucene], a lightweight [http://en.wikipedia.org/wiki/Rewrite_engine URL rewriting] and [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model–view–controller] framework, as well as support for [http://xproc.org/ XProc]. With version 1.4, the XQuery engine has seen a major redesign, resulting in improved performance.<br /> <br /> The [http://exist.sourceforge.net/download.html 2.0 version] completely redesigned the Security subsystem introducing Access Control Lists and multiple realm authentication, and also introduced a re-write of the WebDAV Server making it more widely compatible with clients. In addition hundreds of bugfixes and performance improvements have been made since the 1.4 release.<br /> <br /> eXist-db is highly compliant with the [http://www.w3.org/TR/xquery/ XQuery standard] (current [http://www.w3.org/XML/Query/test-suite/ XQuery Test Suite] score is [http://www.w3.org/XML/Query/test-suite/XQTSReportSimple.html 99.4%]).<br /> <br /> The query engine is extensible and features a large collection of [http://demo.exist-db.org/exist/xquery/functions.xql XQuery Function Modules].<br /> <br /> eXist-db provides a powerful environment for the development of web applications<br /> based on XQuery and related standards. Entire web applications can be written in<br /> XQuery, using XSLT, XHTML, CSS and Javascript (for AJAX functionality). <br /> <br /> <br /> <br /> == Features ==<br /> * Persistent storing and indexing of the XML documents<br /> * Database administration functions (data management, backup, recoveries) <br /> * Management of the stored documents in collections<br /> * XQuery engine with extentions for full-text search<br /> * Support for XQuery, XSLT, XInclude and XPointer (partial), XUpdate, XSLT and XProc<br /> * [http://xmldb-org.sourceforge.net/xapi/ XML:DB API]<br /> * Use of network protocols (HTTP/REST, XML-RPC, SOAP, WebDAV)<br /> * Security Access Control Lists on Documents and Collections<br /> * Optional multi-realm integration with LDAP and Active Directory<br /> * Integration with [[ApacheCocoon]]<br /> <br /> == User commentary ==<br /> '''Please sign all comments.'''<br /> <br /> Can be very sensitive to placement of certain files, in particular collection.xconf. Silently ignores config files in the wrong place. [[User:Stuartyeates|Stuartyeates]] 18:15, 26 April 2011 (EDT)<br /> <br /> <br /> == System requirements ==<br /> eXist is written in Java, and therefore requires a [http://java.oracle.com JRE] >= 6. Being a Java application it can be used on most operating systems, including Windows, Linux, Mac OS X, Solaris and FreeBSD and it can be deployed in several ways, as a standalone server application, as a web application inside a servlet container (such as [http://tomcat.apache.org/ Apache Tomcat] or [http://www.mortbay.org/ Jetty]) or as a Java library embedded in a larger application.<br /> <br /> == Source code and licensing ==<br /> eXist is open-source, released under the [http://www.gnu.org/licenses/lgpl-2.1.html GNU LGPL 2.1] license.<br /> <br /> == Support for TEI ==<br /> Joe Wicentowski has a step-by-step introduction with full example files on how to publish TEI texts with eXist, presented at the Digital.Humanities@Oxford Summer School in 2011; see the [http://digital.humanities.ox.ac.uk/dhoxss/2011/sessions.html#xmldb session description] with links to slides and sample material.<br /> <br /> <br /> From the Package Manager, accessed through the eXist Dashboard, one can install the application Shakespeare's Works in TEI from the eXist Public Repository. All Shakespeare's plays from the [http://wordhoard.northwestern.edu/ WordHoard Shakespeare] can be queried with search results displayed in the hit list in KWIC format. See also the [https://github.com/wolfgangmm/ShakespeareDemo GitHub repo] for this application.<br /> <br /> <br /> A TEI module called Matumi is distributed as an eXist application. Matumi is still under development. It requires eXist version 1.5 and is installed from within eXist's Package Reposistory. After installation, it can be accessed from [http://localhost:8080/exist/apps/encyclopedia/ http://localhost:8080/exist/apps/encyclopedia/] on a default installation.<br /> <br /> Matumi is not a full-blown TEI module yet, but it has some notable features, such as the ability to browse by filtering texts and core parts of the markup. It contains faceted search feeding off the markup, making possible "translingual" searches that utilise references added to name forms.<br /> <br /> The app uses XQuery only.<br /> <br /> Installation will store a number of basic TEI documents in the data directory. These files are excepts from encyclopaedias, whence the present orientation of the app.<br /> <br /> If you access through browsing, you can arrange the data by four criteria - books, entry title, subjects and names.<br /> <br /> If you access through search, in order to retrieve some sample results, select lemma and search for "nation", select term and search for "ars", select name and search for "marx", select text and search for "gouvernement", or select key and search for "http://dbpedia.org/page/French_Revolution".<br /> <br /> <br /> There is a comprehensive discussion of optimising eXist/XQuery for TEI on [http://exist.2174344.n4.nabble.com/eXist-optimisation-and-large-TEI-collections-td3487406.html the eXist-open mailing list]<br /> <br /> == Language(s) ==<br /> As detailed above, eXist is itself written in the Java language. However, it enables complete applications to be created without writing any programming code, by just using only XQuery, XSLT, (X)HTML, CSS, XForms, XProc and Javascript. Using the available network interfaces is possible to query eXist not only with Java, and there are already available several modules for other languages ([http://www.bmuskalla.de/DB_eXist/ PHP], [http://query-exist.sourceforge.net/ Perl]) and frameworks ([http://sourceforge.net/projects/springxmldb/ Spring], [http://www.throwingbeans.org/tech/xml_databases_with_exist_and_coldfusion.html ColdFusion], [http://www.zope.org/Members/spilloz/existda Zope]).<br /> The [http://exist-db.org/documentation.html documentation] is available only in english.<br /> <br /> == Documentation ==<br /> [http://exist-db.org/exist/apps/doc/ eXist Documentation]<br /> <br /> == Tech support ==<br /> Technical support for the Open Source product is provided mainly throught the [http://sourceforge.net/mail/?group_id=17691 mailing list]. Being open-source all kind of support and help is made voluntarily and with no obligations. Anyway the support it is very efficient, and almost all the requests are answered in a complete and qualified way.<br /> <br /> Commercial support, consultancy and training is also available from the creators of eXist through [http://www.existsolutions.com eXist Solutions]. eXist Solutions directly support and further the development of eXist.<br /> <br /> == User community ==<br /> The user community is very active and, as for the technical support, the main way of communication is the [http://sourceforge.net/mail/?group_id=17691 mailing list]. Many participants of this list are also part of the TEI Community. There is also a [http://wiki.exist-db.org wiki] and an IRC channel: #existdb at irc.freenode.net.<br /> <br /> In August 2011, a dedicated email list was created on using eXist with TEI resources. For information or to subscribe, go to the [https://lists.sourceforge.net/lists/listinfo/exist-teixml eXist-TEIXML] information page.<br /> <br /> == Sample implementations ==<br /> * [http://mapoflondon.uvic.ca/ The Map of Early Modern London] maps the streets, sites, and significant boundaries of late 16th-century and early 17th-century London. <br /> * [http://www.weber-gesamtausgabe.de/ Carl-Maria-von-Weber-Gesamtausgabe (WeGA)] The correspondence, diaries, writings and works of Carl Maria von Weber <br /> * [http://web.uvic.ca/hrd/achallc2005/abstracts.htm ACH/ALLC 2005: Conference Program and Abstracts]<br /> * [http://graves.uvic.ca/ Diary of Robert Graves]<br /> * [http://193.204.255.27/operaliber/index.php?page=/operaLiber/home OperaLiber]<br /> * [http://www.anglo-norman.net/ The Anglo-Norman Dictionary]<br /> * [http://mith2.umd.edu/eada/ Early Americas Digital Archive]<br /> * [http://buddhistinformatics.ddbc.edu.tw/BZA/ A Digital Comparative Edition and Translation of the Shorter Chinese Saṃyukta Āgama]<br /> * [http://history.state.gov/ Foreign Relations of the United States and other publications of the Office of the Historian, U.S. Department of State]<br /> * [https://github.com/stuartyeates/He-Kupu-Tawhito Multilingual Concordances with TEI]<br /> * [http://vnsletters.org/VNS/ VNS letters online]: digital edition of letters concerning the Belgian literary journal 'Van nu en Straks'<br /> * [http://ctb.kantl.be/corpora/CPWNL/ Corpus Pieter Willems]: searchable facsimile edition of the first Dutch dialect survey ever<br /> * [http://tbe.kantl.be/TBE/xquery/TBEvalidator.xq TEI validator]: interactive validating app for TEI documents using eXist's XML validation functions<br /> * [http://sermones.net/thesaurus/ Sermones.net : éditions électroniques de sermons latins médiévaux]: l’édition électronique de corpus de sermons, dont le premier est la série de sermons de Carême de Jacques de Voragine.<br /> * [http://ciham.ish-lyon.cnrs.fr/paleographie/index.php?l=en Interactive Album of Mediaeval Palaeography]: website for training in practical palaeographical skills.<br /> * [http://bcgenesis.uvic.ca/ The Colonial Despatches of Vancouver Island and British Columbia 1846-1871] contains the original correspondence between the British Colonial Office and the colonies of Vancouver Island and British Columbia. <br /> * [http://mariage.uvic.ca/ Le mariage sous L'Ancien Régime]<br /> * [http://scancan.net/ Scandinavian-Canadian Studies / Études scandinaves au Canada]<br /> * [http://voice.univie.ac.at Vienna-Oxford International Corpus of English]: a corpus of transcripts of spoken ELF interactions in TEI format.<br /> <br /> <br /> <br /> == Current version number and date of release ==<br /> Current stable release: eXist 2.0 revision 18252 - 2013-02-07<br /> <br /> == How to download ==<br /> Download an installer for the current stable version (version 2.1, July 2013) from the [http://www.exist-db.org/exist/apps/homepage/index.html#subscriptions eXist Home Page]; clone or download the current trunk version from the [https://github.com/eXist-db/exist eXist GitHub Page].<br /> <br /> == See also ==<br /> * [[Berkeley DB XML]]<br /> * [[Base-X]]<br /> * [[TEI Web Publishing]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=TEI_Cheatsheets&diff=11896 TEI Cheatsheets 2013-04-19T20:15:00Z

<p>Mburghart: /* Which TEI cheatsheets? */</p> <hr /> <div>This page is listing the "cheatsheets" in preparation for various types of tasks or sub-communities of the TEI users community at large. <br /> <br /> ''Started by Marjorie Burghart - April 2013''<br /> <br /> =What are TEI cheatsheets?=<br /> A "TEI cheatsheet" starts from the scholarly experience of the users and offers, without assuming that they have read the Guidelines before, a "translation" of the phenomenon in TEI, or maybe several options when useful and possible, all this with minimal textual glosses but references and pointers to the Guidelines, for those who want to go further. They would be unverbose "best practice" guides, conceived as simple "scholar experience to TEI" dictionaries. <br /> <br /> There is a great deal in the Guidelines that is aimed at people who are not familiar with the Humanities concepts behind the encoding, which is helpful if you come from a different background. But I really think that to a seasoned philologist reading the TEI chapters on the transcription of sources and critical apparatus must be really boring - they already know the theory better than us. That is why I believe many would be grateful if they were given a simple "translation" into TEI lingo. <br /> <br /> <br /> =Why TEI cheatsheets?=<br /> <br /> ==Easing the learning curve==<br /> My feeling is that the Guidelines should be regarded as a reference book for more advanced users, not as the textbook for people starting to learn (or even people who do not really want to learn but just do). There are many different communities of Humanities scholars who use the TEI, and I am assuming that all (most?) of them know what they want to do with their texts, and have their own ways of working with them. My hope is that the cheatsheets, targetting specific Humanities communities or needs, will be a way of making the learning curve less steep for newbies. I hope that this would let people with no experience of XML feel immediately familiar with what the encoding is doing, at no great learning cost. It should get them started quickly, then it'll be up to them to see if they need (or care) to learn more and delve into the Guidelines. <br /> <br /> ==Facilitating the work of tool developpers==<br /> A notable side-effect of the existence of such cheatsheets or "best practice in a nutshell" would be to greatly facilitate the work of tool developpers considering to support TEI as a format in their application. It is currently most difficult for tools developpers to figure how to support TEI, because of the many possible ways of encoding the same phenomenon. Having a clearly defined list of "best practice" guides would make it easier to conform to those practices, and would hopefully boost the number of TEI-aware tools available.<br /> <br /> =Which TEI cheatsheets?=<br /> <br /> There is of course no fixed set, and each sub-community or transversal task could have its cheatsheet. The list below is just a couple of suggestions, please feel free to add to it! <br /> <br /> *[[Critical Editions Cheatsheet]]<br /> This is the task/community that is the closest to my own scholarly experience, and the one about which I first got the idea of creating "cheatsheets". I started this as a blog post, based on my own experience, some discussions on TEI-L or the MS SIG list, and further edited after feedback from users. The result is an example of what I have in mind, but could certainly be expanded further: <br /> [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet]<br /> This cheatsheet should go further than the Critical Apparatus module/chapter of the Guidelines, BTW, and should incorporate phenomena usually present in critical editions like other layers of notes, index of people's names, index of place names, etc.<br /> Please use the [[Critical Editions Cheatsheet]] page on this Wiki to suggest phenomena that should be treated, and ideally how they should be encoded (but it is not mandatory, you can of course simply list the phenomena and wait for the community to come up with encoding recommendations. <br /> <br /> *[[Annotation Cheatsheet]]<br /> I separate this from Critical Editions, because it is very common to want to add scholarly annotations to texts or documents which are not critical editions. This is therefore a transversal task. <br /> Please use the [[Annotation Cheatsheet]] to submit tasks and the best way do perform them. <br /> <br /> *[[Facsimile Linking Cheatsheet]]<br /> You have a digiral facsimile, you have its transcription or annotations about its content, how do you do that in TEI? <br /> Please describe the phenomena / subtasks involved and the best practice to encode them in the [[Facsimile Linking Cheatsheet]]<br /> <br /> *[[Linguistic Encoding Cheatsheet]]<br /> This is not something I am in any way experienced with but I suspect there is some need for cheatsheets in this department. <br /> Please use the [[Linguistic Encoding Cheatsheet]] to submit tasks and the best way do perform them.<br /> <br /> *[[Encoding Patent Bibliographic References]]<br /> <br /> *[[Images Cheatsheet]]<br /> ''You have a facsimile with both textual and non-textual information, how do you encode the non-textual information and connect it with the transcription? I started compiling a similar resource, "[[User_talk:Martin_de_la_Iglesia/A_Guide_to_Images_in_TEI|A Guide to Images in TEI]]", but it might be useful if we could distil that into a Cheatsheet written from an art historian's perspective. --[[User:Martin de la Iglesia|Martin de la Iglesia]] 07:51, 9 April 2013 (EDT)''<br /> <br /> *[[Encoding non-European names]]<br /> ** Arabic names: cf. http://jtei.revues.org/398#tocto3n3<br /> ** Hebrew names: cf. suggestion from Hayim Lapin on TEI-L</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11871 Critical Editions Cheatsheet 2013-04-16T18:09:43Z

<p>Mburghart: /* Index nominum */</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical references and quotations=<br /> <br /> Work in progress: listing the different cases / problems<br /> <br /> <br /> * Sometimes, the quotation is explicit, i. e. following or followed by a reference (for medieval times, only book and chapter, never the verse(s) of course):<br /> <br /> '''Example:''' Matt. XXVI : ''Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum''.<br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> &lt;quote&gt;&lt;ref cRef="Mt 26.3"&gt;Matt. XXVI&lt;/ref&gt; Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum&lt;/quote&gt;<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * Sometimes, the quotation is implicit, with no reference in the original text. <br /> <br /> '''Example:''' Unde dicitur quod ''gentiles uocabant Paulum Mercurium qui erat dux uerbi''. <br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> Unde dicitur quod &lt;quote&gt;gentiles uocabant Paulum Mercurium qui erat dux uerbi&lt;ptr cRef="Act 14.11"/&gt;&lt;/quote&gt;.<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * In all previous cases, the medieval author may have added "tool words" of his own in the quotation, or cut it in two parts, and the additional words should not be displayed the same way: <br /> <br /> Example: Eph. V: ''Eratis enim aliquando'' tenebre, ''nunc autem lux in Domino''.<br /> <br /> * In all previous cases, the author or scribe may have made a blunder and the reference is sometimes erroneous. You could therefore have something like: <br /> <br /> Example: Rom. V: ''Eratis enim aliquando tenebre, nunc autem lux in Domino''.<br /> <br /> * Eventually, the text of the quotation might be different from the text found in the Vulgate to an extent that requires the editor to mention it. This is usually something that belongs in the layer of notes regarding the textual variants, with the exact quote from the Vulgate. <br /> <br /> * There are different Bible versions (Greek LXX, Latin Vulgate or Vetus Latina)<br /> <br /> * There are different historical editions of the same Bible version (like a modern critical Vulgate or the Clementine Vulgate or manuscript X). Even two critical editions of the same Bible version might not follow the same versification (like Swete and Rahlfs for the LXX).<br /> <br /> * The list of abbreviations used for the books of the bibles will vary according to the language, community,etc.<br /> <br /> Recommendation to check Nestle-Aland, Sources chrétiennes, openbible, [https://en.wikipedia.org/wiki/Open_Scripture_Information_Standard OSIS]<br /> Also the list of abbr. in the Fischer-Weber edition of the ''Vulgate''.<br /> <br /> But is it the TEI's role to make recommendation on the set of abbreviations to use? <br /> <br /> * It would be a Good Thing if there was some system for indicating levels of certainty w.r.to scribal biblical citations. E.g.<br /> **A = no shadow of a doubt what is the referent<br /> **B = the most likely of two possibilities<br /> **C = the most likely of three possibilities<br /> **D = no idea what this points to<br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> You could have several levels of "complexity". <br /> <br /> ==Simplest case== <br /> <br /> You just want to mention that "Jesus" in this sentence is a person name. This will not let you compile automatically a full-fledged index nominum, but may be useful for data exploration. <br /> <br /> If you want to markup "Jesus" in the following sentence: ''Jezus z wielką chwałą przyjechał do Jeruzalem...''<br /> <br /> '''Suggestion''': <br /> <br /> &lt;persName&gt;Jezus&lt;/persName&gt; z wielką chwałą przyjechał do Jeruzalem<br /> <br /> ==More complex== <br /> <br /> You want to create a link between this occurrence of a name and a single entry describing a person in index nominum: <br /> <br /> <br /> Example: ''Arthemandus senior comes de Quibor et M[argarita] comitissa uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore.'' <br /> <br /> <br /> '''Suggestion:''' <br /> * In the text: Jezus&lt;/persName&gt;<br /> <br /> &lt;persName ref="#Hartmann4"&gt;Arthemandus senior comes de Quibor&lt;/persName&gt; et &lt;persName ref="#Marg"&gt;M[argarita] <br /> comitissa&lt;/persName&gt; uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore.<br /> <br /> Nota: it is absolutely possible to encode the previous names with more details (for instance, it is possible to encode their titles (count and countess). But here we are assuming that you are only interested in building an ''index nominum'', and those pieces of information are irrelevant for that. <br /> <br /> * Somewhere else in the TEI file, or an external TEI file: encode the person<br /> <br /> &lt;listPerson&gt;<br /> &lt;person xml:id="Hartmann4"&gt;<br /> &lt;persName&gt;Hartmann IV l'Ancien<br /> &lt;roleName&gt;comte de &lt;placeName&gt;Kibourg&lt;/placeName>&lt;/roleName&gt;<br /> &lt;/persName&gt;<br /> &lt;death when="1264-11-27"/&gt;<br /> &lt;/person&gt;<br /> &lt;person xml:id="Marg"&gt;<br /> Marguerite de Savoie (1212-1270 ou 73), fille du comte de Savoie Thomas Ier, et épouse d'Hartmann IV de Kibourg depuis 1218<br /> &lt;/person&gt;<br /> &lt;/listPerson&gt;<br /> <br /> <br /> '''Question:''' <br /> In some instances, you may find a name in your text and not be certain to which person it refers. For instance, a single first name might refer to two or more people in your list of persons. What would be the recommended encoding?<br /> <br /> =Index locorum=<br /> <br /> Same as for the index nominum, but replace persName with placeName, listPerson with listPlace and person with place.</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11870 Critical Editions Cheatsheet 2013-04-16T18:07:44Z

<p>Mburghart: /* Index nominum */</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical references and quotations=<br /> <br /> Work in progress: listing the different cases / problems<br /> <br /> <br /> * Sometimes, the quotation is explicit, i. e. following or followed by a reference (for medieval times, only book and chapter, never the verse(s) of course):<br /> <br /> '''Example:''' Matt. XXVI : ''Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum''.<br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> &lt;quote&gt;&lt;ref cRef="Mt 26.3"&gt;Matt. XXVI&lt;/ref&gt; Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum&lt;/quote&gt;<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * Sometimes, the quotation is implicit, with no reference in the original text. <br /> <br /> '''Example:''' Unde dicitur quod ''gentiles uocabant Paulum Mercurium qui erat dux uerbi''. <br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> Unde dicitur quod &lt;quote&gt;gentiles uocabant Paulum Mercurium qui erat dux uerbi&lt;ptr cRef="Act 14.11"/&gt;&lt;/quote&gt;.<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * In all previous cases, the medieval author may have added "tool words" of his own in the quotation, or cut it in two parts, and the additional words should not be displayed the same way: <br /> <br /> Example: Eph. V: ''Eratis enim aliquando'' tenebre, ''nunc autem lux in Domino''.<br /> <br /> * In all previous cases, the author or scribe may have made a blunder and the reference is sometimes erroneous. You could therefore have something like: <br /> <br /> Example: Rom. V: ''Eratis enim aliquando tenebre, nunc autem lux in Domino''.<br /> <br /> * Eventually, the text of the quotation might be different from the text found in the Vulgate to an extent that requires the editor to mention it. This is usually something that belongs in the layer of notes regarding the textual variants, with the exact quote from the Vulgate. <br /> <br /> * There are different Bible versions (Greek LXX, Latin Vulgate or Vetus Latina)<br /> <br /> * There are different historical editions of the same Bible version (like a modern critical Vulgate or the Clementine Vulgate or manuscript X). Even two critical editions of the same Bible version might not follow the same versification (like Swete and Rahlfs for the LXX).<br /> <br /> * The list of abbreviations used for the books of the bibles will vary according to the language, community,etc.<br /> <br /> Recommendation to check Nestle-Aland, Sources chrétiennes, openbible, [https://en.wikipedia.org/wiki/Open_Scripture_Information_Standard OSIS]<br /> Also the list of abbr. in the Fischer-Weber edition of the ''Vulgate''.<br /> <br /> But is it the TEI's role to make recommendation on the set of abbreviations to use? <br /> <br /> * It would be a Good Thing if there was some system for indicating levels of certainty w.r.to scribal biblical citations. E.g.<br /> **A = no shadow of a doubt what is the referent<br /> **B = the most likely of two possibilities<br /> **C = the most likely of three possibilities<br /> **D = no idea what this points to<br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> If you want to markup "Jesus" in the following sentence: <br /> <br /> Example: Jezus z wielką chwałą przyjechał do Jeruzalem<br /> <br /> You could have several levels of "complication". <br /> <br /> a) Simplest case: you just want to mention that "Jesus" in this sentence is a person name. This will not let you compile automatically a full-fledged index nominum, but may be useful for data exploration. <br /> <br /> '''Suggestion''': <br /> <br /> &lt;persName&gt;Jezus&lt;/persName&gt; z wielką chwałą przyjechał do Jeruzalem<br /> <br /> b) More complex: you want to create a link between this occurrence of a name and a single entry describing a person in index nominum: <br /> <br /> <br /> Example: Arthemandus senior comes de Quibor et M[argarita] comitissa uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore. <br /> <br /> <br /> '''Suggestion:''' <br /> * In the text: Jezus&lt;/persName&gt;<br /> <br /> &lt;persName ref="#Hartmann4"&gt;Arthemandus senior comes de Quibor&lt;/persName&gt; et &lt;persName ref="#Marg"&gt;M[argarita] <br /> comitissa&lt;/persName&gt; uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore.<br /> <br /> Nota: it is absolutely possible to encode the previous names with more details (for instance, it is possible to encode their titles (count and countess). But here we are assuming that you are only interested in building an ''index nominum'', and those pieces of information are irrelevant for that. <br /> <br /> * Somewhere else in the TEI file, or an external TEI file: encode the person<br /> <br /> &lt;listPerson&gt;<br /> &lt;person xml:id="Hartmann4"&gt;<br /> &lt;persName&gt;Hartmann IV l'Ancien<br /> &lt;roleName&gt;comte de &lt;placeName&gt;Kibourg&lt;/placeName>&lt;/roleName&gt;<br /> &lt;/persName&gt;<br /> &lt;death when="1264-11-27"/&gt;<br /> &lt;/person&gt;<br /> &lt;person xml:id="Marg"&gt;<br /> Marguerite de Savoie (1212-1270 ou 73), fille du comte de Savoie Thomas Ier, et épouse d'Hartmann IV de Kibourg depuis 1218<br /> &lt;/person&gt;<br /> &lt;/listPerson&gt;<br /> <br /> <br /> '''Question:''' <br /> In some instances, you may find a name in your text and not be certain to which person it refers. For instance, a single first name might refer to two or more people in your list of persons. What would be the recommended encoding?<br /> <br /> =Index locorum=<br /> <br /> Same as for the index nominum, but replace persName with placeName, listPerson with listPlace and person with place.</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11869 Critical Editions Cheatsheet 2013-04-16T18:07:04Z

<p>Mburghart: /* Index nominum */</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical references and quotations=<br /> <br /> Work in progress: listing the different cases / problems<br /> <br /> <br /> * Sometimes, the quotation is explicit, i. e. following or followed by a reference (for medieval times, only book and chapter, never the verse(s) of course):<br /> <br /> '''Example:''' Matt. XXVI : ''Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum''.<br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> &lt;quote&gt;&lt;ref cRef="Mt 26.3"&gt;Matt. XXVI&lt;/ref&gt; Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum&lt;/quote&gt;<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * Sometimes, the quotation is implicit, with no reference in the original text. <br /> <br /> '''Example:''' Unde dicitur quod ''gentiles uocabant Paulum Mercurium qui erat dux uerbi''. <br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> Unde dicitur quod &lt;quote&gt;gentiles uocabant Paulum Mercurium qui erat dux uerbi&lt;ptr cRef="Act 14.11"/&gt;&lt;/quote&gt;.<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * In all previous cases, the medieval author may have added "tool words" of his own in the quotation, or cut it in two parts, and the additional words should not be displayed the same way: <br /> <br /> Example: Eph. V: ''Eratis enim aliquando'' tenebre, ''nunc autem lux in Domino''.<br /> <br /> * In all previous cases, the author or scribe may have made a blunder and the reference is sometimes erroneous. You could therefore have something like: <br /> <br /> Example: Rom. V: ''Eratis enim aliquando tenebre, nunc autem lux in Domino''.<br /> <br /> * Eventually, the text of the quotation might be different from the text found in the Vulgate to an extent that requires the editor to mention it. This is usually something that belongs in the layer of notes regarding the textual variants, with the exact quote from the Vulgate. <br /> <br /> * There are different Bible versions (Greek LXX, Latin Vulgate or Vetus Latina)<br /> <br /> * There are different historical editions of the same Bible version (like a modern critical Vulgate or the Clementine Vulgate or manuscript X). Even two critical editions of the same Bible version might not follow the same versification (like Swete and Rahlfs for the LXX).<br /> <br /> * The list of abbreviations used for the books of the bibles will vary according to the language, community,etc.<br /> <br /> Recommendation to check Nestle-Aland, Sources chrétiennes, openbible, [https://en.wikipedia.org/wiki/Open_Scripture_Information_Standard OSIS]<br /> Also the list of abbr. in the Fischer-Weber edition of the ''Vulgate''.<br /> <br /> But is it the TEI's role to make recommendation on the set of abbreviations to use? <br /> <br /> * It would be a Good Thing if there was some system for indicating levels of certainty w.r.to scribal biblical citations. E.g.<br /> **A = no shadow of a doubt what is the referent<br /> **B = the most likely of two possibilities<br /> **C = the most likely of three possibilities<br /> **D = no idea what this points to<br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> If you want to markup "Jesus" in the following sentence: <br /> <br /> Example: Jezus z wielką chwałą przyjechał do Jeruzalem<br /> <br /> You could have several levels of "complication". <br /> <br /> a) Simplest case: you just want to mention that "Jesus" in this sentence is a person name. This will not let you compile automatically a full-fledged index nominum, but may be useful for data exploration. <br /> <br /> Suggestion: &lt;persName&gt;Jezus&lt;/persName&gt; z wielką chwałą przyjechał do Jeruzalem<br /> <br /> b) More complex: you want to create a link between this occurrence of a name and a single entry describing a person in index nominum: <br /> <br /> <br /> Example: Arthemandus senior comes de Quibor et M[argarita] comitissa uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore. <br /> <br /> <br /> '''Suggestion:''' <br /> * In the text: Jezus&lt;/persName&gt;<br /> <br /> &lt;persName ref="#Hartmann4"&gt;Arthemandus senior comes de Quibor&lt;/persName&gt; et &lt;persName ref="#Marg"&gt;M[argarita] comitissa&lt;/persName&gt; uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore.<br /> <br /> Nota: it is absolutely possible to encode the previous names with more details (for instance, it is possible to encode their titles (count and countess). But here we are assuming that you are only interested in building an ''index nominum'', and those pieces of information are irrelevant for that. <br /> <br /> * Somewhere else in the TEI file, or an external TEI file: encode the person<br /> <br /> &lt;listPerson&gt;<br /> &lt;person xml:id="Hartmann4"&gt;<br /> &lt;persName&gt;Hartmann IV l'Ancien<br /> &lt;roleName&gt;comte de &lt;placeName&gt;Kibourg&lt;/placeName>&lt;/roleName&gt;<br /> &lt;/persName&gt;<br /> &lt;death when="1264-11-27"/&gt;<br /> &lt;/person&gt;<br /> &lt;person xml:id="Marg"&gt;<br /> Marguerite de Savoie (1212-1270 ou 73), fille du comte de Savoie Thomas Ier, et épouse d'Hartmann IV de Kibourg depuis 1218<br /> &lt;/person&gt;<br /> &lt;/listPerson&gt;<br /> <br /> <br /> '''Question:''' <br /> In some instances, you may find a name in your text and not be certain to which person it refers. For instance, a single first name might refer to two or more people in your list of persons. What would be the recommended encoding?<br /> <br /> =Index locorum=<br /> <br /> Same as for the index nominum, but replace persName with placeName, listPerson with listPlace and person with place.</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11868 Critical Editions Cheatsheet 2013-04-16T18:04:33Z

<p>Mburghart: /* Index nominum */</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical references and quotations=<br /> <br /> Work in progress: listing the different cases / problems<br /> <br /> <br /> * Sometimes, the quotation is explicit, i. e. following or followed by a reference (for medieval times, only book and chapter, never the verse(s) of course):<br /> <br /> '''Example:''' Matt. XXVI : ''Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum''.<br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> &lt;quote&gt;&lt;ref cRef="Mt 26.3"&gt;Matt. XXVI&lt;/ref&gt; Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum&lt;/quote&gt;<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * Sometimes, the quotation is implicit, with no reference in the original text. <br /> <br /> '''Example:''' Unde dicitur quod ''gentiles uocabant Paulum Mercurium qui erat dux uerbi''. <br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> Unde dicitur quod &lt;quote&gt;gentiles uocabant Paulum Mercurium qui erat dux uerbi&lt;ptr cRef="Act 14.11"/&gt;&lt;/quote&gt;.<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * In all previous cases, the medieval author may have added "tool words" of his own in the quotation, or cut it in two parts, and the additional words should not be displayed the same way: <br /> <br /> Example: Eph. V: ''Eratis enim aliquando'' tenebre, ''nunc autem lux in Domino''.<br /> <br /> * In all previous cases, the author or scribe may have made a blunder and the reference is sometimes erroneous. You could therefore have something like: <br /> <br /> Example: Rom. V: ''Eratis enim aliquando tenebre, nunc autem lux in Domino''.<br /> <br /> * Eventually, the text of the quotation might be different from the text found in the Vulgate to an extent that requires the editor to mention it. This is usually something that belongs in the layer of notes regarding the textual variants, with the exact quote from the Vulgate. <br /> <br /> * There are different Bible versions (Greek LXX, Latin Vulgate or Vetus Latina)<br /> <br /> * There are different historical editions of the same Bible version (like a modern critical Vulgate or the Clementine Vulgate or manuscript X). Even two critical editions of the same Bible version might not follow the same versification (like Swete and Rahlfs for the LXX).<br /> <br /> * The list of abbreviations used for the books of the bibles will vary according to the language, community,etc.<br /> <br /> Recommendation to check Nestle-Aland, Sources chrétiennes, openbible, [https://en.wikipedia.org/wiki/Open_Scripture_Information_Standard OSIS]<br /> Also the list of abbr. in the Fischer-Weber edition of the ''Vulgate''.<br /> <br /> But is it the TEI's role to make recommendation on the set of abbreviations to use? <br /> <br /> * It would be a Good Thing if there was some system for indicating levels of certainty w.r.to scribal biblical citations. E.g.<br /> **A = no shadow of a doubt what is the referent<br /> **B = the most likely of two possibilities<br /> **C = the most likely of three possibilities<br /> **D = no idea what this points to<br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> If you want to markup "Jesus" in the following sentence: <br /> <br /> Example: Jezus z wielką chwałą przyjechał do Jeruzalem<br /> <br /> You could have several levels of "complication". <br /> <br /> a) Simplest case: you just want to mention that "Jesus" in this sentence is a person name. This will not let you compile automatically a full-fledged index nominum, but may be useful for data exploration. <br /> <br /> Suggestion: &lt;persName&gt;Jezus&lt;/persName&gt; z wielką chwałą przyjechał do Jeruzalem<br /> <br /> b) More complex: you want to create a link between this occurrence of a name and a single entry describing a person in index nominum: <br /> <br /> <br /> Example: Arthemandus senior comes de Quibor et M[argarita] comitissa uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore. <br /> <br /> <br /> '''Suggestion:''' <br /> * In the text: Jezus&lt;/persName&gt;<br /> <br /> &lt;persName ref="#Hartmann4"&gt;Arthemandus senior comes de Quibor&lt;/persName&gt; et &lt;persName ref="#Marg"&gt;M[argarita] comitissa&lt;/persName&gt; uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore.<br /> <br /> Nota: it is absolutely possible to encode the previous names with more details (for instance, it is possible to encode their titles (count and countess). But here we are assuming that you are only interested in building an ''index nominum'', and those pieces of information are irrelevant for that. <br /> <br /> * Somewhere else in the TEI file, or an external TEI file: encode the person<br /> <br /> &lt;listPerson&gt;<br /> &lt;person xml:id="Hartmann4"&gt;<br /> &lt;persName&gt;Hartmann IV l'Ancien<br /> &lt;roleName&gt;comte de &lt;placeName&gt;Kibourg&lt;/placeName>&lt;/roleName&gt;<br /> &lt;/persName&gt;<br /> &lt;death when="1264-11-27"/&gt;<br /> &lt;/person&gt;<br /> &lt;person xml:id="Marg"&gt;<br /> Marguerite de Savoie (1212-1270 ou 73), fille du comte de Savoie Thomas Ier, et épouse d'Hartmann IV de Kibourg depuis 1218<br /> &lt;/person&gt;<br /> &lt;/listPerson&gt;<br /> <br /> =Index locorum=<br /> <br /> Same as for the index nominum, but replace persName with placeName, listPerson with listPlace and person with place.</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11867 Critical Editions Cheatsheet 2013-04-16T18:03:01Z

<p>Mburghart: /* Index locorum */</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical references and quotations=<br /> <br /> Work in progress: listing the different cases / problems<br /> <br /> <br /> * Sometimes, the quotation is explicit, i. e. following or followed by a reference (for medieval times, only book and chapter, never the verse(s) of course):<br /> <br /> '''Example:''' Matt. XXVI : ''Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum''.<br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> &lt;quote&gt;&lt;ref cRef="Mt 26.3"&gt;Matt. XXVI&lt;/ref&gt; Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum&lt;/quote&gt;<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * Sometimes, the quotation is implicit, with no reference in the original text. <br /> <br /> '''Example:''' Unde dicitur quod ''gentiles uocabant Paulum Mercurium qui erat dux uerbi''. <br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> Unde dicitur quod &lt;quote&gt;gentiles uocabant Paulum Mercurium qui erat dux uerbi&lt;ptr cRef="Act 14.11"/&gt;&lt;/quote&gt;.<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * In all previous cases, the medieval author may have added "tool words" of his own in the quotation, or cut it in two parts, and the additional words should not be displayed the same way: <br /> <br /> Example: Eph. V: ''Eratis enim aliquando'' tenebre, ''nunc autem lux in Domino''.<br /> <br /> * In all previous cases, the author or scribe may have made a blunder and the reference is sometimes erroneous. You could therefore have something like: <br /> <br /> Example: Rom. V: ''Eratis enim aliquando tenebre, nunc autem lux in Domino''.<br /> <br /> * Eventually, the text of the quotation might be different from the text found in the Vulgate to an extent that requires the editor to mention it. This is usually something that belongs in the layer of notes regarding the textual variants, with the exact quote from the Vulgate. <br /> <br /> * There are different Bible versions (Greek LXX, Latin Vulgate or Vetus Latina)<br /> <br /> * There are different historical editions of the same Bible version (like a modern critical Vulgate or the Clementine Vulgate or manuscript X). Even two critical editions of the same Bible version might not follow the same versification (like Swete and Rahlfs for the LXX).<br /> <br /> * The list of abbreviations used for the books of the bibles will vary according to the language, community,etc.<br /> <br /> Recommendation to check Nestle-Aland, Sources chrétiennes, openbible, [https://en.wikipedia.org/wiki/Open_Scripture_Information_Standard OSIS]<br /> Also the list of abbr. in the Fischer-Weber edition of the ''Vulgate''.<br /> <br /> But is it the TEI's role to make recommendation on the set of abbreviations to use? <br /> <br /> * It would be a Good Thing if there was some system for indicating levels of certainty w.r.to scribal biblical citations. E.g.<br /> **A = no shadow of a doubt what is the referent<br /> **B = the most likely of two possibilities<br /> **C = the most likely of three possibilities<br /> **D = no idea what this points to<br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> If you want to markup "Jesus" in the following sentence: <br /> <br /> Example: Jezus z wielką chwałą przyjechał do Jeruzalem<br /> <br /> You could have several levels of "complication". <br /> <br /> a) Simplest case: you just want to mention that "Jesus" in this sentence is a person name. This will not let you compile automatically a full-fledged index nominum, but may be useful for data exploration. <br /> <br /> Suggestion: &lt;persName&gt;Jezus&lt;/persName&gt; z wielką chwałą przyjechał do Jeruzalem<br /> <br /> b) More complex: you want to create a link between this occurrence of a name and a single entry describing a person in index nominum: <br /> <br /> <br /> Example: Arthemandus senior comes de Quibor et M[argarita] comitissa uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore. <br /> <br /> <br /> '''Suggestion:''' <br /> * In the text: Jezus&lt;/persName&gt;<br /> <br /> &lt;persName ref="#Hartmann4"&gt;Arthemandus senior comes de Quibor&lt;/persName&gt; et &lt;persName ref="#Marg"&gt;M[argarita] comitissa&lt;/persName&gt; uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore.<br /> <br /> Nota: it is absolutely possible to encode the previous names with more details (for instance, it is possible to encode their titles (count and countess). But here we are assuming that you are only interested in building an ''index nominum'', and those pieces of information are irremevant for that. <br /> <br /> * Somewhere else in the TEI file, or an external TEI file: encode the person<br /> <br /> &lt;listPerson&gt;<br /> &lt;person xml:id="Hartmann4"&gt;<br /> &lt;persName&gt;Hartmann IV l'Ancien<br /> &lt;roleName&gt;comte de &lt;placeName&gt;Kibourg&lt;/placeName>&lt;/roleName&gt;<br /> &lt;/persName&gt;<br /> &lt;death when="1264-11-27"/&gt;<br /> &lt;/person&gt;<br /> &lt;person xml:id="Marg"&gt;<br /> Marguerite de Savoie (1212-1270 ou 73), fille du comte de Savoie Thomas Ier, et épouse d'Hartmann IV de Kibourg depuis 1218<br /> &lt;/person&gt;<br /> &lt;/listPerson&gt;<br /> <br /> =Index locorum=<br /> <br /> Same as for the index nominum, but replace persName with placeName, listPerson with listPlace and person with place.</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11866 Critical Editions Cheatsheet 2013-04-16T17:57:49Z

<p>Mburghart: /* Index nominum */</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical references and quotations=<br /> <br /> Work in progress: listing the different cases / problems<br /> <br /> <br /> * Sometimes, the quotation is explicit, i. e. following or followed by a reference (for medieval times, only book and chapter, never the verse(s) of course):<br /> <br /> '''Example:''' Matt. XXVI : ''Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum''.<br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> &lt;quote&gt;&lt;ref cRef="Mt 26.3"&gt;Matt. XXVI&lt;/ref&gt; Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum&lt;/quote&gt;<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * Sometimes, the quotation is implicit, with no reference in the original text. <br /> <br /> '''Example:''' Unde dicitur quod ''gentiles uocabant Paulum Mercurium qui erat dux uerbi''. <br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> Unde dicitur quod &lt;quote&gt;gentiles uocabant Paulum Mercurium qui erat dux uerbi&lt;ptr cRef="Act 14.11"/&gt;&lt;/quote&gt;.<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * In all previous cases, the medieval author may have added "tool words" of his own in the quotation, or cut it in two parts, and the additional words should not be displayed the same way: <br /> <br /> Example: Eph. V: ''Eratis enim aliquando'' tenebre, ''nunc autem lux in Domino''.<br /> <br /> * In all previous cases, the author or scribe may have made a blunder and the reference is sometimes erroneous. You could therefore have something like: <br /> <br /> Example: Rom. V: ''Eratis enim aliquando tenebre, nunc autem lux in Domino''.<br /> <br /> * Eventually, the text of the quotation might be different from the text found in the Vulgate to an extent that requires the editor to mention it. This is usually something that belongs in the layer of notes regarding the textual variants, with the exact quote from the Vulgate. <br /> <br /> * There are different Bible versions (Greek LXX, Latin Vulgate or Vetus Latina)<br /> <br /> * There are different historical editions of the same Bible version (like a modern critical Vulgate or the Clementine Vulgate or manuscript X). Even two critical editions of the same Bible version might not follow the same versification (like Swete and Rahlfs for the LXX).<br /> <br /> * The list of abbreviations used for the books of the bibles will vary according to the language, community,etc.<br /> <br /> Recommendation to check Nestle-Aland, Sources chrétiennes, openbible, [https://en.wikipedia.org/wiki/Open_Scripture_Information_Standard OSIS]<br /> Also the list of abbr. in the Fischer-Weber edition of the ''Vulgate''.<br /> <br /> But is it the TEI's role to make recommendation on the set of abbreviations to use? <br /> <br /> * It would be a Good Thing if there was some system for indicating levels of certainty w.r.to scribal biblical citations. E.g.<br /> **A = no shadow of a doubt what is the referent<br /> **B = the most likely of two possibilities<br /> **C = the most likely of three possibilities<br /> **D = no idea what this points to<br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> If you want to markup "Jesus" in the following sentence: <br /> <br /> Example: Jezus z wielką chwałą przyjechał do Jeruzalem<br /> <br /> You could have several levels of "complication". <br /> <br /> a) Simplest case: you just want to mention that "Jesus" in this sentence is a person name. This will not let you compile automatically a full-fledged index nominum, but may be useful for data exploration. <br /> <br /> Suggestion: &lt;persName&gt;Jezus&lt;/persName&gt; z wielką chwałą przyjechał do Jeruzalem<br /> <br /> b) More complex: you want to create a link between this occurrence of a name and a single entry describing a person in index nominum: <br /> <br /> <br /> Example: Arthemandus senior comes de Quibor et M[argarita] comitissa uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore. <br /> <br /> <br /> '''Suggestion:''' <br /> * In the text: Jezus&lt;/persName&gt;<br /> <br /> &lt;persName ref="#Hartmann4"&gt;Arthemandus senior comes de Quibor&lt;/persName&gt; et &lt;persName ref="#Marg"&gt;M[argarita] comitissa&lt;/persName&gt; uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore.<br /> <br /> Nota: it is absolutely possible to encode the previous names with more details (for instance, it is possible to encode their titles (count and countess). But here we are assuming that you are only interested in building an ''index nominum'', and those pieces of information are irremevant for that. <br /> <br /> * Somewhere else in the TEI file, or an external TEI file: encode the person<br /> <br /> &lt;listPerson&gt;<br /> &lt;person xml:id="Hartmann4"&gt;<br /> &lt;persName&gt;Hartmann IV l'Ancien<br /> &lt;roleName&gt;comte de &lt;placeName&gt;Kibourg&lt;/placeName>&lt;/roleName&gt;<br /> &lt;/persName&gt;<br /> &lt;death when="1264-11-27"/&gt;<br /> &lt;/person&gt;<br /> &lt;person xml:id="Marg"&gt;<br /> Marguerite de Savoie (1212-1270 ou 73), fille du comte de Savoie Thomas Ier, et épouse d'Hartmann IV de Kibourg depuis 1218<br /> &lt;/person&gt;<br /> &lt;/listPerson&gt;<br /> <br /> =Index locorum=</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11865 Critical Editions Cheatsheet 2013-04-16T17:51:35Z

<p>Mburghart: /* Index nominum */</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical references and quotations=<br /> <br /> Work in progress: listing the different cases / problems<br /> <br /> <br /> * Sometimes, the quotation is explicit, i. e. following or followed by a reference (for medieval times, only book and chapter, never the verse(s) of course):<br /> <br /> '''Example:''' Matt. XXVI : ''Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum''.<br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> &lt;quote&gt;&lt;ref cRef="Mt 26.3"&gt;Matt. XXVI&lt;/ref&gt; Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum&lt;/quote&gt;<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * Sometimes, the quotation is implicit, with no reference in the original text. <br /> <br /> '''Example:''' Unde dicitur quod ''gentiles uocabant Paulum Mercurium qui erat dux uerbi''. <br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> Unde dicitur quod &lt;quote&gt;gentiles uocabant Paulum Mercurium qui erat dux uerbi&lt;ptr cRef="Act 14.11"/&gt;&lt;/quote&gt;.<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * In all previous cases, the medieval author may have added "tool words" of his own in the quotation, or cut it in two parts, and the additional words should not be displayed the same way: <br /> <br /> Example: Eph. V: ''Eratis enim aliquando'' tenebre, ''nunc autem lux in Domino''.<br /> <br /> * In all previous cases, the author or scribe may have made a blunder and the reference is sometimes erroneous. You could therefore have something like: <br /> <br /> Example: Rom. V: ''Eratis enim aliquando tenebre, nunc autem lux in Domino''.<br /> <br /> * Eventually, the text of the quotation might be different from the text found in the Vulgate to an extent that requires the editor to mention it. This is usually something that belongs in the layer of notes regarding the textual variants, with the exact quote from the Vulgate. <br /> <br /> * There are different Bible versions (Greek LXX, Latin Vulgate or Vetus Latina)<br /> <br /> * There are different historical editions of the same Bible version (like a modern critical Vulgate or the Clementine Vulgate or manuscript X). Even two critical editions of the same Bible version might not follow the same versification (like Swete and Rahlfs for the LXX).<br /> <br /> * The list of abbreviations used for the books of the bibles will vary according to the language, community,etc.<br /> <br /> Recommendation to check Nestle-Aland, Sources chrétiennes, openbible, [https://en.wikipedia.org/wiki/Open_Scripture_Information_Standard OSIS]<br /> Also the list of abbr. in the Fischer-Weber edition of the ''Vulgate''.<br /> <br /> But is it the TEI's role to make recommendation on the set of abbreviations to use? <br /> <br /> * It would be a Good Thing if there was some system for indicating levels of certainty w.r.to scribal biblical citations. E.g.<br /> **A = no shadow of a doubt what is the referent<br /> **B = the most likely of two possibilities<br /> **C = the most likely of three possibilities<br /> **D = no idea what this points to<br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> If you want to markup "Jesus" in the following sentence: <br /> <br /> Example: Jezus z wielką chwałą przyjechał do Jeruzalem<br /> <br /> You could have several levels of "complication". <br /> <br /> a) Simplest case: you just want to mention that "Jesus" in this sentence is a person name. This will not let you compile automatically a full-fledged index nominum, but may be useful for data exploration. <br /> <br /> Suggestion: &lt;persName&gt;Jezus&lt;/persName&gt; z wielką chwałą przyjechał do Jeruzalem<br /> <br /> b) More complex: you want to create a link between this occurrence of a name and a single entry describing a person in index nominum: <br /> <br /> <br /> Example: Arthemandus senior comes de Quibor et M[argarita] comitissa uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore. <br /> <br /> <br /> '''Suggestion:''' <br /> * In the text: Jezus&lt;/persName&gt;<br /> <br /> &lt;persName ref="#Hartmann4"&gt;Arthemandus senior comes de Quibor&lt;/persName&gt; et &lt;persName ref="#Marg"&gt;M[argarita] comitissa&lt;/persName&gt; uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore.<br /> <br /> Nota: it is absolutely possible to encode the previous names with more details (for instance, it is possible to encode their titles (count and countess). But here we are assuming that you are only interested in building an ''index nominum'', and those pieces of information are irremevant for that. <br /> <br /> * Somewhere else in the TEI file, or an external TEI file: encode the person<br /> <br /> &lt;listPerson&gt;<br /> &lt;person xml:id="Hartmann4"&gt;<br /> &lt;persName&gt;Hartmann IV l'Ancien<br /> &lt;roleName&gt;comte de &lt;placeName&gt;Kibourg&lt;/placeName>&lt;/roleName&gt;<br /> &lt;/persName&gt;<br /> &lt;death when="1264-11-27"/&gt;<br /> &lt;/person&gt;<br /> &lt;person xml:id="Marg"&gt;<br /> Marguerite de Savoie (1212-1270 ou 73), fille du comte de Savoie Thomas Ier, et épouse d'Hartmann IV de Kibourg depuis 1218<br /> &lt;/person&gt;<br /> &lt;/listPerson&gt;<br /> <br /> =Index locorum=</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11864 Critical Editions Cheatsheet 2013-04-16T17:50:11Z

<p>Mburghart: /* Index nominum */</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical references and quotations=<br /> <br /> Work in progress: listing the different cases / problems<br /> <br /> <br /> * Sometimes, the quotation is explicit, i. e. following or followed by a reference (for medieval times, only book and chapter, never the verse(s) of course):<br /> <br /> '''Example:''' Matt. XXVI : ''Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum''.<br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> &lt;quote&gt;&lt;ref cRef="Mt 26.3"&gt;Matt. XXVI&lt;/ref&gt; Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum&lt;/quote&gt;<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * Sometimes, the quotation is implicit, with no reference in the original text. <br /> <br /> '''Example:''' Unde dicitur quod ''gentiles uocabant Paulum Mercurium qui erat dux uerbi''. <br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> Unde dicitur quod &lt;quote&gt;gentiles uocabant Paulum Mercurium qui erat dux uerbi&lt;ptr cRef="Act 14.11"/&gt;&lt;/quote&gt;.<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * In all previous cases, the medieval author may have added "tool words" of his own in the quotation, or cut it in two parts, and the additional words should not be displayed the same way: <br /> <br /> Example: Eph. V: ''Eratis enim aliquando'' tenebre, ''nunc autem lux in Domino''.<br /> <br /> * In all previous cases, the author or scribe may have made a blunder and the reference is sometimes erroneous. You could therefore have something like: <br /> <br /> Example: Rom. V: ''Eratis enim aliquando tenebre, nunc autem lux in Domino''.<br /> <br /> * Eventually, the text of the quotation might be different from the text found in the Vulgate to an extent that requires the editor to mention it. This is usually something that belongs in the layer of notes regarding the textual variants, with the exact quote from the Vulgate. <br /> <br /> * There are different Bible versions (Greek LXX, Latin Vulgate or Vetus Latina)<br /> <br /> * There are different historical editions of the same Bible version (like a modern critical Vulgate or the Clementine Vulgate or manuscript X). Even two critical editions of the same Bible version might not follow the same versification (like Swete and Rahlfs for the LXX).<br /> <br /> * The list of abbreviations used for the books of the bibles will vary according to the language, community,etc.<br /> <br /> Recommendation to check Nestle-Aland, Sources chrétiennes, openbible, [https://en.wikipedia.org/wiki/Open_Scripture_Information_Standard OSIS]<br /> Also the list of abbr. in the Fischer-Weber edition of the ''Vulgate''.<br /> <br /> But is it the TEI's role to make recommendation on the set of abbreviations to use? <br /> <br /> * It would be a Good Thing if there was some system for indicating levels of certainty w.r.to scribal biblical citations. E.g.<br /> **A = no shadow of a doubt what is the referent<br /> **B = the most likely of two possibilities<br /> **C = the most likely of three possibilities<br /> **D = no idea what this points to<br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> If you want to markup "Jesus" in the following sentence: <br /> <br /> Example: Jezus z wielką chwałą przyjechał do Jeruzalem<br /> <br /> You could have several levels of "complication". <br /> <br /> a) Simplest case: you just want to mention that "Jesus" in this sentence is a person name. This will not let you compile automatically a full-fledged index nominum, but may be useful for data exploration. <br /> <br /> Suggestion: &lt;persName&gt;Jezus&lt;/persName&gt; z wielką chwałą przyjechał do Jeruzalem<br /> <br /> b) More complex: you want to create a link between this occurrence of a name and a single entry describing a person in index nominum: <br /> <br /> <br /> Example: Arthemandus senior comes de Quibor et M[argarita] comitissa uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore. <br /> <br /> <br /> '''Suggestion:''' <br /> * In the text: Jezus&lt;/persName&gt;<br /> <br /> &lt;persName ref="#Hartmann4"&gt;Arthemandus senior comes de Quibor&lt;/persName&gt; et &lt;persName ref="#Marg"&gt;M[argarita] comitissa&lt;/persName&gt; uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore.<br /> <br /> Nota: it is absolutely possible to encode the previous names with more details (for instance, it is possible to encode their titles (count and countess). But here we are assuming that you are only interested in building an ''index nominum'', and those pieces of information are irremevant for that. <br /> <br /> * Somewhere else in the TEI file, or an external TEI file: encode the person<br /> <br /> &lt;listPerson&gt;<br /> &lt;person xml:id="Hartmann4"&gt;<br /> &lt;persName&gt;Hartmann IV l'Ancien<br /> &lt;roleName&gt;comte de &lt;placeName&gt;Kibourg&lt;/placeName>&lt;/roleName&gt;<br /> &lt;/persName&gt;<br /> &lt;death when="1264-11-27"/&gt;<br /> &lt;person&gt;<br /> &lt;person xml:id="Marg"&gt;<br /> Marguerite de Savoie (1212-1270 ou 73), fille du comte de Savoie Thomas Ier, et épouse d'Hartmann IV de Kibourg depuis 1218<br /> &lt;person&gt;<br /> &lt;/listPerson&gt;<br /> <br /> =Index locorum=</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11863 Critical Editions Cheatsheet 2013-04-16T17:30:43Z

<p>Mburghart: /* Index nominum */</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical references and quotations=<br /> <br /> Work in progress: listing the different cases / problems<br /> <br /> <br /> * Sometimes, the quotation is explicit, i. e. following or followed by a reference (for medieval times, only book and chapter, never the verse(s) of course):<br /> <br /> '''Example:''' Matt. XXVI : ''Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum''.<br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> &lt;quote&gt;&lt;ref cRef="Mt 26.3"&gt;Matt. XXVI&lt;/ref&gt; Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum&lt;/quote&gt;<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * Sometimes, the quotation is implicit, with no reference in the original text. <br /> <br /> '''Example:''' Unde dicitur quod ''gentiles uocabant Paulum Mercurium qui erat dux uerbi''. <br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> Unde dicitur quod &lt;quote&gt;gentiles uocabant Paulum Mercurium qui erat dux uerbi&lt;ptr cRef="Act 14.11"/&gt;&lt;/quote&gt;.<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * In all previous cases, the medieval author may have added "tool words" of his own in the quotation, or cut it in two parts, and the additional words should not be displayed the same way: <br /> <br /> Example: Eph. V: ''Eratis enim aliquando'' tenebre, ''nunc autem lux in Domino''.<br /> <br /> * In all previous cases, the author or scribe may have made a blunder and the reference is sometimes erroneous. You could therefore have something like: <br /> <br /> Example: Rom. V: ''Eratis enim aliquando tenebre, nunc autem lux in Domino''.<br /> <br /> * Eventually, the text of the quotation might be different from the text found in the Vulgate to an extent that requires the editor to mention it. This is usually something that belongs in the layer of notes regarding the textual variants, with the exact quote from the Vulgate. <br /> <br /> * There are different Bible versions (Greek LXX, Latin Vulgate or Vetus Latina)<br /> <br /> * There are different historical editions of the same Bible version (like a modern critical Vulgate or the Clementine Vulgate or manuscript X). Even two critical editions of the same Bible version might not follow the same versification (like Swete and Rahlfs for the LXX).<br /> <br /> * The list of abbreviations used for the books of the bibles will vary according to the language, community,etc.<br /> <br /> Recommendation to check Nestle-Aland, Sources chrétiennes, openbible, [https://en.wikipedia.org/wiki/Open_Scripture_Information_Standard OSIS]<br /> Also the list of abbr. in the Fischer-Weber edition of the ''Vulgate''.<br /> <br /> But is it the TEI's role to make recommendation on the set of abbreviations to use? <br /> <br /> * It would be a Good Thing if there was some system for indicating levels of certainty w.r.to scribal biblical citations. E.g.<br /> **A = no shadow of a doubt what is the referent<br /> **B = the most likely of two possibilities<br /> **C = the most likely of three possibilities<br /> **D = no idea what this points to<br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> If you want to markup "Jesus" in the following sentence: <br /> <br /> Example: Jezus z wielką chwałą przyjechał do Jeruzalem<br /> <br /> You could have several levels of "complication". <br /> <br /> a) Simplest case: you just want to mention that "Jesus" in this sentence is a person name. This will not let you compile automatically a full-fledged index nominum, but may be useful for data exploration. <br /> <br /> Suggestion: &lt;persName&gt;Jezus&lt;/persName&gt; z wielką chwałą przyjechał do Jeruzalem<br /> <br /> b) More complex: you want to create a link between this occurrence of a name and a single entry describing a person in index nominum: <br /> <br /> <br /> Example: Arthemandus senior comes de Quibor et M[argarita] comitissa uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore. <br /> <br /> <br /> '''Suggestion:''' <br /> * In the text: Jezus&lt;/persName&gt;<br /> <br /> &lt;persName ref="#Hartmann4"&gt;Arthemandus senior comes de Quibor&lt;/persName&gt; et &lt;persName ref="#Marg"&gt;M[argarita] comitissa&lt;/persName&gt; uxor illius omnibus presentem paginam intuentibus salutem in omnium salvatore.<br /> <br /> Nota: it is absolutely possible to encode the previous names with more details (for instance, it is possible to encode their titles (count and countess). But here we are assuming that you are only interested in building an ''index nominum'', and those pieces of information are irremevant for that. <br /> <br /> * Somewhere else in the TEI file, or an external TEI file: encode the person<br /> <br /> &lt;listPerson&gt;<br /> &lt;person xml:id="Hartmann4"&gt;<br /> &lt;person&gt;<br /> &lt;person xml:id="Marg"&gt;<br /> &lt;person&gt;<br /> &lt;/listPerson&gt;<br /> <br /> =Index locorum=</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11855 Critical Editions Cheatsheet 2013-04-11T21:18:24Z

<p>Mburghart: /* Biblical references and quotations */</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical references and quotations=<br /> <br /> Work in progress: listing the different cases / problems<br /> <br /> <br /> * Sometimes, the quotation is explicit, i. e. following or followed by a reference (for medieval times, only book and chapter, never the verse(s) of course):<br /> <br /> '''Example:''' Matt. XXVI : ''Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum''.<br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> &lt;quote&gt;&lt;ref cRef="Mt 26.3"&gt;Matt. XXVI&lt;/ref&gt; Nam tunc principes sacerdotum cum senioribus populi congregati sunt in atrium Caiphe principis sacerdotum&lt;/quote&gt;<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * Sometimes, the quotation is implicit, with no reference in the original text. <br /> <br /> '''Example:''' Unde dicitur quod ''gentiles uocabant Paulum Mercurium qui erat dux uerbi''. <br /> <br /> '''Recommendation from Lou:''' <br /> <code language="xml"><br /> Unde dicitur quod &lt;quote&gt;gentiles uocabant Paulum Mercurium qui erat dux uerbi&lt;ptr cRef="Act 14.11"/&gt;&lt;/quote&gt;.<br /> </code><br /> with an associated <cRefPattern> in your teiHeader to decompose the cRef value into its component parts.<br /> <br /> <br /> * In all previous cases, the medieval author may have added "tool words" of his own in the quotation, or cut it in two parts, and the additional words should not be displayed the same way: <br /> <br /> Example: Eph. V: ''Eratis enim aliquando'' tenebre, ''nunc autem lux in Domino''.<br /> <br /> * In all previous cases, the author or scribe may have made a blunder and the reference is sometimes erroneous. You could therefore have something like: <br /> <br /> Example: Rom. V: ''Eratis enim aliquando tenebre, nunc autem lux in Domino''.<br /> <br /> * Eventually, the text of the quotation might be different from the text found in the Vulgate to an extent that requires the editor to mention it. This is usually something that belongs in the layer of notes regarding the textual variants, with the exact quote from the Vulgate. <br /> <br /> * There are different Bible versions (Greek LXX, Latin Vulgate or Vetus Latina)<br /> <br /> * There are different historical editions of the same Bible version (like a modern critical Vulgate or the Clementine Vulgate or manuscript X). Even two critical editions of the same Bible version might not follow the same versification (like Swete and Rahlfs for the LXX).<br /> <br /> * The list of abbreviations used for the books of the bibles will vary according to the language, community,etc.<br /> <br /> Recommendation to check Nestle-Aland, Sources chrétiennes, openbible, [https://en.wikipedia.org/wiki/Open_Scripture_Information_Standard OSIS]<br /> Also the list of abbr. in the Fischer-Weber edition of the ''Vulgate''.<br /> <br /> But is it the TEI's role to make recommendation on the set of abbreviations to use? <br /> <br /> * It would be a Good Thing if there was some system for indicating levels of certainty w.r.to scribal biblical citations. E.g.<br /> **A = no shadow of a doubt what is the referent<br /> **B = the most likely of two possibilities<br /> **C = the most likely of three possibilities<br /> **D = no idea what this points to<br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> <br /> =Index locorum=</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11840 Critical Editions Cheatsheet 2013-04-08T20:37:55Z

<p>Mburghart: /* Biblical reference and quotations */</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical references and quotations=<br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> <br /> =Index locorum=</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Editions_Cheatsheet&diff=11839 Critical Editions Cheatsheet 2013-04-08T20:37:39Z

<p>Mburghart: Created page with "This page draws on the experience of the first of the TEI_Cheatsheets, [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Appa..."</p> <hr /> <div>This page draws on the experience of the first of the [[TEI_Cheatsheets]], [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet "TEI: Critical Apparatus Cheatsheet"] (Marjorie Burghart, 2011).<br /> <br /> Feel free to add other phenomena or tasks that should be covered. Some examples: <br /> <br /> <br /> =Biblical reference and quotations= <br /> <br /> <br /> =Other sources and quotations (implicit and explicit)=<br /> <br /> <br /> =Historical notes=<br /> <br /> <br /> =Index nominum=<br /> <br /> <br /> =Index locorum=</div>

Mburghart https://wiki.tei-c.org/index.php?title=TEI_Cheatsheets&diff=11838 TEI Cheatsheets 2013-04-08T20:35:32Z

<p>Mburghart: /* Why TEI cheatwsheets? */</p> <hr /> <div>This page is listing the "cheatsheets" in preparation for various types of tasks or sub-communities of the TEI users community at large. <br /> <br /> ''Started by Marjorie Burghart - April 2013''<br /> <br /> =What are TEI cheatsheets?=<br /> A "TEI cheatsheet" starts from the scholarly experience of the users and offers, without assuming that they have read the Guidelines before, a "translation" of the phenomenon in TEI, or maybe several options when useful and possible, all this with minimal textual glosses but references and pointers to the Guidelines, for those who want to go further. They would be unverbose "best practice" guides, conceived as simple "scholar experience to TEI" dictionaries. <br /> <br /> There is a great deal in the Guidelines that is aimed at people who are not familiar with the Humanities concepts behind the encoding, which is helpful if you come from a different background. But I really think that to a seasoned philologist reading the TEI chapters on the transcription of sources and critical apparatus must be really boring - they already know the theory better than us. That is why I believe many would be grateful if they were given a simple "translation" into TEI lingo. <br /> <br /> <br /> =Why TEI cheatsheets?=<br /> <br /> ==Easing the learning curve==<br /> My feeling is that the Guidelines should be regarded as a reference book for more advanced users, not as the textbook for people starting to learn (or even people who do not really want to learn but just do). There are many different communities of Humanities scholars who use the TEI, and I am assuming that all (most?) of them know what they want to do with their texts, and have their own ways of working with them. My hope is that the cheatsheets, targetting specific Humanities communities or needs, will be a way of making the learning curve less steep for newbies. I hope that this would let people with no experience of XML feel immediately familiar with what the encoding is doing, at no great learning cost. It should get them started quickly, then it'll be up to them to see if they need (or care) to learn more and delve into the Guidelines. <br /> <br /> ==Facilitating the work of tool developpers==<br /> A notable side-effect of the existence of such cheatsheets or "best practice in a nutshell" would be to greatly facilitate the work of tool developpers considering to support TEI as a format in their application. It is currently most difficult for tools developpers to figure how to support TEI, because of the many possible ways of encoding the same phenomenon. Having a clearly defined list of "best practice" guides would make it easier to conform to those practices, and would hopefully boost the number of TEI-aware tools available.<br /> <br /> =Which TEI cheatsheets?=<br /> <br /> There is of course no fixed set, and each sub-community or transversal task could have its cheatsheet. The list below is just a couple of suggestions, please feel free to add to it! <br /> <br /> *[[Critical Editions Cheatsheet]]<br /> This is the task/community that is the closest to my own scholarly experience, and the one about which I first got the idea of creating "cheatsheets". I started this as a blog post, based on my own experience, some discussions on TEI-L or the MS SIG list, and further edited after feedback from users. The result is an example of what I have in mind, but could certainly be expanded further: <br /> [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet]<br /> This cheatsheet should go further than the Critical Apparatus module/chapter of the Guidelines, BTW, and should incorporate phenomena usually present in critical editions like other layers of notes, index of people's names, index of place names, etc.<br /> Please use the [[Critical Editions Cheatsheet]] page on this Wiki to suggest phenomena that should be treated, and ideally how they should be encoded (but it is not mandatory, you can of course simply list the phenomena and wait for the community to come up with encoding recommendations. <br /> <br /> *[[Annotation Cheatsheet]]<br /> I separate this from Critical Editions, because it is very common to want to add scholarly annotations to texts or documents which are not critical editions. This is therefore a transversal task. <br /> Please use the [[Annotation Cheatsheet]] to submit tasks and the best way do perform them. <br /> <br /> *[[Facsimile Linking Cheatsheet]]<br /> You have a digiral facsimile, you have its transcription or annotations about its content, how do you do that in TEI? <br /> Please describe the phenomena / subtasks involved and the best practice to encode them in the [[Facsimile Linking Cheatsheet]]<br /> <br /> *[[Linguistic Encoding Cheatsheet]]<br /> This is not something I am in any way experienced with but I suspect there is some need for cheatsheets in this department. <br /> Please use the [[Linguistic Encoding Cheatsheet]] to submit tasks and the best way do perform them.</div>

Mburghart https://wiki.tei-c.org/index.php?title=TEI_Cheatsheets&diff=11837 TEI Cheatsheets 2013-04-08T20:30:15Z

<p>Mburghart: </p> <hr /> <div>This page is listing the "cheatsheets" in preparation for various types of tasks or sub-communities of the TEI users community at large. <br /> <br /> ''Started by Marjorie Burghart - April 2013''<br /> <br /> =What are TEI cheatsheets?=<br /> A "TEI cheatsheet" starts from the scholarly experience of the users and offers, without assuming that they have read the Guidelines before, a "translation" of the phenomenon in TEI, or maybe several options when useful and possible, all this with minimal textual glosses but references and pointers to the Guidelines, for those who want to go further. They would be unverbose "best practice" guides, conceived as simple "scholar experience to TEI" dictionaries. <br /> <br /> There is a great deal in the Guidelines that is aimed at people who are not familiar with the Humanities concepts behind the encoding, which is helpful if you come from a different background. But I really think that to a seasoned philologist reading the TEI chapters on the transcription of sources and critical apparatus must be really boring - they already know the theory better than us. That is why I believe many would be grateful if they were given a simple "translation" into TEI lingo. <br /> <br /> <br /> =Why TEI cheatwsheets?=<br /> <br /> ==Easing the learning curve==<br /> My feeling is that the Guidelines should be regarded as a reference book for more advanced users, not as the textbook for people starting to learn (or even people who do not really want to learn but just do). There are many different communities of Humanities scholars who use the TEI, and I am assuming that all (most?) of them know what they want to do with their texts, and have their own ways of working with them. My hope is that the cheatsheets, targetting specific Humanities communities or needs, will be a way of making the learning curve less steep for newbies. I hope that this would let people with no experience of XML feel immediately familiar with what the encoding is doing, at no great learning cost. It should get them started quickly, then it'll be up to them to see if they need (or care) to learn more and delve into the Guidelines. <br /> <br /> ==Facilitating the work of tool developpers==<br /> A notable side-effect of the existence of such cheatsheets or "best practice in a nutshell" would be to greatly facilitate the work of tool developpers considering to support TEI as a format in their application. It is currently most difficult for tools developpers to figure how to support TEI, because of the many possible ways of encoding the same phenomenon. Having a clearly defined list of "best practice" guides would make it easier to conform to those practices, and would hopefully boost the number of TEI-aware tools available. <br /> <br /> <br /> =Which TEI cheatsheets?=<br /> <br /> There is of course no fixed set, and each sub-community or transversal task could have its cheatsheet. The list below is just a couple of suggestions, please feel free to add to it! <br /> <br /> *[[Critical Editions Cheatsheet]]<br /> This is the task/community that is the closest to my own scholarly experience, and the one about which I first got the idea of creating "cheatsheets". I started this as a blog post, based on my own experience, some discussions on TEI-L or the MS SIG list, and further edited after feedback from users. The result is an example of what I have in mind, but could certainly be expanded further: <br /> [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet]<br /> This cheatsheet should go further than the Critical Apparatus module/chapter of the Guidelines, BTW, and should incorporate phenomena usually present in critical editions like other layers of notes, index of people's names, index of place names, etc.<br /> Please use the [[Critical Editions Cheatsheet]] page on this Wiki to suggest phenomena that should be treated, and ideally how they should be encoded (but it is not mandatory, you can of course simply list the phenomena and wait for the community to come up with encoding recommendations. <br /> <br /> *[[Annotation Cheatsheet]]<br /> I separate this from Critical Editions, because it is very common to want to add scholarly annotations to texts or documents which are not critical editions. This is therefore a transversal task. <br /> Please use the [[Annotation Cheatsheet]] to submit tasks and the best way do perform them. <br /> <br /> *[[Facsimile Linking Cheatsheet]]<br /> You have a digiral facsimile, you have its transcription or annotations about its content, how do you do that in TEI? <br /> Please describe the phenomena / subtasks involved and the best practice to encode them in the [[Facsimile Linking Cheatsheet]]<br /> <br /> *[[Linguistic Encoding Cheatsheet]]<br /> This is not something I am in any way experienced with but I suspect there is some need for cheatsheets in this department. <br /> Please use the [[Linguistic Encoding Cheatsheet]] to submit tasks and the best way do perform them.</div>

Mburghart https://wiki.tei-c.org/index.php?title=TEI_Cheatsheets&diff=11836 TEI Cheatsheets 2013-04-08T20:29:55Z

<p>Mburghart: Created page with "This page is listing the "cheatsheets" in preparation for various types of tasks or sub-communities of the TEI users community at large. ''Started by Marjorie Burghart - April 2..."</p> <hr /> <div>This page is listing the "cheatsheets" in preparation for various types of tasks or sub-communities of the TEI users community at large. <br /> ''Started by Marjorie Burghart - April 2013''<br /> <br /> =What are TEI cheatsheets?=<br /> A "TEI cheatsheet" starts from the scholarly experience of the users and offers, without assuming that they have read the Guidelines before, a "translation" of the phenomenon in TEI, or maybe several options when useful and possible, all this with minimal textual glosses but references and pointers to the Guidelines, for those who want to go further. They would be unverbose "best practice" guides, conceived as simple "scholar experience to TEI" dictionaries. <br /> <br /> There is a great deal in the Guidelines that is aimed at people who are not familiar with the Humanities concepts behind the encoding, which is helpful if you come from a different background. But I really think that to a seasoned philologist reading the TEI chapters on the transcription of sources and critical apparatus must be really boring - they already know the theory better than us. That is why I believe many would be grateful if they were given a simple "translation" into TEI lingo. <br /> <br /> <br /> =Why TEI cheatwsheets?=<br /> <br /> ==Easing the learning curve==<br /> My feeling is that the Guidelines should be regarded as a reference book for more advanced users, not as the textbook for people starting to learn (or even people who do not really want to learn but just do). There are many different communities of Humanities scholars who use the TEI, and I am assuming that all (most?) of them know what they want to do with their texts, and have their own ways of working with them. My hope is that the cheatsheets, targetting specific Humanities communities or needs, will be a way of making the learning curve less steep for newbies. I hope that this would let people with no experience of XML feel immediately familiar with what the encoding is doing, at no great learning cost. It should get them started quickly, then it'll be up to them to see if they need (or care) to learn more and delve into the Guidelines. <br /> <br /> ==Facilitating the work of tool developpers==<br /> A notable side-effect of the existence of such cheatsheets or "best practice in a nutshell" would be to greatly facilitate the work of tool developpers considering to support TEI as a format in their application. It is currently most difficult for tools developpers to figure how to support TEI, because of the many possible ways of encoding the same phenomenon. Having a clearly defined list of "best practice" guides would make it easier to conform to those practices, and would hopefully boost the number of TEI-aware tools available. <br /> <br /> <br /> =Which TEI cheatsheets?=<br /> <br /> There is of course no fixed set, and each sub-community or transversal task could have its cheatsheet. The list below is just a couple of suggestions, please feel free to add to it! <br /> <br /> *[[Critical Editions Cheatsheet]]<br /> This is the task/community that is the closest to my own scholarly experience, and the one about which I first got the idea of creating "cheatsheets". I started this as a blog post, based on my own experience, some discussions on TEI-L or the MS SIG list, and further edited after feedback from users. The result is an example of what I have in mind, but could certainly be expanded further: <br /> [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet]<br /> This cheatsheet should go further than the Critical Apparatus module/chapter of the Guidelines, BTW, and should incorporate phenomena usually present in critical editions like other layers of notes, index of people's names, index of place names, etc.<br /> Please use the [[Critical Editions Cheatsheet]] page on this Wiki to suggest phenomena that should be treated, and ideally how they should be encoded (but it is not mandatory, you can of course simply list the phenomena and wait for the community to come up with encoding recommendations. <br /> <br /> *[[Annotation Cheatsheet]]<br /> I separate this from Critical Editions, because it is very common to want to add scholarly annotations to texts or documents which are not critical editions. This is therefore a transversal task. <br /> Please use the [[Annotation Cheatsheet]] to submit tasks and the best way do perform them. <br /> <br /> *[[Facsimile Linking Cheatsheet]]<br /> You have a digiral facsimile, you have its transcription or annotations about its content, how do you do that in TEI? <br /> Please describe the phenomena / subtasks involved and the best practice to encode them in the [[Facsimile Linking Cheatsheet]]<br /> <br /> *[[Linguistic Encoding Cheatsheet]]<br /> This is not something I am in any way experienced with but I suspect there is some need for cheatsheets in this department. <br /> Please use the [[Linguistic Encoding Cheatsheet]] to submit tasks and the best way do perform them.</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9920 Critical Apparatus Workgroup 2011-09-07T17:52:38Z

<p>Mburghart: /* Inclusion of structural markup in the apparatus */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> <br /> Participants to the preliminary workgroup:<br /> <br /> * Marjorie Burghart (MB)<br /> * James Cummings (JC)<br /> * Fotis Jannidis (FJ)<br /> * Gregor Middell (GM)<br /> * Dan O'Donnell (DOD)<br /> * Espen Ore (EO)<br /> * Elena Pierazzo (EP)<br /> * Roberto Rosselli del Turco (RDT)<br /> * Chris Wittern (CW)<br /> <br /> Comments below from others:<br /> * Pascale Sutter (PS)<br /> * [[User:Stuartyeates|Stuart Yeates]] (SAY)<br /> <br /> <br /> == “Critical Apparatus” vs. “Textual Variance” vs. “Textual Variants”== <br /> <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the '''critical apparatus''' is just inherited from the printed world and one of the possible physical embodiment of '''textual variance'''. EP therefore proposes to use this new name, moving from "critical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use '''textual variants''' instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart of the current critical apparatus recommendations. That of encoding an apparatus at the site of textual variance and encoding a structured view of a note entirely separate from the edited version of texts. (In mass digitization of critical editions, for example, one might have an <app> in a set of notes at the bottom of the page which are not encoded at the site of variance, or indeed necessarily connected with it.) It is this striving to both be able to encode all sorts of various legacy forms of apparatus as well as simultaneously catering for those who are recording the structure by which they will generate an apparatus in producing some output. So JC would argue that the first of these are apparatus and the second of these is a site/locus of textual variance.<br /> <br /> SAY: Prefers either '''textual variants''' or '''textual variance''' over '''Critical Apparatus''' simply because I believe their meaning is clearer to a larger proportion of English speaking people. Clear meanings help us inter-operate with other groups and standards by making our standard easier to read by third parties.<br /> <br /> == Issues == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === Specific phenomena ===<br /> <br /> ==== Transpositions ====<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions.<br /> <br /> Additionally it is not possible to mark them up explicitly. [http://juxtasoftware.org/ Juxta] for example works around that by storing transposition data in a custom XML format:<br /> <br /> <pre><br /> <moves><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10462" doc2="1881 1st Ed." space2="original" start2="9872" end2="10467" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10483" doc2="1870 2nd Ed." space2="original" start2="7781" end2="8376" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10504" doc2="1870 Proof" space2="original" start2="8458" end2="9056" /><br /> <move doc1="1855 MS" space1="original" start1="9886" end1="10525" doc2="1870 1st Ed." space2="original" start2="8546" end2="9141" /><br /> <move doc1="1870 Proof" space1="original" start1="1640" end1="1850" doc2="1881 1st Ed." space2="original" start2="2961" end2="3070" /><br /> </moves><br /> </pre><br /> <br /> Neither is this TEI-compliant, nor is the offset/range-based addressing (@start1/@start2 and @end1/@end2) proper XML markup. A standardized encoding would be helpful.<br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/fuszgtpnn2ywf6bh<br /> <br /> ==== Handling of punctuation ====<br /> <br /> Seems to be a common problem in textual criticism/ apparatus creation, but lacks guidelines/ encoding examples:<br /> <br /> * http://tei.markmail.org/thread/es6byhxpsbgkrxzo<br /> <br /> ==== Representing omissions in an apparatus ====<br /> <br /> What's the proper way to represent missing lines/ paragraphs/ verses?<br /> <br /> * http://tei.markmail.org/thread/parztmwmlx5mqsof<br /> * http://tei.markmail.org/thread/4sheu6nji3dvnf64<br /> <br /> === Markup-related ===<br /> <br /> ==== Inclusion of structural markup in the apparatus ====<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s.<br /> <br /> Use case: <br /> <br /> <blockquote style="background:#FFEAEA">I'm encoding a 19th c. edition of a medieval text, and one of the witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> * http://tei.markmail.org/thread/tbzi2yj5xd4dto34<br /> <br /> <br /> Another use case:<br /> <br /> We have several witnesses of a poem, and in our base text, we have 8 stanzas, in another version only 6 stanzas and in some other 7? We are not allowed to have an <lg> and not even an <l> element within the <app> entry. So, we must put it the other way round, which may be somewhat awkward, like this:<br /> <br /> <l><br /> <app><br /> <rdg wit="#A"> [the text of the verse line here] </rdg><br /> <rdg wit="#B"/><br /> <rdg wit="#C"/><br /> </app><br /> </l><br /> <br /> We should then repeat this for every <l> , while it would be more practical to "say" this only once for entire stanza (with an <lg> within a <rdg> ).<br /> <br /> * Source: http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet#comment-15<br /> <br /> <br /> More use cases from TEI-L:<br /> <br /> * http://tei.markmail.org/thread/jyezaqfycaldtdcv<br /> * http://tei.markmail.org/thread/fbyuxyabbxq4rwbr<br /> * http://tei.markmail.org/thread/vrwkl7kkruulyjzh<br /> * http://tei.markmail.org/thread/x5agpwzn4hiwwwcx<br /> <br /> ==== Encoding variants in structural markup ====<br /> <br /> * http://tei.markmail.org/thread/ap62n37uf6rbfds4<br /> * http://tei.markmail.org/thread/hbmnsn3v4aqjabt3<br /> <br /> ==== Conflicts between individual readings and the semantics of structural markup that surrounds it ====<br /> <br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> === Workflow-related ===<br /> <br /> ==== Scalability ====<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses.<br /> <br /> <blockquote style="background:#FFEAEA"><br /> Scaling is generally a problem with methods of indicating textual variance, but in parallel segmentation this is exacerbated because as the number of witnesses increase, the likelihood of needing to reformulate the reading boundaries, never mind the difficulty in reading or understanding such encodings. This may be a problem not only when looking at a single text with many witnesses, where variation in structure may be extremely difficult to represent where conflicts occur which disrupt this very basic structure (for example, imagine a set of witnesses where some have lines in linegroups, some just lines, some paragraphs, some paragraphs in divisions, but all with the same underlying text). But also where parallel segmentation is being used to record divergent interpretations of these individual witnesses by many editors (for distributed co-operative editions generated from many editorial views of a text). A plausible recommendation is to use a form of stand-off apparatus for such editions rather than parallel segmentation. And while some of the current methods can be used in a stand-off method, they should be updated to reflect current P5 usage of URI-based pointers.<br /> </blockquote><br /> <br /> ==== Refactoring ====<br /> <br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn.<br /> <br /> ==== Complexity ====<br /> <br /> Manually crafting an apparatus is error-prone:<br /> <br /> * http://tei.markmail.org/thread/yuxqotf5aynxznq5<br /> <br /> ==== Feasibility of double-endpoint-attached method ====<br /> <br /> * http://tei.markmail.org/thread/fsj7gvojds4mwcm5<br /> * http://tei.markmail.org/thread/flwcnf4fxm4u7ebj<br /> <br /> === Model vs. Representation ===<br /> <br /> ==== Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note ====<br /> <br /> In a nutshell: depending on the desired output of your digital edition, you may need to show in the apparatus entry a lemma text different from the content of the <lem> or desired <rdg>. This is typically the case for long omissions, when one does not display the full text that is omitted by one or more witnesses, but only the beginning and end of the omitted span of text.<br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">Let's consider again the example used in a previous use case: <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> <br/><br/><br /> You certainly do not want to generate a footnote with these two full paragraphs to tell the reader that one witness omits them, but on the other hand you want to be able to represent the source according to its various witnesses, so location-referenced is not in order. <br /> </blockquote><br /> <br /> Possible workaround: add a new possible child to <add>, indicating how the content of the <lem> should be dislayed; something like: <br /> <br /> <app><br /> <lemDisplay>Eodem anno, rex Francie… dampnificati</lemDisplay><br /> <lem>[several lines or paragraphs]</lem><br /> <rdg wit="#V"></rdg><br /> </app><br /> <br /> ==== Representing "verbose" apparatus ====<br /> <br /> In a nutshell: when you want to represent an apparatus entry written in a rather verbose way (in a print-to-digital edition). The same is true if you want to be able to generate a verbose apparatus note in a "born digital" edition. <br /> <br /> Use cases: <br /> <blockquote style="background:#FFEAEA">You're encoding an existing edition, and want to represent the source it edits, while keeping intact the text / apparatus of the existing edition. Some apparatus entries are easy to represent with the <app> / <lem> / <rdg> elements, some others add editorial comments to the listing of the variants, and are quite difficult to represent. BTW, the same goes when you are encoding a born-digital edition for which you want to be able to generate an alternative print output corresponding to the traditional standards of a collection. <br /> <br/><br/><br /> A - When I have a footnote giving two <i>lectiones</i> from the same manuscrip, one before correction and the other after: <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Text<span class="moz-txt-tag"></span></b>: ad lectorem Venetum (b) .<br /> <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Note<span class="moz-txt-tag"></span></b>: b) <i>ms.</i>, lectionem venerum <i class="moz-txt-slash"><span class="moz-txt-tag"></span>corrigé postérieurement en<span class="moz-txt-tag"></span></i> lectorem Venetum<br /> <br/><br /> <br/><br /> If I encode it like this, with two seprate rdg for the same<br /> witness, each with a different @type (for instance, "anteCorr" and<br /> "postCorr"), it gives an accurate account of the state of the witness, BUT it is an<br /> interpretation of the original note in the critical apparatus, i.e. if<br /> I do this I delete some text added by the original editor. <br><br /> <br /> &lt;app n="b"&gt;<br /> <br><br /> &lt;lem&gt;lectorem Venetum&lt;/lem&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="anteCorr"&gt;lectionem venerum&lt;/rdg&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="postCorr"&gt;lectorem Venetum&lt;/rdg&gt;<br /> <br /> <br><br /> &lt;/app&gt;<br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> Let's consider this other note. There is some text added verbosely within the apparatus note by the editor. <br/><br /> <p class="MsoNormal" style="text-align: justify;"><b style=""><span style="">Text</span></b><span style="">: Hiis diebus civitas<br /> Pergamensis(b) tenebat exersitum</span><br/><br /> <b style=""><span style="">Note</span></b><span style="">: b) se, <i>mis indûment avant</i> tenebat <i>par le ms</i>.</span></p><br /> <br /> <p class="MsoNormal"><span style="">Should I encode it as: <br><br /> ... Pergamensis &lt;app<br /> n="b"&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt;&lt;/rdg&gt;<br><br /> &lt;/app&gt;</span>... <br><br /> </p><br /> <br /> I one represents this note strictly with the <app> / <rdg>, it leads to suppress remarks by the original editor. Adding a note in the rdg to preserve the editor's comments could work here, ut it's not always the case<br/><br /> Like: <br/><br /> <span style="">... Pergamensis &lt;app<br /> n="b"&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt; </span><span style="">&lt;note&gt;&lt;hi<br /> rend="italics"&gt;<span style="">mis<br /> indûment avant</span>&lt;/hi&gt; tenebat.</span><span style="">&lt;/note&gt;&lt;/rdg&gt;<br><br /> <br /> &lt;/app&gt;</span><br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> <p class="MsoNormal" style="text-align: justify;">'''Text'''<span style="">: …reliqui demum meos socios (d)</span><br><br /> '''Note'''<span style="">: d) domum<br /> meam solito, <i>Bal.;</i> dni <i>ou</i> dm, <i>ms.; en note</i> meam solita.</span></p><br /> <br /> Here we have 2 witnesses (Bal. et ms.), the latter with a) an uncertain<br /> lectio ("dni" or "dm") and b) a part of the lectio which is written as<br /> a note ("meam solita"). This is tricky to encode. <br /> </blockquote><br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/ib3bsrpirepp4ibc<br /> * http://tei.markmail.org/thread/diubpw5adw6ntcas<br /> <br /> ==== Representation of suggestions by the editor: ''lege'' ''dele'' etc. ====<br /> <br /> In a nutshell: Sometimes, the editor provides working suggestions through apparatus notes such as ''lege(ndum)'' ("read"), ''dele(ndum)'' ("delete)" etc. They do not belong in the textual variants ''per se'', and are not attached to witnesses, although they do belong in the critical apparatus.<br /> <br /> * http://tei.markmail.org/thread/vfw25psb5vgdiftw<br /> <br /> ==== Collations of differing granularity ====<br /> <br /> * http://tei.markmail.org/thread/bonflsyb2d3ebtp2<br /> * http://tei.markmail.org/thread/gqyymzd4a4xvhch7<br /> <br /> == An encoding proposal from the perspective of computer-aided collation tools == <br /> <br /> Gregor Middell gave an overview of textual variance from a software developer's perspective for the workgroup on a [[Textual_Variance|separate page]]. The models described there are used in tools like [http://collatex.sourceforge.net/ CollateX], [http://www.juxtasoftware.org/ Juxta] and [http://code.google.com/p/multiversiondocs/ nmerge].<br /> <br /> Collecting ideas from the mailinglist by James Cummings, Dan O'Donnell and Marjorie Burghart as well as following the [[Textual_Variance|“Gothenburg model” of textual variance]], a first take at separating the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller model from the representation] of textual variance could be structured as follows.<br /> <br /> === Modelling input data: Make the units of a collation addressable in the witnesses ===<br /> <br /> The Gothenburg model assumes a [[Textual_Variance#Tokenizer|preprocessing step]] by which the witnesses get split up into '''tokens''' of desired granularity. This granularity becomes the minimal unit of collation and can defined as pages, paragraphs, verses, lines, words, characters or any other unit that makes sense in the context of a particular tradition under investigation. To model collation results on top of tokenized witnesses, those tokens have to be addressable.<br /> <br /> The TEI defines an [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAXP array of pointing mechanisms], which can be used to address anything from a whole XML document via URIs down to arbitrary content of those documents via sophisticated XPointer schemes. Projects would be free to choose among those mechanisms as long as each token is made available for later reference.<br /> <br /> Examples:<br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_1"><br /> <w>The</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w> <w>quickly</w>.<br /> </p><br /> </pre><br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_2"><br /> <w>Quickly</w>, <w>the</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w>.<br /> </p><br /> </pre><br /> <br /> Here tokens on the word-level could be addressed via the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSXP xpath1() XPointer scheme]:<br /> <br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[1])</nowiki><br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[2])</nowiki><br /> # ...<br /> <br /> A less verbose scheme would rely on each container element of a token being identified via a (possibly autogenerated) <code>xml:id</code> attribute, like in the following verse-level tokenization.<br /> <br /> <pre><br /> <lg xml:base="urn:goethe:faust2"><br /> <l xml:id="l_1">Die Sonne sinkt, die letzten Schiffe</l><br /> <l xml:id="l_2">Sie ziehen munter hafenein.</l><br /> <l xml:id="l_3">Ein großer Kahn ist im Begriffe</l><br /> <l xml:id="l_4">Auf dem Canale hier zu sein.</l><br /> </lg><br /> </pre><br /> <br /> # <nowiki>urn:goethe:faust2#l_1</nowiki><br /> # <nowiki>urn:goethe:faust2#l_2</nowiki><br /> # ...<br /> <br /> One can even think of reference schemes, which are as independent of existing markup as possible. By introducing &lt;anchor/> milestone elements at token boundaries and using the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSRN range() XPointer scheme] the tokenization of arbitrary TEI documents can be accomplished, because &lt;anchor/> is part of [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.global.html model.global].<br /> <br /> === Modelling collated data: Encode the alignment/linking between tokens ===<br /> <br /> After tokens in the different witnesses have been made addressable, collation data can be modelled on top of that as [[Textual_Variance#Aligner|alignments of tokens]]. An '''alignment''' can be expressed as a set of tokens from different witnesses or, in accordance with the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html corresponding guidelines chapter] as a link between two or more tokens.<br /> <br /> Taking the first example from above, a collation of the two given witnesses could be expressed as<br /> <br /> <pre><br /> <linkGrp type="collation" xml:base="http://edition.org/"><br /> <link target="witness_1#xpath1(/p[1]/w[1]) witness_2#xpath1(/p[1]/w[2])" /><br /> <link target="witness_1#xpath1(/p[1]/w[2]) witness_2#xpath1(/p[1]/w[3])" /><br /> <link target="witness_1#xpath1(/p[1]/w[3]) witness_2#xpath1(/p[1]/w[4])" /><br /> <link target="witness_1#xpath1(/p[1]/w[4]) witness_2#xpath1(/p[1]/w[5])" /><br /> <link target="witness_1#xpath1(/p[1]/w[5]) witness_2#xpath1(/p[1]/w[6])" /><br /> <link target="witness_1#xpath1(/p[1]/w[6]) witness_2#xpath1(/p[1]/w[1])" type="transposition" /><br /> </linkGrp><br /> </pre><br /> <br /> Each link in this example corresponds to a row in an alignment table as depicted in the Gothenburg model description. Omitted/ added tokens are expressed implictly by not linking to tokens in other witnesses, this is to say: Whether a set of tokens has been added to a witness or has been omitted from it, is a matter of interpreting collation data as expressed above from the perspective of one witness or another and with regard to the way, this witness aligns with others.<br /> <br /> One advantage of encoding collation data in such a set-oriented way is its '''scalability''':<br /> <br /> # Gradually adding witnesses to the collation may amount to adding alignments to the existing ones or modifying/augmenting the latter, depending on whether the collation is done pairwise (e. g. in relation to a base text) or via multiple alignment (e. g. without a prechosen base).<br /> # Guiding a collation tool in producing ever more precise aligments in consecutive runs can be achieved by [[Textual_Variance#Analyzer|declaring alignments]] (for example transpositions), feeding those into the collator, adjusting the resulting alignment set, feeding it back into the collator for another run and so forth. Being able to encode the initial/preliminary results of such an iterative process in a standardized way, makes it possible to run different collation tools on the same text tradition, ideally each being able to make use of former results by other tools and to contribute to the overall result.<br /> <br /> The major disadvantage of encoding collation data this way is its apparant lack of human readability and that it is hardly possible to edit it by hand, especially when the collated text tradition grows larger. This problem can only be solved via tool support.<br /> <br /> === Encoding the interpretation/ representation: Derive an apparatus from the collation ===<br /> <br /> A TEI-encoded critical apparatus is one possible rendition of collation data, possibly enhanced with information yielded from interpreting the alignments. There are a couple of ways how we could encode the above collation as an apparatus.<br /> <br /> ==== Apparatus pointing to the collated tokens (for easier post-processing) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" xml:id="w2_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2"><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" corresp="#w2_1"><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> ==== Apparatus with embedded textual content (for readability) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:id="w2_1">Quickly,</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1">The cat ate the food</rdg><br /> <rdg wit="http://edition.org/witness_2">the cat ate the food.</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" corresp="#w2_1">quickly.</rdg><br /> <rdg wit="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> Some problems here:<br /> <br /> * @corresp vs. <link/> for transpositions over more than two witnesses<br /> * How to derive the segment content from the original witness automatically, if the token content does not add up to it (e. g. because of punctuation being excluded from the tokens from the start)?<br /> <br /> == Bibliography ==<br /> <br /> * O'Donnell, Daniel Paul. [http://etjanst.hb.se/bhs/ith/1-8/dpo.pdf “The Ghost in the Machine: Revisiting an Old Model for the Dynamic Generation of Digital Editions.”] HumanIT 8.1 (2005): 5171.<br /> * Vetter, L. and McDonald, J. ‘Witnessing Dickinson’s Witnesses’, Literary and Linguistic Computing, 18.2: 2003, 151-165.<br /> * [http://eprints.qut.edu.au/38436/ Schmidt, D., 2010. The inadequacy of embedded markup for cultural heritage texts. Literary and Linguistic Computing, 25(3), pp. 337-356.]<br /> <br /> [[Category:SIG:Manuscripts]]<br /> [[Category:Critical Apparatus]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9919 Critical Apparatus Workgroup 2011-09-07T17:48:49Z

<p>Mburghart: /* Inclusion of structural markup in the apparatus */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> <br /> Participants to the preliminary workgroup:<br /> <br /> * Marjorie Burghart (MB)<br /> * James Cummings (JC)<br /> * Fotis Jannidis (FJ)<br /> * Gregor Middell (GM)<br /> * Dan O'Donnell (DOD)<br /> * Espen Ore (EO)<br /> * Elena Pierazzo (EP)<br /> * Roberto Rosselli del Turco (RDT)<br /> * Chris Wittern (CW)<br /> <br /> Comments below from others:<br /> * Pascale Sutter (PS)<br /> * [[User:Stuartyeates|Stuart Yeates]] (SAY)<br /> <br /> <br /> == “Critical Apparatus” vs. “Textual Variance” vs. “Textual Variants”== <br /> <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the '''critical apparatus''' is just inherited from the printed world and one of the possible physical embodiment of '''textual variance'''. EP therefore proposes to use this new name, moving from "critical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use '''textual variants''' instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart of the current critical apparatus recommendations. That of encoding an apparatus at the site of textual variance and encoding a structured view of a note entirely separate from the edited version of texts. (In mass digitization of critical editions, for example, one might have an <app> in a set of notes at the bottom of the page which are not encoded at the site of variance, or indeed necessarily connected with it.) It is this striving to both be able to encode all sorts of various legacy forms of apparatus as well as simultaneously catering for those who are recording the structure by which they will generate an apparatus in producing some output. So JC would argue that the first of these are apparatus and the second of these is a site/locus of textual variance.<br /> <br /> SAY: Prefers either '''textual variants''' or '''textual variance''' over '''Critical Apparatus''' simply because I believe their meaning is clearer to a larger proportion of English speaking people. Clear meanings help us inter-operate with other groups and standards by making our standard easier to read by third parties.<br /> <br /> == Issues == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === Specific phenomena ===<br /> <br /> ==== Transpositions ====<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions.<br /> <br /> Additionally it is not possible to mark them up explicitly. [http://juxtasoftware.org/ Juxta] for example works around that by storing transposition data in a custom XML format:<br /> <br /> <pre><br /> <moves><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10462" doc2="1881 1st Ed." space2="original" start2="9872" end2="10467" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10483" doc2="1870 2nd Ed." space2="original" start2="7781" end2="8376" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10504" doc2="1870 Proof" space2="original" start2="8458" end2="9056" /><br /> <move doc1="1855 MS" space1="original" start1="9886" end1="10525" doc2="1870 1st Ed." space2="original" start2="8546" end2="9141" /><br /> <move doc1="1870 Proof" space1="original" start1="1640" end1="1850" doc2="1881 1st Ed." space2="original" start2="2961" end2="3070" /><br /> </moves><br /> </pre><br /> <br /> Neither is this TEI-compliant, nor is the offset/range-based addressing (@start1/@start2 and @end1/@end2) proper XML markup. A standardized encoding would be helpful.<br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/fuszgtpnn2ywf6bh<br /> <br /> ==== Handling of punctuation ====<br /> <br /> Seems to be a common problem in textual criticism/ apparatus creation, but lacks guidelines/ encoding examples:<br /> <br /> * http://tei.markmail.org/thread/es6byhxpsbgkrxzo<br /> <br /> ==== Representing omissions in an apparatus ====<br /> <br /> What's the proper way to represent missing lines/ paragraphs/ verses?<br /> <br /> * http://tei.markmail.org/thread/parztmwmlx5mqsof<br /> * http://tei.markmail.org/thread/4sheu6nji3dvnf64<br /> <br /> === Markup-related ===<br /> <br /> ==== Inclusion of structural markup in the apparatus ====<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s.<br /> <br /> Use case: <br /> <br /> <blockquote style="background:#FFEAEA">I'm encoding a 19th c. edition of a medieval text, and one of the witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> * http://tei.markmail.org/thread/tbzi2yj5xd4dto34<br /> <br /> <br /> '''Another use case:''' <br /> Source: http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet#comment-15<br /> <blockquote style="background:#FFEAEA">We have several witnesses of a poem, and in our base text, we have 8 stanzas, in another version only 6 stanzas and in some other 7? We are not allowed to have an <lg> and not even an <l> element within the <app> entry. So, we must put it the other way round, which may be somewhat awkward, like this:<br /> <br /> <l><br /> <app><br /> <rdg wit="#A"> [the text of the verse line here] </rdg><br /> <rdg wit="#B"/><br /> <rdg wit="#C"/><br /> </app><br /> </l><br /> <br /> We should then repeat this for every <l> , while it would be more practical to "say" this only once for entire stanza (with an <lg> within a <rdg> ).<br /> </blockquote><br /> <br /> More use cases from TEI-L:<br /> <br /> * http://tei.markmail.org/thread/jyezaqfycaldtdcv<br /> * http://tei.markmail.org/thread/fbyuxyabbxq4rwbr<br /> * http://tei.markmail.org/thread/vrwkl7kkruulyjzh<br /> * http://tei.markmail.org/thread/x5agpwzn4hiwwwcx<br /> <br /> ==== Encoding variants in structural markup ====<br /> <br /> * http://tei.markmail.org/thread/ap62n37uf6rbfds4<br /> * http://tei.markmail.org/thread/hbmnsn3v4aqjabt3<br /> <br /> ==== Conflicts between individual readings and the semantics of structural markup that surrounds it ====<br /> <br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> === Workflow-related ===<br /> <br /> ==== Scalability ====<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses.<br /> <br /> <blockquote style="background:#FFEAEA"><br /> Scaling is generally a problem with methods of indicating textual variance, but in parallel segmentation this is exacerbated because as the number of witnesses increase, the likelihood of needing to reformulate the reading boundaries, never mind the difficulty in reading or understanding such encodings. This may be a problem not only when looking at a single text with many witnesses, where variation in structure may be extremely difficult to represent where conflicts occur which disrupt this very basic structure (for example, imagine a set of witnesses where some have lines in linegroups, some just lines, some paragraphs, some paragraphs in divisions, but all with the same underlying text). But also where parallel segmentation is being used to record divergent interpretations of these individual witnesses by many editors (for distributed co-operative editions generated from many editorial views of a text). A plausible recommendation is to use a form of stand-off apparatus for such editions rather than parallel segmentation. And while some of the current methods can be used in a stand-off method, they should be updated to reflect current P5 usage of URI-based pointers.<br /> </blockquote><br /> <br /> ==== Refactoring ====<br /> <br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn.<br /> <br /> ==== Complexity ====<br /> <br /> Manually crafting an apparatus is error-prone:<br /> <br /> * http://tei.markmail.org/thread/yuxqotf5aynxznq5<br /> <br /> ==== Feasibility of double-endpoint-attached method ====<br /> <br /> * http://tei.markmail.org/thread/fsj7gvojds4mwcm5<br /> * http://tei.markmail.org/thread/flwcnf4fxm4u7ebj<br /> <br /> === Model vs. Representation ===<br /> <br /> ==== Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note ====<br /> <br /> In a nutshell: depending on the desired output of your digital edition, you may need to show in the apparatus entry a lemma text different from the content of the <lem> or desired <rdg>. This is typically the case for long omissions, when one does not display the full text that is omitted by one or more witnesses, but only the beginning and end of the omitted span of text.<br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">Let's consider again the example used in a previous use case: <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> <br/><br/><br /> You certainly do not want to generate a footnote with these two full paragraphs to tell the reader that one witness omits them, but on the other hand you want to be able to represent the source according to its various witnesses, so location-referenced is not in order. <br /> </blockquote><br /> <br /> Possible workaround: add a new possible child to <add>, indicating how the content of the <lem> should be dislayed; something like: <br /> <br /> <app><br /> <lemDisplay>Eodem anno, rex Francie… dampnificati</lemDisplay><br /> <lem>[several lines or paragraphs]</lem><br /> <rdg wit="#V"></rdg><br /> </app><br /> <br /> ==== Representing "verbose" apparatus ====<br /> <br /> In a nutshell: when you want to represent an apparatus entry written in a rather verbose way (in a print-to-digital edition). The same is true if you want to be able to generate a verbose apparatus note in a "born digital" edition. <br /> <br /> Use cases: <br /> <blockquote style="background:#FFEAEA">You're encoding an existing edition, and want to represent the source it edits, while keeping intact the text / apparatus of the existing edition. Some apparatus entries are easy to represent with the <app> / <lem> / <rdg> elements, some others add editorial comments to the listing of the variants, and are quite difficult to represent. BTW, the same goes when you are encoding a born-digital edition for which you want to be able to generate an alternative print output corresponding to the traditional standards of a collection. <br /> <br/><br/><br /> A - When I have a footnote giving two <i>lectiones</i> from the same manuscrip, one before correction and the other after: <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Text<span class="moz-txt-tag"></span></b>: ad lectorem Venetum (b) .<br /> <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Note<span class="moz-txt-tag"></span></b>: b) <i>ms.</i>, lectionem venerum <i class="moz-txt-slash"><span class="moz-txt-tag"></span>corrigé postérieurement en<span class="moz-txt-tag"></span></i> lectorem Venetum<br /> <br/><br /> <br/><br /> If I encode it like this, with two seprate rdg for the same<br /> witness, each with a different @type (for instance, "anteCorr" and<br /> "postCorr"), it gives an accurate account of the state of the witness, BUT it is an<br /> interpretation of the original note in the critical apparatus, i.e. if<br /> I do this I delete some text added by the original editor. <br><br /> <br /> &lt;app n="b"&gt;<br /> <br><br /> &lt;lem&gt;lectorem Venetum&lt;/lem&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="anteCorr"&gt;lectionem venerum&lt;/rdg&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="postCorr"&gt;lectorem Venetum&lt;/rdg&gt;<br /> <br /> <br><br /> &lt;/app&gt;<br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> Let's consider this other note. There is some text added verbosely within the apparatus note by the editor. <br/><br /> <p class="MsoNormal" style="text-align: justify;"><b style=""><span style="">Text</span></b><span style="">: Hiis diebus civitas<br /> Pergamensis(b) tenebat exersitum</span><br/><br /> <b style=""><span style="">Note</span></b><span style="">: b) se, <i>mis indûment avant</i> tenebat <i>par le ms</i>.</span></p><br /> <br /> <p class="MsoNormal"><span style="">Should I encode it as: <br><br /> ... Pergamensis &lt;app<br /> n="b"&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt;&lt;/rdg&gt;<br><br /> &lt;/app&gt;</span>... <br><br /> </p><br /> <br /> I one represents this note strictly with the <app> / <rdg>, it leads to suppress remarks by the original editor. Adding a note in the rdg to preserve the editor's comments could work here, ut it's not always the case<br/><br /> Like: <br/><br /> <span style="">... Pergamensis &lt;app<br /> n="b"&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt; </span><span style="">&lt;note&gt;&lt;hi<br /> rend="italics"&gt;<span style="">mis<br /> indûment avant</span>&lt;/hi&gt; tenebat.</span><span style="">&lt;/note&gt;&lt;/rdg&gt;<br><br /> <br /> &lt;/app&gt;</span><br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> <p class="MsoNormal" style="text-align: justify;">'''Text'''<span style="">: …reliqui demum meos socios (d)</span><br><br /> '''Note'''<span style="">: d) domum<br /> meam solito, <i>Bal.;</i> dni <i>ou</i> dm, <i>ms.; en note</i> meam solita.</span></p><br /> <br /> Here we have 2 witnesses (Bal. et ms.), the latter with a) an uncertain<br /> lectio ("dni" or "dm") and b) a part of the lectio which is written as<br /> a note ("meam solita"). This is tricky to encode. <br /> </blockquote><br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/ib3bsrpirepp4ibc<br /> * http://tei.markmail.org/thread/diubpw5adw6ntcas<br /> <br /> ==== Representation of suggestions by the editor: ''lege'' ''dele'' etc. ====<br /> <br /> In a nutshell: Sometimes, the editor provides working suggestions through apparatus notes such as ''lege(ndum)'' ("read"), ''dele(ndum)'' ("delete)" etc. They do not belong in the textual variants ''per se'', and are not attached to witnesses, although they do belong in the critical apparatus.<br /> <br /> * http://tei.markmail.org/thread/vfw25psb5vgdiftw<br /> <br /> ==== Collations of differing granularity ====<br /> <br /> * http://tei.markmail.org/thread/bonflsyb2d3ebtp2<br /> * http://tei.markmail.org/thread/gqyymzd4a4xvhch7<br /> <br /> == An encoding proposal from the perspective of computer-aided collation tools == <br /> <br /> Gregor Middell gave an overview of textual variance from a software developer's perspective for the workgroup on a [[Textual_Variance|separate page]]. The models described there are used in tools like [http://collatex.sourceforge.net/ CollateX], [http://www.juxtasoftware.org/ Juxta] and [http://code.google.com/p/multiversiondocs/ nmerge].<br /> <br /> Collecting ideas from the mailinglist by James Cummings, Dan O'Donnell and Marjorie Burghart as well as following the [[Textual_Variance|“Gothenburg model” of textual variance]], a first take at separating the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller model from the representation] of textual variance could be structured as follows.<br /> <br /> === Modelling input data: Make the units of a collation addressable in the witnesses ===<br /> <br /> The Gothenburg model assumes a [[Textual_Variance#Tokenizer|preprocessing step]] by which the witnesses get split up into '''tokens''' of desired granularity. This granularity becomes the minimal unit of collation and can defined as pages, paragraphs, verses, lines, words, characters or any other unit that makes sense in the context of a particular tradition under investigation. To model collation results on top of tokenized witnesses, those tokens have to be addressable.<br /> <br /> The TEI defines an [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAXP array of pointing mechanisms], which can be used to address anything from a whole XML document via URIs down to arbitrary content of those documents via sophisticated XPointer schemes. Projects would be free to choose among those mechanisms as long as each token is made available for later reference.<br /> <br /> Examples:<br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_1"><br /> <w>The</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w> <w>quickly</w>.<br /> </p><br /> </pre><br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_2"><br /> <w>Quickly</w>, <w>the</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w>.<br /> </p><br /> </pre><br /> <br /> Here tokens on the word-level could be addressed via the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSXP xpath1() XPointer scheme]:<br /> <br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[1])</nowiki><br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[2])</nowiki><br /> # ...<br /> <br /> A less verbose scheme would rely on each container element of a token being identified via a (possibly autogenerated) <code>xml:id</code> attribute, like in the following verse-level tokenization.<br /> <br /> <pre><br /> <lg xml:base="urn:goethe:faust2"><br /> <l xml:id="l_1">Die Sonne sinkt, die letzten Schiffe</l><br /> <l xml:id="l_2">Sie ziehen munter hafenein.</l><br /> <l xml:id="l_3">Ein großer Kahn ist im Begriffe</l><br /> <l xml:id="l_4">Auf dem Canale hier zu sein.</l><br /> </lg><br /> </pre><br /> <br /> # <nowiki>urn:goethe:faust2#l_1</nowiki><br /> # <nowiki>urn:goethe:faust2#l_2</nowiki><br /> # ...<br /> <br /> One can even think of reference schemes, which are as independent of existing markup as possible. By introducing &lt;anchor/> milestone elements at token boundaries and using the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSRN range() XPointer scheme] the tokenization of arbitrary TEI documents can be accomplished, because &lt;anchor/> is part of [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.global.html model.global].<br /> <br /> === Modelling collated data: Encode the alignment/linking between tokens ===<br /> <br /> After tokens in the different witnesses have been made addressable, collation data can be modelled on top of that as [[Textual_Variance#Aligner|alignments of tokens]]. An '''alignment''' can be expressed as a set of tokens from different witnesses or, in accordance with the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html corresponding guidelines chapter] as a link between two or more tokens.<br /> <br /> Taking the first example from above, a collation of the two given witnesses could be expressed as<br /> <br /> <pre><br /> <linkGrp type="collation" xml:base="http://edition.org/"><br /> <link target="witness_1#xpath1(/p[1]/w[1]) witness_2#xpath1(/p[1]/w[2])" /><br /> <link target="witness_1#xpath1(/p[1]/w[2]) witness_2#xpath1(/p[1]/w[3])" /><br /> <link target="witness_1#xpath1(/p[1]/w[3]) witness_2#xpath1(/p[1]/w[4])" /><br /> <link target="witness_1#xpath1(/p[1]/w[4]) witness_2#xpath1(/p[1]/w[5])" /><br /> <link target="witness_1#xpath1(/p[1]/w[5]) witness_2#xpath1(/p[1]/w[6])" /><br /> <link target="witness_1#xpath1(/p[1]/w[6]) witness_2#xpath1(/p[1]/w[1])" type="transposition" /><br /> </linkGrp><br /> </pre><br /> <br /> Each link in this example corresponds to a row in an alignment table as depicted in the Gothenburg model description. Omitted/ added tokens are expressed implictly by not linking to tokens in other witnesses, this is to say: Whether a set of tokens has been added to a witness or has been omitted from it, is a matter of interpreting collation data as expressed above from the perspective of one witness or another and with regard to the way, this witness aligns with others.<br /> <br /> One advantage of encoding collation data in such a set-oriented way is its '''scalability''':<br /> <br /> # Gradually adding witnesses to the collation may amount to adding alignments to the existing ones or modifying/augmenting the latter, depending on whether the collation is done pairwise (e. g. in relation to a base text) or via multiple alignment (e. g. without a prechosen base).<br /> # Guiding a collation tool in producing ever more precise aligments in consecutive runs can be achieved by [[Textual_Variance#Analyzer|declaring alignments]] (for example transpositions), feeding those into the collator, adjusting the resulting alignment set, feeding it back into the collator for another run and so forth. Being able to encode the initial/preliminary results of such an iterative process in a standardized way, makes it possible to run different collation tools on the same text tradition, ideally each being able to make use of former results by other tools and to contribute to the overall result.<br /> <br /> The major disadvantage of encoding collation data this way is its apparant lack of human readability and that it is hardly possible to edit it by hand, especially when the collated text tradition grows larger. This problem can only be solved via tool support.<br /> <br /> === Encoding the interpretation/ representation: Derive an apparatus from the collation ===<br /> <br /> A TEI-encoded critical apparatus is one possible rendition of collation data, possibly enhanced with information yielded from interpreting the alignments. There are a couple of ways how we could encode the above collation as an apparatus.<br /> <br /> ==== Apparatus pointing to the collated tokens (for easier post-processing) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" xml:id="w2_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2"><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" corresp="#w2_1"><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> ==== Apparatus with embedded textual content (for readability) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:id="w2_1">Quickly,</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1">The cat ate the food</rdg><br /> <rdg wit="http://edition.org/witness_2">the cat ate the food.</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" corresp="#w2_1">quickly.</rdg><br /> <rdg wit="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> Some problems here:<br /> <br /> * @corresp vs. <link/> for transpositions over more than two witnesses<br /> * How to derive the segment content from the original witness automatically, if the token content does not add up to it (e. g. because of punctuation being excluded from the tokens from the start)?<br /> <br /> == Bibliography ==<br /> <br /> * O'Donnell, Daniel Paul. [http://etjanst.hb.se/bhs/ith/1-8/dpo.pdf “The Ghost in the Machine: Revisiting an Old Model for the Dynamic Generation of Digital Editions.”] HumanIT 8.1 (2005): 5171.<br /> * Vetter, L. and McDonald, J. ‘Witnessing Dickinson’s Witnesses’, Literary and Linguistic Computing, 18.2: 2003, 151-165.<br /> * [http://eprints.qut.edu.au/38436/ Schmidt, D., 2010. The inadequacy of embedded markup for cultural heritage texts. Literary and Linguistic Computing, 25(3), pp. 337-356.]<br /> <br /> [[Category:SIG:Manuscripts]]<br /> [[Category:Critical Apparatus]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9838 Critical Apparatus Workgroup 2011-09-02T22:34:32Z

<p>Mburghart: </p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> <br /> Participants to the preliminary workgroup:<br /> <br /> * Marjorie Burghart (MB)<br /> * James Cummings (JC)<br /> * Fotis Jannidis (FJ)<br /> * Gregor Middell (GM)<br /> * Dan O'Donnell (DOD)<br /> * Espen Ore (EO)<br /> * Elena Pierazzo (EP)<br /> * Roberto Rosselli del Turco (RDT)<br /> * Chris Wittern (CW)<br /> <br /> Comments below from others:<br /> * Pascale Sutter (PS)<br /> * [[User:Stuartyeates|Stuart Yeates]] (SAY)<br /> <br /> <br /> == “Critical Apparatus” vs. “Textual Variance” vs. “Textual Variants”== <br /> <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the '''critical apparatus''' is just inherited from the printed world and one of the possible physical embodiment of '''textual variance'''. EP therefore proposes to use this new name, moving from "critical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use '''textual variants''' instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart of the current critical apparatus recommendations. That of encoding an apparatus at the site of textual variance and encoding a structured view of a note entirely separate from the edited version of texts. (In mass digitization of critical editions, for example, one might have an <app> in a set of notes at the bottom of the page which are not encoded at the site of variance, or indeed necessarily connected with it.) It is this striving to both be able to encode all sorts of various legacy forms of apparatus as well as simultaneously catering for those who are recording the structure by which they will generate an apparatus in producing some output. So JC would argue that the first of these are apparatus and the second of these is a site/locus of textual variance.<br /> <br /> SAY: Prefers either '''textual variants''' or '''textual variance''' over '''Critical Apparatus''' simply because I believe their meaning is clearer to a larger proportion of English speaking people. Clear meanings help us inter-operate with other groups and standards by making our standard easier to read by third parties.<br /> <br /> == Issues == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === Specific phenomena ===<br /> <br /> ==== Transpositions ====<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions.<br /> <br /> Additionally it is not possible to mark them up explicitly. [http://juxtasoftware.org/ Juxta] for example works around that by storing transposition data in a custom XML format:<br /> <br /> <pre><br /> <moves><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10462" doc2="1881 1st Ed." space2="original" start2="9872" end2="10467" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10483" doc2="1870 2nd Ed." space2="original" start2="7781" end2="8376" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10504" doc2="1870 Proof" space2="original" start2="8458" end2="9056" /><br /> <move doc1="1855 MS" space1="original" start1="9886" end1="10525" doc2="1870 1st Ed." space2="original" start2="8546" end2="9141" /><br /> <move doc1="1870 Proof" space1="original" start1="1640" end1="1850" doc2="1881 1st Ed." space2="original" start2="2961" end2="3070" /><br /> </moves><br /> </pre><br /> <br /> Neither is this TEI-compliant, nor is the offset/range-based addressing (@start1/@start2 and @end1/@end2) proper XML markup. A standardized encoding would be helpful.<br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/fuszgtpnn2ywf6bh<br /> <br /> ==== Handling of punctuation ====<br /> <br /> Seems to be a common problem in textual criticism/ apparatus creation, but lacks guidelines/ encoding examples:<br /> <br /> * http://tei.markmail.org/thread/es6byhxpsbgkrxzo<br /> <br /> ==== Representing omissions in an apparatus ====<br /> <br /> What's the proper way to represent missing lines/ paragraphs/ verses?<br /> <br /> * http://tei.markmail.org/thread/parztmwmlx5mqsof<br /> * http://tei.markmail.org/thread/4sheu6nji3dvnf64<br /> <br /> === Markup-related ===<br /> <br /> ==== Inclusion of structural markup in the apparatus ====<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s.<br /> <br /> Use case: <br /> <br /> <blockquote style="background:#FFEAEA">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> * http://tei.markmail.org/thread/tbzi2yj5xd4dto34<br /> <br /> More use cases from TEI-L:<br /> <br /> * http://tei.markmail.org/thread/jyezaqfycaldtdcv<br /> * http://tei.markmail.org/thread/fbyuxyabbxq4rwbr<br /> * http://tei.markmail.org/thread/vrwkl7kkruulyjzh<br /> * http://tei.markmail.org/thread/x5agpwzn4hiwwwcx<br /> <br /> ==== Encoding variants in structural markup ====<br /> <br /> * http://tei.markmail.org/thread/ap62n37uf6rbfds4<br /> * http://tei.markmail.org/thread/hbmnsn3v4aqjabt3<br /> <br /> ==== Conflicts between individual readings and the semantics of structural markup that surrounds it ====<br /> <br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> === Workflow-related ===<br /> <br /> ==== Scalability ====<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses.<br /> <br /> <blockquote style="background:#FFEAEA"><br /> Scaling is generally a problem with methods of indicating textual variance, but in parallel segmentation this is exacerbated because as the number of witnesses increase, the likelihood of needing to reformulate the reading boundaries, never mind the difficulty in reading or understanding such encodings. This may be a problem not only when looking at a single text with many witnesses, where variation in structure may be extremely difficult to represent where conflicts occur which disrupt this very basic structure (for example, imagine a set of witnesses where some have lines in linegroups, some just lines, some paragraphs, some paragraphs in divisions, but all with the same underlying text). But also where parallel segmentation is being used to record divergent interpretations of these individual witnesses by many editors (for distributed co-operative editions generated from many editorial views of a text). A plausible recommendation is to use a form of stand-off apparatus for such editions rather than parallel segmentation. And while some of the current methods can be used in a stand-off method, they should be updated to reflect current P5 usage of URI-based pointers.<br /> </blockquote><br /> <br /> ==== Refactoring ====<br /> <br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn.<br /> <br /> ==== Complexity ====<br /> <br /> Manually crafting an apparatus is error-prone:<br /> <br /> * http://tei.markmail.org/thread/yuxqotf5aynxznq5<br /> <br /> ==== Feasibility of double-endpoint-attached method ====<br /> <br /> * http://tei.markmail.org/thread/fsj7gvojds4mwcm5<br /> * http://tei.markmail.org/thread/flwcnf4fxm4u7ebj<br /> <br /> === Model vs. Representation ===<br /> <br /> ==== Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note ====<br /> <br /> In a nutshell: depending on the desired output of your digital edition, you may need to show in the apparatus entry a lemma text different from the content of the <lem> or desired <rdg>. This is typically the case for long omissions, when one does not display the full text that is omitted by one or more witnesses, but only the beginning and end of the omitted span of text.<br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">Let's consider again the example used in a previous use case: <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> <br/><br/><br /> You certainly do not want to generate a footnote with these two full paragraphs to tell the reader that one witness omits them, but on the other hand you want to be able to represent the source according to its various witnesses, so location-referenced is not in order. <br /> </blockquote><br /> <br /> Possible workaround: add a new possible child to <add>, indicating how the content of the <lem> should be dislayed; something like: <br /> <br /> <app><br /> <lemDisplay>Eodem anno, rex Francie… dampnificati</lemDisplay><br /> <lem>[several lines or paragraphs]</lem><br /> <rdg wit="#V"></rdg><br /> </app><br /> <br /> ==== Representing "verbose" apparatus ====<br /> <br /> In a nutshell: when you want to represent an apparatus entry written in a rather verbose way (in a print-to-digital edition). The same is true if you want to be able to generate a verbose apparatus note in a "born digital" edition. <br /> <br /> Use cases: <br /> <blockquote style="background:#FFEAEA">You're encoding an existing edition, and want to represent the source it edits, while keeping intact the text / apparatus of the existing edition. Some apparatus entries are easy to represent with the <app> / <lem> / <rdg> elements, some others add editorial comments to the listing of the variants, and are quite difficult to represent. BTW, the same goes when you are encoding a born-digital edition for which you want to be able to generate an alternative print output corresponding to the traditional standards of a collection. <br /> <br/><br/><br /> A - When I have a footnote giving two <i>lectiones</i> from the same manuscrip, one before correction and the other after: <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Text<span class="moz-txt-tag"></span></b>: ad lectorem Venetum (b) .<br /> <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Note<span class="moz-txt-tag"></span></b>: b) <i>ms.</i>, lectionem venerum <i class="moz-txt-slash"><span class="moz-txt-tag"></span>corrigé postérieurement en<span class="moz-txt-tag"></span></i> lectorem Venetum<br /> <br/><br /> <br/><br /> If I encode it like this, with two seprate rdg for the same<br /> witness, each with a different @type (for instance, "anteCorr" and<br /> "postCorr"), it gives an accurate account of the state of the witness, BUT it is an<br /> interpretation of the original note in the critical apparatus, i.e. if<br /> I do this I delete some text added by the original editor. <br><br /> <br /> &lt;app n="b"&gt;<br /> <br><br /> &lt;lem&gt;lectorem Venetum&lt;/lem&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="anteCorr"&gt;lectionem venerum&lt;/rdg&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="postCorr"&gt;lectorem Venetum&lt;/rdg&gt;<br /> <br /> <br><br /> &lt;/app&gt;<br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> Let's consider this other note. There is some text added verbosely within the apparatus note by the editor. <br/><br /> <p class="MsoNormal" style="text-align: justify;"><b style=""><span style="">Text</span></b><span style="">: Hiis diebus civitas<br /> Pergamensis(b) tenebat exersitum</span><br/><br /> <b style=""><span style="">Note</span></b><span style="">: b) se, <i>mis indûment avant</i> tenebat <i>par le ms</i>.</span></p><br /> <br /> <p class="MsoNormal"><span style="">Should I encode it as: <br><br /> ... Pergamensis &lt;app<br /> n="b"&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt;&lt;/rdg&gt;<br><br /> &lt;/app&gt;</span>... <br><br /> </p><br /> <br /> I one represents this note strictly with the <app> / <rdg>, it leads to suppress remarks by the original editor. Adding a note in the rdg to preserve the editor's comments could work here, ut it's not always the case<br/><br /> Like: <br/><br /> <span style="">... Pergamensis &lt;app<br /> n="b"&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt; </span><span style="">&lt;note&gt;&lt;hi<br /> rend="italics"&gt;<span style="">mis<br /> indûment avant</span>&lt;/hi&gt; tenebat.</span><span style="">&lt;/note&gt;&lt;/rdg&gt;<br><br /> <br /> &lt;/app&gt;</span><br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> <p class="MsoNormal" style="text-align: justify;">'''Text'''<span style="">: …reliqui demum meos socios (d)</span><br><br /> '''Note'''<span style="">: d) domum<br /> meam solito, <i>Bal.;</i> dni <i>ou</i> dm, <i>ms.; en note</i> meam solita.</span></p><br /> <br /> Here we have 2 witnesses (Bal. et ms.), the latter with a) an uncertain<br /> lectio ("dni" or "dm") and b) a part of the lectio which is written as<br /> a note ("meam solita"). This is tricky to encode. <br /> </blockquote><br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/ib3bsrpirepp4ibc<br /> * http://tei.markmail.org/thread/diubpw5adw6ntcas<br /> <br /> ==== Representation of suggestions by the editor: ''lege'' ''dele'' etc. ====<br /> <br /> In a nutshell: Sometimes, the editor provides working suggestions through apparatus notes such as ''lege(ndum)'' ("read"), ''dele(ndum)'' ("delete)" etc. They do not belong in the textual variants ''per se'', and are not attached to witnesses, although they do belong in the critical apparatus.<br /> <br /> * http://tei.markmail.org/thread/vfw25psb5vgdiftw<br /> <br /> ==== Collations of differing granularity ====<br /> <br /> * http://tei.markmail.org/thread/bonflsyb2d3ebtp2<br /> * http://tei.markmail.org/thread/gqyymzd4a4xvhch7<br /> <br /> == An encoding proposal from the perspective of computer-aided collation tools == <br /> <br /> Gregor Middell gave an overview of textual variance from a software developer's perspective for the workgroup on a [[Textual_Variance|separate page]]. The models described there are used in tools like [http://collatex.sourceforge.net/ CollateX], [http://www.juxtasoftware.org/ Juxta] and [http://code.google.com/p/multiversiondocs/ nmerge].<br /> <br /> Collecting ideas from the mailinglist by James Cummings, Dan O'Donnell and Marjorie Burghart as well as following the [[Textual_Variance|“Gothenburg model” of textual variance]], a first take at separating the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller model from the representation] of textual variance could be structured as follows.<br /> <br /> === Modelling input data: Make the units of a collation addressable in the witnesses ===<br /> <br /> The Gothenburg model assumes a [[Textual_Variance#Tokenizer|preprocessing step]] by which the witnesses get split up into '''tokens''' of desired granularity. This granularity becomes the minimal unit of collation and can defined as pages, paragraphs, verses, lines, words, characters or any other unit that makes sense in the context of a particular tradition under investigation. To model collation results on top of tokenized witnesses, those tokens have to be addressable.<br /> <br /> The TEI defines an [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAXP array of pointing mechanisms], which can be used to address anything from a whole XML document via URIs down to arbitrary content of those documents via sophisticated XPointer schemes. Projects would be free to choose among those mechanisms as long as each token is made available for later reference.<br /> <br /> Examples:<br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_1"><br /> <w>The</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w> <w>quickly</w>.<br /> </p><br /> </pre><br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_2"><br /> <w>Quickly</w>, <w>the</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w>.<br /> </p><br /> </pre><br /> <br /> Here tokens on the word-level could be addressed via the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSXP xpath1() XPointer scheme]:<br /> <br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[1])</nowiki><br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[2])</nowiki><br /> # ...<br /> <br /> A less verbose scheme would rely on each container element of a token being identified via a (possibly autogenerated) <code>xml:id</code> attribute, like in the following verse-level tokenization.<br /> <br /> <pre><br /> <lg xml:base="urn:goethe:faust2"><br /> <l xml:id="l_1">Die Sonne sinkt, die letzten Schiffe</l><br /> <l xml:id="l_2">Sie ziehen munter hafenein.</l><br /> <l xml:id="l_3">Ein großer Kahn ist im Begriffe</l><br /> <l xml:id="l_4">Auf dem Canale hier zu sein.</l><br /> </lg><br /> </pre><br /> <br /> # <nowiki>urn:goethe:faust2#l_1</nowiki><br /> # <nowiki>urn:goethe:faust2#l_2</nowiki><br /> # ...<br /> <br /> One can even think of reference schemes, which are as independent of existing markup as possible. By introducing &lt;anchor/> milestone elements at token boundaries and using the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSRN range() XPointer scheme] the tokenization of arbitrary TEI documents can be accomplished, because &lt;anchor/> is part of [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.global.html model.global].<br /> <br /> === Modelling collated data: Encode the alignment/linking between tokens ===<br /> <br /> After tokens in the different witnesses have been made addressable, collation data can be modelled on top of that as [[Textual_Variance#Aligner|alignments of tokens]]. An '''alignment''' can be expressed as a set of tokens from different witnesses or, in accordance with the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html corresponding guidelines chapter] as a link between two or more tokens.<br /> <br /> Taking the first example from above, a collation of the two given witnesses could be expressed as<br /> <br /> <pre><br /> <linkGrp type="collation" xml:base="http://edition.org/"><br /> <link target="witness_1#xpath1(/p[1]/w[1]) witness_2#xpath1(/p[1]/w[2])" /><br /> <link target="witness_1#xpath1(/p[1]/w[2]) witness_2#xpath1(/p[1]/w[3])" /><br /> <link target="witness_1#xpath1(/p[1]/w[3]) witness_2#xpath1(/p[1]/w[4])" /><br /> <link target="witness_1#xpath1(/p[1]/w[4]) witness_2#xpath1(/p[1]/w[5])" /><br /> <link target="witness_1#xpath1(/p[1]/w[5]) witness_2#xpath1(/p[1]/w[6])" /><br /> <link target="witness_1#xpath1(/p[1]/w[6]) witness_2#xpath1(/p[1]/w[1])" type="transposition" /><br /> </linkGrp><br /> </pre><br /> <br /> Each link in this example corresponds to a row in an alignment table as depicted in the Gothenburg model description. Omitted/ added tokens are expressed implictly by not linking to tokens in other witnesses, this is to say: Whether a set of tokens has been added to a witness or has been omitted from it, is a matter of interpreting collation data as expressed above from the perspective of one witness or another and with regard to the way, this witness aligns with others.<br /> <br /> One advantage of encoding collation data in such a set-oriented way is its '''scalability''':<br /> <br /> # Gradually adding witnesses to the collation may amount to adding alignments to the existing ones or modifying/augmenting the latter, depending on whether the collation is done pairwise (e. g. in relation to a base text) or via multiple alignment (e. g. without a prechosen base).<br /> # Guiding a collation tool in producing ever more precise aligments in consecutive runs can be achieved by [[Textual_Variance#Analyzer|declaring alignments]] (for example transpositions), feeding those into the collator, adjusting the resulting alignment set, feeding it back into the collator for another run and so forth. Being able to encode the initial/preliminary results of such an iterative process in a standardized way, makes it possible to run different collation tools on the same text tradition, ideally each being able to make use of former results by other tools and to contribute to the overall result.<br /> <br /> The major disadvantage of encoding collation data this way is its apparant lack of human readability and that it is hardly possible to edit it by hand, especially when the collated text tradition grows larger. This problem can only be solved via tool support.<br /> <br /> === Encoding the interpretation/ representation: Derive an apparatus from the collation ===<br /> <br /> A TEI-encoded critical apparatus is one possible rendition of collation data, possibly enhanced with information yielded from interpreting the alignments. There are a couple of ways how we could encode the above collation as an apparatus.<br /> <br /> ==== Apparatus pointing to the collated tokens (for easier post-processing) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" xml:id="w2_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2"><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" corresp="#w2_1"><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> ==== Apparatus with embedded textual content (for readability) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:id="w2_1">Quickly,</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1">The cat ate the food</rdg><br /> <rdg wit="http://edition.org/witness_2">the cat ate the food.</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" corresp="#w2_1">quickly.</rdg><br /> <rdg wit="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> Some problems here:<br /> <br /> * @corresp vs. <link/> for transpositions over more than two witnesses<br /> * How to derive the segment content from the original witness automatically, if the token content does not add up to it (e. g. because of punctuation being excluded from the tokens from the start)?<br /> <br /> == Bibliography ==<br /> <br /> * O'Donnell, Daniel Paul. [http://etjanst.hb.se/bhs/ith/1-8/dpo.pdf “The Ghost in the Machine: Revisiting an Old Model for the Dynamic Generation of Digital Editions.”] HumanIT 8.1 (2005): 5171.<br /> * Vetter, L. and McDonald, J. ‘Witnessing Dickinson’s Witnesses’, Literary and Linguistic Computing, 18.2: 2003, 151-165.<br /> * [http://eprints.qut.edu.au/38436/ Schmidt, D., 2010. The inadequacy of embedded markup for cultural heritage texts. Literary and Linguistic Computing, 25(3), pp. 337-356.]<br /> <br /> [[Category:SIG:Manuscripts]]<br /> [[Category:Critical Apparatus]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9835 Critical Apparatus Workgroup 2011-09-02T17:38:58Z

<p>Mburghart: /* Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> <br /> Participants to the preliminary workgroup:<br /> <br /> * Marjorie Burghart (MB)<br /> * James Cummings (JC)<br /> * Fotis Jannidis (FJ)<br /> * Gregor Middell (GM)<br /> * Dan O'Donnell (DOD)<br /> * Espen Ore (EO)<br /> * Elena Pierazzo (EP)<br /> * Roberto Rosselli del Turco (RDT)<br /> * Pascale Sutter (PS)<br /> * Chris Wittern (CW)<br /> <br /> <br /> <br /> == “Critical Apparatus” vs. “Textual Variance” vs. “Textual Variants”== <br /> <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the '''critical apparatus''' is just inherited from the printed world and one of the possible physical embodiment of '''textual variance'''. EP therefore proposes to use this new name, moving from "critical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use '''textual variants''' instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart of the current critical apparatus recommendations. That of encoding an apparatus at the site of textual variance and encoding a structured view of a note entirely separate from the edited version of texts. (In mass digitization of critical editions, for example, one might have an <app> in a set of notes at the bottom of the page which are not encoded at the site of variance, or indeed necessarily connected with it.) It is this striving to both be able to encode all sorts of various legacy forms of apparatus as well as simultaneously catering for those who are recording the structure by which they will generate an apparatus in producing some output. So JC would argue that the first of these are apparatus and the second of these is a site/locus of textual variance.<br /> <br /> == Issues == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === Specific phenomena ===<br /> <br /> ==== Transpositions ====<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions.<br /> <br /> Additionally it is not possible to mark them up explicitly. [http://juxtasoftware.org/ Juxta] for example works around that by storing transposition data in a custom XML format:<br /> <br /> <pre><br /> <moves><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10462" doc2="1881 1st Ed." space2="original" start2="9872" end2="10467" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10483" doc2="1870 2nd Ed." space2="original" start2="7781" end2="8376" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10504" doc2="1870 Proof" space2="original" start2="8458" end2="9056" /><br /> <move doc1="1855 MS" space1="original" start1="9886" end1="10525" doc2="1870 1st Ed." space2="original" start2="8546" end2="9141" /><br /> <move doc1="1870 Proof" space1="original" start1="1640" end1="1850" doc2="1881 1st Ed." space2="original" start2="2961" end2="3070" /><br /> </moves><br /> </pre><br /> <br /> Neither is this TEI-compliant, nor is the offset/range-based addressing (@start1/@start2 and @end1/@end2) proper XML markup. A standardized encoding would be helpful.<br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/fuszgtpnn2ywf6bh<br /> <br /> ==== Handling of punctuation ====<br /> <br /> Seems to be a common problem in textual criticism/ apparatus creation, but lacks guidelines/ encoding examples:<br /> <br /> * http://tei.markmail.org/thread/es6byhxpsbgkrxzo<br /> <br /> ==== Representing omissions in an apparatus ====<br /> <br /> What's the proper way to represent missing lines/ paragraphs/ verses?<br /> <br /> * http://tei.markmail.org/thread/parztmwmlx5mqsof<br /> * http://tei.markmail.org/thread/4sheu6nji3dvnf64<br /> <br /> === Markup-related ===<br /> <br /> ==== Inclusion of structural markup in the apparatus ====<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s.<br /> <br /> Use case: <br /> <br /> <blockquote style="background:#FFEAEA">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> * http://tei.markmail.org/thread/tbzi2yj5xd4dto34<br /> <br /> More use cases from TEI-L:<br /> <br /> * http://tei.markmail.org/thread/jyezaqfycaldtdcv<br /> * http://tei.markmail.org/thread/fbyuxyabbxq4rwbr<br /> * http://tei.markmail.org/thread/vrwkl7kkruulyjzh<br /> * http://tei.markmail.org/thread/x5agpwzn4hiwwwcx<br /> <br /> ==== Encoding variants in structural markup ====<br /> <br /> * http://tei.markmail.org/thread/ap62n37uf6rbfds4<br /> * http://tei.markmail.org/thread/hbmnsn3v4aqjabt3<br /> <br /> ==== Conflicts between individual readings and the semantics of structural markup that surrounds it ====<br /> <br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> === Workflow-related ===<br /> <br /> ==== Scalability ====<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses.<br /> <br /> <blockquote style="background:#FFEAEA"><br /> Scaling is generally a problem with methods of indicating textual variance, but in parallel segmentation this is exacerbated because as the number of witnesses increase, the likelihood of needing to reformulate the reading boundaries, never mind the difficulty in reading or understanding such encodings. This may be a problem not only when looking at a single text with many witnesses, where variation in structure may be extremely difficult to represent where conflicts occur which disrupt this very basic structure (for example, imagine a set of witnesses where some have lines in linegroups, some just lines, some paragraphs, some paragraphs in divisions, but all with the same underlying text). But also where parallel segmentation is being used to record divergent interpretations of these individual witnesses by many editors (for distributed co-operative editions generated from many editorial views of a text). A plausible recommendation is to use a form of stand-off apparatus for such editions rather than parallel segmentation. And while some of the current methods can be used in a stand-off method, they should be updated to reflect current P5 usage of URI-based pointers.<br /> </blockquote><br /> <br /> ==== Refactoring ====<br /> <br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn.<br /> <br /> ==== Complexity ====<br /> <br /> Manually crafting an apparatus is error-prone:<br /> <br /> * http://tei.markmail.org/thread/yuxqotf5aynxznq5<br /> <br /> ==== Feasibility of double-endpoint-attached method ====<br /> <br /> * http://tei.markmail.org/thread/fsj7gvojds4mwcm5<br /> * http://tei.markmail.org/thread/flwcnf4fxm4u7ebj<br /> <br /> === Model vs. Representation ===<br /> <br /> ==== Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note ====<br /> <br /> In a nutshell: depending on the desired output of your digital edition, you may need to show in the apparatus entry a lemma text different from the content of the <lem> or desired <rdg>. This is typically the case for long omissions, when one does not display the full text that is omitted by one or more witnesses, but only the beginning and end of the omitted span of text.<br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">Let's consider again the example used in a previous use case: <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> <br/><br/><br /> You certainly do not want to generate a footnote with these two full paragraphs to tell the reader that one witness omits them, but on the other hand you want to be able to represent the source according to its various witnesses, so location-referenced is not in order. <br /> </blockquote><br /> <br /> Possible workaround: add a new possible child to <add>, indicating how the content of the <lem> should be dislayed; something like: <br /> <br /> <app><br /> <lemDisplay>Eodem anno, rex Francie… dampnificati</lemDisplay><br /> <lem>[several lines or paragraphs]</lem><br /> <rdg wit="#V"></rdg><br /> </app><br /> <br /> ==== Representing "verbose" apparatus ====<br /> <br /> In a nutshell: when you want to represent an apparatus entry written in a rather verbose way (in a print-to-digital edition). The same is true if you want to be able to generate a verbose apparatus note in a "born digital" edition. <br /> <br /> Use cases: <br /> <blockquote style="background:#FFEAEA">You're encoding an existing edition, and want to represent the source it edits, while keeping intact the text / apparatus of the existing edition. Some apparatus entries are easy to represent with the <app> / <lem> / <rdg> elements, some others add editorial comments to the listing of the variants, and are quite difficult to represent. BTW, the same goes when you are encoding a born-digital edition for which you want to be able to generate an alternative print output corresponding to the traditional standards of a collection. <br /> <br/><br/><br /> A - When I have a footnote giving two <i>lectiones</i> from the same manuscrip, one before correction and the other after: <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Text<span class="moz-txt-tag"></span></b>: ad lectorem Venetum (b) .<br /> <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Note<span class="moz-txt-tag"></span></b>: b) <i>ms.</i>, lectionem venerum <i class="moz-txt-slash"><span class="moz-txt-tag"></span>corrigé postérieurement en<span class="moz-txt-tag"></span></i> lectorem Venetum<br /> <br/><br /> <br/><br /> If I encode it like this, with two seprate rdg for the same<br /> witness, each with a different @type (for instance, "anteCorr" and<br /> "postCorr"), it gives an accurate account of the state of the witness, BUT it is an<br /> interpretation of the original note in the critical apparatus, i.e. if<br /> I do this I delete some text added by the original editor. <br><br /> <br /> &lt;app n="b"&gt;<br /> <br><br /> &lt;lem&gt;lectorem Venetum&lt;/lem&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="anteCorr"&gt;lectionem venerum&lt;/rdg&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="postCorr"&gt;lectorem Venetum&lt;/rdg&gt;<br /> <br /> <br><br /> &lt;/app&gt;<br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> Let's consider this other note. There is some text added verbosely within the apparatus note by the editor. <br/><br /> <p class="MsoNormal" style="text-align: justify;"><b style=""><span style="">Text</span></b><span style="">: Hiis diebus civitas<br /> Pergamensis(b) tenebat exersitum</span><br/><br /> <b style=""><span style="">Note</span></b><span style="">: b) se, <i>mis indûment avant</i> tenebat <i>par le ms</i>.</span></p><br /> <br /> <p class="MsoNormal"><span style="">Should I encode it as: <br><br /> ... Pergamensis &lt;app<br /> n="b"&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt;&lt;/rdg&gt;<br><br /> &lt;/app&gt;</span>... <br><br /> </p><br /> <br /> I one represents this note strictly with the <app> / <rdg>, it leads to suppress remarks by the original editor. Adding a note in the rdg to preserve the editor's comments could work here, ut it's not always the case<br/><br /> Like: <br/><br /> <span style="">... Pergamensis &lt;app<br /> n="b"&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt; </span><span style="">&lt;note&gt;&lt;hi<br /> rend="italics"&gt;<span style="">mis<br /> indûment avant</span>&lt;/hi&gt; tenebat.</span><span style="">&lt;/note&gt;&lt;/rdg&gt;<br><br /> <br /> &lt;/app&gt;</span><br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> <p class="MsoNormal" style="text-align: justify;">'''Text'''<span style="">: …reliqui demum meos socios (d)</span><br><br /> '''Note'''<span style="">: d) domum<br /> meam solito, <i>Bal.;</i> dni <i>ou</i> dm, <i>ms.; en note</i> meam solita.</span></p><br /> <br /> Here we have 2 witnesses (Bal. et ms.), the latter with a) an uncertain<br /> lectio ("dni" or "dm") and b) a part of the lectio which is written as<br /> a note ("meam solita"). This is tricky to encode. <br /> </blockquote><br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/ib3bsrpirepp4ibc<br /> * http://tei.markmail.org/thread/diubpw5adw6ntcas<br /> <br /> ==== Representation of suggestions by the editor: ''lege'' ''dele'' etc. ====<br /> <br /> In a nutshell: Sometimes, the editor provides working suggestions through apparatus notes such as ''lege(ndum)'' ("read"), ''dele(ndum)'' ("delete)" etc. They do not belong in the textual variants ''per se'', and are not attached to witnesses, although they do belong in the critical apparatus.<br /> <br /> * http://tei.markmail.org/thread/vfw25psb5vgdiftw<br /> <br /> ==== Collations of differing granularity ====<br /> <br /> * http://tei.markmail.org/thread/bonflsyb2d3ebtp2<br /> * http://tei.markmail.org/thread/gqyymzd4a4xvhch7<br /> <br /> == An encoding proposal from the perspective of computer-aided collation tools == <br /> <br /> Gregor Middell gave an overview of textual variance from a software developer's perspective for the workgroup on a [[Textual_Variance|separate page]]. The models described there are used in tools like [http://collatex.sourceforge.net/ CollateX], [http://www.juxtasoftware.org/ Juxta] and [http://code.google.com/p/multiversiondocs/ nmerge].<br /> <br /> Collecting ideas from the mailinglist by James Cummings, Dan O'Donnell and Marjorie Burghart as well as following the [[Textual_Variance|“Gothenburg model” of textual variance]], a first take at separating the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller model from the representation] of textual variance could be structured as follows.<br /> <br /> === Modelling input data: Make the units of a collation addressable in the witnesses ===<br /> <br /> The Gothenburg model assumes a [[Textual_Variance#Tokenizer|preprocessing step]] by which the witnesses get split up into '''tokens''' of desired granularity. This granularity becomes the minimal unit of collation and can defined as pages, paragraphs, verses, lines, words, characters or any other unit that makes sense in the context of a particular tradition under investigation. To model collation results on top of tokenized witnesses, those tokens have to be addressable.<br /> <br /> The TEI defines an [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAXP array of pointing mechanisms], which can be used to address anything from a whole XML document via URIs down to arbitrary content of those documents via sophisticated XPointer schemes. Projects would be free to choose among those mechanisms as long as each token is made available for later reference.<br /> <br /> Examples:<br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_1"><br /> <w>The</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w> <w>quickly</w>.<br /> </p><br /> </pre><br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_2"><br /> <w>Quickly</w>, <w>the</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w>.<br /> </p><br /> </pre><br /> <br /> Here tokens on the word-level could be addressed via the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSXP xpath1() XPointer scheme]:<br /> <br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[1])</nowiki><br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[2])</nowiki><br /> # ...<br /> <br /> A less verbose scheme would rely on each container element of a token being identified via a (possibly autogenerated) <code>xml:id</code> attribute, like in the following verse-level tokenization.<br /> <br /> <pre><br /> <lg xml:base="urn:goethe:faust2"><br /> <l xml:id="l_1">Die Sonne sinkt, die letzten Schiffe</l><br /> <l xml:id="l_2">Sie ziehen munter hafenein.</l><br /> <l xml:id="l_3">Ein großer Kahn ist im Begriffe</l><br /> <l xml:id="l_4">Auf dem Canale hier zu sein.</l><br /> </lg><br /> </pre><br /> <br /> # <nowiki>urn:goethe:faust2#l_1</nowiki><br /> # <nowiki>urn:goethe:faust2#l_2</nowiki><br /> # ...<br /> <br /> One can even think of reference schemes, which are as independent of existing markup as possible. By introducing &lt;anchor/> milestone elements at token boundaries and using the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSRN range() XPointer scheme] the tokenization of arbitrary TEI documents can be accomplished, because &lt;anchor/> is part of [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.global.html model.global].<br /> <br /> === Modelling collated data: Encode the alignment/linking between tokens ===<br /> <br /> After tokens in the different witnesses have been made addressable, collation data can be modelled on top of that as [[Textual_Variance#Aligner|alignments of tokens]]. An '''alignment''' can be expressed as a set of tokens from different witnesses or, in accordance with the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html corresponding guidelines chapter] as a link between two or more tokens.<br /> <br /> Taking the first example from above, a collation of the two given witnesses could be expressed as<br /> <br /> <pre><br /> <linkGrp type="collation" xml:base="http://edition.org/"><br /> <link target="witness_1#xpath1(/p[1]/w[1]) witness_2#xpath1(/p[1]/w[2])" /><br /> <link target="witness_1#xpath1(/p[1]/w[2]) witness_2#xpath1(/p[1]/w[3])" /><br /> <link target="witness_1#xpath1(/p[1]/w[3]) witness_2#xpath1(/p[1]/w[4])" /><br /> <link target="witness_1#xpath1(/p[1]/w[4]) witness_2#xpath1(/p[1]/w[5])" /><br /> <link target="witness_1#xpath1(/p[1]/w[5]) witness_2#xpath1(/p[1]/w[6])" /><br /> <link target="witness_1#xpath1(/p[1]/w[6]) witness_2#xpath1(/p[1]/w[1])" type="transposition" /><br /> </linkGrp><br /> </pre><br /> <br /> Each link in this example corresponds to a row in an alignment table as depicted in the Gothenburg model description. Omitted/ added tokens are expressed implictly by not linking to tokens in other witnesses, this is to say: Whether a set of tokens has been added to a witness or has been omitted from it, is a matter of interpreting collation data as expressed above from the perspective of one witness or another and with regard to the way, this witness aligns with others.<br /> <br /> One advantage of encoding collation data in such a set-oriented way is its '''scalability''':<br /> <br /> # Gradually adding witnesses to the collation may amount to adding alignments to the existing ones or modifying/augmenting the latter, depending on whether the collation is done pairwise (e. g. in relation to a base text) or via multiple alignment (e. g. without a prechosen base).<br /> # Guiding a collation tool in producing ever more precise aligments in consecutive runs can be achieved by [[Textual_Variance#Analyzer|declaring alignments]] (for example transpositions), feeding those into the collator, adjusting the resulting alignment set, feeding it back into the collator for another run and so forth. Being able to encode the initial/preliminary results of such an iterative process in a standardized way, makes it possible to run different collation tools on the same text tradition, ideally each being able to make use of former results by other tools and to contribute to the overall result.<br /> <br /> The major disadvantage of encoding collation data this way is its apparant lack of human readability and that it is hardly possible to edit it by hand, especially when the collated text tradition grows larger. This problem can only be solved via tool support.<br /> <br /> === Encoding the interpretation/ representation: Derive an apparatus from the collation ===<br /> <br /> A TEI-encoded critical apparatus is one possible rendition of collation data, possibly enhanced with information yielded from interpreting the alignments. There are a couple of ways how we could encode the above collation as an apparatus.<br /> <br /> ==== Apparatus pointing to the collated tokens (for easier post-processing) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" xml:id="w2_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2"><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" corresp="#w2_1"><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> ==== Apparatus with embedded textual content (for readability) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:id="w2_1">Quickly,</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1">The cat ate the food</rdg><br /> <rdg wit="http://edition.org/witness_2">the cat ate the food.</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" corresp="#w2_1">quickly.</rdg><br /> <rdg wit="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> Some problems here:<br /> <br /> * @corresp vs. <link/> for transpositions over more than two witnesses<br /> * How to derive the segment content from the original witness automatically, if the token content does not add up to it (e. g. because of punctuation being excluded from the tokens from the start)?<br /> <br /> == Bibliography ==<br /> <br /> * O'Donnell, Daniel Paul. [http://etjanst.hb.se/bhs/ith/1-8/dpo.pdf “The Ghost in the Machine: Revisiting an Old Model for the Dynamic Generation of Digital Editions.”] HumanIT 8.1 (2005): 5171.<br /> * Vetter, L. and McDonald, J. ‘Witnessing Dickinson’s Witnesses’, Literary and Linguistic Computing, 18.2: 2003, 151-165.<br /> * [http://eprints.qut.edu.au/38436/ Schmidt, D., 2010. The inadequacy of embedded markup for cultural heritage texts. Literary and Linguistic Computing, 25(3), pp. 337-356.]<br /> <br /> [[Category:SIG:Manuscripts]]<br /> [[Category:Critical Apparatus]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9834 Critical Apparatus Workgroup 2011-09-02T17:38:28Z

<p>Mburghart: /* Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> <br /> Participants to the preliminary workgroup:<br /> <br /> * Marjorie Burghart (MB)<br /> * James Cummings (JC)<br /> * Fotis Jannidis (FJ)<br /> * Gregor Middell (GM)<br /> * Dan O'Donnell (DOD)<br /> * Espen Ore (EO)<br /> * Elena Pierazzo (EP)<br /> * Roberto Rosselli del Turco (RDT)<br /> * Pascale Sutter (PS)<br /> * Chris Wittern (CW)<br /> <br /> <br /> <br /> == “Critical Apparatus” vs. “Textual Variance” vs. “Textual Variants”== <br /> <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the '''critical apparatus''' is just inherited from the printed world and one of the possible physical embodiment of '''textual variance'''. EP therefore proposes to use this new name, moving from "critical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use '''textual variants''' instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart of the current critical apparatus recommendations. That of encoding an apparatus at the site of textual variance and encoding a structured view of a note entirely separate from the edited version of texts. (In mass digitization of critical editions, for example, one might have an <app> in a set of notes at the bottom of the page which are not encoded at the site of variance, or indeed necessarily connected with it.) It is this striving to both be able to encode all sorts of various legacy forms of apparatus as well as simultaneously catering for those who are recording the structure by which they will generate an apparatus in producing some output. So JC would argue that the first of these are apparatus and the second of these is a site/locus of textual variance.<br /> <br /> == Issues == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === Specific phenomena ===<br /> <br /> ==== Transpositions ====<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions.<br /> <br /> Additionally it is not possible to mark them up explicitly. [http://juxtasoftware.org/ Juxta] for example works around that by storing transposition data in a custom XML format:<br /> <br /> <pre><br /> <moves><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10462" doc2="1881 1st Ed." space2="original" start2="9872" end2="10467" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10483" doc2="1870 2nd Ed." space2="original" start2="7781" end2="8376" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10504" doc2="1870 Proof" space2="original" start2="8458" end2="9056" /><br /> <move doc1="1855 MS" space1="original" start1="9886" end1="10525" doc2="1870 1st Ed." space2="original" start2="8546" end2="9141" /><br /> <move doc1="1870 Proof" space1="original" start1="1640" end1="1850" doc2="1881 1st Ed." space2="original" start2="2961" end2="3070" /><br /> </moves><br /> </pre><br /> <br /> Neither is this TEI-compliant, nor is the offset/range-based addressing (@start1/@start2 and @end1/@end2) proper XML markup. A standardized encoding would be helpful.<br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/fuszgtpnn2ywf6bh<br /> <br /> ==== Handling of punctuation ====<br /> <br /> Seems to be a common problem in textual criticism/ apparatus creation, but lacks guidelines/ encoding examples:<br /> <br /> * http://tei.markmail.org/thread/es6byhxpsbgkrxzo<br /> <br /> ==== Representing omissions in an apparatus ====<br /> <br /> What's the proper way to represent missing lines/ paragraphs/ verses?<br /> <br /> * http://tei.markmail.org/thread/parztmwmlx5mqsof<br /> * http://tei.markmail.org/thread/4sheu6nji3dvnf64<br /> <br /> === Markup-related ===<br /> <br /> ==== Inclusion of structural markup in the apparatus ====<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s.<br /> <br /> Use case: <br /> <br /> <blockquote style="background:#FFEAEA">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> * http://tei.markmail.org/thread/tbzi2yj5xd4dto34<br /> <br /> More use cases from TEI-L:<br /> <br /> * http://tei.markmail.org/thread/jyezaqfycaldtdcv<br /> * http://tei.markmail.org/thread/fbyuxyabbxq4rwbr<br /> * http://tei.markmail.org/thread/vrwkl7kkruulyjzh<br /> * http://tei.markmail.org/thread/x5agpwzn4hiwwwcx<br /> <br /> ==== Encoding variants in structural markup ====<br /> <br /> * http://tei.markmail.org/thread/ap62n37uf6rbfds4<br /> * http://tei.markmail.org/thread/hbmnsn3v4aqjabt3<br /> <br /> ==== Conflicts between individual readings and the semantics of structural markup that surrounds it ====<br /> <br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> === Workflow-related ===<br /> <br /> ==== Scalability ====<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses.<br /> <br /> <blockquote style="background:#FFEAEA"><br /> Scaling is generally a problem with methods of indicating textual variance, but in parallel segmentation this is exacerbated because as the number of witnesses increase, the likelihood of needing to reformulate the reading boundaries, never mind the difficulty in reading or understanding such encodings. This may be a problem not only when looking at a single text with many witnesses, where variation in structure may be extremely difficult to represent where conflicts occur which disrupt this very basic structure (for example, imagine a set of witnesses where some have lines in linegroups, some just lines, some paragraphs, some paragraphs in divisions, but all with the same underlying text). But also where parallel segmentation is being used to record divergent interpretations of these individual witnesses by many editors (for distributed co-operative editions generated from many editorial views of a text). A plausible recommendation is to use a form of stand-off apparatus for such editions rather than parallel segmentation. And while some of the current methods can be used in a stand-off method, they should be updated to reflect current P5 usage of URI-based pointers.<br /> </blockquote><br /> <br /> ==== Refactoring ====<br /> <br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn.<br /> <br /> ==== Complexity ====<br /> <br /> Manually crafting an apparatus is error-prone:<br /> <br /> * http://tei.markmail.org/thread/yuxqotf5aynxznq5<br /> <br /> ==== Feasibility of double-endpoint-attached method ====<br /> <br /> * http://tei.markmail.org/thread/fsj7gvojds4mwcm5<br /> * http://tei.markmail.org/thread/flwcnf4fxm4u7ebj<br /> <br /> === Model vs. Representation ===<br /> <br /> ==== Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note ====<br /> <br /> In a nutshell: depending on the desired output of your digital edition, you may need to show in the apparatus entry a lemma text different from the content of the <lem> or desired <rdg>. This is typically the case for long omissions, when one does not display the full text that is omitted by one or more witnesses, but only the beginning and end of the omitted span of text.<br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">Let's consider again the example used in a previous use case: <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> <br/><br/><br /> You certainly do not want to generate a footnote with these two full paragraphs to tell the reader that one witness omits them, but on the other hand you want to be able to represent the source according to its various witnesses, so location-referenced is not in order. <br /> </blockquote><br /> <br /> Possible workaround: add a new possible child to <add>, indicating how the content of the <lem> should be dislayed; something like: <br /> <app><br /> <lemDisplay>Eodem anno, rex Francie… dampnificati</lemDisplay><br /> <lem>[several lines or paragraphs]</lem><br /> <rdg wit="#V"></rdg><br /> </app><br /> <br /> ==== Representing "verbose" apparatus ====<br /> <br /> In a nutshell: when you want to represent an apparatus entry written in a rather verbose way (in a print-to-digital edition). The same is true if you want to be able to generate a verbose apparatus note in a "born digital" edition. <br /> <br /> Use cases: <br /> <blockquote style="background:#FFEAEA">You're encoding an existing edition, and want to represent the source it edits, while keeping intact the text / apparatus of the existing edition. Some apparatus entries are easy to represent with the <app> / <lem> / <rdg> elements, some others add editorial comments to the listing of the variants, and are quite difficult to represent. BTW, the same goes when you are encoding a born-digital edition for which you want to be able to generate an alternative print output corresponding to the traditional standards of a collection. <br /> <br/><br/><br /> A - When I have a footnote giving two <i>lectiones</i> from the same manuscrip, one before correction and the other after: <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Text<span class="moz-txt-tag"></span></b>: ad lectorem Venetum (b) .<br /> <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Note<span class="moz-txt-tag"></span></b>: b) <i>ms.</i>, lectionem venerum <i class="moz-txt-slash"><span class="moz-txt-tag"></span>corrigé postérieurement en<span class="moz-txt-tag"></span></i> lectorem Venetum<br /> <br/><br /> <br/><br /> If I encode it like this, with two seprate rdg for the same<br /> witness, each with a different @type (for instance, "anteCorr" and<br /> "postCorr"), it gives an accurate account of the state of the witness, BUT it is an<br /> interpretation of the original note in the critical apparatus, i.e. if<br /> I do this I delete some text added by the original editor. <br><br /> <br /> &lt;app n="b"&gt;<br /> <br><br /> &lt;lem&gt;lectorem Venetum&lt;/lem&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="anteCorr"&gt;lectionem venerum&lt;/rdg&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="postCorr"&gt;lectorem Venetum&lt;/rdg&gt;<br /> <br /> <br><br /> &lt;/app&gt;<br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> Let's consider this other note. There is some text added verbosely within the apparatus note by the editor. <br/><br /> <p class="MsoNormal" style="text-align: justify;"><b style=""><span style="">Text</span></b><span style="">: Hiis diebus civitas<br /> Pergamensis(b) tenebat exersitum</span><br/><br /> <b style=""><span style="">Note</span></b><span style="">: b) se, <i>mis indûment avant</i> tenebat <i>par le ms</i>.</span></p><br /> <br /> <p class="MsoNormal"><span style="">Should I encode it as: <br><br /> ... Pergamensis &lt;app<br /> n="b"&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt;&lt;/rdg&gt;<br><br /> &lt;/app&gt;</span>... <br><br /> </p><br /> <br /> I one represents this note strictly with the <app> / <rdg>, it leads to suppress remarks by the original editor. Adding a note in the rdg to preserve the editor's comments could work here, ut it's not always the case<br/><br /> Like: <br/><br /> <span style="">... Pergamensis &lt;app<br /> n="b"&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt; </span><span style="">&lt;note&gt;&lt;hi<br /> rend="italics"&gt;<span style="">mis<br /> indûment avant</span>&lt;/hi&gt; tenebat.</span><span style="">&lt;/note&gt;&lt;/rdg&gt;<br><br /> <br /> &lt;/app&gt;</span><br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> <p class="MsoNormal" style="text-align: justify;">'''Text'''<span style="">: …reliqui demum meos socios (d)</span><br><br /> '''Note'''<span style="">: d) domum<br /> meam solito, <i>Bal.;</i> dni <i>ou</i> dm, <i>ms.; en note</i> meam solita.</span></p><br /> <br /> Here we have 2 witnesses (Bal. et ms.), the latter with a) an uncertain<br /> lectio ("dni" or "dm") and b) a part of the lectio which is written as<br /> a note ("meam solita"). This is tricky to encode. <br /> </blockquote><br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/ib3bsrpirepp4ibc<br /> * http://tei.markmail.org/thread/diubpw5adw6ntcas<br /> <br /> ==== Representation of suggestions by the editor: ''lege'' ''dele'' etc. ====<br /> <br /> In a nutshell: Sometimes, the editor provides working suggestions through apparatus notes such as ''lege(ndum)'' ("read"), ''dele(ndum)'' ("delete)" etc. They do not belong in the textual variants ''per se'', and are not attached to witnesses, although they do belong in the critical apparatus.<br /> <br /> * http://tei.markmail.org/thread/vfw25psb5vgdiftw<br /> <br /> ==== Collations of differing granularity ====<br /> <br /> * http://tei.markmail.org/thread/bonflsyb2d3ebtp2<br /> * http://tei.markmail.org/thread/gqyymzd4a4xvhch7<br /> <br /> == An encoding proposal from the perspective of computer-aided collation tools == <br /> <br /> Gregor Middell gave an overview of textual variance from a software developer's perspective for the workgroup on a [[Textual_Variance|separate page]]. The models described there are used in tools like [http://collatex.sourceforge.net/ CollateX], [http://www.juxtasoftware.org/ Juxta] and [http://code.google.com/p/multiversiondocs/ nmerge].<br /> <br /> Collecting ideas from the mailinglist by James Cummings, Dan O'Donnell and Marjorie Burghart as well as following the [[Textual_Variance|“Gothenburg model” of textual variance]], a first take at separating the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller model from the representation] of textual variance could be structured as follows.<br /> <br /> === Modelling input data: Make the units of a collation addressable in the witnesses ===<br /> <br /> The Gothenburg model assumes a [[Textual_Variance#Tokenizer|preprocessing step]] by which the witnesses get split up into '''tokens''' of desired granularity. This granularity becomes the minimal unit of collation and can defined as pages, paragraphs, verses, lines, words, characters or any other unit that makes sense in the context of a particular tradition under investigation. To model collation results on top of tokenized witnesses, those tokens have to be addressable.<br /> <br /> The TEI defines an [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAXP array of pointing mechanisms], which can be used to address anything from a whole XML document via URIs down to arbitrary content of those documents via sophisticated XPointer schemes. Projects would be free to choose among those mechanisms as long as each token is made available for later reference.<br /> <br /> Examples:<br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_1"><br /> <w>The</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w> <w>quickly</w>.<br /> </p><br /> </pre><br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_2"><br /> <w>Quickly</w>, <w>the</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w>.<br /> </p><br /> </pre><br /> <br /> Here tokens on the word-level could be addressed via the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSXP xpath1() XPointer scheme]:<br /> <br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[1])</nowiki><br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[2])</nowiki><br /> # ...<br /> <br /> A less verbose scheme would rely on each container element of a token being identified via a (possibly autogenerated) <code>xml:id</code> attribute, like in the following verse-level tokenization.<br /> <br /> <pre><br /> <lg xml:base="urn:goethe:faust2"><br /> <l xml:id="l_1">Die Sonne sinkt, die letzten Schiffe</l><br /> <l xml:id="l_2">Sie ziehen munter hafenein.</l><br /> <l xml:id="l_3">Ein großer Kahn ist im Begriffe</l><br /> <l xml:id="l_4">Auf dem Canale hier zu sein.</l><br /> </lg><br /> </pre><br /> <br /> # <nowiki>urn:goethe:faust2#l_1</nowiki><br /> # <nowiki>urn:goethe:faust2#l_2</nowiki><br /> # ...<br /> <br /> One can even think of reference schemes, which are as independent of existing markup as possible. By introducing &lt;anchor/> milestone elements at token boundaries and using the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSRN range() XPointer scheme] the tokenization of arbitrary TEI documents can be accomplished, because &lt;anchor/> is part of [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.global.html model.global].<br /> <br /> === Modelling collated data: Encode the alignment/linking between tokens ===<br /> <br /> After tokens in the different witnesses have been made addressable, collation data can be modelled on top of that as [[Textual_Variance#Aligner|alignments of tokens]]. An '''alignment''' can be expressed as a set of tokens from different witnesses or, in accordance with the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html corresponding guidelines chapter] as a link between two or more tokens.<br /> <br /> Taking the first example from above, a collation of the two given witnesses could be expressed as<br /> <br /> <pre><br /> <linkGrp type="collation" xml:base="http://edition.org/"><br /> <link target="witness_1#xpath1(/p[1]/w[1]) witness_2#xpath1(/p[1]/w[2])" /><br /> <link target="witness_1#xpath1(/p[1]/w[2]) witness_2#xpath1(/p[1]/w[3])" /><br /> <link target="witness_1#xpath1(/p[1]/w[3]) witness_2#xpath1(/p[1]/w[4])" /><br /> <link target="witness_1#xpath1(/p[1]/w[4]) witness_2#xpath1(/p[1]/w[5])" /><br /> <link target="witness_1#xpath1(/p[1]/w[5]) witness_2#xpath1(/p[1]/w[6])" /><br /> <link target="witness_1#xpath1(/p[1]/w[6]) witness_2#xpath1(/p[1]/w[1])" type="transposition" /><br /> </linkGrp><br /> </pre><br /> <br /> Each link in this example corresponds to a row in an alignment table as depicted in the Gothenburg model description. Omitted/ added tokens are expressed implictly by not linking to tokens in other witnesses, this is to say: Whether a set of tokens has been added to a witness or has been omitted from it, is a matter of interpreting collation data as expressed above from the perspective of one witness or another and with regard to the way, this witness aligns with others.<br /> <br /> One advantage of encoding collation data in such a set-oriented way is its '''scalability''':<br /> <br /> # Gradually adding witnesses to the collation may amount to adding alignments to the existing ones or modifying/augmenting the latter, depending on whether the collation is done pairwise (e. g. in relation to a base text) or via multiple alignment (e. g. without a prechosen base).<br /> # Guiding a collation tool in producing ever more precise aligments in consecutive runs can be achieved by [[Textual_Variance#Analyzer|declaring alignments]] (for example transpositions), feeding those into the collator, adjusting the resulting alignment set, feeding it back into the collator for another run and so forth. Being able to encode the initial/preliminary results of such an iterative process in a standardized way, makes it possible to run different collation tools on the same text tradition, ideally each being able to make use of former results by other tools and to contribute to the overall result.<br /> <br /> The major disadvantage of encoding collation data this way is its apparant lack of human readability and that it is hardly possible to edit it by hand, especially when the collated text tradition grows larger. This problem can only be solved via tool support.<br /> <br /> === Encoding the interpretation/ representation: Derive an apparatus from the collation ===<br /> <br /> A TEI-encoded critical apparatus is one possible rendition of collation data, possibly enhanced with information yielded from interpreting the alignments. There are a couple of ways how we could encode the above collation as an apparatus.<br /> <br /> ==== Apparatus pointing to the collated tokens (for easier post-processing) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" xml:id="w2_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2"><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" corresp="#w2_1"><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> ==== Apparatus with embedded textual content (for readability) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:id="w2_1">Quickly,</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1">The cat ate the food</rdg><br /> <rdg wit="http://edition.org/witness_2">the cat ate the food.</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" corresp="#w2_1">quickly.</rdg><br /> <rdg wit="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> Some problems here:<br /> <br /> * @corresp vs. <link/> for transpositions over more than two witnesses<br /> * How to derive the segment content from the original witness automatically, if the token content does not add up to it (e. g. because of punctuation being excluded from the tokens from the start)?<br /> <br /> == Bibliography ==<br /> <br /> * O'Donnell, Daniel Paul. [http://etjanst.hb.se/bhs/ith/1-8/dpo.pdf “The Ghost in the Machine: Revisiting an Old Model for the Dynamic Generation of Digital Editions.”] HumanIT 8.1 (2005): 5171.<br /> * Vetter, L. and McDonald, J. ‘Witnessing Dickinson’s Witnesses’, Literary and Linguistic Computing, 18.2: 2003, 151-165.<br /> * [http://eprints.qut.edu.au/38436/ Schmidt, D., 2010. The inadequacy of embedded markup for cultural heritage texts. Literary and Linguistic Computing, 25(3), pp. 337-356.]<br /> <br /> [[Category:SIG:Manuscripts]]<br /> [[Category:Critical Apparatus]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9471 Critical Apparatus Workgroup 2011-05-30T23:55:26Z

<p>Mburghart: /* An encoding proposal from the perspective of computer-aided collation tools */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> <br /> Participants to the preliminary workgroup:<br /> <br /> * Marjorie Burghart (MB)<br /> * James Cummings (JC)<br /> * Fotis Jannidis (FJ)<br /> * Gregor Middell (GM)<br /> * Dan O'Donnell (DOD)<br /> * Espen Ore (EO)<br /> * Elena Pierazzo (EP)<br /> * Roberto Rosselli del Turco (RDT)<br /> * Chris Wittern (CW)<br /> <br /> <br /> <br /> == “Critical Apparatus” vs. “Textual Variance” vs. “Textual Variants”== <br /> <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the '''critical apparatus''' is just inherited from the printed world and one of the possible physical embodiment of '''textual variance'''. EP therefore proposes to use this new name, moving from "critical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use '''textual variants''' instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart of the current critical apparatus recommendations. That of encoding an apparatus at the site of textual variance and encoding a structured view of a note entirely separate from the edited version of texts. (In mass digitization of critical editions, for example, one might have an <app> in a set of notes at the bottom of the page which are not encoded at the site of variance, or indeed necessarily connected with it.) It is this striving to both be able to encode all sorts of various legacy forms of apparatus as well as simultaneously catering for those who are recording the structure by which they will generate an apparatus in producing some output. So JC would argue that the first of these are apparatus and the second of these is a site/locus of textual variance.<br /> <br /> == Issues == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === Specific phenomena ===<br /> <br /> ==== Transpositions ====<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions.<br /> <br /> Additionally it is not possible to mark them up explicitly. [http://juxtasoftware.org/ Juxta] for example works around that by storing transposition data in a custom XML format:<br /> <br /> <pre><br /> <moves><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10462" doc2="1881 1st Ed." space2="original" start2="9872" end2="10467" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10483" doc2="1870 2nd Ed." space2="original" start2="7781" end2="8376" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10504" doc2="1870 Proof" space2="original" start2="8458" end2="9056" /><br /> <move doc1="1855 MS" space1="original" start1="9886" end1="10525" doc2="1870 1st Ed." space2="original" start2="8546" end2="9141" /><br /> <move doc1="1870 Proof" space1="original" start1="1640" end1="1850" doc2="1881 1st Ed." space2="original" start2="2961" end2="3070" /><br /> </moves><br /> </pre><br /> <br /> Neither is this TEI-compliant, nor is the offset/range-based addressing (@start1/@start2 and @end1/@end2) proper XML markup. A standardized encoding would be helpful.<br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/fuszgtpnn2ywf6bh<br /> <br /> ==== Handling of punctuation ====<br /> <br /> Seems to be a common problem in textual criticism/ apparatus creation, but lacks guidelines/ encoding examples:<br /> <br /> * http://tei.markmail.org/thread/es6byhxpsbgkrxzo<br /> <br /> ==== Representing omissions in an apparatus ====<br /> <br /> What's the proper way to represent missing lines/ paragraphs/ verses?<br /> <br /> * http://tei.markmail.org/thread/parztmwmlx5mqsof<br /> * http://tei.markmail.org/thread/4sheu6nji3dvnf64<br /> <br /> === Markup-related ===<br /> <br /> ==== Inclusion of structural markup in the apparatus ====<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s.<br /> <br /> Use case: <br /> <br /> <blockquote style="background:#FFEAEA">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> * http://tei.markmail.org/thread/tbzi2yj5xd4dto34<br /> <br /> More use cases from TEI-L:<br /> <br /> * http://tei.markmail.org/thread/jyezaqfycaldtdcv<br /> * http://tei.markmail.org/thread/fbyuxyabbxq4rwbr<br /> * http://tei.markmail.org/thread/vrwkl7kkruulyjzh<br /> * http://tei.markmail.org/thread/x5agpwzn4hiwwwcx<br /> <br /> ==== Encoding variants in structural markup ====<br /> <br /> * http://tei.markmail.org/thread/ap62n37uf6rbfds4<br /> * http://tei.markmail.org/thread/hbmnsn3v4aqjabt3<br /> <br /> ==== Conflicts between individual readings and the semantics of structural markup that surrounds it ====<br /> <br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> === Workflow-related ===<br /> <br /> ==== Scalability ====<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses.<br /> <br /> <blockquote style="background:#FFEAEA"><br /> Scaling is generally a problem with methods of indicating textual variance, but in parallel segmentation this is exacerbated because as the number of witnesses increase, the likelihood of needing to reformulate the reading boundaries, never mind the difficulty in reading or understanding such encodings. This may be a problem not only when looking at a single text with many witnesses, where variation in structure may be extremely difficult to represent where conflicts occur which disrupt this very basic structure (for example, imagine a set of witnesses where some have lines in linegroups, some just lines, some paragraphs, some paragraphs in divisions, but all with the same underlying text). But also where parallel segmentation is being used to record divergent interpretations of these individual witnesses by many editors (for distributed co-operative editions generated from many editorial views of a text). A plausible recommendation is to use a form of stand-off apparatus for such editions rather than parallel segmentation. And while some of the current methods can be used in a stand-off method, they should be updated to reflect current P5 usage of URI-based pointers.<br /> </blockquote><br /> <br /> ==== Refactoring ====<br /> <br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn.<br /> <br /> ==== Complexity ====<br /> <br /> Manually crafting an apparatus is error-prone:<br /> <br /> * http://tei.markmail.org/thread/yuxqotf5aynxznq5<br /> <br /> ==== Feasibility of double-endpoint-attached method ====<br /> <br /> * http://tei.markmail.org/thread/fsj7gvojds4mwcm5<br /> * http://tei.markmail.org/thread/flwcnf4fxm4u7ebj<br /> <br /> === Model vs. Representation ===<br /> <br /> ==== Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note ====<br /> <br /> In a nutshell: depending on the desired output of your digital edition, you may need to show in the apparatus entry a lemma text different from the content of the <lem> or desired <rdg>. This is typically the case for long omissions, when one does not display the full text that is omitted by one or more witnesses, but only the beginning and end of the omitted span of text.<br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">Let's consider again the example used in a previous use case: <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> <br/><br/><br /> You certainly do not want to generate a footnote with these two full paragraphs to tell the reader that one witness omits them, but on the other hand you want to be able to represent the source according to its various witnesses, so location-referenced is not in order. <br /> </blockquote><br /> <br /> ==== Representing "verbose" apparatus ====<br /> <br /> In a nutshell: when you want to represent an apparatus entry written in a rather verbose way (in a print-to-digital edition). The same is true if you want to be able to generate a verbose apparatus note in a "born digital" edition. <br /> <br /> Use cases: <br /> <blockquote style="background:#FFEAEA">You're encoding an existing edition, and want to represent the source it edits, while keeping intact the text / apparatus of the existing edition. Some apparatus entries are easy to represent with the <app> / <lem> / <rdg> elements, some others add editorial comments to the listing of the variants, and are quite difficult to represent. BTW, the same goes when you are encoding a born-digital edition for which you want to be able to generate an alternative print output corresponding to the traditional standards of a collection. <br /> <br/><br/><br /> A - When I have a footnote giving two <i>lectiones</i> from the same manuscrip, one before correction and the other after: <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Text<span class="moz-txt-tag"></span></b>: ad lectorem Venetum (b) .<br /> <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Note<span class="moz-txt-tag"></span></b>: b) <i>ms.</i>, lectionem venerum <i class="moz-txt-slash"><span class="moz-txt-tag"></span>corrigé postérieurement en<span class="moz-txt-tag"></span></i> lectorem Venetum<br /> <br/><br /> <br/><br /> If I encode it like this, with two seprate rdg for the same<br /> witness, each with a different @type (for instance, "anteCorr" and<br /> "postCorr"), it gives an accurate account of the state of the witness, BUT it is an<br /> interpretation of the original note in the critical apparatus, i.e. if<br /> I do this I delete some text added by the original editor. <br><br /> <br /> &lt;app n="b"&gt;<br /> <br><br /> &lt;lem&gt;lectorem Venetum&lt;/lem&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="anteCorr"&gt;lectionem venerum&lt;/rdg&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="postCorr"&gt;lectorem Venetum&lt;/rdg&gt;<br /> <br /> <br><br /> &lt;/app&gt;<br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> Let's consider this other note. There is some text added verbosely within the apparatus note by the editor. <br/><br /> <p class="MsoNormal" style="text-align: justify;"><b style=""><span style="">Text</span></b><span style="">: Hiis diebus civitas<br /> Pergamensis(b) tenebat exersitum</span><br/><br /> <b style=""><span style="">Note</span></b><span style="">: b) se, <i>mis indûment avant</i> tenebat <i>par le ms</i>.</span></p><br /> <br /> <p class="MsoNormal"><span style="">Should I encode it as: <br><br /> ... Pergamensis &lt;app<br /> n="b"&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt;&lt;/rdg&gt;<br><br /> &lt;/app&gt;</span>... <br><br /> </p><br /> <br /> I one represents this note strictly with the <app> / <rdg>, it leads to suppress remarks by the original editor. Adding a note in the rdg to preserve the editor's comments could work here, ut it's not always the case<br/><br /> Like: <br/><br /> <span style="">... Pergamensis &lt;app<br /> n="b"&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt; </span><span style="">&lt;note&gt;&lt;hi<br /> rend="italics"&gt;<span style="">mis<br /> indûment avant</span>&lt;/hi&gt; tenebat.</span><span style="">&lt;/note&gt;&lt;/rdg&gt;<br><br /> <br /> &lt;/app&gt;</span><br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> <p class="MsoNormal" style="text-align: justify;">'''Text'''<span style="">: …reliqui demum meos socios (d)</span><br><br /> '''Note'''<span style="">: d) domum<br /> meam solito, <i>Bal.;</i> dni <i>ou</i> dm, <i>ms.; en note</i> meam solita.</span></p><br /> <br /> Here we have 2 witnesses (Bal. et ms.), the latter with a) an uncertain<br /> lectio ("dni" or "dm") and b) a part of the lectio which is written as<br /> a note ("meam solita"). This is tricky to encode. <br /> </blockquote><br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/ib3bsrpirepp4ibc<br /> * http://tei.markmail.org/thread/diubpw5adw6ntcas<br /> <br /> ==== Representation of suggestions by the editor: ''lege'' ''dele'' etc. ====<br /> <br /> In a nutshell: Sometimes, the editor provides working suggestions through apparatus notes such as ''lege(ndum)'' ("read"), ''dele(ndum)'' ("delete)" etc. They do not belong in the textual variants ''per se'', and are not attached to witnesses, although they do belong in the critical apparatus.<br /> <br /> * http://tei.markmail.org/thread/vfw25psb5vgdiftw<br /> <br /> ==== Collations of differing granularity ====<br /> <br /> * http://tei.markmail.org/thread/bonflsyb2d3ebtp2<br /> * http://tei.markmail.org/thread/gqyymzd4a4xvhch7<br /> <br /> == An encoding proposal from the perspective of computer-aided collation tools == <br /> <br /> Gregor Middell gave an overview of textual variance from a software developer's perspective for the workgroup on a [[Textual_Variance|separate page]]. The models described there are used in tools like [http://collatex.sourceforge.net/ CollateX], [http://www.juxtasoftware.org/ Juxta] and [http://code.google.com/p/multiversiondocs/ nmerge].<br /> <br /> Collecting ideas from the mailinglist by James Cummings, Dan O'Donnell and Marjorie Burghart as well as following the “Gothenburg model” of textual variance, a first take at separating the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller model from the representation] of textual variance could be structured as follows.<br /> <br /> === Modelling input data: Make the units of a collation addressable in the witnesses ===<br /> <br /> The Gothenburg model assumes a [[Textual_Variance#Tokenizer|preprocessing step]] by which the witnesses get split up into '''tokens''' of desired granularity. This granularity becomes the minimal unit of collation and can defined as pages, paragraphs, verses, lines, words, characters or any other unit that makes sense in the context of a particular tradition under investigation. To model collation results on top of tokenized witnesses, those tokens have to be addressable.<br /> <br /> The TEI defines an [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAXP array of pointing mechanisms], which can be used to address anything from a whole XML document via URIs down to arbitrary content of those documents via sophisticated XPointer schemes. Projects would be free to choose among those mechanisms as long as each token is made available for later reference.<br /> <br /> Examples:<br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_1"><br /> <w>The</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w> <w>quickly</w>.<br /> </p><br /> </pre><br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_2"><br /> <w>Quickly</w>, <w>the</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w>.<br /> </p><br /> </pre><br /> <br /> Here tokens on the word-level could be addressed via the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSXP xpath1() XPointer scheme]:<br /> <br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[1])</nowiki><br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[2])</nowiki><br /> # ...<br /> <br /> A less verbose scheme would rely on each container element of a token being identified via a (possibly autogenerated) <code>xml:id</code> attribute, like in the following verse-level tokenization.<br /> <br /> <pre><br /> <lg xml:base="urn:goethe:faust2"><br /> <l xml:id="l_1">Die Sonne sinkt, die letzten Schiffe</l><br /> <l xml:id="l_2">Sie ziehen munter hafenein.</l><br /> <l xml:id="l_3">Ein großer Kahn ist im Begriffe</l><br /> <l xml:id="l_4">Auf dem Canale hier zu sein.</l><br /> </lg><br /> </pre><br /> <br /> # <nowiki>urn:goethe:faust2#l_1</nowiki><br /> # <nowiki>urn:goethe:faust2#l_2</nowiki><br /> # ...<br /> <br /> One can even think of reference schemes, which are as independent of existing markup as possible. By introducing &lt;anchor/> milestone elements at token boundaries and using the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSRN range() XPointer scheme] the tokenization of arbitrary TEI documents can be accomplished, because &lt;anchor/> is part of [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.global.html model.global].<br /> <br /> === Modelling collated data: Encode the alignment/linking between tokens ===<br /> <br /> After tokens in the different witnesses have been made addressable, collation data can be modelled on top of that as [[Textual_Variance#Aligner|alignments of tokens]]. An '''alignment''' can be expressed as a set of tokens from different witnesses or, in accordance with the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html corresponding guidelines chapter] as a link between two or more tokens.<br /> <br /> Taking the first example from above, a collation of the two given witnesses could be expressed as<br /> <br /> <pre><br /> <linkGrp type="collation" xml:base="http://edition.org/"><br /> <link target="witness_1#xpath1(/p[1]/w[1]) witness_2#xpath1(/p[1]/w[2])" /><br /> <link target="witness_1#xpath1(/p[1]/w[2]) witness_2#xpath1(/p[1]/w[3])" /><br /> <link target="witness_1#xpath1(/p[1]/w[3]) witness_2#xpath1(/p[1]/w[4])" /><br /> <link target="witness_1#xpath1(/p[1]/w[4]) witness_2#xpath1(/p[1]/w[5])" /><br /> <link target="witness_1#xpath1(/p[1]/w[5]) witness_2#xpath1(/p[1]/w[6])" /><br /> <link target="witness_1#xpath1(/p[1]/w[6]) witness_2#xpath1(/p[1]/w[1])" type="transposition" /><br /> </linkGrp><br /> </pre><br /> <br /> Each link in this example corresponds to a row in an alignment table as depicted in the Gothenburg model description. Omitted/ added tokens are expressed implictly by not linking to tokens in other witnesses, this is to say: Whether a set of tokens has been added to a witness or has been omitted from it, is a matter of interpreting collation data as expressed above from the perspective of one witness or another and with regard to the way, this witness aligns with others.<br /> <br /> One advantage of encoding collation data in such a set-oriented way is its '''scalability''':<br /> <br /> # Gradually adding witnesses to the collation may amount to adding alignments to the existing ones or modifying/augmenting the latter, depending on whether the collation is done pairwise (e. g. in relation to a base text) or via multiple alignment (e. g. without a prechosen base).<br /> # Guiding a collation tool in producing ever more precise aligments in consecutive runs can be achieved by [[Textual_Variance#Analyzer|declaring alignments]] (for example transpositions), feeding those into the collator, adjusting the resulting alignment set, feeding it back into the collator for another run and so forth. Being able to encode the initial/preliminary results of such an iterative process in a standardized way, makes it possible to run different collation tools on the same text tradition, ideally each being able to make use of former results by other tools and to contribute to the overall result.<br /> <br /> The major disadvantage of encoding collation data this way is its apparant lack of human readability and that it is hardly possible to edit it by hand, especially when the collated text tradition grows larger. This problem can only be solved via tool support.<br /> <br /> === Encoding the interpretation/ representation: Derive an apparatus from the collation ===<br /> <br /> A TEI-encoded critical apparatus is one possible rendition of collation data, possibly enhanced with information yielded from interpreting the alignments. There are a couple of ways how we could encode the above collation as an apparatus.<br /> <br /> ==== Apparatus pointing to the collated tokens (for easier post-processing) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" xml:id="w2_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2"><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" corresp="#w2_1"><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> ==== Apparatus with embedded textual content (for readability) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:id="w2_1">Quickly,</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1">The cat ate the food</rdg><br /> <rdg wit="http://edition.org/witness_2">the cat ate the food.</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" corresp="#w2_1">quickly.</rdg><br /> <rdg wit="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> Some problems here:<br /> <br /> * @corresp vs. <link/> for transpositions over more than two witnesses<br /> * How to derive the segment content from the original witness automatically, if the token content does not add up to it (e. g. because of punctuation being excluded from the tokens from the start)?<br /> <br /> == Bibliography ==<br /> <br /> * O'Donnell, Daniel Paul. [http://etjanst.hb.se/bhs/ith/1-8/dpo.pdf “The Ghost in the Machine: Revisiting an Old Model for the Dynamic Generation of Digital Editions.”] HumanIT 8.1 (2005): 5171.<br /> * Vetter, L. and McDonald, J. ‘Witnessing Dickinson’s Witnesses’, Literary and Linguistic Computing, 18.2: 2003, 151-165.<br /> * [http://eprints.qut.edu.au/38436/ Schmidt, D., 2010. The inadequacy of embedded markup for cultural heritage texts. Literary and Linguistic Computing, 25(3), pp. 337-356.]<br /> <br /> [[Category:SIG:Manuscripts]]<br /> [[Category:Critical Apparatus]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9470 Critical Apparatus Workgroup 2011-05-30T23:53:06Z

<p>Mburghart: /* Representing "verbose" apparatus */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> <br /> Participants to the preliminary workgroup:<br /> <br /> * Marjorie Burghart (MB)<br /> * James Cummings (JC)<br /> * Fotis Jannidis (FJ)<br /> * Gregor Middell (GM)<br /> * Dan O'Donnell (DOD)<br /> * Espen Ore (EO)<br /> * Elena Pierazzo (EP)<br /> * Roberto Rosselli del Turco (RDT)<br /> * Chris Wittern (CW)<br /> <br /> <br /> <br /> == “Critical Apparatus” vs. “Textual Variance” vs. “Textual Variants”== <br /> <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the '''critical apparatus''' is just inherited from the printed world and one of the possible physical embodiment of '''textual variance'''. EP therefore proposes to use this new name, moving from "critical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use '''textual variants''' instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart of the current critical apparatus recommendations. That of encoding an apparatus at the site of textual variance and encoding a structured view of a note entirely separate from the edited version of texts. (In mass digitization of critical editions, for example, one might have an <app> in a set of notes at the bottom of the page which are not encoded at the site of variance, or indeed necessarily connected with it.) It is this striving to both be able to encode all sorts of various legacy forms of apparatus as well as simultaneously catering for those who are recording the structure by which they will generate an apparatus in producing some output. So JC would argue that the first of these are apparatus and the second of these is a site/locus of textual variance.<br /> <br /> == Issues == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === Specific phenomena ===<br /> <br /> ==== Transpositions ====<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions.<br /> <br /> Additionally it is not possible to mark them up explicitly. [http://juxtasoftware.org/ Juxta] for example works around that by storing transposition data in a custom XML format:<br /> <br /> <pre><br /> <moves><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10462" doc2="1881 1st Ed." space2="original" start2="9872" end2="10467" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10483" doc2="1870 2nd Ed." space2="original" start2="7781" end2="8376" /><br /> <move doc1="1855 MS" space1="original" start1="9679" end1="10504" doc2="1870 Proof" space2="original" start2="8458" end2="9056" /><br /> <move doc1="1855 MS" space1="original" start1="9886" end1="10525" doc2="1870 1st Ed." space2="original" start2="8546" end2="9141" /><br /> <move doc1="1870 Proof" space1="original" start1="1640" end1="1850" doc2="1881 1st Ed." space2="original" start2="2961" end2="3070" /><br /> </moves><br /> </pre><br /> <br /> Neither is this TEI-compliant, nor is the offset/range-based addressing (@start1/@start2 and @end1/@end2) proper XML markup. A standardized encoding would be helpful.<br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/fuszgtpnn2ywf6bh<br /> <br /> ==== Handling of punctuation ====<br /> <br /> Seems to be a common problem in textual criticism/ apparatus creation, but lacks guidelines/ encoding examples:<br /> <br /> * http://tei.markmail.org/thread/es6byhxpsbgkrxzo<br /> <br /> ==== Representing omissions in an apparatus ====<br /> <br /> What's the proper way to represent missing lines/ paragraphs/ verses?<br /> <br /> * http://tei.markmail.org/thread/parztmwmlx5mqsof<br /> * http://tei.markmail.org/thread/4sheu6nji3dvnf64<br /> <br /> === Markup-related ===<br /> <br /> ==== Inclusion of structural markup in the apparatus ====<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s.<br /> <br /> Use case: <br /> <br /> <blockquote style="background:#FFEAEA">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> * http://tei.markmail.org/thread/tbzi2yj5xd4dto34<br /> <br /> More use cases from TEI-L:<br /> <br /> * http://tei.markmail.org/thread/jyezaqfycaldtdcv<br /> * http://tei.markmail.org/thread/fbyuxyabbxq4rwbr<br /> * http://tei.markmail.org/thread/vrwkl7kkruulyjzh<br /> * http://tei.markmail.org/thread/x5agpwzn4hiwwwcx<br /> <br /> ==== Encoding variants in structural markup ====<br /> <br /> * http://tei.markmail.org/thread/ap62n37uf6rbfds4<br /> * http://tei.markmail.org/thread/hbmnsn3v4aqjabt3<br /> <br /> ==== Conflicts between individual readings and the semantics of structural markup that surrounds it ====<br /> <br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> === Workflow-related ===<br /> <br /> ==== Scalability ====<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses.<br /> <br /> <blockquote style="background:#FFEAEA"><br /> Scaling is generally a problem with methods of indicating textual variance, but in parallel segmentation this is exacerbated because as the number of witnesses increase, the likelihood of needing to reformulate the reading boundaries, never mind the difficulty in reading or understanding such encodings. This may be a problem not only when looking at a single text with many witnesses, where variation in structure may be extremely difficult to represent where conflicts occur which disrupt this very basic structure (for example, imagine a set of witnesses where some have lines in linegroups, some just lines, some paragraphs, some paragraphs in divisions, but all with the same underlying text). But also where parallel segmentation is being used to record divergent interpretations of these individual witnesses by many editors (for distributed co-operative editions generated from many editorial views of a text). A plausible recommendation is to use a form of stand-off apparatus for such editions rather than parallel segmentation. And while some of the current methods can be used in a stand-off method, they should be updated to reflect current P5 usage of URI-based pointers.<br /> </blockquote><br /> <br /> ==== Refactoring ====<br /> <br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn.<br /> <br /> ==== Complexity ====<br /> <br /> Manually crafting an apparatus is error-prone:<br /> <br /> * http://tei.markmail.org/thread/yuxqotf5aynxznq5<br /> <br /> ==== Feasibility of double-endpoint-attached method ====<br /> <br /> * http://tei.markmail.org/thread/fsj7gvojds4mwcm5<br /> * http://tei.markmail.org/thread/flwcnf4fxm4u7ebj<br /> <br /> === Model vs. Representation ===<br /> <br /> ==== Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note ====<br /> <br /> In a nutshell: depending on the desired output of your digital edition, you may need to show in the apparatus entry a lemma text different from the content of the <lem> or desired <rdg>. This is typically the case for long omissions, when one does not display the full text that is omitted by one or more witnesses, but only the beginning and end of the omitted span of text.<br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">Let's consider again the example used in a previous use case: <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> <br/><br/><br /> You certainly do not want to generate a footnote with these two full paragraphs to tell the reader that one witness omits them, but on the other hand you want to be able to represent the source according to its various witnesses, so location-referenced is not in order. <br /> </blockquote><br /> <br /> ==== Representing "verbose" apparatus ====<br /> <br /> In a nutshell: when you want to represent an apparatus entry written in a rather verbose way (in a print-to-digital edition). The same is true if you want to be able to generate a verbose apparatus note in a "born digital" edition. <br /> <br /> Use cases: <br /> <blockquote style="background:#FFEAEA">You're encoding an existing edition, and want to represent the source it edits, while keeping intact the text / apparatus of the existing edition. Some apparatus entries are easy to represent with the <app> / <lem> / <rdg> elements, some others add editorial comments to the listing of the variants, and are quite difficult to represent. BTW, the same goes when you are encoding a born-digital edition for which you want to be able to generate an alternative print output corresponding to the traditional standards of a collection. <br /> <br/><br/><br /> A - When I have a footnote giving two <i>lectiones</i> from the same manuscrip, one before correction and the other after: <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Text<span class="moz-txt-tag"></span></b>: ad lectorem Venetum (b) .<br /> <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Note<span class="moz-txt-tag"></span></b>: b) <i>ms.</i>, lectionem venerum <i class="moz-txt-slash"><span class="moz-txt-tag"></span>corrigé postérieurement en<span class="moz-txt-tag"></span></i> lectorem Venetum<br /> <br/><br /> <br/><br /> If I encode it like this, with two seprate rdg for the same<br /> witness, each with a different @type (for instance, "anteCorr" and<br /> "postCorr"), it gives an accurate account of the state of the witness, BUT it is an<br /> interpretation of the original note in the critical apparatus, i.e. if<br /> I do this I delete some text added by the original editor. <br><br /> <br /> &lt;app n="b"&gt;<br /> <br><br /> &lt;lem&gt;lectorem Venetum&lt;/lem&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="anteCorr"&gt;lectionem venerum&lt;/rdg&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="postCorr"&gt;lectorem Venetum&lt;/rdg&gt;<br /> <br /> <br><br /> &lt;/app&gt;<br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> Let's consider this other note. There is some text added verbosely within the apparatus note by the editor. <br/><br /> <p class="MsoNormal" style="text-align: justify;"><b style=""><span style="">Text</span></b><span style="">: Hiis diebus civitas<br /> Pergamensis(b) tenebat exersitum</span><br/><br /> <b style=""><span style="">Note</span></b><span style="">: b) se, <i>mis indûment avant</i> tenebat <i>par le ms</i>.</span></p><br /> <br /> <p class="MsoNormal"><span style="">Should I encode it as: <br><br /> ... Pergamensis &lt;app<br /> n="b"&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt;&lt;/rdg&gt;<br><br /> &lt;/app&gt;</span>... <br><br /> </p><br /> <br /> I one represents this note strictly with the <app> / <rdg>, it leads to suppress remarks by the original editor. Adding a note in the rdg to preserve the editor's comments could work here, ut it's not always the case<br/><br /> Like: <br/><br /> <span style="">... Pergamensis &lt;app<br /> n="b"&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt; </span><span style="">&lt;note&gt;&lt;hi<br /> rend="italics"&gt;<span style="">mis<br /> indûment avant</span>&lt;/hi&gt; tenebat.</span><span style="">&lt;/note&gt;&lt;/rdg&gt;<br><br /> <br /> &lt;/app&gt;</span><br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> <p class="MsoNormal" style="text-align: justify;">'''Text'''<span style="">: …reliqui demum meos socios (d)</span><br><br /> '''Note'''<span style="">: d) domum<br /> meam solito, <i>Bal.;</i> dni <i>ou</i> dm, <i>ms.; en note</i> meam solita.</span></p><br /> <br /> Here we have 2 witnesses (Bal. et ms.), the latter with a) an uncertain<br /> lectio ("dni" or "dm") and b) a part of the lectio which is written as<br /> a note ("meam solita"). This is tricky to encode. <br /> </blockquote><br /> <br /> See also:<br /> <br /> * http://tei.markmail.org/thread/ib3bsrpirepp4ibc<br /> * http://tei.markmail.org/thread/diubpw5adw6ntcas<br /> <br /> ==== Representation of suggestions by the editor: ''lege'' ''dele'' etc. ====<br /> <br /> In a nutshell: Sometimes, the editor provides working suggestions through apparatus notes such as ''lege(ndum)'' ("read"), ''dele(ndum)'' ("delete)" etc. They do not belong in the textual variants ''per se'', and are not attached to witnesses, although they do belong in the critical apparatus.<br /> <br /> * http://tei.markmail.org/thread/vfw25psb5vgdiftw<br /> <br /> ==== Collations of differing granularity ====<br /> <br /> * http://tei.markmail.org/thread/bonflsyb2d3ebtp2<br /> * http://tei.markmail.org/thread/gqyymzd4a4xvhch7<br /> <br /> == An encoding proposal from the perspective of computer-aided collation tools == <br /> <br /> Gregor Middell gave an overview of textual variance from a software developer's perspective for the workgroup on a [[Textual_Variance|separate page]]. The models described there are used in tools like [http://collatex.sourceforge.net/ CollateX], [http://www.juxtasoftware.org/ Juxta] and [http://code.google.com/p/multiversiondocs/ nmerge].<br /> <br /> Collecting ideas from the mailinglist by James Cummings, Dan O'Donnell and Marjorie Burghardt as well as following the “Gothenburg model” of textual variance, a first take at separating the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller model from the representation] of textual variance could be structured as follows.<br /> <br /> === Modelling input data: Make the units of a collation addressable in the witnesses ===<br /> <br /> The Gothenburg model assumes a [[Textual_Variance#Tokenizer|preprocessing step]] by which the witnesses get split up into '''tokens''' of desired granularity. This granularity becomes the minimal unit of collation and can defined as pages, paragraphs, verses, lines, words, characters or any other unit that makes sense in the context of a particular tradition under investigation. To model collation results on top of tokenized witnesses, those tokens have to be addressable.<br /> <br /> The TEI defines an [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAXP array of pointing mechanisms], which can be used to address anything from a whole XML document via URIs down to arbitrary content of those documents via sophisticated XPointer schemes. Projects would be free to choose among those mechanisms as long as each token is made available for later reference.<br /> <br /> Examples:<br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_1"><br /> <w>The</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w> <w>quickly</w>.<br /> </p><br /> </pre><br /> <br /> <pre><br /> <p xml:base="http://edition.org/witness_2"><br /> <w>Quickly</w>, <w>the</w> <w>cat</w> <w>ate</w> <w>the</w> <w>food</w>.<br /> </p><br /> </pre><br /> <br /> Here tokens on the word-level could be addressed via the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSXP xpath1() XPointer scheme]:<br /> <br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[1])</nowiki><br /> # <nowiki>http://edition.org/witness_1#xpath1(/p[1]/w[2])</nowiki><br /> # ...<br /> <br /> A less verbose scheme would rely on each container element of a token being identified via a (possibly autogenerated) <code>xml:id</code> attribute, like in the following verse-level tokenization.<br /> <br /> <pre><br /> <lg xml:base="urn:goethe:faust2"><br /> <l xml:id="l_1">Die Sonne sinkt, die letzten Schiffe</l><br /> <l xml:id="l_2">Sie ziehen munter hafenein.</l><br /> <l xml:id="l_3">Ein großer Kahn ist im Begriffe</l><br /> <l xml:id="l_4">Auf dem Canale hier zu sein.</l><br /> </lg><br /> </pre><br /> <br /> # <nowiki>urn:goethe:faust2#l_1</nowiki><br /> # <nowiki>urn:goethe:faust2#l_2</nowiki><br /> # ...<br /> <br /> One can even think of reference schemes, which are as independent of existing markup as possible. By introducing &lt;anchor/> milestone elements at token boundaries and using the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATSRN range() XPointer scheme] the tokenization of arbitrary TEI documents can be accomplished, because &lt;anchor/> is part of [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.global.html model.global].<br /> <br /> === Modelling collated data: Encode the alignment/linking between tokens ===<br /> <br /> After tokens in the different witnesses have been made addressable, collation data can be modelled on top of that as [[Textual_Variance#Aligner|alignments of tokens]]. An '''alignment''' can be expressed as a set of tokens from different witnesses or, in accordance with the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html corresponding guidelines chapter] as a link between two or more tokens.<br /> <br /> Taking the first example from above, a collation of the two given witnesses could be expressed as<br /> <br /> <pre><br /> <linkGrp type="collation" xml:base="http://edition.org/"><br /> <link target="witness_1#xpath1(/p[1]/w[1]) witness_2#xpath1(/p[1]/w[2])" /><br /> <link target="witness_1#xpath1(/p[1]/w[2]) witness_2#xpath1(/p[1]/w[3])" /><br /> <link target="witness_1#xpath1(/p[1]/w[3]) witness_2#xpath1(/p[1]/w[4])" /><br /> <link target="witness_1#xpath1(/p[1]/w[4]) witness_2#xpath1(/p[1]/w[5])" /><br /> <link target="witness_1#xpath1(/p[1]/w[5]) witness_2#xpath1(/p[1]/w[6])" /><br /> <link target="witness_1#xpath1(/p[1]/w[6]) witness_2#xpath1(/p[1]/w[1])" type="transposition" /><br /> </linkGrp><br /> </pre><br /> <br /> Each link in this example corresponds to a row in an alignment table as depicted in the Gothenburg model description. Omitted/ added tokens are expressed implictly by not linking to tokens in other witnesses, this is to say: Whether a set of tokens has been added to a witness or has been omitted from it, is a matter of interpreting collation data as expressed above from the perspective of one witness or another and with regard to the way, this witness aligns with others.<br /> <br /> One advantage of encoding collation data in such a set-oriented way is its '''scalability''':<br /> <br /> # Gradually adding witnesses to the collation may amount to adding alignments to the existing ones or modifying/augmenting the latter, depending on whether the collation is done pairwise (e. g. in relation to a base text) or via multiple alignment (e. g. without a prechosen base).<br /> # Guiding a collation tool in producing ever more precise aligments in consecutive runs can be achieved by [[Textual_Variance#Analyzer|declaring alignments]] (for example transpositions), feeding those into the collator, adjusting the resulting alignment set, feeding it back into the collator for another run and so forth. Being able to encode the initial/preliminary results of such an iterative process in a standardized way, makes it possible to run different collation tools on the same text tradition, ideally each being able to make use of former results by other tools and to contribute to the overall result.<br /> <br /> The major disadvantage of encoding collation data this way is its apparant lack of human readability and that it is hardly possible to edit it by hand, especially when the collated text tradition grows larger. This problem can only be solved via tool support.<br /> <br /> === Encoding the interpretation/ representation: Derive an apparatus from the collation ===<br /> <br /> A TEI-encoded critical apparatus is one possible rendition of collation data, possibly enhanced with information yielded from interpreting the alignments. There are a couple of ways how we could encode the above collation as an apparatus.<br /> <br /> ==== Apparatus pointing to the collated tokens (for easier post-processing) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" xml:id="w2_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1"><br /> <ptr target="#xpath1(/p[1]/w[1])" /><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2"><br /> <ptr target="#xpath1(/p[1]/w[2])" /><br /> <ptr target="#xpath1(/p[1]/w[3])" /><br /> <ptr target="#xpath1(/p[1]/w[4])" /><br /> <ptr target="#xpath1(/p[1]/w[5])" /><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" xml:base="http://edition.org/witness_1" corresp="#w2_1"><br /> <ptr target="#xpath1(/p[1]/w[6])" /><br /> </rdg><br /> <rdg wit="http://edition.org/witness_2" xml:base="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> ==== Apparatus with embedded textual content (for readability) ====<br /> <br /> <pre><br /> <app><br /> <rdg wit="http://edition.org/witness_1" /><br /> <rdg wit="http://edition.org/witness_2" xml:id="w2_1">Quickly,</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1">The cat ate the food</rdg><br /> <rdg wit="http://edition.org/witness_2">the cat ate the food.</rdg><br /> </app><br /> <app><br /> <rdg wit="http://edition.org/witness_1" corresp="#w2_1">quickly.</rdg><br /> <rdg wit="http://edition.org/witness_2" /><br /> </app><br /> </pre><br /> <br /> Some problems here:<br /> <br /> * @corresp vs. <link/> for transpositions over more than two witnesses<br /> * How to derive the segment content from the original witness automatically, if the token content does not add up to it (e. g. because of punctuation being excluded from the tokens from the start)?<br /> <br /> == Bibliography ==<br /> <br /> * O'Donnell, Daniel Paul. [http://etjanst.hb.se/bhs/ith/1-8/dpo.pdf “The Ghost in the Machine: Revisiting an Old Model for the Dynamic Generation of Digital Editions.”] HumanIT 8.1 (2005): 5171.<br /> * Vetter, L. and McDonald, J. ‘Witnessing Dickinson’s Witnesses’, Literary and Linguistic Computing, 18.2: 2003, 151-165.<br /> * [http://eprints.qut.edu.au/38436/ Schmidt, D., 2010. The inadequacy of embedded markup for cultural heritage texts. Literary and Linguistic Computing, 25(3), pp. 337-356.]<br /> <br /> [[Category:SIG:Manuscripts]]<br /> [[Category:Critical Apparatus]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=SIG:MSS&diff=9467 SIG:MSS 2011-05-30T17:05:56Z

<p>Mburghart: /* Manuscript Transcription */</p> <hr /> <div>== TEI Special Interest Group on Manuscripts (TEI MS SIG) ==<br /> <br /> === Agenda of this SIG ===<br /> *revision of the chapter on critical apparatus<br /> ** see working group on [[Critical_Apparatus_Workgroup|Critical Apparatus]]/ [[Textual Variance]]<br /> *revision of the chapter on manuscript description<br /> **see working group on [[msDesc enhancement|MSS Description]]<br /> *drafting a chapter (or section) on markup of genetic editions<br /> **see working group on [[Genetic Editions]]<br /> <br /> === News ===<br /> <br /> * [[SIGMS_Minutes_20101112|Minutes SIG meeting, Zadar 12 November 2010]]<br /> * [[SIGMS_Minutes_20091114|Minutes SIG meeting, Ann Arbor 14 November 2009]]<br /> * [[SIGMS_Agenda_20081108|Agenda SIG meeting, London 8 November 2008]]<br /> <br /> === Introduction ===<br /> <br /> The goal of the TEI Special Interest Group on Manuscripts is to bring together users of the TEI who wish to improve the encoding strategies for marking up transcriptions and editions of manuscript materials.<br /> <br /> This SIG will explore a range of issues common to editing manuscripts, including: <br /> # how to handle time based encoding<br /> # how to record place based encoding<br /> # how to encode fragments<br /> # how to record codicology (the substance of the medium, ink stints, etc); Robinson noted that the TEI already has mechanisms to record this, but it needs to be better documented<br /> # issues of substitutions<br /> # issues of variation<br /> # to clarify the role of using the critical apparatus tagset in manuscript transcription (which is dependent on whether one is encoding an edition or encoding a manuscript transcription)<br /> <br /> It will do this by: <br /> * running a mailing list on this topic<br /> * assess the TEI and suggest improvements/alterations to the TEI-Council<br /> <br /> The SIG is currently convened by Elena Pierazzo who also manages the TEI-MS-SIG List, Amanda Gailey, and Malte Rehbein. It was originally setup by Elena Pierazzo, Susan Schreibman, and Edward Vanhoutte.<br /> <br /> The SIG runs a mailing list on this topic. To join visit http://listserv.brown.edu/tei-ms-sig.html<br /> <br /> === Activities ===<br /> <br /> The SIG met at the Third Annual TEI Members' Meeting in Nancy, France on 08 November 2003. The report can be found [http://www.tei-c.org.uk/Activities/SIG/Manuscript/mssigr01.html here].<br /> <br /> The second meeting of the SIG was held at the Fourth Annual TEI Members' Meeting at Johns Hopkins University, Baltimore, USA, 23 October 2004. The report can be found [http://www.tei-c.org.uk/Activities/SIG/Manuscript/mssigr02.html here].<br /> <br /> The third meeting of the SIG was held at Seventh Annual TEI Member's Meeting at University of Maryland, College Park, 3nd of November 2007. The agenda of the meeting can be found [[MS SIG Agenda 2007|here]]; the report can be found [[MS SIG Report 07|here]]. During the meeting several task forces were created to deal with specific problems: the task forces main page can be found [[MS task forces|here]].<br /> <br /> === Useful links ===<br /> <br /> ==== Manuscript Description ====<br /> <br /> Projects, resources, guidelines concerning MS description.<br /> <br /> * [http://www.tei-c.org/release/doc/tei-p5-doc/html/MS.html TEI P5: 13. Manuscript Description]<br /> * [http://enrich.manuscriptorium.com ENRICH project] - standardising and aggregating medieval manuscript descriptions. See also [http://tei.oucs.ox.ac.uk/ENRICH/ OUCS ENRICH Website] containing ENRICH Schemas, ODD, Documentation and Training Materials.<br /> * [http://sunsite3.berkeley.edu/Scriptorium/ Digital Scriptorium] (see especially the [http://sunsite3.berkeley.edu/Scriptorium/technical/description_dtd.html DESCRIPTION DTD] page).<br /> * [http://www.hab.de/forschung/projekte/master-e.htm MASTER - Interface format for the description of medieval manuscripts]<br /> * [http://www.tei-c.org/Activities/MS/msw05.xml Reviews of the manuscript description chapter: A summary]<br /> <br /> ==== Manuscript Transcription ====<br /> <br /> Projects, resources, guidelines concerning MS transcription.<br /> <br /> * [http://www.cdlib.org/inside/diglib/stwg/ms/ CDL Encoding Guidelines for Manuscripts and Rare Books]<br /> * [http://www.kantl.be/ctb/project/dalf/ DALF: Digital Archive of Letters in Flanders]<br /> * [http://www.scriptorium.columbia.edu/ Digital Scriptorium] (see especially the [https://www1.columbia.edu/sec/cu/libraries/bts/digital_scriptorium/technical/ds-xml/transcription_dtd/index.html TRANSCRIPTION DTD] and [https://www1.columbia.edu/sec/cu/libraries/bts/digital_scriptorium/technical/ds-xml/description_dtd/index.html DESCRIPTION DTD] pages).<br /> * [[EpiDoc]], guidelines for transcribing ancient texts<br /> * [http://skaldic.arts.usyd.edu.au/docs/guidelines/guide.html Guidelines for the electronic edition of the skaldic corpus]<br /> * [http://web.uvic.ca/hrd/lydgate/pilot.htm Partial Transcription of John Lydgate's "Fall of Princes"]<br /> * [http://webapp1.dlib.indiana.edu/newton/index.jsp The Chymistry of Isaac Newton]<br /> * [http://gandalf.aksis.uib.no/menota/guidelines/ The Menota handbook]<br /> * [http://www.newtonproject.ic.ac.uk/prism.php?id=1 The Newton Project] (see also [http://ahds.ac.uk/creating/case-studies/newton/index.htm The Newton Project: Implementing and Exploiting XML]).<br /> * [http://www.whitmanarchive.org/guidelines/ The Walt Whitman Archive Encoding Guidelines for Poetry Manuscripts]<br /> * [http://jefferson.village.virginia.edu/seenet/piers/protocoltran.html Transcriptional Protocols: Piers Plowman Electronic Archive and SEENET]<br /> * [http://elec.enc.sorbonne.fr/chroniqueslatines/ Chroniques latines de Saint-Denis] : critical edition using TEI P4 (but we hope to migrate in P5 this year) : [http://elec.enc.sorbonne.fr/chroniqueslatines/xml/chroniquesstdenis.xml XML Files]<br /> * [http://lemo.irht.cnrs.fr/43/43-12.htm Réflexions sur l'utilisation de la TEI pour encoder les sources diplomatiques] and [http://elec.enc.sorbonne.fr/cartulaireblanc/guidebalisage/ Guide du balisage du Cartulaire blanc] : two resources in French<br /> * [http://ccfm.ens-lsh.fr/IMG/pdf/BFM-Mss_Encodage-XML.pdf Base de Français Médiéval - MSS Encoding Guidelines (in French)]<br /> * [http://marjorie.burghart.online.fr/?q=en/content/tei-critical-apparatus-cheatsheet TEI: Critical Apparatus Cheatsheet]<br /> <br /> [[Category:SIG|MSS]]<br /> [[Category:SIG:Manuscripts]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Publishing_printed_critical_editions_from_TEI&diff=9380 Publishing printed critical editions from TEI 2011-05-04T15:30:39Z

<p>Mburghart: /* TEI to InDesign */</p> <hr /> <div>Publishing printed critical editions from TEI encoded files is possible, but requires the use of third-party tools and some specific knowledge. This page aims at providing information on the various ways of producing a camera-ready file, including the usual features of critical editions, i.e. multiple layers of footnotes, and optionally footnotes referencing the line numbers in the text, instead of footnote calls, etc. <br /> <br /> This transformation could be most easily done with XSL FO, but it is unclear whether FO supports the more elaborate options needed in a complex critical edition, like the multiple layers of footnotes or the references to line numbers. Any precision or experience on this welcome. For features unsupported by FO, the recommended solution is to convert the TEI to another format, which allows the publication as wanted. <br /> <br /> <br /> <br /> == TEI to InDesign ==<br /> <br /> http://www.unc.edu/~reedkm/files/TEIPublishingWorkflow_KR.pdf<br /> <br /> InDesign does not support roundtripping (conversing back to XML TEI)<br /> <br /> See also: http://wiki.tei-c.org/index.php/Publishing_printed_critical_editions_from_TEI<br /> <br /> == TEI to PDF / PS ==<br /> <br /> === using LaTeX ===<br /> There are [http://www.tei-c.org/release/doc/tei-xsl-common/profiles/default/latex/to.html TEI to LaTeX stylesheets], with the expectation of processing using XeLaTeX, and they come with a command-line script "teitolatex" for Unix/Linux. But there's a lot more to do there to get the right output.<br /> <br /> [http://www.ucl.ac.uk/~ucgadkw/edmac/ EDMAC] is a TeX/LaTEX library which can be used for this precise purpose. Maybe one can think of using: TEI > XSLT > LaTeX/EDMAC > PDF<br /> <br /> Checking this page [http://www.djdekker.net/ledmac/ ''Typesetting Critical Editions with LaTeX''], about ledmac, will provide useful information. <br /> <br /> <br /> Example of a printed version of a volume of the Leibniz-Edition (Reihe 8), produced with LaTeX, which can be found as a pdf here: http://nbn-resolving.de/urn:nbn:de:kobv:b4-opus-11675 <br /> Some differences between TUSTEP and LaTeX by comparing the two printed Leibniz volumes:<br /> * TUSTEP can count the lines as well in normal footnotes (margins), whereas LaTeX/ledmac cannot (or at least we haven't found a way to do so).<br /> * LaTeX has advantages with the math mode, which was extremely helpful in editing the mathematical texts of Leibniz.<br /> <br /> <br /> === using TUSTEP ===<br /> <br /> Advantage: does the job<br /> <br /> Drawback: very difficult to learn<br /> <br /> The powerful typesetting routines support up to 9 critical apparatuses, layers of footnotes, endnotes, marginal notes, synopses (with individual apparatuses), special characters and character sets etc. A further benefit is that programming and typesetting interact very smoothly and in various directions. Thus, you can enrich the original XML-Markup with page or line references of the printed result automatically, which is useful when electronic and printed editions are supposed to accompany each other. TEI data (as all XML data) can be imported easily into TUSTEP. It treats XML data string based but not as node tree, which might be an advantage and a disadvantage as well. The output is PS or PDF. Therefore TEI > XSLT (to prepare encoding for TUSTEP with XML technologies) > TUSTEP > PDF or TEI <> TUSTEP > PDF are possible workflows respectively. Once the typesetting routine is set up for a specific edition it can be plugged as black box into XML-environments (e.g. Oxygen) to "typeset-on-demand" during XML-encoding.<br /> The shortcomings: Learning TUSTEP is not a walk in the park and there are no prepackaged solutions or patterns or cookbooks. A scholar with no or minor technical background will need support to get things work.<br /> For more information in English see http://www.tustep.uni-tuebingen.de/tustep_eng.html, which covers a list of scholarly edition made with use of TUSTEP. <br /> For editions produced with TUSTEP have a look at http://www.uni-muenster.de/Leibniz/bd_1_1_2009.html or http://www.albertus-magnus-institut.de/MeteoraSpecimen.pdf for example.<br /> <br /> With TUSTEP roundtripping is no problem. Sometimes one just wants to have the information about page- and linebreaks within your outgoing XML, in order to show that information later in an online representation or use it while comparing the output with further witnesses. Then how do you do that? Here you need a system that can give you a XML-output with just that information.<br /> <br /> Just besides, TUSTEP is much more than a publishing system. Within the scope of a critical edition you usually need to enrich data in various forms, compare witnesses, automatically generate apparatuses and indexes etc. TUSTEP even comprises a very powerful scripting language of it's own, Tuscript.<br /> <br /> === using XEP ===<br /> <br /> Advantage: very good<br /> <br /> Drawback: expensive<br /> <br /> http://www.renderx.com/tools/xep.html<br /> <br /> TEI -> XSLT -> XSL:FO -> XEP -> PDF<br /> <br /> Nota: FOP http://xmlgraphics.apache.org/fop/ can be a free alternative, depending on your needs (it does not implement all XSL FO)</div>

Mburghart https://wiki.tei-c.org/index.php?title=Publishing_printed_critical_editions_from_TEI&diff=9376 Publishing printed critical editions from TEI 2011-05-04T12:55:13Z

<p>Mburghart: /* using TUSTEP */</p> <hr /> <div>Publishing printed critical editions from TEI encoded files is possible, but requires the use of third-party tools and some specific knowledge. This page aims at providing information on the various ways of producing a camera-ready file, including the usual features of critical editions, i.e. multiple layers of footnotes, and optionally footnotes referencing the line numbers in the text, instead of footnote calls, etc. <br /> <br /> This transformation could be most easily done with XSL FO, but it is unclear whether FO supports the more elaborate options needed in a complex critical edition, like the multiple layers of footnotes or the references to line numbers. Any precision or experience on this welcome. For features unsupported by FO, the recommended solution is to convert the TEI to another format, which allows the publication as wanted. <br /> <br /> <br /> <br /> == TEI to InDesign ==<br /> <br /> http://www.unc.edu/~reedkm/files/TEIPublishingWorkflow_KR.pdf<br /> <br /> InDesign does not support roundtripping (conversing back to XML TEI)<br /> <br /> <br /> == TEI to PDF / PS ==<br /> <br /> === using LaTeX ===<br /> There are [http://www.tei-c.org/release/doc/tei-xsl-common/profiles/default/latex/to.html TEI to LaTeX stylesheets], with the expectation of processing using XeLaTeX, and they come with a command-line script "teitolatex" for Unix/Linux. But there's a lot more to do there to get the right output.<br /> <br /> [http://www.ucl.ac.uk/~ucgadkw/edmac/ EDMAC] is a TeX/LaTEX library which can be used for this precise purpose. Maybe one can think of using: TEI > XSLT > LaTeX/EDMAC > PDF<br /> <br /> Checking this page [http://www.djdekker.net/ledmac/ ''Typesetting Critical Editions with LaTeX''], about ledmac, will provide useful information. <br /> <br /> <br /> Example of a printed version of a volume of the Leibniz-Edition (Reihe 8), produced with LaTeX, which can be found as a pdf here: http://nbn-resolving.de/urn:nbn:de:kobv:b4-opus-11675 <br /> Some differences between TUSTEP and LaTeX by comparing the two printed Leibniz volumes:<br /> * TUSTEP can count the lines as well in normal footnotes (margins), whereas LaTeX/ledmac cannot (or at least we haven't found a way to do so).<br /> * LaTeX has advantages with the math mode, which was extremely helpful in editing the mathematical texts of Leibniz.<br /> <br /> <br /> === using TUSTEP ===<br /> <br /> Advantage: does the job<br /> <br /> Drawback: very difficult to learn<br /> <br /> The powerful typesetting routines support up to 9 critical apparatuses, layers of footnotes, endnotes, marginal notes, synopses (with individual apparatuses), special characters and character sets etc. A further benefit is that programming and typesetting interact very smoothly and in various directions. Thus, you can enrich the original XML-Markup with page or line references of the printed result automatically, which is useful when electronic and printed editions are supposed to accompany each other. TEI data (as all XML data) can be imported easily into TUSTEP. It treats XML data string based but not as node tree, which might be an advantage and a disadvantage as well. The output is PS or PDF. Therefore TEI > XSLT (to prepare encoding for TUSTEP with XML technologies) > TUSTEP > PDF or TEI <> TUSTEP > PDF are possible workflows respectively. Once the typesetting routine is set up for a specific edition it can be plugged as black box into XML-environments (e.g. Oxygen) to "typeset-on-demand" during XML-encoding.<br /> The shortcomings: Learning TUSTEP is not a walk in the park and there are no prepackaged solutions or patterns or cookbooks. A scholar with no or minor technical background will need support to get things work.<br /> For more information in English see http://www.tustep.uni-tuebingen.de/tustep_eng.html, which covers a list of scholarly edition made with use of TUSTEP. <br /> For editions produced with TUSTEP have a look at http://www.uni-muenster.de/Leibniz/bd_1_1_2009.html or http://www.albertus-magnus-institut.de/MeteoraSpecimen.pdf for example.<br /> <br /> With TUSTEP roundtripping is no problem. Sometimes one just wants to have the information about page- and linebreaks within your outgoing XML, in order to show that information later in an online representation or use it while comparing the output with further witnesses. Then how do you do that? Here you need a system that can give you a XML-output with just that information.<br /> <br /> Just besides, TUSTEP is much more than a publishing system. Within the scope of a critical edition you usually need to enrich data in various forms, compare witnesses, automatically generate apparatuses and indexes etc. TUSTEP even comprises a very powerful scripting language of it's own, Tuscript.<br /> <br /> === using XEP ===<br /> <br /> Advantage: very good<br /> <br /> Drawback: expensive<br /> <br /> http://www.renderx.com/tools/xep.html<br /> <br /> TEI -> XSLT -> XSL:FO -> XEP -> PDF<br /> <br /> Nota: FOP http://xmlgraphics.apache.org/fop/ can be a free alternative, depending on your needs (it does not implement all XSL FO)</div>

Mburghart https://wiki.tei-c.org/index.php?title=Publishing_printed_critical_editions_from_TEI&diff=9375 Publishing printed critical editions from TEI 2011-05-04T12:53:46Z

<p>Mburghart: New page: Publishing printed critical editions from TEI encoded files is possible, but requires the use of third-party tools and some specific knowledge. This page aims at providing information on t...</p> <hr /> <div>Publishing printed critical editions from TEI encoded files is possible, but requires the use of third-party tools and some specific knowledge. This page aims at providing information on the various ways of producing a camera-ready file, including the usual features of critical editions, i.e. multiple layers of footnotes, and optionally footnotes referencing the line numbers in the text, instead of footnote calls, etc. <br /> <br /> This transformation could be most easily done with XSL FO, but it is unclear whether FO supports the more elaborate options needed in a complex critical edition, like the multiple layers of footnotes or the references to line numbers. Any precision or experience on this welcome. For features unsupported by FO, the recommended solution is to convert the TEI to another format, which allows the publication as wanted. <br /> <br /> <br /> <br /> == TEI to InDesign ==<br /> <br /> http://www.unc.edu/~reedkm/files/TEIPublishingWorkflow_KR.pdf<br /> <br /> InDesign does not support roundtripping (conversing back to XML TEI)<br /> <br /> <br /> == TEI to PDF / PS ==<br /> <br /> === using LaTeX ===<br /> There are [http://www.tei-c.org/release/doc/tei-xsl-common/profiles/default/latex/to.html TEI to LaTeX stylesheets], with the expectation of processing using XeLaTeX, and they come with a command-line script "teitolatex" for Unix/Linux. But there's a lot more to do there to get the right output.<br /> <br /> [http://www.ucl.ac.uk/~ucgadkw/edmac/ EDMAC] is a TeX/LaTEX library which can be used for this precise purpose. Maybe one can think of using: TEI > XSLT > LaTeX/EDMAC > PDF<br /> <br /> Checking this page [http://www.djdekker.net/ledmac/ ''Typesetting Critical Editions with LaTeX''], about ledmac, will provide useful information. <br /> <br /> <br /> Example of a printed version of a volume of the Leibniz-Edition (Reihe 8), produced with LaTeX, which can be found as a pdf here: http://nbn-resolving.de/urn:nbn:de:kobv:b4-opus-11675 <br /> Some differences between TUSTEP and LaTeX by comparing the two printed Leibniz volumes:<br /> * TUSTEP can count the lines as well in normal footnotes (margins), whereas LaTeX/ledmac cannot (or at least we haven't found a way to do so).<br /> * LaTeX has advantages with the math mode, which was extremely helpful in editing the mathematical texts of Leibniz.<br /> <br /> <br /> === using TUSTEP ===<br /> <br /> Advantage: does the job<br /> <br /> Drawback: very difficult to learn<br /> <br /> The powerful typesetting routines support up to 9 critical apparatuses, layers of footnotes, endnotes, marginal notes, synopses (with individual apparatuses), special characters and character sets etc. A further benefit is that programming and typesetting interact very smoothly and in various directions. Thus, you can enrich the original XML-Markup with page or line references of the printed result automatically, which is useful when electronic and printed editions are supposed to accompany each other. TEI data (as all XML data) can be imported easily into TUSTEP. It treats XML data string based but not as node tree, which might be an advantage and a disadvantage as well. The output is PS or PDF. Therefore TEI > XSLT (to prepare encoding for TUSTEP with XML technologies) > TUSTEP > PDF or TEI <> TUSTEP > PDF are possible workflows respectively. Once the typesetting routine is set up for a specific edition it can be plugged as black box into XML-environments (e.g. Oxygen) to "typeset-on-demand" during XML-encoding.<br /> The shortcomings: Learning TUSTEP is not a walk in the park and there are no prepackaged solutions or patterns or cookbooks. A scholar with no or minor technical background will need support to get things work.<br /> For more information in English see http://www.tustep.uni-tuebingen.de/tustep_eng.html, which covers a list of scholarly edition made with use of TUSTEP. <br /> For editions produced with TUSTEP have a look at http://www.uni-muenster.de/Leibniz/bd_1_1_2009.html or http://www.albertus-magnus-institut.de/MeteoraSpecimen.pdf for example.<br /> <br /> <br /> === using XEP ===<br /> <br /> Advantage: very good<br /> <br /> Drawback: expensive<br /> <br /> http://www.renderx.com/tools/xep.html<br /> <br /> TEI -> XSLT -> XSL:FO -> XEP -> PDF<br /> <br /> Nota: FOP http://xmlgraphics.apache.org/fop/ can be a free alternative, depending on your needs (it does not implement all XSL FO)</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9024 Critical Apparatus Workgroup 2011-03-22T23:22:45Z

<p>Mburghart: /* Representing "verbose" apparatus */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middell (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middell summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> === Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note ===<br /> <br /> In a nutshell: depending on the desired output of your digital edition, you may need to show in the apparatus entry a lemma text different from the content of the <lem> or desired <rdg>. This is typically the case for long omissions, when one does not display the full text that is omitted by one or more witnesses, but only the beginning and end of the omitted span of text.<br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">Let's consider again the example used in a previous use case: <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> <br/><br/><br /> You certainly do not want to generate a footnote with these two full paragraphs to tell the reader that one witness omits them, but on the other hand you want to be able to represent the source according to its various witnesses, so location-referenced is not in order. <br /> </blockquote><br /> <br /> === Representing "verbose" apparatus ===<br /> In a nutshell: when ou want to represent an apparatus entry written in a rather verbose way (in a print-to-digital edition). The same is true if you want to be able to generate a verbose apparatus note in a "born digital" edition. <br /> <br /> Use cases: <br /> <blockquote style="background:#FFEAEA">You're encoding an existing edition, and want to represent the source it edits, while keeping intact the text / apparatus of the existing edition. Some apparatus entries are easy to represent with the <app> / <lem> / <rdg> elements, some others add editorial comments to the listing of the variants, and are quite difficult to represent. BTW, the same goes when you are encoding a born-digital edition for which you want to be able to generate an alternative print output corresponding to the traditional standards of a collection. <br /> <br/><br/><br /> A - When I have a footnote giving two <i>lectiones</i> from the same manuscrip, one before correction and the other after: <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Text<span class="moz-txt-tag"></span></b>: ad lectorem Venetum (b) .<br /> <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Note<span class="moz-txt-tag"></span></b>: b) <i>ms.</i>, lectionem venerum <i class="moz-txt-slash"><span class="moz-txt-tag"></span>corrigé postérieurement en<span class="moz-txt-tag"></span></i> lectorem Venetum<br /> <br/><br /> <br/><br /> If I encode it like this, with two seprate rdg for the same<br /> witness, each with a different @type (for instance, "anteCorr" and<br /> "postCorr"), it gives an accurate account of the state of the witness, BUT it is an<br /> interpretation of the original note in the critical apparatus, i.e. if<br /> I do this I delete some text added by the original editor. <br><br /> <br /> &lt;app n="b"&gt;<br /> <br><br /> &lt;lem&gt;lectorem Venetum&lt;/lem&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="anteCorr"&gt;lectionem venerum&lt;/rdg&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="postCorr"&gt;lectorem Venetum&lt;/rdg&gt;<br /> <br /> <br><br /> &lt;/app&gt;<br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> Let's consider this other note. There is some text added verbosely within the apparatus note by the editor. <br/><br /> <p class="MsoNormal" style="text-align: justify;"><b style=""><span style="">Text</span></b><span style="">: Hiis diebus civitas<br /> Pergamensis(b) tenebat exersitum</span><br/><br /> <b style=""><span style="">Note</span></b><span style="">: b) se, <i>mis indûment avant</i> tenebat <i>par le ms</i>.</span></p><br /> <br /> <p class="MsoNormal"><span style="">Should I encode it as: <br><br /> ... Pergamensis &lt;app<br /> n="b"&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt;&lt;/rdg&gt;<br><br /> &lt;/app&gt;</span>... <br><br /> </p><br /> <br /> I one represents this note strictly with the <app> / <rdg>, it leads to suppress remarks by the original editor. Adding a note in the rdg to preserve the editor's comments could work here, ut it's not always the case<br/><br /> Like: <br/><br /> <span style="">... Pergamensis &lt;app<br /> n="b"&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt; </span><span style="">&lt;note&gt;&lt;hi<br /> rend="italics"&gt;<span style="">mis<br /> indûment avant</span>&lt;/hi&gt; tenebat.</span><span style="">&lt;/note&gt;&lt;/rdg&gt;<br><br /> <br /> &lt;/app&gt;</span><br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> <p class="MsoNormal" style="text-align: justify;">'''Text'''<span style="">: …reliqui demum meos socios (d)</span><br><br /> '''Note'''<span style="">: d) domum<br /> meam solito, <i>Bal.;</i> dni <i>ou</i> dm, <i>ms.; en note</i> meam solita.</span></p><br /> <br /> Here we have 2 witnesses (Bal. et ms.), the latter with a) an uncertain<br /> lectio ("dni" or "dm") and b) a part of the lectio which is written as<br /> a note ("meam solita"). This is tricky to encode. <br /> </blockquote><br /> <br /> === Representation of suggestions by the editor: ''lege'' ''dele'' etc. ===<br /> <br /> In a nutshell: Sometimes, the editor provides working suggestions through apparatus notes such as ''lege(ndum)'' ("read"), ''dele(ndum)'' ("delete)" etc. They do not belong in the textual variants ''per se'', and are not attached to witnesses, although they do belong in the critical apparatus. <br /> <br /> == Bibliography ==<br /> <br /> * O'Donnell, Daniel Paul. [http://etjanst.hb.se/bhs/ith/1-8/dpo.pdf “The Ghost in the Machine: Revisiting an Old Model for the Dynamic Generation of Digital Editions.”] HumanIT 8.1 (2005): 5171.<br /> [[Category:SIG:Manuscripts]]<br /> * Vetter, L. and McDonald, J. ‘Witnessing Dickinson’s Witnesses’, Literary and Linguistic Computing, 18.2: 2003, 151-165.<br /> * [http://eprints.qut.edu.au/38436/ Schmidt, D., 2010. The inadequacy of embedded markup for cultural heritage texts. Literary and Linguistic Computing, 25(3), pp. 337-356.]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9015 Critical Apparatus Workgroup 2011-03-21T20:05:38Z

<p>Mburghart: /* Issues with the current Critical Apparatus chapter/module */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middell (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middell summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> === Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note ===<br /> <br /> In a nutshell: depending on the desired output of your digital edition, you may need to show in the apparatus entry a lemma text different from the content of the <lem> or desired <rdg>. This is typically the case for long omissions, when one does not display the full text that is omitted by one or more witnesses, but only the beginning and end of the omitted span of text.<br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">Let's consider again the example used in a previous use case: <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> <br/><br/><br /> You certainly do not want to generate a footnote with these two full paragraphs to tell the reader that one witness omits them, but on the other hand you want to be able to represent the source according to its various witnesses, so location-referenced is not in order. <br /> </blockquote><br /> <br /> === Representing "verbose" apparatus ===<br /> In a nutshell: when ou want to represent an apparatus entry written in a rather verbose way (in a print-to-digital edition). The same is true if you want to be able to generate a verbose apparatus note in a "born digital" edition. <br /> <br /> Use cases: <br /> <blockquote style="background:#FFEAEA">You're encoding an existing edition, and want to represent the source it edits, while keeping intact the text / apparatus of the existing edition. Some apparatus entries are easy to represent with the <app> / <lem> / <rdg> elements, some others add editorial comments to the listing of the variants, and are quite difficult to represent. BTW, the same goes when you are encoding a born-digital edition for which you want to be able to generate an alternative print output corresponding to the traditional standards of a collection. <br /> <br/><br/><br /> A - When I have a footnote giving two <i>lectiones</i> from the same manuscrip, one before correction and the other after: <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Text<span class="moz-txt-tag"></span></b>: ad lectorem Venetum (b) .<br /> <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Note<span class="moz-txt-tag"></span></b>: b) <i>ms.</i>, lectionem venerum <i class="moz-txt-slash"><span class="moz-txt-tag"></span>corrigé postérieurement en<span class="moz-txt-tag"></span></i> lectorem Venetum<br /> <br/><br /> <br/><br /> If I encode it like this, with two seprate rdg for the same<br /> witness, each with a different @type (for instance, "anteCorr" and<br /> "postCorr"), it gives an accurate account of the state of the witness, BUT it is an<br /> interpretation of the original note in the critical apparatus, i.e. if<br /> I do this I delete some text added by the original editor. <br><br /> <br /> &lt;app n="b"&gt;<br /> <br><br /> &lt;lem&gt;lectorem Venetum&lt;/lem&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="anteCorr"&gt;lectionem venerum&lt;/rdg&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="postCorr"&gt;lectorem Venetum&lt;/rdg&gt;<br /> <br /> <br><br /> &lt;/app&gt;<br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> Let's consider this other note. There is some text added verbosely within the apparatus note by the editor. <br/><br /> <p class="MsoNormal" style="text-align: justify;"><b style=""><span style="">Text</span></b><span style="">: Hiis diebus civitas<br /> Pergamensis(b) tenebat exersitum</span><br/><br /> <b style=""><span style="">Note</span></b><span style="">: b) se, <i>mis indûment avant</i> tenebat <i>par le ms</i>.</span></p><br /> <br /> <p class="MsoNormal"><span style="">Should I encode it as: <br><br /> ... Pergamensis &lt;app<br /> n="b"&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt;&lt;/rdg&gt;<br><br /> &lt;/app&gt;</span>... <br><br /> </p><br /> <br /> I one represents this note strictly with the <app> / <rdg>, it leads to suppress remarks by the original editor. Adding a note in the rdg to preserve the editor's comments could work here, ut it's not always the case<br/><br /> Like: <br/><br /> <span style="">... Pergamensis &lt;app<br /> n="b"&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt; </span><span style="">&lt;note&gt;&lt;hi<br /> rend="italics"&gt;<span style="">mis<br /> indûment avant</span>&lt;/hi&gt; tenebat.</span><span style="">&lt;/note&gt;&lt;/rdg&gt;<br><br /> <br /> &lt;/app&gt;</span><br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> <p class="MsoNormal" style="text-align: justify;">'''Text'''<span style="">: …reliqui demum meos socios (d)<o:p></o:p></span><br><br /> '''Note'''<span style="">: d) domum<br /> meam solito, <i>Bal.;</i> dni <i>ou</i> dm, <i>ms.; en note</i> meam solita.</span></p><br /> <br /> Here we have 2 witnesses (Bal. et ms.), the latter with a) an uncertain<br /> lectio ("dni" or "dm") and b) a part of the lectio which is written as<br /> a note ("meam solita"). This is tricky to encode. <br /> </blockquote><br /> <br /> <br /> === Representation of suggestions by the editor: ''lege'' ''dele'' etc. ===<br /> <br /> In a nutshell: Sometimes, the editor provides working suggestions through apparatus notes such as ''lege(ndum)'' ("read"), ''dele(ndum)'' ("delete)" etc. They do not belong in the textual variants ''per se'', and are not attached to witnesses, although they do belong in the critical apparatus. <br /> <br /> [[Category:SIG:Manuscripts]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=User:Mburghart&diff=9014 User:Mburghart 2011-03-21T18:17:10Z

<p>Mburghart: New page: Marjorie Burghart [http://www.ehess.fr Ecole des Hautes Etudes en Sciences Sociales (EHESS)], France</p> <hr /> <div>Marjorie Burghart<br /> <br /> [http://www.ehess.fr Ecole des Hautes Etudes en Sciences Sociales (EHESS)], France</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9013 Critical Apparatus Workgroup 2011-03-21T17:24:43Z

<p>Mburghart: /* Issues with the current Critical Apparatus chapter/module */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middell (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middell summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> === Showing a lemma different from the content of the <lem> or chosen reading in an apparatus note ===<br /> <br /> In a nutshell: depending on the desired output of your digital edition, you may need to show in the apparatus entry a lemma text different from the content of the <lem> or desired <rdg>. This is typically the case for long omissions, when one does not display the full text that is omitted by one or more witnesses, but only the beginning and end of the omitted span of text.<br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">Let's consider again the example used in a previous use case: <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> <br/><br/><br /> You certainly do not want to generate a footnote with these two full paragraphs to tell the reader that one witness omits them, but on the other hand you want to be able to represent the source according to its various witnesses, so location-referenced is not in order. <br /> </blockquote><br /> <br /> === Representing "verbose" apparatus ===<br /> In a nutshell: when ou want to represent an apparatus entry written in a rather verbose way (in a print-to-digital edition). The same is true if you want to be able to generate a verbose apparatus note in a "born digital" edition. <br /> <br /> Use cases: <br /> <blockquote style="background:#FFEAEA">You're encoding an existing edition, and want to represent the source it edits, while keeping intact the text / apparatus of the existing edition. Some apparatus entries are easy to represent with the <app> / <lem> / <rdg> elements, some others add editorial comments to the listing of the variants, and are quite difficult to represent. BTW, the same goes when you are encoding a born-digital edition for which you want to be able to generate an alternative print output corresponding to the traditional standards of a collection. <br /> <br/><br/><br /> A - When I have a footnote giving two <i>lectiones</i> from the same manuscrip, one before correction and the other after: <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Text<span class="moz-txt-tag"></span></b>: ad lectorem Venetum (b) .<br /> <br><br /> <b class="moz-txt-star"><span class="moz-txt-tag"></span>Note<span class="moz-txt-tag"></span></b>: b) <i>ms.</i>, lectionem venerum <i class="moz-txt-slash"><span class="moz-txt-tag"></span>corrigé postérieurement en<span class="moz-txt-tag"></span></i> lectorem Venetum<br /> <br/><br /> <br/><br /> If I encode it like this, with two seprate rdg for the same<br /> witness, each with a different @type (for instance, "anteCorr" and<br /> "postCorr"), it gives an accurate account of the state of the witness, BUT it is an<br /> interpretation of the original note in the critical apparatus, i.e. if<br /> I do this I delete some text added by the original editor. <br><br /> <br /> &lt;app n="b"&gt;<br /> <br><br /> &lt;lem&gt;lectorem Venetum&lt;/lem&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="anteCorr"&gt;lectionem venerum&lt;/rdg&gt;<br /> <br><br /> &lt;rdg wit="#ms.2" type="postCorr"&gt;lectorem Venetum&lt;/rdg&gt;<br /> <br /> <br><br /> &lt;/app&gt;<br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> Let's consider this other note. There is some text added verbosely within the apparatus note by the editor. <br/><br /> <p class="MsoNormal" style="text-align: justify;"><b style=""><span style="">Text</span></b><span style="">: Hiis diebus civitas<br /> Pergamensis(b) tenebat exersitum</span><br/><br /> <b style=""><span style="">Note</span></b><span style="">: b) se, <i>mis indûment avant</i> tenebat <i>par le ms</i>.</span></p><br /> <br /> <p class="MsoNormal"><span style="">Should I encode it as: <br><br /> ... Pergamensis &lt;app<br /> n="b"&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt;&lt;/rdg&gt;<br><br /> &lt;/app&gt;</span>... <br><br /> </p><br /> <br /> I one represents this note strictly with the <app> / <rdg>, it leads to suppress remarks by the original editor. Adding a note in the rdg to preserve the editor's comments could work here, ut it's not always the case<br/><br /> Like: <br/><br /> <span style="">... Pergamensis &lt;app<br /> n="b"&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;lem/&gt;<br/><br /> &nbsp;&nbsp;&nbsp; &lt;rdg<br /> type="addition" wit="#ms"&gt;&lt;sic&gt;se&lt;/sic&gt; </span><span style="">&lt;note&gt;&lt;hi<br /> rend="italics"&gt;<span style="">mis<br /> indûment avant</span>&lt;/hi&gt; tenebat.</span><span style="">&lt;/note&gt;&lt;/rdg&gt;<br><br /> <br /> &lt;/app&gt;</span><br /> </blockquote><br /> <br /> <br><br /> <br /> <blockquote style="background:#FFEAEA"><br /> <p class="MsoNormal" style="text-align: justify;">'''Text'''<span style="">: …reliqui demum meos socios (d)<o:p></o:p></span><br><br /> '''Note'''<span style="">: d) domum<br /> meam solito, <i>Bal.;</i> dni <i>ou</i> dm, <i>ms.; en note</i> meam solita.</span></p><br /> <br /> Here we have 2 witnesses (Bal. et ms.), the latter with a) an uncertain<br /> lectio ("dni" or "dm") and b) a part of the lectio which is written as<br /> a note ("meam solita"). This is tricky to encode. <br /> </blockquote><br /> <br /> <br /> [[Category:SIG:Manuscripts]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9012 Critical Apparatus Workgroup 2011-03-21T16:33:05Z

<p>Mburghart: /* A reading covering several paragraphs */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middell (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middell summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <blockquote style="background:#FFEAEA">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> [[Category:SIG:Manuscripts]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9011 Critical Apparatus Workgroup 2011-03-21T16:32:14Z

<p>Mburghart: /* A reading covering several paragraphs */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middell (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middell summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <blockquote style="background:#c0c0c0">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br/><br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes numbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> [[Category:SIG:Manuscripts]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9010 Critical Apparatus Workgroup 2011-03-21T16:31:51Z

<p>Mburghart: /* A reading covering several paragraphs */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middell (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middell summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <blockquote style="background:#c0c0c0">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/><br/><br /> <br /> - I use the parallel segmentation method<br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes noumbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/><br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> [[Category:SIG:Manuscripts]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9009 Critical Apparatus Workgroup 2011-03-21T16:31:30Z

<p>Mburghart: /* A reading covering several paragraphs */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middell (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middell summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <blockquote style="background:#c0c0c0">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br/>br/><br /> <br /> - I use the parallel segmentation method<br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes noumbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br/>br/><br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> [[Category:SIG:Manuscripts]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9008 Critical Apparatus Workgroup 2011-03-21T16:30:57Z

<p>Mburghart: /* A reading covering several paragraphs */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middell (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middell summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <blockquote style="background:#c0c0c0">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br /> <br /> - I use the parallel segmentation method<br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes noumbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </blockquote><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> [[Category:SIG:Manuscripts]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9007 Critical Apparatus Workgroup 2011-03-21T16:25:29Z

<p>Mburghart: /* A reading covering several paragraphs */</p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middell (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middell summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <span style="background:#c0c0c0">I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br /> <br /> - I use the parallel segmentation method<br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes noumbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </span><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.<br /> <br /> [[Category:SIG:Manuscripts]]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9001 Critical Apparatus Workgroup 2011-03-21T10:39:35Z

<p>Mburghart: </p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middel (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middel summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <pre>I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br /> <br /> - I use the parallel segmentation method<br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes noumbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </pre><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem.</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=9000 Critical Apparatus Workgroup 2011-03-21T10:38:38Z

<p>Mburghart: </p> <hr /> <div>The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html Critical Apparatus] workgroup is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middel (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <pre>I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br /> <br /> - I use the parallel segmentation method<br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes noumbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </pre><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem. <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middel summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]</div>

Mburghart https://wiki.tei-c.org/index.php?title=Critical_Apparatus_Workgroup&diff=8999 Critical Apparatus Workgroup 2011-03-21T10:37:41Z

<p>Mburghart: New page: The Critical Apparatus [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter] is part of the TEI special interest group on manuscript SIG:MSS. Thi...</p> <hr /> <div>The Critical Apparatus [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter] is part of the TEI special interest group on manuscript [[SIG:MSS]].<br /> This page provides a summary of the preliminary discussions regarding the current issues with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html the critical apparatus chapter]. <br /> <br /> Participants to the preliminary workgroup: Marjorie Burghart (MB), James Cummings (JC), Fotis Jannidis (FJ), Gregor Middel (GM), Dan O'Donnell (DOD), Espen Ore (EO), Elena Pierazzo (EP), Roberto Rosselli del Turco (RDT), Chris Wittern (CW)<br /> <br /> == A preliminary vocabulary question == <br /> The very name of the chapter, "Critical apparatus", is felt by some to be be a problem: the critical apparatus is just inherited from the printed world and one of the possible physical embodiment of TEXTUAL VARIANCE. EP therefore proposes to use this new name, moving from "citical apparatus" to textual variance.<br /> <br /> MB argues that, oddly, "textual variance" feels more restrictive to her than "critical apparatus": it is a notion linked with Cerquiglini's work, which does not correspond to '''every''' branch of textual criticism. On the other hand, strictly speaking, the "critical apparatus" is not limited to registering the variants of the several witnesses of a text. It also includes various kinds of notes (identification of the sources of the text, historical notes, etc.). Even texts with a single witness may have a critical apparatus. Maybe the problem with the name has its origins in the choice of giving the name "critical apparatus" to a part of the guidelines dedicated solely to the registration of textual variants. <br /> <br /> FJ argues that for German ears the concept of textual variance is not closely connected to a specific scholar.<br /> <br /> MB proposes to use "TEXTUAL VARIANTS" instead, since it focuses more on actual elements in the edition, when "variance" is nothing concrete but a phenomenon. <br /> <br /> <br /> <br /> Side remarks by MB: this vocabulary queston might prove sticky in the end. The <app> elements is named <app> because it is considered "an apparatus entry", so unless we end up recommending to change the elements names, the phrase "critical apparatus" will still be used in the module, at least to explain the tag names?<br /> <br /> RDT argues that while backward compatibility is clearly a bonus, as MB states <app> stands for 'apparatus entry': we shouldn't be afraid to change its function, for instance making it a container instead of a phrase level element. RDT stresses that he is proposing this by way of example, and to stress that our focus is on variants: these might then be organised in <app>s for traditional CA display, and/or in other, new ways for electronic display. Note that this might mean no traditional critical apparatus in a digital edition.<br /> <br /> <br /> <br /> MB: It is characteristic of a print-based approach to encoding that the <app> element was considered as encoding an apparatus entry (hence the <app> name), when what it really encodes is a locus where different witnesses have variant readings (whch would probably have justified a name along the lines of <locus> or whatnot). <br /> <br /> JC: Thinks this points to a slight divergent nature at the heart<br /> of the current critical apparatus recommendations. That of encoding<br /> an apparatus at the site of textual variance and encoding a structured<br /> view of a note entirely separate from the edited version of texts.<br /> (In mass digitization of critical editions, for example, one might<br /> have an <app> in a set of notes at the bottom of the page which are<br /> not encoded at the site of variance, or indeed necessarily connected<br /> with it.) It is this striving to both be able to encode all sorts of<br /> various legacy forms of apparatus as well as simultaneously catering<br /> for those who are recording the structure by which they will generate<br /> an apparatus in producing some output. So JC would argue that the first of<br /> these are apparatus and the second of these is a site/locus of textual<br /> variance.<br /> <br /> <br /> == Issues with the current Critical Apparatus chapter/module == <br /> <br /> Preliminary notice: most of the issues raised here are connected with the parallel segmentation method, not because it is the more flawed, but because it is the more used by the members of this group. While location-referenced and double-end-point-attachment might be useful for mass conversion of printed material (for the former) and/or when using a piece of software handling the encoding (for the latter), the parallel segmentation method seems to be the easiest and more powerful way to encode the critical apparatus "by hand". <br /> <br /> Also, one might point out that most of the issues raised here might be solved with standoff encoding. But this is extremely cumbersome to handle without the aid of a software, and it does not correspond to the way most people work. <br /> <br /> === A reading covering several paragraphs ===<br /> <br /> In a nutshell: the <app> element is phrase-level, when it really should be allowed to include paragraphs, and even &lt;div&gt;s. <br /> <br /> Use case: <br /> <pre>I'm encoding a 19th c. edition of a medieval text, and one of the <br /> witness has omissions of several paragraphs. Of course, the TEI schema <br /> won't let me put &lt;p&gt; elements inside an <app>/<lem> element...<br /> <br /> - I use the parallel segmentation method<br /> - It is important to me to keep a methodical link between the encoded <br /> apparatus and the notes noumbers in the original edition (the <br /> @n of each <app> tag bears the number of the footnote in the original <br /> edition)<br /> <br /> Here is the [http://baluze.univ-avignon.fr/scan/t1/%285%29.jpg scan of a page from this edition], please consider footnote number 9. <br /> The note contains: "9. Eodem anno, rex Francie… dampnificati, paragraphes omis par Bal.", meaning that the ''Bal.'' witness has an omission where other witnesses have two long paragraphs, the first one beginning on the previous page (see the [http://baluze.univ-avignon.fr/scan/t1/%284%29.jpg previous page scanned]). <br /> </pre><br /> <br /> === Transpositions ===<br /> <br /> In a nutshell: with the parallel segmentation method, it is often cumbersome to render transpositions. <br /> <br /> === Scalability ===<br /> <br /> In a nutshell: the parallel segmentation method is difficult to handle when adding hundreds of conflicting witnesses. <br /> <br /> === Refactoring ===<br /> In a nutshell: with the the parallel segmentation method, it is cumbersome to add a new reading that necessitates changing where the borders of readings are drawn. <br /> <br /> === conflicts between individual readings and the semantics of structural markup that surrounds it ===<br /> In a nutshell: with the parallel segmentation method, witnesses with different forms of lineation pose a problem. <br /> <br /> == The standpoint of developpers of computer-aided collation tools == <br /> <br /> Gregor Middel summarized this standpoint for the workgroup in a page on the model of [[Textual_Variance]] used in [http://collatex.sourceforge.net/ CollateX] and [http://www.juxtasoftware.org/ Juxta]</div>

Mburghart