Version classiqueVersion mobile
OpenEdition Books

What is the Text Encoding Initiative?

 | 
Lou Burnard

The TEI cornucopia, part one

Texte intégral

1In this and the following chapter we discuss and exemplify some of the elements defined by the full TEI. The elements discussed in the present chapter are likely to be useful in almost every kind of encoding project; those discussed in the next are more specialized. It should be emphasized that all we aim to do here is to give some sense of the rich variety offered by the TEI; for complete information the Guidelines should always be consulted.

Milestones

2We noted above that the TEI is most often used to represent the organization of a book into components such as chapters, paragraphs, etc. or of a poem into verses and stanzas. But books and printed poems also exist as physical objects, which are typically made up of pages with verso and recto surfaces. Why does the TEI not provide an element <page> to represent each page of a book? Surely it is at least as important to know on which page a sentence begins as it is to know that it is in the fifth paragraph of the second chapter of the ninth subsection of a work? Surely we would like to be able to display the text paginated on screen in the same way as it was paginated in the original source?

3The answer to these perfectly reasonable questions is perhaps surprisingly complex. In fact, the TEI does provide an element to mark up page boundaries (<pb>), but it is an empty element which should be placed at the beginning of the text transcribed from each page:

<body xml:lang="en">
	<pb n="42"/>
	<p>This paragraph begins on the page numbered 42... 
  <!-- lots more text here -->
	<pb n="43"/>
  <!-- yet more text here --> ... and finishes half way down the page numbered 43.</p>
	<p>This much shorter paragraph begins and ends on page 43. </p>
</body>

4 A close study of the above example may help explain why a <page> element that actually encloses all the text on a page (rather than an empty <pb> which simply flags the beginning of a page) is not possible. In XML and similar markup languages, it is an absolute requirement that the elements defined by the markup tags should be properly nested one within another. If we start a <page> element, and then within it start a <p> element, the syntax of the language requires us to close that <p> before we can close the <page>, even though it is an observed fact of life that paragraphs frequently span across page boundaries.

5Users of XML (and before that SGML) have been trying to find better ways of representing textual structure without falling foul of this constraint for decades, and we don’t intend to debate the ‘overlap problem’ in any more detail here. We note simply that one well-established TEI way of addressing this problem takes the form of the ‘milestone’ tags, of which <pb> is probably the most frequently encountered example. Whereas normal tags in an XML document mark explicitly both the start and the end of an element and thus always enclose something, a milestone tag marks simply a point at which something changes, but does not enclose anything. Milestone number 42 on the road from London to Bath marks the point at which the forty-second section of that road begins. We can guess that if we keep going we will eventually reach milestone number 43, which will mark the point at which the forty-third section starts, and hence (since a stretch of road cannot be in two sections at once) the point at which the forty-second section finishes, but it is not explicitly marked.

6The elements <lb> (line break), <cb> (column break), and <gb> (gathering or folio break) are all milestones in this sense. In addition the TEI provides a generic <milestone> element which can be used to mark any kind of unit not otherwise provided for. As an example consider the practice (common in the 19th century) of publishing novels in serial form. We might wish to mark the boundary of the individual part issues, even though these do not necessarily fit well with the novel’s internal organization as a series of chapters. (Dickens, for example, was not above closing a part issue with a mid-chapter cliff-hanger). A <milestone unit='serialPart' n='12'/> can be used to represent the point at which serialPart number 12 begins, independent of the structure of <div> and <p> elements used for the text itself.

7This generic element can be used for any kind of shift, of course, not simply structural units. A narratological analysis might be represented using <milestone> elements to mark points at which the narrative voice changes; a stylistic analysis might use them to mark points of stylistic variation. There are also other specific elements which behave in a milestone-like fashion for example to indicate changes of voice quality in transcribed speech, or changes of hand in transcribed manuscript.

Languages and writing systems

8Unless it is an empty milestone every element in a TEI document can contain one of plain text, ‘element content’, or (by far the most frequent case) ‘mixed content’. Plain text consists of encoded characters represented using the Unicode standard; element content consists of other XML elements; and mixed content combines the two. TEI elements and attributes are used to associate semantic and other properties with the content so that a processor can treat it correctly in a variety of situations. One particularly important property is the human language in which the textual content is expressed; another is the way the textual content is displayed or formatted. These properties are potentially important at almost every level: we might want to say that a whole document uses a specific language, or that just a few words here and there do; we might want to say that the whole of a document was typeset in a Roman font of a given size, and then indicate those parts of it which use some other font or size. Because such information is potentially applicable to every element, the TEI proposes global attributes to specify it.

Languages

9The global @xml:lang attribute is the recommended means of specifying the human language in which the content of an element is expressed. (As the xml: prefix suggests, this attribute is common to all XML documents: it is not defined by the TEI but by the W3C, as part of the definition of XML.) Its value applies hierarchically to all the elements contained by that element, unless overridden:

<div xml:lang="la">
	<s>Pars haec lingua Latine composita est.</s>
	<s xml:lang="en">Except that this sentence is in English.</s>
	<s>Vita brevis, ars longa.</s>
</div>

10Here we specify that the whole <div> element uses the language with the coded identifier la (The codes used are taken from ISO standard 639 for language identifiers) i.e. Latin. Since it is contained by that <div> there is no need to supply this information again for the first <s> element. The second <s> element however overrides this value, and indicates that its content is in English (the language with identifier en). The third <s> element is again in Latin. To find the language for any element’s content, a processor must first look to see whether that element, or any of its parents, supplies a value for @xml:lang. As you may suppose, the nearest parent is the one applicable, if there is more than one. Suppose, for example, that the second sentence above also contained a phrase in French. Such a phrase will need to be tagged with some element of course: the element <foreign> is provided for cases like this, where we simply want to show that some sequence of content uses a different language:

<div xml:lang="la">
	<s>Pars haec lingua Latine composita est.</s>
	<s xml:lang="en">Except that <foreign xml:lang="fr">sacrebleu</foreign> this
	sentence is in English.</s>
	<s>Vita brevis, ars longa.</s>
</div>

11The codes used to identify language may (as here) be standard two-letter codes; more complex codes can be used to distinguish such things as geographically or socially-defined variants, or to distinguish the same language written using different scripts. These codes, and ways of using them, are defined by the ISO rather than the TEI, and we do not discuss them further.

Nonstandard characters

12We noted above that a TEI document is an XML document, and therefore expressed using Unicode characters. The Unicode standard at the time of writing covers a very high proportion of existing and ancient writing systems, but quite properly does not attempt to standardize writing systems still in the course of being studied or defined, nor does it attempt to provide codes for every possible character or glyph variant likely to be encountered in the study of ancient documents. For these reasons, the TEI provides an element <g> which can be used to mark the presence in a document of some character or glyph for which there is no existing standard Unicode codepoint.

13Suppose for example that we are studying a range of manuscripts characterized by a particularly striking variant form of some letter (say an R); our TEI transcriptions can distinguish this variant glyph from the usual form of the same letter by using a <g> element to mark it. The content of the <g> might simply be a normalised form, or the element might be empty; in either case it will carry a @ref attribute which points to a <glyph> element somewhere, in which we define the nature, function, appearance, name etc. of this variation. Thus, supposing that we have identified and described three variant forms of the letter R, giving them codes R1, R2, R3, we might represent individual occurrences of these forms as <g ref='#R1'/>, <g ref='#R2'/>or <g ref='#R3'/>. The associated definitions may be provided within the <charsDecl> element of the TEI Header, discussed below.

Rendition

14The term rendition is used in a TEI context to describe the way in which an element is formatted or presented, on screen or on the page. The TEI is not a document formatting system, and (as we suggested above) generally aims to facilitate an encoding which is faithful to the perceived meaning of a text rather than one which reproduces its appearance, or intended appearance. This is one of many aspects which distinguish the TEI from systems such as those typically used for word processing, as we noted above. Nevertheless, recognizing that it may be important to retain information about the original rendition of a document for analytic purposes (not least because it may be that its appearance is all we can reliably describe in an ancient document), the TEI provides a number of mechanisms for encoding such data. We emphasize again that the function of such renditional markup is always to describe the appearance or rendition of one or more original source documents; of course, it is likely that when displaying a text encoded in such a manner we will wish to achieve a similar appearance using different technology, but this is by no means always or necessarily the case.

15The simplest method is to use the global attribute @rend. This attribute behaves in a way similar to the @xml:lang attribute discussed above: it supplies a coded value for the rendition associated with an element and (unless overridden) its children. Unlike @xml:lang however, the values available for use with the @rend attribute are not formally defined, either by the TEI or any other agency, although a comparatively small number of codes are conventionally used. The encoder is free to make up their own set of labels and to apply them as consistently (or inconsistently) as they wish.

16The @rendition attribute, by contrast, behaves more like the @ref attribute on <g> in that it references a definition (or set of definitions) provided elsewhere; the encoder is thus constrained both to use only a specified set of renditional labels and also to supply (or refer to) some kind of definition of the intended meanings for each such label.

17Such style definitions are of course most easily expressed using an encoding language designed for formatting software, such as a web browser or document processing system. The TEI allows you to express your definitions in whatever such language you choose; currently a well established W3C recommendation called CSS (Cascading Stylesheets) is the most practical, since it is both powerful and very widely implemented. The syntax of this language is very simple and it can even be used directly within a TEI document, either to provide a default rendition for an element, or to override that default using yet another global attribute: @style.

18We show how each of these methods might be used to encode the following brief passage, taken from an early 17th century schoolbook.

Figure 3

Figure 3

Extract from Henry Care’s The tutor to true English (1687), p 70

19In this passage, we observe sequences of words in a gothic or black letter font, in a normal roman font, and in italics. We can speculate about the reasons for this typographic variation, but supposing that at least initially all we want to do is record it, we might adopt a encoding like the following:

<p rend="roman">
	<lb/>And here note, for a Caution against	<hi rend="italic">Extrava-<lb break="no"/>gance</hi>, and 
	for encouragement to <hi rend="italic">Frugality</hi>
	and <lb/>good Husbandry in all People, especially <hi rend="italic">Youth</hi>,
</p>
<p rend="gothic">
	<lb/>That <hi rend="roman">every Penny</hi> any Person spends
	<lb/>idly, would purchase a <hi rend="roman">Yard</hi> (that is three <lb/>foot)
	square, and somewhat above, of as <hi rend="roman">
	<lb/>good Land</hi> as most in England, to <hi rend="roman">him <lb/>and his Heirs
	for ever.</hi>
</p>

20This encoding uses the milestone <lb> element to mark explicitly the start of typographic lines. It also uses a new element <hi> (short for highlighted). This element has no particular semantics - it simply indicates that its content is visually distinct from what surrounds it, in rather the same way that <foreign> simply shows that its contents are linguistically distinct from what surrounds it. The nature of this visual distinction is not fully specified since this encoding does not explain what the values roman, italic or gothic mean; nor is there any way of providing such an explanation other than a documentary note. Of course, a human reader will know more or less what italic means, but a rendering program will probably not. Suppose instead that we have provided definitions (expressed in CSS) in the place in the <teiHeader> allocated for this purpose:

<rendition xml:id="it" scheme="css">font-family: roman; font-style: italic</rendition>
<rendition xml:id="ro" scheme="css">font-family: roman; font-style: normal</rendition>
<rendition xml:id="go" scheme="css">font-family: unifraktur cursive</rendition>

21With these definitions in place, we could now simplify our example slightly:

<p rendition="#go">That <hi rendition="#ro">every Penny</hi> any Person spends idly
 ...</p>

22Any rendering program can now process the CSS directly and display our text in a visually distinctive manner.

23Moreover, since the CSS expressions are actually quite simple, we might just use the @style attribute to provide them directly within our text:

<p style="font-family: roman">And here note, for a Caution against <hi style="font-style:italic">Extravagance</hi>, and for encouragement to <hi style="font-style:italic">Frugality</hi> ...</p>

24As we noted above, the <hi> element has no semantics other than to indicate that some part of the document being encoded looks significantly different in some respect. In large scale encoding projects identifying such variation may be all that is feasible; in projects working with very ancient, visually complex, or scarcely comprehensible resources, it may also be very hard to go beyond the point of saying this part of the text is visually distinct in some way. But for the vast majority of TEI encoding projects it is usually considered both desirable and feasible to add value to an encoding by pausing to consider why something is visually distinct in the source. Where an answer to that question can be reached with any degree of confidence, an encoding which shows us what motivated the original renditional decision is more likely to be generally useful than one that does not.

25It is not so difficult to list the main reasons why a printer might choose to highlight some words in a text printed according to the conventions elaborated in Western Europe over the last 300 years or so. Words in a foreign language are almost always highlighted, as are words on which the author places some degree of linguistic emphasis. Titles and technical terms are conventionally identified by highlighting when they appear in running prose. Until recently, words indicating the names of persons, places, or abstractions would conventionally be highlighted as well.

26Note that we use the word highlighted here to include any form of visual salience, whether it is a passage in italic embedded in one predominantly set in roman font, or the reverse, or (as above) a passage in roman embedded in one predominantly in gothic. If we extend the meaning of the term to include passages set off by quotation marks of various kinds, the list of motivations for highlighting expands to include passages of direct speech, material cited or quoted from elsewhere, or which the writer wishes to indicate as being in some sense non-authorial, words which are being talked about rather than used... and so on and so forth.

27The TEI provides elements which enable the encoder to make all these and other semantic distinctions within the simple words of a text, guided by the visual clues implicit in the original rendition of a document, and the encoder’s understanding of it. This is often a useful way of distinguishing an otherwise ambiguous passage of text. In a modern journal article, for example, a passage set in italic might be a foreign expression, the title of another article or of a film or song, a technical term, or a phrase the author wishes to emphasize. By using the appropriate tag (<foreign>, <title>, <term>, or <emph> respectively), the encoder enriches the text and facilitates more intelligent processing of it, for example to list the titles of works mentioned in a document, excluding emphasized or foreign words.

28These tags can also be used even when no highlighting has been applied, of course. The @rend attribute is also available on all these elements, so that the encoder can say both what they believe a highlighted passage to indicate, and in what respects (if any) it is visually salient.

Names and dates

29We mentioned above the convention of highlighting the names of persons places, etc. in printed text. This practice, which was commonplace till the mid 19th century, testifies to a long standing desire on the part of readers to distinguish names clearly from other words, and it is one which remains true of modern day digital encoders. Identifying what are now often referred to as named entities from the rest of a sea of words is just as important a task for today’s computational linguist building a language understanding system, or today’s digital historian tracing social networks within a corpus of 18th century correspondence, as it is for today’s intelligence operative trying to track down references to terrorist suspects in vast bodies of surveillance data.

30The TEI provides several elements to encode such things once they have been identified. Probably the most general-purpose of these is <rs> (short for referring string) which can be used to tag any sequence of words considered by the encoder to refer to some entity such as a person or place, even if the reference does not take the form of a name, but is rather a pronominal reference (she, the king) or deictic phrase (that girl, the chap we saw on Thursday), or idiom (the great wen, the big apple). When however a reference of this kind contains only one or more proper nouns, it should be encoded using the generic <name> element.

31Both <rs> and <name> elements have a @type attribute which can be used to distinguish the type of entity being named, so that, for example, the place <name type="place">London</name> is distinguishable from the author <name type="person">London</name>. However, the TEI also provides specialised tags which enable you to make the same distinction, and others, with more precision. These more specialised elements distinguish names which refer to different kinds of entity explicitly: thus it provides <persName>, <placeName>, <orgName>, to support the assertion that the name refers to a person, place or organization. It is also possible to identify significant subcomponents of such names: the TEI provides <surname>, <foreName>, <altName> (for an alternative name such as a nickname), <roleName> (for a socially-defined role or title such as Lady, Esquire, Preacher, etc.), <genName> (for a generational name such as Junior, the elder, etc.) and others. For place names, the TEI distinguishes components placing the name socio-politically such as <settlement>, <region>, <country> and also components such as <geogName> for any purely geographic name such as Mount Sinai or River Thames, which can also be further decomposed into a name (Thames, Sinai) and the name of some kind of geographic feature (Mount, River).

32These elements are particularly useful when dealing with archival documents of any kind, in which indexing the names of people and places referred to in a document is a major concern, but they may be useful in any kind of digital edition or lexical study.

33Suppose, for example, that we are preparing a digital edition of a primary document such as the Current Record of Events from 1792 to 1885, As recorded by The Shaker community of Canterbury, New Hampshire (a manuscript preserved in the Special Collections of Hamilton College Library). This 19th c. document begins with the following sentence: On the first of February 1792 Father Job Bishop and Elder Edmond Lougee came from New Lebanon N.Y. to organize and establish a community of Believers at Canterbury N.H..

34We might be content simply to record the presence of the proper names (Father Job Bishop, Canterbury etc.) using the <name> element as follows:

<p>On the first of February 1792 <name>Father Job Bishop</name> and <name>Elder Edmond
   Lougee</name> came from <name>New Lebanon, N.Y.</name> to organize and establish a
 Community of Believers at <name>Canterbury, N.H.</name>
</p>

35Even this minimal tagging makes it easy to distinguish the names of the people and places mentioned, and hence to process them separately from the rest of the text, for example to construct an index of names, or to link these references to further information about the person or place concerned.

36A more careful tagging would however distinguish the component parts of the names which (as is often the case) combine family names (Bishop, Lougee) with names indicating a social role (Father, Elder) and with forenames (Job, Edmond). Such distinctions can only be made explicit by proper tagging - Bishop might be a role or a surname, depending on context. Similarly, within a <placeName> it is convenient to distinguish the name of an administrative or other region such as a US state from the name of a settlement (TEI uses this neutral term in preference to other terms such as town, village, city etc. which are hard to define outside a very precise context).

<p>On the first of February 1792 <persName>
  <roleName>Father</roleName>
  <forename>Job</forename>
  <surname>Bishop</surname>
 </persName> and <persName>
  <roleName>Elder</roleName>
  <forename>Edmond</forename>
  <surname>Lougee</surname>
 </persName> came from <placeName>
  <settlement>New
     Lebanon</settlement>
  <region>N.Y.</region>
 </placeName> to organize and establish a Community of Believers
 at <placeName>
  <settlement>Canterbury</settlement>,
 <region>N.H.</region>
 </placeName>
</p>

37By definition, a name refers to a specific entity (a person or place) but historical or genealogical research would not be much of a challenge if it did so unambiguously or directly. Is this Edmond Lougee the same person as the Edmund Lougee recorded in other sources? A little further in the source, there is a mention of Elder Lougee: does this refer to the same person? As ever, TEI cannot help you answer such questions, but it does provide ways of expressing the answer (if any) you have reached.

38Proposing a standardised form for a name has, of course, long been the business of librarians and cataloguers. For literary works and persons, and for modern or classical geographies, there exist well-established reference works or ‘authority files’ which provide a useful point of reference for many of the entities that may be named in a TEI document; for others, we may find some kind of canonical information in other online references such as wikipedia or ancestry.com. One way of making clear which of the many possible people which we believe this Edmond Lougee concerns would therefore be to provide a reference to an online definitive record for the person:

 ... <persName
  ref="http://records.ancestry.co.uk/​Edmund_Lougee_records.ashx?pid=24762763"> Elder
 Edmond Lougee </persName> ... 

39However, given that few of the people in an archival document of this kind are likely to have such records, it will often be necessary for a project to define their own authority file, comprising a series of records, one for each identified individual. The TEI provides additional elements which can be used to record such information in some considerable detail: biographical or prosopographical information for example can be grouped within a <person> element, while geographical information can be grouped within a <place> element; if this is done, then the @ref attribute can be used to point to such a description:

<persName ref="#P1234"> Elder Edmond Lougee </persName>
<!-- .... -->
<person xml:id="P1234">
 <p>Edmund or Edmond Lougee was born in Exeter Newmarket, Rockingham, New Hampshire,
   USA on 1731 to John Lougee and Anne Gilman. He married Hannah Lord and had 7
   children. He passed away on 3 Jun 1807 in Loudon, New Hampshire, USA.</p>
</person>

40Note that this example simply provides a prose summary of the available information for Elder Lougee within the referenced <person> element; it might alternatively have been constructed using specialised elements such as <birth>, <death>, <marriage>, <relation> etc.

41It may however be sufficient for the needs of a project to provide with each reference an arbitrary code, or a normalised form of the name, perhaps including dates or a generational marker to make that form unambiguous. The @key attribute is provided for this purpose:

<persName key="Lougee, Edmond (1731-1807)"> Elder Edmond Lougee </persName>

42Normalisation by means of attribute values is a mechanism found throughout the TEI. It is particularly useful wherever something that a search engine or other processor would prefer to find in one particular format actually appears in a document in many different forms, some of which may have some linguistic interest or significance. If we want to recover from this document all references to events occurring before or after a particular date, for example, the task will be much easier if the dates all use a standard representation. In the above example, we might therefore choose to encode the first date as follows:

<p>On <date when="1792-02-01">the first of February 1792</date> ... </p>

using the W3C recommendation for the format of dates. The @when attribute used here allows us to associate a date with a specific point in time. The TEI also provides a set of other attributes which can be used in combination to express a variety of temporal concepts:

<p>
 <date notAfter="1792-02-28" notBefore="1792-02-01">In February 1792</date> ... 
</p>

<p>
 <date from="1792-02-01" to="1792-02-07">During the first week of February 1792</date>
 ... 
</p>

Tables, figures, and bibliographies

43Documents in the real world contain many non-textual or only semi-textual components such as figures or tables, as well as textual components that have their own internal structure such as indexes and bibliographies. Particularly where the TEI is used to encode a new document, but also where there is a need to indicate the presence of such features in an old one, the encoder cannot do without elements such as <table>, <figure>, or <bibl>, each of which we introduce very briefly in the following sections.

Tables

44A table is a way of organizing several related snippets of textual information into rows (or columns) composed of cells. Most document production systems have developed quite complex ways of indicating exactly how the cells of a table should be displayed, but these are largely missing from the TEI table model. In the TEI, a <table> element is composed of <row> s, which are composed of <cell> s; a TEI table cannot therefore easily be represented as a series of columns. There is an attribute @role to indicate whether a particular row or cell contains labelling information or data, and there are attributes @rows and @cols which can be used to indicate when a row or a cell spans more than one row or column respectively.

45Suppose we find the following (imaginary) table in a document we are encoding:

Figure 4

Figure 4

An imaginary table

46In our TEI version, we can record that the first column of cells supplies a label for the entries in the remainder of each row, and also that the cell in the third column of the first row spans two columns.

<table>
 <row>
  <cell role="label">Fruit</cell>
  <cell>apple</cell>
  <cell>banana</cell>
  <cell cols="2">cherry</cell>
  <cell>date</cell>
 </row>
 <row>
  <cell role="label">Nuts</cell>
  <cell>almond</cell>
  <cell>brazil</cell>
  <cell>coconut</cell>
  <cell>doughnut</cell>
  <cell>pistachio</cell>
 </row>
</table>

Figures

47Any kind of graphic component such as an illustration, chart, or diagram may be embedded within a document, sometimes as a separate component such as a frontispiece or separately paginated illustration, sometimes as a part of some division of the text. Such figures often contain headings or titles, possibly associated with some running text, as well as an image. To encode them, the TEI provides a <figure> element which typically contains at least <graphic> and one or more <head> elements, though other textual elements may be used as well if the illustration contains text.

48The <graphic> element is a specialised kind of pointer. Its @url attribute points to a location where a digital representation of the image concerned may be found. Attributes @scale, @width or @height are available to specify the desired size of the image when it is displayed.

49Consider the following example taken from Punch, a well known 19th century British humorous publication:

Figure 5

Figure 5

John Leech: Domestic Bliss,cartoon in Punch vol 13 (July 1847), page 14.

50We may encode this as follows:

<figure type="cartoon" place="topLeft">
 <head rend="caps">Domestic Bliss</head>
 <graphic url="vol13p14.png"/>
 <sp>
  <speaker rend="italic">Wife of your bussum</speaker>
  <p rend="smallcaps">
   <q>Oh! I don’t want to interrupt you dear. I only want some
       money for Baby’s socks — and to know whether you will have the mutton cold or
       hashed.</q>
  </p>
 </sp>
 <figDesc>A domestic interior drawn by Leech, showing a wild-haired man in a dressing
   gown sitting at a desk covered in papers, with his wife, two small children, one
   of them banging a drum, and a cat. </figDesc>
</figure>

51In our encoding we have transcribed the text below the graphic using the <sp> element discussed earlier, to show that the text is presented as a piece of dramatic dialogue. We have also used the <figDesc> element to enclose additional text, not present in the figure, but supplying useful descriptive metadata which might be displayed as an alternative to the graphic itself, or used to index its content.

Bibliographic descriptions

52Bibliographic descriptions, such as would usually be included as a bibliography or list of references at the end of an academic article, or in a footnote, are a common feature of scientific writing. It is useful to distinguish explicitly such items and in particular their components (author, title, publisher, publication date, etc.) both to make them more accurately searchable and to make it easier to render or format them in different ways. Where large numbers of such references are to be handled, specialist tools such as Zotero which can import or export in a TEI format provide an efficient way of maintaining them, but they can be treated in just the same way as any other component of a TEI document whether they appear in the body of the text, as a separate division of the back matter, or in the header.

53It is conventional practice in scientific writing to provide references in a standard format, in which the components appear in a specified order, and use consistent layout. Whether in a footnote, or in a standalone list of references, a book will typically be described something like this:

54Cameron, D. (1995) Verbal Hygiene. London and New York: Routledge.

55TEI markup can be used to show which part of this is the title, which the place of publication, etc. The TEI provides two distinct elements for this purpose: <biblStruct> and <bibl>.

56The <biblStruct> element provides a ‘structured’ or data-centred view of a bibliographic item, in which each part of the description (author, title, etc.) is tagged distinctly, treating it as if it were part of a database. Note that punctuation is not allowed between components: this is because different visualisations might be appropriate for different bibliographic styles. A detailed tagging like the following allows this to be done simply: the formatting program simply chooses the elements needed in the order required, inserting punctuation according to the style required.

<biblStruct xml:id="Cameron1995">
 <monogr>
	<author>
		<surname>Cameron</surname>
		<forename>Deborah</forename>
	</author>
	<title>Verbal Hygiene</title>
	<imprint>
		<publisher>Routledge</publisher>
		<pubPlace>London</pubPlace>
		<pubPlace>New York</pubPlace>
		<date>1995</date>
	</imprint>
 </monogr>
</biblStruct>

57The <monogr> element here indicates that this is what bibliographers call a monographic item, that is an individual work, rather than an analytic item such as an article in a journal.

58The <bibl> element provides a less structured, more text-centred, view of a bibliographic item, in which punctuation is permitted between tagged items, along with any running prose found, and the order of the components is not fixed. It is useful where the encoder wishes to follow the conventions of the (usually printed) catalogue from which such a description is taken or for which it is intended.

59Using this, we might tag this item in a way that more closely resembles the original version, at the price of making its subsequent processing a little more difficult:

<bibl>
	<author>Deborah Cameron</author>:
	<title level="m">Verbal Hygiene</title>.
	London, New York: Routledge.<date>1995</date>
</bibl>

60Most of the elements available within <biblStruct> are also available (but optional) within <bibl>, so it is possible to use either element to provide detailed tagging of any kind of bibliographic citation. We give some further examples below.

61When a book is mentioned within running text, particularly if it is mentioned more than once, it is usual to do so by means of a very short reference such as ‘Cameron 1995’. To link such a reference to a fuller bibliographic description of the work in question we can use the @target attribute on a <ref> or <ptr> element:

<p>Humans have <q>a healthy obsession with language</q> (<ref target="#Cameron1995">Cameron 1995</ref>). It would be surprising if we did not...</p>

Table des illustrations

Titre Figure 3
Légende Extract from Henry Care’s The tutor to true English (1687), p 70
URL http://books.openedition.org/oep/docannexe/image/689/img-1.png
Fichier image/png, 1,0M
Titre Figure 4
Légende An imaginary table
URL http://books.openedition.org/oep/docannexe/image/689/img-2.png
Fichier image/png, 5,4k
Titre Figure 5
Légende John Leech: Domestic Bliss,cartoon in Punch vol 13 (July 1847), page 14.
URL http://books.openedition.org/oep/docannexe/image/689/img-3.png
Fichier image/png, 4,1M

Acheter

Volume papier

Chargement

Unavailable