1.1. What do we need to make a textual resource?

1.2. What's in a text (2)?

1.3. What's in a text (3)?

1.4. The ontology of text

A "text" is an abstraction, created by or for a community of readers. Markup encodes and makes concrete such abstractions.

1.5. Encoding of texts

• Texts are more than sequences of encoded glyphs
  • They have structure and content
  • They also have multiple readings
• Encoding, or markup, is a way of making these things explicit

Only that which is explicit can be reliably processed

1.6. What's the point of markup?

• To make explicit (to a machine) what is implicit (to a person)
• To add value by supplying multiple annotations
• To facilitate re-use of the same material
  • in different formats
  • in different contexts
  • by different users

1.7. Markup is also a scholarly activity!

• Deciding what markup to apply, and how far this represents the original, is a kind of textual editing
• There is (almost) no such thing as neutral markup — all of it involves interpretation
• Useful markup is rarely as easy or as quick to produce as people would have you believe
• Markup can assist both in answering and in expressing fundamental research questions
• Deciding what to markup is at least as important as deciding how... we call that document analysis

1.8. What does markup capture?

1.9. A useful mental exercise

Now, imagine your budget has been halved. Repeat the exercise!

2.1. Schemas and namespaces

• A namespace is one way of specifying the meaning of the markup introduced in a document: like a dictionary
• A more powerful way is to use a schema: a kind of grammar for your markup
• A namespace tells you who defined or claims this element, but not much more about how to use it
• A schema tells you how you are supposed to use an element, and thus allows you to validate your documents against a set of rules

2.2. What can a schema do for you?

• ensure that your documents use only predefined elements, attributes, and entities
• enforce structural rules such as ‘every chapter must begin with a heading’ or ‘recipes must include an ingredient list’
• make sure that the same thing is always called by the same name

Schema languages vary in the amount of validation they support

2.3. Schemas

There are a variety of schema languages

• XML DTD language
• ISO RELAX NG
• W3C Schema
• ISO Schematron

All have different tool kits, different syntaxes, and different methods of doing things

2.4. The TEI aims to be independent of schema language

3.1. Some terminology

• The TEI encoding scheme consists of a number of modules
• Each module contains a number of element specifications (marked up in TEI using the <elementSpec> element)
• Each element specification contains:
  • a canonical name (<gi>) for the element, and optionally other names in other languages
  • a canonical description (also possibly translated) of its function
  • a declaration of the classes to which it belongs
  • a definition for each of its attributes
  • a definition of its content model
  • usage examples and notes
• a TEI schema specification (<schemaSpec>) is made by selecting modules and (optionally) modifying their contents
• a TEI document containing a schema specification is called an ODD (One Document Does it all)

3.2. What is a module?

• A convenient way of grouping together a number of element declarations
• These are usually on a related topic or specific application
• Most chapters of P5 focus on elements drawn from a single module, which that chapter then defines
• A TEI Schema is created by selecting modules and adding or removing elements from them as needed

3.3. Which modules exist?

3.4. The TEI Class System

• The TEI distinguishes over 500 elements,
• Having these organised into classes aids comprehension, modularity, and modification.
• Attribute class: the members share common attributes
• Model class: they can appear in the same locations (and are often semantically related)
• Classes may contain other classes
• An element can be a member of any number of classes, irrespective of the module it belongs to.

3.5. Attribute Classes

• Attribute classes are given (usually adjectival) names beginning with att.; e.g. att.naming, att.typed
• all members of att.naming inherit from it attributes key and ref; all members of att.typed inherit from it type and subtype
• If we want an element to carry the type attribute, therefore, we add the element to the att.typed class, rather than define those attributes explicitly.

4.1. Problems and solutions

• A methodology: markup
• An ontology: Text Encoding Initiative guidelines
• Modules: for different subject areas
• * ODD: Customizable schema(s)
• * Tools: to help build the schemas
• Tools: to creation and editing text

Now we've got a resource…

* we have not addressed these today.