TEIWiki - User contributions [en]

Level 3 Prose Documentation Feedback

2011-05-20T20:15:55Z

Melanieschlosser:

>>Return to testing instructions: [[Feedback_on_the_Best_Practices_for_TEI_in_Libraries_ODD_Documentation_and_Schemas]]

==Tester: Kevin Hawkins==

'''Comments/Feedback'''

* Move prose description of encoding figures ("Level 4 Figures") to Level 3 to correspond to move of these elements to that level (that happened on 30 June 2010).

==Tester: Melanie Schlosser==

'''Comments/Feedback'''

* Under 'reference', new sentence: "Note that this is intended to be a ‘TEI conformant’ customization, per P5 section 23.3."
* Everything else looks fine.

==Tester: Enter Your Name==

'''Comments/Feedback'''

* List feedback, problems encountered, etc. in bulleted list form. Provide detailed examples please so that we may make corrections more easily.
* Feedback
* Feedback

Feedback on the Best Practices for TEI in Libraries ODD Documentation and Schemas

2011-05-20T17:04:13Z

Melanieschlosser:

[[Category:SIG:Libraries|!]]

==Overview==

The Best Practices for TEI in Libraries are now captured in a series of ODD files that generate both the prose documentation for encoding levels 1-5 and the schemas for encoding levels 1-4 that conform to '''TEI P5'''. Before we can officially "release" the Best Practices, we need to undergo a round of systematic testing to make sure nothing was lost in translation from our original TEI wiki documentation to the ODDs. We have established a two-pronged testing approach:

* Review and compare the prose documentation with the original wiki documentation to make sure nothing is amiss.
* Test the RelaxNG and Schematron schemas against content from TEI P5 projects to see whether the expressed constraints match the prose documentation and whether they unduly constrain content that a project thinks conforms to a particular encoding level.

We are soliciting volunteers to help with both endeavors. We especially welcome "fresh eyes" to help us with testing and we would especially like to see '''multiple people testing the same levels''' to make sure we receive comprehensive feedback if possible.

Our goal is to have testing complete by '''May 1, 2011'''

==Prong 1: Review/Compare Prose Documentation==

In reviewing and comparing the prose documentation, we ask that you pay special attention to the following:

* Missing or altered prose
* Missing or altered markup examples
* Additional prose or examples not found in the original wiki documentation

We are still wotking on styling/rendering/display issues in the HTML output. However, please do feel
free to comment on rendering issues you may encounter. This will make sure we don't take any of it for granted.

===Links to Review/Compare Prose Documentation===

* Prose Documentation for Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_1:_Fully_Automated_Conversion_and_Encoding Wiki documentation]
* Prose Documentation for Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_2:_Minimal_Encoding Wiki documentation]
* Prose Documentation for Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_3:_Simple_Analysis Wiki documentation]
* Prose Documentation for Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_4:_Basic_Content_Analysis Wiki documentation]
* Prose Documentation for Level 5
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html#index.xml-body.1_div.4_div.2_div.5 ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_5:_Scholarly_Encoding_Projects Wiki documentation]
* Prose Documentation for Front and Back Matter (e.g., Introduction, Appendices, etc.)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html ODD documentation] (sections 1-4 (except 4.2), 5-7)
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries Wiki documentation] (sections 1-5, 7-10)

===Suggested Steps to Follow for Review===

# Select a section of the documentation to review and sign-up (see below)
# Read the ODD-generated documentation for the selected section
# Peruse corresponding section in the wiki version of the documentation
# Document any differences or problems encountered on wiki pages linked in table below

===Sign-Up for Review of Prose Documentation===

'''Note:''' We encourage more than one reviewer per level.

{| border="1"
|-
! Level
! Name
! Contact Email
! Feedback
|-
| Level 1
| Melanie Schlosser, Name 2, etc.
| melanie.schlosser@gmail.com, Email 2, etc.
| [[Level 1 Prose Documentation Feedback]]
|-
| Level 2
| Melanie Schlosser, Name 2, etc.
| melanie.schlosser@gmail.com, Email 2, etc.
| [[Level 2 Prose Documentation Feedback]]
|-
| Level 3
| Kevin Hawkins, Melanie Schlosser, etc.
| Email 1, melanie.schlosser@gmail.com, etc.
| [[Level 3 Prose Documentation Feedback]]
|-
| Level 4
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 4 Prose Documentation Feedback]]
|-
| Level 5
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 5 Prose Documentation Feedback]]
|-
| Front Matter (e.g., Introduction)
| Melanie Schlosser, Name 2, etc.
| melanieschlosser@gmail.com, Email 2, etc.
| [[Front Matter Documentation Feedback]]
|-
| Back Matter (e.g., Appendices)
| Melanie Schlosser, Name 2, etc.
| melanieschlosser@gmail.com, Email 2, etc.
| [[Back Matter Documentation Feedback]]
|}

==Prong 2: Test Levels 1-4 Schemas and Schematron==

In testing the schemas and schematron for levels 1-4, we ask that you pay special attention to the following:

* Aspects that do not validate and why (perhaps your local project isn't conformant or we overlooked a markup practice that should be reflected in the "Best Practices")

We expect schema and schematron validation to be more experimental. We are more concerned with validation errors than a perfectly valid document, but please do tell us if your project happens to validate.

'''Please note that these Best Practices and schemas conform to TEI version P5. Please make sure you are testing the right version of the TEI. Thanks!'''

===Download Schemas (RelaxNG) and Schematron===

You have the option of downloading the compact (.rnc) or regular (.rng) RelaxNG schema for each of the levels. Testing both is not required, but please
do let us know which schema you used.

* Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rnc Compact Syntax Closed Schema for Level 1] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rng XML Syntax Closed Schema for Level 1] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.isosch ISO Schematron Level 1] (.isosch)
* Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rnc Compact Syntax Closed Schema for Level 2] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rng XML Syntax Closed Schema for Level 2] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.isosch ISO Schematron Level 2] (.isosch)
* Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rnc Compact Syntax Closed Schema for Level 3] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rng XML Syntax Closed Schema for Level 3] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.isosch ISO Schematron Level 3] (.isosch)
* Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rnc Compact Syntax Closed Schema for Level 4] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rng XML Syntax Closed Schema for Level 4] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.isosch ISO Schematron Level 4] (.isosch)

===Schema and Schematron Setup===

Since TEI workflows and XML editors vary, we will not provide specific instructions on how to set up schema validation. We assume
you will plug in the Best Practices schema into your own workflow/software environments.

We assume the same is true for schematron validation, but will provide a scenario if you use the Oxygen XML editor:

* Make sure the TEI/XML file or files you are checking are open in Oxygen (run the schematron on one file or against multiple files assigned to a project)
* Click on the little downward-pointing error on the Validate icon (the red checkmark)
* Select "Validate with ..."
* Select the "Schematron Schema" tab and browse for the Best Practices schematron (.isosch) file you downloaded for testing
* Select "OK"

The schematron will run against your TEI file and generate a list of errors or warnings in the "Errors" pane of the Oxygen editor (similar to errors generated
when validating against the schema).

===Sign-Up for Schema/Schematron Testing===

'''Note:''' We encourage more than one tester per level.

{| border="1"
|-
! Level
! Name
! Contact Email
| P5 Project Tested (include URL is possible)
! Specify Schema Tested (e.g., rnc or rng)
! Schematron Tested (e.g., Yes or No)
! Feedback
|-
| Level 1
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 1 Schema and Schematron Feedback]]
|-
| Level 2
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 2 Schema and Schematron Feedback]]
|-
| Level 3
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 3 Schema and Schematron Feedback]]
|-
| Level 4
| Michelle Dalmau, Name 2, etc.
| mdalmau@indiana.edu, Email 2, etc.
| [http://www.dlib.indiana.edu/collections/vwwp/ VWWP], Project 2, etc.
| rng, Schema(s) 2, etc.
| Yes, Yes/No 2, etc.
| [[Level 4 Schema and Schematron Feedback]]

|}

==Thank You!==

Thanks in advance for your willingness to review both the prose documentation and the schemas/schematron for the Best Practices for TEI in Libraries. This undertaking has been a work in progress for a few years and we look forward to officially releasing it to the public.

Feedback on the Best Practices for TEI in Libraries ODD Documentation and Schemas

2011-05-20T17:03:09Z

Melanieschlosser:

[[Category:SIG:Libraries|!]]

==Overview==

The Best Practices for TEI in Libraries are now captured in a series of ODD files that generate both the prose documentation for encoding levels 1-5 and the schemas for encoding levels 1-4 that conform to '''TEI P5'''. Before we can officially "release" the Best Practices, we need to undergo a round of systematic testing to make sure nothing was lost in translation from our original TEI wiki documentation to the ODDs. We have established a two-pronged testing approach:

* Review and compare the prose documentation with the original wiki documentation to make sure nothing is amiss.
* Test the RelaxNG and Schematron schemas against content from TEI P5 projects to see whether the expressed constraints match the prose documentation and whether they unduly constrain content that a project thinks conforms to a particular encoding level.

We are soliciting volunteers to help with both endeavors. We especially welcome "fresh eyes" to help us with testing and we would especially like to see '''multiple people testing the same levels''' to make sure we receive comprehensive feedback if possible.

Our goal is to have testing complete by '''May 1, 2011'''

==Prong 1: Review/Compare Prose Documentation==

In reviewing and comparing the prose documentation, we ask that you pay special attention to the following:

* Missing or altered prose
* Missing or altered markup examples
* Additional prose or examples not found in the original wiki documentation

We are still wotking on styling/rendering/display issues in the HTML output. However, please do feel
free to comment on rendering issues you may encounter. This will make sure we don't take any of it for granted.

===Links to Review/Compare Prose Documentation===

* Prose Documentation for Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_1:_Fully_Automated_Conversion_and_Encoding Wiki documentation]
* Prose Documentation for Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_2:_Minimal_Encoding Wiki documentation]
* Prose Documentation for Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_3:_Simple_Analysis Wiki documentation]
* Prose Documentation for Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_4:_Basic_Content_Analysis Wiki documentation]
* Prose Documentation for Level 5
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html#index.xml-body.1_div.4_div.2_div.5 ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_5:_Scholarly_Encoding_Projects Wiki documentation]
* Prose Documentation for Front and Back Matter (e.g., Introduction, Appendices, etc.)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html ODD documentation] (sections 1-4 (except 4.2), 5-7)
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries Wiki documentation] (sections 1-5, 7-10)

===Suggested Steps to Follow for Review===

# Select a section of the documentation to review and sign-up (see below)
# Read the ODD-generated documentation for the selected section
# Peruse corresponding section in the wiki version of the documentation
# Document any differences or problems encountered on wiki pages linked in table below

===Sign-Up for Review of Prose Documentation===

'''Note:''' We encourage more than one reviewer per level.

{| border="1"
|-
! Level
! Name
! Contact Email
! Feedback
|-
| Level 1
| Melanie Schlosser, Name 2, etc.
| melanie.schlosser@gmail.com, Email 2, etc.
| [[Level 1 Prose Documentation Feedback]]
|-
| Level 2
| Melanie Schlosser, Name 2, etc.
| melanie.schlosser@gmail.com, Email 2, etc.
| [[Level 2 Prose Documentation Feedback]]
|-
| Level 3
| Melanie Schlosser, Name 2, etc.
| melanie.schlosser@gmail.com, Email 2, etc.
| [[Level 3 Prose Documentation Feedback]]
|-
| Level 4
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 4 Prose Documentation Feedback]]
|-
| Level 5
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 5 Prose Documentation Feedback]]
|-
| Front Matter (e.g., Introduction)
| Melanie Schlosser, Name 2, etc.
| melanieschlosser@gmail.com, Email 2, etc.
| [[Front Matter Documentation Feedback]]
|-
| Back Matter (e.g., Appendices)
| Melanie Schlosser, Name 2, etc.
| melanieschlosser@gmail.com, Email 2, etc.
| [[Back Matter Documentation Feedback]]
|}

==Prong 2: Test Levels 1-4 Schemas and Schematron==

In testing the schemas and schematron for levels 1-4, we ask that you pay special attention to the following:

* Aspects that do not validate and why (perhaps your local project isn't conformant or we overlooked a markup practice that should be reflected in the "Best Practices")

We expect schema and schematron validation to be more experimental. We are more concerned with validation errors than a perfectly valid document, but please do tell us if your project happens to validate.

'''Please note that these Best Practices and schemas conform to TEI version P5. Please make sure you are testing the right version of the TEI. Thanks!'''

===Download Schemas (RelaxNG) and Schematron===

You have the option of downloading the compact (.rnc) or regular (.rng) RelaxNG schema for each of the levels. Testing both is not required, but please
do let us know which schema you used.

* Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rnc Compact Syntax Closed Schema for Level 1] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rng XML Syntax Closed Schema for Level 1] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.isosch ISO Schematron Level 1] (.isosch)
* Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rnc Compact Syntax Closed Schema for Level 2] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rng XML Syntax Closed Schema for Level 2] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.isosch ISO Schematron Level 2] (.isosch)
* Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rnc Compact Syntax Closed Schema for Level 3] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rng XML Syntax Closed Schema for Level 3] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.isosch ISO Schematron Level 3] (.isosch)
* Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rnc Compact Syntax Closed Schema for Level 4] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rng XML Syntax Closed Schema for Level 4] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.isosch ISO Schematron Level 4] (.isosch)

===Schema and Schematron Setup===

Since TEI workflows and XML editors vary, we will not provide specific instructions on how to set up schema validation. We assume
you will plug in the Best Practices schema into your own workflow/software environments.

We assume the same is true for schematron validation, but will provide a scenario if you use the Oxygen XML editor:

* Make sure the TEI/XML file or files you are checking are open in Oxygen (run the schematron on one file or against multiple files assigned to a project)
* Click on the little downward-pointing error on the Validate icon (the red checkmark)
* Select "Validate with ..."
* Select the "Schematron Schema" tab and browse for the Best Practices schematron (.isosch) file you downloaded for testing
* Select "OK"

The schematron will run against your TEI file and generate a list of errors or warnings in the "Errors" pane of the Oxygen editor (similar to errors generated
when validating against the schema).

===Sign-Up for Schema/Schematron Testing===

'''Note:''' We encourage more than one tester per level.

{| border="1"
|-
! Level
! Name
! Contact Email
| P5 Project Tested (include URL is possible)
! Specify Schema Tested (e.g., rnc or rng)
! Schematron Tested (e.g., Yes or No)
! Feedback
|-
| Level 1
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 1 Schema and Schematron Feedback]]
|-
| Level 2
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 2 Schema and Schematron Feedback]]
|-
| Level 3
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 3 Schema and Schematron Feedback]]
|-
| Level 4
| Michelle Dalmau, Name 2, etc.
| mdalmau@indiana.edu, Email 2, etc.
| [http://www.dlib.indiana.edu/collections/vwwp/ VWWP], Project 2, etc.
| rng, Schema(s) 2, etc.
| Yes, Yes/No 2, etc.
| [[Level 4 Schema and Schematron Feedback]]

|}

==Thank You!==

Thanks in advance for your willingness to review both the prose documentation and the schemas/schematron for the Best Practices for TEI in Libraries. This undertaking has been a work in progress for a few years and we look forward to officially releasing it to the public.

Level 2 Prose Documentation Feedback

2011-05-20T17:01:16Z

Melanieschlosser:

>>Return to testing instructions: [[Feedback_on_the_Best_Practices_for_TEI_in_Libraries_ODD_Documentation_and_Schemas]]

==Tester: Melanie Schlosser==

'''Comments/Feedback'''

* Extra sentence in the ODD file under 'Reference': "Note that this is a ‘syntactically conformant’ customization, in that documents that are valid against this scheme will also be valid against the TEI_all schema. However, it is unkown whether or not it is truly ‘TEI conformant’, as the TEI Guidelines do not make clear whether or not encoding of individual paragraphs is mandatory."
* Example 1: Same comment about the Header element as in level 1.
* Example 1: The child elements of the optional 'front' element are missing.
* Example 1: Information missing from 'back' illustration: "organized like <front>, with 1 or more <div> or <div1>,each with a single <ab>"
* I didn't look at anything on the ODD after the 2nd example.

==Tester: Enter Your Name==

'''Comments/Feedback'''

* List feedback, problems encountered, etc. in bulleted list form. Provide detailed examples please so that we may make corrections more easily.
* Feedback
* Feedback

==Tester: Enter Your Name==

'''Comments/Feedback'''

* List feedback, problems encountered, etc. in bulleted list form. Provide detailed examples please so that we may make corrections more easily.
* Feedback
* Feedback

Feedback on the Best Practices for TEI in Libraries ODD Documentation and Schemas

2011-05-20T15:42:36Z

Melanieschlosser:

[[Category:SIG:Libraries|!]]

==Overview==

The Best Practices for TEI in Libraries are now captured in a series of ODD files that generate both the prose documentation for encoding levels 1-5 and the schemas for encoding levels 1-4 that conform to '''TEI P5'''. Before we can officially "release" the Best Practices, we need to undergo a round of systematic testing to make sure nothing was lost in translation from our original TEI wiki documentation to the ODDs. We have established a two-pronged testing approach:

* Review and compare the prose documentation with the original wiki documentation to make sure nothing is amiss.
* Test the RelaxNG and Schematron schemas against content from TEI P5 projects to see whether the expressed constraints match the prose documentation and whether they unduly constrain content that a project thinks conforms to a particular encoding level.

We are soliciting volunteers to help with both endeavors. We especially welcome "fresh eyes" to help us with testing and we would especially like to see '''multiple people testing the same levels''' to make sure we receive comprehensive feedback if possible.

Our goal is to have testing complete by '''May 1, 2011'''

==Prong 1: Review/Compare Prose Documentation==

In reviewing and comparing the prose documentation, we ask that you pay special attention to the following:

* Missing or altered prose
* Missing or altered markup examples
* Additional prose or examples not found in the original wiki documentation

We are still wotking on styling/rendering/display issues in the HTML output. However, please do feel
free to comment on rendering issues you may encounter. This will make sure we don't take any of it for granted.

===Links to Review/Compare Prose Documentation===

* Prose Documentation for Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_1:_Fully_Automated_Conversion_and_Encoding Wiki documentation]
* Prose Documentation for Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_2:_Minimal_Encoding Wiki documentation]
* Prose Documentation for Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_3:_Simple_Analysis Wiki documentation]
* Prose Documentation for Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_4:_Basic_Content_Analysis Wiki documentation]
* Prose Documentation for Level 5
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html#index.xml-body.1_div.4_div.2_div.5 ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_5:_Scholarly_Encoding_Projects Wiki documentation]
* Prose Documentation for Front and Back Matter (e.g., Introduction, Appendices, etc.)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html ODD documentation] (sections 1-4 (except 4.2), 5-7)
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries Wiki documentation] (sections 1-5, 7-10)

===Suggested Steps to Follow for Review===

# Select a section of the documentation to review and sign-up (see below)
# Read the ODD-generated documentation for the selected section
# Peruse corresponding section in the wiki version of the documentation
# Document any differences or problems encountered on wiki pages linked in table below

===Sign-Up for Review of Prose Documentation===

'''Note:''' We encourage more than one reviewer per level.

{| border="1"
|-
! Level
! Name
! Contact Email
! Feedback
|-
| Level 1
| Melanie Schlosser, Name 2, etc.
| melanie.schlosser@gmail.com, Email 2, etc.
| [[Level 1 Prose Documentation Feedback]]
|-
| Level 2
| Melanie Schlosser, Name 2, etc.
| melanie.schlosser@gmail.com, Email 2, etc.
| [[Level 2 Prose Documentation Feedback]]
|-
| Level 3
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 3 Prose Documentation Feedback]]
|-
| Level 4
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 4 Prose Documentation Feedback]]
|-
| Level 5
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 5 Prose Documentation Feedback]]
|-
| Front Matter (e.g., Introduction)
| Melanie Schlosser, Name 2, etc.
| melanieschlosser@gmail.com, Email 2, etc.
| [[Front Matter Documentation Feedback]]
|-
| Back Matter (e.g., Appendices)
| Melanie Schlosser, Name 2, etc.
| melanieschlosser@gmail.com, Email 2, etc.
| [[Back Matter Documentation Feedback]]
|}

==Prong 2: Test Levels 1-4 Schemas and Schematron==

In testing the schemas and schematron for levels 1-4, we ask that you pay special attention to the following:

* Aspects that do not validate and why (perhaps your local project isn't conformant or we overlooked a markup practice that should be reflected in the "Best Practices")

We expect schema and schematron validation to be more experimental. We are more concerned with validation errors than a perfectly valid document, but please do tell us if your project happens to validate.

'''Please note that these Best Practices and schemas conform to TEI version P5. Please make sure you are testing the right version of the TEI. Thanks!'''

===Download Schemas (RelaxNG) and Schematron===

You have the option of downloading the compact (.rnc) or regular (.rng) RelaxNG schema for each of the levels. Testing both is not required, but please
do let us know which schema you used.

* Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rnc Compact Syntax Closed Schema for Level 1] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rng XML Syntax Closed Schema for Level 1] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.isosch ISO Schematron Level 1] (.isosch)
* Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rnc Compact Syntax Closed Schema for Level 2] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rng XML Syntax Closed Schema for Level 2] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.isosch ISO Schematron Level 2] (.isosch)
* Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rnc Compact Syntax Closed Schema for Level 3] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rng XML Syntax Closed Schema for Level 3] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.isosch ISO Schematron Level 3] (.isosch)
* Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rnc Compact Syntax Closed Schema for Level 4] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rng XML Syntax Closed Schema for Level 4] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.isosch ISO Schematron Level 4] (.isosch)

===Schema and Schematron Setup===

Since TEI workflows and XML editors vary, we will not provide specific instructions on how to set up schema validation. We assume
you will plug in the Best Practices schema into your own workflow/software environments.

We assume the same is true for schematron validation, but will provide a scenario if you use the Oxygen XML editor:

* Make sure the TEI/XML file or files you are checking are open in Oxygen (run the schematron on one file or against multiple files assigned to a project)
* Click on the little downward-pointing error on the Validate icon (the red checkmark)
* Select "Validate with ..."
* Select the "Schematron Schema" tab and browse for the Best Practices schematron (.isosch) file you downloaded for testing
* Select "OK"

The schematron will run against your TEI file and generate a list of errors or warnings in the "Errors" pane of the Oxygen editor (similar to errors generated
when validating against the schema).

===Sign-Up for Schema/Schematron Testing===

'''Note:''' We encourage more than one tester per level.

{| border="1"
|-
! Level
! Name
! Contact Email
| P5 Project Tested (include URL is possible)
! Specify Schema Tested (e.g., rnc or rng)
! Schematron Tested (e.g., Yes or No)
! Feedback
|-
| Level 1
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 1 Schema and Schematron Feedback]]
|-
| Level 2
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 2 Schema and Schematron Feedback]]
|-
| Level 3
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 3 Schema and Schematron Feedback]]
|-
| Level 4
| Michelle Dalmau, Name 2, etc.
| mdalmau@indiana.edu, Email 2, etc.
| [http://www.dlib.indiana.edu/collections/vwwp/ VWWP], Project 2, etc.
| rng, Schema(s) 2, etc.
| Yes, Yes/No 2, etc.
| [[Level 4 Schema and Schematron Feedback]]

|}

==Thank You!==

Thanks in advance for your willingness to review both the prose documentation and the schemas/schematron for the Best Practices for TEI in Libraries. This undertaking has been a work in progress for a few years and we look forward to officially releasing it to the public.

Level 1 Prose Documentation Feedback

2011-05-20T15:41:45Z

Melanieschlosser:

>>Return to testing instructions: [[Feedback_on_the_Best_Practices_for_TEI_in_Libraries_ODD_Documentation_and_Schemas]]

==Tester: Melanie Schlosser==

'''Comments/Feedback'''

* The ODD version has the additional sentence "Note that this is not a ‘TEI conformant’ customization, because it does not follow the TEI abstract model. However, this is a ‘syntactically conformant’ customization, in that documents that are valid against this scheme will also be valid against the TEI_all schema."
* In the bulleted list under 'Rationale': "one desires to keep open the option for a higher level of encoding to be added at a later da" - the 'te' is missing from 'date'
* Same in both versions, but typo. Under 'Workflow'" "Page images are tagged using software that assigns a page-level metadata..." Remove 'a'.
* Under the example, the ODD version has additional sentence "Note that for technical reasons the namespace is not shown in these examples, but it should always be supplied on the root TEI element, e.g.: <TEI xmlns="http://www.tei-c.org/ns/1.0">" and the namespace attribute has been removed from the example.
* ODD version example is missing the comment "". Instead, it has a self-closing header element. In fact, there are no comments in the example. It either needs the comments added back in, or the note about comments taken out.
* I didn't look at anything in the ODD after the example.

==Tester: Enter Your Name==

'''Comments/Feedback'''

* List feedback, problems encountered, etc. in bulleted list form. Provide detailed examples please so that we may make corrections more easily.
* Feedback
* Feedback

==Tester: Enter Your Name==

'''Comments/Feedback'''

* List feedback, problems encountered, etc. in bulleted list form. Provide detailed examples please so that we may make corrections more easily.
* Feedback
* Feedback

Feedback on the Best Practices for TEI in Libraries ODD Documentation and Schemas

2011-05-20T15:26:28Z

Melanieschlosser:

[[Category:SIG:Libraries|!]]

==Overview==

The Best Practices for TEI in Libraries are now captured in a series of ODD files that generate both the prose documentation for encoding levels 1-5 and the schemas for encoding levels 1-4 that conform to '''TEI P5'''. Before we can officially "release" the Best Practices, we need to undergo a round of systematic testing to make sure nothing was lost in translation from our original TEI wiki documentation to the ODDs. We have established a two-pronged testing approach:

* Review and compare the prose documentation with the original wiki documentation to make sure nothing is amiss.
* Test the RelaxNG and Schematron schemas against content from TEI P5 projects to see whether the expressed constraints match the prose documentation and whether they unduly constrain content that a project thinks conforms to a particular encoding level.

We are soliciting volunteers to help with both endeavors. We especially welcome "fresh eyes" to help us with testing and we would especially like to see '''multiple people testing the same levels''' to make sure we receive comprehensive feedback if possible.

Our goal is to have testing complete by '''May 1, 2011'''

==Prong 1: Review/Compare Prose Documentation==

In reviewing and comparing the prose documentation, we ask that you pay special attention to the following:

* Missing or altered prose
* Missing or altered markup examples
* Additional prose or examples not found in the original wiki documentation

We are still wotking on styling/rendering/display issues in the HTML output. However, please do feel
free to comment on rendering issues you may encounter. This will make sure we don't take any of it for granted.

===Links to Review/Compare Prose Documentation===

* Prose Documentation for Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_1:_Fully_Automated_Conversion_and_Encoding Wiki documentation]
* Prose Documentation for Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_2:_Minimal_Encoding Wiki documentation]
* Prose Documentation for Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_3:_Simple_Analysis Wiki documentation]
* Prose Documentation for Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_4:_Basic_Content_Analysis Wiki documentation]
* Prose Documentation for Level 5
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html#index.xml-body.1_div.4_div.2_div.5 ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_5:_Scholarly_Encoding_Projects Wiki documentation]
* Prose Documentation for Front and Back Matter (e.g., Introduction, Appendices, etc.)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html ODD documentation] (sections 1-4 (except 4.2), 5-7)
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries Wiki documentation] (sections 1-5, 7-10)

===Suggested Steps to Follow for Review===

# Select a section of the documentation to review and sign-up (see below)
# Read the ODD-generated documentation for the selected section
# Peruse corresponding section in the wiki version of the documentation
# Document any differences or problems encountered on wiki pages linked in table below

===Sign-Up for Review of Prose Documentation===

'''Note:''' We encourage more than one reviewer per level.

{| border="1"
|-
! Level
! Name
! Contact Email
! Feedback
|-
| Level 1
| Melanie Schlosser, Name 2, etc.
| melanie.schlosser@gmail.com, Email 2, etc.
| [[Level 1 Prose Documentation Feedback]]
|-
| Level 2
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 2 Prose Documentation Feedback]]
|-
| Level 3
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 3 Prose Documentation Feedback]]
|-
| Level 4
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 4 Prose Documentation Feedback]]
|-
| Level 5
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 5 Prose Documentation Feedback]]
|-
| Front Matter (e.g., Introduction)
| Melanie Schlosser, Name 2, etc.
| melanieschlosser@gmail.com, Email 2, etc.
| [[Front Matter Documentation Feedback]]
|-
| Back Matter (e.g., Appendices)
| Melanie Schlosser, Name 2, etc.
| melanieschlosser@gmail.com, Email 2, etc.
| [[Back Matter Documentation Feedback]]
|}

==Prong 2: Test Levels 1-4 Schemas and Schematron==

In testing the schemas and schematron for levels 1-4, we ask that you pay special attention to the following:

* Aspects that do not validate and why (perhaps your local project isn't conformant or we overlooked a markup practice that should be reflected in the "Best Practices")

We expect schema and schematron validation to be more experimental. We are more concerned with validation errors than a perfectly valid document, but please do tell us if your project happens to validate.

'''Please note that these Best Practices and schemas conform to TEI version P5. Please make sure you are testing the right version of the TEI. Thanks!'''

===Download Schemas (RelaxNG) and Schematron===

You have the option of downloading the compact (.rnc) or regular (.rng) RelaxNG schema for each of the levels. Testing both is not required, but please
do let us know which schema you used.

* Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rnc Compact Syntax Closed Schema for Level 1] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rng XML Syntax Closed Schema for Level 1] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.isosch ISO Schematron Level 1] (.isosch)
* Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rnc Compact Syntax Closed Schema for Level 2] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rng XML Syntax Closed Schema for Level 2] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.isosch ISO Schematron Level 2] (.isosch)
* Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rnc Compact Syntax Closed Schema for Level 3] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rng XML Syntax Closed Schema for Level 3] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.isosch ISO Schematron Level 3] (.isosch)
* Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rnc Compact Syntax Closed Schema for Level 4] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rng XML Syntax Closed Schema for Level 4] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.isosch ISO Schematron Level 4] (.isosch)

===Schema and Schematron Setup===

Since TEI workflows and XML editors vary, we will not provide specific instructions on how to set up schema validation. We assume
you will plug in the Best Practices schema into your own workflow/software environments.

We assume the same is true for schematron validation, but will provide a scenario if you use the Oxygen XML editor:

* Make sure the TEI/XML file or files you are checking are open in Oxygen (run the schematron on one file or against multiple files assigned to a project)
* Click on the little downward-pointing error on the Validate icon (the red checkmark)
* Select "Validate with ..."
* Select the "Schematron Schema" tab and browse for the Best Practices schematron (.isosch) file you downloaded for testing
* Select "OK"

The schematron will run against your TEI file and generate a list of errors or warnings in the "Errors" pane of the Oxygen editor (similar to errors generated
when validating against the schema).

===Sign-Up for Schema/Schematron Testing===

'''Note:''' We encourage more than one tester per level.

{| border="1"
|-
! Level
! Name
! Contact Email
| P5 Project Tested (include URL is possible)
! Specify Schema Tested (e.g., rnc or rng)
! Schematron Tested (e.g., Yes or No)
! Feedback
|-
| Level 1
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 1 Schema and Schematron Feedback]]
|-
| Level 2
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 2 Schema and Schematron Feedback]]
|-
| Level 3
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 3 Schema and Schematron Feedback]]
|-
| Level 4
| Michelle Dalmau, Name 2, etc.
| mdalmau@indiana.edu, Email 2, etc.
| [http://www.dlib.indiana.edu/collections/vwwp/ VWWP], Project 2, etc.
| rng, Schema(s) 2, etc.
| Yes, Yes/No 2, etc.
| [[Level 4 Schema and Schematron Feedback]]

|}

==Thank You!==

Thanks in advance for your willingness to review both the prose documentation and the schemas/schematron for the Best Practices for TEI in Libraries. This undertaking has been a work in progress for a few years and we look forward to officially releasing it to the public.

Back Matter Documentation Feedback

2011-03-17T15:10:23Z

Melanieschlosser: /* Tester: Enter Your Name */

>>Return to testing instructions: [[Feedback_on_the_Best_Practices_for_TEI_in_Libraries_ODD_Documentation_and_Schemas]]

==Tester: Melanie Schlosser==

'''Comments/Feedback'''

* The back matter looks fine - I didn't notice any problems.

==Tester: Enter Your Name==

'''Comments/Feedback'''

* List feedback, problems encountered, etc. in bulleted list form. Provide detailed examples please so that we may make corrections more easily.
* Feedback
* Feedback

==Tester: Enter Your Name==

'''Comments/Feedback'''

* List feedback, problems encountered, etc. in bulleted list form. Provide detailed examples please so that we may make corrections more easily.
* Feedback
* Feedback

Front Matter Documentation Feedback

2011-03-16T20:57:46Z

Melanieschlosser: /* Tester: Enter Your Name */

>>Return to testing instructions: [[Feedback_on_the_Best_Practices_for_TEI_in_Libraries_ODD_Documentation_and_Schemas]]

==Tester: Melanie Schlosser==

'''Comments/Feedback'''

* In the ODD HTML file, sections 4.1 and 4.1.8 are missing their section headers, which messes up the ToC. The title for 4.1 is, presumably, "The TEI Header," but I couldn't figure out what the title for 4.1.8 is supposed to be. The content in that section isn't in the wiki documentation.
* Formatting/rendition issues in the ODD HTML
** Quotation marks in examples sometimes display incorrectly. Sometimes they are rendered as a vertical bar (Example: 3.2.1.), and sometimes they cause a new paragraph to start (Example: 4.1.2)
** Missing paragraph breaks. This happens most often in the table with the element and attribute recommendations, but it also happens all through sections 4.1.3-4.1.5.
** Table formatting
*** The tables don't have borders between cells, which would make them easier to read
*** Almost all of the text formatting inside the table cells is wonky, including paragraph breaks, lists, and more. The first good example is in the element recommendations table under <title type=" ">
* In the Introduction, the table that briefly describes the encoding levels is somewhat confusing - mostly because of the third column ("Example of encoding of Alger Hiss document"). This isn't explained previously, and the links in that column take you to page images, not markup. A couple sentences explaining what that column is would be helpful.
* These are the same in the wiki documentation, but I found a few instances of typos or unclear wording:
** Section 2 (Relationship to TEI Tite): At the end of the first sentence, 'organization' should be 'organizations.'
** In the second paragraph of that same section, it talks about "mass digitization of born-digital source documents." What does that mean?
** In section 4.1.1 (Reference), in the first sentence, "It is just one specification group that is used be each of the..." Huh?

==Tester: Enter Your Name==

'''Comments/Feedback'''

* List feedback, problems encountered, etc. in bulleted list form. Provide detailed examples please so that we may make corrections more easily.
* Feedback
* Feedback

==Tester: Enter Your Name==

'''Comments/Feedback'''

* List feedback, problems encountered, etc. in bulleted list form. Provide detailed examples please so that we may make corrections more easily.
* Feedback
* Feedback

Feedback on the Best Practices for TEI in Libraries ODD Documentation and Schemas

2011-03-11T14:33:05Z

Melanieschlosser: /* Sign-Up for Review of Prose Documentation */

[[Category:SIG:Libraries|!]]

==Overview==

The Best Practices for TEI in Libraries are now captured in a series of ODD files that generate both the prose documentation for encoding levels 1-5 and the schemas for encoding levels 1-4 that conform to '''TEI P5'''. Before we can officially "release" the Best Practices, we need to undergo a round of systematic testing to make sure nothing was lost in translation from our original TEI wiki documentation to the ODDs. We have established a two-pronged testing approach:

* Review and compare the prose documentation with the original wiki documentation to make sure nothing is amiss.
* Test the RelaxNG and Schematron schemas against content from TEI P5 projects to see whether the expressed constraints match the prose documentation and whether they unduly constrain content that a project thinks conforms to a particular encoding level.

We are soliciting volunteers to help with both endeavors. We especially welcome "fresh eyes" to help us with testing and we would especially like to see '''multiple people testing the same levels''' to make sure we receive comprehensive feedback if possible.

Our goal is to have testing complete by '''May 1, 2011'''

==Prong 1: Review/Compare Prose Documentation==

In reviewing and comparing the prose documentation, we ask that you pay special attention to the following:

* Missing or altered prose
* Missing or altered markup examples
* Additional prose or examples not found in the original wiki documentation

We are still wotking on styling/rendering/display issues in the HTML output. However, please do feel
free to comment on rendering issues you may encounter. This will make sure we don't take any of it for granted.

===Links to Review/Compare Prose Documentation===

* Prose Documentation for Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_1:_Fully_Automated_Conversion_and_Encoding Wiki documentation]
* Prose Documentation for Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_2:_Minimal_Encoding Wiki documentation]
* Prose Documentation for Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_3:_Simple_Analysis Wiki documentation]
* Prose Documentation for Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_4:_Basic_Content_Analysis Wiki documentation]
* Prose Documentation for Level 5
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html#index.xml-body.1_div.4_div.2_div.5 ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_5:_Scholarly_Encoding_Projects Wiki documentation]
* Prose Documentation for Front and Back Matter (e.g., Introduction, Appendices, etc.)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html ODD documentation] (sections 1-4, 5-7)
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries Wiki documentation] (sections 1-5, 7-10)

===Suggested Steps to Follow for Review===

# Select a section of the documentation to review and sign-up (see below)
# Read the ODD-generated documentation for the selected section
# Peruse corresponding section in the wiki version of the documentation
# Document any differences or problems encountered on wiki pages linked in table below

===Sign-Up for Review of Prose Documentation===

'''Note:''' We encourage more than one reviewer per level.

{| border="1"
|-
! Level
! Name
! Contact Email
! Feedback
|-
| Level 1
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 1 Prose Documentation Feedback]]
|-
| Level 2
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 2 Prose Documentation Feedback]]
|-
| Level 3
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 3 Prose Documentation Feedback]]
|-
| Level 4
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 4 Prose Documentation Feedback]]
|-
| Level 5
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 5 Prose Documentation Feedback]]
|-
| Front Matter (e.g., Introduction)
| Melanie Schlosser, Name 2, etc.
| melanieschlosser@gmail.com, Email 2, etc.
| [[Front Matter Documentation Feedback]]
|-
| Back Matter (e.g., Appendices)
| Melanie Schlosser, Name 2, etc.
| melanieschlosser@gmail.com, Email 2, etc.
| [[Back Matter Documentation Feedback]]
|}

==Prong 2: Test Levels 1-4 Schemas and Schematron==

In testing the schemas and schematron for levels 1-4, we ask that you pay special attention to the following:

* Aspects that do not validate and why (perhaps your local project isn't conformant or we overlooked a markup practice that should be reflected in the "Best Practices")

We expect schema and schematron validation to be more experimental. We are more concerned with validation errors than a perfectly valid document, but please do tell us if your project happens to validate.

'''Please note that these Best Practices and schemas conform to TEI version P5. Please make sure you are testing the right version of the TEI. Thanks!'''

===Download Schemas (RelaxNG) and Schematron===

You have the option of downloading the compact (.rnc) or regular (.rng) RelaxNG schema for each of the levels. Testing both is not required, but please
do let us know which schema you used.

* Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rnc Compact Syntax Closed Schema for Level 1] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rng XML Syntax Closed Schema for Level 1] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.isosch ISO Schematron Level 1] (.isosch)
* Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rnc Compact Syntax Closed Schema for Level 2] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rng XML Syntax Closed Schema for Level 2] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.isosch ISO Schematron Level 2] (.isosch)
* Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rnc Compact Syntax Closed Schema for Level 3] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rng XML Syntax Closed Schema for Level 3] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.isosch ISO Schematron Level 3] (.isosch)
* Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rnc Compact Syntax Closed Schema for Level 4] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rng XML Syntax Closed Schema for Level 4] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.isosch ISO Schematron Level 4] (.isosch)

===Schema and Schematron Setup===

Since TEI workflows and XML editors vary, we will not provide specific instructions on how to set up schema validation. We assume
you will plug in the Best Practices schema into your own workflow/software environments.

We assume the same is true for schematron validation, but will provide a scenario if you use the Oxygen XML editor:

* Make sure the TEI/XML file or files you are checking are open in Oxygen (run the schematron on one file or against multiple files assigned to a project)
* Click on the little downward-pointing error on the Validate icon (the red checkmark)
* Select "Validate with ..."
* Select the "Schematron Schema" tab and browse for the Best Practices schematron (.isosch) file you downloaded for testing
* Select "OK"

The schematron will run against your TEI file and generate a list of errors or warnings in the "Errors" pane of the Oxygen editor (similar to errors generated
when validating against the schema).

===Sign-Up for Schema/Schematron Testing===

'''Note:''' We encourage more than one tester per level.

{| border="1"
|-
! Level
! Name
! Contact Email
| P5 Project Tested (include URL is possible)
! Specify Schema Tested (e.g., rnc or rng)
! Schematron Tested (e.g., Yes or No)
! Feedback
|-
| Level 1
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 1 Schema and Schematron Feedback]]
|-
| Level 2
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 2 Schema and Schematron Feedback]]
|-
| Level 3
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 3 Schema and Schematron Feedback]]
|-
| Level 4
| Michelle Dalmau, Name 2, etc.
| mdalmau@indiana.edu, Email 2, etc.
| [http://www.dlib.indiana.edu/collections/vwwp/ VWWP], Project 2, etc.
| rng, Schema(s) 2, etc.
| Yes, Yes/No 2, etc.
| [[Level 4 Schema and Schematron Feedback]]

|}

==Thank You!==

Thanks in advance for your willingness to review both the prose documentation and the schemas/schematron for the Best Practices for TEI in Libraries. This undertaking has been a work in progress for a few years and we look forward to officially releasing it to the public.

Feedback on the Best Practices for TEI in Libraries ODD Documentation and Schemas

2011-03-11T14:31:22Z

Melanieschlosser: /* Sign-Up for Review of Prose Documentation */

[[Category:SIG:Libraries|!]]

==Overview==

The Best Practices for TEI in Libraries are now captured in a series of ODD files that generate both the prose documentation for encoding levels 1-5 and the schemas for encoding levels 1-4 that conform to '''TEI P5'''. Before we can officially "release" the Best Practices, we need to undergo a round of systematic testing to make sure nothing was lost in translation from our original TEI wiki documentation to the ODDs. We have established a two-pronged testing approach:

* Review and compare the prose documentation with the original wiki documentation to make sure nothing is amiss.
* Test the RelaxNG and Schematron schemas against content from TEI P5 projects to see whether the expressed constraints match the prose documentation and whether they unduly constrain content that a project thinks conforms to a particular encoding level.

We are soliciting volunteers to help with both endeavors. We especially welcome "fresh eyes" to help us with testing and we would especially like to see '''multiple people testing the same levels''' to make sure we receive comprehensive feedback if possible.

Our goal is to have testing complete by '''May 1, 2011'''

==Prong 1: Review/Compare Prose Documentation==

In reviewing and comparing the prose documentation, we ask that you pay special attention to the following:

* Missing or altered prose
* Missing or altered markup examples
* Additional prose or examples not found in the original wiki documentation

We are still wotking on styling/rendering/display issues in the HTML output. However, please do feel
free to comment on rendering issues you may encounter. This will make sure we don't take any of it for granted.

===Links to Review/Compare Prose Documentation===

* Prose Documentation for Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_1:_Fully_Automated_Conversion_and_Encoding Wiki documentation]
* Prose Documentation for Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_2:_Minimal_Encoding Wiki documentation]
* Prose Documentation for Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_3:_Simple_Analysis Wiki documentation]
* Prose Documentation for Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.doc.html ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_4:_Basic_Content_Analysis Wiki documentation]
* Prose Documentation for Level 5
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html#index.xml-body.1_div.4_div.2_div.5 ODD documentation]
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries#LEVEL_5:_Scholarly_Encoding_Projects Wiki documentation]
* Prose Documentation for Front and Back Matter (e.g., Introduction, Appendices, etc.)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/main-driver.html ODD documentation] (sections 1-4, 5-7)
** [http://wiki.tei-c.org/index.php/Best_Practices_for_TEI_in_Libraries Wiki documentation] (sections 1-5, 7-10)

===Suggested Steps to Follow for Review===

# Select a section of the documentation to review and sign-up (see below)
# Read the ODD-generated documentation for the selected section
# Peruse corresponding section in the wiki version of the documentation
# Document any differences or problems encountered on wiki pages linked in table below

===Sign-Up for Review of Prose Documentation===

'''Note:''' We encourage more than one reviewer per level.

{| border="1"
|-
! Level
! Name
! Contact Email
! Feedback
|-
| Level 1
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 1 Prose Documentation Feedback]]
|-
| Level 2
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 2 Prose Documentation Feedback]]
|-
| Level 3
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 3 Prose Documentation Feedback]]
|-
| Level 4
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 4 Prose Documentation Feedback]]
|-
| Level 5
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| [[Level 5 Prose Documentation Feedback]]
|-
| Front Matter (e.g., Introduction)
| Melanie Schlosser, Name 2, etc.
| Email 1, Email 2, etc.
| [[Front Matter Documentation Feedback]]
|-
| Back Matter (e.g., Appendices)
| Melanie Schlosser, Name 2, etc.
| Email 1, Email 2, etc.
| [[Back Matter Documentation Feedback]]
|}

==Prong 2: Test Levels 1-4 Schemas and Schematron==

In testing the schemas and schematron for levels 1-4, we ask that you pay special attention to the following:

* Aspects that do not validate and why (perhaps your local project isn't conformant or we overlooked a markup practice that should be reflected in the "Best Practices")

We expect schema and schematron validation to be more experimental. We are more concerned with validation errors than a perfectly valid document, but please do tell us if your project happens to validate.

'''Please note that these Best Practices and schemas conform to TEI version P5. Please make sure you are testing the right version of the TEI. Thanks!'''

===Download Schemas (RelaxNG) and Schematron===

You have the option of downloading the compact (.rnc) or regular (.rng) RelaxNG schema for each of the levels. Testing both is not required, but please
do let us know which schema you used.

* Level 1
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rnc Compact Syntax Closed Schema for Level 1] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.rng XML Syntax Closed Schema for Level 1] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib1.isosch ISO Schematron Level 1] (.isosch)
* Level 2
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rnc Compact Syntax Closed Schema for Level 2] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.rng XML Syntax Closed Schema for Level 2] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib2.isosch ISO Schematron Level 2] (.isosch)
* Level 3
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rnc Compact Syntax Closed Schema for Level 3] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.rng XML Syntax Closed Schema for Level 3] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib3.isosch ISO Schematron Level 3] (.isosch)
* Level 4
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rnc Compact Syntax Closed Schema for Level 4] (.rnc)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.rng XML Syntax Closed Schema for Level 4] (.rng)
** [http://tei.wwp.brown.edu/~syd/temp/TEI-Library-SIG/BestPractices/lib4.isosch ISO Schematron Level 4] (.isosch)

===Schema and Schematron Setup===

Since TEI workflows and XML editors vary, we will not provide specific instructions on how to set up schema validation. We assume
you will plug in the Best Practices schema into your own workflow/software environments.

We assume the same is true for schematron validation, but will provide a scenario if you use the Oxygen XML editor:

* Make sure the TEI/XML file or files you are checking are open in Oxygen (run the schematron on one file or against multiple files assigned to a project)
* Click on the little downward-pointing error on the Validate icon (the red checkmark)
* Select "Validate with ..."
* Select the "Schematron Schema" tab and browse for the Best Practices schematron (.isosch) file you downloaded for testing
* Select "OK"

The schematron will run against your TEI file and generate a list of errors or warnings in the "Errors" pane of the Oxygen editor (similar to errors generated
when validating against the schema).

===Sign-Up for Schema/Schematron Testing===

'''Note:''' We encourage more than one tester per level.

{| border="1"
|-
! Level
! Name
! Contact Email
| P5 Project Tested (include URL is possible)
! Specify Schema Tested (e.g., rnc or rng)
! Schematron Tested (e.g., Yes or No)
! Feedback
|-
| Level 1
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 1 Schema and Schematron Feedback]]
|-
| Level 2
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 2 Schema and Schematron Feedback]]
|-
| Level 3
| Name 1, Name 2, etc.
| Email 1, Email 2, etc.
| Project 1, Project 2, etc.
| Schema(s) 1, Schema(s) 2, etc.
| Yes/No 1, Yes/No 2, etc.
| [[Level 3 Schema and Schematron Feedback]]
|-
| Level 4
| Michelle Dalmau, Name 2, etc.
| mdalmau@indiana.edu, Email 2, etc.
| [http://www.dlib.indiana.edu/collections/vwwp/ VWWP], Project 2, etc.
| rng, Schema(s) 2, etc.
| Yes, Yes/No 2, etc.
| [[Level 4 Schema and Schematron Feedback]]

|}

==Thank You!==

Thanks in advance for your willingness to review both the prose documentation and the schemas/schematron for the Best Practices for TEI in Libraries. This undertaking has been a work in progress for a few years and we look forward to officially releasing it to the public.

Best Practices for TEI in Libraries

2008-09-22T14:01:03Z

Melanieschlosser: TEI Header recommendations

[http://www.tei-c.org/wiki/index.php/SIG:Libraries TEI in Libraries: Home]

==Introduction and History==
<p>The Text Encoding Initiative Guidelines for Electronic Text Encoding and Interchange (referred to as
the <i>TEI Guidelines</i>) were first published in 1994 and represent a tremendous
achievement in electronic text standards by providing a highly sophisticated structure for encoding
electronic text. Digital librarians have benefited greatly from the standardization provided by these
guidelines, and the potential for interoperability and long-term preservation of digital collections
facilitated by their wide adoption.</p>

<p>In 1998, the Digital Library Federation (DLF) sponsored the [http://www.lib.umich.edu/lit/dlps/history/teidlf/index.html TEI and XML in Digital Libraries Workshop] at the
Library of Congress to discuss the use of the <i>TEI Guidelines</i> in libraries for electronic text,
and to create a set of best practices for librarians implementing them. From this workshop, three working
groups were formed the members of which represented some of the largest and most mature digital library
programs in the U.S. Group 2 was charged with developing a set of recommendations for libraries using the
TEI Guidelines in electronic text encoding. This group included the following representatives from six libraries:
</p>
<ul>
<li>LeeEllen Friedland, Library of Congress</li>
<li>Nancy Kushigian, University of California, Davis</li>
<li>Christina Powell, University of Michigan</li>
<li>David Seaman, University of Virginia</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>At the ALA mid-winter (January 1999), the DLF task force revised a draft set of best practices, called
TEI Text Encoding in Libraries: Guidelines for Best Practices (referred to as <i>TEI in Libraries
Guidelines</i>). The revised recommendations were circulated to the conference working group in May
1999 and presented at the joint annual meeting of the Association of Computers and the Humanities and
Association of Literary and Linguistic Computing in June 1999. [http://www.diglib.org/standards/tei-old.htm Version 1.0] was circulated for comments in
August 1999. These guidelines were endorsed by the DLF, and have been used by many digital libraries,
including those of the task force members, as a model for their own local best practices. Libraries,
museums and end-users have benefitted from a set of best practices for electronic text in a number of
ways, including better interoperability between electronic text collections, better documented practices
among digital libraries, and a starting point for discussion of best practices with commercial publishers
regarding electronic text creation.</p>

<p>Written in 1998, this first iteration of <i>TEI in Libraries Guidelines</i> made no mention of XML,
XSLT, or any of the other powerful tools that have now become common parlance and practice in creating
digital documents and collections. Based on these important changes in markup technology, it came to the
attention of the DLF and members of the original Task Force that the <i>TEI in Libraries Guidelines</i>
required substantial revision. In 2002, the TEI Consortium published a new edition of the complete
<i>TEI Guidelines</i> that conformed to XML specifications. In order to remain useful, the <i>TEI in
Libraries Guidelines</i> had to be updated to reflect these developments.</p>

<p>Furthermore, librarians need more guidance than the original <i>TEI in Libraries Guidelines</i>
provided. There are many library-specific encoding issues which need to be addressed and documented to
ensure consistency. The intention of this document is to provide recommended paths of encoding for these
issues.</p>

<p>In addition, these library guidelines have the potential to be much more useful if they can serve as a
training document from which librarians can learn about text encoding and addressing particular encoding
challenges. To fulfill this role, the guidelines require more examples and detailed explanations,
giving documentation of the use of TEI in a library context. Librarians also need a set of standards
and best practices for vendors and publishers who create electronic text for digital libraries, so that
these collections adhere to the same archival standards as locally-created electronic text collections.
With detailed guidelines that could serve as an encoding specification, librarians might encourage
vendors to follow the principles in these standards, to facilitate the long-term preservation of
commercially published electronic text collections, and more readily allow for cross-collection
searching.</p>

<p>In order to facilitate the evolution of this document, another DLF-sponsored Task Force—some
of the representatives of which were on the original Task Force—met on October 24-25, 2003 at
the Cosmos Club in Washington, D.C.: </p>
<ul>
<li>Richard Gartner, Oxford University Library</li>
<li>Matthew Gibson, University of Virginia Library</li>
<li>Kirk Hastings, California Digital Library</li>
<li>Christina Powell, University of Michigan</li>
<li>Merrilee Proffitt, RLG</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>These representatives met to revise the original <i>TEI in Libraries Guidelines</i> in order
that they: </p>
<ul>
<li>reflect changes occuring within the text encoding world generally and within the TEI
community specifically</li>
<li>further illuminate the different levels of encoding by offering clearer and more robust
examples.</li>
</ul>
<p>After producing [http://www.diglib.org/standards/tei2/tei20.htm Version 2.0] of the Guidelines, this group (with some changes in membership) met again
at the Cosmos Club on February 13-14, 2006. Those in attendance were: </p>
<ul>
<li>Syd Bauman, The TEI Consortium</li>
<li>Richard Gartner, Oxford University Library (by phone)</li>
<li>Matthew Gibson, Virginia Foundation for the Humanities (chair)</li>
<li>Merrilee Proffitt, RLG</li>
<li>Chris Powell, The University of Michigan</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natasha Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, The University of Michigan</li>
</ul>
<p>This group of continues to meet and based upon their discussions and resolutions, the following
guidelines will continue to be updated and enhanced.</p>

==General Overview and Comments==

<p>These recommendations are for libraries using the XML version of the TEILite DTD (teixlite).
There are many different library text digitization projects, for different purposes. With this in mind,
the Task Force has attempted to make these recommendations as inclusive as possible by developing a
series of encoding levels. These levels are meant to allow for a range of practice, from wholly automated
text creation and encoding, to encoding that requires expert content knowledge, analysis, and editing.</p>

<p>Recommendations for Levels 1-4 are intended for projects wishing to create encoded electronic text with
structural markup, but minimal semantic or content markup. Also, the encoding levels are cumulative:
encoding requirements at each level incorporate the requirements of lower levels. Levels 1-4 allow the
conversion and encoding of texts to be performed without the assistance of deep content knowledge and can
be enriched with more markup at any time. Level 5, in contrast, requires scholarly analysis. </p>

<p>These recommendations are concerned with the text portion of a TEI-encoded document. While there are
modest requirements for including certain information about encoding level in the TEI header, a separate
set of recommendations, now integrated into this document, was developed to address issues concerning TEI header
contents to MARC-format bibliographic data (see the [[#The TEI Header (based on June 16, 2001 Draft)|<teiHeader> section]]).</p>

==General Recommendations==

<p>Note: all recommendations that follow are based on P4:2004, with the exception of the facs= attribute of <pb>, which comes from the P5 module for the transcription of primary sources ('transcr').</p>

<ul>
<li>The encoding level (as described in this document) should be recorded in the
<editorialDecl> in the TEI header, along with an explanation of any deviation from the
recommendations.</li>

<li>Electronic text at all levels of encoding should begin with the transcription of the first word on
the first leaf of the original work. It may be impractical or undesirable to transcribe and encode
certain features of the text, such as publisher's advertisements or indexes, but if at all possible,
they should be included as links to page images. Any omissions of material found in the original work
should be noted in the <editorialDecl> in the TEI header.</li>
<li>File naming should follow ISO 9660 conventions: 8-character filenames, 3-character extensions,
using A-Z, a-z, 0-9, underscores and hyphens. The rationale behind this suggestion is that when moving
texts across different platforms (DOS for instance), some systems will truncate beyond the eighth
character.</li>
<li>We recommend the use of numbered divisions throughout the electronic text, always beginning with
<div1> (we prefer that <div0> not be used since the TEI Guidelines does not
make it available in <front> or <back> matter). Numbered divisions present
advantages to search and indexing software by explicitly communicating the hierarchical level of the
section described. Texts at all levels should include at least one <div1>.</li>
<li>Page breaks should be encoded using the <pb> element,
which should demark the top of a page (i.e. the text of page
seven should immediately follow <pb n="7"/>), and should
always be contained within a division. E.g., a page break that
occurs between chapters 2 and 3 should be encoded near the top
of the <div> that holds chapter 3 (rather than near the bottom
of the <div> that holds chapter 2).</li>
</ul>

==The TEI Header==

===Introduction===
<p>At the TEI and XML in Digital Libraries Workshop that was held at the Library of Congress in July 1998, several working groups
were formed to consider various aspects of the Text Encoding Initiative. Group 1 was charged to recommend some best practices
for TEI header content and to review the relationship between the Text Encoding Initiative header and MARC. To this end,
representatives of the University of Virginia Library and the University of Michigan Library gathered in Ann Arbor in early
October 1998 to develop a recommended practice guide. This work was assisted by similar efforts that had taken place in the United
Kingdom under the auspices of the Oxford Text Archive the previous year.
The following document represents a draft of those recommended practices. It has been submitted to various constituencies for
comment.</p>

===Working Assumptions===
<p>A TEI header can serve many publics. Headers can be created in a text center and reflect the center's standards, or they can
serve as the basis for other types of metadata system records produced by other agencies. Headers can function in detached
form as records in a catalog, as a title page inherent to the document, or as a source for index displays.</p>

<p>In addition, a header may describe a collection of documents, a single item, or a portion of an item. Variances in TEI header
content can result from making different choices of what is being described.</p>

<p>A TEI header may not have a one to one correspondence with a MARC record. One TEI header may have multiple MARC analytic records,
or one MARC record may be used to describe a collection of TEI documents with individual headers.</p>

<p>A TEI header serves several purposes. It may contain an historical background on how the file has been treated. It can extend the
information of a classic catalog record. The Text Center and/or cataloging agency can act as the gatekeeper for creators by
providing standards for content.</p>

===Cataloging a TEI Document===

<p>Does the TEI header act as the electronic title page or as a catalog record? Is it integral to the document it describes or
independent? Depending on the community being served, the TEI elements will reflect the interest of that community. Nonetheless,
it is possible to describe a set of "best practices" that will produce compatible content while accommodating this variety of
purposes. Compatibility of content encourages a more understandable set of results when information about assorted items is
displayed as a set of search results, a contents list, or an index, and it allows for more reasonable conversion of content
information from TEI elements to elements of other metadata sets when this action seems advisable.</p>

<p>It is a traditional practice of librarianship to agree upon where in a document and in what order of preference one should look
to identify the title, author, etc., of that document. This permits a certain consistency in terminology and allows for a certain
amount of authentication of content. We recommend the following preferences to those who create headers and to those who attempt
to use headers to create traditional catalog records that are compliant with AACR2 and ISBD(ER) rules.</p>

<p>As a member of the academic community, the header creator/editor has a responsibility to verify, whenever humanly possible, the
intellectual source for an electronic document that presents itself without any information regarding its source or authorship.</p>

====Chief Sources of Information for Several Types of Electronic Resources Are:====
<ul> <li>1. For an electronic document with a digitized title page (without a header), prefer
<ul>
<li>a) Chief source of information = information coded as title page</li>
<li>b) Use added information from an originating paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>2. Electronic document with header (without a title page)
<ul>
<li>a) Chief source of information = supplied and verified header <ref name="verify">Verified means that the cataloger/editor has established for him/herself that the information represented as title information is an accurate representation of content.</ref></li>

<li>b) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>

<li>3. Electronic document with header and title page
<ul>
<li>a) Chief source of information = supplied header (if verified)<ref name="verify"/></li>
<li>b) If header is not verified, use title page as chief source</li>
<li>c) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>4. If neither header nor title page is present and there is no evidence of a source document, the header creator
<ul>
<li>a) May assign a title and author if appropriate</li>
<li>b) Enclose the information in brackets, using the standard English language convention for editorial interjections</li>
</ul>
</li>
<li>5. If neither header nor title page is present but the header creator has satisfactory evidence of an originating source, that
document should be used as the chief source of information for the title and author of the header. If the source cannot be fully
verified as to edition, authorship, etc., this fact should be clearly indicated in a note in the <fileDesc>.
</li>

</ul>

===Element Recommendations for the <teiHeader>===

<table border="1" width="80%">
<tr>
<td colspan="1"><teiHeader type="____"></td>
<td colspan="1">
Standards which apply to the header, e.g., <teiHeader type="ISBD(ER)">, <teiHeader
type="AACR2">
</td>
</tr>
</table>

===<fileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<title type="____"></td>
<td colspan="1">
Only uniform title and main title for the TEI document, not the source document, should be entered here, e.g., <title type="uniform"> or <title type="main">. See <sourceDesc> for other title forms for documents where a user might seek the documents under titles other than those assigned. Where a title is supplied, the title should be enclosed in square brackets using standard English-language conventions for editorial insertion.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of original source (electronic or print) should be entered into the <author> element before the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.
</td>
</tr>

<tr>
<td colspan="1">
<editor></td>
<td colspan="1">
Editor of original source (electronic or print) should be entered into the <editor> element <b>before</b> the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.</td>

</tr>

<tr>
<td colspan="1">
<respStmt></td>
<td colspan="1">
The editor (also compiler, illustrator) of the TEI document, not the source document, should be entered here. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<editionStmt></td>

<td colspan="1">
This element should be used sparingly as there are currently no standards as to when versions become editions. Users should refer to the TEI guidelines.</td>
</tr>

<tr>
<td colspan="1">

<extent></td>
<td colspan="1">
Use the standard text "ca.**** kilobytes".</td>
</tr>

<tr>
<td colspan="1">

<publicationStmt></td>
<td colspan="1">
Use the child elements below rather than <p> for a prose description.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
The publisher is whoever has collected the TEI document, not the source document, and has made decisions concerning it.</td>
</tr>

<tr>

<td colspan="1">

<distributor></td>
<td colspan="1">
The distributor is whoever makes the TEI document, not the source document, available.</td>
</tr>

<tr>
<td colspan="1">
<idno></td>
<td colspan="1">
Any unique identification number determined by the publisher. Use type="OCLC-___" to point to the catalog record for the TEI document, if applicable. The institution's three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<availability status="___"><p></td>
<td colspan="1">
Describe any rights statement for the TEI document. Use a standard scheme, such as the code for a Creative Commonse license, for the value of the status attribute if possible.</td>
</tr>

<tr>
<td colspan="1">
<date></td>
<td colspan="1">
Refers to the date of the first publication of the TEI document. <b>For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.</b></td>
</tr>

<tr>
<td colspan="1">
<seriesStmt><title></td>

<td colspan="1">
Whenever possible, establish or use the name from a national name authority file authorized for the electronic, locally created series.
</td>
</tr>

<tr>
<td colspan="1">
<notesStmt></td>

<td colspan="1">
Optional, for indicating questionable attributions for title, author, etc.</td>

</tr>

<tr>
<td colspan="1">
<sourceDesc></td>
<td colspan="1">
In order to effectively represent the source(s) when many documents are represented by the TEI header, we see the need for structured elements that minimally allow us to identify parent-child and component relationships. In the absence of these structures, we suggest that multiple source descriptions be employed with relationships described in free text. Relationships also could be useful in other portions of the TEI header. Cataloger may need to do research to establish the original source.</td>
</tr>

<tr>

<td colspan="1">
<bibl> or
<biblFull></td>
<td colspan="1">
Use <bibl> with child elements listed below. metadata for the source document is automatically generated from a MARC record. It is suggested that child elements appear in the following order for ease of display according to ISBD: <author>, <title type="245a">, <title type="245b">, <respStmt>, <edition>, <pubPlace>, <publisher>, <date>, <extent>, <title type="series">, <note>, <idno type="isbn-13">, <idno type="isbn-10">, <idno type="OCLC-___">. Use <biblFull> for exhaustive description created by hand. </td>

</tr>

<tr>
<td colspan="1">
<title></td>
<td colspan="1">
Title of the source document. It is possible to have multiple <title> elements. Alternative titles (cover, running, spine titles) should be entered in separate <title> elements in <biblFull>.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of the source document. It is possible to have multiple <author> elements. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">

<editor></td>
<td colspan="1">
Editor of the source document. It is possible to have multiple <editor> elements.</td>
</tr>

<tr>
<td colspan="1">

<respStmt></td>
<td colspan="1">
If using <bibl> and generating from a MARC record, use this for the statement of responsibility (MARC field 245, subfield c).</td>
</tr>

<tr>
<td colspan="1">

<editionStmt></td>
<td colspan="1">
Edition statement in the source document (if present).</td>
</tr>

<tr>
<td colspan="1">
<extent></td>

<td colspan="1">
Enter physical description for the original source. If using <bibl> and generating from a MARC record, use this for MARC field 300.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
Don't repeat field. Enter multiple publishers divided by semicolons.</td></tr>

<tr>
<td colspan="1">
<pubPlace></td>
<td colspan="1">

Don't repeat field. Enter multiple publication places divided by semicolons.</td>
</tr>

<tr>
<td colspan="1">
<date></td>

<td colspan="1">
Imprint date for the original source. '''For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.'''</td>
</tr>

<tr>

<td colspan="1">
<idno></td>
<td colspan="1">
In this location, <idno> refers to identification numbers for the source document. They can be used to indicate the source's location in an individual institution's collection. If a formal standard location system is being used, indicate the nature of the system, e.g., <idno type="LC call number">. If using <bibl> and generating from a MARC record, use type="isbn-13" and type=-"isbn-10" if applicable. Use type="LC call number" (or appropriate abbreviation) for a call number. Use type="OCLC-___" to point to the catalog record for the source document. The institution’s three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<seriesStmt> or <series></td>

<td colspan="1">
Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<notes></td>

<td colspan="1">
Notes about the source document. If using <bibl> and generating from a MARC record, use for the value of MARC field 500.</td>
</tr>
</table>

===<encodingDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<projectDesc></td>
<td colspan="1">Enter a description of the purpose for which the electronic file was encoded.</td>
</tr>

<tr>
<td colspan="1">
<editorialDecl></td>
<td colspan="1">
Enter general and specific statements about how the electronic file has been treated. Record here editorial decisions made
during encoding.</td>

</tr>

<tr>
<td colspan="1">
<refsDecl></td>
<td colspan="1">
<refsDecl> could be used for administrative metadata, e.g., pagination and page sequencing.</td>
</tr>

<tr>

<td colspan="1">

<classDecl> <taxonomy id="____"> <bibl></td>
<td colspan="1">
If used, identify the appropriate taxonomy definitions or descriptive sources in the <taxonomy> element followed by id, e.g.,
<taxonomy id="LCSH"> <bibl>Library of Congress Subject Headings</bibl> </taxonomy>, <taxonomy id="AAT"> <bibl> Art & Architecture Theasaurus</bibl> </taxonomy>.</td>
</tr>
</table>

===<profileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">

<langUsage> <language id="____"></td>
<td colspan="1">
Use the ISO 639-2 standard (which is the same as the MARC language codes) for the id attribute. The content of the element should be the name of the language given in ISO 639-2.</td>

</tr>

<tr>
<td colspan="1">
<classCode scheme="___"></td>
<td colspan="1">
True classification numbers as opposed to call numbers can be entered here.</td>

</tr>

<tr>
<td colspan="1">
<keywords><br />

<term>
</td>
<td colspan="1">
Use for uncontrolled terms.</td>
</tr>

<tr>
<td colspan="1">
<keywords scheme="____"><br />
<term>
</td>
<td colspan="1">
Use for controlled vocabulary as specified in <encodingDesc> taxonomy id. Example: scheme="LCSH"</td>

</tr>
</table>

===<revisionDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<change>
</td>
<td colspan="1">
Create a <change> element to record each significant change to the TEI document.</td>

</tr>

<tr>
<td colspan="1">
<date>
</td>
<td colspan="1">
The date of the change in ISO 8601 form (YYYY-MM-DD).</td>

</tr>

<tr>
<td colspan="1">
<respStmt> <name>
</td>
<td colspan="1">
Initials or other identifying information about the person or process making the change.</td>

</tr>

<tr>
<td colspan="1">
<item>
</td>
<td colspan="1">
Prose description of the change.</td>

</tr>
</table>

===Minimal TEI Header Recommendation===
<blockquote>
<div class="indent"><teiHeader></div>
<div class="lindent"><fileDesc></div>

<div class="lindent2"><titleStmt></div>
<div class="lindent3"><title></title></div>
<div class="lindent3"><author></author></div>
<div class="lindent2"></titleStmt>

</div>
<div class="lindent2"><publicationStmt>
</div>
<div class="lindent3"><publisher></publisher>

</div>
<div class="lindent3"><pubPlace></pubPlace>
</div>
<div class="lindent3"><idno></idno>
</div>
<div class="lindent3"><availability><p></p></availability>
</div>
<div class="lindent3"><date></date>

</div>
<div class="lindent2"></publicationStmt>

</div>
<div class="lindent2"><sourceDesc>
</div>
<div class="lindent3"><biblFull>
</div>
<div class="lindent4"><titleStmt>
</div>
<div class="lindent5"><title></title>

</div>
<div class="lindent5"><author></author>
</div>
<div class="lindent4"></titleStmt>
</div>
<div class="lindent4"><publicationStmt>
</div>
<div class="lindent5"><publisher></publisher>
</div>
<div class="lindent5"><pubPlace></pubPlace>

</div>
<div class="lindent5"><date></date>
</div>
<div class="lindent4"></publicationStmt>
</div>
<div class="lindent3"></biblFull>
</div>
<div class="lindent2"></sourceDesc>
</div>
<div class="lindent"></fileDesc>
</div>

<div class="indent"></teiHeader>
</div>
</blockquote>

Repeat the <biblFull> field, as appropriate, if there is more than one source for the electronic item. [http://www.diglib.org/standards/teiheaders.html See some examples in context …]

===Recommended Additions to the teixlite DTD===
<ul>
<li>Add elements under <name> to allow for the variable ordering and alphabetization of names:
<forename>, <surname>, <birthdate>, <deathdate>, <title>, etc.</li>

<li>In order to effectively represent the source(s) when many documents are
represented by the TEI header, we see the need for structured elements that, minimally,
allow us to identify parent-child and component relationships.</li>
</ul>

===Acknowledgments and Bibliography===
<ul>
<li>
This guide was prepared by Judy Ahronheim, Thomas Champagne, Lynn Marko, Kelly Webster, and Chris Wilcox of the University of
Michigan Library and Jackie Shieh of the University of Virginia Library in October 1998. The source documents were the cataloging
guides prepared by those two institutions ([http://www.lib.virginia.edu/cataloging/manual/chapters/chapxiib.html Virginia] and [http://www.lib.umich.edu/ts/sections/electronicresourcesdev.html Michigan]). In addition,
documentation from the Oxford Text Archive, Arts and Humanities Data Service of the United Kingdom also was made available to assist
in this effort.

</li>

</ul>

==Encoding Levels==
===LEVEL 1: Fully Automated Conversion and Encoding===

'''Purpose''': To create electronic text with the primary purpose of keyword searching and linking to page images. The primary advantage in using the teixlite DTD at this level is that a TEI header is attached to the text file.

<p>
'''Rationale''': The text is subordinate to the page image, and is not intended to
stand alone as an electronic text (without page images).</p>

<p>Texts at Level 1 can be created and encoded by fully automated means, using uncorrected OCR of page
images ("dirty OCR"), exporting from existing electronic text files, or actually not including any text
at all. Only those elements that are necessary to divide the text from the header and facilitate linking to
page images are used. Encoding is performed automatically based on artifacts of the OCR or other
document creation process (page breaks, for example) and metadata collected during the imaging or
preparation process. This encoding is both minimal and reliable, and does not typically require
extensive review of each page of each text.</p>

<p>Level 1 texts are not intended to be adequate for textual analysis; they are more likely to be suited
to the goals of a preservation unit or mass digitization initiative. Though their encoding is minimal,
Level 1 texts are fully valid XML texts. In addition to taking advantage of the TEI header, using the
teixlite DTD--with the consistency suggested by these guidelines--allows Level 1 texts to be compatible
with more richly encoded teixlite texts (that also follow these guidelines) for
searching, for example. Further encoding based on document structures or content analysis can be added
to a Level 1 text at any time.</p>

<p>
'''Level 1 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>a large volume of material is to be made available online quickly</li>
<li>a digital image of each page is desired</li>
<li>no manual intervention will be performed in the text creation process</li>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>sophisticated search and display capabilities based on the structure of the text are not necessary</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<table border="1" width="80%">
<tr>
<td colspan="1"><div1></td>
<td colspan="1">If no type= attribute is specified, a type= value of
"section" should be presumed.</td>
</tr>

<tr>
<td colspan="1"><p></td>
<td colspan="1">At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using <p> in order that the document be open to being extended to other encoding levels).</td>
</tr>
<tr>

<td colspan="1"><pb></td>
<td colspan="1">Required in Level 1. Page images can be linked to the text by specifying a jpeg or other image file as the value of the facs= attribute. Page numbers can be supplied with the n= attribute to record the number that is on the page. The Task Force sees the use of METS here as having a tremendous advantage. METS/TEI page turning documentation will be included in the near future.</td>
</tr>
</table>

====Basic Structural Example:====
<pre>
<TEI.2 id="someid">
<teiHeader>
[Source and processing information goes here]
</teiHeader>
<text>
<body>
<div1>
<p>
<pb id="p00000001" n="1"/>
[main body of the unmarked up plain text begins here]
<pb id="p00000002" n="2"/>
[more plain text goes here with appropriate page breaks interspersed] ...
<pb id="p00000145" n="145"/>
[more plain text]
<pb id="p00000146" n="146"/>
[text ends here]
</p>
</div1>
</body>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level1example.html See an example in context…]

===LEVEL 2: Minimal Encoding===
'''Purpose''': To create electronic text for full-text searching, linking to page images, and identifying simple structural hierarchy to improve navigation.

'''Rationale''': The text is subordinate to the page image, though navigational markers (textual divisions, headings) are captured. The text could stand alone as electronic text (without page images) if the accuracy of its contents is suitable to its intended use and it is not necessary to display low-level typographic or structural information. Level 2 requires a set of elements more granular than those of Level 1, including bibliographic or structural information below the monographic or volume level.

Though texts at Level 2 can be created and encoded by automated means, based on the typographic elements in the electronic file (for example, bold centered text at the top of the page surrounded by whitespace indicates a new chapter heading, and thus a new division), it is not likely to be absolutely reliable across a large body of material. Level 2 encoding requires some human intervention to identify each textual division and heading. Level 2 texts do not require any special knowledge or manual intervention below the section level.

Level 2 texts are not intended to be displayed separately from their page images. Level 2 encoding of sections and headings provides greater navigational possibilities than Level 1 encoding, and enables searching to be restricted within particular textual divisions (for example, searching for two phrases within the same chapter).

'''Level 2 is most suitable for projects with the following characteristics''':

* a large volume of material is to be made available online quickly
* a digital image of each page is desired
* the material is of interest to a large community of users who wish to read texts that allow keyword searching
* rudimentary search and display capabilities based on the large structures of the text are desired
* each text will be checked to ensure that divisions and headers are properly identified
* extensibility is desired; that is, one desires to keep open the option for a higher level of encoding to be added at a later date

All elements specified in Level 1 plus the following:

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>
<td colspan="1">Optional</td>
</tr>
<tr>
<td colspan="1"><div1></td>
<td colspan="1">type="section" is the default attribute value. It is recommended that the n= attribute be
included to record the sequence of divisions.</td>
</tr>
<tr>
<td colspan="1"><head></td>
<td colspan="1">Required if present</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">One "container" element per div is required.</td>
</tr>
</table>

====Basic Structural Example:====

<pre>
<TEI.2 id="someid">
<teiHeader> [Source and processing information goes here] </teiHeader>
<text id="someotherid">
<front> [titlepage information, table of contents, prefaces, etc.] </front>
<body>
<div1 type="chapter" n="1">
<head>Chapter 1</head>
<p>[text of Chapter 1 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="2">
<head>Chapter 2</head>
<p>[text of Chapter 2 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="3">
<head>Chapter 3</head> [text of Chapter 3 goes here interspersed with <pb> elements
pointing to page images] </div1>
<div1 type="chapter" n="4">
<head>Chapter 4</head> [text of Chapter 4 goes here interspersed with <pb> elements
pointing to page images] </div1>
</body>
<back> [optional text of backmatter, appendices, etc.] </back>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level2example.html See an example in context…]

===LEVEL 3: Simple Analysis===

<p>
'''Purpose''': To create text that can stand alone as electronic text and identifies
hierarchy and typography without content analysis being of primary importance.</p>

<p>
'''Rationale''': Level 3 texts can be created from scratch or by the relatively easy
conversion of existing HTML or word-processing documents. Encoding offers the advantage of the TEI
header, interoperability with other TEI collections, and extensibility to higher levels of encoding.
Level 3 generally requires some human editing, but the features to be encoded are determined by the
appearance of the text and not specialized content analysis.</p>

<p>Level 3 texts identify front and back matter, and all paragraph breaks. The finer granularity of
encoding these features, as well as figures, notes, and all changes of typography, allows a range of
options for display, delivery, and searching. For example, one has the option of identifying and,
therefore, specifying the display charactersitics of different typographic styles, and regularizing the
display and placement of note text.</p>

<p>Level 3 texts can stand alone as text without page images and, therefore, can be uploaded, downloaded
and delivered quickly, and require less storage space than digital collections with page images.
However, the simple level of structural anaylsis and absence of specialized content analysis reflected
in Level 3 encoding may make it desirable for some, depending on project priorities, to include page
images in order to provide users with a fuller set of resources.</p>

<p>
'''Level 3 is most suitable for projects with the following characteristics:'''
</p>

<ul>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>some sophistication of display, delivery, and searching based on structure of the text is desired</li>
<li>each text will be checked to ensure that encoding decisions have been made appropriately</li>
<li>the users of the texts may have limited storage or display capabilities</li>
<li>the creator of the texts has limited or no ability to provide content expertise to analyze, tag,
or review texts</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<p>All elements specified in Levels 1 and 2, plus the following:</p>

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>

<td colspan="1">Required if present.</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">Required for paragraph breaks in prose; may be used for stanzas using <lb> for
line breaks in verse.</td>
</tr>

<tr>
<td colspan="1"><list> and <item></td>
<td colspan="1">May be used in this level to indicate ordered and unordered list structures.</td>
</tr>
<tr>
<td colspan="1"><table>, <row>, and <cell></td>

<td colspan="1">May be used to indicate table structures.</td>
</tr>
<tr>
<td colspan="1"><figure></td>
<td colspan="1">Required to indicate figures other than page images.</td>
</tr>
<tr>

<td colspan="1"><hi></td>
<td colspan="1">Required to indicate changes in typeface; rend attribute is optional.</td>
</tr>
<tr>
<td colspan="1"><note></td>
<td colspan="1">All notes must be encoded. It is also recommended that notes that extend beyond one page be combined into one <note> element. Marginal notes, without reference, should occur at the beginning of the paragraph to which they refer, with the value of the place attribute as "margin".</td>

</tr>
<tr>
<td colspan="1"><lb></td>
<td colspan="1">May be used to force line breaks.</td>
</tr>
</table>

<p>NOTE ON <note>:</p>

<p>It may be desirable to move footnotes from their original location in the text. If left at the bottom
of a page, a note may become included in another paragraph or section of the encoded text, and thus
separated from its reference. There are options for placement of footnotes if they are moved:</p>

<ul>
<li>Inline. The note is inserted at the point of reference. An n attribute records the value of the
note reference if there is one.</li>
<li>End-of-Division. Notes moved to the end of the division</li>
</ul>

<p>

'''Basic Structural Example forthcoming ...'''
</p>

===LEVEL 4: Basic Content Analysis===
<p>'''Purpose''': To create text that can stand alone as electronic text, identifies
hierarchy and typography, specifies function of textual and structural elements, and describes the
nature of the content and not merely its appearance. This level is not meant to encode or identify all
structural, semantic or bibliographic features of the text.</p>

<p>
'''Rationale''': Greater description of function and content allows for:</p>

<ul>
<li>flexibility of display and delivery</li>
<li>sophisticated searching within specified textual and structural elements</li>
<li>combining the broadest range of uses and audiences</li>

</ul>

<p>Texts encoded at Level 4 are able to stand alone as part of a library collection, and do not require
page images in order for them to be read by students, scholars and general readers. This level of TEI
encoding allows them to be displayed or printed in a variety of ways suitable for classroom or scholarly
use.</p>

<p>Level 4 texts contain elements and attributes that describe content. For example, lines of verse are
tagged with <l>; the <p> element is reserved for true paragraphs. Features of
the text that may contribute to meaning, such as indentation of verse lines and typographic change, are
preserved. These are textual features that are not encoded at lower levels and that allow the text to be
used and understood fully independent of images.</p>

<p>The ability to stand alone as text means that Level 4 texts are more nimble and robust for exercises
such as format repurposing and textual analysis.</p>

<p>Finally, functionally accurate encoding in Level 4 texts
allows them to be searched or displayed in sophisticated ways.
For example, a searcher could limit his or her search in a
dramatic text to stage directions or in a verse text to only
first lines. In a politicall tract published by subscription, a
search could be confined to names that appear in lists, thus
limiting a search to names of people who subscribed to a
particular volume. This ability to limit searches becomes more
significant as textbases become larger, and thus is of great
importance to the library community as it attempts to build into
the initial design and implementation of textbases the features
needed to enhance interoperability.</p>

<p>
'''Level 4 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>sophisticated search and retrieval capabilities are desired</li>

<li>the texts will be used for textual analysis</li>
<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added by the scholarly community at a later date</li>
<li>the users of the texts may have limited storage or display capabilities</li>
</ul>

====General Level 4 Recommendations====
<ul>
<li>Typographically distinct text should be encoded as appropriate,
e.g. with <term>, <q>, <gloss>, <mentioned>, <soCalled>, <foreign>,
<title>, or <emph>. Any ambiguous emphasized text should be
encoded as <hi> (e.g. <hi rend="bold">).</li>
<li>It is recommended that the <sic> element be used to
indicate typographic errors, with corrections (if any) noted
as the value of the corr= attribute.</li>
<li><titlePage> should include the verso if present, divided by <pb
n="verso"/>. Tables of contents, errata, subscription lists, "other titles by the same author"
should be included in a separate numbered division, as a <list> with <item>s.
Frontispieces should be encoded as a <figure>, within a separate numbered division and
<p>.</li>
</ul>

[http://www.diglib.org/standards/level4genrec.html See some examples in context…]

====Level 4 Prose====
<ul>
<li>Letters that occur within the text body provide some challenges. It is recommended that quoted
letters that occur as part of a text (and not collections of letters themselves) be encoded within
<q><text><body><div1 type="letter">, with
<opener>, <dateline>, <salute>, <signed>,
<closer> included as appropriate.</li>

<li>Quotations that do not occur inline, but are set off typographically in some way, should be
encoded as <q>.</li>
<li>Notes are to be encoded as described in Level 3.</li>
<li><argument>, <opener>, <epigraph>,
<closer>, <trailer>, <add>, <del>,
<unclear> as appropriate.</li>

</ul>

[http://www.diglib.org/standards/level4prose.html See some examples in context…]

====Level 4 Drama====
<ul>
<li>Cast lists should be encoded as <list>s, with <item>s.</li>

<li>Speeches are encoded as <sp>, with speakers identified within
<speaker> elements; stage directions are encoded as <stage> and enclose
block level content describing scenery, etc.</li>
</ul>

[http://www.diglib.org/standards/level4drama.html See some examples in context…]

====Level 4 Oral History====
<ul>
<li>Speakers in interviews can be identified in the <teiHeader> in several ways.
<ul>
<li>In the <profileDesc>, in the <particDesc> in a <list>, with <name> inside of <item>s.</li>

<li>As a list of author <name>s within <fileDesc><titleStmt></li>
</ul>
</li>
<li>In either method, use an id= on the <name> element to uniquely identify the individual participant</li>

<li>Questions and answers from interviewees and interviewers are encoded as <sp>,
with speakers identified within <speaker> elements with a who= attribute the value of which
corresponds to the id= in the list of interview participants.</li>
</ul>
[http://www.diglib.org/standards/level4oh.html See some examples in context…]

====Level 4 Verse====
<ul>
<li>All verse, even poems without separate stanzas or verse paragraphs, should be contained within a
line group element <lg>. This will assist with automated processing and retrieval.</li>
<li>It is common to see informal divisions within poems, noted by a string of asterisks or periods.
These should be encoded as <milestone/>s with attribute values of unit="typography" and
n="()" indicating the character used and its occurrence, <milestone unit="typography"
n="******"/>.</li>
<li><l> It is recommended that indentation be recorded and that the rend attribute be
used to do this.</li>
</ul>
[http://www.diglib.org/standards/level4verse.html See some examples in context…]
====Level 4 Front and Back Matter====
<ul>
<li>It is recommended that all prefaces, tables of contents, afterwords, appendices, endnotes and
apparatus be encoded. For publisher's advertisements, indexes, and glossaries or other front or back
matter that isn't considered of primary importance to the text, there are three options:<ul>
<li>Fully transcribe and encode</li>
<li>Link to page images (may include an unencoded transcription)</li>
<li>Omit, noted in <editorialDesc></li>
</ul>
</li>
</ul>
[http://www.diglib.org/standards/level4fandb.html See some examples in context…]

===LEVEL 5: Scholarly Encoding Projects===

<p>Level 5 texts are those that require subject knowledge, and encode semantic, linguistic, prosodic or
other elements beyond a basic structural level.</p>

==General Guidelines for Attribute Usage==

<p>Some general advice on the use of particular attributes
follows.</p>
<ul>
<li><b>type=</b>: Constructing a list of acceptable attribute values
for type that could find wide agreement is impossible. Instead,
it is recommended that projects describe the type= attribute
values used in their texts in the project ODD file or other
documentation and that this list be made available to people
using the texts. See <i>ABC for Book Collectors</i> by John
Carter (7th edition, New Castle, DE:Oak Knoll Books, 1995) for
a list of standard names and definitions of bibliographic
features of printed books. For those elements where type is not
required, such as <head> and <title>, use the
attribute values for subtitles and additional titles, but not
main titles.<br /> Example: <div1 type="volume"></li>

<li><b>n=</b>: Sometimes an n= (number) attribute can be used by itself. For instance in the case of
pagebreaks:<br /> Example: <pb n="456"/></li>

<li><b>id=</b>: If you are in a situation that requires you to
uniquely identify an element that will be used to reference
another specific location in one or more texts, use an id=
attribute. The value of this attribute must be unique within a
document, and must be composed of alphanumeric characters,
dots, hyphens, and underscores, and must start with a
letter.<br /> Example: <note id="n5" n="5"></li>

<li><b>target=</b>: follows the same syntactic rules as the id=
attribute value. In fact, target= and id= are often used in
conjunction with one another as in the case of footnotes where
the <anchor id="n5" n="5"> is at a specific place in the
text and is referred to by the <note target="n5" n="5">
which contains the actual information of the footnote itself
elsewhere.</li>

<li><b>entity=</b>: The entity= attribute is simply the way a
figure indirectly points or refers to its the actual image
file<br /> Example:
<!ENTITY TwaFifrn SYSTEM "TwaFifrn.jpg" NDATA jpeg><br />
<br />
<figure entity="TwaFifrn"></li>

<li><b>rend=</b>: Difficulty using rend= attributes occurs when it is desirable to record
more than one rendition feature. With this in mind, it is recommended that projects employ the
following adaptation of "rendition ladders", a concept developed at the [http://www.wwp.brown.edu/ Brown University Women Writers Project]. This system allows for sets
of multiple renditional features to be included in one rend= value. Rendition ladders consist of categories of
renditional features with values of each of those features enclosed in parentheses.<br /> rend= should only be
used to override a default value. For instance, if all text encoded as <hi> is defined as being
rendered in italics, there is no reason to encode text as <hi rend="font(italics)"> Combining renditional features would result in a tag with attributes such as <l rend="font(italics)align(right)">
<ul>
<li>font <br />italics, bold, fsc (full and smallcaps), smallcap, underlined, gothic</li>
<li>align <br />right, left, center, block</li>
<li>indent <br />Values in parentheses should indicate the number of tabstops to be indented, e.g.,
<l rend="indent(1)"></li>
</ul>
</li>
<li><b>lang=</b>: Use ISO639-2 three-character language codes. Note that this recommendation is slightly different from that of the TEI P5 Guidelines, which recommends the BCP 47 language codes.</li>
</ul>
References: <references/>
[[Category:SIG:Libraries]]

Best Practices for TEI in Libraries

2008-09-22T13:59:52Z

Melanieschlosser: /* Acknowledgments and Bibliography */

[http://www.tei-c.org/wiki/index.php/SIG:Libraries TEI in Libraries: Home]

==Introduction and History==
<p>The Text Encoding Initiative Guidelines for Electronic Text Encoding and Interchange (referred to as
the <i>TEI Guidelines</i>) were first published in 1994 and represent a tremendous
achievement in electronic text standards by providing a highly sophisticated structure for encoding
electronic text. Digital librarians have benefited greatly from the standardization provided by these
guidelines, and the potential for interoperability and long-term preservation of digital collections
facilitated by their wide adoption.</p>

<p>In 1998, the Digital Library Federation (DLF) sponsored the [http://www.lib.umich.edu/lit/dlps/history/teidlf/index.html TEI and XML in Digital Libraries Workshop] at the
Library of Congress to discuss the use of the <i>TEI Guidelines</i> in libraries for electronic text,
and to create a set of best practices for librarians implementing them. From this workshop, three working
groups were formed the members of which represented some of the largest and most mature digital library
programs in the U.S. Group 2 was charged with developing a set of recommendations for libraries using the
TEI Guidelines in electronic text encoding. This group included the following representatives from six libraries:
</p>
<ul>
<li>LeeEllen Friedland, Library of Congress</li>
<li>Nancy Kushigian, University of California, Davis</li>
<li>Christina Powell, University of Michigan</li>
<li>David Seaman, University of Virginia</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>At the ALA mid-winter (January 1999), the DLF task force revised a draft set of best practices, called
TEI Text Encoding in Libraries: Guidelines for Best Practices (referred to as <i>TEI in Libraries
Guidelines</i>). The revised recommendations were circulated to the conference working group in May
1999 and presented at the joint annual meeting of the Association of Computers and the Humanities and
Association of Literary and Linguistic Computing in June 1999. [http://www.diglib.org/standards/tei-old.htm Version 1.0] was circulated for comments in
August 1999. These guidelines were endorsed by the DLF, and have been used by many digital libraries,
including those of the task force members, as a model for their own local best practices. Libraries,
museums and end-users have benefitted from a set of best practices for electronic text in a number of
ways, including better interoperability between electronic text collections, better documented practices
among digital libraries, and a starting point for discussion of best practices with commercial publishers
regarding electronic text creation.</p>

<p>Written in 1998, this first iteration of <i>TEI in Libraries Guidelines</i> made no mention of XML,
XSLT, or any of the other powerful tools that have now become common parlance and practice in creating
digital documents and collections. Based on these important changes in markup technology, it came to the
attention of the DLF and members of the original Task Force that the <i>TEI in Libraries Guidelines</i>
required substantial revision. In 2002, the TEI Consortium published a new edition of the complete
<i>TEI Guidelines</i> that conformed to XML specifications. In order to remain useful, the <i>TEI in
Libraries Guidelines</i> had to be updated to reflect these developments.</p>

<p>Furthermore, librarians need more guidance than the original <i>TEI in Libraries Guidelines</i>
provided. There are many library-specific encoding issues which need to be addressed and documented to
ensure consistency. The intention of this document is to provide recommended paths of encoding for these
issues.</p>

<p>In addition, these library guidelines have the potential to be much more useful if they can serve as a
training document from which librarians can learn about text encoding and addressing particular encoding
challenges. To fulfill this role, the guidelines require more examples and detailed explanations,
giving documentation of the use of TEI in a library context. Librarians also need a set of standards
and best practices for vendors and publishers who create electronic text for digital libraries, so that
these collections adhere to the same archival standards as locally-created electronic text collections.
With detailed guidelines that could serve as an encoding specification, librarians might encourage
vendors to follow the principles in these standards, to facilitate the long-term preservation of
commercially published electronic text collections, and more readily allow for cross-collection
searching.</p>

<p>In order to facilitate the evolution of this document, another DLF-sponsored Task Force—some
of the representatives of which were on the original Task Force—met on October 24-25, 2003 at
the Cosmos Club in Washington, D.C.: </p>
<ul>
<li>Richard Gartner, Oxford University Library</li>
<li>Matthew Gibson, University of Virginia Library</li>
<li>Kirk Hastings, California Digital Library</li>
<li>Christina Powell, University of Michigan</li>
<li>Merrilee Proffitt, RLG</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>These representatives met to revise the original <i>TEI in Libraries Guidelines</i> in order
that they: </p>
<ul>
<li>reflect changes occuring within the text encoding world generally and within the TEI
community specifically</li>
<li>further illuminate the different levels of encoding by offering clearer and more robust
examples.</li>
</ul>
<p>After producing [http://www.diglib.org/standards/tei2/tei20.htm Version 2.0] of the Guidelines, this group (with some changes in membership) met again
at the Cosmos Club on February 13-14, 2006. Those in attendance were: </p>
<ul>
<li>Syd Bauman, The TEI Consortium</li>
<li>Richard Gartner, Oxford University Library (by phone)</li>
<li>Matthew Gibson, Virginia Foundation for the Humanities (chair)</li>
<li>Merrilee Proffitt, RLG</li>
<li>Chris Powell, The University of Michigan</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natasha Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, The University of Michigan</li>
</ul>
<p>This group of continues to meet and based upon their discussions and resolutions, the following
guidelines will continue to be updated and enhanced.</p>

==General Overview and Comments==

<p>These recommendations are for libraries using the XML version of the TEILite DTD (teixlite).
There are many different library text digitization projects, for different purposes. With this in mind,
the Task Force has attempted to make these recommendations as inclusive as possible by developing a
series of encoding levels. These levels are meant to allow for a range of practice, from wholly automated
text creation and encoding, to encoding that requires expert content knowledge, analysis, and editing.</p>

<p>Recommendations for Levels 1-4 are intended for projects wishing to create encoded electronic text with
structural markup, but minimal semantic or content markup. Also, the encoding levels are cumulative:
encoding requirements at each level incorporate the requirements of lower levels. Levels 1-4 allow the
conversion and encoding of texts to be performed without the assistance of deep content knowledge and can
be enriched with more markup at any time. Level 5, in contrast, requires scholarly analysis. </p>

<p>These recommendations are concerned with the text portion of a TEI-encoded document. While there are
modest requirements for including certain information about encoding level in the TEI header, a separate
set of recommendations, now integrated into this document, was developed to address issues concerning TEI header
contents to MARC-format bibliographic data (see the [[#The TEI Header (based on June 16, 2001 Draft)|<teiHeader> section]]).</p>

==General Recommendations==

<p>Note: all recommendations that follow are based on P4:2004, with the exception of the facs= attribute of <pb>, which comes from the P5 module for the transcription of primary sources ('transcr').</p>

<ul>
<li>The encoding level (as described in this document) should be recorded in the
<editorialDecl> in the TEI header, along with an explanation of any deviation from the
recommendations.</li>

<li>Electronic text at all levels of encoding should begin with the transcription of the first word on
the first leaf of the original work. It may be impractical or undesirable to transcribe and encode
certain features of the text, such as publisher's advertisements or indexes, but if at all possible,
they should be included as links to page images. Any omissions of material found in the original work
should be noted in the <editorialDecl> in the TEI header.</li>
<li>File naming should follow ISO 9660 conventions: 8-character filenames, 3-character extensions,
using A-Z, a-z, 0-9, underscores and hyphens. The rationale behind this suggestion is that when moving
texts across different platforms (DOS for instance), some systems will truncate beyond the eighth
character.</li>
<li>We recommend the use of numbered divisions throughout the electronic text, always beginning with
<div1> (we prefer that <div0> not be used since the TEI Guidelines does not
make it available in <front> or <back> matter). Numbered divisions present
advantages to search and indexing software by explicitly communicating the hierarchical level of the
section described. Texts at all levels should include at least one <div1>.</li>
<li>Page breaks should be encoded using the <pb> element,
which should demark the top of a page (i.e. the text of page
seven should immediately follow <pb n="7"/>), and should
always be contained within a division. E.g., a page break that
occurs between chapters 2 and 3 should be encoded near the top
of the <div> that holds chapter 3 (rather than near the bottom
of the <div> that holds chapter 2).</li>
</ul>

==The TEI Header==

===Introduction===
<p>At the TEI and XML in Digital Libraries Workshop that was held at the Library of Congress in July 1998, several working groups
were formed to consider various aspects of the Text Encoding Initiative. Group 1 was charged to recommend some best practices
for TEI header content and to review the relationship between the Text Encoding Initiative header and MARC. To this end,
representatives of the University of Virginia Library and the University of Michigan Library gathered in Ann Arbor in early
October 1998 to develop a recommended practice guide. This work was assisted by similar efforts that had taken place in the United
Kingdom under the auspices of the Oxford Text Archive the previous year.
The following document represents a draft of those recommended practices. It has been submitted to various constituencies for
comment.</p>

===Working Assumptions===
<p>A TEI header can serve many publics. Headers can be created in a text center and reflect the center's standards, or they can
serve as the basis for other types of metadata system records produced by other agencies. Headers can function in detached
form as records in a catalog, as a title page inherent to the document, or as a source for index displays.</p>

<p>In addition, a header may describe a collection of documents, a single item, or a portion of an item. Variances in TEI header
content can result from making different choices of what is being described.</p>

<p>A TEI header may not have a one to one correspondence with a MARC record. One TEI header may have multiple MARC analytic records,
or one MARC record may be used to describe a collection of TEI documents with individual headers.</p>

<p>A TEI header serves several purposes. It may contain an historical background on how the file has been treated. It can extend the
information of a classic catalog record. The Text Center and/or cataloging agency can act as the gatekeeper for creators by
providing standards for content.</p>

===Cataloging a TEI Document===

<p>Does the TEI header act as the electronic title page or as a catalog record? Is it integral to the document it describes or
independent? Depending on the community being served, the TEI elements will reflect the interest of that community. Nonetheless,
it is possible to describe a set of "best practices" that will produce compatible content while accommodating this variety of
purposes. Compatibility of content encourages a more understandable set of results when information about assorted items is
displayed as a set of search results, a contents list, or an index, and it allows for more reasonable conversion of content
information from TEI elements to elements of other metadata sets when this action seems advisable.</p>

<p>It is a traditional practice of librarianship to agree upon where in a document and in what order of preference one should look
to identify the title, author, etc., of that document. This permits a certain consistency in terminology and allows for a certain
amount of authentication of content. We recommend the following preferences to those who create headers and to those who attempt
to use headers to create traditional catalog records that are compliant with AACR2 and ISBD(ER) rules.</p>

<p>As a member of the academic community, the header creator/editor has a responsibility to verify, whenever humanly possible, the
intellectual source for an electronic document that presents itself without any information regarding its source or authorship.</p>

====Chief Sources of Information for Several Types of Electronic Resources Are:====
<ul> <li>1. For an electronic document with a digitized title page (without a header), prefer
<ul>
<li>a) Chief source of information = information coded as title page</li>
<li>b) Use added information from an originating paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>2. Electronic document with header (without a title page)
<ul>
<li>a) Chief source of information = supplied and verified header <ref name="verify">Verified means that the cataloger/editor has established for him/herself that the information represented as title information is an accurate representation of content.</ref></li>

<li>b) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>

<li>3. Electronic document with header and title page
<ul>
<li>a) Chief source of information = supplied header (if verified)<ref name="verify"/></li>
<li>b) If header is not verified, use title page as chief source</li>
<li>c) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>4. If neither header nor title page is present and there is no evidence of a source document, the header creator
<ul>
<li>a) May assign a title and author if appropriate</li>
<li>b) Enclose the information in brackets, using the standard English language convention for editorial interjections</li>
</ul>
</li>
<li>5. If neither header nor title page is present but the header creator has satisfactory evidence of an originating source, that
document should be used as the chief source of information for the title and author of the header. If the source cannot be fully
verified as to edition, authorship, etc., this fact should be clearly indicated in a note in the <fileDesc>.
</li>

</ul>

===Element Recommendations for the <teiHeader>===

<table border="1" width="80%">
<tr>
<td colspan="1"><teiHeader type="____"></td>
<td colspan="1">
Standards which apply to the header, e.g., <teiHeader type="ISBD(ER)">, <teiHeader
type="AACR2">
</td>
</tr>
</table>

===<fileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<title type="____"></td>
<td colspan="1">
Only uniform title and main title for the TEI document, not the source document, should be entered here, e.g., <title type="uniform"> or <title type="main">. See <sourceDesc> for other title forms for documents where a user might seek the documents under titles other than those assigned. Where a title is supplied, the title should be enclosed in square brackets using standard English-language conventions for editorial insertion.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of original source (electronic or print) should be entered into the <author> element before the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.
</td>
</tr>

<tr>
<td colspan="1">
<editor></td>
<td colspan="1">
Editor of original source (electronic or print) should be entered into the <editor> element <b>before</b> the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.</td>

</tr>

<tr>
<td colspan="1">
<respStmt></td>
<td colspan="1">
The editor (also compiler, illustrator) of the TEI document, not the source document, should be entered here. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<editionStmt></td>

<td colspan="1">
This element should be used sparingly as there are currently no standards as to when versions become editions. Users should refer to the TEI guidelines.</td>
</tr>

<tr>
<td colspan="1">

<extent></td>
<td colspan="1">
Use the standard text "ca.**** kilobytes".</td>
</tr>

<tr>
<td colspan="1">

<publicationStmt></td>
<td colspan="1">
Use the child elements below rather than <p> for a prose description.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
The publisher is whoever has collected the TEI document, not the source document, and has made decisions concerning it.</td>
</tr>

<tr>

<td colspan="1">

<distributor></td>
<td colspan="1">
The distributor is whoever makes the TEI document, not the source document, available.</td>
</tr>

<tr>
<td colspan="1">
<idno></td>
<td colspan="1">
Any unique identification number determined by the publisher. Use type="OCLC-___" to point to the catalog record for the TEI document, if applicable. The institution's three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<availability status=" "><p></td>
<td colspan="1">
Describe any rights statement for the TEI document. Use a standard scheme, such as the code for a Creative Commonse license, for the value of the status attribute if possible.</td>
</tr>

<tr>
<td colspan="1">
<date></td>
<td colspan="1">
Refers to the date of the first publication of the TEI document. <b>For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.</b></td>
</tr>

<tr>
<td colspan="1">
<seriesStmt><title></td>

<td colspan="1">
Whenever possible, establish or use the name from a national name authority file authorized for the electronic, locally created series.
</td>
</tr>

<tr>
<td colspan="1">
<notesStmt></td>

<td colspan="1">
Optional, for indicating questionable attributions for title, author, etc.</td>

</tr>

<tr>
<td colspan="1">
<sourceDesc></td>
<td colspan="1">
In order to effectively represent the source(s) when many documents are represented by the TEI header, we see the need for structured elements that minimally allow us to identify parent-child and component relationships. In the absence of these structures, we suggest that multiple source descriptions be employed with relationships described in free text. Relationships also could be useful in other portions of the TEI header. Cataloger may need to do research to establish the original source.</td>
</tr>

<tr>

<td colspan="1">
<bibl> or
<biblFull></td>
<td colspan="1">
Use <bibl> with child elements listed below. metadata for the source document is automatically generated from a MARC record. It is suggested that child elements appear in the following order for ease of display according to ISBD: <author>, <title type="245a">, <title type="245b">, <respStmt>, <edition>, <pubPlace>, <publisher>, <date>, <extent>, <title type="series">, <note>, <idno type="isbn-13">, <idno type="isbn-10">, <idno type="OCLC-___">. Use <biblFull> for exhaustive description created by hand. </td>

</tr>

<tr>
<td colspan="1">
<title></td>
<td colspan="1">
Title of the source document. It is possible to have multiple <title> elements. Alternative titles (cover, running, spine titles) should be entered in separate <title> elements in <biblFull>.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of the source document. It is possible to have multiple <author> elements. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">

<editor></td>
<td colspan="1">
Editor of the source document. It is possible to have multiple <editor> elements.</td>
</tr>

<tr>
<td colspan="1">

<respStmt></td>
<td colspan="1">
If using <bibl> and generating from a MARC record, use this for the statement of responsibility (MARC field 245, subfield c).</td>
</tr>

<tr>
<td colspan="1">

<editionStmt></td>
<td colspan="1">
Edition statement in the source document (if present).</td>
</tr>

<tr>
<td colspan="1">
<extent></td>

<td colspan="1">
Enter physical description for the original source. If using <bibl> and generating from a MARC record, use this for MARC field 300.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
Don't repeat field. Enter multiple publishers divided by semicolons.</td></tr>

<tr>
<td colspan="1">
<pubPlace></td>
<td colspan="1">

Don't repeat field. Enter multiple publication places divided by semicolons.</td>
</tr>

<tr>
<td colspan="1">
<date></td>

<td colspan="1">
Imprint date for the original source. '''For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.'''</td>
</tr>

<tr>

<td colspan="1">
<idno></td>
<td colspan="1">
In this location, <idno> refers to identification numbers for the source document. They can be used to indicate the source's location in an individual institution's collection. If a formal standard location system is being used, indicate the nature of the system, e.g., <idno type="LC call number">. If using <bibl> and generating from a MARC record, use type="isbn-13" and type=-"isbn-10" if applicable. Use type="LC call number" (or appropriate abbreviation) for a call number. Use type="OCLC-___" to point to the catalog record for the source document. The institution’s three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<seriesStmt> or <series></td>

<td colspan="1">
Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<notes></td>

<td colspan="1">
Notes about the source document. If using <bibl> and generating from a MARC record, use for the value of MARC field 500.</td>
</tr>
</table>

===<encodingDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<projectDesc></td>
<td colspan="1">Enter a description of the purpose for which the electronic file was encoded.</td>
</tr>

<tr>
<td colspan="1">
<editorialDecl></td>
<td colspan="1">
Enter general and specific statements about how the electronic file has been treated. Record here editorial decisions made
during encoding.</td>

</tr>

<tr>
<td colspan="1">
<refsDecl></td>
<td colspan="1">
<refsDecl> could be used for administrative metadata, e.g., pagination and page sequencing.</td>
</tr>

<tr>

<td colspan="1">

<classDecl> <taxonomy id="____"> <bibl></td>
<td colspan="1">
If used, identify the appropriate taxonomy definitions or descriptive sources in the <taxonomy> element followed by id, e.g.,
<taxonomy id="LCSH"> <bibl>Library of Congress Subject Headings</bibl> </taxonomy>, <taxonomy id="AAT"> <bibl> Art & Architecture Theasaurus</bibl> </taxonomy>.</td>
</tr>
</table>

===<profileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">

<langUsage> <language id="____"></td>
<td colspan="1">
Use the ISO 639-2 standard (which is the same as the MARC language codes) for the id attribute. The content of the element should be the name of the language given in ISO 639-2.</td>

</tr>

<tr>
<td colspan="1">
<classCode scheme="___"></td>
<td colspan="1">
True classification numbers as opposed to call numbers can be entered here.</td>

</tr>

<tr>
<td colspan="1">
<keywords><br />

<term>
</td>
<td colspan="1">
Use for uncontrolled terms.</td>
</tr>

<tr>
<td colspan="1">
<keywords scheme="____"><br />
<term>
</td>
<td colspan="1">
Use for controlled vocabulary as specified in <encodingDesc> taxonomy id. Example: scheme="LCSH"</td>

</tr>
</table>

===<revisionDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<change>
</td>
<td colspan="1">
Create a <change> element to record each significant change to the TEI document.</td>

</tr>

<tr>
<td colspan="1">
<date>
</td>
<td colspan="1">
The date of the change in ISO 8601 form (YYYY-MM-DD).</td>

</tr>

<tr>
<td colspan="1">
<respStmt> <name>
</td>
<td colspan="1">
Initials or other identifying information about the person or process making the change.</td>

</tr>

<tr>
<td colspan="1">
<item>
</td>
<td colspan="1">
Prose description of the change.</td>

</tr>
</table>

===Minimal TEI Header Recommendation===
<blockquote>
<div class="indent"><teiHeader></div>
<div class="lindent"><fileDesc></div>

<div class="lindent2"><titleStmt></div>
<div class="lindent3"><title></title></div>
<div class="lindent3"><author></author></div>
<div class="lindent2"></titleStmt>

</div>
<div class="lindent2"><publicationStmt>
</div>
<div class="lindent3"><publisher></publisher>

</div>
<div class="lindent3"><pubPlace></pubPlace>
</div>
<div class="lindent3"><idno></idno>
</div>
<div class="lindent3"><availability><p></p></availability>
</div>
<div class="lindent3"><date></date>

</div>
<div class="lindent2"></publicationStmt>

</div>
<div class="lindent2"><sourceDesc>
</div>
<div class="lindent3"><biblFull>
</div>
<div class="lindent4"><titleStmt>
</div>
<div class="lindent5"><title></title>

</div>
<div class="lindent5"><author></author>
</div>
<div class="lindent4"></titleStmt>
</div>
<div class="lindent4"><publicationStmt>
</div>
<div class="lindent5"><publisher></publisher>
</div>
<div class="lindent5"><pubPlace></pubPlace>

</div>
<div class="lindent5"><date></date>
</div>
<div class="lindent4"></publicationStmt>
</div>
<div class="lindent3"></biblFull>
</div>
<div class="lindent2"></sourceDesc>
</div>
<div class="lindent"></fileDesc>
</div>

<div class="indent"></teiHeader>
</div>
</blockquote>

Repeat the <biblFull> field, as appropriate, if there is more than one source for the electronic item. [http://www.diglib.org/standards/teiheaders.html See some examples in context …]

===Recommended Additions to the teixlite DTD===
<ul>
<li>Add elements under <name> to allow for the variable ordering and alphabetization of names:
<forename>, <surname>, <birthdate>, <deathdate>, <title>, etc.</li>

<li>In order to effectively represent the source(s) when many documents are
represented by the TEI header, we see the need for structured elements that, minimally,
allow us to identify parent-child and component relationships.</li>
</ul>

===Acknowledgments and Bibliography===
<ul>
<li>
This guide was prepared by Judy Ahronheim, Thomas Champagne, Lynn Marko, Kelly Webster, and Chris Wilcox of the University of
Michigan Library and Jackie Shieh of the University of Virginia Library in October 1998. The source documents were the cataloging
guides prepared by those two institutions ([http://www.lib.virginia.edu/cataloging/manual/chapters/chapxiib.html Virginia] and [http://www.lib.umich.edu/ts/sections/electronicresourcesdev.html Michigan]). In addition,
documentation from the Oxford Text Archive, Arts and Humanities Data Service of the United Kingdom also was made available to assist
in this effort.

</li>

</ul>

==Encoding Levels==
===LEVEL 1: Fully Automated Conversion and Encoding===

'''Purpose''': To create electronic text with the primary purpose of keyword searching and linking to page images. The primary advantage in using the teixlite DTD at this level is that a TEI header is attached to the text file.

<p>
'''Rationale''': The text is subordinate to the page image, and is not intended to
stand alone as an electronic text (without page images).</p>

<p>Texts at Level 1 can be created and encoded by fully automated means, using uncorrected OCR of page
images ("dirty OCR"), exporting from existing electronic text files, or actually not including any text
at all. Only those elements that are necessary to divide the text from the header and facilitate linking to
page images are used. Encoding is performed automatically based on artifacts of the OCR or other
document creation process (page breaks, for example) and metadata collected during the imaging or
preparation process. This encoding is both minimal and reliable, and does not typically require
extensive review of each page of each text.</p>

<p>Level 1 texts are not intended to be adequate for textual analysis; they are more likely to be suited
to the goals of a preservation unit or mass digitization initiative. Though their encoding is minimal,
Level 1 texts are fully valid XML texts. In addition to taking advantage of the TEI header, using the
teixlite DTD--with the consistency suggested by these guidelines--allows Level 1 texts to be compatible
with more richly encoded teixlite texts (that also follow these guidelines) for
searching, for example. Further encoding based on document structures or content analysis can be added
to a Level 1 text at any time.</p>

<p>
'''Level 1 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>a large volume of material is to be made available online quickly</li>
<li>a digital image of each page is desired</li>
<li>no manual intervention will be performed in the text creation process</li>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>sophisticated search and display capabilities based on the structure of the text are not necessary</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<table border="1" width="80%">
<tr>
<td colspan="1"><div1></td>
<td colspan="1">If no type= attribute is specified, a type= value of
"section" should be presumed.</td>
</tr>

<tr>
<td colspan="1"><p></td>
<td colspan="1">At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using <p> in order that the document be open to being extended to other encoding levels).</td>
</tr>
<tr>

<td colspan="1"><pb></td>
<td colspan="1">Required in Level 1. Page images can be linked to the text by specifying a jpeg or other image file as the value of the facs= attribute. Page numbers can be supplied with the n= attribute to record the number that is on the page. The Task Force sees the use of METS here as having a tremendous advantage. METS/TEI page turning documentation will be included in the near future.</td>
</tr>
</table>

====Basic Structural Example:====
<pre>
<TEI.2 id="someid">
<teiHeader>
[Source and processing information goes here]
</teiHeader>
<text>
<body>
<div1>
<p>
<pb id="p00000001" n="1"/>
[main body of the unmarked up plain text begins here]
<pb id="p00000002" n="2"/>
[more plain text goes here with appropriate page breaks interspersed] ...
<pb id="p00000145" n="145"/>
[more plain text]
<pb id="p00000146" n="146"/>
[text ends here]
</p>
</div1>
</body>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level1example.html See an example in context…]

===LEVEL 2: Minimal Encoding===
'''Purpose''': To create electronic text for full-text searching, linking to page images, and identifying simple structural hierarchy to improve navigation.

'''Rationale''': The text is subordinate to the page image, though navigational markers (textual divisions, headings) are captured. The text could stand alone as electronic text (without page images) if the accuracy of its contents is suitable to its intended use and it is not necessary to display low-level typographic or structural information. Level 2 requires a set of elements more granular than those of Level 1, including bibliographic or structural information below the monographic or volume level.

Though texts at Level 2 can be created and encoded by automated means, based on the typographic elements in the electronic file (for example, bold centered text at the top of the page surrounded by whitespace indicates a new chapter heading, and thus a new division), it is not likely to be absolutely reliable across a large body of material. Level 2 encoding requires some human intervention to identify each textual division and heading. Level 2 texts do not require any special knowledge or manual intervention below the section level.

Level 2 texts are not intended to be displayed separately from their page images. Level 2 encoding of sections and headings provides greater navigational possibilities than Level 1 encoding, and enables searching to be restricted within particular textual divisions (for example, searching for two phrases within the same chapter).

'''Level 2 is most suitable for projects with the following characteristics''':

* a large volume of material is to be made available online quickly
* a digital image of each page is desired
* the material is of interest to a large community of users who wish to read texts that allow keyword searching
* rudimentary search and display capabilities based on the large structures of the text are desired
* each text will be checked to ensure that divisions and headers are properly identified
* extensibility is desired; that is, one desires to keep open the option for a higher level of encoding to be added at a later date

All elements specified in Level 1 plus the following:

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>
<td colspan="1">Optional</td>
</tr>
<tr>
<td colspan="1"><div1></td>
<td colspan="1">type="section" is the default attribute value. It is recommended that the n= attribute be
included to record the sequence of divisions.</td>
</tr>
<tr>
<td colspan="1"><head></td>
<td colspan="1">Required if present</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">One "container" element per div is required.</td>
</tr>
</table>

====Basic Structural Example:====

<pre>
<TEI.2 id="someid">
<teiHeader> [Source and processing information goes here] </teiHeader>
<text id="someotherid">
<front> [titlepage information, table of contents, prefaces, etc.] </front>
<body>
<div1 type="chapter" n="1">
<head>Chapter 1</head>
<p>[text of Chapter 1 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="2">
<head>Chapter 2</head>
<p>[text of Chapter 2 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="3">
<head>Chapter 3</head> [text of Chapter 3 goes here interspersed with <pb> elements
pointing to page images] </div1>
<div1 type="chapter" n="4">
<head>Chapter 4</head> [text of Chapter 4 goes here interspersed with <pb> elements
pointing to page images] </div1>
</body>
<back> [optional text of backmatter, appendices, etc.] </back>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level2example.html See an example in context…]

===LEVEL 3: Simple Analysis===

<p>
'''Purpose''': To create text that can stand alone as electronic text and identifies
hierarchy and typography without content analysis being of primary importance.</p>

<p>
'''Rationale''': Level 3 texts can be created from scratch or by the relatively easy
conversion of existing HTML or word-processing documents. Encoding offers the advantage of the TEI
header, interoperability with other TEI collections, and extensibility to higher levels of encoding.
Level 3 generally requires some human editing, but the features to be encoded are determined by the
appearance of the text and not specialized content analysis.</p>

<p>Level 3 texts identify front and back matter, and all paragraph breaks. The finer granularity of
encoding these features, as well as figures, notes, and all changes of typography, allows a range of
options for display, delivery, and searching. For example, one has the option of identifying and,
therefore, specifying the display charactersitics of different typographic styles, and regularizing the
display and placement of note text.</p>

<p>Level 3 texts can stand alone as text without page images and, therefore, can be uploaded, downloaded
and delivered quickly, and require less storage space than digital collections with page images.
However, the simple level of structural anaylsis and absence of specialized content analysis reflected
in Level 3 encoding may make it desirable for some, depending on project priorities, to include page
images in order to provide users with a fuller set of resources.</p>

<p>
'''Level 3 is most suitable for projects with the following characteristics:'''
</p>

<ul>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>some sophistication of display, delivery, and searching based on structure of the text is desired</li>
<li>each text will be checked to ensure that encoding decisions have been made appropriately</li>
<li>the users of the texts may have limited storage or display capabilities</li>
<li>the creator of the texts has limited or no ability to provide content expertise to analyze, tag,
or review texts</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<p>All elements specified in Levels 1 and 2, plus the following:</p>

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>

<td colspan="1">Required if present.</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">Required for paragraph breaks in prose; may be used for stanzas using <lb> for
line breaks in verse.</td>
</tr>

<tr>
<td colspan="1"><list> and <item></td>
<td colspan="1">May be used in this level to indicate ordered and unordered list structures.</td>
</tr>
<tr>
<td colspan="1"><table>, <row>, and <cell></td>

<td colspan="1">May be used to indicate table structures.</td>
</tr>
<tr>
<td colspan="1"><figure></td>
<td colspan="1">Required to indicate figures other than page images.</td>
</tr>
<tr>

<td colspan="1"><hi></td>
<td colspan="1">Required to indicate changes in typeface; rend attribute is optional.</td>
</tr>
<tr>
<td colspan="1"><note></td>
<td colspan="1">All notes must be encoded. It is also recommended that notes that extend beyond one page be combined into one <note> element. Marginal notes, without reference, should occur at the beginning of the paragraph to which they refer, with the value of the place attribute as "margin".</td>

</tr>
<tr>
<td colspan="1"><lb></td>
<td colspan="1">May be used to force line breaks.</td>
</tr>
</table>

<p>NOTE ON <note>:</p>

<p>It may be desirable to move footnotes from their original location in the text. If left at the bottom
of a page, a note may become included in another paragraph or section of the encoded text, and thus
separated from its reference. There are options for placement of footnotes if they are moved:</p>

<ul>
<li>Inline. The note is inserted at the point of reference. An n attribute records the value of the
note reference if there is one.</li>
<li>End-of-Division. Notes moved to the end of the division</li>
</ul>

<p>

'''Basic Structural Example forthcoming ...'''
</p>

===LEVEL 4: Basic Content Analysis===
<p>'''Purpose''': To create text that can stand alone as electronic text, identifies
hierarchy and typography, specifies function of textual and structural elements, and describes the
nature of the content and not merely its appearance. This level is not meant to encode or identify all
structural, semantic or bibliographic features of the text.</p>

<p>
'''Rationale''': Greater description of function and content allows for:</p>

<ul>
<li>flexibility of display and delivery</li>
<li>sophisticated searching within specified textual and structural elements</li>
<li>combining the broadest range of uses and audiences</li>

</ul>

<p>Texts encoded at Level 4 are able to stand alone as part of a library collection, and do not require
page images in order for them to be read by students, scholars and general readers. This level of TEI
encoding allows them to be displayed or printed in a variety of ways suitable for classroom or scholarly
use.</p>

<p>Level 4 texts contain elements and attributes that describe content. For example, lines of verse are
tagged with <l>; the <p> element is reserved for true paragraphs. Features of
the text that may contribute to meaning, such as indentation of verse lines and typographic change, are
preserved. These are textual features that are not encoded at lower levels and that allow the text to be
used and understood fully independent of images.</p>

<p>The ability to stand alone as text means that Level 4 texts are more nimble and robust for exercises
such as format repurposing and textual analysis.</p>

<p>Finally, functionally accurate encoding in Level 4 texts
allows them to be searched or displayed in sophisticated ways.
For example, a searcher could limit his or her search in a
dramatic text to stage directions or in a verse text to only
first lines. In a politicall tract published by subscription, a
search could be confined to names that appear in lists, thus
limiting a search to names of people who subscribed to a
particular volume. This ability to limit searches becomes more
significant as textbases become larger, and thus is of great
importance to the library community as it attempts to build into
the initial design and implementation of textbases the features
needed to enhance interoperability.</p>

<p>
'''Level 4 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>sophisticated search and retrieval capabilities are desired</li>

<li>the texts will be used for textual analysis</li>
<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added by the scholarly community at a later date</li>
<li>the users of the texts may have limited storage or display capabilities</li>
</ul>

====General Level 4 Recommendations====
<ul>
<li>Typographically distinct text should be encoded as appropriate,
e.g. with <term>, <q>, <gloss>, <mentioned>, <soCalled>, <foreign>,
<title>, or <emph>. Any ambiguous emphasized text should be
encoded as <hi> (e.g. <hi rend="bold">).</li>
<li>It is recommended that the <sic> element be used to
indicate typographic errors, with corrections (if any) noted
as the value of the corr= attribute.</li>
<li><titlePage> should include the verso if present, divided by <pb
n="verso"/>. Tables of contents, errata, subscription lists, "other titles by the same author"
should be included in a separate numbered division, as a <list> with <item>s.
Frontispieces should be encoded as a <figure>, within a separate numbered division and
<p>.</li>
</ul>

[http://www.diglib.org/standards/level4genrec.html See some examples in context…]

====Level 4 Prose====
<ul>
<li>Letters that occur within the text body provide some challenges. It is recommended that quoted
letters that occur as part of a text (and not collections of letters themselves) be encoded within
<q><text><body><div1 type="letter">, with
<opener>, <dateline>, <salute>, <signed>,
<closer> included as appropriate.</li>

<li>Quotations that do not occur inline, but are set off typographically in some way, should be
encoded as <q>.</li>
<li>Notes are to be encoded as described in Level 3.</li>
<li><argument>, <opener>, <epigraph>,
<closer>, <trailer>, <add>, <del>,
<unclear> as appropriate.</li>

</ul>

[http://www.diglib.org/standards/level4prose.html See some examples in context…]

====Level 4 Drama====
<ul>
<li>Cast lists should be encoded as <list>s, with <item>s.</li>

<li>Speeches are encoded as <sp>, with speakers identified within
<speaker> elements; stage directions are encoded as <stage> and enclose
block level content describing scenery, etc.</li>
</ul>

[http://www.diglib.org/standards/level4drama.html See some examples in context…]

====Level 4 Oral History====
<ul>
<li>Speakers in interviews can be identified in the <teiHeader> in several ways.
<ul>
<li>In the <profileDesc>, in the <particDesc> in a <list>, with <name> inside of <item>s.</li>

<li>As a list of author <name>s within <fileDesc><titleStmt></li>
</ul>
</li>
<li>In either method, use an id= on the <name> element to uniquely identify the individual participant</li>

<li>Questions and answers from interviewees and interviewers are encoded as <sp>,
with speakers identified within <speaker> elements with a who= attribute the value of which
corresponds to the id= in the list of interview participants.</li>
</ul>
[http://www.diglib.org/standards/level4oh.html See some examples in context…]

====Level 4 Verse====
<ul>
<li>All verse, even poems without separate stanzas or verse paragraphs, should be contained within a
line group element <lg>. This will assist with automated processing and retrieval.</li>
<li>It is common to see informal divisions within poems, noted by a string of asterisks or periods.
These should be encoded as <milestone/>s with attribute values of unit="typography" and
n="()" indicating the character used and its occurrence, <milestone unit="typography"
n="******"/>.</li>
<li><l> It is recommended that indentation be recorded and that the rend attribute be
used to do this.</li>
</ul>
[http://www.diglib.org/standards/level4verse.html See some examples in context…]
====Level 4 Front and Back Matter====
<ul>
<li>It is recommended that all prefaces, tables of contents, afterwords, appendices, endnotes and
apparatus be encoded. For publisher's advertisements, indexes, and glossaries or other front or back
matter that isn't considered of primary importance to the text, there are three options:<ul>
<li>Fully transcribe and encode</li>
<li>Link to page images (may include an unencoded transcription)</li>
<li>Omit, noted in <editorialDesc></li>
</ul>
</li>
</ul>
[http://www.diglib.org/standards/level4fandb.html See some examples in context…]

===LEVEL 5: Scholarly Encoding Projects===

<p>Level 5 texts are those that require subject knowledge, and encode semantic, linguistic, prosodic or
other elements beyond a basic structural level.</p>

==General Guidelines for Attribute Usage==

<p>Some general advice on the use of particular attributes
follows.</p>
<ul>
<li><b>type=</b>: Constructing a list of acceptable attribute values
for type that could find wide agreement is impossible. Instead,
it is recommended that projects describe the type= attribute
values used in their texts in the project ODD file or other
documentation and that this list be made available to people
using the texts. See <i>ABC for Book Collectors</i> by John
Carter (7th edition, New Castle, DE:Oak Knoll Books, 1995) for
a list of standard names and definitions of bibliographic
features of printed books. For those elements where type is not
required, such as <head> and <title>, use the
attribute values for subtitles and additional titles, but not
main titles.<br /> Example: <div1 type="volume"></li>

<li><b>n=</b>: Sometimes an n= (number) attribute can be used by itself. For instance in the case of
pagebreaks:<br /> Example: <pb n="456"/></li>

<li><b>id=</b>: If you are in a situation that requires you to
uniquely identify an element that will be used to reference
another specific location in one or more texts, use an id=
attribute. The value of this attribute must be unique within a
document, and must be composed of alphanumeric characters,
dots, hyphens, and underscores, and must start with a
letter.<br /> Example: <note id="n5" n="5"></li>

<li><b>target=</b>: follows the same syntactic rules as the id=
attribute value. In fact, target= and id= are often used in
conjunction with one another as in the case of footnotes where
the <anchor id="n5" n="5"> is at a specific place in the
text and is referred to by the <note target="n5" n="5">
which contains the actual information of the footnote itself
elsewhere.</li>

<li><b>entity=</b>: The entity= attribute is simply the way a
figure indirectly points or refers to its the actual image
file<br /> Example:
<!ENTITY TwaFifrn SYSTEM "TwaFifrn.jpg" NDATA jpeg><br />
<br />
<figure entity="TwaFifrn"></li>

<li><b>rend=</b>: Difficulty using rend= attributes occurs when it is desirable to record
more than one rendition feature. With this in mind, it is recommended that projects employ the
following adaptation of "rendition ladders", a concept developed at the [http://www.wwp.brown.edu/ Brown University Women Writers Project]. This system allows for sets
of multiple renditional features to be included in one rend= value. Rendition ladders consist of categories of
renditional features with values of each of those features enclosed in parentheses.<br /> rend= should only be
used to override a default value. For instance, if all text encoded as <hi> is defined as being
rendered in italics, there is no reason to encode text as <hi rend="font(italics)"> Combining renditional features would result in a tag with attributes such as <l rend="font(italics)align(right)">
<ul>
<li>font <br />italics, bold, fsc (full and smallcaps), smallcap, underlined, gothic</li>
<li>align <br />right, left, center, block</li>
<li>indent <br />Values in parentheses should indicate the number of tabstops to be indented, e.g.,
<l rend="indent(1)"></li>
</ul>
</li>
<li><b>lang=</b>: Use ISO639-2 three-character language codes. Note that this recommendation is slightly different from that of the TEI P5 Guidelines, which recommends the BCP 47 language codes.</li>
</ul>
References: <references/>
[[Category:SIG:Libraries]]

Best Practices for TEI in Libraries

2008-09-22T13:59:26Z

Melanieschlosser: /* <revisionDesc> */

[http://www.tei-c.org/wiki/index.php/SIG:Libraries TEI in Libraries: Home]

==Introduction and History==
<p>The Text Encoding Initiative Guidelines for Electronic Text Encoding and Interchange (referred to as
the <i>TEI Guidelines</i>) were first published in 1994 and represent a tremendous
achievement in electronic text standards by providing a highly sophisticated structure for encoding
electronic text. Digital librarians have benefited greatly from the standardization provided by these
guidelines, and the potential for interoperability and long-term preservation of digital collections
facilitated by their wide adoption.</p>

<p>In 1998, the Digital Library Federation (DLF) sponsored the [http://www.lib.umich.edu/lit/dlps/history/teidlf/index.html TEI and XML in Digital Libraries Workshop] at the
Library of Congress to discuss the use of the <i>TEI Guidelines</i> in libraries for electronic text,
and to create a set of best practices for librarians implementing them. From this workshop, three working
groups were formed the members of which represented some of the largest and most mature digital library
programs in the U.S. Group 2 was charged with developing a set of recommendations for libraries using the
TEI Guidelines in electronic text encoding. This group included the following representatives from six libraries:
</p>
<ul>
<li>LeeEllen Friedland, Library of Congress</li>
<li>Nancy Kushigian, University of California, Davis</li>
<li>Christina Powell, University of Michigan</li>
<li>David Seaman, University of Virginia</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>At the ALA mid-winter (January 1999), the DLF task force revised a draft set of best practices, called
TEI Text Encoding in Libraries: Guidelines for Best Practices (referred to as <i>TEI in Libraries
Guidelines</i>). The revised recommendations were circulated to the conference working group in May
1999 and presented at the joint annual meeting of the Association of Computers and the Humanities and
Association of Literary and Linguistic Computing in June 1999. [http://www.diglib.org/standards/tei-old.htm Version 1.0] was circulated for comments in
August 1999. These guidelines were endorsed by the DLF, and have been used by many digital libraries,
including those of the task force members, as a model for their own local best practices. Libraries,
museums and end-users have benefitted from a set of best practices for electronic text in a number of
ways, including better interoperability between electronic text collections, better documented practices
among digital libraries, and a starting point for discussion of best practices with commercial publishers
regarding electronic text creation.</p>

<p>Written in 1998, this first iteration of <i>TEI in Libraries Guidelines</i> made no mention of XML,
XSLT, or any of the other powerful tools that have now become common parlance and practice in creating
digital documents and collections. Based on these important changes in markup technology, it came to the
attention of the DLF and members of the original Task Force that the <i>TEI in Libraries Guidelines</i>
required substantial revision. In 2002, the TEI Consortium published a new edition of the complete
<i>TEI Guidelines</i> that conformed to XML specifications. In order to remain useful, the <i>TEI in
Libraries Guidelines</i> had to be updated to reflect these developments.</p>

<p>Furthermore, librarians need more guidance than the original <i>TEI in Libraries Guidelines</i>
provided. There are many library-specific encoding issues which need to be addressed and documented to
ensure consistency. The intention of this document is to provide recommended paths of encoding for these
issues.</p>

<p>In addition, these library guidelines have the potential to be much more useful if they can serve as a
training document from which librarians can learn about text encoding and addressing particular encoding
challenges. To fulfill this role, the guidelines require more examples and detailed explanations,
giving documentation of the use of TEI in a library context. Librarians also need a set of standards
and best practices for vendors and publishers who create electronic text for digital libraries, so that
these collections adhere to the same archival standards as locally-created electronic text collections.
With detailed guidelines that could serve as an encoding specification, librarians might encourage
vendors to follow the principles in these standards, to facilitate the long-term preservation of
commercially published electronic text collections, and more readily allow for cross-collection
searching.</p>

<p>In order to facilitate the evolution of this document, another DLF-sponsored Task Force—some
of the representatives of which were on the original Task Force—met on October 24-25, 2003 at
the Cosmos Club in Washington, D.C.: </p>
<ul>
<li>Richard Gartner, Oxford University Library</li>
<li>Matthew Gibson, University of Virginia Library</li>
<li>Kirk Hastings, California Digital Library</li>
<li>Christina Powell, University of Michigan</li>
<li>Merrilee Proffitt, RLG</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>These representatives met to revise the original <i>TEI in Libraries Guidelines</i> in order
that they: </p>
<ul>
<li>reflect changes occuring within the text encoding world generally and within the TEI
community specifically</li>
<li>further illuminate the different levels of encoding by offering clearer and more robust
examples.</li>
</ul>
<p>After producing [http://www.diglib.org/standards/tei2/tei20.htm Version 2.0] of the Guidelines, this group (with some changes in membership) met again
at the Cosmos Club on February 13-14, 2006. Those in attendance were: </p>
<ul>
<li>Syd Bauman, The TEI Consortium</li>
<li>Richard Gartner, Oxford University Library (by phone)</li>
<li>Matthew Gibson, Virginia Foundation for the Humanities (chair)</li>
<li>Merrilee Proffitt, RLG</li>
<li>Chris Powell, The University of Michigan</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natasha Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, The University of Michigan</li>
</ul>
<p>This group of continues to meet and based upon their discussions and resolutions, the following
guidelines will continue to be updated and enhanced.</p>

==General Overview and Comments==

<p>These recommendations are for libraries using the XML version of the TEILite DTD (teixlite).
There are many different library text digitization projects, for different purposes. With this in mind,
the Task Force has attempted to make these recommendations as inclusive as possible by developing a
series of encoding levels. These levels are meant to allow for a range of practice, from wholly automated
text creation and encoding, to encoding that requires expert content knowledge, analysis, and editing.</p>

<p>Recommendations for Levels 1-4 are intended for projects wishing to create encoded electronic text with
structural markup, but minimal semantic or content markup. Also, the encoding levels are cumulative:
encoding requirements at each level incorporate the requirements of lower levels. Levels 1-4 allow the
conversion and encoding of texts to be performed without the assistance of deep content knowledge and can
be enriched with more markup at any time. Level 5, in contrast, requires scholarly analysis. </p>

<p>These recommendations are concerned with the text portion of a TEI-encoded document. While there are
modest requirements for including certain information about encoding level in the TEI header, a separate
set of recommendations, now integrated into this document, was developed to address issues concerning TEI header
contents to MARC-format bibliographic data (see the [[#The TEI Header (based on June 16, 2001 Draft)|<teiHeader> section]]).</p>

==General Recommendations==

<p>Note: all recommendations that follow are based on P4:2004, with the exception of the facs= attribute of <pb>, which comes from the P5 module for the transcription of primary sources ('transcr').</p>

<ul>
<li>The encoding level (as described in this document) should be recorded in the
<editorialDecl> in the TEI header, along with an explanation of any deviation from the
recommendations.</li>

<li>Electronic text at all levels of encoding should begin with the transcription of the first word on
the first leaf of the original work. It may be impractical or undesirable to transcribe and encode
certain features of the text, such as publisher's advertisements or indexes, but if at all possible,
they should be included as links to page images. Any omissions of material found in the original work
should be noted in the <editorialDecl> in the TEI header.</li>
<li>File naming should follow ISO 9660 conventions: 8-character filenames, 3-character extensions,
using A-Z, a-z, 0-9, underscores and hyphens. The rationale behind this suggestion is that when moving
texts across different platforms (DOS for instance), some systems will truncate beyond the eighth
character.</li>
<li>We recommend the use of numbered divisions throughout the electronic text, always beginning with
<div1> (we prefer that <div0> not be used since the TEI Guidelines does not
make it available in <front> or <back> matter). Numbered divisions present
advantages to search and indexing software by explicitly communicating the hierarchical level of the
section described. Texts at all levels should include at least one <div1>.</li>
<li>Page breaks should be encoded using the <pb> element,
which should demark the top of a page (i.e. the text of page
seven should immediately follow <pb n="7"/>), and should
always be contained within a division. E.g., a page break that
occurs between chapters 2 and 3 should be encoded near the top
of the <div> that holds chapter 3 (rather than near the bottom
of the <div> that holds chapter 2).</li>
</ul>

==The TEI Header==

===Introduction===
<p>At the TEI and XML in Digital Libraries Workshop that was held at the Library of Congress in July 1998, several working groups
were formed to consider various aspects of the Text Encoding Initiative. Group 1 was charged to recommend some best practices
for TEI header content and to review the relationship between the Text Encoding Initiative header and MARC. To this end,
representatives of the University of Virginia Library and the University of Michigan Library gathered in Ann Arbor in early
October 1998 to develop a recommended practice guide. This work was assisted by similar efforts that had taken place in the United
Kingdom under the auspices of the Oxford Text Archive the previous year.
The following document represents a draft of those recommended practices. It has been submitted to various constituencies for
comment.</p>

===Working Assumptions===
<p>A TEI header can serve many publics. Headers can be created in a text center and reflect the center's standards, or they can
serve as the basis for other types of metadata system records produced by other agencies. Headers can function in detached
form as records in a catalog, as a title page inherent to the document, or as a source for index displays.</p>

<p>In addition, a header may describe a collection of documents, a single item, or a portion of an item. Variances in TEI header
content can result from making different choices of what is being described.</p>

<p>A TEI header may not have a one to one correspondence with a MARC record. One TEI header may have multiple MARC analytic records,
or one MARC record may be used to describe a collection of TEI documents with individual headers.</p>

<p>A TEI header serves several purposes. It may contain an historical background on how the file has been treated. It can extend the
information of a classic catalog record. The Text Center and/or cataloging agency can act as the gatekeeper for creators by
providing standards for content.</p>

===Cataloging a TEI Document===

<p>Does the TEI header act as the electronic title page or as a catalog record? Is it integral to the document it describes or
independent? Depending on the community being served, the TEI elements will reflect the interest of that community. Nonetheless,
it is possible to describe a set of "best practices" that will produce compatible content while accommodating this variety of
purposes. Compatibility of content encourages a more understandable set of results when information about assorted items is
displayed as a set of search results, a contents list, or an index, and it allows for more reasonable conversion of content
information from TEI elements to elements of other metadata sets when this action seems advisable.</p>

<p>It is a traditional practice of librarianship to agree upon where in a document and in what order of preference one should look
to identify the title, author, etc., of that document. This permits a certain consistency in terminology and allows for a certain
amount of authentication of content. We recommend the following preferences to those who create headers and to those who attempt
to use headers to create traditional catalog records that are compliant with AACR2 and ISBD(ER) rules.</p>

<p>As a member of the academic community, the header creator/editor has a responsibility to verify, whenever humanly possible, the
intellectual source for an electronic document that presents itself without any information regarding its source or authorship.</p>

====Chief Sources of Information for Several Types of Electronic Resources Are:====
<ul> <li>1. For an electronic document with a digitized title page (without a header), prefer
<ul>
<li>a) Chief source of information = information coded as title page</li>
<li>b) Use added information from an originating paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>2. Electronic document with header (without a title page)
<ul>
<li>a) Chief source of information = supplied and verified header <ref name="verify">Verified means that the cataloger/editor has established for him/herself that the information represented as title information is an accurate representation of content.</ref></li>

<li>b) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>

<li>3. Electronic document with header and title page
<ul>
<li>a) Chief source of information = supplied header (if verified)<ref name="verify"/></li>
<li>b) If header is not verified, use title page as chief source</li>
<li>c) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>4. If neither header nor title page is present and there is no evidence of a source document, the header creator
<ul>
<li>a) May assign a title and author if appropriate</li>
<li>b) Enclose the information in brackets, using the standard English language convention for editorial interjections</li>
</ul>
</li>
<li>5. If neither header nor title page is present but the header creator has satisfactory evidence of an originating source, that
document should be used as the chief source of information for the title and author of the header. If the source cannot be fully
verified as to edition, authorship, etc., this fact should be clearly indicated in a note in the <fileDesc>.
</li>

</ul>

===Element Recommendations for the <teiHeader>===

<table border="1" width="80%">
<tr>
<td colspan="1"><teiHeader type="____"></td>
<td colspan="1">
Standards which apply to the header, e.g., <teiHeader type="ISBD(ER)">, <teiHeader
type="AACR2">
</td>
</tr>
</table>

===<fileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<title type="____"></td>
<td colspan="1">
Only uniform title and main title for the TEI document, not the source document, should be entered here, e.g., <title type="uniform"> or <title type="main">. See <sourceDesc> for other title forms for documents where a user might seek the documents under titles other than those assigned. Where a title is supplied, the title should be enclosed in square brackets using standard English-language conventions for editorial insertion.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of original source (electronic or print) should be entered into the <author> element before the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.
</td>
</tr>

<tr>
<td colspan="1">
<editor></td>
<td colspan="1">
Editor of original source (electronic or print) should be entered into the <editor> element <b>before</b> the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.</td>

</tr>

<tr>
<td colspan="1">
<respStmt></td>
<td colspan="1">
The editor (also compiler, illustrator) of the TEI document, not the source document, should be entered here. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<editionStmt></td>

<td colspan="1">
This element should be used sparingly as there are currently no standards as to when versions become editions. Users should refer to the TEI guidelines.</td>
</tr>

<tr>
<td colspan="1">

<extent></td>
<td colspan="1">
Use the standard text "ca.**** kilobytes".</td>
</tr>

<tr>
<td colspan="1">

<publicationStmt></td>
<td colspan="1">
Use the child elements below rather than <p> for a prose description.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
The publisher is whoever has collected the TEI document, not the source document, and has made decisions concerning it.</td>
</tr>

<tr>

<td colspan="1">

<distributor></td>
<td colspan="1">
The distributor is whoever makes the TEI document, not the source document, available.</td>
</tr>

<tr>
<td colspan="1">
<idno></td>
<td colspan="1">
Any unique identification number determined by the publisher. Use type="OCLC-___" to point to the catalog record for the TEI document, if applicable. The institution's three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<availability status=" "><p></td>
<td colspan="1">
Describe any rights statement for the TEI document. Use a standard scheme, such as the code for a Creative Commonse license, for the value of the status attribute if possible.</td>
</tr>

<tr>
<td colspan="1">
<date></td>
<td colspan="1">
Refers to the date of the first publication of the TEI document. <b>For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.</b></td>
</tr>

<tr>
<td colspan="1">
<seriesStmt><title></td>

<td colspan="1">
Whenever possible, establish or use the name from a national name authority file authorized for the electronic, locally created series.
</td>
</tr>

<tr>
<td colspan="1">
<notesStmt></td>

<td colspan="1">
Optional, for indicating questionable attributions for title, author, etc.</td>

</tr>

<tr>
<td colspan="1">
<sourceDesc></td>
<td colspan="1">
In order to effectively represent the source(s) when many documents are represented by the TEI header, we see the need for structured elements that minimally allow us to identify parent-child and component relationships. In the absence of these structures, we suggest that multiple source descriptions be employed with relationships described in free text. Relationships also could be useful in other portions of the TEI header. Cataloger may need to do research to establish the original source.</td>
</tr>

<tr>

<td colspan="1">
<bibl> or
<biblFull></td>
<td colspan="1">
Use <bibl> with child elements listed below. metadata for the source document is automatically generated from a MARC record. It is suggested that child elements appear in the following order for ease of display according to ISBD: <author>, <title type="245a">, <title type="245b">, <respStmt>, <edition>, <pubPlace>, <publisher>, <date>, <extent>, <title type="series">, <note>, <idno type="isbn-13">, <idno type="isbn-10">, <idno type="OCLC-___">. Use <biblFull> for exhaustive description created by hand. </td>

</tr>

<tr>
<td colspan="1">
<title></td>
<td colspan="1">
Title of the source document. It is possible to have multiple <title> elements. Alternative titles (cover, running, spine titles) should be entered in separate <title> elements in <biblFull>.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of the source document. It is possible to have multiple <author> elements. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">

<editor></td>
<td colspan="1">
Editor of the source document. It is possible to have multiple <editor> elements.</td>
</tr>

<tr>
<td colspan="1">

<respStmt></td>
<td colspan="1">
If using <bibl> and generating from a MARC record, use this for the statement of responsibility (MARC field 245, subfield c).</td>
</tr>

<tr>
<td colspan="1">

<editionStmt></td>
<td colspan="1">
Edition statement in the source document (if present).</td>
</tr>

<tr>
<td colspan="1">
<extent></td>

<td colspan="1">
Enter physical description for the original source. If using <bibl> and generating from a MARC record, use this for MARC field 300.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
Don't repeat field. Enter multiple publishers divided by semicolons.</td></tr>

<tr>
<td colspan="1">
<pubPlace></td>
<td colspan="1">

Don't repeat field. Enter multiple publication places divided by semicolons.</td>
</tr>

<tr>
<td colspan="1">
<date></td>

<td colspan="1">
Imprint date for the original source. '''For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.'''</td>
</tr>

<tr>

<td colspan="1">
<idno></td>
<td colspan="1">
In this location, <idno> refers to identification numbers for the source document. They can be used to indicate the source's location in an individual institution's collection. If a formal standard location system is being used, indicate the nature of the system, e.g., <idno type="LC call number">. If using <bibl> and generating from a MARC record, use type="isbn-13" and type=-"isbn-10" if applicable. Use type="LC call number" (or appropriate abbreviation) for a call number. Use type="OCLC-___" to point to the catalog record for the source document. The institution’s three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<seriesStmt> or <series></td>

<td colspan="1">
Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<notes></td>

<td colspan="1">
Notes about the source document. If using <bibl> and generating from a MARC record, use for the value of MARC field 500.</td>
</tr>
</table>

===<encodingDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<projectDesc></td>
<td colspan="1">Enter a description of the purpose for which the electronic file was encoded.</td>
</tr>

<tr>
<td colspan="1">
<editorialDecl></td>
<td colspan="1">
Enter general and specific statements about how the electronic file has been treated. Record here editorial decisions made
during encoding.</td>

</tr>

<tr>
<td colspan="1">
<refsDecl></td>
<td colspan="1">
<refsDecl> could be used for administrative metadata, e.g., pagination and page sequencing.</td>
</tr>

<tr>

<td colspan="1">

<classDecl> <taxonomy id="____"> <bibl></td>
<td colspan="1">
If used, identify the appropriate taxonomy definitions or descriptive sources in the <taxonomy> element followed by id, e.g.,
<taxonomy id="LCSH"> <bibl>Library of Congress Subject Headings</bibl> </taxonomy>, <taxonomy id="AAT"> <bibl> Art & Architecture Theasaurus</bibl> </taxonomy>.</td>
</tr>
</table>

===<profileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">

<langUsage> <language id="____"></td>
<td colspan="1">
Use the ISO 639-2 standard (which is the same as the MARC language codes) for the id attribute. The content of the element should be the name of the language given in ISO 639-2.</td>

</tr>

<tr>
<td colspan="1">
<classCode scheme="___"></td>
<td colspan="1">
True classification numbers as opposed to call numbers can be entered here.</td>

</tr>

<tr>
<td colspan="1">
<keywords><br />

<term>
</td>
<td colspan="1">
Use for uncontrolled terms.</td>
</tr>

<tr>
<td colspan="1">
<keywords scheme="____"><br />
<term>
</td>
<td colspan="1">
Use for controlled vocabulary as specified in <encodingDesc> taxonomy id. Example: scheme="LCSH"</td>

</tr>
</table>

===<revisionDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<change>
</td>
<td colspan="1">
Create a <change> element to record each significant change to the TEI document.</td>

</tr>

<tr>
<td colspan="1">
<date>
</td>
<td colspan="1">
The date of the change in ISO 8601 form (YYYY-MM-DD).</td>

</tr>

<tr>
<td colspan="1">
<respStmt> <name>
</td>
<td colspan="1">
Initials or other identifying information about the person or process making the change.</td>

</tr>

<tr>
<td colspan="1">
<item>
</td>
<td colspan="1">
Prose description of the change.</td>

</tr>
</table>

===Minimal TEI Header Recommendation===
<blockquote>
<div class="indent"><teiHeader></div>
<div class="lindent"><fileDesc></div>

<div class="lindent2"><titleStmt></div>
<div class="lindent3"><title></title></div>
<div class="lindent3"><author></author></div>
<div class="lindent2"></titleStmt>

</div>
<div class="lindent2"><publicationStmt>
</div>
<div class="lindent3"><publisher></publisher>

</div>
<div class="lindent3"><pubPlace></pubPlace>
</div>
<div class="lindent3"><idno></idno>
</div>
<div class="lindent3"><availability><p></p></availability>
</div>
<div class="lindent3"><date></date>

</div>
<div class="lindent2"></publicationStmt>

</div>
<div class="lindent2"><sourceDesc>
</div>
<div class="lindent3"><biblFull>
</div>
<div class="lindent4"><titleStmt>
</div>
<div class="lindent5"><title></title>

</div>
<div class="lindent5"><author></author>
</div>
<div class="lindent4"></titleStmt>
</div>
<div class="lindent4"><publicationStmt>
</div>
<div class="lindent5"><publisher></publisher>
</div>
<div class="lindent5"><pubPlace></pubPlace>

</div>
<div class="lindent5"><date></date>
</div>
<div class="lindent4"></publicationStmt>
</div>
<div class="lindent3"></biblFull>
</div>
<div class="lindent2"></sourceDesc>
</div>
<div class="lindent"></fileDesc>
</div>

<div class="indent"></teiHeader>
</div>
</blockquote>

Repeat the <biblFull> field, as appropriate, if there is more than one source for the electronic item. [http://www.diglib.org/standards/teiheaders.html See some examples in context …]

===Recommended Additions to the teixlite DTD===
<ul>
<li>Add elements under <name> to allow for the variable ordering and alphabetization of names:
<forename>, <surname>, <birthdate>, <deathdate>, <title>, etc.</li>

<li>In order to effectively represent the source(s) when many documents are
represented by the TEI header, we see the need for structured elements that, minimally,
allow us to identify parent-child and component relationships.</li>
</ul>

===Acknowledgments and Bibliography===
<ul>
<li>
This guide was prepared by Judy Ahronheim, Thomas Champagne, Lynn Marko, Kelly Webster, and Chris Wilcox of the University of
Michigan Library and Jackie Shieh of the University of Virginia Library in October 1998. The source documents were the cataloging
guides prepared by those two institutions ([http://www.lib.virginia.edu/cataloging/manual/chapters/chapxiib.html Virginia] and [http://www.lib.umich.edu/ts/sections/electronicresourcesdev.html Michigan]). In addition,
documentation from the Oxford Text Archive, Arts and Humanities Data Service of the United Kingdom also was made available to assist
in this effort.

</li>
<li>
For a description of TEI header elements and correstponding USMARC fields, see Appendix A at
[http://etext.lib.virginia.edu/tei/tei-usmarc.html http://etext.lib.virginia.edu/tei/tei-usmarc.html].
</li>
</ul>

==Encoding Levels==
===LEVEL 1: Fully Automated Conversion and Encoding===

'''Purpose''': To create electronic text with the primary purpose of keyword searching and linking to page images. The primary advantage in using the teixlite DTD at this level is that a TEI header is attached to the text file.

<p>
'''Rationale''': The text is subordinate to the page image, and is not intended to
stand alone as an electronic text (without page images).</p>

<p>Texts at Level 1 can be created and encoded by fully automated means, using uncorrected OCR of page
images ("dirty OCR"), exporting from existing electronic text files, or actually not including any text
at all. Only those elements that are necessary to divide the text from the header and facilitate linking to
page images are used. Encoding is performed automatically based on artifacts of the OCR or other
document creation process (page breaks, for example) and metadata collected during the imaging or
preparation process. This encoding is both minimal and reliable, and does not typically require
extensive review of each page of each text.</p>

<p>Level 1 texts are not intended to be adequate for textual analysis; they are more likely to be suited
to the goals of a preservation unit or mass digitization initiative. Though their encoding is minimal,
Level 1 texts are fully valid XML texts. In addition to taking advantage of the TEI header, using the
teixlite DTD--with the consistency suggested by these guidelines--allows Level 1 texts to be compatible
with more richly encoded teixlite texts (that also follow these guidelines) for
searching, for example. Further encoding based on document structures or content analysis can be added
to a Level 1 text at any time.</p>

<p>
'''Level 1 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>a large volume of material is to be made available online quickly</li>
<li>a digital image of each page is desired</li>
<li>no manual intervention will be performed in the text creation process</li>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>sophisticated search and display capabilities based on the structure of the text are not necessary</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<table border="1" width="80%">
<tr>
<td colspan="1"><div1></td>
<td colspan="1">If no type= attribute is specified, a type= value of
"section" should be presumed.</td>
</tr>

<tr>
<td colspan="1"><p></td>
<td colspan="1">At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using <p> in order that the document be open to being extended to other encoding levels).</td>
</tr>
<tr>

<td colspan="1"><pb></td>
<td colspan="1">Required in Level 1. Page images can be linked to the text by specifying a jpeg or other image file as the value of the facs= attribute. Page numbers can be supplied with the n= attribute to record the number that is on the page. The Task Force sees the use of METS here as having a tremendous advantage. METS/TEI page turning documentation will be included in the near future.</td>
</tr>
</table>

====Basic Structural Example:====
<pre>
<TEI.2 id="someid">
<teiHeader>
[Source and processing information goes here]
</teiHeader>
<text>
<body>
<div1>
<p>
<pb id="p00000001" n="1"/>
[main body of the unmarked up plain text begins here]
<pb id="p00000002" n="2"/>
[more plain text goes here with appropriate page breaks interspersed] ...
<pb id="p00000145" n="145"/>
[more plain text]
<pb id="p00000146" n="146"/>
[text ends here]
</p>
</div1>
</body>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level1example.html See an example in context…]

===LEVEL 2: Minimal Encoding===
'''Purpose''': To create electronic text for full-text searching, linking to page images, and identifying simple structural hierarchy to improve navigation.

'''Rationale''': The text is subordinate to the page image, though navigational markers (textual divisions, headings) are captured. The text could stand alone as electronic text (without page images) if the accuracy of its contents is suitable to its intended use and it is not necessary to display low-level typographic or structural information. Level 2 requires a set of elements more granular than those of Level 1, including bibliographic or structural information below the monographic or volume level.

Though texts at Level 2 can be created and encoded by automated means, based on the typographic elements in the electronic file (for example, bold centered text at the top of the page surrounded by whitespace indicates a new chapter heading, and thus a new division), it is not likely to be absolutely reliable across a large body of material. Level 2 encoding requires some human intervention to identify each textual division and heading. Level 2 texts do not require any special knowledge or manual intervention below the section level.

Level 2 texts are not intended to be displayed separately from their page images. Level 2 encoding of sections and headings provides greater navigational possibilities than Level 1 encoding, and enables searching to be restricted within particular textual divisions (for example, searching for two phrases within the same chapter).

'''Level 2 is most suitable for projects with the following characteristics''':

* a large volume of material is to be made available online quickly
* a digital image of each page is desired
* the material is of interest to a large community of users who wish to read texts that allow keyword searching
* rudimentary search and display capabilities based on the large structures of the text are desired
* each text will be checked to ensure that divisions and headers are properly identified
* extensibility is desired; that is, one desires to keep open the option for a higher level of encoding to be added at a later date

All elements specified in Level 1 plus the following:

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>
<td colspan="1">Optional</td>
</tr>
<tr>
<td colspan="1"><div1></td>
<td colspan="1">type="section" is the default attribute value. It is recommended that the n= attribute be
included to record the sequence of divisions.</td>
</tr>
<tr>
<td colspan="1"><head></td>
<td colspan="1">Required if present</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">One "container" element per div is required.</td>
</tr>
</table>

====Basic Structural Example:====

<pre>
<TEI.2 id="someid">
<teiHeader> [Source and processing information goes here] </teiHeader>
<text id="someotherid">
<front> [titlepage information, table of contents, prefaces, etc.] </front>
<body>
<div1 type="chapter" n="1">
<head>Chapter 1</head>
<p>[text of Chapter 1 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="2">
<head>Chapter 2</head>
<p>[text of Chapter 2 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="3">
<head>Chapter 3</head> [text of Chapter 3 goes here interspersed with <pb> elements
pointing to page images] </div1>
<div1 type="chapter" n="4">
<head>Chapter 4</head> [text of Chapter 4 goes here interspersed with <pb> elements
pointing to page images] </div1>
</body>
<back> [optional text of backmatter, appendices, etc.] </back>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level2example.html See an example in context…]

===LEVEL 3: Simple Analysis===

<p>
'''Purpose''': To create text that can stand alone as electronic text and identifies
hierarchy and typography without content analysis being of primary importance.</p>

<p>
'''Rationale''': Level 3 texts can be created from scratch or by the relatively easy
conversion of existing HTML or word-processing documents. Encoding offers the advantage of the TEI
header, interoperability with other TEI collections, and extensibility to higher levels of encoding.
Level 3 generally requires some human editing, but the features to be encoded are determined by the
appearance of the text and not specialized content analysis.</p>

<p>Level 3 texts identify front and back matter, and all paragraph breaks. The finer granularity of
encoding these features, as well as figures, notes, and all changes of typography, allows a range of
options for display, delivery, and searching. For example, one has the option of identifying and,
therefore, specifying the display charactersitics of different typographic styles, and regularizing the
display and placement of note text.</p>

<p>Level 3 texts can stand alone as text without page images and, therefore, can be uploaded, downloaded
and delivered quickly, and require less storage space than digital collections with page images.
However, the simple level of structural anaylsis and absence of specialized content analysis reflected
in Level 3 encoding may make it desirable for some, depending on project priorities, to include page
images in order to provide users with a fuller set of resources.</p>

<p>
'''Level 3 is most suitable for projects with the following characteristics:'''
</p>

<ul>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>some sophistication of display, delivery, and searching based on structure of the text is desired</li>
<li>each text will be checked to ensure that encoding decisions have been made appropriately</li>
<li>the users of the texts may have limited storage or display capabilities</li>
<li>the creator of the texts has limited or no ability to provide content expertise to analyze, tag,
or review texts</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<p>All elements specified in Levels 1 and 2, plus the following:</p>

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>

<td colspan="1">Required if present.</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">Required for paragraph breaks in prose; may be used for stanzas using <lb> for
line breaks in verse.</td>
</tr>

<tr>
<td colspan="1"><list> and <item></td>
<td colspan="1">May be used in this level to indicate ordered and unordered list structures.</td>
</tr>
<tr>
<td colspan="1"><table>, <row>, and <cell></td>

<td colspan="1">May be used to indicate table structures.</td>
</tr>
<tr>
<td colspan="1"><figure></td>
<td colspan="1">Required to indicate figures other than page images.</td>
</tr>
<tr>

<td colspan="1"><hi></td>
<td colspan="1">Required to indicate changes in typeface; rend attribute is optional.</td>
</tr>
<tr>
<td colspan="1"><note></td>
<td colspan="1">All notes must be encoded. It is also recommended that notes that extend beyond one page be combined into one <note> element. Marginal notes, without reference, should occur at the beginning of the paragraph to which they refer, with the value of the place attribute as "margin".</td>

</tr>
<tr>
<td colspan="1"><lb></td>
<td colspan="1">May be used to force line breaks.</td>
</tr>
</table>

<p>NOTE ON <note>:</p>

<p>It may be desirable to move footnotes from their original location in the text. If left at the bottom
of a page, a note may become included in another paragraph or section of the encoded text, and thus
separated from its reference. There are options for placement of footnotes if they are moved:</p>

<ul>
<li>Inline. The note is inserted at the point of reference. An n attribute records the value of the
note reference if there is one.</li>
<li>End-of-Division. Notes moved to the end of the division</li>
</ul>

<p>

'''Basic Structural Example forthcoming ...'''
</p>

===LEVEL 4: Basic Content Analysis===
<p>'''Purpose''': To create text that can stand alone as electronic text, identifies
hierarchy and typography, specifies function of textual and structural elements, and describes the
nature of the content and not merely its appearance. This level is not meant to encode or identify all
structural, semantic or bibliographic features of the text.</p>

<p>
'''Rationale''': Greater description of function and content allows for:</p>

<ul>
<li>flexibility of display and delivery</li>
<li>sophisticated searching within specified textual and structural elements</li>
<li>combining the broadest range of uses and audiences</li>

</ul>

<p>Texts encoded at Level 4 are able to stand alone as part of a library collection, and do not require
page images in order for them to be read by students, scholars and general readers. This level of TEI
encoding allows them to be displayed or printed in a variety of ways suitable for classroom or scholarly
use.</p>

<p>Level 4 texts contain elements and attributes that describe content. For example, lines of verse are
tagged with <l>; the <p> element is reserved for true paragraphs. Features of
the text that may contribute to meaning, such as indentation of verse lines and typographic change, are
preserved. These are textual features that are not encoded at lower levels and that allow the text to be
used and understood fully independent of images.</p>

<p>The ability to stand alone as text means that Level 4 texts are more nimble and robust for exercises
such as format repurposing and textual analysis.</p>

<p>Finally, functionally accurate encoding in Level 4 texts
allows them to be searched or displayed in sophisticated ways.
For example, a searcher could limit his or her search in a
dramatic text to stage directions or in a verse text to only
first lines. In a politicall tract published by subscription, a
search could be confined to names that appear in lists, thus
limiting a search to names of people who subscribed to a
particular volume. This ability to limit searches becomes more
significant as textbases become larger, and thus is of great
importance to the library community as it attempts to build into
the initial design and implementation of textbases the features
needed to enhance interoperability.</p>

<p>
'''Level 4 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>sophisticated search and retrieval capabilities are desired</li>

<li>the texts will be used for textual analysis</li>
<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added by the scholarly community at a later date</li>
<li>the users of the texts may have limited storage or display capabilities</li>
</ul>

====General Level 4 Recommendations====
<ul>
<li>Typographically distinct text should be encoded as appropriate,
e.g. with <term>, <q>, <gloss>, <mentioned>, <soCalled>, <foreign>,
<title>, or <emph>. Any ambiguous emphasized text should be
encoded as <hi> (e.g. <hi rend="bold">).</li>
<li>It is recommended that the <sic> element be used to
indicate typographic errors, with corrections (if any) noted
as the value of the corr= attribute.</li>
<li><titlePage> should include the verso if present, divided by <pb
n="verso"/>. Tables of contents, errata, subscription lists, "other titles by the same author"
should be included in a separate numbered division, as a <list> with <item>s.
Frontispieces should be encoded as a <figure>, within a separate numbered division and
<p>.</li>
</ul>

[http://www.diglib.org/standards/level4genrec.html See some examples in context…]

====Level 4 Prose====
<ul>
<li>Letters that occur within the text body provide some challenges. It is recommended that quoted
letters that occur as part of a text (and not collections of letters themselves) be encoded within
<q><text><body><div1 type="letter">, with
<opener>, <dateline>, <salute>, <signed>,
<closer> included as appropriate.</li>

<li>Quotations that do not occur inline, but are set off typographically in some way, should be
encoded as <q>.</li>
<li>Notes are to be encoded as described in Level 3.</li>
<li><argument>, <opener>, <epigraph>,
<closer>, <trailer>, <add>, <del>,
<unclear> as appropriate.</li>

</ul>

[http://www.diglib.org/standards/level4prose.html See some examples in context…]

====Level 4 Drama====
<ul>
<li>Cast lists should be encoded as <list>s, with <item>s.</li>

<li>Speeches are encoded as <sp>, with speakers identified within
<speaker> elements; stage directions are encoded as <stage> and enclose
block level content describing scenery, etc.</li>
</ul>

[http://www.diglib.org/standards/level4drama.html See some examples in context…]

====Level 4 Oral History====
<ul>
<li>Speakers in interviews can be identified in the <teiHeader> in several ways.
<ul>
<li>In the <profileDesc>, in the <particDesc> in a <list>, with <name> inside of <item>s.</li>

<li>As a list of author <name>s within <fileDesc><titleStmt></li>
</ul>
</li>
<li>In either method, use an id= on the <name> element to uniquely identify the individual participant</li>

<li>Questions and answers from interviewees and interviewers are encoded as <sp>,
with speakers identified within <speaker> elements with a who= attribute the value of which
corresponds to the id= in the list of interview participants.</li>
</ul>
[http://www.diglib.org/standards/level4oh.html See some examples in context…]

====Level 4 Verse====
<ul>
<li>All verse, even poems without separate stanzas or verse paragraphs, should be contained within a
line group element <lg>. This will assist with automated processing and retrieval.</li>
<li>It is common to see informal divisions within poems, noted by a string of asterisks or periods.
These should be encoded as <milestone/>s with attribute values of unit="typography" and
n="()" indicating the character used and its occurrence, <milestone unit="typography"
n="******"/>.</li>
<li><l> It is recommended that indentation be recorded and that the rend attribute be
used to do this.</li>
</ul>
[http://www.diglib.org/standards/level4verse.html See some examples in context…]
====Level 4 Front and Back Matter====
<ul>
<li>It is recommended that all prefaces, tables of contents, afterwords, appendices, endnotes and
apparatus be encoded. For publisher's advertisements, indexes, and glossaries or other front or back
matter that isn't considered of primary importance to the text, there are three options:<ul>
<li>Fully transcribe and encode</li>
<li>Link to page images (may include an unencoded transcription)</li>
<li>Omit, noted in <editorialDesc></li>
</ul>
</li>
</ul>
[http://www.diglib.org/standards/level4fandb.html See some examples in context…]

===LEVEL 5: Scholarly Encoding Projects===

<p>Level 5 texts are those that require subject knowledge, and encode semantic, linguistic, prosodic or
other elements beyond a basic structural level.</p>

==General Guidelines for Attribute Usage==

<p>Some general advice on the use of particular attributes
follows.</p>
<ul>
<li><b>type=</b>: Constructing a list of acceptable attribute values
for type that could find wide agreement is impossible. Instead,
it is recommended that projects describe the type= attribute
values used in their texts in the project ODD file or other
documentation and that this list be made available to people
using the texts. See <i>ABC for Book Collectors</i> by John
Carter (7th edition, New Castle, DE:Oak Knoll Books, 1995) for
a list of standard names and definitions of bibliographic
features of printed books. For those elements where type is not
required, such as <head> and <title>, use the
attribute values for subtitles and additional titles, but not
main titles.<br /> Example: <div1 type="volume"></li>

<li><b>n=</b>: Sometimes an n= (number) attribute can be used by itself. For instance in the case of
pagebreaks:<br /> Example: <pb n="456"/></li>

<li><b>id=</b>: If you are in a situation that requires you to
uniquely identify an element that will be used to reference
another specific location in one or more texts, use an id=
attribute. The value of this attribute must be unique within a
document, and must be composed of alphanumeric characters,
dots, hyphens, and underscores, and must start with a
letter.<br /> Example: <note id="n5" n="5"></li>

<li><b>target=</b>: follows the same syntactic rules as the id=
attribute value. In fact, target= and id= are often used in
conjunction with one another as in the case of footnotes where
the <anchor id="n5" n="5"> is at a specific place in the
text and is referred to by the <note target="n5" n="5">
which contains the actual information of the footnote itself
elsewhere.</li>

<li><b>entity=</b>: The entity= attribute is simply the way a
figure indirectly points or refers to its the actual image
file<br /> Example:
<!ENTITY TwaFifrn SYSTEM "TwaFifrn.jpg" NDATA jpeg><br />
<br />
<figure entity="TwaFifrn"></li>

<li><b>rend=</b>: Difficulty using rend= attributes occurs when it is desirable to record
more than one rendition feature. With this in mind, it is recommended that projects employ the
following adaptation of "rendition ladders", a concept developed at the [http://www.wwp.brown.edu/ Brown University Women Writers Project]. This system allows for sets
of multiple renditional features to be included in one rend= value. Rendition ladders consist of categories of
renditional features with values of each of those features enclosed in parentheses.<br /> rend= should only be
used to override a default value. For instance, if all text encoded as <hi> is defined as being
rendered in italics, there is no reason to encode text as <hi rend="font(italics)"> Combining renditional features would result in a tag with attributes such as <l rend="font(italics)align(right)">
<ul>
<li>font <br />italics, bold, fsc (full and smallcaps), smallcap, underlined, gothic</li>
<li>align <br />right, left, center, block</li>
<li>indent <br />Values in parentheses should indicate the number of tabstops to be indented, e.g.,
<l rend="indent(1)"></li>
</ul>
</li>
<li><b>lang=</b>: Use ISO639-2 three-character language codes. Note that this recommendation is slightly different from that of the TEI P5 Guidelines, which recommends the BCP 47 language codes.</li>
</ul>
References: <references/>
[[Category:SIG:Libraries]]

Best Practices for TEI in Libraries

2008-09-22T13:56:29Z

Melanieschlosser: /* <profileDesc> */

[http://www.tei-c.org/wiki/index.php/SIG:Libraries TEI in Libraries: Home]

==Introduction and History==
<p>The Text Encoding Initiative Guidelines for Electronic Text Encoding and Interchange (referred to as
the <i>TEI Guidelines</i>) were first published in 1994 and represent a tremendous
achievement in electronic text standards by providing a highly sophisticated structure for encoding
electronic text. Digital librarians have benefited greatly from the standardization provided by these
guidelines, and the potential for interoperability and long-term preservation of digital collections
facilitated by their wide adoption.</p>

<p>In 1998, the Digital Library Federation (DLF) sponsored the [http://www.lib.umich.edu/lit/dlps/history/teidlf/index.html TEI and XML in Digital Libraries Workshop] at the
Library of Congress to discuss the use of the <i>TEI Guidelines</i> in libraries for electronic text,
and to create a set of best practices for librarians implementing them. From this workshop, three working
groups were formed the members of which represented some of the largest and most mature digital library
programs in the U.S. Group 2 was charged with developing a set of recommendations for libraries using the
TEI Guidelines in electronic text encoding. This group included the following representatives from six libraries:
</p>
<ul>
<li>LeeEllen Friedland, Library of Congress</li>
<li>Nancy Kushigian, University of California, Davis</li>
<li>Christina Powell, University of Michigan</li>
<li>David Seaman, University of Virginia</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>At the ALA mid-winter (January 1999), the DLF task force revised a draft set of best practices, called
TEI Text Encoding in Libraries: Guidelines for Best Practices (referred to as <i>TEI in Libraries
Guidelines</i>). The revised recommendations were circulated to the conference working group in May
1999 and presented at the joint annual meeting of the Association of Computers and the Humanities and
Association of Literary and Linguistic Computing in June 1999. [http://www.diglib.org/standards/tei-old.htm Version 1.0] was circulated for comments in
August 1999. These guidelines were endorsed by the DLF, and have been used by many digital libraries,
including those of the task force members, as a model for their own local best practices. Libraries,
museums and end-users have benefitted from a set of best practices for electronic text in a number of
ways, including better interoperability between electronic text collections, better documented practices
among digital libraries, and a starting point for discussion of best practices with commercial publishers
regarding electronic text creation.</p>

<p>Written in 1998, this first iteration of <i>TEI in Libraries Guidelines</i> made no mention of XML,
XSLT, or any of the other powerful tools that have now become common parlance and practice in creating
digital documents and collections. Based on these important changes in markup technology, it came to the
attention of the DLF and members of the original Task Force that the <i>TEI in Libraries Guidelines</i>
required substantial revision. In 2002, the TEI Consortium published a new edition of the complete
<i>TEI Guidelines</i> that conformed to XML specifications. In order to remain useful, the <i>TEI in
Libraries Guidelines</i> had to be updated to reflect these developments.</p>

<p>Furthermore, librarians need more guidance than the original <i>TEI in Libraries Guidelines</i>
provided. There are many library-specific encoding issues which need to be addressed and documented to
ensure consistency. The intention of this document is to provide recommended paths of encoding for these
issues.</p>

<p>In addition, these library guidelines have the potential to be much more useful if they can serve as a
training document from which librarians can learn about text encoding and addressing particular encoding
challenges. To fulfill this role, the guidelines require more examples and detailed explanations,
giving documentation of the use of TEI in a library context. Librarians also need a set of standards
and best practices for vendors and publishers who create electronic text for digital libraries, so that
these collections adhere to the same archival standards as locally-created electronic text collections.
With detailed guidelines that could serve as an encoding specification, librarians might encourage
vendors to follow the principles in these standards, to facilitate the long-term preservation of
commercially published electronic text collections, and more readily allow for cross-collection
searching.</p>

<p>In order to facilitate the evolution of this document, another DLF-sponsored Task Force—some
of the representatives of which were on the original Task Force—met on October 24-25, 2003 at
the Cosmos Club in Washington, D.C.: </p>
<ul>
<li>Richard Gartner, Oxford University Library</li>
<li>Matthew Gibson, University of Virginia Library</li>
<li>Kirk Hastings, California Digital Library</li>
<li>Christina Powell, University of Michigan</li>
<li>Merrilee Proffitt, RLG</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>These representatives met to revise the original <i>TEI in Libraries Guidelines</i> in order
that they: </p>
<ul>
<li>reflect changes occuring within the text encoding world generally and within the TEI
community specifically</li>
<li>further illuminate the different levels of encoding by offering clearer and more robust
examples.</li>
</ul>
<p>After producing [http://www.diglib.org/standards/tei2/tei20.htm Version 2.0] of the Guidelines, this group (with some changes in membership) met again
at the Cosmos Club on February 13-14, 2006. Those in attendance were: </p>
<ul>
<li>Syd Bauman, The TEI Consortium</li>
<li>Richard Gartner, Oxford University Library (by phone)</li>
<li>Matthew Gibson, Virginia Foundation for the Humanities (chair)</li>
<li>Merrilee Proffitt, RLG</li>
<li>Chris Powell, The University of Michigan</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natasha Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, The University of Michigan</li>
</ul>
<p>This group of continues to meet and based upon their discussions and resolutions, the following
guidelines will continue to be updated and enhanced.</p>

==General Overview and Comments==

<p>These recommendations are for libraries using the XML version of the TEILite DTD (teixlite).
There are many different library text digitization projects, for different purposes. With this in mind,
the Task Force has attempted to make these recommendations as inclusive as possible by developing a
series of encoding levels. These levels are meant to allow for a range of practice, from wholly automated
text creation and encoding, to encoding that requires expert content knowledge, analysis, and editing.</p>

<p>Recommendations for Levels 1-4 are intended for projects wishing to create encoded electronic text with
structural markup, but minimal semantic or content markup. Also, the encoding levels are cumulative:
encoding requirements at each level incorporate the requirements of lower levels. Levels 1-4 allow the
conversion and encoding of texts to be performed without the assistance of deep content knowledge and can
be enriched with more markup at any time. Level 5, in contrast, requires scholarly analysis. </p>

<p>These recommendations are concerned with the text portion of a TEI-encoded document. While there are
modest requirements for including certain information about encoding level in the TEI header, a separate
set of recommendations, now integrated into this document, was developed to address issues concerning TEI header
contents to MARC-format bibliographic data (see the [[#The TEI Header (based on June 16, 2001 Draft)|<teiHeader> section]]).</p>

==General Recommendations==

<p>Note: all recommendations that follow are based on P4:2004, with the exception of the facs= attribute of <pb>, which comes from the P5 module for the transcription of primary sources ('transcr').</p>

<ul>
<li>The encoding level (as described in this document) should be recorded in the
<editorialDecl> in the TEI header, along with an explanation of any deviation from the
recommendations.</li>

<li>Electronic text at all levels of encoding should begin with the transcription of the first word on
the first leaf of the original work. It may be impractical or undesirable to transcribe and encode
certain features of the text, such as publisher's advertisements or indexes, but if at all possible,
they should be included as links to page images. Any omissions of material found in the original work
should be noted in the <editorialDecl> in the TEI header.</li>
<li>File naming should follow ISO 9660 conventions: 8-character filenames, 3-character extensions,
using A-Z, a-z, 0-9, underscores and hyphens. The rationale behind this suggestion is that when moving
texts across different platforms (DOS for instance), some systems will truncate beyond the eighth
character.</li>
<li>We recommend the use of numbered divisions throughout the electronic text, always beginning with
<div1> (we prefer that <div0> not be used since the TEI Guidelines does not
make it available in <front> or <back> matter). Numbered divisions present
advantages to search and indexing software by explicitly communicating the hierarchical level of the
section described. Texts at all levels should include at least one <div1>.</li>
<li>Page breaks should be encoded using the <pb> element,
which should demark the top of a page (i.e. the text of page
seven should immediately follow <pb n="7"/>), and should
always be contained within a division. E.g., a page break that
occurs between chapters 2 and 3 should be encoded near the top
of the <div> that holds chapter 3 (rather than near the bottom
of the <div> that holds chapter 2).</li>
</ul>

==The TEI Header==

===Introduction===
<p>At the TEI and XML in Digital Libraries Workshop that was held at the Library of Congress in July 1998, several working groups
were formed to consider various aspects of the Text Encoding Initiative. Group 1 was charged to recommend some best practices
for TEI header content and to review the relationship between the Text Encoding Initiative header and MARC. To this end,
representatives of the University of Virginia Library and the University of Michigan Library gathered in Ann Arbor in early
October 1998 to develop a recommended practice guide. This work was assisted by similar efforts that had taken place in the United
Kingdom under the auspices of the Oxford Text Archive the previous year.
The following document represents a draft of those recommended practices. It has been submitted to various constituencies for
comment.</p>

===Working Assumptions===
<p>A TEI header can serve many publics. Headers can be created in a text center and reflect the center's standards, or they can
serve as the basis for other types of metadata system records produced by other agencies. Headers can function in detached
form as records in a catalog, as a title page inherent to the document, or as a source for index displays.</p>

<p>In addition, a header may describe a collection of documents, a single item, or a portion of an item. Variances in TEI header
content can result from making different choices of what is being described.</p>

<p>A TEI header may not have a one to one correspondence with a MARC record. One TEI header may have multiple MARC analytic records,
or one MARC record may be used to describe a collection of TEI documents with individual headers.</p>

<p>A TEI header serves several purposes. It may contain an historical background on how the file has been treated. It can extend the
information of a classic catalog record. The Text Center and/or cataloging agency can act as the gatekeeper for creators by
providing standards for content.</p>

===Cataloging a TEI Document===

<p>Does the TEI header act as the electronic title page or as a catalog record? Is it integral to the document it describes or
independent? Depending on the community being served, the TEI elements will reflect the interest of that community. Nonetheless,
it is possible to describe a set of "best practices" that will produce compatible content while accommodating this variety of
purposes. Compatibility of content encourages a more understandable set of results when information about assorted items is
displayed as a set of search results, a contents list, or an index, and it allows for more reasonable conversion of content
information from TEI elements to elements of other metadata sets when this action seems advisable.</p>

<p>It is a traditional practice of librarianship to agree upon where in a document and in what order of preference one should look
to identify the title, author, etc., of that document. This permits a certain consistency in terminology and allows for a certain
amount of authentication of content. We recommend the following preferences to those who create headers and to those who attempt
to use headers to create traditional catalog records that are compliant with AACR2 and ISBD(ER) rules.</p>

<p>As a member of the academic community, the header creator/editor has a responsibility to verify, whenever humanly possible, the
intellectual source for an electronic document that presents itself without any information regarding its source or authorship.</p>

====Chief Sources of Information for Several Types of Electronic Resources Are:====
<ul> <li>1. For an electronic document with a digitized title page (without a header), prefer
<ul>
<li>a) Chief source of information = information coded as title page</li>
<li>b) Use added information from an originating paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>2. Electronic document with header (without a title page)
<ul>
<li>a) Chief source of information = supplied and verified header <ref name="verify">Verified means that the cataloger/editor has established for him/herself that the information represented as title information is an accurate representation of content.</ref></li>

<li>b) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>

<li>3. Electronic document with header and title page
<ul>
<li>a) Chief source of information = supplied header (if verified)<ref name="verify"/></li>
<li>b) If header is not verified, use title page as chief source</li>
<li>c) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>4. If neither header nor title page is present and there is no evidence of a source document, the header creator
<ul>
<li>a) May assign a title and author if appropriate</li>
<li>b) Enclose the information in brackets, using the standard English language convention for editorial interjections</li>
</ul>
</li>
<li>5. If neither header nor title page is present but the header creator has satisfactory evidence of an originating source, that
document should be used as the chief source of information for the title and author of the header. If the source cannot be fully
verified as to edition, authorship, etc., this fact should be clearly indicated in a note in the <fileDesc>.
</li>

</ul>

===Element Recommendations for the <teiHeader>===

<table border="1" width="80%">
<tr>
<td colspan="1"><teiHeader type="____"></td>
<td colspan="1">
Standards which apply to the header, e.g., <teiHeader type="ISBD(ER)">, <teiHeader
type="AACR2">
</td>
</tr>
</table>

===<fileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<title type="____"></td>
<td colspan="1">
Only uniform title and main title for the TEI document, not the source document, should be entered here, e.g., <title type="uniform"> or <title type="main">. See <sourceDesc> for other title forms for documents where a user might seek the documents under titles other than those assigned. Where a title is supplied, the title should be enclosed in square brackets using standard English-language conventions for editorial insertion.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of original source (electronic or print) should be entered into the <author> element before the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.
</td>
</tr>

<tr>
<td colspan="1">
<editor></td>
<td colspan="1">
Editor of original source (electronic or print) should be entered into the <editor> element <b>before</b> the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.</td>

</tr>

<tr>
<td colspan="1">
<respStmt></td>
<td colspan="1">
The editor (also compiler, illustrator) of the TEI document, not the source document, should be entered here. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<editionStmt></td>

<td colspan="1">
This element should be used sparingly as there are currently no standards as to when versions become editions. Users should refer to the TEI guidelines.</td>
</tr>

<tr>
<td colspan="1">

<extent></td>
<td colspan="1">
Use the standard text "ca.**** kilobytes".</td>
</tr>

<tr>
<td colspan="1">

<publicationStmt></td>
<td colspan="1">
Use the child elements below rather than <p> for a prose description.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
The publisher is whoever has collected the TEI document, not the source document, and has made decisions concerning it.</td>
</tr>

<tr>

<td colspan="1">

<distributor></td>
<td colspan="1">
The distributor is whoever makes the TEI document, not the source document, available.</td>
</tr>

<tr>
<td colspan="1">
<idno></td>
<td colspan="1">
Any unique identification number determined by the publisher. Use type="OCLC-___" to point to the catalog record for the TEI document, if applicable. The institution's three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<availability status=" "><p></td>
<td colspan="1">
Describe any rights statement for the TEI document. Use a standard scheme, such as the code for a Creative Commonse license, for the value of the status attribute if possible.</td>
</tr>

<tr>
<td colspan="1">
<date></td>
<td colspan="1">
Refers to the date of the first publication of the TEI document. <b>For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.</b></td>
</tr>

<tr>
<td colspan="1">
<seriesStmt><title></td>

<td colspan="1">
Whenever possible, establish or use the name from a national name authority file authorized for the electronic, locally created series.
</td>
</tr>

<tr>
<td colspan="1">
<notesStmt></td>

<td colspan="1">
Optional, for indicating questionable attributions for title, author, etc.</td>

</tr>

<tr>
<td colspan="1">
<sourceDesc></td>
<td colspan="1">
In order to effectively represent the source(s) when many documents are represented by the TEI header, we see the need for structured elements that minimally allow us to identify parent-child and component relationships. In the absence of these structures, we suggest that multiple source descriptions be employed with relationships described in free text. Relationships also could be useful in other portions of the TEI header. Cataloger may need to do research to establish the original source.</td>
</tr>

<tr>

<td colspan="1">
<bibl> or
<biblFull></td>
<td colspan="1">
Use <bibl> with child elements listed below. metadata for the source document is automatically generated from a MARC record. It is suggested that child elements appear in the following order for ease of display according to ISBD: <author>, <title type="245a">, <title type="245b">, <respStmt>, <edition>, <pubPlace>, <publisher>, <date>, <extent>, <title type="series">, <note>, <idno type="isbn-13">, <idno type="isbn-10">, <idno type="OCLC-___">. Use <biblFull> for exhaustive description created by hand. </td>

</tr>

<tr>
<td colspan="1">
<title></td>
<td colspan="1">
Title of the source document. It is possible to have multiple <title> elements. Alternative titles (cover, running, spine titles) should be entered in separate <title> elements in <biblFull>.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of the source document. It is possible to have multiple <author> elements. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">

<editor></td>
<td colspan="1">
Editor of the source document. It is possible to have multiple <editor> elements.</td>
</tr>

<tr>
<td colspan="1">

<respStmt></td>
<td colspan="1">
If using <bibl> and generating from a MARC record, use this for the statement of responsibility (MARC field 245, subfield c).</td>
</tr>

<tr>
<td colspan="1">

<editionStmt></td>
<td colspan="1">
Edition statement in the source document (if present).</td>
</tr>

<tr>
<td colspan="1">
<extent></td>

<td colspan="1">
Enter physical description for the original source. If using <bibl> and generating from a MARC record, use this for MARC field 300.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
Don't repeat field. Enter multiple publishers divided by semicolons.</td></tr>

<tr>
<td colspan="1">
<pubPlace></td>
<td colspan="1">

Don't repeat field. Enter multiple publication places divided by semicolons.</td>
</tr>

<tr>
<td colspan="1">
<date></td>

<td colspan="1">
Imprint date for the original source. '''For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.'''</td>
</tr>

<tr>

<td colspan="1">
<idno></td>
<td colspan="1">
In this location, <idno> refers to identification numbers for the source document. They can be used to indicate the source's location in an individual institution's collection. If a formal standard location system is being used, indicate the nature of the system, e.g., <idno type="LC call number">. If using <bibl> and generating from a MARC record, use type="isbn-13" and type=-"isbn-10" if applicable. Use type="LC call number" (or appropriate abbreviation) for a call number. Use type="OCLC-___" to point to the catalog record for the source document. The institution’s three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<seriesStmt> or <series></td>

<td colspan="1">
Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<notes></td>

<td colspan="1">
Notes about the source document. If using <bibl> and generating from a MARC record, use for the value of MARC field 500.</td>
</tr>
</table>

===<encodingDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<projectDesc></td>
<td colspan="1">Enter a description of the purpose for which the electronic file was encoded.</td>
</tr>

<tr>
<td colspan="1">
<editorialDecl></td>
<td colspan="1">
Enter general and specific statements about how the electronic file has been treated. Record here editorial decisions made
during encoding.</td>

</tr>

<tr>
<td colspan="1">
<refsDecl></td>
<td colspan="1">
<refsDecl> could be used for administrative metadata, e.g., pagination and page sequencing.</td>
</tr>

<tr>

<td colspan="1">

<classDecl> <taxonomy id="____"> <bibl></td>
<td colspan="1">
If used, identify the appropriate taxonomy definitions or descriptive sources in the <taxonomy> element followed by id, e.g.,
<taxonomy id="LCSH"> <bibl>Library of Congress Subject Headings</bibl> </taxonomy>, <taxonomy id="AAT"> <bibl> Art & Architecture Theasaurus</bibl> </taxonomy>.</td>
</tr>
</table>

===<profileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">

<langUsage> <language id="____"></td>
<td colspan="1">
Use the ISO 639-2 standard (which is the same as the MARC language codes) for the id attribute. The content of the element should be the name of the language given in ISO 639-2.</td>

</tr>

<tr>
<td colspan="1">
<classCode scheme="___"></td>
<td colspan="1">
True classification numbers as opposed to call numbers can be entered here.</td>

</tr>

<tr>
<td colspan="1">
<keywords><br />

<term>
</td>
<td colspan="1">
Use for uncontrolled terms.</td>
</tr>

<tr>
<td colspan="1">
<keywords scheme="____"><br />
<term>
</td>
<td colspan="1">
Use for controlled vocabulary as specified in <encodingDesc> taxonomy id. Example: scheme="LCSH"</td>

</tr>
</table>

===<revisionDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<change>
<resp>
<item></td>
<td colspan="1">
Use the specific codes to note revisions rather than free text description. Include the entire date
(e.g., 19991101).</td>

</tr>
</table>

===Minimal TEI Header Recommendation===
<blockquote>
<div class="indent"><teiHeader></div>
<div class="lindent"><fileDesc></div>

<div class="lindent2"><titleStmt></div>
<div class="lindent3"><title></title></div>
<div class="lindent3"><author></author></div>
<div class="lindent2"></titleStmt>

</div>
<div class="lindent2"><publicationStmt>
</div>
<div class="lindent3"><publisher></publisher>

</div>
<div class="lindent3"><pubPlace></pubPlace>
</div>
<div class="lindent3"><idno></idno>
</div>
<div class="lindent3"><availability><p></p></availability>
</div>
<div class="lindent3"><date></date>

</div>
<div class="lindent2"></publicationStmt>

</div>
<div class="lindent2"><sourceDesc>
</div>
<div class="lindent3"><biblFull>
</div>
<div class="lindent4"><titleStmt>
</div>
<div class="lindent5"><title></title>

</div>
<div class="lindent5"><author></author>
</div>
<div class="lindent4"></titleStmt>
</div>
<div class="lindent4"><publicationStmt>
</div>
<div class="lindent5"><publisher></publisher>
</div>
<div class="lindent5"><pubPlace></pubPlace>

</div>
<div class="lindent5"><date></date>
</div>
<div class="lindent4"></publicationStmt>
</div>
<div class="lindent3"></biblFull>
</div>
<div class="lindent2"></sourceDesc>
</div>
<div class="lindent"></fileDesc>
</div>

<div class="indent"></teiHeader>
</div>
</blockquote>

Repeat the <biblFull> field, as appropriate, if there is more than one source for the electronic item. [http://www.diglib.org/standards/teiheaders.html See some examples in context …]

===Recommended Additions to the teixlite DTD===
<ul>
<li>Add elements under <name> to allow for the variable ordering and alphabetization of names:
<forename>, <surname>, <birthdate>, <deathdate>, <title>, etc.</li>

<li>In order to effectively represent the source(s) when many documents are
represented by the TEI header, we see the need for structured elements that, minimally,
allow us to identify parent-child and component relationships.</li>
</ul>

===Acknowledgments and Bibliography===
<ul>
<li>
This guide was prepared by Judy Ahronheim, Thomas Champagne, Lynn Marko, Kelly Webster, and Chris Wilcox of the University of
Michigan Library and Jackie Shieh of the University of Virginia Library in October 1998. The source documents were the cataloging
guides prepared by those two institutions ([http://www.lib.virginia.edu/cataloging/manual/chapters/chapxiib.html Virginia] and [http://www.lib.umich.edu/ts/sections/electronicresourcesdev.html Michigan]). In addition,
documentation from the Oxford Text Archive, Arts and Humanities Data Service of the United Kingdom also was made available to assist
in this effort.

</li>
<li>
For a description of TEI header elements and correstponding USMARC fields, see Appendix A at
[http://etext.lib.virginia.edu/tei/tei-usmarc.html http://etext.lib.virginia.edu/tei/tei-usmarc.html].
</li>
</ul>

==Encoding Levels==
===LEVEL 1: Fully Automated Conversion and Encoding===

'''Purpose''': To create electronic text with the primary purpose of keyword searching and linking to page images. The primary advantage in using the teixlite DTD at this level is that a TEI header is attached to the text file.

<p>
'''Rationale''': The text is subordinate to the page image, and is not intended to
stand alone as an electronic text (without page images).</p>

<p>Texts at Level 1 can be created and encoded by fully automated means, using uncorrected OCR of page
images ("dirty OCR"), exporting from existing electronic text files, or actually not including any text
at all. Only those elements that are necessary to divide the text from the header and facilitate linking to
page images are used. Encoding is performed automatically based on artifacts of the OCR or other
document creation process (page breaks, for example) and metadata collected during the imaging or
preparation process. This encoding is both minimal and reliable, and does not typically require
extensive review of each page of each text.</p>

<p>Level 1 texts are not intended to be adequate for textual analysis; they are more likely to be suited
to the goals of a preservation unit or mass digitization initiative. Though their encoding is minimal,
Level 1 texts are fully valid XML texts. In addition to taking advantage of the TEI header, using the
teixlite DTD--with the consistency suggested by these guidelines--allows Level 1 texts to be compatible
with more richly encoded teixlite texts (that also follow these guidelines) for
searching, for example. Further encoding based on document structures or content analysis can be added
to a Level 1 text at any time.</p>

<p>
'''Level 1 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>a large volume of material is to be made available online quickly</li>
<li>a digital image of each page is desired</li>
<li>no manual intervention will be performed in the text creation process</li>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>sophisticated search and display capabilities based on the structure of the text are not necessary</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<table border="1" width="80%">
<tr>
<td colspan="1"><div1></td>
<td colspan="1">If no type= attribute is specified, a type= value of
"section" should be presumed.</td>
</tr>

<tr>
<td colspan="1"><p></td>
<td colspan="1">At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using <p> in order that the document be open to being extended to other encoding levels).</td>
</tr>
<tr>

<td colspan="1"><pb></td>
<td colspan="1">Required in Level 1. Page images can be linked to the text by specifying a jpeg or other image file as the value of the facs= attribute. Page numbers can be supplied with the n= attribute to record the number that is on the page. The Task Force sees the use of METS here as having a tremendous advantage. METS/TEI page turning documentation will be included in the near future.</td>
</tr>
</table>

====Basic Structural Example:====
<pre>
<TEI.2 id="someid">
<teiHeader>
[Source and processing information goes here]
</teiHeader>
<text>
<body>
<div1>
<p>
<pb id="p00000001" n="1"/>
[main body of the unmarked up plain text begins here]
<pb id="p00000002" n="2"/>
[more plain text goes here with appropriate page breaks interspersed] ...
<pb id="p00000145" n="145"/>
[more plain text]
<pb id="p00000146" n="146"/>
[text ends here]
</p>
</div1>
</body>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level1example.html See an example in context…]

===LEVEL 2: Minimal Encoding===
'''Purpose''': To create electronic text for full-text searching, linking to page images, and identifying simple structural hierarchy to improve navigation.

'''Rationale''': The text is subordinate to the page image, though navigational markers (textual divisions, headings) are captured. The text could stand alone as electronic text (without page images) if the accuracy of its contents is suitable to its intended use and it is not necessary to display low-level typographic or structural information. Level 2 requires a set of elements more granular than those of Level 1, including bibliographic or structural information below the monographic or volume level.

Though texts at Level 2 can be created and encoded by automated means, based on the typographic elements in the electronic file (for example, bold centered text at the top of the page surrounded by whitespace indicates a new chapter heading, and thus a new division), it is not likely to be absolutely reliable across a large body of material. Level 2 encoding requires some human intervention to identify each textual division and heading. Level 2 texts do not require any special knowledge or manual intervention below the section level.

Level 2 texts are not intended to be displayed separately from their page images. Level 2 encoding of sections and headings provides greater navigational possibilities than Level 1 encoding, and enables searching to be restricted within particular textual divisions (for example, searching for two phrases within the same chapter).

'''Level 2 is most suitable for projects with the following characteristics''':

* a large volume of material is to be made available online quickly
* a digital image of each page is desired
* the material is of interest to a large community of users who wish to read texts that allow keyword searching
* rudimentary search and display capabilities based on the large structures of the text are desired
* each text will be checked to ensure that divisions and headers are properly identified
* extensibility is desired; that is, one desires to keep open the option for a higher level of encoding to be added at a later date

All elements specified in Level 1 plus the following:

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>
<td colspan="1">Optional</td>
</tr>
<tr>
<td colspan="1"><div1></td>
<td colspan="1">type="section" is the default attribute value. It is recommended that the n= attribute be
included to record the sequence of divisions.</td>
</tr>
<tr>
<td colspan="1"><head></td>
<td colspan="1">Required if present</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">One "container" element per div is required.</td>
</tr>
</table>

====Basic Structural Example:====

<pre>
<TEI.2 id="someid">
<teiHeader> [Source and processing information goes here] </teiHeader>
<text id="someotherid">
<front> [titlepage information, table of contents, prefaces, etc.] </front>
<body>
<div1 type="chapter" n="1">
<head>Chapter 1</head>
<p>[text of Chapter 1 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="2">
<head>Chapter 2</head>
<p>[text of Chapter 2 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="3">
<head>Chapter 3</head> [text of Chapter 3 goes here interspersed with <pb> elements
pointing to page images] </div1>
<div1 type="chapter" n="4">
<head>Chapter 4</head> [text of Chapter 4 goes here interspersed with <pb> elements
pointing to page images] </div1>
</body>
<back> [optional text of backmatter, appendices, etc.] </back>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level2example.html See an example in context…]

===LEVEL 3: Simple Analysis===

<p>
'''Purpose''': To create text that can stand alone as electronic text and identifies
hierarchy and typography without content analysis being of primary importance.</p>

<p>
'''Rationale''': Level 3 texts can be created from scratch or by the relatively easy
conversion of existing HTML or word-processing documents. Encoding offers the advantage of the TEI
header, interoperability with other TEI collections, and extensibility to higher levels of encoding.
Level 3 generally requires some human editing, but the features to be encoded are determined by the
appearance of the text and not specialized content analysis.</p>

<p>Level 3 texts identify front and back matter, and all paragraph breaks. The finer granularity of
encoding these features, as well as figures, notes, and all changes of typography, allows a range of
options for display, delivery, and searching. For example, one has the option of identifying and,
therefore, specifying the display charactersitics of different typographic styles, and regularizing the
display and placement of note text.</p>

<p>Level 3 texts can stand alone as text without page images and, therefore, can be uploaded, downloaded
and delivered quickly, and require less storage space than digital collections with page images.
However, the simple level of structural anaylsis and absence of specialized content analysis reflected
in Level 3 encoding may make it desirable for some, depending on project priorities, to include page
images in order to provide users with a fuller set of resources.</p>

<p>
'''Level 3 is most suitable for projects with the following characteristics:'''
</p>

<ul>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>some sophistication of display, delivery, and searching based on structure of the text is desired</li>
<li>each text will be checked to ensure that encoding decisions have been made appropriately</li>
<li>the users of the texts may have limited storage or display capabilities</li>
<li>the creator of the texts has limited or no ability to provide content expertise to analyze, tag,
or review texts</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<p>All elements specified in Levels 1 and 2, plus the following:</p>

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>

<td colspan="1">Required if present.</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">Required for paragraph breaks in prose; may be used for stanzas using <lb> for
line breaks in verse.</td>
</tr>

<tr>
<td colspan="1"><list> and <item></td>
<td colspan="1">May be used in this level to indicate ordered and unordered list structures.</td>
</tr>
<tr>
<td colspan="1"><table>, <row>, and <cell></td>

<td colspan="1">May be used to indicate table structures.</td>
</tr>
<tr>
<td colspan="1"><figure></td>
<td colspan="1">Required to indicate figures other than page images.</td>
</tr>
<tr>

<td colspan="1"><hi></td>
<td colspan="1">Required to indicate changes in typeface; rend attribute is optional.</td>
</tr>
<tr>
<td colspan="1"><note></td>
<td colspan="1">All notes must be encoded. It is also recommended that notes that extend beyond one page be combined into one <note> element. Marginal notes, without reference, should occur at the beginning of the paragraph to which they refer, with the value of the place attribute as "margin".</td>

</tr>
<tr>
<td colspan="1"><lb></td>
<td colspan="1">May be used to force line breaks.</td>
</tr>
</table>

<p>NOTE ON <note>:</p>

<p>It may be desirable to move footnotes from their original location in the text. If left at the bottom
of a page, a note may become included in another paragraph or section of the encoded text, and thus
separated from its reference. There are options for placement of footnotes if they are moved:</p>

<ul>
<li>Inline. The note is inserted at the point of reference. An n attribute records the value of the
note reference if there is one.</li>
<li>End-of-Division. Notes moved to the end of the division</li>
</ul>

<p>

'''Basic Structural Example forthcoming ...'''
</p>

===LEVEL 4: Basic Content Analysis===
<p>'''Purpose''': To create text that can stand alone as electronic text, identifies
hierarchy and typography, specifies function of textual and structural elements, and describes the
nature of the content and not merely its appearance. This level is not meant to encode or identify all
structural, semantic or bibliographic features of the text.</p>

<p>
'''Rationale''': Greater description of function and content allows for:</p>

<ul>
<li>flexibility of display and delivery</li>
<li>sophisticated searching within specified textual and structural elements</li>
<li>combining the broadest range of uses and audiences</li>

</ul>

<p>Texts encoded at Level 4 are able to stand alone as part of a library collection, and do not require
page images in order for them to be read by students, scholars and general readers. This level of TEI
encoding allows them to be displayed or printed in a variety of ways suitable for classroom or scholarly
use.</p>

<p>Level 4 texts contain elements and attributes that describe content. For example, lines of verse are
tagged with <l>; the <p> element is reserved for true paragraphs. Features of
the text that may contribute to meaning, such as indentation of verse lines and typographic change, are
preserved. These are textual features that are not encoded at lower levels and that allow the text to be
used and understood fully independent of images.</p>

<p>The ability to stand alone as text means that Level 4 texts are more nimble and robust for exercises
such as format repurposing and textual analysis.</p>

<p>Finally, functionally accurate encoding in Level 4 texts
allows them to be searched or displayed in sophisticated ways.
For example, a searcher could limit his or her search in a
dramatic text to stage directions or in a verse text to only
first lines. In a politicall tract published by subscription, a
search could be confined to names that appear in lists, thus
limiting a search to names of people who subscribed to a
particular volume. This ability to limit searches becomes more
significant as textbases become larger, and thus is of great
importance to the library community as it attempts to build into
the initial design and implementation of textbases the features
needed to enhance interoperability.</p>

<p>
'''Level 4 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>sophisticated search and retrieval capabilities are desired</li>

<li>the texts will be used for textual analysis</li>
<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added by the scholarly community at a later date</li>
<li>the users of the texts may have limited storage or display capabilities</li>
</ul>

====General Level 4 Recommendations====
<ul>
<li>Typographically distinct text should be encoded as appropriate,
e.g. with <term>, <q>, <gloss>, <mentioned>, <soCalled>, <foreign>,
<title>, or <emph>. Any ambiguous emphasized text should be
encoded as <hi> (e.g. <hi rend="bold">).</li>
<li>It is recommended that the <sic> element be used to
indicate typographic errors, with corrections (if any) noted
as the value of the corr= attribute.</li>
<li><titlePage> should include the verso if present, divided by <pb
n="verso"/>. Tables of contents, errata, subscription lists, "other titles by the same author"
should be included in a separate numbered division, as a <list> with <item>s.
Frontispieces should be encoded as a <figure>, within a separate numbered division and
<p>.</li>
</ul>

[http://www.diglib.org/standards/level4genrec.html See some examples in context…]

====Level 4 Prose====
<ul>
<li>Letters that occur within the text body provide some challenges. It is recommended that quoted
letters that occur as part of a text (and not collections of letters themselves) be encoded within
<q><text><body><div1 type="letter">, with
<opener>, <dateline>, <salute>, <signed>,
<closer> included as appropriate.</li>

<li>Quotations that do not occur inline, but are set off typographically in some way, should be
encoded as <q>.</li>
<li>Notes are to be encoded as described in Level 3.</li>
<li><argument>, <opener>, <epigraph>,
<closer>, <trailer>, <add>, <del>,
<unclear> as appropriate.</li>

</ul>

[http://www.diglib.org/standards/level4prose.html See some examples in context…]

====Level 4 Drama====
<ul>
<li>Cast lists should be encoded as <list>s, with <item>s.</li>

<li>Speeches are encoded as <sp>, with speakers identified within
<speaker> elements; stage directions are encoded as <stage> and enclose
block level content describing scenery, etc.</li>
</ul>

[http://www.diglib.org/standards/level4drama.html See some examples in context…]

====Level 4 Oral History====
<ul>
<li>Speakers in interviews can be identified in the <teiHeader> in several ways.
<ul>
<li>In the <profileDesc>, in the <particDesc> in a <list>, with <name> inside of <item>s.</li>

<li>As a list of author <name>s within <fileDesc><titleStmt></li>
</ul>
</li>
<li>In either method, use an id= on the <name> element to uniquely identify the individual participant</li>

<li>Questions and answers from interviewees and interviewers are encoded as <sp>,
with speakers identified within <speaker> elements with a who= attribute the value of which
corresponds to the id= in the list of interview participants.</li>
</ul>
[http://www.diglib.org/standards/level4oh.html See some examples in context…]

====Level 4 Verse====
<ul>
<li>All verse, even poems without separate stanzas or verse paragraphs, should be contained within a
line group element <lg>. This will assist with automated processing and retrieval.</li>
<li>It is common to see informal divisions within poems, noted by a string of asterisks or periods.
These should be encoded as <milestone/>s with attribute values of unit="typography" and
n="()" indicating the character used and its occurrence, <milestone unit="typography"
n="******"/>.</li>
<li><l> It is recommended that indentation be recorded and that the rend attribute be
used to do this.</li>
</ul>
[http://www.diglib.org/standards/level4verse.html See some examples in context…]
====Level 4 Front and Back Matter====
<ul>
<li>It is recommended that all prefaces, tables of contents, afterwords, appendices, endnotes and
apparatus be encoded. For publisher's advertisements, indexes, and glossaries or other front or back
matter that isn't considered of primary importance to the text, there are three options:<ul>
<li>Fully transcribe and encode</li>
<li>Link to page images (may include an unencoded transcription)</li>
<li>Omit, noted in <editorialDesc></li>
</ul>
</li>
</ul>
[http://www.diglib.org/standards/level4fandb.html See some examples in context…]

===LEVEL 5: Scholarly Encoding Projects===

<p>Level 5 texts are those that require subject knowledge, and encode semantic, linguistic, prosodic or
other elements beyond a basic structural level.</p>

==General Guidelines for Attribute Usage==

<p>Some general advice on the use of particular attributes
follows.</p>
<ul>
<li><b>type=</b>: Constructing a list of acceptable attribute values
for type that could find wide agreement is impossible. Instead,
it is recommended that projects describe the type= attribute
values used in their texts in the project ODD file or other
documentation and that this list be made available to people
using the texts. See <i>ABC for Book Collectors</i> by John
Carter (7th edition, New Castle, DE:Oak Knoll Books, 1995) for
a list of standard names and definitions of bibliographic
features of printed books. For those elements where type is not
required, such as <head> and <title>, use the
attribute values for subtitles and additional titles, but not
main titles.<br /> Example: <div1 type="volume"></li>

<li><b>n=</b>: Sometimes an n= (number) attribute can be used by itself. For instance in the case of
pagebreaks:<br /> Example: <pb n="456"/></li>

<li><b>id=</b>: If you are in a situation that requires you to
uniquely identify an element that will be used to reference
another specific location in one or more texts, use an id=
attribute. The value of this attribute must be unique within a
document, and must be composed of alphanumeric characters,
dots, hyphens, and underscores, and must start with a
letter.<br /> Example: <note id="n5" n="5"></li>

<li><b>target=</b>: follows the same syntactic rules as the id=
attribute value. In fact, target= and id= are often used in
conjunction with one another as in the case of footnotes where
the <anchor id="n5" n="5"> is at a specific place in the
text and is referred to by the <note target="n5" n="5">
which contains the actual information of the footnote itself
elsewhere.</li>

<li><b>entity=</b>: The entity= attribute is simply the way a
figure indirectly points or refers to its the actual image
file<br /> Example:
<!ENTITY TwaFifrn SYSTEM "TwaFifrn.jpg" NDATA jpeg><br />
<br />
<figure entity="TwaFifrn"></li>

<li><b>rend=</b>: Difficulty using rend= attributes occurs when it is desirable to record
more than one rendition feature. With this in mind, it is recommended that projects employ the
following adaptation of "rendition ladders", a concept developed at the [http://www.wwp.brown.edu/ Brown University Women Writers Project]. This system allows for sets
of multiple renditional features to be included in one rend= value. Rendition ladders consist of categories of
renditional features with values of each of those features enclosed in parentheses.<br /> rend= should only be
used to override a default value. For instance, if all text encoded as <hi> is defined as being
rendered in italics, there is no reason to encode text as <hi rend="font(italics)"> Combining renditional features would result in a tag with attributes such as <l rend="font(italics)align(right)">
<ul>
<li>font <br />italics, bold, fsc (full and smallcaps), smallcap, underlined, gothic</li>
<li>align <br />right, left, center, block</li>
<li>indent <br />Values in parentheses should indicate the number of tabstops to be indented, e.g.,
<l rend="indent(1)"></li>
</ul>
</li>
<li><b>lang=</b>: Use ISO639-2 three-character language codes. Note that this recommendation is slightly different from that of the TEI P5 Guidelines, which recommends the BCP 47 language codes.</li>
</ul>
References: <references/>
[[Category:SIG:Libraries]]

Best Practices for TEI in Libraries

2008-09-22T13:54:00Z

Melanieschlosser: /* <encodingDesc> */

[http://www.tei-c.org/wiki/index.php/SIG:Libraries TEI in Libraries: Home]

==Introduction and History==
<p>The Text Encoding Initiative Guidelines for Electronic Text Encoding and Interchange (referred to as
the <i>TEI Guidelines</i>) were first published in 1994 and represent a tremendous
achievement in electronic text standards by providing a highly sophisticated structure for encoding
electronic text. Digital librarians have benefited greatly from the standardization provided by these
guidelines, and the potential for interoperability and long-term preservation of digital collections
facilitated by their wide adoption.</p>

<p>In 1998, the Digital Library Federation (DLF) sponsored the [http://www.lib.umich.edu/lit/dlps/history/teidlf/index.html TEI and XML in Digital Libraries Workshop] at the
Library of Congress to discuss the use of the <i>TEI Guidelines</i> in libraries for electronic text,
and to create a set of best practices for librarians implementing them. From this workshop, three working
groups were formed the members of which represented some of the largest and most mature digital library
programs in the U.S. Group 2 was charged with developing a set of recommendations for libraries using the
TEI Guidelines in electronic text encoding. This group included the following representatives from six libraries:
</p>
<ul>
<li>LeeEllen Friedland, Library of Congress</li>
<li>Nancy Kushigian, University of California, Davis</li>
<li>Christina Powell, University of Michigan</li>
<li>David Seaman, University of Virginia</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>At the ALA mid-winter (January 1999), the DLF task force revised a draft set of best practices, called
TEI Text Encoding in Libraries: Guidelines for Best Practices (referred to as <i>TEI in Libraries
Guidelines</i>). The revised recommendations were circulated to the conference working group in May
1999 and presented at the joint annual meeting of the Association of Computers and the Humanities and
Association of Literary and Linguistic Computing in June 1999. [http://www.diglib.org/standards/tei-old.htm Version 1.0] was circulated for comments in
August 1999. These guidelines were endorsed by the DLF, and have been used by many digital libraries,
including those of the task force members, as a model for their own local best practices. Libraries,
museums and end-users have benefitted from a set of best practices for electronic text in a number of
ways, including better interoperability between electronic text collections, better documented practices
among digital libraries, and a starting point for discussion of best practices with commercial publishers
regarding electronic text creation.</p>

<p>Written in 1998, this first iteration of <i>TEI in Libraries Guidelines</i> made no mention of XML,
XSLT, or any of the other powerful tools that have now become common parlance and practice in creating
digital documents and collections. Based on these important changes in markup technology, it came to the
attention of the DLF and members of the original Task Force that the <i>TEI in Libraries Guidelines</i>
required substantial revision. In 2002, the TEI Consortium published a new edition of the complete
<i>TEI Guidelines</i> that conformed to XML specifications. In order to remain useful, the <i>TEI in
Libraries Guidelines</i> had to be updated to reflect these developments.</p>

<p>Furthermore, librarians need more guidance than the original <i>TEI in Libraries Guidelines</i>
provided. There are many library-specific encoding issues which need to be addressed and documented to
ensure consistency. The intention of this document is to provide recommended paths of encoding for these
issues.</p>

<p>In addition, these library guidelines have the potential to be much more useful if they can serve as a
training document from which librarians can learn about text encoding and addressing particular encoding
challenges. To fulfill this role, the guidelines require more examples and detailed explanations,
giving documentation of the use of TEI in a library context. Librarians also need a set of standards
and best practices for vendors and publishers who create electronic text for digital libraries, so that
these collections adhere to the same archival standards as locally-created electronic text collections.
With detailed guidelines that could serve as an encoding specification, librarians might encourage
vendors to follow the principles in these standards, to facilitate the long-term preservation of
commercially published electronic text collections, and more readily allow for cross-collection
searching.</p>

<p>In order to facilitate the evolution of this document, another DLF-sponsored Task Force—some
of the representatives of which were on the original Task Force—met on October 24-25, 2003 at
the Cosmos Club in Washington, D.C.: </p>
<ul>
<li>Richard Gartner, Oxford University Library</li>
<li>Matthew Gibson, University of Virginia Library</li>
<li>Kirk Hastings, California Digital Library</li>
<li>Christina Powell, University of Michigan</li>
<li>Merrilee Proffitt, RLG</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>These representatives met to revise the original <i>TEI in Libraries Guidelines</i> in order
that they: </p>
<ul>
<li>reflect changes occuring within the text encoding world generally and within the TEI
community specifically</li>
<li>further illuminate the different levels of encoding by offering clearer and more robust
examples.</li>
</ul>
<p>After producing [http://www.diglib.org/standards/tei2/tei20.htm Version 2.0] of the Guidelines, this group (with some changes in membership) met again
at the Cosmos Club on February 13-14, 2006. Those in attendance were: </p>
<ul>
<li>Syd Bauman, The TEI Consortium</li>
<li>Richard Gartner, Oxford University Library (by phone)</li>
<li>Matthew Gibson, Virginia Foundation for the Humanities (chair)</li>
<li>Merrilee Proffitt, RLG</li>
<li>Chris Powell, The University of Michigan</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natasha Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, The University of Michigan</li>
</ul>
<p>This group of continues to meet and based upon their discussions and resolutions, the following
guidelines will continue to be updated and enhanced.</p>

==General Overview and Comments==

<p>These recommendations are for libraries using the XML version of the TEILite DTD (teixlite).
There are many different library text digitization projects, for different purposes. With this in mind,
the Task Force has attempted to make these recommendations as inclusive as possible by developing a
series of encoding levels. These levels are meant to allow for a range of practice, from wholly automated
text creation and encoding, to encoding that requires expert content knowledge, analysis, and editing.</p>

<p>Recommendations for Levels 1-4 are intended for projects wishing to create encoded electronic text with
structural markup, but minimal semantic or content markup. Also, the encoding levels are cumulative:
encoding requirements at each level incorporate the requirements of lower levels. Levels 1-4 allow the
conversion and encoding of texts to be performed without the assistance of deep content knowledge and can
be enriched with more markup at any time. Level 5, in contrast, requires scholarly analysis. </p>

<p>These recommendations are concerned with the text portion of a TEI-encoded document. While there are
modest requirements for including certain information about encoding level in the TEI header, a separate
set of recommendations, now integrated into this document, was developed to address issues concerning TEI header
contents to MARC-format bibliographic data (see the [[#The TEI Header (based on June 16, 2001 Draft)|<teiHeader> section]]).</p>

==General Recommendations==

<p>Note: all recommendations that follow are based on P4:2004, with the exception of the facs= attribute of <pb>, which comes from the P5 module for the transcription of primary sources ('transcr').</p>

<ul>
<li>The encoding level (as described in this document) should be recorded in the
<editorialDecl> in the TEI header, along with an explanation of any deviation from the
recommendations.</li>

<li>Electronic text at all levels of encoding should begin with the transcription of the first word on
the first leaf of the original work. It may be impractical or undesirable to transcribe and encode
certain features of the text, such as publisher's advertisements or indexes, but if at all possible,
they should be included as links to page images. Any omissions of material found in the original work
should be noted in the <editorialDecl> in the TEI header.</li>
<li>File naming should follow ISO 9660 conventions: 8-character filenames, 3-character extensions,
using A-Z, a-z, 0-9, underscores and hyphens. The rationale behind this suggestion is that when moving
texts across different platforms (DOS for instance), some systems will truncate beyond the eighth
character.</li>
<li>We recommend the use of numbered divisions throughout the electronic text, always beginning with
<div1> (we prefer that <div0> not be used since the TEI Guidelines does not
make it available in <front> or <back> matter). Numbered divisions present
advantages to search and indexing software by explicitly communicating the hierarchical level of the
section described. Texts at all levels should include at least one <div1>.</li>
<li>Page breaks should be encoded using the <pb> element,
which should demark the top of a page (i.e. the text of page
seven should immediately follow <pb n="7"/>), and should
always be contained within a division. E.g., a page break that
occurs between chapters 2 and 3 should be encoded near the top
of the <div> that holds chapter 3 (rather than near the bottom
of the <div> that holds chapter 2).</li>
</ul>

==The TEI Header==

===Introduction===
<p>At the TEI and XML in Digital Libraries Workshop that was held at the Library of Congress in July 1998, several working groups
were formed to consider various aspects of the Text Encoding Initiative. Group 1 was charged to recommend some best practices
for TEI header content and to review the relationship between the Text Encoding Initiative header and MARC. To this end,
representatives of the University of Virginia Library and the University of Michigan Library gathered in Ann Arbor in early
October 1998 to develop a recommended practice guide. This work was assisted by similar efforts that had taken place in the United
Kingdom under the auspices of the Oxford Text Archive the previous year.
The following document represents a draft of those recommended practices. It has been submitted to various constituencies for
comment.</p>

===Working Assumptions===
<p>A TEI header can serve many publics. Headers can be created in a text center and reflect the center's standards, or they can
serve as the basis for other types of metadata system records produced by other agencies. Headers can function in detached
form as records in a catalog, as a title page inherent to the document, or as a source for index displays.</p>

<p>In addition, a header may describe a collection of documents, a single item, or a portion of an item. Variances in TEI header
content can result from making different choices of what is being described.</p>

<p>A TEI header may not have a one to one correspondence with a MARC record. One TEI header may have multiple MARC analytic records,
or one MARC record may be used to describe a collection of TEI documents with individual headers.</p>

<p>A TEI header serves several purposes. It may contain an historical background on how the file has been treated. It can extend the
information of a classic catalog record. The Text Center and/or cataloging agency can act as the gatekeeper for creators by
providing standards for content.</p>

===Cataloging a TEI Document===

<p>Does the TEI header act as the electronic title page or as a catalog record? Is it integral to the document it describes or
independent? Depending on the community being served, the TEI elements will reflect the interest of that community. Nonetheless,
it is possible to describe a set of "best practices" that will produce compatible content while accommodating this variety of
purposes. Compatibility of content encourages a more understandable set of results when information about assorted items is
displayed as a set of search results, a contents list, or an index, and it allows for more reasonable conversion of content
information from TEI elements to elements of other metadata sets when this action seems advisable.</p>

<p>It is a traditional practice of librarianship to agree upon where in a document and in what order of preference one should look
to identify the title, author, etc., of that document. This permits a certain consistency in terminology and allows for a certain
amount of authentication of content. We recommend the following preferences to those who create headers and to those who attempt
to use headers to create traditional catalog records that are compliant with AACR2 and ISBD(ER) rules.</p>

<p>As a member of the academic community, the header creator/editor has a responsibility to verify, whenever humanly possible, the
intellectual source for an electronic document that presents itself without any information regarding its source or authorship.</p>

====Chief Sources of Information for Several Types of Electronic Resources Are:====
<ul> <li>1. For an electronic document with a digitized title page (without a header), prefer
<ul>
<li>a) Chief source of information = information coded as title page</li>
<li>b) Use added information from an originating paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>2. Electronic document with header (without a title page)
<ul>
<li>a) Chief source of information = supplied and verified header <ref name="verify">Verified means that the cataloger/editor has established for him/herself that the information represented as title information is an accurate representation of content.</ref></li>

<li>b) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>

<li>3. Electronic document with header and title page
<ul>
<li>a) Chief source of information = supplied header (if verified)<ref name="verify"/></li>
<li>b) If header is not verified, use title page as chief source</li>
<li>c) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>4. If neither header nor title page is present and there is no evidence of a source document, the header creator
<ul>
<li>a) May assign a title and author if appropriate</li>
<li>b) Enclose the information in brackets, using the standard English language convention for editorial interjections</li>
</ul>
</li>
<li>5. If neither header nor title page is present but the header creator has satisfactory evidence of an originating source, that
document should be used as the chief source of information for the title and author of the header. If the source cannot be fully
verified as to edition, authorship, etc., this fact should be clearly indicated in a note in the <fileDesc>.
</li>

</ul>

===Element Recommendations for the <teiHeader>===

<table border="1" width="80%">
<tr>
<td colspan="1"><teiHeader type="____"></td>
<td colspan="1">
Standards which apply to the header, e.g., <teiHeader type="ISBD(ER)">, <teiHeader
type="AACR2">
</td>
</tr>
</table>

===<fileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<title type="____"></td>
<td colspan="1">
Only uniform title and main title for the TEI document, not the source document, should be entered here, e.g., <title type="uniform"> or <title type="main">. See <sourceDesc> for other title forms for documents where a user might seek the documents under titles other than those assigned. Where a title is supplied, the title should be enclosed in square brackets using standard English-language conventions for editorial insertion.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of original source (electronic or print) should be entered into the <author> element before the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.
</td>
</tr>

<tr>
<td colspan="1">
<editor></td>
<td colspan="1">
Editor of original source (electronic or print) should be entered into the <editor> element <b>before</b> the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.</td>

</tr>

<tr>
<td colspan="1">
<respStmt></td>
<td colspan="1">
The editor (also compiler, illustrator) of the TEI document, not the source document, should be entered here. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<editionStmt></td>

<td colspan="1">
This element should be used sparingly as there are currently no standards as to when versions become editions. Users should refer to the TEI guidelines.</td>
</tr>

<tr>
<td colspan="1">

<extent></td>
<td colspan="1">
Use the standard text "ca.**** kilobytes".</td>
</tr>

<tr>
<td colspan="1">

<publicationStmt></td>
<td colspan="1">
Use the child elements below rather than <p> for a prose description.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
The publisher is whoever has collected the TEI document, not the source document, and has made decisions concerning it.</td>
</tr>

<tr>

<td colspan="1">

<distributor></td>
<td colspan="1">
The distributor is whoever makes the TEI document, not the source document, available.</td>
</tr>

<tr>
<td colspan="1">
<idno></td>
<td colspan="1">
Any unique identification number determined by the publisher. Use type="OCLC-___" to point to the catalog record for the TEI document, if applicable. The institution's three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<availability status=" "><p></td>
<td colspan="1">
Describe any rights statement for the TEI document. Use a standard scheme, such as the code for a Creative Commonse license, for the value of the status attribute if possible.</td>
</tr>

<tr>
<td colspan="1">
<date></td>
<td colspan="1">
Refers to the date of the first publication of the TEI document. <b>For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.</b></td>
</tr>

<tr>
<td colspan="1">
<seriesStmt><title></td>

<td colspan="1">
Whenever possible, establish or use the name from a national name authority file authorized for the electronic, locally created series.
</td>
</tr>

<tr>
<td colspan="1">
<notesStmt></td>

<td colspan="1">
Optional, for indicating questionable attributions for title, author, etc.</td>

</tr>

<tr>
<td colspan="1">
<sourceDesc></td>
<td colspan="1">
In order to effectively represent the source(s) when many documents are represented by the TEI header, we see the need for structured elements that minimally allow us to identify parent-child and component relationships. In the absence of these structures, we suggest that multiple source descriptions be employed with relationships described in free text. Relationships also could be useful in other portions of the TEI header. Cataloger may need to do research to establish the original source.</td>
</tr>

<tr>

<td colspan="1">
<bibl> or
<biblFull></td>
<td colspan="1">
Use <bibl> with child elements listed below. metadata for the source document is automatically generated from a MARC record. It is suggested that child elements appear in the following order for ease of display according to ISBD: <author>, <title type="245a">, <title type="245b">, <respStmt>, <edition>, <pubPlace>, <publisher>, <date>, <extent>, <title type="series">, <note>, <idno type="isbn-13">, <idno type="isbn-10">, <idno type="OCLC-___">. Use <biblFull> for exhaustive description created by hand. </td>

</tr>

<tr>
<td colspan="1">
<title></td>
<td colspan="1">
Title of the source document. It is possible to have multiple <title> elements. Alternative titles (cover, running, spine titles) should be entered in separate <title> elements in <biblFull>.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of the source document. It is possible to have multiple <author> elements. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">

<editor></td>
<td colspan="1">
Editor of the source document. It is possible to have multiple <editor> elements.</td>
</tr>

<tr>
<td colspan="1">

<respStmt></td>
<td colspan="1">
If using <bibl> and generating from a MARC record, use this for the statement of responsibility (MARC field 245, subfield c).</td>
</tr>

<tr>
<td colspan="1">

<editionStmt></td>
<td colspan="1">
Edition statement in the source document (if present).</td>
</tr>

<tr>
<td colspan="1">
<extent></td>

<td colspan="1">
Enter physical description for the original source. If using <bibl> and generating from a MARC record, use this for MARC field 300.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
Don't repeat field. Enter multiple publishers divided by semicolons.</td></tr>

<tr>
<td colspan="1">
<pubPlace></td>
<td colspan="1">

Don't repeat field. Enter multiple publication places divided by semicolons.</td>
</tr>

<tr>
<td colspan="1">
<date></td>

<td colspan="1">
Imprint date for the original source. '''For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.'''</td>
</tr>

<tr>

<td colspan="1">
<idno></td>
<td colspan="1">
In this location, <idno> refers to identification numbers for the source document. They can be used to indicate the source's location in an individual institution's collection. If a formal standard location system is being used, indicate the nature of the system, e.g., <idno type="LC call number">. If using <bibl> and generating from a MARC record, use type="isbn-13" and type=-"isbn-10" if applicable. Use type="LC call number" (or appropriate abbreviation) for a call number. Use type="OCLC-___" to point to the catalog record for the source document. The institution’s three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<seriesStmt> or <series></td>

<td colspan="1">
Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<notes></td>

<td colspan="1">
Notes about the source document. If using <bibl> and generating from a MARC record, use for the value of MARC field 500.</td>
</tr>
</table>

===<encodingDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<projectDesc></td>
<td colspan="1">Enter a description of the purpose for which the electronic file was encoded.</td>
</tr>

<tr>
<td colspan="1">
<editorialDecl></td>
<td colspan="1">
Enter general and specific statements about how the electronic file has been treated. Record here editorial decisions made
during encoding.</td>

</tr>

<tr>
<td colspan="1">
<refsDecl></td>
<td colspan="1">
<refsDecl> could be used for administrative metadata, e.g., pagination and page sequencing.</td>
</tr>

<tr>

<td colspan="1">

<classDecl> <taxonomy id="____"> <bibl></td>
<td colspan="1">
If used, identify the appropriate taxonomy definitions or descriptive sources in the <taxonomy> element followed by id, e.g.,
<taxonomy id="LCSH"> <bibl>Library of Congress Subject Headings</bibl> </taxonomy>, <taxonomy id="AAT"> <bibl> Art & Architecture Theasaurus</bibl> </taxonomy>.</td>
</tr>
</table>

===<profileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<creation>
     <date></td>
<td colspan="1">
Use the date as it comes from the creator. '''For most purposes, the year date (yyyy) will be adequate. If greater detail is required, enter dates as yyymmdd.'''</td>
</tr>

<tr>
<td colspan="1">
<langUsage></td>
<td colspan="1">
Language usage is specified by document creators. Use standard language names.</td>
</tr>

<tr>
<td colspan="1">

<language id="____"></td>
<td colspan="1">
Use the ISO 639-2 standard (which is the same as the MARC language codes).</td>

</tr>

<tr>
<td colspan="1">
<textClass></td>
<td colspan="1">
True classification numbers as opposed to call numbers can be entered here.</td>

</tr>

<tr>
<td colspan="1">
<keywords><br />

<term>
</td>
<td colspan="1">
Use for uncontrolled terms.</td>
</tr>

<tr>
<td colspan="1">
<keywords scheme="____"><br />
<term>
</td>
<td colspan="1">
Use for controlled vocabulary as specified in <encodingDesc> taxonomy id. Example: scheme="LCSH"</td>

</tr>
</table>

===<revisionDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<change>
<resp>
<item></td>
<td colspan="1">
Use the specific codes to note revisions rather than free text description. Include the entire date
(e.g., 19991101).</td>

</tr>
</table>

===Minimal TEI Header Recommendation===
<blockquote>
<div class="indent"><teiHeader></div>
<div class="lindent"><fileDesc></div>

<div class="lindent2"><titleStmt></div>
<div class="lindent3"><title></title></div>
<div class="lindent3"><author></author></div>
<div class="lindent2"></titleStmt>

</div>
<div class="lindent2"><publicationStmt>
</div>
<div class="lindent3"><publisher></publisher>

</div>
<div class="lindent3"><pubPlace></pubPlace>
</div>
<div class="lindent3"><idno></idno>
</div>
<div class="lindent3"><availability><p></p></availability>
</div>
<div class="lindent3"><date></date>

</div>
<div class="lindent2"></publicationStmt>

</div>
<div class="lindent2"><sourceDesc>
</div>
<div class="lindent3"><biblFull>
</div>
<div class="lindent4"><titleStmt>
</div>
<div class="lindent5"><title></title>

</div>
<div class="lindent5"><author></author>
</div>
<div class="lindent4"></titleStmt>
</div>
<div class="lindent4"><publicationStmt>
</div>
<div class="lindent5"><publisher></publisher>
</div>
<div class="lindent5"><pubPlace></pubPlace>

</div>
<div class="lindent5"><date></date>
</div>
<div class="lindent4"></publicationStmt>
</div>
<div class="lindent3"></biblFull>
</div>
<div class="lindent2"></sourceDesc>
</div>
<div class="lindent"></fileDesc>
</div>

<div class="indent"></teiHeader>
</div>
</blockquote>

Repeat the <biblFull> field, as appropriate, if there is more than one source for the electronic item. [http://www.diglib.org/standards/teiheaders.html See some examples in context …]

===Recommended Additions to the teixlite DTD===
<ul>
<li>Add elements under <name> to allow for the variable ordering and alphabetization of names:
<forename>, <surname>, <birthdate>, <deathdate>, <title>, etc.</li>

<li>In order to effectively represent the source(s) when many documents are
represented by the TEI header, we see the need for structured elements that, minimally,
allow us to identify parent-child and component relationships.</li>
</ul>

===Acknowledgments and Bibliography===
<ul>
<li>
This guide was prepared by Judy Ahronheim, Thomas Champagne, Lynn Marko, Kelly Webster, and Chris Wilcox of the University of
Michigan Library and Jackie Shieh of the University of Virginia Library in October 1998. The source documents were the cataloging
guides prepared by those two institutions ([http://www.lib.virginia.edu/cataloging/manual/chapters/chapxiib.html Virginia] and [http://www.lib.umich.edu/ts/sections/electronicresourcesdev.html Michigan]). In addition,
documentation from the Oxford Text Archive, Arts and Humanities Data Service of the United Kingdom also was made available to assist
in this effort.

</li>
<li>
For a description of TEI header elements and correstponding USMARC fields, see Appendix A at
[http://etext.lib.virginia.edu/tei/tei-usmarc.html http://etext.lib.virginia.edu/tei/tei-usmarc.html].
</li>
</ul>

==Encoding Levels==
===LEVEL 1: Fully Automated Conversion and Encoding===

'''Purpose''': To create electronic text with the primary purpose of keyword searching and linking to page images. The primary advantage in using the teixlite DTD at this level is that a TEI header is attached to the text file.

<p>
'''Rationale''': The text is subordinate to the page image, and is not intended to
stand alone as an electronic text (without page images).</p>

<p>Texts at Level 1 can be created and encoded by fully automated means, using uncorrected OCR of page
images ("dirty OCR"), exporting from existing electronic text files, or actually not including any text
at all. Only those elements that are necessary to divide the text from the header and facilitate linking to
page images are used. Encoding is performed automatically based on artifacts of the OCR or other
document creation process (page breaks, for example) and metadata collected during the imaging or
preparation process. This encoding is both minimal and reliable, and does not typically require
extensive review of each page of each text.</p>

<p>Level 1 texts are not intended to be adequate for textual analysis; they are more likely to be suited
to the goals of a preservation unit or mass digitization initiative. Though their encoding is minimal,
Level 1 texts are fully valid XML texts. In addition to taking advantage of the TEI header, using the
teixlite DTD--with the consistency suggested by these guidelines--allows Level 1 texts to be compatible
with more richly encoded teixlite texts (that also follow these guidelines) for
searching, for example. Further encoding based on document structures or content analysis can be added
to a Level 1 text at any time.</p>

<p>
'''Level 1 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>a large volume of material is to be made available online quickly</li>
<li>a digital image of each page is desired</li>
<li>no manual intervention will be performed in the text creation process</li>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>sophisticated search and display capabilities based on the structure of the text are not necessary</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<table border="1" width="80%">
<tr>
<td colspan="1"><div1></td>
<td colspan="1">If no type= attribute is specified, a type= value of
"section" should be presumed.</td>
</tr>

<tr>
<td colspan="1"><p></td>
<td colspan="1">At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using <p> in order that the document be open to being extended to other encoding levels).</td>
</tr>
<tr>

<td colspan="1"><pb></td>
<td colspan="1">Required in Level 1. Page images can be linked to the text by specifying a jpeg or other image file as the value of the facs= attribute. Page numbers can be supplied with the n= attribute to record the number that is on the page. The Task Force sees the use of METS here as having a tremendous advantage. METS/TEI page turning documentation will be included in the near future.</td>
</tr>
</table>

====Basic Structural Example:====
<pre>
<TEI.2 id="someid">
<teiHeader>
[Source and processing information goes here]
</teiHeader>
<text>
<body>
<div1>
<p>
<pb id="p00000001" n="1"/>
[main body of the unmarked up plain text begins here]
<pb id="p00000002" n="2"/>
[more plain text goes here with appropriate page breaks interspersed] ...
<pb id="p00000145" n="145"/>
[more plain text]
<pb id="p00000146" n="146"/>
[text ends here]
</p>
</div1>
</body>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level1example.html See an example in context…]

===LEVEL 2: Minimal Encoding===
'''Purpose''': To create electronic text for full-text searching, linking to page images, and identifying simple structural hierarchy to improve navigation.

'''Rationale''': The text is subordinate to the page image, though navigational markers (textual divisions, headings) are captured. The text could stand alone as electronic text (without page images) if the accuracy of its contents is suitable to its intended use and it is not necessary to display low-level typographic or structural information. Level 2 requires a set of elements more granular than those of Level 1, including bibliographic or structural information below the monographic or volume level.

Though texts at Level 2 can be created and encoded by automated means, based on the typographic elements in the electronic file (for example, bold centered text at the top of the page surrounded by whitespace indicates a new chapter heading, and thus a new division), it is not likely to be absolutely reliable across a large body of material. Level 2 encoding requires some human intervention to identify each textual division and heading. Level 2 texts do not require any special knowledge or manual intervention below the section level.

Level 2 texts are not intended to be displayed separately from their page images. Level 2 encoding of sections and headings provides greater navigational possibilities than Level 1 encoding, and enables searching to be restricted within particular textual divisions (for example, searching for two phrases within the same chapter).

'''Level 2 is most suitable for projects with the following characteristics''':

* a large volume of material is to be made available online quickly
* a digital image of each page is desired
* the material is of interest to a large community of users who wish to read texts that allow keyword searching
* rudimentary search and display capabilities based on the large structures of the text are desired
* each text will be checked to ensure that divisions and headers are properly identified
* extensibility is desired; that is, one desires to keep open the option for a higher level of encoding to be added at a later date

All elements specified in Level 1 plus the following:

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>
<td colspan="1">Optional</td>
</tr>
<tr>
<td colspan="1"><div1></td>
<td colspan="1">type="section" is the default attribute value. It is recommended that the n= attribute be
included to record the sequence of divisions.</td>
</tr>
<tr>
<td colspan="1"><head></td>
<td colspan="1">Required if present</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">One "container" element per div is required.</td>
</tr>
</table>

====Basic Structural Example:====

<pre>
<TEI.2 id="someid">
<teiHeader> [Source and processing information goes here] </teiHeader>
<text id="someotherid">
<front> [titlepage information, table of contents, prefaces, etc.] </front>
<body>
<div1 type="chapter" n="1">
<head>Chapter 1</head>
<p>[text of Chapter 1 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="2">
<head>Chapter 2</head>
<p>[text of Chapter 2 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="3">
<head>Chapter 3</head> [text of Chapter 3 goes here interspersed with <pb> elements
pointing to page images] </div1>
<div1 type="chapter" n="4">
<head>Chapter 4</head> [text of Chapter 4 goes here interspersed with <pb> elements
pointing to page images] </div1>
</body>
<back> [optional text of backmatter, appendices, etc.] </back>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level2example.html See an example in context…]

===LEVEL 3: Simple Analysis===

<p>
'''Purpose''': To create text that can stand alone as electronic text and identifies
hierarchy and typography without content analysis being of primary importance.</p>

<p>
'''Rationale''': Level 3 texts can be created from scratch or by the relatively easy
conversion of existing HTML or word-processing documents. Encoding offers the advantage of the TEI
header, interoperability with other TEI collections, and extensibility to higher levels of encoding.
Level 3 generally requires some human editing, but the features to be encoded are determined by the
appearance of the text and not specialized content analysis.</p>

<p>Level 3 texts identify front and back matter, and all paragraph breaks. The finer granularity of
encoding these features, as well as figures, notes, and all changes of typography, allows a range of
options for display, delivery, and searching. For example, one has the option of identifying and,
therefore, specifying the display charactersitics of different typographic styles, and regularizing the
display and placement of note text.</p>

<p>Level 3 texts can stand alone as text without page images and, therefore, can be uploaded, downloaded
and delivered quickly, and require less storage space than digital collections with page images.
However, the simple level of structural anaylsis and absence of specialized content analysis reflected
in Level 3 encoding may make it desirable for some, depending on project priorities, to include page
images in order to provide users with a fuller set of resources.</p>

<p>
'''Level 3 is most suitable for projects with the following characteristics:'''
</p>

<ul>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>some sophistication of display, delivery, and searching based on structure of the text is desired</li>
<li>each text will be checked to ensure that encoding decisions have been made appropriately</li>
<li>the users of the texts may have limited storage or display capabilities</li>
<li>the creator of the texts has limited or no ability to provide content expertise to analyze, tag,
or review texts</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<p>All elements specified in Levels 1 and 2, plus the following:</p>

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>

<td colspan="1">Required if present.</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">Required for paragraph breaks in prose; may be used for stanzas using <lb> for
line breaks in verse.</td>
</tr>

<tr>
<td colspan="1"><list> and <item></td>
<td colspan="1">May be used in this level to indicate ordered and unordered list structures.</td>
</tr>
<tr>
<td colspan="1"><table>, <row>, and <cell></td>

<td colspan="1">May be used to indicate table structures.</td>
</tr>
<tr>
<td colspan="1"><figure></td>
<td colspan="1">Required to indicate figures other than page images.</td>
</tr>
<tr>

<td colspan="1"><hi></td>
<td colspan="1">Required to indicate changes in typeface; rend attribute is optional.</td>
</tr>
<tr>
<td colspan="1"><note></td>
<td colspan="1">All notes must be encoded. It is also recommended that notes that extend beyond one page be combined into one <note> element. Marginal notes, without reference, should occur at the beginning of the paragraph to which they refer, with the value of the place attribute as "margin".</td>

</tr>
<tr>
<td colspan="1"><lb></td>
<td colspan="1">May be used to force line breaks.</td>
</tr>
</table>

<p>NOTE ON <note>:</p>

<p>It may be desirable to move footnotes from their original location in the text. If left at the bottom
of a page, a note may become included in another paragraph or section of the encoded text, and thus
separated from its reference. There are options for placement of footnotes if they are moved:</p>

<ul>
<li>Inline. The note is inserted at the point of reference. An n attribute records the value of the
note reference if there is one.</li>
<li>End-of-Division. Notes moved to the end of the division</li>
</ul>

<p>

'''Basic Structural Example forthcoming ...'''
</p>

===LEVEL 4: Basic Content Analysis===
<p>'''Purpose''': To create text that can stand alone as electronic text, identifies
hierarchy and typography, specifies function of textual and structural elements, and describes the
nature of the content and not merely its appearance. This level is not meant to encode or identify all
structural, semantic or bibliographic features of the text.</p>

<p>
'''Rationale''': Greater description of function and content allows for:</p>

<ul>
<li>flexibility of display and delivery</li>
<li>sophisticated searching within specified textual and structural elements</li>
<li>combining the broadest range of uses and audiences</li>

</ul>

<p>Texts encoded at Level 4 are able to stand alone as part of a library collection, and do not require
page images in order for them to be read by students, scholars and general readers. This level of TEI
encoding allows them to be displayed or printed in a variety of ways suitable for classroom or scholarly
use.</p>

<p>Level 4 texts contain elements and attributes that describe content. For example, lines of verse are
tagged with <l>; the <p> element is reserved for true paragraphs. Features of
the text that may contribute to meaning, such as indentation of verse lines and typographic change, are
preserved. These are textual features that are not encoded at lower levels and that allow the text to be
used and understood fully independent of images.</p>

<p>The ability to stand alone as text means that Level 4 texts are more nimble and robust for exercises
such as format repurposing and textual analysis.</p>

<p>Finally, functionally accurate encoding in Level 4 texts
allows them to be searched or displayed in sophisticated ways.
For example, a searcher could limit his or her search in a
dramatic text to stage directions or in a verse text to only
first lines. In a politicall tract published by subscription, a
search could be confined to names that appear in lists, thus
limiting a search to names of people who subscribed to a
particular volume. This ability to limit searches becomes more
significant as textbases become larger, and thus is of great
importance to the library community as it attempts to build into
the initial design and implementation of textbases the features
needed to enhance interoperability.</p>

<p>
'''Level 4 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>sophisticated search and retrieval capabilities are desired</li>

<li>the texts will be used for textual analysis</li>
<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added by the scholarly community at a later date</li>
<li>the users of the texts may have limited storage or display capabilities</li>
</ul>

====General Level 4 Recommendations====
<ul>
<li>Typographically distinct text should be encoded as appropriate,
e.g. with <term>, <q>, <gloss>, <mentioned>, <soCalled>, <foreign>,
<title>, or <emph>. Any ambiguous emphasized text should be
encoded as <hi> (e.g. <hi rend="bold">).</li>
<li>It is recommended that the <sic> element be used to
indicate typographic errors, with corrections (if any) noted
as the value of the corr= attribute.</li>
<li><titlePage> should include the verso if present, divided by <pb
n="verso"/>. Tables of contents, errata, subscription lists, "other titles by the same author"
should be included in a separate numbered division, as a <list> with <item>s.
Frontispieces should be encoded as a <figure>, within a separate numbered division and
<p>.</li>
</ul>

[http://www.diglib.org/standards/level4genrec.html See some examples in context…]

====Level 4 Prose====
<ul>
<li>Letters that occur within the text body provide some challenges. It is recommended that quoted
letters that occur as part of a text (and not collections of letters themselves) be encoded within
<q><text><body><div1 type="letter">, with
<opener>, <dateline>, <salute>, <signed>,
<closer> included as appropriate.</li>

<li>Quotations that do not occur inline, but are set off typographically in some way, should be
encoded as <q>.</li>
<li>Notes are to be encoded as described in Level 3.</li>
<li><argument>, <opener>, <epigraph>,
<closer>, <trailer>, <add>, <del>,
<unclear> as appropriate.</li>

</ul>

[http://www.diglib.org/standards/level4prose.html See some examples in context…]

====Level 4 Drama====
<ul>
<li>Cast lists should be encoded as <list>s, with <item>s.</li>

<li>Speeches are encoded as <sp>, with speakers identified within
<speaker> elements; stage directions are encoded as <stage> and enclose
block level content describing scenery, etc.</li>
</ul>

[http://www.diglib.org/standards/level4drama.html See some examples in context…]

====Level 4 Oral History====
<ul>
<li>Speakers in interviews can be identified in the <teiHeader> in several ways.
<ul>
<li>In the <profileDesc>, in the <particDesc> in a <list>, with <name> inside of <item>s.</li>

<li>As a list of author <name>s within <fileDesc><titleStmt></li>
</ul>
</li>
<li>In either method, use an id= on the <name> element to uniquely identify the individual participant</li>

<li>Questions and answers from interviewees and interviewers are encoded as <sp>,
with speakers identified within <speaker> elements with a who= attribute the value of which
corresponds to the id= in the list of interview participants.</li>
</ul>
[http://www.diglib.org/standards/level4oh.html See some examples in context…]

====Level 4 Verse====
<ul>
<li>All verse, even poems without separate stanzas or verse paragraphs, should be contained within a
line group element <lg>. This will assist with automated processing and retrieval.</li>
<li>It is common to see informal divisions within poems, noted by a string of asterisks or periods.
These should be encoded as <milestone/>s with attribute values of unit="typography" and
n="()" indicating the character used and its occurrence, <milestone unit="typography"
n="******"/>.</li>
<li><l> It is recommended that indentation be recorded and that the rend attribute be
used to do this.</li>
</ul>
[http://www.diglib.org/standards/level4verse.html See some examples in context…]
====Level 4 Front and Back Matter====
<ul>
<li>It is recommended that all prefaces, tables of contents, afterwords, appendices, endnotes and
apparatus be encoded. For publisher's advertisements, indexes, and glossaries or other front or back
matter that isn't considered of primary importance to the text, there are three options:<ul>
<li>Fully transcribe and encode</li>
<li>Link to page images (may include an unencoded transcription)</li>
<li>Omit, noted in <editorialDesc></li>
</ul>
</li>
</ul>
[http://www.diglib.org/standards/level4fandb.html See some examples in context…]

===LEVEL 5: Scholarly Encoding Projects===

<p>Level 5 texts are those that require subject knowledge, and encode semantic, linguistic, prosodic or
other elements beyond a basic structural level.</p>

==General Guidelines for Attribute Usage==

<p>Some general advice on the use of particular attributes
follows.</p>
<ul>
<li><b>type=</b>: Constructing a list of acceptable attribute values
for type that could find wide agreement is impossible. Instead,
it is recommended that projects describe the type= attribute
values used in their texts in the project ODD file or other
documentation and that this list be made available to people
using the texts. See <i>ABC for Book Collectors</i> by John
Carter (7th edition, New Castle, DE:Oak Knoll Books, 1995) for
a list of standard names and definitions of bibliographic
features of printed books. For those elements where type is not
required, such as <head> and <title>, use the
attribute values for subtitles and additional titles, but not
main titles.<br /> Example: <div1 type="volume"></li>

<li><b>n=</b>: Sometimes an n= (number) attribute can be used by itself. For instance in the case of
pagebreaks:<br /> Example: <pb n="456"/></li>

<li><b>id=</b>: If you are in a situation that requires you to
uniquely identify an element that will be used to reference
another specific location in one or more texts, use an id=
attribute. The value of this attribute must be unique within a
document, and must be composed of alphanumeric characters,
dots, hyphens, and underscores, and must start with a
letter.<br /> Example: <note id="n5" n="5"></li>

<li><b>target=</b>: follows the same syntactic rules as the id=
attribute value. In fact, target= and id= are often used in
conjunction with one another as in the case of footnotes where
the <anchor id="n5" n="5"> is at a specific place in the
text and is referred to by the <note target="n5" n="5">
which contains the actual information of the footnote itself
elsewhere.</li>

<li><b>entity=</b>: The entity= attribute is simply the way a
figure indirectly points or refers to its the actual image
file<br /> Example:
<!ENTITY TwaFifrn SYSTEM "TwaFifrn.jpg" NDATA jpeg><br />
<br />
<figure entity="TwaFifrn"></li>

<li><b>rend=</b>: Difficulty using rend= attributes occurs when it is desirable to record
more than one rendition feature. With this in mind, it is recommended that projects employ the
following adaptation of "rendition ladders", a concept developed at the [http://www.wwp.brown.edu/ Brown University Women Writers Project]. This system allows for sets
of multiple renditional features to be included in one rend= value. Rendition ladders consist of categories of
renditional features with values of each of those features enclosed in parentheses.<br /> rend= should only be
used to override a default value. For instance, if all text encoded as <hi> is defined as being
rendered in italics, there is no reason to encode text as <hi rend="font(italics)"> Combining renditional features would result in a tag with attributes such as <l rend="font(italics)align(right)">
<ul>
<li>font <br />italics, bold, fsc (full and smallcaps), smallcap, underlined, gothic</li>
<li>align <br />right, left, center, block</li>
<li>indent <br />Values in parentheses should indicate the number of tabstops to be indented, e.g.,
<l rend="indent(1)"></li>
</ul>
</li>
<li><b>lang=</b>: Use ISO639-2 three-character language codes. Note that this recommendation is slightly different from that of the TEI P5 Guidelines, which recommends the BCP 47 language codes.</li>
</ul>
References: <references/>
[[Category:SIG:Libraries]]

Best Practices for TEI in Libraries

2008-09-22T13:49:55Z

Melanieschlosser: /* <fileDesc> */

[http://www.tei-c.org/wiki/index.php/SIG:Libraries TEI in Libraries: Home]

==Introduction and History==
<p>The Text Encoding Initiative Guidelines for Electronic Text Encoding and Interchange (referred to as
the <i>TEI Guidelines</i>) were first published in 1994 and represent a tremendous
achievement in electronic text standards by providing a highly sophisticated structure for encoding
electronic text. Digital librarians have benefited greatly from the standardization provided by these
guidelines, and the potential for interoperability and long-term preservation of digital collections
facilitated by their wide adoption.</p>

<p>In 1998, the Digital Library Federation (DLF) sponsored the [http://www.lib.umich.edu/lit/dlps/history/teidlf/index.html TEI and XML in Digital Libraries Workshop] at the
Library of Congress to discuss the use of the <i>TEI Guidelines</i> in libraries for electronic text,
and to create a set of best practices for librarians implementing them. From this workshop, three working
groups were formed the members of which represented some of the largest and most mature digital library
programs in the U.S. Group 2 was charged with developing a set of recommendations for libraries using the
TEI Guidelines in electronic text encoding. This group included the following representatives from six libraries:
</p>
<ul>
<li>LeeEllen Friedland, Library of Congress</li>
<li>Nancy Kushigian, University of California, Davis</li>
<li>Christina Powell, University of Michigan</li>
<li>David Seaman, University of Virginia</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>At the ALA mid-winter (January 1999), the DLF task force revised a draft set of best practices, called
TEI Text Encoding in Libraries: Guidelines for Best Practices (referred to as <i>TEI in Libraries
Guidelines</i>). The revised recommendations were circulated to the conference working group in May
1999 and presented at the joint annual meeting of the Association of Computers and the Humanities and
Association of Literary and Linguistic Computing in June 1999. [http://www.diglib.org/standards/tei-old.htm Version 1.0] was circulated for comments in
August 1999. These guidelines were endorsed by the DLF, and have been used by many digital libraries,
including those of the task force members, as a model for their own local best practices. Libraries,
museums and end-users have benefitted from a set of best practices for electronic text in a number of
ways, including better interoperability between electronic text collections, better documented practices
among digital libraries, and a starting point for discussion of best practices with commercial publishers
regarding electronic text creation.</p>

<p>Written in 1998, this first iteration of <i>TEI in Libraries Guidelines</i> made no mention of XML,
XSLT, or any of the other powerful tools that have now become common parlance and practice in creating
digital documents and collections. Based on these important changes in markup technology, it came to the
attention of the DLF and members of the original Task Force that the <i>TEI in Libraries Guidelines</i>
required substantial revision. In 2002, the TEI Consortium published a new edition of the complete
<i>TEI Guidelines</i> that conformed to XML specifications. In order to remain useful, the <i>TEI in
Libraries Guidelines</i> had to be updated to reflect these developments.</p>

<p>Furthermore, librarians need more guidance than the original <i>TEI in Libraries Guidelines</i>
provided. There are many library-specific encoding issues which need to be addressed and documented to
ensure consistency. The intention of this document is to provide recommended paths of encoding for these
issues.</p>

<p>In addition, these library guidelines have the potential to be much more useful if they can serve as a
training document from which librarians can learn about text encoding and addressing particular encoding
challenges. To fulfill this role, the guidelines require more examples and detailed explanations,
giving documentation of the use of TEI in a library context. Librarians also need a set of standards
and best practices for vendors and publishers who create electronic text for digital libraries, so that
these collections adhere to the same archival standards as locally-created electronic text collections.
With detailed guidelines that could serve as an encoding specification, librarians might encourage
vendors to follow the principles in these standards, to facilitate the long-term preservation of
commercially published electronic text collections, and more readily allow for cross-collection
searching.</p>

<p>In order to facilitate the evolution of this document, another DLF-sponsored Task Force—some
of the representatives of which were on the original Task Force—met on October 24-25, 2003 at
the Cosmos Club in Washington, D.C.: </p>
<ul>
<li>Richard Gartner, Oxford University Library</li>
<li>Matthew Gibson, University of Virginia Library</li>
<li>Kirk Hastings, California Digital Library</li>
<li>Christina Powell, University of Michigan</li>
<li>Merrilee Proffitt, RLG</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>These representatives met to revise the original <i>TEI in Libraries Guidelines</i> in order
that they: </p>
<ul>
<li>reflect changes occuring within the text encoding world generally and within the TEI
community specifically</li>
<li>further illuminate the different levels of encoding by offering clearer and more robust
examples.</li>
</ul>
<p>After producing [http://www.diglib.org/standards/tei2/tei20.htm Version 2.0] of the Guidelines, this group (with some changes in membership) met again
at the Cosmos Club on February 13-14, 2006. Those in attendance were: </p>
<ul>
<li>Syd Bauman, The TEI Consortium</li>
<li>Richard Gartner, Oxford University Library (by phone)</li>
<li>Matthew Gibson, Virginia Foundation for the Humanities (chair)</li>
<li>Merrilee Proffitt, RLG</li>
<li>Chris Powell, The University of Michigan</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natasha Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, The University of Michigan</li>
</ul>
<p>This group of continues to meet and based upon their discussions and resolutions, the following
guidelines will continue to be updated and enhanced.</p>

==General Overview and Comments==

<p>These recommendations are for libraries using the XML version of the TEILite DTD (teixlite).
There are many different library text digitization projects, for different purposes. With this in mind,
the Task Force has attempted to make these recommendations as inclusive as possible by developing a
series of encoding levels. These levels are meant to allow for a range of practice, from wholly automated
text creation and encoding, to encoding that requires expert content knowledge, analysis, and editing.</p>

<p>Recommendations for Levels 1-4 are intended for projects wishing to create encoded electronic text with
structural markup, but minimal semantic or content markup. Also, the encoding levels are cumulative:
encoding requirements at each level incorporate the requirements of lower levels. Levels 1-4 allow the
conversion and encoding of texts to be performed without the assistance of deep content knowledge and can
be enriched with more markup at any time. Level 5, in contrast, requires scholarly analysis. </p>

<p>These recommendations are concerned with the text portion of a TEI-encoded document. While there are
modest requirements for including certain information about encoding level in the TEI header, a separate
set of recommendations, now integrated into this document, was developed to address issues concerning TEI header
contents to MARC-format bibliographic data (see the [[#The TEI Header (based on June 16, 2001 Draft)|<teiHeader> section]]).</p>

==General Recommendations==

<p>Note: all recommendations that follow are based on P4:2004, with the exception of the facs= attribute of <pb>, which comes from the P5 module for the transcription of primary sources ('transcr').</p>

<ul>
<li>The encoding level (as described in this document) should be recorded in the
<editorialDecl> in the TEI header, along with an explanation of any deviation from the
recommendations.</li>

<li>Electronic text at all levels of encoding should begin with the transcription of the first word on
the first leaf of the original work. It may be impractical or undesirable to transcribe and encode
certain features of the text, such as publisher's advertisements or indexes, but if at all possible,
they should be included as links to page images. Any omissions of material found in the original work
should be noted in the <editorialDecl> in the TEI header.</li>
<li>File naming should follow ISO 9660 conventions: 8-character filenames, 3-character extensions,
using A-Z, a-z, 0-9, underscores and hyphens. The rationale behind this suggestion is that when moving
texts across different platforms (DOS for instance), some systems will truncate beyond the eighth
character.</li>
<li>We recommend the use of numbered divisions throughout the electronic text, always beginning with
<div1> (we prefer that <div0> not be used since the TEI Guidelines does not
make it available in <front> or <back> matter). Numbered divisions present
advantages to search and indexing software by explicitly communicating the hierarchical level of the
section described. Texts at all levels should include at least one <div1>.</li>
<li>Page breaks should be encoded using the <pb> element,
which should demark the top of a page (i.e. the text of page
seven should immediately follow <pb n="7"/>), and should
always be contained within a division. E.g., a page break that
occurs between chapters 2 and 3 should be encoded near the top
of the <div> that holds chapter 3 (rather than near the bottom
of the <div> that holds chapter 2).</li>
</ul>

==The TEI Header==

===Introduction===
<p>At the TEI and XML in Digital Libraries Workshop that was held at the Library of Congress in July 1998, several working groups
were formed to consider various aspects of the Text Encoding Initiative. Group 1 was charged to recommend some best practices
for TEI header content and to review the relationship between the Text Encoding Initiative header and MARC. To this end,
representatives of the University of Virginia Library and the University of Michigan Library gathered in Ann Arbor in early
October 1998 to develop a recommended practice guide. This work was assisted by similar efforts that had taken place in the United
Kingdom under the auspices of the Oxford Text Archive the previous year.
The following document represents a draft of those recommended practices. It has been submitted to various constituencies for
comment.</p>

===Working Assumptions===
<p>A TEI header can serve many publics. Headers can be created in a text center and reflect the center's standards, or they can
serve as the basis for other types of metadata system records produced by other agencies. Headers can function in detached
form as records in a catalog, as a title page inherent to the document, or as a source for index displays.</p>

<p>In addition, a header may describe a collection of documents, a single item, or a portion of an item. Variances in TEI header
content can result from making different choices of what is being described.</p>

<p>A TEI header may not have a one to one correspondence with a MARC record. One TEI header may have multiple MARC analytic records,
or one MARC record may be used to describe a collection of TEI documents with individual headers.</p>

<p>A TEI header serves several purposes. It may contain an historical background on how the file has been treated. It can extend the
information of a classic catalog record. The Text Center and/or cataloging agency can act as the gatekeeper for creators by
providing standards for content.</p>

===Cataloging a TEI Document===

<p>Does the TEI header act as the electronic title page or as a catalog record? Is it integral to the document it describes or
independent? Depending on the community being served, the TEI elements will reflect the interest of that community. Nonetheless,
it is possible to describe a set of "best practices" that will produce compatible content while accommodating this variety of
purposes. Compatibility of content encourages a more understandable set of results when information about assorted items is
displayed as a set of search results, a contents list, or an index, and it allows for more reasonable conversion of content
information from TEI elements to elements of other metadata sets when this action seems advisable.</p>

<p>It is a traditional practice of librarianship to agree upon where in a document and in what order of preference one should look
to identify the title, author, etc., of that document. This permits a certain consistency in terminology and allows for a certain
amount of authentication of content. We recommend the following preferences to those who create headers and to those who attempt
to use headers to create traditional catalog records that are compliant with AACR2 and ISBD(ER) rules.</p>

<p>As a member of the academic community, the header creator/editor has a responsibility to verify, whenever humanly possible, the
intellectual source for an electronic document that presents itself without any information regarding its source or authorship.</p>

====Chief Sources of Information for Several Types of Electronic Resources Are:====
<ul> <li>1. For an electronic document with a digitized title page (without a header), prefer
<ul>
<li>a) Chief source of information = information coded as title page</li>
<li>b) Use added information from an originating paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>2. Electronic document with header (without a title page)
<ul>
<li>a) Chief source of information = supplied and verified header <ref name="verify">Verified means that the cataloger/editor has established for him/herself that the information represented as title information is an accurate representation of content.</ref></li>

<li>b) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>

<li>3. Electronic document with header and title page
<ul>
<li>a) Chief source of information = supplied header (if verified)<ref name="verify"/></li>
<li>b) If header is not verified, use title page as chief source</li>
<li>c) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>4. If neither header nor title page is present and there is no evidence of a source document, the header creator
<ul>
<li>a) May assign a title and author if appropriate</li>
<li>b) Enclose the information in brackets, using the standard English language convention for editorial interjections</li>
</ul>
</li>
<li>5. If neither header nor title page is present but the header creator has satisfactory evidence of an originating source, that
document should be used as the chief source of information for the title and author of the header. If the source cannot be fully
verified as to edition, authorship, etc., this fact should be clearly indicated in a note in the <fileDesc>.
</li>

</ul>

===Element Recommendations for the <teiHeader>===

<table border="1" width="80%">
<tr>
<td colspan="1"><teiHeader type="____"></td>
<td colspan="1">
Standards which apply to the header, e.g., <teiHeader type="ISBD(ER)">, <teiHeader
type="AACR2">
</td>
</tr>
</table>

===<fileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<title type="____"></td>
<td colspan="1">
Only uniform title and main title for the TEI document, not the source document, should be entered here, e.g., <title type="uniform"> or <title type="main">. See <sourceDesc> for other title forms for documents where a user might seek the documents under titles other than those assigned. Where a title is supplied, the title should be enclosed in square brackets using standard English-language conventions for editorial insertion.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of original source (electronic or print) should be entered into the <author> element before the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.
</td>
</tr>

<tr>
<td colspan="1">
<editor></td>
<td colspan="1">
Editor of original source (electronic or print) should be entered into the <editor> element <b>before</b> the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.</td>

</tr>

<tr>
<td colspan="1">
<respStmt></td>
<td colspan="1">
The editor (also compiler, illustrator) of the TEI document, not the source document, should be entered here. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<editionStmt></td>

<td colspan="1">
This element should be used sparingly as there are currently no standards as to when versions become editions. Users should refer to the TEI guidelines.</td>
</tr>

<tr>
<td colspan="1">

<extent></td>
<td colspan="1">
Use the standard text "ca.**** kilobytes".</td>
</tr>

<tr>
<td colspan="1">

<publicationStmt></td>
<td colspan="1">
Use the child elements below rather than <p> for a prose description.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
The publisher is whoever has collected the TEI document, not the source document, and has made decisions concerning it.</td>
</tr>

<tr>

<td colspan="1">

<distributor></td>
<td colspan="1">
The distributor is whoever makes the TEI document, not the source document, available.</td>
</tr>

<tr>
<td colspan="1">
<idno></td>
<td colspan="1">
Any unique identification number determined by the publisher. Use type="OCLC-___" to point to the catalog record for the TEI document, if applicable. The institution's three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<availability status=" "><p></td>
<td colspan="1">
Describe any rights statement for the TEI document. Use a standard scheme, such as the code for a Creative Commonse license, for the value of the status attribute if possible.</td>
</tr>

<tr>
<td colspan="1">
<date></td>
<td colspan="1">
Refers to the date of the first publication of the TEI document. <b>For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.</b></td>
</tr>

<tr>
<td colspan="1">
<seriesStmt><title></td>

<td colspan="1">
Whenever possible, establish or use the name from a national name authority file authorized for the electronic, locally created series.
</td>
</tr>

<tr>
<td colspan="1">
<notesStmt></td>

<td colspan="1">
Optional, for indicating questionable attributions for title, author, etc.</td>

</tr>

<tr>
<td colspan="1">
<sourceDesc></td>
<td colspan="1">
In order to effectively represent the source(s) when many documents are represented by the TEI header, we see the need for structured elements that minimally allow us to identify parent-child and component relationships. In the absence of these structures, we suggest that multiple source descriptions be employed with relationships described in free text. Relationships also could be useful in other portions of the TEI header. Cataloger may need to do research to establish the original source.</td>
</tr>

<tr>

<td colspan="1">
<bibl> or
<biblFull></td>
<td colspan="1">
Use <bibl> with child elements listed below. metadata for the source document is automatically generated from a MARC record. It is suggested that child elements appear in the following order for ease of display according to ISBD: <author>, <title type="245a">, <title type="245b">, <respStmt>, <edition>, <pubPlace>, <publisher>, <date>, <extent>, <title type="series">, <note>, <idno type="isbn-13">, <idno type="isbn-10">, <idno type="OCLC-___">. Use <biblFull> for exhaustive description created by hand. </td>

</tr>

<tr>
<td colspan="1">
<title></td>
<td colspan="1">
Title of the source document. It is possible to have multiple <title> elements. Alternative titles (cover, running, spine titles) should be entered in separate <title> elements in <biblFull>.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of the source document. It is possible to have multiple <author> elements. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">

<editor></td>
<td colspan="1">
Editor of the source document. It is possible to have multiple <editor> elements.</td>
</tr>

<tr>
<td colspan="1">

<respStmt></td>
<td colspan="1">
If using <bibl> and generating from a MARC record, use this for the statement of responsibility (MARC field 245, subfield c).</td>
</tr>

<tr>
<td colspan="1">

<editionStmt></td>
<td colspan="1">
Edition statement in the source document (if present).</td>
</tr>

<tr>
<td colspan="1">
<extent></td>

<td colspan="1">
Enter physical description for the original source. If using <bibl> and generating from a MARC record, use this for MARC field 300.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
Don't repeat field. Enter multiple publishers divided by semicolons.</td></tr>

<tr>
<td colspan="1">
<pubPlace></td>
<td colspan="1">

Don't repeat field. Enter multiple publication places divided by semicolons.</td>
</tr>

<tr>
<td colspan="1">
<date></td>

<td colspan="1">
Imprint date for the original source. '''For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.'''</td>
</tr>

<tr>

<td colspan="1">
<idno></td>
<td colspan="1">
In this location, <idno> refers to identification numbers for the source document. They can be used to indicate the source's location in an individual institution's collection. If a formal standard location system is being used, indicate the nature of the system, e.g., <idno type="LC call number">. If using <bibl> and generating from a MARC record, use type="isbn-13" and type=-"isbn-10" if applicable. Use type="LC call number" (or appropriate abbreviation) for a call number. Use type="OCLC-___" to point to the catalog record for the source document. The institution’s three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<seriesStmt> or <series></td>

<td colspan="1">
Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<notes></td>

<td colspan="1">
Notes about the source document. If using <bibl> and generating from a MARC record, use for the value of MARC field 500.</td>
</tr>
</table>

===<encodingDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<projectDesc></td>
<td colspan="1">Enter a description of the purpose for which the electronic file was encoded.</td>
</tr>

<tr>
<td colspan="1">
<editorialDecl></td>
<td colspan="1">
Enter general and specific statements about how the electronic file has been treated. Record here editorial decisions made
during encoding.</td>

</tr>

<tr>
<td colspan="1">
<refsDecl></td>
<td colspan="1">
<refsDecl> seems a possibility for administrative metadata, e.g., pagination and page sequencing.</td>
</tr>

<tr>

<td colspan="1">

<classDecl> <taxonomy id="____"></td>
<td colspan="1">
If used, identify the appropriate taxonomy definitions or descriptive sources in the <taxonomy> element followed by id, e.g.,
<taxonomy id="LCSH">, <taxonomy id="AAT">.</td>
</tr>
</table>

===<profileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<creation>
     <date></td>
<td colspan="1">
Use the date as it comes from the creator. '''For most purposes, the year date (yyyy) will be adequate. If greater detail is required, enter dates as yyymmdd.'''</td>
</tr>

<tr>
<td colspan="1">
<langUsage></td>
<td colspan="1">
Language usage is specified by document creators. Use standard language names.</td>
</tr>

<tr>
<td colspan="1">

<language id="____"></td>
<td colspan="1">
Use the ISO 639-2 standard (which is the same as the MARC language codes).</td>

</tr>

<tr>
<td colspan="1">
<textClass></td>
<td colspan="1">
True classification numbers as opposed to call numbers can be entered here.</td>

</tr>

<tr>
<td colspan="1">
<keywords><br />

<term>
</td>
<td colspan="1">
Use for uncontrolled terms.</td>
</tr>

<tr>
<td colspan="1">
<keywords scheme="____"><br />
<term>
</td>
<td colspan="1">
Use for controlled vocabulary as specified in <encodingDesc> taxonomy id. Example: scheme="LCSH"</td>

</tr>
</table>

===<revisionDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<change>
<resp>
<item></td>
<td colspan="1">
Use the specific codes to note revisions rather than free text description. Include the entire date
(e.g., 19991101).</td>

</tr>
</table>

===Minimal TEI Header Recommendation===
<blockquote>
<div class="indent"><teiHeader></div>
<div class="lindent"><fileDesc></div>

<div class="lindent2"><titleStmt></div>
<div class="lindent3"><title></title></div>
<div class="lindent3"><author></author></div>
<div class="lindent2"></titleStmt>

</div>
<div class="lindent2"><publicationStmt>
</div>
<div class="lindent3"><publisher></publisher>

</div>
<div class="lindent3"><pubPlace></pubPlace>
</div>
<div class="lindent3"><idno></idno>
</div>
<div class="lindent3"><availability><p></p></availability>
</div>
<div class="lindent3"><date></date>

</div>
<div class="lindent2"></publicationStmt>

</div>
<div class="lindent2"><sourceDesc>
</div>
<div class="lindent3"><biblFull>
</div>
<div class="lindent4"><titleStmt>
</div>
<div class="lindent5"><title></title>

</div>
<div class="lindent5"><author></author>
</div>
<div class="lindent4"></titleStmt>
</div>
<div class="lindent4"><publicationStmt>
</div>
<div class="lindent5"><publisher></publisher>
</div>
<div class="lindent5"><pubPlace></pubPlace>

</div>
<div class="lindent5"><date></date>
</div>
<div class="lindent4"></publicationStmt>
</div>
<div class="lindent3"></biblFull>
</div>
<div class="lindent2"></sourceDesc>
</div>
<div class="lindent"></fileDesc>
</div>

<div class="indent"></teiHeader>
</div>
</blockquote>

Repeat the <biblFull> field, as appropriate, if there is more than one source for the electronic item. [http://www.diglib.org/standards/teiheaders.html See some examples in context …]

===Recommended Additions to the teixlite DTD===
<ul>
<li>Add elements under <name> to allow for the variable ordering and alphabetization of names:
<forename>, <surname>, <birthdate>, <deathdate>, <title>, etc.</li>

<li>In order to effectively represent the source(s) when many documents are
represented by the TEI header, we see the need for structured elements that, minimally,
allow us to identify parent-child and component relationships.</li>
</ul>

===Acknowledgments and Bibliography===
<ul>
<li>
This guide was prepared by Judy Ahronheim, Thomas Champagne, Lynn Marko, Kelly Webster, and Chris Wilcox of the University of
Michigan Library and Jackie Shieh of the University of Virginia Library in October 1998. The source documents were the cataloging
guides prepared by those two institutions ([http://www.lib.virginia.edu/cataloging/manual/chapters/chapxiib.html Virginia] and [http://www.lib.umich.edu/ts/sections/electronicresourcesdev.html Michigan]). In addition,
documentation from the Oxford Text Archive, Arts and Humanities Data Service of the United Kingdom also was made available to assist
in this effort.

</li>
<li>
For a description of TEI header elements and correstponding USMARC fields, see Appendix A at
[http://etext.lib.virginia.edu/tei/tei-usmarc.html http://etext.lib.virginia.edu/tei/tei-usmarc.html].
</li>
</ul>

==Encoding Levels==
===LEVEL 1: Fully Automated Conversion and Encoding===

'''Purpose''': To create electronic text with the primary purpose of keyword searching and linking to page images. The primary advantage in using the teixlite DTD at this level is that a TEI header is attached to the text file.

<p>
'''Rationale''': The text is subordinate to the page image, and is not intended to
stand alone as an electronic text (without page images).</p>

<p>Texts at Level 1 can be created and encoded by fully automated means, using uncorrected OCR of page
images ("dirty OCR"), exporting from existing electronic text files, or actually not including any text
at all. Only those elements that are necessary to divide the text from the header and facilitate linking to
page images are used. Encoding is performed automatically based on artifacts of the OCR or other
document creation process (page breaks, for example) and metadata collected during the imaging or
preparation process. This encoding is both minimal and reliable, and does not typically require
extensive review of each page of each text.</p>

<p>Level 1 texts are not intended to be adequate for textual analysis; they are more likely to be suited
to the goals of a preservation unit or mass digitization initiative. Though their encoding is minimal,
Level 1 texts are fully valid XML texts. In addition to taking advantage of the TEI header, using the
teixlite DTD--with the consistency suggested by these guidelines--allows Level 1 texts to be compatible
with more richly encoded teixlite texts (that also follow these guidelines) for
searching, for example. Further encoding based on document structures or content analysis can be added
to a Level 1 text at any time.</p>

<p>
'''Level 1 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>a large volume of material is to be made available online quickly</li>
<li>a digital image of each page is desired</li>
<li>no manual intervention will be performed in the text creation process</li>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>sophisticated search and display capabilities based on the structure of the text are not necessary</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<table border="1" width="80%">
<tr>
<td colspan="1"><div1></td>
<td colspan="1">If no type= attribute is specified, a type= value of
"section" should be presumed.</td>
</tr>

<tr>
<td colspan="1"><p></td>
<td colspan="1">At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using <p> in order that the document be open to being extended to other encoding levels).</td>
</tr>
<tr>

<td colspan="1"><pb></td>
<td colspan="1">Required in Level 1. Page images can be linked to the text by specifying a jpeg or other image file as the value of the facs= attribute. Page numbers can be supplied with the n= attribute to record the number that is on the page. The Task Force sees the use of METS here as having a tremendous advantage. METS/TEI page turning documentation will be included in the near future.</td>
</tr>
</table>

====Basic Structural Example:====
<pre>
<TEI.2 id="someid">
<teiHeader>
[Source and processing information goes here]
</teiHeader>
<text>
<body>
<div1>
<p>
<pb id="p00000001" n="1"/>
[main body of the unmarked up plain text begins here]
<pb id="p00000002" n="2"/>
[more plain text goes here with appropriate page breaks interspersed] ...
<pb id="p00000145" n="145"/>
[more plain text]
<pb id="p00000146" n="146"/>
[text ends here]
</p>
</div1>
</body>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level1example.html See an example in context…]

===LEVEL 2: Minimal Encoding===
'''Purpose''': To create electronic text for full-text searching, linking to page images, and identifying simple structural hierarchy to improve navigation.

'''Rationale''': The text is subordinate to the page image, though navigational markers (textual divisions, headings) are captured. The text could stand alone as electronic text (without page images) if the accuracy of its contents is suitable to its intended use and it is not necessary to display low-level typographic or structural information. Level 2 requires a set of elements more granular than those of Level 1, including bibliographic or structural information below the monographic or volume level.

Though texts at Level 2 can be created and encoded by automated means, based on the typographic elements in the electronic file (for example, bold centered text at the top of the page surrounded by whitespace indicates a new chapter heading, and thus a new division), it is not likely to be absolutely reliable across a large body of material. Level 2 encoding requires some human intervention to identify each textual division and heading. Level 2 texts do not require any special knowledge or manual intervention below the section level.

Level 2 texts are not intended to be displayed separately from their page images. Level 2 encoding of sections and headings provides greater navigational possibilities than Level 1 encoding, and enables searching to be restricted within particular textual divisions (for example, searching for two phrases within the same chapter).

'''Level 2 is most suitable for projects with the following characteristics''':

* a large volume of material is to be made available online quickly
* a digital image of each page is desired
* the material is of interest to a large community of users who wish to read texts that allow keyword searching
* rudimentary search and display capabilities based on the large structures of the text are desired
* each text will be checked to ensure that divisions and headers are properly identified
* extensibility is desired; that is, one desires to keep open the option for a higher level of encoding to be added at a later date

All elements specified in Level 1 plus the following:

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>
<td colspan="1">Optional</td>
</tr>
<tr>
<td colspan="1"><div1></td>
<td colspan="1">type="section" is the default attribute value. It is recommended that the n= attribute be
included to record the sequence of divisions.</td>
</tr>
<tr>
<td colspan="1"><head></td>
<td colspan="1">Required if present</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">One "container" element per div is required.</td>
</tr>
</table>

====Basic Structural Example:====

<pre>
<TEI.2 id="someid">
<teiHeader> [Source and processing information goes here] </teiHeader>
<text id="someotherid">
<front> [titlepage information, table of contents, prefaces, etc.] </front>
<body>
<div1 type="chapter" n="1">
<head>Chapter 1</head>
<p>[text of Chapter 1 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="2">
<head>Chapter 2</head>
<p>[text of Chapter 2 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="3">
<head>Chapter 3</head> [text of Chapter 3 goes here interspersed with <pb> elements
pointing to page images] </div1>
<div1 type="chapter" n="4">
<head>Chapter 4</head> [text of Chapter 4 goes here interspersed with <pb> elements
pointing to page images] </div1>
</body>
<back> [optional text of backmatter, appendices, etc.] </back>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level2example.html See an example in context…]

===LEVEL 3: Simple Analysis===

<p>
'''Purpose''': To create text that can stand alone as electronic text and identifies
hierarchy and typography without content analysis being of primary importance.</p>

<p>
'''Rationale''': Level 3 texts can be created from scratch or by the relatively easy
conversion of existing HTML or word-processing documents. Encoding offers the advantage of the TEI
header, interoperability with other TEI collections, and extensibility to higher levels of encoding.
Level 3 generally requires some human editing, but the features to be encoded are determined by the
appearance of the text and not specialized content analysis.</p>

<p>Level 3 texts identify front and back matter, and all paragraph breaks. The finer granularity of
encoding these features, as well as figures, notes, and all changes of typography, allows a range of
options for display, delivery, and searching. For example, one has the option of identifying and,
therefore, specifying the display charactersitics of different typographic styles, and regularizing the
display and placement of note text.</p>

<p>Level 3 texts can stand alone as text without page images and, therefore, can be uploaded, downloaded
and delivered quickly, and require less storage space than digital collections with page images.
However, the simple level of structural anaylsis and absence of specialized content analysis reflected
in Level 3 encoding may make it desirable for some, depending on project priorities, to include page
images in order to provide users with a fuller set of resources.</p>

<p>
'''Level 3 is most suitable for projects with the following characteristics:'''
</p>

<ul>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>some sophistication of display, delivery, and searching based on structure of the text is desired</li>
<li>each text will be checked to ensure that encoding decisions have been made appropriately</li>
<li>the users of the texts may have limited storage or display capabilities</li>
<li>the creator of the texts has limited or no ability to provide content expertise to analyze, tag,
or review texts</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<p>All elements specified in Levels 1 and 2, plus the following:</p>

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>

<td colspan="1">Required if present.</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">Required for paragraph breaks in prose; may be used for stanzas using <lb> for
line breaks in verse.</td>
</tr>

<tr>
<td colspan="1"><list> and <item></td>
<td colspan="1">May be used in this level to indicate ordered and unordered list structures.</td>
</tr>
<tr>
<td colspan="1"><table>, <row>, and <cell></td>

<td colspan="1">May be used to indicate table structures.</td>
</tr>
<tr>
<td colspan="1"><figure></td>
<td colspan="1">Required to indicate figures other than page images.</td>
</tr>
<tr>

<td colspan="1"><hi></td>
<td colspan="1">Required to indicate changes in typeface; rend attribute is optional.</td>
</tr>
<tr>
<td colspan="1"><note></td>
<td colspan="1">All notes must be encoded. It is also recommended that notes that extend beyond one page be combined into one <note> element. Marginal notes, without reference, should occur at the beginning of the paragraph to which they refer, with the value of the place attribute as "margin".</td>

</tr>
<tr>
<td colspan="1"><lb></td>
<td colspan="1">May be used to force line breaks.</td>
</tr>
</table>

<p>NOTE ON <note>:</p>

<p>It may be desirable to move footnotes from their original location in the text. If left at the bottom
of a page, a note may become included in another paragraph or section of the encoded text, and thus
separated from its reference. There are options for placement of footnotes if they are moved:</p>

<ul>
<li>Inline. The note is inserted at the point of reference. An n attribute records the value of the
note reference if there is one.</li>
<li>End-of-Division. Notes moved to the end of the division</li>
</ul>

<p>

'''Basic Structural Example forthcoming ...'''
</p>

===LEVEL 4: Basic Content Analysis===
<p>'''Purpose''': To create text that can stand alone as electronic text, identifies
hierarchy and typography, specifies function of textual and structural elements, and describes the
nature of the content and not merely its appearance. This level is not meant to encode or identify all
structural, semantic or bibliographic features of the text.</p>

<p>
'''Rationale''': Greater description of function and content allows for:</p>

<ul>
<li>flexibility of display and delivery</li>
<li>sophisticated searching within specified textual and structural elements</li>
<li>combining the broadest range of uses and audiences</li>

</ul>

<p>Texts encoded at Level 4 are able to stand alone as part of a library collection, and do not require
page images in order for them to be read by students, scholars and general readers. This level of TEI
encoding allows them to be displayed or printed in a variety of ways suitable for classroom or scholarly
use.</p>

<p>Level 4 texts contain elements and attributes that describe content. For example, lines of verse are
tagged with <l>; the <p> element is reserved for true paragraphs. Features of
the text that may contribute to meaning, such as indentation of verse lines and typographic change, are
preserved. These are textual features that are not encoded at lower levels and that allow the text to be
used and understood fully independent of images.</p>

<p>The ability to stand alone as text means that Level 4 texts are more nimble and robust for exercises
such as format repurposing and textual analysis.</p>

<p>Finally, functionally accurate encoding in Level 4 texts
allows them to be searched or displayed in sophisticated ways.
For example, a searcher could limit his or her search in a
dramatic text to stage directions or in a verse text to only
first lines. In a politicall tract published by subscription, a
search could be confined to names that appear in lists, thus
limiting a search to names of people who subscribed to a
particular volume. This ability to limit searches becomes more
significant as textbases become larger, and thus is of great
importance to the library community as it attempts to build into
the initial design and implementation of textbases the features
needed to enhance interoperability.</p>

<p>
'''Level 4 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>sophisticated search and retrieval capabilities are desired</li>

<li>the texts will be used for textual analysis</li>
<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added by the scholarly community at a later date</li>
<li>the users of the texts may have limited storage or display capabilities</li>
</ul>

====General Level 4 Recommendations====
<ul>
<li>Typographically distinct text should be encoded as appropriate,
e.g. with <term>, <q>, <gloss>, <mentioned>, <soCalled>, <foreign>,
<title>, or <emph>. Any ambiguous emphasized text should be
encoded as <hi> (e.g. <hi rend="bold">).</li>
<li>It is recommended that the <sic> element be used to
indicate typographic errors, with corrections (if any) noted
as the value of the corr= attribute.</li>
<li><titlePage> should include the verso if present, divided by <pb
n="verso"/>. Tables of contents, errata, subscription lists, "other titles by the same author"
should be included in a separate numbered division, as a <list> with <item>s.
Frontispieces should be encoded as a <figure>, within a separate numbered division and
<p>.</li>
</ul>

[http://www.diglib.org/standards/level4genrec.html See some examples in context…]

====Level 4 Prose====
<ul>
<li>Letters that occur within the text body provide some challenges. It is recommended that quoted
letters that occur as part of a text (and not collections of letters themselves) be encoded within
<q><text><body><div1 type="letter">, with
<opener>, <dateline>, <salute>, <signed>,
<closer> included as appropriate.</li>

<li>Quotations that do not occur inline, but are set off typographically in some way, should be
encoded as <q>.</li>
<li>Notes are to be encoded as described in Level 3.</li>
<li><argument>, <opener>, <epigraph>,
<closer>, <trailer>, <add>, <del>,
<unclear> as appropriate.</li>

</ul>

[http://www.diglib.org/standards/level4prose.html See some examples in context…]

====Level 4 Drama====
<ul>
<li>Cast lists should be encoded as <list>s, with <item>s.</li>

<li>Speeches are encoded as <sp>, with speakers identified within
<speaker> elements; stage directions are encoded as <stage> and enclose
block level content describing scenery, etc.</li>
</ul>

[http://www.diglib.org/standards/level4drama.html See some examples in context…]

====Level 4 Oral History====
<ul>
<li>Speakers in interviews can be identified in the <teiHeader> in several ways.
<ul>
<li>In the <profileDesc>, in the <particDesc> in a <list>, with <name> inside of <item>s.</li>

<li>As a list of author <name>s within <fileDesc><titleStmt></li>
</ul>
</li>
<li>In either method, use an id= on the <name> element to uniquely identify the individual participant</li>

<li>Questions and answers from interviewees and interviewers are encoded as <sp>,
with speakers identified within <speaker> elements with a who= attribute the value of which
corresponds to the id= in the list of interview participants.</li>
</ul>
[http://www.diglib.org/standards/level4oh.html See some examples in context…]

====Level 4 Verse====
<ul>
<li>All verse, even poems without separate stanzas or verse paragraphs, should be contained within a
line group element <lg>. This will assist with automated processing and retrieval.</li>
<li>It is common to see informal divisions within poems, noted by a string of asterisks or periods.
These should be encoded as <milestone/>s with attribute values of unit="typography" and
n="()" indicating the character used and its occurrence, <milestone unit="typography"
n="******"/>.</li>
<li><l> It is recommended that indentation be recorded and that the rend attribute be
used to do this.</li>
</ul>
[http://www.diglib.org/standards/level4verse.html See some examples in context…]
====Level 4 Front and Back Matter====
<ul>
<li>It is recommended that all prefaces, tables of contents, afterwords, appendices, endnotes and
apparatus be encoded. For publisher's advertisements, indexes, and glossaries or other front or back
matter that isn't considered of primary importance to the text, there are three options:<ul>
<li>Fully transcribe and encode</li>
<li>Link to page images (may include an unencoded transcription)</li>
<li>Omit, noted in <editorialDesc></li>
</ul>
</li>
</ul>
[http://www.diglib.org/standards/level4fandb.html See some examples in context…]

===LEVEL 5: Scholarly Encoding Projects===

<p>Level 5 texts are those that require subject knowledge, and encode semantic, linguistic, prosodic or
other elements beyond a basic structural level.</p>

==General Guidelines for Attribute Usage==

<p>Some general advice on the use of particular attributes
follows.</p>
<ul>
<li><b>type=</b>: Constructing a list of acceptable attribute values
for type that could find wide agreement is impossible. Instead,
it is recommended that projects describe the type= attribute
values used in their texts in the project ODD file or other
documentation and that this list be made available to people
using the texts. See <i>ABC for Book Collectors</i> by John
Carter (7th edition, New Castle, DE:Oak Knoll Books, 1995) for
a list of standard names and definitions of bibliographic
features of printed books. For those elements where type is not
required, such as <head> and <title>, use the
attribute values for subtitles and additional titles, but not
main titles.<br /> Example: <div1 type="volume"></li>

<li><b>n=</b>: Sometimes an n= (number) attribute can be used by itself. For instance in the case of
pagebreaks:<br /> Example: <pb n="456"/></li>

<li><b>id=</b>: If you are in a situation that requires you to
uniquely identify an element that will be used to reference
another specific location in one or more texts, use an id=
attribute. The value of this attribute must be unique within a
document, and must be composed of alphanumeric characters,
dots, hyphens, and underscores, and must start with a
letter.<br /> Example: <note id="n5" n="5"></li>

<li><b>target=</b>: follows the same syntactic rules as the id=
attribute value. In fact, target= and id= are often used in
conjunction with one another as in the case of footnotes where
the <anchor id="n5" n="5"> is at a specific place in the
text and is referred to by the <note target="n5" n="5">
which contains the actual information of the footnote itself
elsewhere.</li>

<li><b>entity=</b>: The entity= attribute is simply the way a
figure indirectly points or refers to its the actual image
file<br /> Example:
<!ENTITY TwaFifrn SYSTEM "TwaFifrn.jpg" NDATA jpeg><br />
<br />
<figure entity="TwaFifrn"></li>

<li><b>rend=</b>: Difficulty using rend= attributes occurs when it is desirable to record
more than one rendition feature. With this in mind, it is recommended that projects employ the
following adaptation of "rendition ladders", a concept developed at the [http://www.wwp.brown.edu/ Brown University Women Writers Project]. This system allows for sets
of multiple renditional features to be included in one rend= value. Rendition ladders consist of categories of
renditional features with values of each of those features enclosed in parentheses.<br /> rend= should only be
used to override a default value. For instance, if all text encoded as <hi> is defined as being
rendered in italics, there is no reason to encode text as <hi rend="font(italics)"> Combining renditional features would result in a tag with attributes such as <l rend="font(italics)align(right)">
<ul>
<li>font <br />italics, bold, fsc (full and smallcaps), smallcap, underlined, gothic</li>
<li>align <br />right, left, center, block</li>
<li>indent <br />Values in parentheses should indicate the number of tabstops to be indented, e.g.,
<l rend="indent(1)"></li>
</ul>
</li>
<li><b>lang=</b>: Use ISO639-2 three-character language codes. Note that this recommendation is slightly different from that of the TEI P5 Guidelines, which recommends the BCP 47 language codes.</li>
</ul>
References: <references/>
[[Category:SIG:Libraries]]

Best Practices for TEI in Libraries

2008-09-22T13:32:31Z

Melanieschlosser: /* <fileDesc> */

[http://www.tei-c.org/wiki/index.php/SIG:Libraries TEI in Libraries: Home]

==Introduction and History==
<p>The Text Encoding Initiative Guidelines for Electronic Text Encoding and Interchange (referred to as
the <i>TEI Guidelines</i>) were first published in 1994 and represent a tremendous
achievement in electronic text standards by providing a highly sophisticated structure for encoding
electronic text. Digital librarians have benefited greatly from the standardization provided by these
guidelines, and the potential for interoperability and long-term preservation of digital collections
facilitated by their wide adoption.</p>

<p>In 1998, the Digital Library Federation (DLF) sponsored the [http://www.lib.umich.edu/lit/dlps/history/teidlf/index.html TEI and XML in Digital Libraries Workshop] at the
Library of Congress to discuss the use of the <i>TEI Guidelines</i> in libraries for electronic text,
and to create a set of best practices for librarians implementing them. From this workshop, three working
groups were formed the members of which represented some of the largest and most mature digital library
programs in the U.S. Group 2 was charged with developing a set of recommendations for libraries using the
TEI Guidelines in electronic text encoding. This group included the following representatives from six libraries:
</p>
<ul>
<li>LeeEllen Friedland, Library of Congress</li>
<li>Nancy Kushigian, University of California, Davis</li>
<li>Christina Powell, University of Michigan</li>
<li>David Seaman, University of Virginia</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>At the ALA mid-winter (January 1999), the DLF task force revised a draft set of best practices, called
TEI Text Encoding in Libraries: Guidelines for Best Practices (referred to as <i>TEI in Libraries
Guidelines</i>). The revised recommendations were circulated to the conference working group in May
1999 and presented at the joint annual meeting of the Association of Computers and the Humanities and
Association of Literary and Linguistic Computing in June 1999. [http://www.diglib.org/standards/tei-old.htm Version 1.0] was circulated for comments in
August 1999. These guidelines were endorsed by the DLF, and have been used by many digital libraries,
including those of the task force members, as a model for their own local best practices. Libraries,
museums and end-users have benefitted from a set of best practices for electronic text in a number of
ways, including better interoperability between electronic text collections, better documented practices
among digital libraries, and a starting point for discussion of best practices with commercial publishers
regarding electronic text creation.</p>

<p>Written in 1998, this first iteration of <i>TEI in Libraries Guidelines</i> made no mention of XML,
XSLT, or any of the other powerful tools that have now become common parlance and practice in creating
digital documents and collections. Based on these important changes in markup technology, it came to the
attention of the DLF and members of the original Task Force that the <i>TEI in Libraries Guidelines</i>
required substantial revision. In 2002, the TEI Consortium published a new edition of the complete
<i>TEI Guidelines</i> that conformed to XML specifications. In order to remain useful, the <i>TEI in
Libraries Guidelines</i> had to be updated to reflect these developments.</p>

<p>Furthermore, librarians need more guidance than the original <i>TEI in Libraries Guidelines</i>
provided. There are many library-specific encoding issues which need to be addressed and documented to
ensure consistency. The intention of this document is to provide recommended paths of encoding for these
issues.</p>

<p>In addition, these library guidelines have the potential to be much more useful if they can serve as a
training document from which librarians can learn about text encoding and addressing particular encoding
challenges. To fulfill this role, the guidelines require more examples and detailed explanations,
giving documentation of the use of TEI in a library context. Librarians also need a set of standards
and best practices for vendors and publishers who create electronic text for digital libraries, so that
these collections adhere to the same archival standards as locally-created electronic text collections.
With detailed guidelines that could serve as an encoding specification, librarians might encourage
vendors to follow the principles in these standards, to facilitate the long-term preservation of
commercially published electronic text collections, and more readily allow for cross-collection
searching.</p>

<p>In order to facilitate the evolution of this document, another DLF-sponsored Task Force—some
of the representatives of which were on the original Task Force—met on October 24-25, 2003 at
the Cosmos Club in Washington, D.C.: </p>
<ul>
<li>Richard Gartner, Oxford University Library</li>
<li>Matthew Gibson, University of Virginia Library</li>
<li>Kirk Hastings, California Digital Library</li>
<li>Christina Powell, University of Michigan</li>
<li>Merrilee Proffitt, RLG</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>These representatives met to revise the original <i>TEI in Libraries Guidelines</i> in order
that they: </p>
<ul>
<li>reflect changes occuring within the text encoding world generally and within the TEI
community specifically</li>
<li>further illuminate the different levels of encoding by offering clearer and more robust
examples.</li>
</ul>
<p>After producing [http://www.diglib.org/standards/tei2/tei20.htm Version 2.0] of the Guidelines, this group (with some changes in membership) met again
at the Cosmos Club on February 13-14, 2006. Those in attendance were: </p>
<ul>
<li>Syd Bauman, The TEI Consortium</li>
<li>Richard Gartner, Oxford University Library (by phone)</li>
<li>Matthew Gibson, Virginia Foundation for the Humanities (chair)</li>
<li>Merrilee Proffitt, RLG</li>
<li>Chris Powell, The University of Michigan</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natasha Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, The University of Michigan</li>
</ul>
<p>This group of continues to meet and based upon their discussions and resolutions, the following
guidelines will continue to be updated and enhanced.</p>

==General Overview and Comments==

<p>These recommendations are for libraries using the XML version of the TEILite DTD (teixlite).
There are many different library text digitization projects, for different purposes. With this in mind,
the Task Force has attempted to make these recommendations as inclusive as possible by developing a
series of encoding levels. These levels are meant to allow for a range of practice, from wholly automated
text creation and encoding, to encoding that requires expert content knowledge, analysis, and editing.</p>

<p>Recommendations for Levels 1-4 are intended for projects wishing to create encoded electronic text with
structural markup, but minimal semantic or content markup. Also, the encoding levels are cumulative:
encoding requirements at each level incorporate the requirements of lower levels. Levels 1-4 allow the
conversion and encoding of texts to be performed without the assistance of deep content knowledge and can
be enriched with more markup at any time. Level 5, in contrast, requires scholarly analysis. </p>

<p>These recommendations are concerned with the text portion of a TEI-encoded document. While there are
modest requirements for including certain information about encoding level in the TEI header, a separate
set of recommendations, now integrated into this document, was developed to address issues concerning TEI header
contents to MARC-format bibliographic data (see the [[#The TEI Header (based on June 16, 2001 Draft)|<teiHeader> section]]).</p>

==General Recommendations==

<p>Note: all recommendations that follow are based on P4:2004, with the exception of the facs= attribute of <pb>, which comes from the P5 module for the transcription of primary sources ('transcr').</p>

<ul>
<li>The encoding level (as described in this document) should be recorded in the
<editorialDecl> in the TEI header, along with an explanation of any deviation from the
recommendations.</li>

<li>Electronic text at all levels of encoding should begin with the transcription of the first word on
the first leaf of the original work. It may be impractical or undesirable to transcribe and encode
certain features of the text, such as publisher's advertisements or indexes, but if at all possible,
they should be included as links to page images. Any omissions of material found in the original work
should be noted in the <editorialDecl> in the TEI header.</li>
<li>File naming should follow ISO 9660 conventions: 8-character filenames, 3-character extensions,
using A-Z, a-z, 0-9, underscores and hyphens. The rationale behind this suggestion is that when moving
texts across different platforms (DOS for instance), some systems will truncate beyond the eighth
character.</li>
<li>We recommend the use of numbered divisions throughout the electronic text, always beginning with
<div1> (we prefer that <div0> not be used since the TEI Guidelines does not
make it available in <front> or <back> matter). Numbered divisions present
advantages to search and indexing software by explicitly communicating the hierarchical level of the
section described. Texts at all levels should include at least one <div1>.</li>
<li>Page breaks should be encoded using the <pb> element,
which should demark the top of a page (i.e. the text of page
seven should immediately follow <pb n="7"/>), and should
always be contained within a division. E.g., a page break that
occurs between chapters 2 and 3 should be encoded near the top
of the <div> that holds chapter 3 (rather than near the bottom
of the <div> that holds chapter 2).</li>
</ul>

==The TEI Header==

===Introduction===
<p>At the TEI and XML in Digital Libraries Workshop that was held at the Library of Congress in July 1998, several working groups
were formed to consider various aspects of the Text Encoding Initiative. Group 1 was charged to recommend some best practices
for TEI header content and to review the relationship between the Text Encoding Initiative header and MARC. To this end,
representatives of the University of Virginia Library and the University of Michigan Library gathered in Ann Arbor in early
October 1998 to develop a recommended practice guide. This work was assisted by similar efforts that had taken place in the United
Kingdom under the auspices of the Oxford Text Archive the previous year.
The following document represents a draft of those recommended practices. It has been submitted to various constituencies for
comment.</p>

===Working Assumptions===
<p>A TEI header can serve many publics. Headers can be created in a text center and reflect the center's standards, or they can
serve as the basis for other types of metadata system records produced by other agencies. Headers can function in detached
form as records in a catalog, as a title page inherent to the document, or as a source for index displays.</p>

<p>In addition, a header may describe a collection of documents, a single item, or a portion of an item. Variances in TEI header
content can result from making different choices of what is being described.</p>

<p>A TEI header may not have a one to one correspondence with a MARC record. One TEI header may have multiple MARC analytic records,
or one MARC record may be used to describe a collection of TEI documents with individual headers.</p>

<p>A TEI header serves several purposes. It may contain an historical background on how the file has been treated. It can extend the
information of a classic catalog record. The Text Center and/or cataloging agency can act as the gatekeeper for creators by
providing standards for content.</p>

===Cataloging a TEI Document===

<p>Does the TEI header act as the electronic title page or as a catalog record? Is it integral to the document it describes or
independent? Depending on the community being served, the TEI elements will reflect the interest of that community. Nonetheless,
it is possible to describe a set of "best practices" that will produce compatible content while accommodating this variety of
purposes. Compatibility of content encourages a more understandable set of results when information about assorted items is
displayed as a set of search results, a contents list, or an index, and it allows for more reasonable conversion of content
information from TEI elements to elements of other metadata sets when this action seems advisable.</p>

<p>It is a traditional practice of librarianship to agree upon where in a document and in what order of preference one should look
to identify the title, author, etc., of that document. This permits a certain consistency in terminology and allows for a certain
amount of authentication of content. We recommend the following preferences to those who create headers and to those who attempt
to use headers to create traditional catalog records that are compliant with AACR2 and ISBD(ER) rules.</p>

<p>As a member of the academic community, the header creator/editor has a responsibility to verify, whenever humanly possible, the
intellectual source for an electronic document that presents itself without any information regarding its source or authorship.</p>

====Chief Sources of Information for Several Types of Electronic Resources Are:====
<ul> <li>1. For an electronic document with a digitized title page (without a header), prefer
<ul>
<li>a) Chief source of information = information coded as title page</li>
<li>b) Use added information from an originating paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>2. Electronic document with header (without a title page)
<ul>
<li>a) Chief source of information = supplied and verified header <ref name="verify">Verified means that the cataloger/editor has established for him/herself that the information represented as title information is an accurate representation of content.</ref></li>

<li>b) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>

<li>3. Electronic document with header and title page
<ul>
<li>a) Chief source of information = supplied header (if verified)<ref name="verify"/></li>
<li>b) If header is not verified, use title page as chief source</li>
<li>c) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>4. If neither header nor title page is present and there is no evidence of a source document, the header creator
<ul>
<li>a) May assign a title and author if appropriate</li>
<li>b) Enclose the information in brackets, using the standard English language convention for editorial interjections</li>
</ul>
</li>
<li>5. If neither header nor title page is present but the header creator has satisfactory evidence of an originating source, that
document should be used as the chief source of information for the title and author of the header. If the source cannot be fully
verified as to edition, authorship, etc., this fact should be clearly indicated in a note in the <fileDesc>.
</li>

</ul>

===Element Recommendations for the <teiHeader>===

<table border="1" width="80%">
<tr>
<td colspan="1"><teiHeader type="____"></td>
<td colspan="1">
Standards which apply to the header, e.g., <teiHeader type="ISBD(ER)">, <teiHeader
type="AACR2">
</td>
</tr>
</table>

===<fileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<title type="____"></td>
<td colspan="1">
Only uniform title and main title for the TEI document, not the source document, should be entered here, e.g., <title type="uniform"> or <title type="main">. See <sourceDesc> for other title forms for documents where a user might seek the documents under titles other than those assigned. Where a title is supplied, the title should be enclosed in square brackets using standard English-language conventions for editorial insertion.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of original source (electronic or print) should be entered into the <author> element before the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.
</td>
</tr>

<tr>
<td colspan="1">
<editor></td>
<td colspan="1">
Editor of original source (electronic or print) should be entered into the <editor> element <b>before</b> the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.</td>

</tr>

<tr>
<td colspan="1">
<respStmt></td>
<td colspan="1">
The editor (also compiler, illustrator) of the TEI document, not the source document, should be entered here. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<editionStmt></td>

<td colspan="1">
This element should be used sparingly as there are currently no standards as to when versions become editions. Users should refer to the TEI guidelines.</td>
</tr>

<tr>
<td colspan="1">

<extent></td>
<td colspan="1">
Use the standard text "ca.**** kilobytes".</td>
</tr>

<tr>
<td colspan="1">

<publicationStmt></td>
<td colspan="1">
Use the child elements below rather than <p> for a prose description.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
The publisher is whoever has collected the TEI document, not the source document, and has made decisions concerning it.</td>
</tr>

<tr>

<td colspan="1">

<distributor></td>
<td colspan="1">
The distributor is whoever makes the TEI document, not the source document, available.</td>
</tr>

<tr>
<td colspan="1">
<idno></td>
<td colspan="1">
Any unique identification number determined by the publisher. Use type="OCLC-___" to point to the catalog record for the TEI document, if applicable. The institution's three-letter MARC code follows "OCLC-" in the attribute value. Alternatively, use an ISO 15511 code in the type attribute to specify the holding institution.</td>

</tr>

<tr>
<td colspan="1">
<availability></td>
<td colspan="1">
Describe any rights statement for the TEI document. Use a standard scheme, such as the code for a Creative Commonse license, for the value of the status attribute if possible.</td>
</tr>

<tr>
<td colspan="1">
<date></td>
<td colspan="1">
Refers to the date of the publication of the electronic document. <b>For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.</b></td>
</tr>

<tr>
<td colspan="1">
<seriesStmt></td>

<td colspan="1">
Whenever possible, establish the national authority file authorized form for the electronic locally created series.
</td>
</tr>

<tr>
<td colspan="1">
<notesStmt></td>

<td colspan="1">
Optional, depending on display decisions. Should be used for indicating questionable attributions for title, author, etc.</td>

</tr>

<tr>
<td colspan="1">
<sourceDesc></td>
<td colspan="1">
In order to effectively represent the source(s) when many documents are represented by the TEI header, we see the need for structured elements that minimally allow us to identify parent-child and component relationships. In the absence of these structures, we suggest that multiple source descriptions be employed with relationships described in free text. Relationships also could be useful in other portions of the TEI header. Cataloger may need to do research to establish the original source.</td>
</tr>

<tr>

<td colspan="1">
<bibl> or
<biblStruct> or
<biblFull></td>
<td colspan="1">
Prefer <biblFull> to allow searching on parts of the description. </td>

</tr>

<tr>
<td colspan="1">
<title></td>
<td colspan="1">
It is possible to have multiple <title> fields in <biblFull>. Alternative titles (cover, running, spine titles) should be entered in separate <title> fields in the <biblFull> field in the <sourceDesc> where they are searchable.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
If the name of the author(s) in the originating source differs from the established form, include here the form from the source tagged <author type="alternate">.</td>
</tr>

<tr>
<td colspan="1">

<editionStmt></td>
<td colspan="1">
Enter edition statement as found on the original source.</td>
</tr>

<tr>
<td colspan="1">
<extent></td>

<td colspan="1">
Enter physical description for the original source.</td>
</tr>

<tr>
<td colspan="1">
<publicationStmt> <publisher></td>
<td colspan="1">
Don't repeat field. Enter multiple publishers divided by semicolons.</td></tr>

<tr>
<td colspan="1">
<pubPlace></td>
<td colspan="1">

Don't repeat field. Enter multiple publishers divided by semicolons.</td>
</tr>

<tr>
<td colspan="1">
<date></td>

<td colspan="1">
Imprint date for the original source. '''For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.'''</td>
</tr>

<tr>

<td colspan="1">
<idno></td>
<td colspan="1">
In this location, <idno> refers to identification numbers for the source document. They can be used to indicate the source's location in an individual institution's collection. If a formal standard location system is being used, indicate the nature of the system, e.g., <idno type="LC call number">.</td>

</tr>

<tr>
<td colspan="1">
<seriesStmt></td>

<td colspan="1">
Establish via national authority file the series statement of original document.</td>
</tr>

<tr>
<td colspan="1">
<notes></td>

<td colspan="1">
Caution: Notes made here should refer to the original source.</td>
</tr>
</table>

===<encodingDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<projectDesc></td>
<td colspan="1">Enter a description of the purpose for which the electronic file was encoded.</td>
</tr>

<tr>
<td colspan="1">
<editorialDecl></td>
<td colspan="1">
Enter general and specific statements about how the electronic file has been treated. Record here editorial decisions made
during encoding.</td>

</tr>

<tr>
<td colspan="1">
<refsDecl></td>
<td colspan="1">
<refsDecl> seems a possibility for administrative metadata, e.g., pagination and page sequencing.</td>
</tr>

<tr>

<td colspan="1">

<classDecl> <taxonomy id="____"></td>
<td colspan="1">
If used, identify the appropriate taxonomy definitions or descriptive sources in the <taxonomy> element followed by id, e.g.,
<taxonomy id="LCSH">, <taxonomy id="AAT">.</td>
</tr>
</table>

===<profileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<creation>
     <date></td>
<td colspan="1">
Use the date as it comes from the creator. '''For most purposes, the year date (yyyy) will be adequate. If greater detail is required, enter dates as yyymmdd.'''</td>
</tr>

<tr>
<td colspan="1">
<langUsage></td>
<td colspan="1">
Language usage is specified by document creators. Use standard language names.</td>
</tr>

<tr>
<td colspan="1">

<language id="____"></td>
<td colspan="1">
Use the ISO 639-2 standard (which is the same as the MARC language codes).</td>

</tr>

<tr>
<td colspan="1">
<textClass></td>
<td colspan="1">
True classification numbers as opposed to call numbers can be entered here.</td>

</tr>

<tr>
<td colspan="1">
<keywords><br />

<term>
</td>
<td colspan="1">
Use for uncontrolled terms.</td>
</tr>

<tr>
<td colspan="1">
<keywords scheme="____"><br />
<term>
</td>
<td colspan="1">
Use for controlled vocabulary as specified in <encodingDesc> taxonomy id. Example: scheme="LCSH"</td>

</tr>
</table>

===<revisionDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<change>
<resp>
<item></td>
<td colspan="1">
Use the specific codes to note revisions rather than free text description. Include the entire date
(e.g., 19991101).</td>

</tr>
</table>

===Minimal TEI Header Recommendation===
<blockquote>
<div class="indent"><teiHeader></div>
<div class="lindent"><fileDesc></div>

<div class="lindent2"><titleStmt></div>
<div class="lindent3"><title></title></div>
<div class="lindent3"><author></author></div>
<div class="lindent2"></titleStmt>

</div>
<div class="lindent2"><publicationStmt>
</div>
<div class="lindent3"><publisher></publisher>

</div>
<div class="lindent3"><pubPlace></pubPlace>
</div>
<div class="lindent3"><idno></idno>
</div>
<div class="lindent3"><availability><p></p></availability>
</div>
<div class="lindent3"><date></date>

</div>
<div class="lindent2"></publicationStmt>

</div>
<div class="lindent2"><sourceDesc>
</div>
<div class="lindent3"><biblFull>
</div>
<div class="lindent4"><titleStmt>
</div>
<div class="lindent5"><title></title>

</div>
<div class="lindent5"><author></author>
</div>
<div class="lindent4"></titleStmt>
</div>
<div class="lindent4"><publicationStmt>
</div>
<div class="lindent5"><publisher></publisher>
</div>
<div class="lindent5"><pubPlace></pubPlace>

</div>
<div class="lindent5"><date></date>
</div>
<div class="lindent4"></publicationStmt>
</div>
<div class="lindent3"></biblFull>
</div>
<div class="lindent2"></sourceDesc>
</div>
<div class="lindent"></fileDesc>
</div>

<div class="indent"></teiHeader>
</div>
</blockquote>

Repeat the <biblFull> field, as appropriate, if there is more than one source for the electronic item. [http://www.diglib.org/standards/teiheaders.html See some examples in context …]

===Recommended Additions to the teixlite DTD===
<ul>
<li>Add elements under <name> to allow for the variable ordering and alphabetization of names:
<forename>, <surname>, <birthdate>, <deathdate>, <title>, etc.</li>

<li>In order to effectively represent the source(s) when many documents are
represented by the TEI header, we see the need for structured elements that, minimally,
allow us to identify parent-child and component relationships.</li>
</ul>

===Acknowledgments and Bibliography===
<ul>
<li>
This guide was prepared by Judy Ahronheim, Thomas Champagne, Lynn Marko, Kelly Webster, and Chris Wilcox of the University of
Michigan Library and Jackie Shieh of the University of Virginia Library in October 1998. The source documents were the cataloging
guides prepared by those two institutions ([http://www.lib.virginia.edu/cataloging/manual/chapters/chapxiib.html Virginia] and [http://www.lib.umich.edu/ts/sections/electronicresourcesdev.html Michigan]). In addition,
documentation from the Oxford Text Archive, Arts and Humanities Data Service of the United Kingdom also was made available to assist
in this effort.

</li>
<li>
For a description of TEI header elements and correstponding USMARC fields, see Appendix A at
[http://etext.lib.virginia.edu/tei/tei-usmarc.html http://etext.lib.virginia.edu/tei/tei-usmarc.html].
</li>
</ul>

==Encoding Levels==
===LEVEL 1: Fully Automated Conversion and Encoding===

'''Purpose''': To create electronic text with the primary purpose of keyword searching and linking to page images. The primary advantage in using the teixlite DTD at this level is that a TEI header is attached to the text file.

<p>
'''Rationale''': The text is subordinate to the page image, and is not intended to
stand alone as an electronic text (without page images).</p>

<p>Texts at Level 1 can be created and encoded by fully automated means, using uncorrected OCR of page
images ("dirty OCR"), exporting from existing electronic text files, or actually not including any text
at all. Only those elements that are necessary to divide the text from the header and facilitate linking to
page images are used. Encoding is performed automatically based on artifacts of the OCR or other
document creation process (page breaks, for example) and metadata collected during the imaging or
preparation process. This encoding is both minimal and reliable, and does not typically require
extensive review of each page of each text.</p>

<p>Level 1 texts are not intended to be adequate for textual analysis; they are more likely to be suited
to the goals of a preservation unit or mass digitization initiative. Though their encoding is minimal,
Level 1 texts are fully valid XML texts. In addition to taking advantage of the TEI header, using the
teixlite DTD--with the consistency suggested by these guidelines--allows Level 1 texts to be compatible
with more richly encoded teixlite texts (that also follow these guidelines) for
searching, for example. Further encoding based on document structures or content analysis can be added
to a Level 1 text at any time.</p>

<p>
'''Level 1 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>a large volume of material is to be made available online quickly</li>
<li>a digital image of each page is desired</li>
<li>no manual intervention will be performed in the text creation process</li>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>sophisticated search and display capabilities based on the structure of the text are not necessary</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<table border="1" width="80%">
<tr>
<td colspan="1"><div1></td>
<td colspan="1">If no type= attribute is specified, a type= value of
"section" should be presumed.</td>
</tr>

<tr>
<td colspan="1"><p></td>
<td colspan="1">At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using <p> in order that the document be open to being extended to other encoding levels).</td>
</tr>
<tr>

<td colspan="1"><pb></td>
<td colspan="1">Required in Level 1. Page images can be linked to the text by specifying a jpeg or other image file as the value of the facs= attribute. Page numbers can be supplied with the n= attribute to record the number that is on the page. The Task Force sees the use of METS here as having a tremendous advantage. METS/TEI page turning documentation will be included in the near future.</td>
</tr>
</table>

====Basic Structural Example:====
<pre>
<TEI.2 id="someid">
<teiHeader>
[Source and processing information goes here]
</teiHeader>
<text>
<body>
<div1>
<p>
<pb id="p00000001" n="1"/>
[main body of the unmarked up plain text begins here]
<pb id="p00000002" n="2"/>
[more plain text goes here with appropriate page breaks interspersed] ...
<pb id="p00000145" n="145"/>
[more plain text]
<pb id="p00000146" n="146"/>
[text ends here]
</p>
</div1>
</body>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level1example.html See an example in context…]

===LEVEL 2: Minimal Encoding===
'''Purpose''': To create electronic text for full-text searching, linking to page images, and identifying simple structural hierarchy to improve navigation.

'''Rationale''': The text is subordinate to the page image, though navigational markers (textual divisions, headings) are captured. The text could stand alone as electronic text (without page images) if the accuracy of its contents is suitable to its intended use and it is not necessary to display low-level typographic or structural information. Level 2 requires a set of elements more granular than those of Level 1, including bibliographic or structural information below the monographic or volume level.

Though texts at Level 2 can be created and encoded by automated means, based on the typographic elements in the electronic file (for example, bold centered text at the top of the page surrounded by whitespace indicates a new chapter heading, and thus a new division), it is not likely to be absolutely reliable across a large body of material. Level 2 encoding requires some human intervention to identify each textual division and heading. Level 2 texts do not require any special knowledge or manual intervention below the section level.

Level 2 texts are not intended to be displayed separately from their page images. Level 2 encoding of sections and headings provides greater navigational possibilities than Level 1 encoding, and enables searching to be restricted within particular textual divisions (for example, searching for two phrases within the same chapter).

'''Level 2 is most suitable for projects with the following characteristics''':

* a large volume of material is to be made available online quickly
* a digital image of each page is desired
* the material is of interest to a large community of users who wish to read texts that allow keyword searching
* rudimentary search and display capabilities based on the large structures of the text are desired
* each text will be checked to ensure that divisions and headers are properly identified
* extensibility is desired; that is, one desires to keep open the option for a higher level of encoding to be added at a later date

All elements specified in Level 1 plus the following:

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>
<td colspan="1">Optional</td>
</tr>
<tr>
<td colspan="1"><div1></td>
<td colspan="1">type="section" is the default attribute value. It is recommended that the n= attribute be
included to record the sequence of divisions.</td>
</tr>
<tr>
<td colspan="1"><head></td>
<td colspan="1">Required if present</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">One "container" element per div is required.</td>
</tr>
</table>

====Basic Structural Example:====

<pre>
<TEI.2 id="someid">
<teiHeader> [Source and processing information goes here] </teiHeader>
<text id="someotherid">
<front> [titlepage information, table of contents, prefaces, etc.] </front>
<body>
<div1 type="chapter" n="1">
<head>Chapter 1</head>
<p>[text of Chapter 1 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="2">
<head>Chapter 2</head>
<p>[text of Chapter 2 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="3">
<head>Chapter 3</head> [text of Chapter 3 goes here interspersed with <pb> elements
pointing to page images] </div1>
<div1 type="chapter" n="4">
<head>Chapter 4</head> [text of Chapter 4 goes here interspersed with <pb> elements
pointing to page images] </div1>
</body>
<back> [optional text of backmatter, appendices, etc.] </back>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level2example.html See an example in context…]

===LEVEL 3: Simple Analysis===

<p>
'''Purpose''': To create text that can stand alone as electronic text and identifies
hierarchy and typography without content analysis being of primary importance.</p>

<p>
'''Rationale''': Level 3 texts can be created from scratch or by the relatively easy
conversion of existing HTML or word-processing documents. Encoding offers the advantage of the TEI
header, interoperability with other TEI collections, and extensibility to higher levels of encoding.
Level 3 generally requires some human editing, but the features to be encoded are determined by the
appearance of the text and not specialized content analysis.</p>

<p>Level 3 texts identify front and back matter, and all paragraph breaks. The finer granularity of
encoding these features, as well as figures, notes, and all changes of typography, allows a range of
options for display, delivery, and searching. For example, one has the option of identifying and,
therefore, specifying the display charactersitics of different typographic styles, and regularizing the
display and placement of note text.</p>

<p>Level 3 texts can stand alone as text without page images and, therefore, can be uploaded, downloaded
and delivered quickly, and require less storage space than digital collections with page images.
However, the simple level of structural anaylsis and absence of specialized content analysis reflected
in Level 3 encoding may make it desirable for some, depending on project priorities, to include page
images in order to provide users with a fuller set of resources.</p>

<p>
'''Level 3 is most suitable for projects with the following characteristics:'''
</p>

<ul>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>some sophistication of display, delivery, and searching based on structure of the text is desired</li>
<li>each text will be checked to ensure that encoding decisions have been made appropriately</li>
<li>the users of the texts may have limited storage or display capabilities</li>
<li>the creator of the texts has limited or no ability to provide content expertise to analyze, tag,
or review texts</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<p>All elements specified in Levels 1 and 2, plus the following:</p>

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>

<td colspan="1">Required if present.</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">Required for paragraph breaks in prose; may be used for stanzas using <lb> for
line breaks in verse.</td>
</tr>

<tr>
<td colspan="1"><list> and <item></td>
<td colspan="1">May be used in this level to indicate ordered and unordered list structures.</td>
</tr>
<tr>
<td colspan="1"><table>, <row>, and <cell></td>

<td colspan="1">May be used to indicate table structures.</td>
</tr>
<tr>
<td colspan="1"><figure></td>
<td colspan="1">Required to indicate figures other than page images.</td>
</tr>
<tr>

<td colspan="1"><hi></td>
<td colspan="1">Required to indicate changes in typeface; rend attribute is optional.</td>
</tr>
<tr>
<td colspan="1"><note></td>
<td colspan="1">All notes must be encoded. It is also recommended that notes that extend beyond one page be combined into one <note> element. Marginal notes, without reference, should occur at the beginning of the paragraph to which they refer, with the value of the place attribute as "margin".</td>

</tr>
<tr>
<td colspan="1"><lb></td>
<td colspan="1">May be used to force line breaks.</td>
</tr>
</table>

<p>NOTE ON <note>:</p>

<p>It may be desirable to move footnotes from their original location in the text. If left at the bottom
of a page, a note may become included in another paragraph or section of the encoded text, and thus
separated from its reference. There are options for placement of footnotes if they are moved:</p>

<ul>
<li>Inline. The note is inserted at the point of reference. An n attribute records the value of the
note reference if there is one.</li>
<li>End-of-Division. Notes moved to the end of the division</li>
</ul>

<p>

'''Basic Structural Example forthcoming ...'''
</p>

===LEVEL 4: Basic Content Analysis===
<p>'''Purpose''': To create text that can stand alone as electronic text, identifies
hierarchy and typography, specifies function of textual and structural elements, and describes the
nature of the content and not merely its appearance. This level is not meant to encode or identify all
structural, semantic or bibliographic features of the text.</p>

<p>
'''Rationale''': Greater description of function and content allows for:</p>

<ul>
<li>flexibility of display and delivery</li>
<li>sophisticated searching within specified textual and structural elements</li>
<li>combining the broadest range of uses and audiences</li>

</ul>

<p>Texts encoded at Level 4 are able to stand alone as part of a library collection, and do not require
page images in order for them to be read by students, scholars and general readers. This level of TEI
encoding allows them to be displayed or printed in a variety of ways suitable for classroom or scholarly
use.</p>

<p>Level 4 texts contain elements and attributes that describe content. For example, lines of verse are
tagged with <l>; the <p> element is reserved for true paragraphs. Features of
the text that may contribute to meaning, such as indentation of verse lines and typographic change, are
preserved. These are textual features that are not encoded at lower levels and that allow the text to be
used and understood fully independent of images.</p>

<p>The ability to stand alone as text means that Level 4 texts are more nimble and robust for exercises
such as format repurposing and textual analysis.</p>

<p>Finally, functionally accurate encoding in Level 4 texts
allows them to be searched or displayed in sophisticated ways.
For example, a searcher could limit his or her search in a
dramatic text to stage directions or in a verse text to only
first lines. In a politicall tract published by subscription, a
search could be confined to names that appear in lists, thus
limiting a search to names of people who subscribed to a
particular volume. This ability to limit searches becomes more
significant as textbases become larger, and thus is of great
importance to the library community as it attempts to build into
the initial design and implementation of textbases the features
needed to enhance interoperability.</p>

<p>
'''Level 4 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>sophisticated search and retrieval capabilities are desired</li>

<li>the texts will be used for textual analysis</li>
<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added by the scholarly community at a later date</li>
<li>the users of the texts may have limited storage or display capabilities</li>
</ul>

====General Level 4 Recommendations====
<ul>
<li>Typographically distinct text should be encoded as appropriate,
e.g. with <term>, <q>, <gloss>, <mentioned>, <soCalled>, <foreign>,
<title>, or <emph>. Any ambiguous emphasized text should be
encoded as <hi> (e.g. <hi rend="bold">).</li>
<li>It is recommended that the <sic> element be used to
indicate typographic errors, with corrections (if any) noted
as the value of the corr= attribute.</li>
<li><titlePage> should include the verso if present, divided by <pb
n="verso"/>. Tables of contents, errata, subscription lists, "other titles by the same author"
should be included in a separate numbered division, as a <list> with <item>s.
Frontispieces should be encoded as a <figure>, within a separate numbered division and
<p>.</li>
</ul>

[http://www.diglib.org/standards/level4genrec.html See some examples in context…]

====Level 4 Prose====
<ul>
<li>Letters that occur within the text body provide some challenges. It is recommended that quoted
letters that occur as part of a text (and not collections of letters themselves) be encoded within
<q><text><body><div1 type="letter">, with
<opener>, <dateline>, <salute>, <signed>,
<closer> included as appropriate.</li>

<li>Quotations that do not occur inline, but are set off typographically in some way, should be
encoded as <q>.</li>
<li>Notes are to be encoded as described in Level 3.</li>
<li><argument>, <opener>, <epigraph>,
<closer>, <trailer>, <add>, <del>,
<unclear> as appropriate.</li>

</ul>

[http://www.diglib.org/standards/level4prose.html See some examples in context…]

====Level 4 Drama====
<ul>
<li>Cast lists should be encoded as <list>s, with <item>s.</li>

<li>Speeches are encoded as <sp>, with speakers identified within
<speaker> elements; stage directions are encoded as <stage> and enclose
block level content describing scenery, etc.</li>
</ul>

[http://www.diglib.org/standards/level4drama.html See some examples in context…]

====Level 4 Oral History====
<ul>
<li>Speakers in interviews can be identified in the <teiHeader> in several ways.
<ul>
<li>In the <profileDesc>, in the <particDesc> in a <list>, with <name> inside of <item>s.</li>

<li>As a list of author <name>s within <fileDesc><titleStmt></li>
</ul>
</li>
<li>In either method, use an id= on the <name> element to uniquely identify the individual participant</li>

<li>Questions and answers from interviewees and interviewers are encoded as <sp>,
with speakers identified within <speaker> elements with a who= attribute the value of which
corresponds to the id= in the list of interview participants.</li>
</ul>
[http://www.diglib.org/standards/level4oh.html See some examples in context…]

====Level 4 Verse====
<ul>
<li>All verse, even poems without separate stanzas or verse paragraphs, should be contained within a
line group element <lg>. This will assist with automated processing and retrieval.</li>
<li>It is common to see informal divisions within poems, noted by a string of asterisks or periods.
These should be encoded as <milestone/>s with attribute values of unit="typography" and
n="()" indicating the character used and its occurrence, <milestone unit="typography"
n="******"/>.</li>
<li><l> It is recommended that indentation be recorded and that the rend attribute be
used to do this.</li>
</ul>
[http://www.diglib.org/standards/level4verse.html See some examples in context…]
====Level 4 Front and Back Matter====
<ul>
<li>It is recommended that all prefaces, tables of contents, afterwords, appendices, endnotes and
apparatus be encoded. For publisher's advertisements, indexes, and glossaries or other front or back
matter that isn't considered of primary importance to the text, there are three options:<ul>
<li>Fully transcribe and encode</li>
<li>Link to page images (may include an unencoded transcription)</li>
<li>Omit, noted in <editorialDesc></li>
</ul>
</li>
</ul>
[http://www.diglib.org/standards/level4fandb.html See some examples in context…]

===LEVEL 5: Scholarly Encoding Projects===

<p>Level 5 texts are those that require subject knowledge, and encode semantic, linguistic, prosodic or
other elements beyond a basic structural level.</p>

==General Guidelines for Attribute Usage==

<p>Some general advice on the use of particular attributes
follows.</p>
<ul>
<li><b>type=</b>: Constructing a list of acceptable attribute values
for type that could find wide agreement is impossible. Instead,
it is recommended that projects describe the type= attribute
values used in their texts in the project ODD file or other
documentation and that this list be made available to people
using the texts. See <i>ABC for Book Collectors</i> by John
Carter (7th edition, New Castle, DE:Oak Knoll Books, 1995) for
a list of standard names and definitions of bibliographic
features of printed books. For those elements where type is not
required, such as <head> and <title>, use the
attribute values for subtitles and additional titles, but not
main titles.<br /> Example: <div1 type="volume"></li>

<li><b>n=</b>: Sometimes an n= (number) attribute can be used by itself. For instance in the case of
pagebreaks:<br /> Example: <pb n="456"/></li>

<li><b>id=</b>: If you are in a situation that requires you to
uniquely identify an element that will be used to reference
another specific location in one or more texts, use an id=
attribute. The value of this attribute must be unique within a
document, and must be composed of alphanumeric characters,
dots, hyphens, and underscores, and must start with a
letter.<br /> Example: <note id="n5" n="5"></li>

<li><b>target=</b>: follows the same syntactic rules as the id=
attribute value. In fact, target= and id= are often used in
conjunction with one another as in the case of footnotes where
the <anchor id="n5" n="5"> is at a specific place in the
text and is referred to by the <note target="n5" n="5">
which contains the actual information of the footnote itself
elsewhere.</li>

<li><b>entity=</b>: The entity= attribute is simply the way a
figure indirectly points or refers to its the actual image
file<br /> Example:
<!ENTITY TwaFifrn SYSTEM "TwaFifrn.jpg" NDATA jpeg><br />
<br />
<figure entity="TwaFifrn"></li>

<li><b>rend=</b>: Difficulty using rend= attributes occurs when it is desirable to record
more than one rendition feature. With this in mind, it is recommended that projects employ the
following adaptation of "rendition ladders", a concept developed at the [http://www.wwp.brown.edu/ Brown University Women Writers Project]. This system allows for sets
of multiple renditional features to be included in one rend= value. Rendition ladders consist of categories of
renditional features with values of each of those features enclosed in parentheses.<br /> rend= should only be
used to override a default value. For instance, if all text encoded as <hi> is defined as being
rendered in italics, there is no reason to encode text as <hi rend="font(italics)"> Combining renditional features would result in a tag with attributes such as <l rend="font(italics)align(right)">
<ul>
<li>font <br />italics, bold, fsc (full and smallcaps), smallcap, underlined, gothic</li>
<li>align <br />right, left, center, block</li>
<li>indent <br />Values in parentheses should indicate the number of tabstops to be indented, e.g.,
<l rend="indent(1)"></li>
</ul>
</li>
<li><b>lang=</b>: Use ISO639-2 three-character language codes. Note that this recommendation is slightly different from that of the TEI P5 Guidelines, which recommends the BCP 47 language codes.</li>
</ul>
References: <references/>
[[Category:SIG:Libraries]]

Best Practices for TEI in Libraries

2008-09-22T13:29:20Z

Melanieschlosser: /* The TEI Header (based on June 16, 2001 Draft) */

[http://www.tei-c.org/wiki/index.php/SIG:Libraries TEI in Libraries: Home]

==Introduction and History==
<p>The Text Encoding Initiative Guidelines for Electronic Text Encoding and Interchange (referred to as
the <i>TEI Guidelines</i>) were first published in 1994 and represent a tremendous
achievement in electronic text standards by providing a highly sophisticated structure for encoding
electronic text. Digital librarians have benefited greatly from the standardization provided by these
guidelines, and the potential for interoperability and long-term preservation of digital collections
facilitated by their wide adoption.</p>

<p>In 1998, the Digital Library Federation (DLF) sponsored the [http://www.lib.umich.edu/lit/dlps/history/teidlf/index.html TEI and XML in Digital Libraries Workshop] at the
Library of Congress to discuss the use of the <i>TEI Guidelines</i> in libraries for electronic text,
and to create a set of best practices for librarians implementing them. From this workshop, three working
groups were formed the members of which represented some of the largest and most mature digital library
programs in the U.S. Group 2 was charged with developing a set of recommendations for libraries using the
TEI Guidelines in electronic text encoding. This group included the following representatives from six libraries:
</p>
<ul>
<li>LeeEllen Friedland, Library of Congress</li>
<li>Nancy Kushigian, University of California, Davis</li>
<li>Christina Powell, University of Michigan</li>
<li>David Seaman, University of Virginia</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>At the ALA mid-winter (January 1999), the DLF task force revised a draft set of best practices, called
TEI Text Encoding in Libraries: Guidelines for Best Practices (referred to as <i>TEI in Libraries
Guidelines</i>). The revised recommendations were circulated to the conference working group in May
1999 and presented at the joint annual meeting of the Association of Computers and the Humanities and
Association of Literary and Linguistic Computing in June 1999. [http://www.diglib.org/standards/tei-old.htm Version 1.0] was circulated for comments in
August 1999. These guidelines were endorsed by the DLF, and have been used by many digital libraries,
including those of the task force members, as a model for their own local best practices. Libraries,
museums and end-users have benefitted from a set of best practices for electronic text in a number of
ways, including better interoperability between electronic text collections, better documented practices
among digital libraries, and a starting point for discussion of best practices with commercial publishers
regarding electronic text creation.</p>

<p>Written in 1998, this first iteration of <i>TEI in Libraries Guidelines</i> made no mention of XML,
XSLT, or any of the other powerful tools that have now become common parlance and practice in creating
digital documents and collections. Based on these important changes in markup technology, it came to the
attention of the DLF and members of the original Task Force that the <i>TEI in Libraries Guidelines</i>
required substantial revision. In 2002, the TEI Consortium published a new edition of the complete
<i>TEI Guidelines</i> that conformed to XML specifications. In order to remain useful, the <i>TEI in
Libraries Guidelines</i> had to be updated to reflect these developments.</p>

<p>Furthermore, librarians need more guidance than the original <i>TEI in Libraries Guidelines</i>
provided. There are many library-specific encoding issues which need to be addressed and documented to
ensure consistency. The intention of this document is to provide recommended paths of encoding for these
issues.</p>

<p>In addition, these library guidelines have the potential to be much more useful if they can serve as a
training document from which librarians can learn about text encoding and addressing particular encoding
challenges. To fulfill this role, the guidelines require more examples and detailed explanations,
giving documentation of the use of TEI in a library context. Librarians also need a set of standards
and best practices for vendors and publishers who create electronic text for digital libraries, so that
these collections adhere to the same archival standards as locally-created electronic text collections.
With detailed guidelines that could serve as an encoding specification, librarians might encourage
vendors to follow the principles in these standards, to facilitate the long-term preservation of
commercially published electronic text collections, and more readily allow for cross-collection
searching.</p>

<p>In order to facilitate the evolution of this document, another DLF-sponsored Task Force—some
of the representatives of which were on the original Task Force—met on October 24-25, 2003 at
the Cosmos Club in Washington, D.C.: </p>
<ul>
<li>Richard Gartner, Oxford University Library</li>
<li>Matthew Gibson, University of Virginia Library</li>
<li>Kirk Hastings, California Digital Library</li>
<li>Christina Powell, University of Michigan</li>
<li>Merrilee Proffitt, RLG</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natalia Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, Indiana University (chair)</li>
</ul>
<p>These representatives met to revise the original <i>TEI in Libraries Guidelines</i> in order
that they: </p>
<ul>
<li>reflect changes occuring within the text encoding world generally and within the TEI
community specifically</li>
<li>further illuminate the different levels of encoding by offering clearer and more robust
examples.</li>
</ul>
<p>After producing [http://www.diglib.org/standards/tei2/tei20.htm Version 2.0] of the Guidelines, this group (with some changes in membership) met again
at the Cosmos Club on February 13-14, 2006. Those in attendance were: </p>
<ul>
<li>Syd Bauman, The TEI Consortium</li>
<li>Richard Gartner, Oxford University Library (by phone)</li>
<li>Matthew Gibson, Virginia Foundation for the Humanities (chair)</li>
<li>Merrilee Proffitt, RLG</li>
<li>Chris Powell, The University of Michigan</li>
<li>David Seaman, Digital Library Federation</li>
<li>Natasha Smith, University of North Carolina at Chapel Hill</li>
<li>Perry Willett, The University of Michigan</li>
</ul>
<p>This group of continues to meet and based upon their discussions and resolutions, the following
guidelines will continue to be updated and enhanced.</p>

==General Overview and Comments==

<p>These recommendations are for libraries using the XML version of the TEILite DTD (teixlite).
There are many different library text digitization projects, for different purposes. With this in mind,
the Task Force has attempted to make these recommendations as inclusive as possible by developing a
series of encoding levels. These levels are meant to allow for a range of practice, from wholly automated
text creation and encoding, to encoding that requires expert content knowledge, analysis, and editing.</p>

<p>Recommendations for Levels 1-4 are intended for projects wishing to create encoded electronic text with
structural markup, but minimal semantic or content markup. Also, the encoding levels are cumulative:
encoding requirements at each level incorporate the requirements of lower levels. Levels 1-4 allow the
conversion and encoding of texts to be performed without the assistance of deep content knowledge and can
be enriched with more markup at any time. Level 5, in contrast, requires scholarly analysis. </p>

<p>These recommendations are concerned with the text portion of a TEI-encoded document. While there are
modest requirements for including certain information about encoding level in the TEI header, a separate
set of recommendations, now integrated into this document, was developed to address issues concerning TEI header
contents to MARC-format bibliographic data (see the [[#The TEI Header (based on June 16, 2001 Draft)|<teiHeader> section]]).</p>

==General Recommendations==

<p>Note: all recommendations that follow are based on P4:2004, with the exception of the facs= attribute of <pb>, which comes from the P5 module for the transcription of primary sources ('transcr').</p>

<ul>
<li>The encoding level (as described in this document) should be recorded in the
<editorialDecl> in the TEI header, along with an explanation of any deviation from the
recommendations.</li>

<li>Electronic text at all levels of encoding should begin with the transcription of the first word on
the first leaf of the original work. It may be impractical or undesirable to transcribe and encode
certain features of the text, such as publisher's advertisements or indexes, but if at all possible,
they should be included as links to page images. Any omissions of material found in the original work
should be noted in the <editorialDecl> in the TEI header.</li>
<li>File naming should follow ISO 9660 conventions: 8-character filenames, 3-character extensions,
using A-Z, a-z, 0-9, underscores and hyphens. The rationale behind this suggestion is that when moving
texts across different platforms (DOS for instance), some systems will truncate beyond the eighth
character.</li>
<li>We recommend the use of numbered divisions throughout the electronic text, always beginning with
<div1> (we prefer that <div0> not be used since the TEI Guidelines does not
make it available in <front> or <back> matter). Numbered divisions present
advantages to search and indexing software by explicitly communicating the hierarchical level of the
section described. Texts at all levels should include at least one <div1>.</li>
<li>Page breaks should be encoded using the <pb> element,
which should demark the top of a page (i.e. the text of page
seven should immediately follow <pb n="7"/>), and should
always be contained within a division. E.g., a page break that
occurs between chapters 2 and 3 should be encoded near the top
of the <div> that holds chapter 3 (rather than near the bottom
of the <div> that holds chapter 2).</li>
</ul>

==The TEI Header==

===Introduction===
<p>At the TEI and XML in Digital Libraries Workshop that was held at the Library of Congress in July 1998, several working groups
were formed to consider various aspects of the Text Encoding Initiative. Group 1 was charged to recommend some best practices
for TEI header content and to review the relationship between the Text Encoding Initiative header and MARC. To this end,
representatives of the University of Virginia Library and the University of Michigan Library gathered in Ann Arbor in early
October 1998 to develop a recommended practice guide. This work was assisted by similar efforts that had taken place in the United
Kingdom under the auspices of the Oxford Text Archive the previous year.
The following document represents a draft of those recommended practices. It has been submitted to various constituencies for
comment.</p>

===Working Assumptions===
<p>A TEI header can serve many publics. Headers can be created in a text center and reflect the center's standards, or they can
serve as the basis for other types of metadata system records produced by other agencies. Headers can function in detached
form as records in a catalog, as a title page inherent to the document, or as a source for index displays.</p>

<p>In addition, a header may describe a collection of documents, a single item, or a portion of an item. Variances in TEI header
content can result from making different choices of what is being described.</p>

<p>A TEI header may not have a one to one correspondence with a MARC record. One TEI header may have multiple MARC analytic records,
or one MARC record may be used to describe a collection of TEI documents with individual headers.</p>

<p>A TEI header serves several purposes. It may contain an historical background on how the file has been treated. It can extend the
information of a classic catalog record. The Text Center and/or cataloging agency can act as the gatekeeper for creators by
providing standards for content.</p>

===Cataloging a TEI Document===

<p>Does the TEI header act as the electronic title page or as a catalog record? Is it integral to the document it describes or
independent? Depending on the community being served, the TEI elements will reflect the interest of that community. Nonetheless,
it is possible to describe a set of "best practices" that will produce compatible content while accommodating this variety of
purposes. Compatibility of content encourages a more understandable set of results when information about assorted items is
displayed as a set of search results, a contents list, or an index, and it allows for more reasonable conversion of content
information from TEI elements to elements of other metadata sets when this action seems advisable.</p>

<p>It is a traditional practice of librarianship to agree upon where in a document and in what order of preference one should look
to identify the title, author, etc., of that document. This permits a certain consistency in terminology and allows for a certain
amount of authentication of content. We recommend the following preferences to those who create headers and to those who attempt
to use headers to create traditional catalog records that are compliant with AACR2 and ISBD(ER) rules.</p>

<p>As a member of the academic community, the header creator/editor has a responsibility to verify, whenever humanly possible, the
intellectual source for an electronic document that presents itself without any information regarding its source or authorship.</p>

====Chief Sources of Information for Several Types of Electronic Resources Are:====
<ul> <li>1. For an electronic document with a digitized title page (without a header), prefer
<ul>
<li>a) Chief source of information = information coded as title page</li>
<li>b) Use added information from an originating paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>2. Electronic document with header (without a title page)
<ul>
<li>a) Chief source of information = supplied and verified header <ref name="verify">Verified means that the cataloger/editor has established for him/herself that the information represented as title information is an accurate representation of content.</ref></li>

<li>b) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>

<li>3. Electronic document with header and title page
<ul>
<li>a) Chief source of information = supplied header (if verified)<ref name="verify"/></li>
<li>b) If header is not verified, use title page as chief source</li>
<li>c) Use information from paper document if absolutely certain it is the source</li>
</ul>

</li>
<li>4. If neither header nor title page is present and there is no evidence of a source document, the header creator
<ul>
<li>a) May assign a title and author if appropriate</li>
<li>b) Enclose the information in brackets, using the standard English language convention for editorial interjections</li>
</ul>
</li>
<li>5. If neither header nor title page is present but the header creator has satisfactory evidence of an originating source, that
document should be used as the chief source of information for the title and author of the header. If the source cannot be fully
verified as to edition, authorship, etc., this fact should be clearly indicated in a note in the <fileDesc>.
</li>

</ul>

===Element Recommendations for the <teiHeader>===

<table border="1" width="80%">
<tr>
<td colspan="1"><teiHeader type="____"></td>
<td colspan="1">
Standards which apply to the header, e.g., <teiHeader type="ISBD(ER)">, <teiHeader
type="AACR2">
</td>
</tr>
</table>

===<fileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<title type="____"></td>
<td colspan="1">
Only uniform title and main title for the TEI document, not the source document, should be entered here, e.g., <title type="uniform"> or <title type="main">. See <sourceDesc> for other title forms for documents where a user might seek the documents under titles other than those assigned. Where a title is supplied, the title should be enclosed in square brackets using standard English-language conventions for editorial insertion.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
Author of original source (electronic or print) should be entered into the <author> element before the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.
</td>
</tr>

<tr>
<td colspan="1">
<editor></td>
<td colspan="1">
Editor of original source (electronic or print) should be entered into the <editor> element <b>before</b> the <respStmt>. Whenever possible, establish or use the form of the name from a national name authority file.</td>

</tr>

<tr>
<td colspan="1">
<respStmt></td>
<td colspan="1">
The editor (also compiler, illustrator) of the TEI document, not the source document, should be entered here. Whenever possible, establish or use the form of the name from a national name authority file.</td>
</tr>

<tr>
<td colspan="1">
<editionStmt></td>

<td colspan="1">
This element should be used sparingly as there are currently no standards as to when versions become editions. Users should refer to the TEI guidelines.</td>
</tr>

<tr>
<td colspan="1">

<extent></td>
<td colspan="1">
Use the standard text "ca.**** kilobytes".</td>
</tr>

<tr>
<td colspan="1">

<publicationStmt></td>
<td colspan="1">
Caution: This statement describes the electronic file.</td>
</tr>

<tr>
<td colspan="1">
<publisher></td>
<td colspan="1">
The publisher is whoever has collected the electronic text and has made decisions concerning it.</td>
</tr>

<tr>

<td colspan="1">

<distributor></td>
<td colspan="1">
The distributor is whoever makes the electronic text available.</td>
</tr>

<tr>
<td colspan="1">
<idno></td>
<td colspan="1">
Any unique identification number determined by the publisher.</td>

</tr>

<tr>
<td colspan="1">
<availability></td>
<td colspan="1">
Use specialized elements when anticipating sharing of the header or free text if only local usage is expected. Caution: Know your audience.</td>
</tr>

<tr>
<td colspan="1">
<date></td>
<td colspan="1">
Refers to the date of the publication of the electronic document. <b>For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.</b></td>
</tr>

<tr>
<td colspan="1">
<seriesStmt></td>

<td colspan="1">
Whenever possible, establish the national authority file authorized form for the electronic locally created series.
</td>
</tr>

<tr>
<td colspan="1">
<notesStmt></td>

<td colspan="1">
Optional, depending on display decisions. Should be used for indicating questionable attributions for title, author, etc.</td>

</tr>

<tr>
<td colspan="1">
<sourceDesc></td>
<td colspan="1">
In order to effectively represent the source(s) when many documents are represented by the TEI header, we see the need for structured elements that minimally allow us to identify parent-child and component relationships. In the absence of these structures, we suggest that multiple source descriptions be employed with relationships described in free text. Relationships also could be useful in other portions of the TEI header. Cataloger may need to do research to establish the original source.</td>
</tr>

<tr>

<td colspan="1">
<bibl> or
<biblStruct> or
<biblFull></td>
<td colspan="1">
Prefer <biblFull> to allow searching on parts of the description. </td>

</tr>

<tr>
<td colspan="1">
<title></td>
<td colspan="1">
It is possible to have multiple <title> fields in <biblFull>. Alternative titles (cover, running, spine titles) should be entered in separate <title> fields in the <biblFull> field in the <sourceDesc> where they are searchable.</td>

</tr>

<tr>
<td colspan="1">
<author></td>
<td colspan="1">
If the name of the author(s) in the originating source differs from the established form, include here the form from the source tagged <author type="alternate">.</td>
</tr>

<tr>
<td colspan="1">

<editionStmt></td>
<td colspan="1">
Enter edition statement as found on the original source.</td>
</tr>

<tr>
<td colspan="1">
<extent></td>

<td colspan="1">
Enter physical description for the original source.</td>
</tr>

<tr>
<td colspan="1">
<publicationStmt> <publisher></td>
<td colspan="1">
Don't repeat field. Enter multiple publishers divided by semicolons.</td></tr>

<tr>
<td colspan="1">
<pubPlace></td>
<td colspan="1">

Don't repeat field. Enter multiple publishers divided by semicolons.</td>
</tr>

<tr>
<td colspan="1">
<date></td>

<td colspan="1">
Imprint date for the original source. '''For most purposes, the year date (yyyy) will be adequate. If greater precision is required, enter dates as yyyymmdd.'''</td>
</tr>

<tr>

<td colspan="1">
<idno></td>
<td colspan="1">
In this location, <idno> refers to identification numbers for the source document. They can be used to indicate the source's location in an individual institution's collection. If a formal standard location system is being used, indicate the nature of the system, e.g., <idno type="LC call number">.</td>

</tr>

<tr>
<td colspan="1">
<seriesStmt></td>

<td colspan="1">
Establish via national authority file the series statement of original document.</td>
</tr>

<tr>
<td colspan="1">
<notes></td>

<td colspan="1">
Caution: Notes made here should refer to the original source.</td>
</tr>
</table>

===<encodingDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<projectDesc></td>
<td colspan="1">Enter a description of the purpose for which the electronic file was encoded.</td>
</tr>

<tr>
<td colspan="1">
<editorialDecl></td>
<td colspan="1">
Enter general and specific statements about how the electronic file has been treated. Record here editorial decisions made
during encoding.</td>

</tr>

<tr>
<td colspan="1">
<refsDecl></td>
<td colspan="1">
<refsDecl> seems a possibility for administrative metadata, e.g., pagination and page sequencing.</td>
</tr>

<tr>

<td colspan="1">

<classDecl> <taxonomy id="____"></td>
<td colspan="1">
If used, identify the appropriate taxonomy definitions or descriptive sources in the <taxonomy> element followed by id, e.g.,
<taxonomy id="LCSH">, <taxonomy id="AAT">.</td>
</tr>
</table>

===<profileDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<creation>
     <date></td>
<td colspan="1">
Use the date as it comes from the creator. '''For most purposes, the year date (yyyy) will be adequate. If greater detail is required, enter dates as yyymmdd.'''</td>
</tr>

<tr>
<td colspan="1">
<langUsage></td>
<td colspan="1">
Language usage is specified by document creators. Use standard language names.</td>
</tr>

<tr>
<td colspan="1">

<language id="____"></td>
<td colspan="1">
Use the ISO 639-2 standard (which is the same as the MARC language codes).</td>

</tr>

<tr>
<td colspan="1">
<textClass></td>
<td colspan="1">
True classification numbers as opposed to call numbers can be entered here.</td>

</tr>

<tr>
<td colspan="1">
<keywords><br />

<term>
</td>
<td colspan="1">
Use for uncontrolled terms.</td>
</tr>

<tr>
<td colspan="1">
<keywords scheme="____"><br />
<term>
</td>
<td colspan="1">
Use for controlled vocabulary as specified in <encodingDesc> taxonomy id. Example: scheme="LCSH"</td>

</tr>
</table>

===<revisionDesc>===
<table border="1" width="80%">

<tr>
<td colspan="1">
<change>
<resp>
<item></td>
<td colspan="1">
Use the specific codes to note revisions rather than free text description. Include the entire date
(e.g., 19991101).</td>

</tr>
</table>

===Minimal TEI Header Recommendation===
<blockquote>
<div class="indent"><teiHeader></div>
<div class="lindent"><fileDesc></div>

<div class="lindent2"><titleStmt></div>
<div class="lindent3"><title></title></div>
<div class="lindent3"><author></author></div>
<div class="lindent2"></titleStmt>

</div>
<div class="lindent2"><publicationStmt>
</div>
<div class="lindent3"><publisher></publisher>

</div>
<div class="lindent3"><pubPlace></pubPlace>
</div>
<div class="lindent3"><idno></idno>
</div>
<div class="lindent3"><availability><p></p></availability>
</div>
<div class="lindent3"><date></date>

</div>
<div class="lindent2"></publicationStmt>

</div>
<div class="lindent2"><sourceDesc>
</div>
<div class="lindent3"><biblFull>
</div>
<div class="lindent4"><titleStmt>
</div>
<div class="lindent5"><title></title>

</div>
<div class="lindent5"><author></author>
</div>
<div class="lindent4"></titleStmt>
</div>
<div class="lindent4"><publicationStmt>
</div>
<div class="lindent5"><publisher></publisher>
</div>
<div class="lindent5"><pubPlace></pubPlace>

</div>
<div class="lindent5"><date></date>
</div>
<div class="lindent4"></publicationStmt>
</div>
<div class="lindent3"></biblFull>
</div>
<div class="lindent2"></sourceDesc>
</div>
<div class="lindent"></fileDesc>
</div>

<div class="indent"></teiHeader>
</div>
</blockquote>

Repeat the <biblFull> field, as appropriate, if there is more than one source for the electronic item. [http://www.diglib.org/standards/teiheaders.html See some examples in context …]

===Recommended Additions to the teixlite DTD===
<ul>
<li>Add elements under <name> to allow for the variable ordering and alphabetization of names:
<forename>, <surname>, <birthdate>, <deathdate>, <title>, etc.</li>

<li>In order to effectively represent the source(s) when many documents are
represented by the TEI header, we see the need for structured elements that, minimally,
allow us to identify parent-child and component relationships.</li>
</ul>

===Acknowledgments and Bibliography===
<ul>
<li>
This guide was prepared by Judy Ahronheim, Thomas Champagne, Lynn Marko, Kelly Webster, and Chris Wilcox of the University of
Michigan Library and Jackie Shieh of the University of Virginia Library in October 1998. The source documents were the cataloging
guides prepared by those two institutions ([http://www.lib.virginia.edu/cataloging/manual/chapters/chapxiib.html Virginia] and [http://www.lib.umich.edu/ts/sections/electronicresourcesdev.html Michigan]). In addition,
documentation from the Oxford Text Archive, Arts and Humanities Data Service of the United Kingdom also was made available to assist
in this effort.

</li>
<li>
For a description of TEI header elements and correstponding USMARC fields, see Appendix A at
[http://etext.lib.virginia.edu/tei/tei-usmarc.html http://etext.lib.virginia.edu/tei/tei-usmarc.html].
</li>
</ul>

==Encoding Levels==
===LEVEL 1: Fully Automated Conversion and Encoding===

'''Purpose''': To create electronic text with the primary purpose of keyword searching and linking to page images. The primary advantage in using the teixlite DTD at this level is that a TEI header is attached to the text file.

<p>
'''Rationale''': The text is subordinate to the page image, and is not intended to
stand alone as an electronic text (without page images).</p>

<p>Texts at Level 1 can be created and encoded by fully automated means, using uncorrected OCR of page
images ("dirty OCR"), exporting from existing electronic text files, or actually not including any text
at all. Only those elements that are necessary to divide the text from the header and facilitate linking to
page images are used. Encoding is performed automatically based on artifacts of the OCR or other
document creation process (page breaks, for example) and metadata collected during the imaging or
preparation process. This encoding is both minimal and reliable, and does not typically require
extensive review of each page of each text.</p>

<p>Level 1 texts are not intended to be adequate for textual analysis; they are more likely to be suited
to the goals of a preservation unit or mass digitization initiative. Though their encoding is minimal,
Level 1 texts are fully valid XML texts. In addition to taking advantage of the TEI header, using the
teixlite DTD--with the consistency suggested by these guidelines--allows Level 1 texts to be compatible
with more richly encoded teixlite texts (that also follow these guidelines) for
searching, for example. Further encoding based on document structures or content analysis can be added
to a Level 1 text at any time.</p>

<p>
'''Level 1 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>a large volume of material is to be made available online quickly</li>
<li>a digital image of each page is desired</li>
<li>no manual intervention will be performed in the text creation process</li>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>sophisticated search and display capabilities based on the structure of the text are not necessary</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<table border="1" width="80%">
<tr>
<td colspan="1"><div1></td>
<td colspan="1">If no type= attribute is specified, a type= value of
"section" should be presumed.</td>
</tr>

<tr>
<td colspan="1"><p></td>
<td colspan="1">At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using <p> in order that the document be open to being extended to other encoding levels).</td>
</tr>
<tr>

<td colspan="1"><pb></td>
<td colspan="1">Required in Level 1. Page images can be linked to the text by specifying a jpeg or other image file as the value of the facs= attribute. Page numbers can be supplied with the n= attribute to record the number that is on the page. The Task Force sees the use of METS here as having a tremendous advantage. METS/TEI page turning documentation will be included in the near future.</td>
</tr>
</table>

====Basic Structural Example:====
<pre>
<TEI.2 id="someid">
<teiHeader>
[Source and processing information goes here]
</teiHeader>
<text>
<body>
<div1>
<p>
<pb id="p00000001" n="1"/>
[main body of the unmarked up plain text begins here]
<pb id="p00000002" n="2"/>
[more plain text goes here with appropriate page breaks interspersed] ...
<pb id="p00000145" n="145"/>
[more plain text]
<pb id="p00000146" n="146"/>
[text ends here]
</p>
</div1>
</body>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level1example.html See an example in context…]

===LEVEL 2: Minimal Encoding===
'''Purpose''': To create electronic text for full-text searching, linking to page images, and identifying simple structural hierarchy to improve navigation.

'''Rationale''': The text is subordinate to the page image, though navigational markers (textual divisions, headings) are captured. The text could stand alone as electronic text (without page images) if the accuracy of its contents is suitable to its intended use and it is not necessary to display low-level typographic or structural information. Level 2 requires a set of elements more granular than those of Level 1, including bibliographic or structural information below the monographic or volume level.

Though texts at Level 2 can be created and encoded by automated means, based on the typographic elements in the electronic file (for example, bold centered text at the top of the page surrounded by whitespace indicates a new chapter heading, and thus a new division), it is not likely to be absolutely reliable across a large body of material. Level 2 encoding requires some human intervention to identify each textual division and heading. Level 2 texts do not require any special knowledge or manual intervention below the section level.

Level 2 texts are not intended to be displayed separately from their page images. Level 2 encoding of sections and headings provides greater navigational possibilities than Level 1 encoding, and enables searching to be restricted within particular textual divisions (for example, searching for two phrases within the same chapter).

'''Level 2 is most suitable for projects with the following characteristics''':

* a large volume of material is to be made available online quickly
* a digital image of each page is desired
* the material is of interest to a large community of users who wish to read texts that allow keyword searching
* rudimentary search and display capabilities based on the large structures of the text are desired
* each text will be checked to ensure that divisions and headers are properly identified
* extensibility is desired; that is, one desires to keep open the option for a higher level of encoding to be added at a later date

All elements specified in Level 1 plus the following:

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>
<td colspan="1">Optional</td>
</tr>
<tr>
<td colspan="1"><div1></td>
<td colspan="1">type="section" is the default attribute value. It is recommended that the n= attribute be
included to record the sequence of divisions.</td>
</tr>
<tr>
<td colspan="1"><head></td>
<td colspan="1">Required if present</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">One "container" element per div is required.</td>
</tr>
</table>

====Basic Structural Example:====

<pre>
<TEI.2 id="someid">
<teiHeader> [Source and processing information goes here] </teiHeader>
<text id="someotherid">
<front> [titlepage information, table of contents, prefaces, etc.] </front>
<body>
<div1 type="chapter" n="1">
<head>Chapter 1</head>
<p>[text of Chapter 1 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="2">
<head>Chapter 2</head>
<p>[text of Chapter 2 goes here interspersed with <pb> elements pointing to page
images]</p>
</div1>
<div1 type="chapter" n="3">
<head>Chapter 3</head> [text of Chapter 3 goes here interspersed with <pb> elements
pointing to page images] </div1>
<div1 type="chapter" n="4">
<head>Chapter 4</head> [text of Chapter 4 goes here interspersed with <pb> elements
pointing to page images] </div1>
</body>
<back> [optional text of backmatter, appendices, etc.] </back>
</text>
</TEI.2>
</pre>

[http://www.diglib.org/standards/level2example.html See an example in context…]

===LEVEL 3: Simple Analysis===

<p>
'''Purpose''': To create text that can stand alone as electronic text and identifies
hierarchy and typography without content analysis being of primary importance.</p>

<p>
'''Rationale''': Level 3 texts can be created from scratch or by the relatively easy
conversion of existing HTML or word-processing documents. Encoding offers the advantage of the TEI
header, interoperability with other TEI collections, and extensibility to higher levels of encoding.
Level 3 generally requires some human editing, but the features to be encoded are determined by the
appearance of the text and not specialized content analysis.</p>

<p>Level 3 texts identify front and back matter, and all paragraph breaks. The finer granularity of
encoding these features, as well as figures, notes, and all changes of typography, allows a range of
options for display, delivery, and searching. For example, one has the option of identifying and,
therefore, specifying the display charactersitics of different typographic styles, and regularizing the
display and placement of note text.</p>

<p>Level 3 texts can stand alone as text without page images and, therefore, can be uploaded, downloaded
and delivered quickly, and require less storage space than digital collections with page images.
However, the simple level of structural anaylsis and absence of specialized content analysis reflected
in Level 3 encoding may make it desirable for some, depending on project priorities, to include page
images in order to provide users with a fuller set of resources.</p>

<p>
'''Level 3 is most suitable for projects with the following characteristics:'''
</p>

<ul>
<li>the material is of interest to a large community of users who wish to read texts that allow
keyword searching</li>
<li>some sophistication of display, delivery, and searching based on structure of the text is desired</li>
<li>each text will be checked to ensure that encoding decisions have been made appropriately</li>
<li>the users of the texts may have limited storage or display capabilities</li>
<li>the creator of the texts has limited or no ability to provide content expertise to analyze, tag,
or review texts</li>

<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added at a later date</li>
</ul>

<p>All elements specified in Levels 1 and 2, plus the following:</p>

<table border="1" width="80%">
<tr>
<td colspan="1"><front>, <back></td>

<td colspan="1">Required if present.</td>
</tr>
<tr>
<td colspan="1"><p></td>
<td colspan="1">Required for paragraph breaks in prose; may be used for stanzas using <lb> for
line breaks in verse.</td>
</tr>

<tr>
<td colspan="1"><list> and <item></td>
<td colspan="1">May be used in this level to indicate ordered and unordered list structures.</td>
</tr>
<tr>
<td colspan="1"><table>, <row>, and <cell></td>

<td colspan="1">May be used to indicate table structures.</td>
</tr>
<tr>
<td colspan="1"><figure></td>
<td colspan="1">Required to indicate figures other than page images.</td>
</tr>
<tr>

<td colspan="1"><hi></td>
<td colspan="1">Required to indicate changes in typeface; rend attribute is optional.</td>
</tr>
<tr>
<td colspan="1"><note></td>
<td colspan="1">All notes must be encoded. It is also recommended that notes that extend beyond one page be combined into one <note> element. Marginal notes, without reference, should occur at the beginning of the paragraph to which they refer, with the value of the place attribute as "margin".</td>

</tr>
<tr>
<td colspan="1"><lb></td>
<td colspan="1">May be used to force line breaks.</td>
</tr>
</table>

<p>NOTE ON <note>:</p>

<p>It may be desirable to move footnotes from their original location in the text. If left at the bottom
of a page, a note may become included in another paragraph or section of the encoded text, and thus
separated from its reference. There are options for placement of footnotes if they are moved:</p>

<ul>
<li>Inline. The note is inserted at the point of reference. An n attribute records the value of the
note reference if there is one.</li>
<li>End-of-Division. Notes moved to the end of the division</li>
</ul>

<p>

'''Basic Structural Example forthcoming ...'''
</p>

===LEVEL 4: Basic Content Analysis===
<p>'''Purpose''': To create text that can stand alone as electronic text, identifies
hierarchy and typography, specifies function of textual and structural elements, and describes the
nature of the content and not merely its appearance. This level is not meant to encode or identify all
structural, semantic or bibliographic features of the text.</p>

<p>
'''Rationale''': Greater description of function and content allows for:</p>

<ul>
<li>flexibility of display and delivery</li>
<li>sophisticated searching within specified textual and structural elements</li>
<li>combining the broadest range of uses and audiences</li>

</ul>

<p>Texts encoded at Level 4 are able to stand alone as part of a library collection, and do not require
page images in order for them to be read by students, scholars and general readers. This level of TEI
encoding allows them to be displayed or printed in a variety of ways suitable for classroom or scholarly
use.</p>

<p>Level 4 texts contain elements and attributes that describe content. For example, lines of verse are
tagged with <l>; the <p> element is reserved for true paragraphs. Features of
the text that may contribute to meaning, such as indentation of verse lines and typographic change, are
preserved. These are textual features that are not encoded at lower levels and that allow the text to be
used and understood fully independent of images.</p>

<p>The ability to stand alone as text means that Level 4 texts are more nimble and robust for exercises
such as format repurposing and textual analysis.</p>

<p>Finally, functionally accurate encoding in Level 4 texts
allows them to be searched or displayed in sophisticated ways.
For example, a searcher could limit his or her search in a
dramatic text to stage directions or in a verse text to only
first lines. In a politicall tract published by subscription, a
search could be confined to names that appear in lists, thus
limiting a search to names of people who subscribed to a
particular volume. This ability to limit searches becomes more
significant as textbases become larger, and thus is of great
importance to the library community as it attempts to build into
the initial design and implementation of textbases the features
needed to enhance interoperability.</p>

<p>
'''Level 4 is most suitable for projects with the following characteristics''':
</p>

<ul>
<li>sophisticated search and retrieval capabilities are desired</li>

<li>the texts will be used for textual analysis</li>
<li>extensibility is desired; that is, one desires to keep open the option for a higher level of
encoding to be added by the scholarly community at a later date</li>
<li>the users of the texts may have limited storage or display capabilities</li>
</ul>

====General Level 4 Recommendations====
<ul>
<li>Typographically distinct text should be encoded as appropriate,
e.g. with <term>, <q>, <gloss>, <mentioned>, <soCalled>, <foreign>,
<title>, or <emph>. Any ambiguous emphasized text should be
encoded as <hi> (e.g. <hi rend="bold">).</li>
<li>It is recommended that the <sic> element be used to
indicate typographic errors, with corrections (if any) noted
as the value of the corr= attribute.</li>
<li><titlePage> should include the verso if present, divided by <pb
n="verso"/>. Tables of contents, errata, subscription lists, "other titles by the same author"
should be included in a separate numbered division, as a <list> with <item>s.
Frontispieces should be encoded as a <figure>, within a separate numbered division and
<p>.</li>
</ul>

[http://www.diglib.org/standards/level4genrec.html See some examples in context…]

====Level 4 Prose====
<ul>
<li>Letters that occur within the text body provide some challenges. It is recommended that quoted
letters that occur as part of a text (and not collections of letters themselves) be encoded within
<q><text><body><div1 type="letter">, with
<opener>, <dateline>, <salute>, <signed>,
<closer> included as appropriate.</li>

<li>Quotations that do not occur inline, but are set off typographically in some way, should be
encoded as <q>.</li>
<li>Notes are to be encoded as described in Level 3.</li>
<li><argument>, <opener>, <epigraph>,
<closer>, <trailer>, <add>, <del>,
<unclear> as appropriate.</li>

</ul>

[http://www.diglib.org/standards/level4prose.html See some examples in context…]

====Level 4 Drama====
<ul>
<li>Cast lists should be encoded as <list>s, with <item>s.</li>

<li>Speeches are encoded as <sp>, with speakers identified within
<speaker> elements; stage directions are encoded as <stage> and enclose
block level content describing scenery, etc.</li>
</ul>

[http://www.diglib.org/standards/level4drama.html See some examples in context…]

====Level 4 Oral History====
<ul>
<li>Speakers in interviews can be identified in the <teiHeader> in several ways.
<ul>
<li>In the <profileDesc>, in the <particDesc> in a <list>, with <name> inside of <item>s.</li>

<li>As a list of author <name>s within <fileDesc><titleStmt></li>
</ul>
</li>
<li>In either method, use an id= on the <name> element to uniquely identify the individual participant</li>

<li>Questions and answers from interviewees and interviewers are encoded as <sp>,
with speakers identified within <speaker> elements with a who= attribute the value of which
corresponds to the id= in the list of interview participants.</li>
</ul>
[http://www.diglib.org/standards/level4oh.html See some examples in context…]

====Level 4 Verse====
<ul>
<li>All verse, even poems without separate stanzas or verse paragraphs, should be contained within a
line group element <lg>. This will assist with automated processing and retrieval.</li>
<li>It is common to see informal divisions within poems, noted by a string of asterisks or periods.
These should be encoded as <milestone/>s with attribute values of unit="typography" and
n="()" indicating the character used and its occurrence, <milestone unit="typography"
n="******"/>.</li>
<li><l> It is recommended that indentation be recorded and that the rend attribute be
used to do this.</li>
</ul>
[http://www.diglib.org/standards/level4verse.html See some examples in context…]
====Level 4 Front and Back Matter====
<ul>
<li>It is recommended that all prefaces, tables of contents, afterwords, appendices, endnotes and
apparatus be encoded. For publisher's advertisements, indexes, and glossaries or other front or back
matter that isn't considered of primary importance to the text, there are three options:<ul>
<li>Fully transcribe and encode</li>
<li>Link to page images (may include an unencoded transcription)</li>
<li>Omit, noted in <editorialDesc></li>
</ul>
</li>
</ul>
[http://www.diglib.org/standards/level4fandb.html See some examples in context…]

===LEVEL 5: Scholarly Encoding Projects===

<p>Level 5 texts are those that require subject knowledge, and encode semantic, linguistic, prosodic or
other elements beyond a basic structural level.</p>

==General Guidelines for Attribute Usage==

<p>Some general advice on the use of particular attributes
follows.</p>
<ul>
<li><b>type=</b>: Constructing a list of acceptable attribute values
for type that could find wide agreement is impossible. Instead,
it is recommended that projects describe the type= attribute
values used in their texts in the project ODD file or other
documentation and that this list be made available to people
using the texts. See <i>ABC for Book Collectors</i> by John
Carter (7th edition, New Castle, DE:Oak Knoll Books, 1995) for
a list of standard names and definitions of bibliographic
features of printed books. For those elements where type is not
required, such as <head> and <title>, use the
attribute values for subtitles and additional titles, but not
main titles.<br /> Example: <div1 type="volume"></li>

<li><b>n=</b>: Sometimes an n= (number) attribute can be used by itself. For instance in the case of
pagebreaks:<br /> Example: <pb n="456"/></li>

<li><b>id=</b>: If you are in a situation that requires you to
uniquely identify an element that will be used to reference
another specific location in one or more texts, use an id=
attribute. The value of this attribute must be unique within a
document, and must be composed of alphanumeric characters,
dots, hyphens, and underscores, and must start with a
letter.<br /> Example: <note id="n5" n="5"></li>

<li><b>target=</b>: follows the same syntactic rules as the id=
attribute value. In fact, target= and id= are often used in
conjunction with one another as in the case of footnotes where
the <anchor id="n5" n="5"> is at a specific place in the
text and is referred to by the <note target="n5" n="5">
which contains the actual information of the footnote itself
elsewhere.</li>

<li><b>entity=</b>: The entity= attribute is simply the way a
figure indirectly points or refers to its the actual image
file<br /> Example:
<!ENTITY TwaFifrn SYSTEM "TwaFifrn.jpg" NDATA jpeg><br />
<br />
<figure entity="TwaFifrn"></li>

<li><b>rend=</b>: Difficulty using rend= attributes occurs when it is desirable to record
more than one rendition feature. With this in mind, it is recommended that projects employ the
following adaptation of "rendition ladders", a concept developed at the [http://www.wwp.brown.edu/ Brown University Women Writers Project]. This system allows for sets
of multiple renditional features to be included in one rend= value. Rendition ladders consist of categories of
renditional features with values of each of those features enclosed in parentheses.<br /> rend= should only be
used to override a default value. For instance, if all text encoded as <hi> is defined as being
rendered in italics, there is no reason to encode text as <hi rend="font(italics)"> Combining renditional features would result in a tag with attributes such as <l rend="font(italics)align(right)">
<ul>
<li>font <br />italics, bold, fsc (full and smallcaps), smallcap, underlined, gothic</li>
<li>align <br />right, left, center, block</li>
<li>indent <br />Values in parentheses should indicate the number of tabstops to be indented, e.g.,
<l rend="indent(1)"></li>
</ul>
</li>
<li><b>lang=</b>: Use ISO639-2 three-character language codes. Note that this recommendation is slightly different from that of the TEI P5 Guidelines, which recommends the BCP 47 language codes.</li>
</ul>
References: <references/>
[[Category:SIG:Libraries]]