TEIWiki - User contributions [en]

Agenda for June 2, 2010

2010-06-02T15:54:40Z

Pwillett:

[[Category:SIG:Libraries]]

* call 1-866-740-1260, access code: 6408974
* Agree on option E for tei-marc mapping approach for the [http://wiki.tei-c.org/index.php/Image:SIG-CFP-2010_Libraries-2.pdf#filelinks|SIG grant]
** Add support for all MARC fields mentioned in the Best Practices and for all three mapping variants (source, tei-from-source, and tei-from-digital). Option includes A & B as detailed in the grant.
* Review pending issues; assign tasks to group members (see http://wiki.tei-c.org/index.php/Talk:Best_Practices_for_TEI_in_Libraries)
** use of any P5 attr within <tt><text></tt> [[Talk:Best_Practices_for_TEI_in_Libraries#Pending_Review:_Use_of_any_P5_attributes|link]]
** publication statement structure [[Talk:Best_Practices_for_TEI_in_Libraries#Publication_Statement|link]]
** <tt><meeting></tt> [[Talk:Best_Practices_for_TEI_in_Libraries#meeting_element|link]] (that section says there’s e-mail from Kevin on 10-12, but I haven’t found it yet — Syd)
** <tt><appInfo</tt> [[Talk:Best_Practices_for_TEI_in_Libraries#appInfo_and_application|link]] (I think we may be able to just resolve this on the call — Syd)
** v. 3 hx [[Talk:Best_Practices_for_TEI_in_Libraries#Add_history_of_version_3_to_Appendix_A|link]]
** Tite == 3.5 ? [[Talk:Best_Practices_for_TEI_in_Libraries#Add_Tite_as_Level_3.5|link]]
** hyphenation [[Talk:Best_Practices_for_TEI_in_Libraries#Revise_section_on_hyphenation|link]] (I think we may be able to just resolve this on the call — Syd)
** odds issues [[Talk:Best_Practices_for_TEI_in_Libraries##Test_ODDs_and_schemas_derived_from_them|link]]
* Determine timeline

Talk:Best Practices for TEI in Libraries

2009-05-26T16:54:25Z

Pwillett: /* hyphenation */

== @type and @key on persName and orgName ==

In the best practices document, the author element is described as follows:

One or more author elements (one name per element) are used to encode the name for the personal author or corporate body responsible for the creation of the source document, even if this creator is not the main entry in the catalog record. Use <persName> or <orgName> when applicable. Whenever possible, establish or use the form of the name from a national name authority file.

Since the forms of names used in name authority files have a rigid form that doesn't look like a name in the TEI sense (strings like "Welles, Gideon, 1802-1878" offend the sensibilities of XML folks), during the Raleigh meeting we decided that name authority records given in the header should have a type attribute, similar to that used on <title>. So on fileDesc/titleStmt/author and fileDesc/sourceDesc/biblStruct/monogr/author the following values of @type would be allowed:

<pre>
marc100
marc110
</pre>

We would not allow marc111 or marc130 because these MARC fields, while used for main entries in cataloging, are not authors in the TEI sense. As explained in the description of the author element, this element should be used for personal authors or corporate bodies, not necessarily main entries.

We also decided to recommend use of @key, as in the "Level 4 Name Tagging" section, to reference authority file records. In "Level 4 Name Tagging", it says, "the key attribute points to the unique key in the database table or, as with the ref attribute, the key attribute can point to the xml:id value in the external file".

However, @key does not take an IDREF data type (as it was called in the old days), and once I tried to create examples, I realized we don't want to be in the business of adding a <taxonomy> for each authority record referenced elsewhere in the header. So I think what we want is this:

<pre>
<author><persName type="marc100" key="lccn-n78-95332">Shakespeare, William, 1564-1616</persName></author>
<author><orgName type="marc110" key="lccn-n50-63455">National Organization for Women</orgName></author>
<author>(unknown)</author>
</pre>

plus this elsewhere in the header:

<pre>
<taxonomy xml:id="lccn"><bibl>Library of Congress Control Number</bibl></taxonomy>
</pre>

Sound right?

== The_TEI_Header_and_Other_Metadata_Schemas ==

I added a paragraph to the section called [[Best_Practices_for_TEI_in_Libraries#The_TEI_Header_and_Other_Metadata_Schemas|The TEI Header and Other Metadata Schemas]] explaining why you can't link to outside metadata the way you'd like to. Does it sound right to everyone?

== rendition in header? ==

I changed removed mention of rendition ladders and replaced recommendation and examples with CSS. Should we add rendition element to the header? P5 talks about using this element to define local styles in terms of CSS, but we want to put CSS right inline. So is there any point in using the rendition element in the header?

== hyphenation ==

One of the comments we received on the Best Practices draft was a request to recommend on a specific way for handling end-of-line (and end-of-page) hyphenation within the <tt>body</tt>. We have not discussed this at all in the Best Practices!

We should have a new section under "General Recommendations" explaining to do end-of-line hyphens like in Tite (to ensure that texts can be converted to Level 3 automatically). See http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#e-o-l . End-of-page hyphens should be done the same way, with the <tt>pb</tt> tag intervening, e.g., <tt>obfus{U+00AD}<pb n="33" facs="00000037.tif"/>cation</tt>

P5 offers the <tt>hyphenation</tt> element in the header to document your method. We could give the following in the header element recommendations:

<tt><hyphenation eol="hard">End-of-line hyphenation silently removed where appropriate.</hyphenation></tt>

However, if we use this element, we would need to find another way to encode all of the prose description that is currently in p elements inside the editorialDecl. What should we do?

For the record, if I weren't trying to ensure this compatibility, I would have distinguished three cases:

* hyphenation that occurs at a line or page break but would never occur normally: use U+00AD
* hyphenation that occurs at a line or page break but might have occurred normally: use U+002D
* hyphenation that should always be present, such as "re-creation" (to create again, as opposed to leisure activity): use U+2011
[pw]: two points. 1) I'm not sure I see the distinction between the last two examples--why would you use two different characters? 2) for the first example, particularly for end-of-line in prose where line breaks aren't otherwise recorded, why include this at all? It would mess up searching at least in some systems (eg DLXS). I'm still for letting projects decide their own approach, and documenting it in the header (even if it means that we need to recast editorialDecl).

== profile/langUsage/language as empty element? ==

I added the language element to the header. The ident= attribute is required, but the element may be empty (despite no such examples given in P5). It seems entirely redundant to me to have content for this element. Should we prescribe having no content for it (and just a value for ident=)?

== idno in sourceDesc ==

I substantially rewrote the description of the idno element in sourceDesc. Does this sound right to everyone? In Raleigh people said they wanted examples of local identifiers, but I don't see where this adds anything useful. Thoughts?

== workflow descriptions and slightly revised rationales ==

I have created a "Workflow" section after the "Rationale" section for Levels 1-4, expanding on the brief description of workflows that we already had in place. I also revised some rationales, especially Level 3. Everything look okay?

== Level 3 and Tite ==

I've explained the relationship between the Best Practices and Tite vis-a-vis Level 3 and Level 4. As [http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#tei-in-lib-bpg Tite explains], there are a few elements missing from Level 3 which are included in Tite. Should we just include these in Level 3 so that elements in the <tt>body</tt> of each map exactly?

Talk:Best Practices for TEI in Libraries

2009-05-26T16:52:54Z

Pwillett:

== @type and @key on persName and orgName ==

In the best practices document, the author element is described as follows:

One or more author elements (one name per element) are used to encode the name for the personal author or corporate body responsible for the creation of the source document, even if this creator is not the main entry in the catalog record. Use <persName> or <orgName> when applicable. Whenever possible, establish or use the form of the name from a national name authority file.

Since the forms of names used in name authority files have a rigid form that doesn't look like a name in the TEI sense (strings like "Welles, Gideon, 1802-1878" offend the sensibilities of XML folks), during the Raleigh meeting we decided that name authority records given in the header should have a type attribute, similar to that used on <title>. So on fileDesc/titleStmt/author and fileDesc/sourceDesc/biblStruct/monogr/author the following values of @type would be allowed:

<pre>
marc100
marc110
</pre>

We would not allow marc111 or marc130 because these MARC fields, while used for main entries in cataloging, are not authors in the TEI sense. As explained in the description of the author element, this element should be used for personal authors or corporate bodies, not necessarily main entries.

We also decided to recommend use of @key, as in the "Level 4 Name Tagging" section, to reference authority file records. In "Level 4 Name Tagging", it says, "the key attribute points to the unique key in the database table or, as with the ref attribute, the key attribute can point to the xml:id value in the external file".

However, @key does not take an IDREF data type (as it was called in the old days), and once I tried to create examples, I realized we don't want to be in the business of adding a <taxonomy> for each authority record referenced elsewhere in the header. So I think what we want is this:

<pre>
<author><persName type="marc100" key="lccn-n78-95332">Shakespeare, William, 1564-1616</persName></author>
<author><orgName type="marc110" key="lccn-n50-63455">National Organization for Women</orgName></author>
<author>(unknown)</author>
</pre>

plus this elsewhere in the header:

<pre>
<taxonomy xml:id="lccn"><bibl>Library of Congress Control Number</bibl></taxonomy>
</pre>

Sound right?

== The_TEI_Header_and_Other_Metadata_Schemas ==

I added a paragraph to the section called [[Best_Practices_for_TEI_in_Libraries#The_TEI_Header_and_Other_Metadata_Schemas|The TEI Header and Other Metadata Schemas]] explaining why you can't link to outside metadata the way you'd like to. Does it sound right to everyone?

== rendition in header? ==

I changed removed mention of rendition ladders and replaced recommendation and examples with CSS. Should we add rendition element to the header? P5 talks about using this element to define local styles in terms of CSS, but we want to put CSS right inline. So is there any point in using the rendition element in the header?

== hyphenation ==

One of the comments we received on the Best Practices draft was a request to recommend on a specific way for handling end-of-line (and end-of-page) hyphenation within the <tt>body</tt>. We have not discussed this at all in the Best Practices!

We should have a new section under "General Recommendations" explaining to do end-of-line hyphens like in Tite (to ensure that texts can be converted to Level 3 automatically). See http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#e-o-l . End-of-page hyphens should be done the same way, with the <tt>pb</tt> tag intervening, e.g., <tt>obfus{U+00AD}<pb n="33" facs="00000037.tif"/>cation</tt>

P5 offers the <tt>hyphenation</tt> element in the header to document your method. We could give the following in the header element recommendations:

<tt><hyphenation eol="hard">End-of-line hyphenation silently removed where appropriate.</hyphenation></tt>

However, if we use this element, we would need to find another way to encode all of the prose description that is currently in p elements inside the editorialDecl. What should we do?

For the record, if I weren't trying to ensure this compatibility, I would have distinguished three cases:

* hyphenation that occurs at a line or page break but would never occur normally: use U+00AD
* hyphenation that occurs at a line or page break but might have occurred normally: use U+002D
* hyphenation that should always be present, such as "re-creation" (to create again, as opposed to leisure activity): use U+2011
[pw]: two points. 1) I'm not sure I see the distinction between the last two examples--why would you use two different characters? 2) for the first example, particularly for end-of-line in prose where line breaks aren't otherwise recorded, why include this at all? It would mess up searching at least in some systems (eg DLXS).
== profile/langUsage/language as empty element? ==

I added the language element to the header. The ident= attribute is required, but the element may be empty (despite no such examples given in P5). It seems entirely redundant to me to have content for this element. Should we prescribe having no content for it (and just a value for ident=)?

== idno in sourceDesc ==

I substantially rewrote the description of the idno element in sourceDesc. Does this sound right to everyone? In Raleigh people said they wanted examples of local identifiers, but I don't see where this adds anything useful. Thoughts?

== workflow descriptions and slightly revised rationales ==

I have created a "Workflow" section after the "Rationale" section for Levels 1-4, expanding on the brief description of workflows that we already had in place. I also revised some rationales, especially Level 3. Everything look okay?

== Level 3 and Tite ==

I've explained the relationship between the Best Practices and Tite vis-a-vis Level 3 and Level 4. As [http://www.tei-c.org/release/doc/tei-p5-exemplars/html/tei_tite.doc.html#tei-in-lib-bpg Tite explains], there are a few elements missing from Level 3 which are included in Tite. Should we just include these in Level 3 so that elements in the <tt>body</tt> of each map exactly?

Minutes for May 6, 2009

2009-05-08T17:01:34Z

Pwillett: New page: TEI in Libraries SIG meeting, DLF Forum, Raleigh NC May 6, 2009 Attendees: Glen Worthy, Kevin Hawkins, Chris Powell, Melanie Schlosser, Michelle Dalmau, Jenn Riley, Perry Willett, Natasha...

TEI in Libraries SIG meeting, DLF Forum, Raleigh NC
May 6, 2009

Attendees: Glen Worthy, Kevin Hawkins, Chris Powell, Melanie Schlosser, Michelle Dalmau, Jenn Riley, Perry Willett, Natasha Smith, Hugh Cayless, Syd Baumann, Matt Gibson

* Perry said that CDL could sponsor conference calls in the future. (We use ReadyTalk, which can also share computer screens.
* add Hugh to email distribution
* Kevin will go through and be sure that all feedback has been addressed in some way.
* No to "marc245": nothing to be gained; keep lowercase. (See additional email from Syd about this.)
* idno: needs more examples? get examples from EEBO, BIM
* type="translated"?
* optional: use ref/key in persName to point to external authority file using LCNAF#; 100 MARC field will contain dates.
**Recommended: use type=marc1XX as source
**later discussion: make recommendation with more granulated subfields
* use one resp/multiple names or multiple resps/one names or one resp/one name
* use xml:lang attribute on <text>; need example
* optional: use profileDesc to indicate predominate language, describing text as a whole.
* ISBD: typo
* deal with other metadata formats in the header in the future; not now
* level2: take out div1, div, ab
* level3/4: no comparison with tite is possible just yet. Kevin will provide some context. Analyze level 3 to see how closely it is to tite.
* fix typo by adding #. Natasha fixed her example. Ampersands to fix.
* level 5: remove examples; reference full tei guidelines and something about header
* general recommendations:
** references to specific tags will be taken care of through odds
** contributing examples: not our problem
** recommend hyphenation be documented in header, explain different cases
** workflow scenario: add more description of some scenarios,
* no recommendation for character encoding
* Michelle will provide a summary of IU's filenaming practice
* pb: just ignore this comment
* levels: add sentence about context: "higher levels indicate more analysis and markup"
* global attr guidelines xml:lang needs to remove sentence about subtag.
* numbered divs: no comment
* type attr: add a little more info, describing why this is necessary
* synopsis at beginning of levels
* Michelle will add discussion of @facsimile
* use css not rendition ladders.
* use @rendition which is documented in header <rendition>
* add sentence about interoperability
* assignments:
** people should volunteer to take on particular tasks
** clean out discussion
** generate P5 odds for each level (Syd)
** proofing
** submit final version for tei-c vetting
** finalize changes to wiki by May 22.
** next call May 26 1pm ET 10am PT
* Syd can't start working on ODDs until July 1, may take at least a month
* Aug 3 ODDs should be done
* unveil at members meeting

SIG:Libraries

2009-05-08T17:00:48Z

Pwillett:

Convenors: Michelle Dalmau and Kevin Hawkins

The goal of the TEI Special Interest Group on Libraries is to discuss topics regarding the use of TEI in libraries, including the creation of guidelines and best practices that encourage the consistent and predictable encoding of TEI documents. Greater consistency and predictability will facilitate the interchange of documents, interoperability of systems, and the creation of standard tools for libraries to use in the creation and publication of TEI documents.

It will do this by:
* Updating and improving the current TEI Text Encoding in Libraries: Guidelines for Best Practices, available at http://www.diglib.org/standards/tei.htm.
* Creation of standard XSL style sheets for use.
* Exploring the use of other metadata standards commonly in use in libraries, such as METS, MODS, EAD, MARC, in conjunction with TEI documents
* Guides to implementing TEI collections that follow the best practices guidelines, using open source digital library software such as Greenstone.
* Other items as they occur to us.

(from [http://www.tei-c.org/Activities/SIG/Libraries/index.xml TEI in Libraries SIG web page])

==Join the List==
* [https://listserv.indiana.edu/cgi-bin/wa-iub.exe?SUBED1=teilib-l&A=1 Join the TEILIB-L] list to participate in discussions, post questions or just to stay informed.

==Meetings==
* TEI in Libraries Joint Meeting with DLF and SIG, May 6, 2009
** [[Registration, May 6, 2009]]
** [[Agenda for May 6, 2009]]
** [[Minutes for May 6, 2009]]
* Best Practices Conference Call, April 14, 2009
** [[Agenda for April 14, 2009]]
** [[Minutes for April 14, 2009]]
* Best Practices Conference Call, March 24, 2009
** [[Agenda for March 24, 2009]]
** [[Minutes for March 24, 2009]]
* Best Practices Conference Call, March 10, 2009
** [[Agenda for March 10, 2009]]
** [[Minutes for March 10, 2009]]
* Header Conference Call, March 3, 2009
** [[Agenda for March 3, 2009]]
** [[Minutes from March 3, 2009]]
* Best Practices Conference Call, February 24, 2009
** [[Agenda for and Notes of February 24, 2009]]
* Header Conference Call, February 17, 2009
** [[Talk:TEI_in_Libraries:_Guidelines_for_Best_Practices#The_TEI_Header|Agenda for February 17, 2009]]
** [[Minutes from February 17, 2009]]
* Best Practices Conference Call, February 10, 2009
** [[Agenda for February 10, 2009]]
** [[Minutes from February 10, 2009]]
* Best Practices Conference Call, January 27, 2009
** [[Minutes from January 27, 2009]]
* Best Practices Conference Call, December 2, 2008
** [[Agenda for December 2, 2008]]
** [[Minutes from December 2, 2008]]
* TEI Members' Meeting, Libraries SIG, November 8, 2008
** [[Agenda for November 8, 2008]]
** [[Minutes from November 8, 2008]]
* Conference call of members of the April 2008 group
** [[Agenda for September 30, 2008]]
** [[Minutes from September 30, 2008]]
* TEI in Libraries Joint Meeting with DLF and SIG, April 28, 2008
** [[Registration]]
** [[Invitation and Agenda]]
** [[Minutes from April 28, 2008]]
* TEI Members' Meeting, Libraires SIG, November 3, 2007
** [[Agenda for November 3, 2007]]
** [[Minutes from November 3, 2007]]

==Working Groups==
* [[TEI in Libraries: Guidelines for Best Practices Working Group]]

==Conferences==
* [[DLF Spring 2009 Forum BoF Session]]
** [[DLF Spring 2009 Forum BoF Session Minues]]

==Documentation==
* [[TEI in Libraries: Guidelines for Best Practices]]
** [[BPG Feedback on Complete Draft]]
** [[BPG Revision 3 for Public Comment]]
** [[BPG Revision 3 Public Comment Feedback]]
* [[TEI Tite]] (Issues under investigation)
** [[Review of Tite Scheme]] (no longer active)

[[Category:SIG|Libraries]]
[[Category:SIG:Libraries|!]]

TEI in Libraries: Guidelines for Best Practices Working Group

2009-04-14T16:59:18Z

Pwillett:

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

===Working Group Charge===
In April 2008, a joint meeting between the Digital Library Federation (DLF) TEI Task Force and TEI in Libraries SIG was held as part of the DLF Spring Forum in Minneapolis. One of the main points of discussion was the necessary revision of the ''TEI in Libraries: Guidelines for Best Practices'' ([http://www.diglib.org/standards/tei.htm current released version], [[TEI_in_Libraries:_Guidelines_for_Best_Practices|development version]]) (GBP) to reflect general conformance and any changes brought about by the TEI P5 release.

The GBP were originally authored by members of the DLF TEI Task Force, but they will fall under the TEI in Libraries SIG purview moving forward. One of our many goals in revising the GBP is to have official bodies of the TEI-C review and approve them, and having them linked from the TEI-C web site for greater exposure.

To further the revision work, a working group has been established to address the various the main components of the GBP: TEI Header and levels 1-5.
The revision work entails:
* updating the narrative
* finding TEI P5 examples for each level (perhaps by migrating P4 examples)

If you are interested in participating, please contact [mailto:msg2d@virginia.edu Matt Gibson], [mailto:kevin.s.hawkins@ultraslavonic.info Kevin Hawkins] or [mailto:mdalmau@indiana.edu Michelle Dalmau] for additional information and to get you signed up!

===Working Group Members===
* Editors: ([mailto:kevin.s.hawkins@ultraslavonic.info Kevin Hawkins] and ([mailto:mdalmau@indiana.edu Michelle Dalmau])
* Consultant for all levels: [mailto:Syd_Bauman@brown.edu Syd Bauman]
* Level 1: Fully Automated Conversion and Encoding ([mailto:emcaulay@library.ucla.edu Lisa McAulay] and [mailto:arouner@wustl.edu Andrew Rouner])
* Level 2: Minimal Encoding ([mailto:emcaulay@library.ucla.edu Lisa McAulay] and [mailto:rlw54@case.edu Richard Wisneski])
* Level 3: Simple Analysis ([mailto:mdalmau@indiana.edu Michelle Dalmau])
* Level 4: Basic Content Analysis ([mailto:nsmith@email.unc.edu Natasha Smith]), [mailto:msg2d@virginia.edu Matt Gibson] and ([mailto:mdalmau@indiana.edu Michelle Dalmau])
* Level 5: Scholarly Encoding ([mailto:nsmith@email.unc.edu Natasha Smith]) and [mailto:msg2d@virginia.edu Matt Gibson]
* [http://www.tei-c.org/wiki/index.php/TEI_Header TEI Header] ([mailto:kevin.s.hawkins@ultraslavonic.info Kevin Hawkins] and [mailto:schlosser.40@osu.edu Melanie Schlosser])

* Planning group:
** Syd Bauman, Brown University
** Michelle Dalmau, Indiana University
** Matthew Gibson, University of Virginia
** Kevin Hawkins, University of Michigan
** Lisa McAulay, University of California, Los Angeles
** Chris Powell, University of Michigan
** Melanie Schlosser, Ohio State University
** Natasha Smith, University of North Carolina, Chapel Hill
** Perry Willett, California Digital Library
** Richard Wisneski, Case Western University
** Glen Worthey, Stanford University

===Conference Calls ===
1-866-519-2804 or 
1-719-234-7307 (Always Available) 
Participant Passcode: 245220 

* February 10: 1 pm EST
* February 24: 1 pm EST
* March 10: 1 pm EST
* March 24: 1 pm EST
* April 14: 1 pm EST
* April 28: 1 pm EST

===Working Documents===
* [[TEI in Libraries: Guidelines for Best Practices]] (Undergoing revision)

===Timeline===
* Conference calls for WG members to occur every 2nd and 4th Tuesday each Month (see above)
* April 7: Complete draft (all levels and introductory/background content complete; examples in place)
* April 7-14: Group proofreads; makes final edits
* April 14: Discuss pending issues; establish public commenting process
* April 14-20: Copyediting
* April 20: Generate HTML version
* April 20-May 6: Disseminate draft for public comment
* May 6: Convenors/editors will compile public comments ; Discuss at meeting
* TBD: Integrate public comments
* TBD: Generate TEI P5 version of BPG; Generate ODDs for each level
* TBD: Submit final version for TEI-C vetting

Registration, May 6, 2009

2009-04-09T15:37:03Z

Pwillett: /* TEI in Libraries Joint Meeting, Digital Library Federation Spring 2009 Forum */

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

== TEI in Libraries Joint Meeting, Digital Library Federation Spring 2009 Forum ==

[http://www.diglib.org/forums/spring2009/ DLF Spring 2009 Forum] 
Raleigh, North Carolina 
Monday, May 4th – Wednesday, May 6th
 
'''Meeting Details''' 
Date/Time: Wednesday, May 6th, 1:00-4:30 pm 
Room: TBD 

Lunch will be provided immediately following the end of the DLF Forum at 12:15 pm.
----

The TEI in Libraries Joint Meeting with members of the TEI DLF Task Force and the TEI in Libraries Special Interest Group is sponsored by the Digital Library Federation. Participation in the meeting is open to members of the [http://wiki.tei-c.org/index.php/TEI_in_Libraries:_Guidelines_for_Best_Practices_Working_Group Guidelines for Best Practices Working Group], and additional people interested in participating in the GBP Working Group. Attendance must be capped at 10-12 participants. Non-DLF members participating in the meeting are welcome to attend the Spring 2009 Forum.

----

 

{| border="1" cellpadding="2"
!width="25%"|Name
!width="25%"|Affiliation
!width="15%"|Email
!width="10%"|DLF Member
!width="10%"|Attending DLF
|-
|Michelle Dalmau || Indiana University || mdalmau@indiana.edu || Yes || Yes
|-
|Matthew Gibson || University of Virginia || msg2d@virginia.edu || Yes || Maybe
|-
|Kevin Hawkins || University of Michigan || kevin.s.hawkins#ultraslavonic.info || Yes || Yes
|-
|Glen Worthey || Stanford University Libraries || gworthey@stanford.edu || Yes || Yes
|-
|Perry Willett || CDL || Perry.Willett@ucop.edu || Yes || Yes
|-
|Lisa McAulay || UCLA || emcaulay@library.ucla.edu || Yes || ?
|-
|Andrew Rouner || Washington University || arouner@wustl.edu || Yes || ?
|-
|Natasha Smith ||University of North Carolina at Chapel Hill || nsmith@email.unc.edu || No || Yes
|-
|Chris Powell ||University of Michigan|| sooty@umich.edu || Yes || Yes
|-
|Melanie Schlosser ||The Ohio State University|| schlosser.40@osu.edu || No || Yes
|-
|Syd Bauman ||Brown University|| Syd_Bauman@brown.edu || No || Yes
|-
|Rich Wisneski ||Case Western|| rlw54@case.edu || No || No
|-
|David Seaman ||Dartmouth|| David.Seaman@dartmouth.edu || Yes || ?
|-
|Jenn Riley ||Indiana University|| jenlrile@indiana.edu || Yes || Yes
|}

Registration, May 6, 2009

2009-04-09T00:03:02Z

Pwillett: /* TEI in Libraries Joint Meeting, Digital Library Federation Spring 2009 Forum */

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

== TEI in Libraries Joint Meeting, Digital Library Federation Spring 2009 Forum ==

[http://www.diglib.org/forums/spring2009/ DLF Spring 2009 Forum] 
Raleigh, North Carolina 
Monday, May 4th – Wednesday, May 6th
 
'''Meeting Details''' 
Date/Time: Wednesday, May 6th, 1:00-4:30 pm 
Room: TBD 

Lunch will be provided immediately following the end of the DLF Forum at 12:15 pm.
----

The TEI in Libraries Joint Meeting with members of the TEI DLF Task Force and the TEI in Libraries Special Interest Group is sponsored by the Digital Library Federation. Participation in the meeting is open to members of the [http://wiki.tei-c.org/index.php/TEI_in_Libraries:_Guidelines_for_Best_Practices_Working_Group Guidelines for Best Practices Working Group], and additional people interested in participating in the GBP Working Group. Attendance must be capped at 10-12 participants. Non-DLF members participating in the meeting are welcome to attend the Spring 2009 Forum.

----

 

{| border="1" cellpadding="2"
!width="25%"|Name
!width="25%"|Affiliation
!width="15%"|Email
!width="10%"|DLF Member
!width="10%"|Attending DLF
|-
|Michelle Dalmau || Indiana University || mdalmau@indiana.edu || Yes || Yes
|-
|Matthew Gibson || University of Virginia || msg2d@virginia.edu || Yes || Maybe
|-
|Kevin Hawkins || University of Michigan || kevin.s.hawkins#ultraslavonic.info || Yes || Yes
|-
|Glen Worthey || Stanford University Libraries || gworthey@stanford.edu || Yes || Yes
|-
|Perry Willett || CDL || Perry.Willett@ucop.edu || Yes || Yes Woo woo!
|-
|Lisa McAulay || UCLA || emcaulay@library.ucla.edu || Yes || ?
|-
|Andrew Rouner || Washington University || arouner@wustl.edu || Yes || ?
|-
|Natasha Smith ||University of North Carolina at Chapel Hill || nsmith@email.unc.edu || No || Yes
|-
|Chris Powell ||University of Michigan|| sooty@umich.edu || Yes || Yes
|-
|Melanie Schlosser ||The Ohio State University|| schlosser.40@osu.edu || No || Yes
|-
|Syd Bauman ||Brown University|| Syd_Bauman@brown.edu || No || Yes
|-
|Rich Wisneski ||Case Western|| rlw54@case.edu || No || No
|-
|David Seaman ||Dartmouth|| David.Seaman@dartmouth.edu || Yes || ?
|-
|Jenn Riley ||Indiana University|| jenlrile@indiana.edu || Yes || Yes
|}

Best Practices for TEI in Libraries

2009-04-07T15:57:26Z

Pwillett: /* Acknowledgements */

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

==Introduction==

These recommendations are for libraries using the [http://www.tei-c.org/ Text Encoding Initiative]’s [http://www.tei-c.org/Guidelines/P5/ Guidelines for Text Encoding and Interchange (P5)]. They are intended for use in large, library-based digitization projects, but may be useful in other scenarios as well. Consult the full TEI Guidelines for guidance beyond what is described below.

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.

Task Force W/C though historically correct may lose context in this new revisions. Consider something more generic like "Working Group" or past tense: "the Task Force attempted to make these ..." --Michelle

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.

==General Recommendations==

An encoding project should strive for internal consistency and for use of standards so that the data can be modified or enhanced in the future with ease. In cases where local practice deviates from standards, there should at least be internal consistency in the local practice.

<ul>
<li>When reformatting to digital media using any level of encoding, the electronic text 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>A filename scheme that is internally consistent should be established for the project. If it is likely that the files will need to be used on more primitive devices (MS-DOS computers or unextended ISO 9660 CDs) it may be useful to limit names to 8 characters (limited to the 26 lower case letters of ASCII, digits, hyphens, and underscore), a dot, and an extension of 3 alphanumeric characters. </li>

<li>An encoding project should use only numbered divisions (i.e., <tt><div1></tt>, <tt><div2></tt>, etc.) or unnumbered divisions (i.e., <tt><div></tt>) but not both. This applies both within a TEI document (i.e., within <tt><front></tt>, <tt><body></tt>, <tt><back></tt>, even if nested within <tt><group></tt> or <tt><floatingText></tt>) and across TEI documents in any given collection. Keep in mind that numbering of divs starts over (at <tt><div1></tt>) within <tt><floatingText></tt>, so any software that expects to process nested numbered divisions within a document will need to account for this.</li>

<li>Whether numbered or unnumbered divisions are used, the <tt>@type</tt> attribute of the division element is not recommended at level 1, is optional at level 2, is recommended at level 3, and required at levels 4 and 5.</li>

<li>Page breaks should be encoded using the <tt><pb></tt> element,
which should demark the top of a page (i.e. the text of page
seven should immediately follow <tt><pb n="7"/></tt>), and should
always be contained within a div for ease of retrieval with indexing software. For example, a page break that
occurs between chapters 2 and 3 should be encoded near the top
of the <tt><div></tt> that holds chapter 3 (rather than near the bottom
of the <tt><div></tt> that holds chapter 2).
</li>
<li>Conisder moving page image referencing info here.</li>
</ul>

==Structure of a TEI Document==

A valid TEI XML document must contain the following elements:
<ul><li>a root <tt><TEI></tt> element, containing:<ul>
<li>a <tt><teiHeader></tt> element</li>
<li>a <tt><text></tt> element </li></ul></li></ul>

Within those two elements, there are additional requirements, which are discussed in these guidelines and in the complete TEI P5 Guidelines. The <tt><teiHeader></tt> element serves as a description of the document presented in the <tt><text></tt> element. The <tt><text></tt> element contains the transcription of the source document.

==The TEI Header==

===Reference===
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/HD.html Chapter 2, TEI Header, P5 Guidelines]

===The TEI Header===

The TEI Header is a metadata record that describes an electronic text encoded according to the TEI specification. The purpose of the TEI Header is to declare the bibliographic information related to the electronic document and if appropriate, the bibliographic data for original analog source document from which the electronic edition was created. The TEI Header often includes a description of the encoding decisions or practices used to create the electronic document. Since the advent of the TEI twenty years ago, many people have described the TEI Header as a title page for the electronic edition, and many librarians have compared it to traditional library catalog records (MARC).

As with any descriptive metadata, the metadata in the TEI Header can serve multiple audiences. In the local context, a TEI Header provides metadata about the TEI document, its source, and its provenance. The TEI Header may used for metadata exchange, to automatically create indexes (author lists, title lists) for a collection of TEI documents, and to aid in browsing heterogeneous TEI documents. TEI Headers may also be used as a basis for other metadata records (such as MARC or Dublin Core), though generation of other formats may require human intervention because they often are more granualar, or have different granularity, than TEI Headers.

===The TEI Header and MARC===

While a TEI header is often perceived as similar to or at least related to a MARC record, a TEI header does not typically have a one-to-one correspondence with a MARC record. One TEI header may be described by multiple MARC analytic records, or one MARC record may be used to describe a collection of TEI documents with individual headers. Furthermore, while a MARC record captures metadata about a bibliographic entity in a library's collection, a TEI header records information both about an encoded text and about the source document for that encoded text.

Each institution and even each project may have a different approach to the way electronic texts are created in TEI and then represented in a larger public catalog through MARC. At one institution, the same unit (e.g., a cataloging department) may be responsible for creating both TEI Headers and MARC records, while at other institutions the work may be distributed among different units. Within the library domain, metadata or cataloging experts are usually required for at least review and standardization of both the TEI Header and the MARC record.

===The TEI Header and Other Metadata Schemas===

Several other descriptive metadata schemas are prevalent within the library domain, including Dublin Core (DC), Dublin Core Qualified (DCQ), and the Metadata Object Description Schema (MODS). Each of these schemas contains elements that capture the same data as many of the elements in the TEI Header. As with MARC, a variety of automated or manual workflows can be implemented to crosswalk metadata from one standard to another and provide for increased sharing of metadata about electronic texts in larger contexts. In particular, DC and MODS are common schemas used by the Open Access Initiative (OAI) and may be particularly valuable for sharing metadata across institutions.

===Determining Data Values for the TEI Header===

Within the library domain, there are several authoritative publications on how to create bibliographic and descriptive metadata for objects. These are usually called “content standards;” two prominent examples are the <cite>Anglo-American Cataloging Rules Second Edition</cite> (AACR2) and the <cite>International Standard Bibliographic Description for Electronic Resources</cite> (ISBD(ER)). These standards are extensive and outline a set of rules that enforce consistency across a voluminous amount of metadata.

Perhaps the primary purpose of these content standards is to give rules for what sources of information may be used in transcribing or generating metadata about a bibliographic entity. Within an electronic context, the analog object may not be available, so the TEI Header creator will need access to digitized images or other verifiable information to create accurate metadata.

The following sources of information are recommended in creating the TEI Header:

<ol>
<li> For an electronic document with a digitized title page and title page verso:<ol style="list-style: lower-alpha;">
<li> Chief source of information is the information coded as title page.</li>
<li> Use added information from an originating paper document if absolutely certain it is the source.</li></ol></li>

<li>If there is no digitized title page but the header creator has satisfactory evidence of the source document, the header creator should refer to the source document for metadata creation. The lack of a title page may be for one of many reasons, among them: the original document is a manuscript item or the electronic edition is a portion of the original object (a poem or short story that was published in a collection or an article from a serial). In all cases, it is recommended that important bibliographic evidence, such as a digitized image of the title page and title page verso for a collection, be provided to the header creator, even if just a piece of the collection is used.</li>

<li>If no title page is present and there is no evidence of a source document, the header creator<ol style="list-style: lower-alpha;">
<li> May assign a title and author, if appropriate.</li>
<li> Enclose the information in brackets, using the standard English language convention for editorial interjections.</li></ol></li></ol>

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

<table border="1">
<tr>
<th colspan="6">Element</th>
<th>Description</th>
<th>Equivalent in MARC when cataloging the TEI document</th>
<th>Equivalent in MARC for the source document</th>
</tr>

<tr>
<td colspan="6"><teiHeader></td>
<td></td>
<td></td>
<td></td>
</tr>

<tr>
<td>└</td>
<td colspan="5"><fileDesc></td>
<td>The fileDesc contains metadata about the TEI document. One of its child elements, <tt>sourceDesc</tt>, describes the source document from which the TEI document was created.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>├</td>
<td colspan="4"><titleStmt></td>
<td></td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>│</td>
<td>├</td>
<td colspan="3"><title></td>
<td>
One or more <tt>title</tt> elements are used to give the title of the TEI document being created. It is suggested that titles be constructed based on the source document according to a national cataloging code.

Use of the <tt>level</tt> attribute is not recommended since it does not apply to a TEI document in a collection.

The <tt>type</tt> attribute may have any of the following values:
* <tt>main</tt>
* <tt>sub</tt>
* <tt>alt</tt>
* <tt>short</tt>
* <tt>desc</tt>
* <tt>translated</tt>
* <tt>MARC245a</tt>
* <tt>MARC245b</tt>
* <tt>uniform</tt>
</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>│</td>
<td>├</td>
<td colspan="3"><author></td>
<td>
One or more <tt>author</tt> elements (one name per element) are used to encode the names of entity primarily responsible for the content of the TEI document. Use <tt>persName</tt> or <tt>orgName</tt> when applicable. Whenever possible, establish or use the form of the name from a national name authority file. Examples:

* <tt><author><persName>Shakespeare, William, 1564-1616</persName></author></tt>
* <tt><author><orgName>National Organization for Women</orgName></author></tt>
* <tt><author>(unknown)</author></tt>
</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>│</td>
<td>├</td>
<td colspan="3"><editor></td>
<td>If applicable, use one or more <tt>editor</tt> elements (one name per element) to encode the names of entities besides those in <tt>author</tt> elements that have made a significant intellectual contribution to the work. If considered appropriate by the encoding project, the editor of the TEI document should be entered here. Use <tt>persName</tt> or <tt>orgName</tt> when applicable. Whenever possible, establish or use the form of the name from a national name authority file.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>│</td>
<td>└</td>
<td colspan="3"><respStmt></td>
<td>Record the names of other persons or organizations not covered by <author> and <editor>, one per <tt>respStmt</tt>. Each <tt>respStmt</tt> may have only one <tt>resp</tt> child element and one <tt>name</tt> element, though they may occur in either order. Use <tt>persName</tt> or <tt>orgName</tt> as children of <tt>name</tt> when applicable. Whenever possible, establish or use the form of the name from a national name authority file.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>├</td>
<td colspan="4"><editionStmt></td>
<td>This element contains information about the edition of the the TEI document produced, not the source document.</td>
<td></td>
<td></td>
</tr>

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

<tr>
<td>│</td>
<td>│</td>
<td>├</td>
<td colspan="3"><publisher></td>
<td>The publisher is the party responsible for making the file (the TEI document, not the source document) public.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>│</td>
<td>├</td>
<td colspan="3"><distributor></td>
<td>The distributor is the party from whom copies of the file (the TEI document, not the source document) can be obtained. Often the same as <publisher>, in which case no <distributor> element should be specified.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>│</td>
<td>├</td>
<td colspan="3"><authority></td>
<td>Only used for a text (the TEI document, not the source document) that is not formally published, but is nevertheless made available for circulation, in which case the party who makes it available should be recorded here.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>│</td>
<td>├</td>
<td colspan="3"><idno></td>
<td>Any unique identification number for the TEI document determined by the publisher.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>│</td>
<td>├</td>
<td colspan="3"><availability></td>
<td>Provide a prose rights statement for the TEI document. Provide a standard license, such as one from Creative Commons, if possible. Provide information on all applicable rights: rights in the original work, rights in page images of the source document, and rights in the encoded text.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>│</td>
<td>└</td>
<td colspan="3"><date when="____"/></td>
<td>Refers to the date of the first publication of the TEI document. Use <tt>when</tt> attribute to aid machine processing. This element has no content.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>├</td>
<td colspan="4"><seriesStmt></td>
<td>This element contains information about the electronic series being created. It has one required element (<tt><title level="s"></tt>) and other optional elements.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>│</td>
<td>└</td>
<td colspan="3"><title level="s" type="_"></td>
<td>Whenever possible, establish or use the form of the name from a national name authority file for the electronic series being created. Value of level attribute is drawn from TEI Guidelines.
</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>└</td>
<td colspan="4"><notesStmt></td>
<td>Optional.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>└</td>
<td colspan="4"><sourceDesc></td>
<td>In order to effectively represent the source(s) when many documents are represented by the TEI header in the absence of structures identifying parent-child and component relationships, multiple source descriptions should 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>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td>└</td>
<td colspan="3"><biblStruct></td>
<td>Metadata for the source document may be automatically generated from a MARC record. Use <biblStruct> with child elements listed, in the order below, for ease of display according to ISBD.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td>└</td>
<td colspan="2"><monogr></td>
<td>Use this element to group together the elements describing the whole source document, even if the whole source document is not a "monograph", per the TEI definition of this element.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>├</td>
<td colspan="1"><author></td>
<td>One or more <tt>author</tt> elements (one name per element) are used to encode the name for the personal author or corporate body responsible for the creation of the source document, even if this creator is not the main entry in the catalog record. Use <tt>persName</tt> or <tt>orgName</tt> when applicable. Whenever possible, establish or use the form of the name from a national name authority file.
</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>├</td>
<td colspan="1"><title level="_" type="_"></td>
<td>
At least one <tt>title</tt> element is required for the title of the source document. Give the title according to the national cataloging code.

The <tt>level</tt> attribute is used as in the TEI Guidelines.

Use of the <tt>type</tt> attribute is required: it may have any of the following values:
* <tt>main</tt>
* <tt>sub</tt>
* <tt>alt</tt>
* <tt>short</tt>
* <tt>desc</tt>
* <tt>translated</tt>
* <tt>MARC245a</tt>
* <tt>MARC245b</tt>
* <tt>uniform</tt>
</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>├</td>
<td colspan="1"><title level="_" type="MARC245b"></td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>├</td>
<td colspan="1"><respStmt></td>
<td>
Statement of responsibility, according to the national cataloging code.

If metadata is generated automatically from a MARC record, include a single empty <resp></resp> and put the entire statement of responsibility in <name> If creating metadata manually, include one <tt>respStmt</tt> for each responsible party.

Each <tt>respStmt</tt> may have only one <tt>resp</tt> child element and one <tt>name</tt> element, though they may occur in either order. Use <tt>persName</tt> or <tt>orgName</tt> as children of <tt>name</tt> when applicable. Whenever possible, establish or use the form of the name from a national name authority file.
</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>├</td>
<td colspan="1"><edition></td>
<td>Edition statement (if present).</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>├</td>
<td colspan="1"><pubPlace></td>
<td>Place of publication from the original source (if present)</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>├</td>
<td colspan="1"><publisher></td>
<td>First publisher etc. from the original source (if present)</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>├</td>
<td colspan="1"><date when="____"></date></td>
<td>Date of publication, distribution, etc. from the original source (if present). The content of the element is the statement of this data according to the national cataloging code. Use <tt>when</tt> attribute to aid machine processing.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>├</td>
<td colspan="1"><extent></td>
<td>Use of this element to describe the extent of the source document is recommended. If the data is generated by hand, it should include a comprehensible statement of the size of the item, such as the number of pages or leaves. If generated from a catalog record, it should include the extent of the item according to a national cataloging code.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>├</td>
<td colspan="1"><series></td>
<td>Following the <monogr> element grouping together all the above metadata about the encoded item, information about the series to which the item belongs goes here, following the content model in the TEI Guidelines. If generating this data from a catalog record, it is likely that you will have only one child element: a <tt>title</tt>.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>├</td>
<td colspan="1"><note></td>
<td>Notes about the source document, according to national cataloging codes.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td></td>
<td>└</td>
<td colspan="1"><idno></td>
<td>
In this location, <idno> refers to identification numbers for the source document. Use type="isbn-13" and type="isbn-10" if applicable.

This element may also 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>
<td></td>
<td></td>
</tr>

<tr>
<td>├</td>
<td colspan="5">encodingDesc</td>
<td></td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td>├</td>
<td colspan="4"></td>
<td>In the first child of <tt>encodingDesc</tt>, include a <tt>p</tt> element containing a prose statement about the format of the data in the header. Does the data in the <tt>sourceDesc</tt> follow AACR rules? How about in the <tt>fileDesc</tt>? Is ISBD punctuation included?</td>
<td></td>
<td></td>
</tr>

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

<tr>
<td>│</td>
<td></td>
<td>├</td>
<td colspan="3"><editorialDecl n="_"></td>
<td>Record encoding level for the content as an arabic numeral in the n attribute. As content of this element, record editorial decisions made during encoding and notes about omissions of material found in the original work.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td>├</td>
<td colspan="3"><tagsDecl><namespace name="http://www.tei-c.org/ns/1.0"><tagUsage></td>
<td>
<tagUsage> must be one of the following:
* <code><tagUsage gi="div1">Numbered divs used.</tagUsage></code>
* <code><tagUsage gi="div">Unnumbered divs used.</tagUsage></code>
</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td>└</td>
<td colspan="3"><classDecl><taxonomy xml:id="____"><bibl></td>
<td>
Use to document classification schemes used in the header or body of the TEI document. For example:
* <code><taxonomy xml:id="LCC"><bibl>Library of Congress Classification</bibl></taxonomy></code>
* <code><taxonomy xml:id="LCSH"><bibl>Library of Congress Subject Headings</bibl></taxonomy></code>
* <code><taxonomy xml:id="AAT"><bibl>Art & Architecture Theasaurus</bibl></taxonomy></code>
</td>
<td></td>
<td></td>
</tr>

<tr>
<td>├</td>
<td colspan="5"><profileDesc></td>
<td></td>
<td></td>
<td></td>
</tr>

<tr>
<td></td>
<td>└</td>
<td colspan="4"><textClass></td>
<td>The elements below are contained within this element.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td>├</td>
<td colspan="3"><classCode scheme="___"></td>
<td>True classification numbers as opposed to call numbers can be entered here. The value of the scheme attribute corresponds to a classification scheme defined previously in classDecl. Example: <code>scheme="#LCC"</code></td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td>└</td>
<td colspan="3"><keywords scheme="____"></td>
<td>Repeat this element as many times as there are keyword schemes. If the child <tt>term</tt> elements contain terms from a controlled vocabulary, indicate that controlled vocabulary through the scheme attribute. The value of the scheme attribute corresponds to a classification scheme defined previously in <tt>classDecl</tt>. Example: <code>scheme="#LCSH"</code></td>
<td></td>
<td></td>
</tr>

<tr>
<td>│</td>
<td></td>
<td></td>
<td>└</td>
<td colspan="2"><term></td>
<td>Use for terms from controlled or uncontrolled vocabularies, as indicated in the parent <tt>keywords</tt> element.</td>
<td></td>
<td></td>
</tr>

<tr>
<td>└</td>
<td colspan="5"><revisionDesc></td>
<td></td>
<td></td>
<td></td>
</tr>

<tr>
<td></td>
<td>└</td>
<td colspan="4"><change when="''YYYY-MM-DD''" who="''URI''"></td>
<td>
Create a <tt>change></tt> element to record each significant change to the TEI document, in reverse chronological order (i.e., most recent first). A prose description of the change is recorded as the content of each <tt><change></tt> element. This prose may contain lists for organization, and phrase-level markup (like <tt><gi></tt>, <tt><ptr></tt>, or <tt><date></tt>), but not paragraphs.

The date of the change in ISO 8601 form (YYYY-MM-DD) should be recorded on the <tt>when=</tt> attribute.

The person who is responsible for making the change is indicated by the <tt>who=</tt> attribute of <tt><change></tt>. Its value is a URI that points to a <tt><respStmt></tt> or <tt><person></tt> element that encodes information about the responsible party. Note that this reference is a URI reference and not an ID/IDREF reference, and thus is not checked by validation software. Small projects sometimes take advantage of this by putting information into the URI itself, and not having a <tt><respStmt></tt> or <tt><person></tt> element. E.g., <tt>who="#Kevin_Hawkins"</tt>.
</td>
<td></td>
<td></td>
</tr>
</table>

===Sample TEI Header===
<blockquote><pre>
<teiHeader>
<fileDesc>
<titleStmt>
<title type="main">Lincoln and Seward.</title>
<author>
<persName>Welles, Gideon, 1802-1878.</persName>
</author>
</titleStmt>
<publicationStmt>
<publisher>University of Michigan, Digital Library Initiatives</publisher>
<availability>
These pages may be freely searched and displayed. Permission must be received for
subsequent distribution in print or electronically. Please go to
http://www.umdl.umich.edu/ for more information.
</availability>
<date when="1996"/>
</publicationStmt>
<seriesStmt>
<title level="s" type="main">Making of America</title>
</seriesStmt>
<sourceDesc>
<biblStruct>
<monogr>
<author>
<persName>Welles, Gideon, 1802-1878.</persName>
</author>
<title level="m" type="MARC245a">Lincoln and Seward.</title>
<title level="m" type="MARC245b">Remarks upon the memorial address of Chas. Francis
Adams, on the late William H. Seward, with incidents and comments illustrative of the
measures and policy of the administration of Abraham Lincoln. And views as to the
relative positions of the late President and secretary of state.</title>
<respStmt>
<resp/>
<name>By Gideon Welles</name>
</respStmt>
<imprint>
<pubPlace>New York</pubPlace>
<publisher>Sheldon & company</publisher>
<date when="1874">1874</date>
</imprint>
<extent>viii, [7]-215 p ; 20 cm.</extent>
</monogr>
<note>First published in condensed form in the Galaxy, v. 16, 1873, p. [518]-530,
[687]-700, [793]-804.</note>
<idno type="isbn-10">1-4255-1817-6</idno>
<idno type="LC_call_number">E456 .W44</idno>
</biblStruct>
</sourceDesc>
</fileDesc>
<encodingDesc>
Data in the <gi>sourceDesc</gi> of the header comes from a pre-AACR2 record. Other data follows
AACR2 when applicable.
<projectDesc>
XML created for the Making of America collection.
</projectDesc>
<editorialDecl n="1">
<gi>sourceDesc</gi> created by exporting from catalog on 2008-06-15.
This electronic text file was created by optical character recognition (OCR). No
corrections have been made to the OCR-ed text and no editing has been done to the content
of the original document. Encoding has been done using the recommendations for Level 1 of
the TEI in Libraries Guidelines.
</editorialDecl>
<tagsDecl>
<namespace name="http://www.tei-c.org/ns/1.0">
<tagUsage gi="div">Only un-numbered divisions are used.</tagUsage>
</namespace>
</tagsDecl>
<classDecl>
<taxonomy xml:id="LCC">
<bibl>Library of Congress Classification</bibl>
</taxonomy>
<taxonomy xml:id="LCSH">
<bibl>Library of Congress Subject Headings</bibl>
</taxonomy>
</classDecl>
</encodingDesc>
<profileDesc>
<textClass>
<classCode scheme="#LCC">E456</classCode>
<keywords scheme="#LCSH">
<term>Lincoln, Abrahan, 1809-1865.</term>
<term>Seward, William Henry, 1801-1872.</term>
<term>Adams, Charles Francis, 1807-1886. Address of Charles Francis Adams ... on the life
... of William H. Seward.</term>
</keywords>
</textClass>
</profileDesc>
<revisionDesc>
<change who="#CKP" when="2005-05-25">Header generated from export of MARC record</change>
</revisionDesc>
</teiHeader>
</pre></blockquote>

==Linking between encoded text and images of source documents==

Consider moving this up under the General Rec. section. --Michelle

There are two recommended mechanisms for linking between the encoded text and facsimile page images of source documents. Projects may either:

<ol style="list-style-type: upper-alpha;">
<li>Use the <tt>@facs</tt> attribute on each <tt><pb></tt> element to point to the corresponding page image using a URI.</li>
<li>Use the <tt>@xml:id</tt> attribute on each <tt><pb></tt> element and a METS document to provide correspondence between <tt><pb></tt> elements and one or more facsimile page images (e.g., master, web derivatives, etc.).</li>
</ol>
Do we need to say this? And do we want all examples to use @facs?--Michelle
The examples below use the former method.

==Encoding Levels==

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

====Reference====
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html Chapter 3, Elements Available in All TEI Documents]

====Purpose====

To create electronic text with the primary purpose of keyword searching and linking to page images. The primary advantage in using the TEI at this very strictly limited level of encoding is that a TEI header is attached to the text file.

====Rationale====

The text is subordinate to the page image, and is not intended to stand alone as an electronic text (without page images).

Texts at Level 1 can be created and encoded by fully automated means, using uncorrected OCR of page images ("dirty OCR") or exporting from existing electronic text files. 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.

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, these texts, while lightly encoded, can be easily combined with more richly encoded texts (that also follow these guidelines) for searching. Further encoding based on document structures or content analysis can be added to a Level 1 text at any time.

'''Level 1 is most suitable for projects with the following characteristics''':
<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>

====Element Recommendations for Level 1====

<table border="1" width="80%">
<tr>
<td colspan="1"><div1> or <div></td>
<td colspan="1">There should be only one child of <body>: a single <div> (or <div1>)</td>
</tr>

<tr>
<td colspan="1"><ab></td>
<td colspan="1">There should be only one child of the <div> (or <div1>): a single <ab> wrapping all of the OCR text. If the text is ever “upgraded” to a Level 3 or higher, the <ab> element will be replaced by structural elements like and <table>.</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>

==== Level 1 Example: Alger Hiss document ====

<pre>
<TEI xml:id="someid" xmlns="http://www.tei-c.org/ns/1.0">
<teiHeader>
[Source and processing information goes here]
</teiHeader>
<text>
<body>
<div1>
<ab>
<pb n="113" facs="00000001.tif"/>
POINT VIII.
BECAUSE OF UNLAWFUL SURVEILLANCE, PETITIONER'S
CONVICTION SHOULD BE VACATED; ALTERNATIVELY,
DISCOVERY AND A HEARING SHOULD BE ORDERED.
The nature and extent of surveillance of Hiss, his
family and associates was not known at the time of trial by
the defense. Even now, with the release of some of the government documents concerning FBI investigative techniques regarding
Hiss, the full extent of surveillance -- wiretapping, mail openings, mail covers, physical surveillance, and other intrusive
techniques -- is still not 'clear. Nevertheless, it is apparent
that information gathered through the exploitation of unlawful
wiretaps and other illegal surveillance was used at trial and
consequently the conviction must be reversed. Alternatively,
further discovery and a hearing is essential to a fair determination regarding these issues.
FBI surveillance of Hiss began in earnest in 1941 with
the institution of a mail cover on his incoming correspondence
at his home in connection with an FBI investigation of possible
Hatch Act violations. CN Ex. 98A. Another mail cover was placed

-113 -

<pb n="114" facs="00000002.tif"/>
on the Hiss mail in 1945, and at the same time the FBI obtained
toll call records from the Hiss residence Telephone for the
years 1943 and 1944 as well. CN Ex. 99. In September, 1945,
the FBI intercepted telegrams to Hiss as well. CN Ex. 100.
In late November, 1945, FBI surveillance of the Hiss
residence in Washington, D.C., escalated. For the third time,
a mail cover was instituted beginning on November 28, 1945,
which was continued at least until 1946. CN Ex. 101 at p. 70;
CN Ex. 102. Continuous physical surveillance of Hiss was begun
as well. CN Ex. 101 at p. 72. Although this twenty-four-hour
surveillance was discontinued on December 14, 1945, physical
surveillance was conducted frequently at various times until
September, 1947. CN Ex. 102; CN Ex. 103.
The most intrusive invasion of petitioner's rights
68/ Also before 1947, a letter from Priscilla Hiss addressed
to her son, Timothy Hobson, was intercepted and its contents
read. CN Ex. 100A at p. 167. In approximately March, 1947,
a letter from a Michael Greenberg addressed to petitioner regarding an application for employment with the United Nations
was also intercepted, in a manner not revealed by the documents. CN Ex. 100B

-114 -

<pb n="115" facs="00000003.tif"/>
occurred from December 13, 1945 until the Hisses moved from
Washington, D.C. to New York City on September 13, 1947. A
"technical surveillance," -- a wiretap -- was placed on the Hiss
telephone at their residence on P Street-in Washington, D.C.
The logs of this surveillance constitute twenty-nine volumes
of FBI serials and are roughly 2,500 pages in length, in which
an enormous amount of information concerning the Hisses' personal lives, relationships with friends and associates, and
habits is recorded.
The wiretap was installed following FBI Director Hoover's
application to the Attorney General for authorization, although
no written authorization appears in the documents released to
Hiss. The purpose of the application was to gather information
regarding Hiss' alleged contacts with Soviet espionage agents and
communists in government service, general allegations which had
been made by Elizabeth Bentley and Chambers.
As one would expect, the interception of every telephone
h9/ Hoover's initial request was answered by a note requesting information on Hiss. CN Ex. 104. Additional information
was furnished by letter dated November 30, 1945. CN Ex. 105.

-115 -

</ab>
</div1>
</body>
</text>
</TEI>
</pre>

===LEVEL 2: Minimal Encoding===

====Reference====
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html Chapter 3, Elements Available in All TEI Documents]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html Chapter 4, Default Text Structure]

====Purpose====
To create electronic text for full-text searching, linking to page images, and identifying simple structural hierarchy to improve navigation. (For example, you can create a table of contents from such encoding.)

====Rationale====
The text is mainly subordinate to the page image, though navigational markers (textual divisions, headings) are captured. The text could stand alone as electronic text (without page images) only ([[User:rwisnesk|rwisnesk]]) 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. One of the motivations for using Level 2 is to avoid expensive analysis of textual elements and/or the expense of accurate text conversion, e.g., double-keying or detailed proofreading of automatic OCR.

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), automated methods are not likely to be reliable across a large body of work, especially if the materials are from earlier than 1900. 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.

For the most part, 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 in which''':

* 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 is 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

====Element Recommendations for Level 2====

Use 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> or <div></td>
<td colspan="1">If no type= attribute is specified, a type= value of "section" should be presumed. </td>
</tr>
<tr>
<td colspan="1"><head></td>
<td colspan="1">Required if headings are present</td>
</tr>
<tr>
<td colspan="1"><ab></td>
<td colspan="1"> At least one container element is required.</td>
</tr>
</table>

====Level 2 Example: Basic Structure====

<pre>
<TEI xmlns="http://www.tei-c.org/ns/1.0">
<teiHeader>[See above for an example of a TEI Header]</teiHeader>
<text>
<front>
[title page information, table of contents, prefaces, etc.]
[optional]
</front>
<body>
<div type="section">
<pb xml:id="p21198-zz0002mpqr" n="1"/>
<head>A DISSERTATION UPON Religious Worship.</head>
<ab>[a whole section is contained within this anonymous block
tag; interspersed with <pb> elements pointing to page
images]<pb xml:id="p21198-zz0002mpwb" n="2"/></ab>
</div>
<div type="section">
<pb xml:id="p21198-zz0002mq0c" n="27"/>
<ab>
</ab>
<div type="subsection">
<head>CHAP. I. The Origin of the Customs and Ceremonies of the Jews. their federal Divisions;
and the various Particulars wherein they differ.</head>
<ab>[all the paragraphs of chapter one go here with page
breaks inserted]</ab>
</div>
</div>
</body>
<back> [optional] </back>
</text>
</TEI>
</pre>

==== Level 2 Example: Alger Hiss document ====

<pre>
<TEI xml:id="someid" xmlns="http://www.tei-c.org/ns/1.0">
<teiHeader>
[Source and processing information goes here]
</teiHeader>
<text>
<body>
<div1>
<pb n="113" facs="00000001.tif"/>
<head>POINT VIII: BECAUSE OF UNLAWFUL SURVEILLANCE, PETITIONER'S CONVICTION SHOULD BE VACATED; ALTERNATIVELY, DISCOVERY AND A HEARING SHOULD BE ORDERED.</head>
<ab>
POINT VIII.
BECAUSE OF UNLAWFUL SURVEILLANCE, PETITIONER'S
CONVICTION SHOULD BE VACATED; ALTERNATIVELY,
DISCOVERY AND A HEARING SHOULD BE ORDERED.
The nature and extent of surveillance of Hiss, his
family and associates was not known at the time of trial by
the defense. Even now, with the release of some of the government documents concerning FBI investigative techniques regarding
Hiss, the full extent of surveillance -- wiretapping, mail openings, mail covers, physical surveillance, and other intrusive
techniques -- is still not 'clear. Nevertheless, it is apparent
that information gathered through the exploitation of unlawful
wiretaps and other illegal surveillance was used at trial and
consequently the conviction must be reversed. Alternatively,
further discovery and a hearing is essential to a fair determination regarding these issues.
FBI surveillance of Hiss began in earnest in 1941 with
the institution of a mail cover on his incoming correspondence
at his home in connection with an FBI investigation of possible
Hatch Act violations. CN Ex. 98A. Another mail cover was placed

-113 -

<pb n="114" facs="00000002.tif"/>
on the Hiss mail in 1945, and at the same time the FBI obtained
toll call records from the Hiss residence Telephone for the
years 1943 and 1944 as well. CN Ex. 99. In September, 1945,
the FBI intercepted telegrams to Hiss as well. CN Ex. 100.
In late November, 1945, FBI surveillance of the Hiss
residence in Washington, D.C., escalated. For the third time,
a mail cover was instituted beginning on November 28, 1945,
which was continued at least until 1946. CN Ex. 101 at p. 70;
CN Ex. 102. Continuous physical surveillance of Hiss was begun
as well. CN Ex. 101 at p. 72. Although this twenty-four-hour
surveillance was discontinued on December 14, 1945, physical
surveillance was conducted frequently at various times until
September, 1947. CN Ex. 102; CN Ex. 103.
The most intrusive invasion of petitioner's rights
68/ Also before 1947, a letter from Priscilla Hiss addressed
to her son, Timothy Hobson, was intercepted and its contents
read. CN Ex. 100A at p. 167. In approximately March, 1947,
a letter from a Michael Greenberg addressed to petitioner regarding an application for employment with the United Nations
was also intercepted, in a manner not revealed by the documents. CN Ex. 100B

-114 -

<pb n="115" facs="00000003.tif"/>
occurred from December 13, 1945 until the Hisses moved from
Washington, D.C. to New York City on September 13, 1947. A
"technical surveillance," -- a wiretap -- was placed on the Hiss
telephone at their residence on P Street-in Washington, D.C.
The logs of this surveillance constitute twenty-nine volumes
of FBI serials and are roughly 2,500 pages in length, in which
an enormous amount of information concerning the Hisses' personal lives, relationships with friends and associates, and
habits is recorded.
The wiretap was installed following FBI Director Hoover's
application to the Attorney General for authorization, although
no written authorization appears in the documents released to
Hiss. The purpose of the application was to gather information
regarding Hiss' alleged contacts with Soviet espionage agents and
communists in government service, general allegations which had
been made by Elizabeth Bentley and Chambers.
As one would expect, the interception of every telephone
h9/ Hoover's initial request was answered by a note requesting information on Hiss. CN Ex. 104. Additional information
was furnished by letter dated November 30, 1945. CN Ex. 105.

-115 -

</ab>
</div1>
</body>
</text>
</TEI>
</pre>

===LEVEL 3: Simple Analysis===

====Reference====

* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html Chapter 4, Default Text Structure, P5 Guidelines]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/VE.html Chapter 6, Verse, P5 Guidelines]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FT.html Chapter 14, Tables, Formulæ, and Graphics, P5 Guidelines]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html Chapter 16, Linking, Segmentation, and Alignment, P5 Guidelines] (for handling notes)

====Purpose====


To create a stand alone electronic text and identify
hierarchy (logical structure) and typography without content analysis being of primary importance.

====Rationale====


Level 3 texts can be created by conversion from an electronic source such as
HTML or word-processed documents or a print source with the automatic generation of full text by
Optical Character Recognition software. Level 3 texts can also be created from scratch (e.g., transcription, born digital, etc.).
Encoding at this level 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 logical structure and appearance of the text and not specialized content analysis.

Level 3 texts identify front and back matter, divisions within the text, and all paragraph breaks. Floating texts, or
sub-texts like a poem or letter embedded in the greater text, are supported in this level. 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.

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.


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


<ul>
<li>the material is of interest to a large community of users who wish to read texts that allow for keyword searching</li>
<li>some sophistication of display, delivery, and searching based on structure of the text is desired</li>
<li>each text will undergo quality control 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>

====Element Recommendations for Level 3====

Use all elements specified in Levels 1 and 2, plus the following:

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

<td colspan="1">Required if present.</td>
</tr>
<tr>
<td colspan="1"><div></td>

<td colspan="1">Required if present; <tt>type</tt> attribute is recommended.</td>
</tr>
<tr>
<td colspan="1"><floatingText></td>

<td colspan="1">Recommended if present.</td>
</tr>

<tr>
<td colspan="1"></td>
<td colspan="1">Required for paragraph breaks in prose.</td>
</tr>

<tr>
<td colspan="1"><lg> and <l></td>
<td colspan="1">Required for identifying groups of lines and lines, respectively.</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; <tt>rend</tt> 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 <tt><note></tt> element. Marginal notes, without reference, should occur at the beginning of the paragraph to which they refer, with the value of the <tt>place</tt> attribute as "margin".</td>

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

====General Level 3 Recommendations====

'''Forme Works'''

Running heads, catch words, and other such forme work information should not be included in Level 3, with the exception of page numbers, which are recorded using <tt>pb</tt>. If upgrading a text from Level 1 or Level 2 that was generated using OCR, discard the forme work information.

'''Front Matter'''

'''<div type="contents">''': Use [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html#DSFRONT lists] to mark up the table of contents with the <tt><ptr></tt> element used to reference the starting page number. The <tt><ptr></tt> element can reference the <tt><pb></tt> identifier or an identifier (e.g., @xml:id) placed in the corresponding division of text.

'''Body'''

'''<note>''': 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:

<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 corresponding division of the text (e.g., end of chapter).</li>
</ul>

'''Back Matter'''

'''<div type="index">''': Use [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#CONOIX lists] to mark up index entries with the <tt><ref></tt> element used to reference the corresponding page number. Add the "target" attribute (@target) to reference the <tt><pb></tt> identifier to generate links from the index into the text proper.

====Level 3 Examples====

=====Basic Structure: Prose ([http://brie.dlib.indiana.edu/~mdalmau/bpg/VAA2383_prose_verse_p5_lev3.xml See full example])=====

<pre>
<TEI xmlns="http://www.tei-c.org/ns/1.0" xml:id="VAA2383">
<teiHeader> [stuff] </teiHeader>
<text>
<front>
<div type="frontispiece">[figure]</div1>
<titlePage>[text]</titlePage>
<div type="dedication">[text]</div1>
<div type="contents">[text]</div1>
</front>
<body>
<div type="book">
<head>[book title]</head>
<div type="chapter">[text]</div2>
<div type="chapter">[text]</div2>
<div type="chapter">[text]</div2>
<div type="chapter">[text]</div2>
<div type="chapter">[text]</div2>
</div>
</body>
<back>
<div type="appendix">[text]</div1>
<div type="index">[text]</div1>
</back>
</text>
</TEI>
</pre>

=====Basic Structure: Verse ([http://brie.dlib.indiana.edu/~mdalmau/bpg/VAA2383_prose_verse_p5_lev3.xml See full example])=====
<pre>
<TEI xmlns="http://www.tei-c.org/ns/1.0" xml:id="VAA2383">
<teiHeader> [info] </teiHeader>
<text>
<front>
<titlePage>[text]</titlePage>
<div type="dedication">[text]</div1>
<div type="contents">[text]</div1>
</front>
<body>
<div type="book">
<head>[book title]</head>
<div type="part">
<head>[section title]</head>
<div type="poem">
<head>THE DAYS GONE BY.</head>
<lg>
<l n="1">O the days gone by! O the days gone by!</l>
<l n="2">The apples in the orchard, and the pathway through the rye;</l>
<l n="3">The chirrup of the robin, and the whistle of the quail</l>
<l n="4">As he piped across the meadows sweet as any nightingale;</l>
<l n="5">When the bloom was on the clover, and the blue was in the sky,</l>
<l n="6">And my happy heart brimmed overin the happy days gone by.</l>
</lg>
<lg>[lines of poetry]</lg>
<lg>[lines of poetry]</lg>
<lg>[lines of poetry]</lg>
</div>
</div>
</div>
</body>
</text>
</TEI>
</pre>

=====Table of Contents=====
<pre>

<div type="contents">
<head>CONTENTS</head>
<list type="simple">
<item>I. A Boy and His Dog <hi rend="right">3</hi>
<ptr target="#VAA2383_011"/></item>
<item>II. Romance <hi rend="right">12</hi>
<ptr target="#VAA2383_020"/></item>
<item>III. The Costume <hi rend="right">21</hi>
<ptr target="#VAA2383_029"/></item>
<item>IV. Desperation <hi rend="right">30</hi>
<ptr target="#VAA2383_038"/></item>
<item>V. The Pageant of the Table Round <hi rend="right">38</hi>
<ptr target="#VAA2383_046"/></item>
</div>
</pre>

=====Chapter with Letter=====
<pre>
<div type="chapter">
<pb xml:id="VAA2383_126" n="118"/>
<head type="main">CHAPTER XIV</head>
<head type="subtitle">MAURICE LEVY'S CONSTITUTION</head>
<hi rend="b">L</hi>O, SAM!" said Maurice cautiously. "What you doin'?"
Penrod at that instant had a singular experiencean intellectual shock like a flash of fire in the
brain. Sitting in darkness, a great light flooded him with wild brilliance. He gasped!

"What you doin'?" asked Maurice for the third time, Sam Williams not having decided upon a reply.
<pb xml:id="VAA2383_127" n="119"/>
It was Penrod who answered.
"Drinkin' lickrish water," he said simply, and wiped his mouth with such delicious enjoyment that
Sam's jaded thirst was instantly stimulated. He took the bottle eagerly from Penrod.
"A-a-h!" exclaimed Penrod, smacking his lips. "That was a good un!"

Penrod uttered some muffled words and then waved both armseither in response or as an expression
of his condition of mind; it may have been a gesture of despair. How much intention there was in
this actobviously so rash, considering the position he occupiedit is impossible to say.
Undeniably there must remain a suspicion of deliberate purpose.

<pb xml:id="VAA2383_138" n="130"/>
The damsel curtsied again and handed him the following communication, addressed to herself: 
<floatingText>
<body>
<div type="letter">
"Dear madam Please excuse me from dancing the cotilo with you
this afternoon as I have fell off the barn
"Sincerly yours<lb/>
"P<hi rend="sc">ENROD</hi> S<hi rend="sc">CHOFIELD</hi>."

</div>
</body>
</floatingText>
</div>
</pre>

===LEVEL 4: Basic Content Analysis===

====Reference====

* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COHQ Chapter 3.3 Highlighting and Quotation, P5 Guidelines]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COED Chapter 3.4 Simple Editorial Changes]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#CONA Chapter 3.5 Names, Numbers, Dates, Abbreviations, and Addresses]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html Chapter 4, Default Text Structure, P5 Guidelines]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/VE.html Chapter 6, Verse, P5 Guidelines]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DR.html#DRCAST Chapter 7.1.4 Performance Texts: castLists and castItems]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DR.html#DRDIV Chapter 7.2.1 Performance Texts: Major Structural Divisions]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DR.html#DRSP Chapter 7.2.2 Performance Texts: Speeches and Speakers]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DR.html#DRSTA Chapter 7.2.3 Performance Texts: Stage Directions]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ND.html Chapter 13, Names, Dates, People, and Places, P5 Guidelines]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FT.html Chapter 14, Tables, Formulæ, and Graphics, P5 Guidelines]
* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html Chapter 16, Linking, Segmentation, and Alignment, P5 Guidelines]

====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.

====Rationale====
Greater description of function and content allows for:

<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>

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.

Level 4 texts contain elements and attributes that describe content. 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. 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.

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 political 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.


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


<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>

====Element Recommendations for Level 4====

Use all elements specified in Levels 1, 2 and 3, plus elements in the following table. Note that some of these elements are defined in Level 3 as well, but their use in Level 4 is more strict.

<table border="1" width="80%">
<tr>
<td colspan="1"><titlePage> and appropriate child elements</td>
<td colspan="1">Required.</td>
</tr>

<tr>
<td colspan="1"><group></td>
<td colspan="1">Required to encode a collection of independent texts that are regarded as a single group for processing or other purposes.</td>
</tr>

<tr>
<td colspan="1"><list> and <item></td>
<td colspan="1">Required to indicate ordered and unordered list structures.</td>
</tr>

<tr>
<td colspan="1"><table>, <row>, and <cell></td>
<td colspan="1">Required to indicate table structures.</td>
</tr>

<tr>
<td colspan="1"><hi></td>
<td colspan="1">Required to indicate change in rendition when a more specific element is not being used; rend attribute is optional.</td>
</tr>

<tr>
<td colspan="1"><emph>, <foreign>, <gloss>, <term>, or <title></td>
<td colspan="1">Recommended to identify typographically distinct text.</td>
</tr>
<tr>
<td colspan="1"><epigraph>, <quote>, <said>, <mentioned>, or <soCalled></td>
<td colspan="1">Recommended to represent speech, thought, quotation, etc.</td>
</tr>
<tr>
<td colspan="1"><sic>, <corr>, or <choice></td>
<td colspan="1">Recommended to encode errors or typos.</td>
</tr>

<tr>
<td colspan="1"><opener>, <dateline>, <salute> <closer>, <signed>, <postscript></td>
<td colspan="1">Required to indicate specific parts of letters.</td>
</tr>

<tr>
<td colspan="1"><argument></td>
<td colspan="1">Recommended to encode a "list of topics sometimes found at the start of a chapter or other division".</td>
</tr>

<tr>
<td colspan="1"><trailer></td>
<td colspan="1">Recommended to encode a heading- or title-like content at the end of a division.</td>
</tr>

<tr>
<td colspan="1"><add>, <del>, <gap>, and <unclear></td>
<td colspan="1">Recommended to encode material that is omitted, added, marked for deletion, or is illegible, invisible, or inaudible. </td>
</tr>

<tr>
<td colspan="1"><figure>, <head>, <figDesc>, and <graphic></td>
<td colspan="1">Used to refer to illustrative images and descriptive information about those images.</td>
</tr>

<tr>
<td colspan="1"><castList>, <castItem>, <sp>, <speaker>, and <stage></td>
<td colspan="1">Required to encode different structures in performance texts (i.e. drama).</td>
</tr>

<tr>
<td colspan="1"><sp> and <speaker></td>
<td colspan="1">Required to encode oral histories interviews.</td>
</tr>

<tr>
<td colspan="1"><persName>, <placeName>, <geogName>and <orgName> </td>
<td colspan="1">Recommended to encode personal, place and organizational names referenced in a text.</td>
</tr>

<tr>
<td colspan="1"><listName>, <listPlace> and <listOrg> </td>
<td colspan="1">Recommended in support of personal, place and organizational names normalization and to capture
additional information about the names. Should be captured in an external TEI file for easier maintenance of names.</td>
</tr>

</table>

====General Level 4 Recommendations====

* The use of [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-group.html <group>] is required when you need to encode a body of distinct texts that are grouped together and are regarded as a unit. Most typical examples of such composite texts would be anthologies, collected works of an author, etc. Section [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html#DSGRP 4.3.1 Grouped Texts] states, "The presence of common front matter referring to the whole collection, possibly in addition to front matter relating to each individual text, is a good indication that a given text might usefully be encoded in this way."

* Any ambiguous emphasized text '''should''' be encoded as [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-hi.html <hi>] (e.g. <hi rend="bold">), if more specific elements are not used.

* Typographically distinct text '''could''' be encoded with more specificity. We recommend the following approaches:
**to represent speech, thought, quotation, etc.:
***[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-epigraph.html <epigraph>]
***[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-quote.html <quote>],
***[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-said.html <said>],
***[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-mentioned.html <mentioned>],
***[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-soCalled.html <soCalled>],
**to represent foreign words or phrases, linguistically emphatic or stressed words or phrases, words regarded as a technical term, etc.:
***[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-emph.html <emph>],
***[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-foreign.html <foreign>] (e.g. <tt><foreign xml:lang="fr"></tt>),
***[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-gloss.html <gloss>],
***[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-term.html <term>],
***[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-title.html <title>]

* We recommend the following three approaches to encode errors or typos in original texts.
** [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-sic.html <sic>] element is recommend to be used to indicate errors without correcting them
** [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-corr.html <corr>] element is recommended to be used if an encoder chooses not to correct
** [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-choice.html <choice>] element represents the combination for two approaches, with the encoder documenting both encountered errors and their corrections:

<pre>
He has no Scruple about Fish; but won't touch a bit of Pork, it being
<choice>
<sic>expresly</sic>
<corr>expressly<corr>
</choice> forbidden by their Law.
</pre>
FROM: Thomas Bluett. ''Some Memoirs of the Life of Job, the Son of Solomon,
the High Priest of Boonda in Africa; Who was a Slave About Two Years in Maryland; and Afterwards Being Brought to England, was Set Free, and Sent to His Native Land in the Year 1734.'' London: Printed for R. Ford, 1734.

or

<pre>
4. The art of writing she obtained by her own industry and curiosity, and in so
short a time that in the year 1765, when she was not more than twelve years of
<choice>
<sic>age,she</sic>
<corr>age, she></corr>
</choice>
was capable of writing letters to her friends <pb xml:id="p11" n="11"/> on various
subjects. She also wrote to several persons in high stations.
</pre>
FROM: Abigail Mott, 1766-1851. ''Biographical Sketches and Interesting Anecdotes of Persons of Colour. To Which is Added, a Selection of Pieces in Poetry.'' New-York: M. Day, 1826.

* Use [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-argument.html <argument>] to encode a prefatory list or prose description of the topics usually discovered at the beginning of a chapter. The content within the <argument> element can be presented as a list or as a paragraph:

<pre>
<div type="chapter" n="1">
<pb xml:id="albert14" n="14"/>
<head>CHAPTER I.<lb/>CHARLOTTE BROOKS.</head>
<argument>
Causes of immorality among colored people - Charlotte Brooks - She is sold South -
Sunday work.
</argument>
 ... 
</div>
</pre>
FROM: Octavia V. Rogers Albert. ''The House of Bondage, or, Charlotte Brooks and Other Slaves, Original and Life Like, As They Appeared in Their Old Plantation and City Slave Life; Together with Pen-Pictures of the Peculiar Institution, with Sights and Insights into Their New Relations as Freedmen, Freemen, and Citizens.'' New York: Hunt & Eaton, 1890.

* The [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-trailer.html <trailer>] element is recommended to encode a heading- or title-like content at the end of a division (i.e. chapter, book, etc.)
<pre>
<TEI xmlns="http://www.tei-c.org/ns/1.0" xml:id="someid">
<teiHeader>[stuff]</teiHeader>
<text>
<body>
<div type="book">
<head>[book title]</head>
<div type="chapter" n="1">
<head>[chapter title]</head>
[text]
<trailer>Here ends the Chapter 1.<trailer>
</div>
<div type="chapter" n="2">
<head>[chapter title]</head>
[text]
<trailer>Here ends the Chapter 2.<trailer>
</div>
<trailer>FINIS.<trailer>
</div>
</body>
</text>
</TEI>
</pre>

* The elements [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-add.html <add>], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-del.html <del>], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-unclear.html <unclear>], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-gap.html <gap>] '''could''' be used to indicate instances when a text (i.e. word or part of it, phrase or part of it) has been omitted, added, marked for deletion, or because the material is illegible, invisible, or inaudible (i.e. while transcribing oral history interviews.)

<pre>
But it is well authenticated by the observation of every one, that <del
rend="overstrike" hand="JHL">their manner</del> <add rend="sup" hand="JHL">this way—i.e.
the above</add> of writing influences the style of compos. of those who practise it
considerably, when they grow up to years of manhood; for their productions, <del
hand="JHL" rend="overstrike">instead</del> far from being terse, argumentative,
convincing, are without head or tail & are generally an incongruous mass mixed up in the
most disgusting manner, without divisions or heads & in short without a subject (so to
speak).
</pre>
FROM: Class Composition of J. Horace Lacy, [January 1851]1. Lacy, James Horace, 1834-1852

<pre>
 [. . .]But I still hope for & trust in God and I believe he will animate our brave
defenders with a superhuman power and we will yet drive from our soil the hated invaders
whose tread <unclear reason="ink blot"></unclear> profanation, but this is an hour to try
men's souls—Fort Donelson has been taken by the enemy. Frank was there and covered
himself with honor but his bravery cost him a wound; he was wounded in the leg slightly—a
flesh wound only, you must not be uneasy. [. . .]
</pre>
FROM: Kimberly Family Personal Correspondence, 1862-1864. Transcript of the manuscript, UNC-Chapel Hill, Southern Historical Collection.

* Names should be encoded using <persName>, <placeName>, <geogName>, and <orgName>, tags with the "key" attribute providing a reference to an external file for managing name normalization and compilation of additional information such as biographical or geospatial information. The external TEI file maintains a unique entry for each name, grouped accordingly under <listPerson>, <listPlace>, and <listOrg>, which is uniquely referenced with an "xml:id" attribute. The "key" value in the source file references the "xml:id" value in the external file. References to controlled vocabularies and national or local authority files may be signified by a prefix in the "xml:id" attribute (e.g., tgn_0000000 for the Getty's Thesaurus of Geographic Names). When referencing a controlled vocabulary be sure to specify this information in the <classDecl> section of the TEI Header.

<pre>

The first Jews arrived in <placeName key="tgn_7012924">Indianapolis</placeName>
in the middle of the 19th century. Primarily immigrants from <placeName key="tgn_7000084">
Germany</placeName> and other points in central Europe (though many had lived elsewhere in the
<placeName key="tgn_7012149">United States</placeName> before they arrived in the city),
they were drawn from throughout the Midwest by the growth of commerce and rail lines in
<placeName key="tgn_7012924">Indianapolis</placeName>.

</pre>

<pre>

<figure n="VAA7662-004-001">
PRIZE LIBRARY GIFT-Indiana University President <persName key="lcnaf_82134365">Elvis J. Stahr</persName> (right),
a former law dean and practicing attorney, reminisces with Professor of Law
<persName key="lcnaf_00113347">W. Howard Mann</persName> as the two inspect some
of the nearly 3,000 volumes of <orgName key="lcnaf_79006848">U.S. Supreme Court</orgName> records recently
transferred to I.U. from the <orgName key="lcnaf_79109178">Indiana Supreme Court Library</orgName>.
The collection, dating back to 1925, is one of the oldest and most complete sets in existence. 
</figure>
</pre>

<pre>
<!--External file for maintaining personal and organization name normalization and additional information.
<listPerson>
<person xml:id="lcnaf_82134365">
<persName>
<surname>Stahr</surname>, <forename type="first">Elvis</forename>
<forename type="middle">J.</forename>
</persName>
<birth when="1916">1916</birth>
</person>
<person xml:id="lcnaf_00113347">
<persName>
<surname>Mann</surname>, <forename type="first">W.</forename>
<forename type="middle">Howard</forename>
</persName>
</person>
</listPerson>

<listOrg>
<org xml:id="lcnaf_79006848">
<orgName>
United States. Supreme Court
</orgName>
</org>
<org xml:id="lcnaf_79109178">
<orgName>
Indiana. Supreme Court
</orgName>
</org>
</listOrg>
</pre>

=====Level 4 Front and Back Matter=====

* The use of the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-titlePage.html <titlePage>] element with appropriate child elements describing the major features of most title pages is required. The child elements are listed in [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html#DSTITL Section 4.6 "Title Pages"]

* [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-titlePage.html <titlePage>] should include the verso if present, divided by <pb n="verso"/>.

* Frontispieces should be encoded as a <figure>, within a separate division (numbered or unnumbered, depending on the general editorial decision for a specific encoding project) and .

* Tables of contents, errata, subscription lists, "other titles by the same author" should be included in a separate division (numbered or unnumbered, depending on the general editorial decision for a specific encoding project), as a [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-list.html <list>] with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-item.html <item>]s.
*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 are not considered of primary importance to the text, we propose three options:
**Fully transcribe and encode
**Link to page images (may not include an encoded transcription)
**Fully omit and note the omission in [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-editorialDecl.html <editorialDecl>]

=====Level 4 Letters=====

* Letters that occur within the text body provided memorable challenges in P4. However, the introduction of the <floatingText> element in TEI P5 gives a cleaner approach of encoding letters or any "independent text which interrupts the text containing it at any point but after which the surrounding text resumes” (see more in [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html#DSFLT Section 4.3.2 Floating Texts]) It is recommended that quoted letters that occur as part of a text (and not collections of letters themselves) be encoded within <floatingText> <body> <div1 type="letter"> with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-opener.html <opener>], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-dateline.html <dateline>], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-salute.html <salute>], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-signed.html <signed>], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-closer.html <closer>], [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-postscript.html <postscript>] included as appropriate.

<pre>
She opened and read as follows:
<floatingText>
<body>
<div1 type="letter">
<opener>
<dateline>AUGUSTA, March 4th, 18—</dateline>
<salute>
<hi rend="italics">Mrs. A. Mitten:</hi>
</salute>
</opener>
"Having recently understood that you have procured a private teacher, we have
ventured to stop your advertisement, <hi rend="italics">though ordered to continue it
until forbid,</hi> under the impression that you have probably forgotten to have it
stopped. If, however, we have been misinformed, we will promptly resume the
publication of it. You will find our account below; which as we are much in want of
funds, you will oblige us by settling as soon as convenient. Hoping your teacher is
all that you could desire in one,
<closer>
<salute>"We remain, your ob't. serv'ts,</salute>
<signed>"H—& B—”</signed>
</closer>
</div1>
</body>
</floatingText>
</pre>
FROM: Augustus Baldwin Longstreet, 1790-1870. ''Master William Mitten: or, A Youth of Brilliant Talents, Who Was Ruined by Bad Luck.'' Macon, Ga.: Burke, Boykin, 1864.

=====Level 4 Drama=====
*Within the front matter (<front>) of a performance text, cast lists should be encoded as <castList>s, with each item in that list encoded as <castItem>s.
*Also, if desired (though not required), each <castItem> can be uniquely identified with the xml:id attribute construct.

From Shakespeare's ''King Lear'':

<pre>
<front>
<castList><head>Dramatis Personae</head>
<castItem xml:id="kllear">LEAR king of Britain</castItem>
<castItem xml:id="klfrance">KING OF FRANCE</castItem>
<castItem xml:id="klburgundy">DUKE OF BURGUNDY</castItem>
<castItem xml:id="klcornwall">DUKE OF CORNWALL</castItem>
<castItem xml:id="klalbany">DUKE OF ALBANY</castItem>
<castItem xml:id="klkent">EARL OF KENT</castItem>
<castItem xml:id="klgloucester">EARL OF GLOUCESTER</castItem>
<castItem xml:id="kledgar">EDGAR son to Gloucester.</castItem>
<castItem xml:id="kledmund">EDMUND bastard son to Gloucester.</castItem>
[. . .]
</castList>
</front>
</pre>
*Within the body of performative texts, speeches are encoded as <sp>, with speakers identified by the <speaker> element which is a child of <sp>
*Stage directions are encoded as <stage> and enclose block level content describing scenery, etc.
*When encoding the actual speech content itself, utilize elements and attributes that correspond to the type of dramatic speech presented (e.g. for prose speech with <lb> to designate a new line in a particular edition of the text or <lg> and <l> to describe dramatic verse structures).
*If referencing the xml:id defined in the <castList> is desired, utilize the "who" attribute construct for the IDREF datatype.

Again, from ''King Lear'':
<pre>
<div type="act" n="1">
<head>Act 1</head>
<div type="scene" n="1">
<head>Scene 1</head>
<stage>King Lear's palace.</stage>
<stage>Enter KENT, GLOUCESTER, and EDMUND</stage>

<sp>
<speaker who="klkent">KENT</speaker>
I thought the king had more affected the Duke of<lb/>
Albany than Cornwall.
</sp>
<sp>
<speaker who="klgloucester">GLOUCESTER</speaker>
It did always seem so to us: but now, in the<lb/>
division of the kingdom, it appears not which of<lb/>
the dukes he values most; for equalities are so<lb/>
weighed, that curiosity in neither can make choice<lb/>
of either's moiety.
</sp>
<sp>
<speaker who="klkent">KENT</speaker>
Is not this your son, my lord?
</sp>
[. . .]
</div>
</div>
</pre>

=====Level 4 Oral History=====

* Speakers in oral history interviews, i.e. interviewee(s) and interviewer(s), can be identified in the <teiHeader> in several ways:
** In the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-profileDesc.html <profileDesc>], in the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-particDesc.html <particDesc>], using the [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-list.html <list>] element, with [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html <name>] inside of [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-item.html <item>]s.
** As a list of author <name>s within [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD2 <fileDesc>] / [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD21 <titleStmt>]

In either method, use an xml:id= on the <name> element to uniquely identify the individual participant

* The list of interview's participants can be also listed within the body of the interview (see an example below.)
* 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 xml:id= in the list of interview participants.

<pre>
<list type="simple">
<head>Interview Participants</head>
<item>
<name xml:id="spk1" key="wf" reg="Friday, William C." type="interviewee">WILLIAM C. FRIDAY
</name>, interviewee
</item>
<item>
<name xml:id="spk2" key="wl" reg="Link, William" type="interviewer">WILLIAM LINK</name>, interviewer
</item>
</list>

[. . . ]

<sp who="spk2">
<speaker n="2">WILLIAM LINK:</speaker>
Last time we were talking about Frank Porter Graham. And I have a couple of questions
about Graham, and I wonder if you could clear them up for me. You have mentioned that you
had worked with him as a student at North Carolina State, had you met him before?

</sp>
<sp who="spk1">
<speaker n="1">WILLIAM C. FRIDAY: </speaker>
No. That budget hearing was the first that I knew of him, of course, but the first time that I ever encountered him. I was president of class at N.C. State, and that through me into this kind of public adventure. And so I went merrily on downtown and sat there in the budget hearing, along with the president of the student body, and some others.

</sp>
</pre>

* One of the approaches to synchronize audio and transcript has been introduced in [http://docsouth.unc.edu/sohp/ Oral Histories of the American South"], using [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-milestone.html <milestone>] with a timestamp attribute:
<pre>
<milestone n="7248" unit="empty" type="stop" timestamp="00:08:54"/>
</pre>

=====Level 4 Verse=====
['''Matthew G.''' will work on this section]
*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.
*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="******"/>. *<l> It is recommended that indentation be recorded and that the rend attribute be used to do this.

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

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

====Level 5 Examples====

=====Lemmatization and Thematic Keyword Tagging from the Swinburne Project=====

<pre>
<lg>
<l n="67"><w lemma="high">High</w>
<w lemma="thing">things</w>
<seg type="keyword" xml:id="ke39" corresp="#kw-song"><w lemma="the">the</w>
<w lemma="high">high</w>
<w lemma="song">song</w></seg>
<w lemma="teach">taught</w>
<w lemma="he">him</w>; <w lemma="how">how</w>
<w lemma="the">the</w>
<w lemma="breath">breath</w></l>
<l n="68"><w lemma="too">Too</w>
<w lemma="frail">frail</w>
<w lemma="for">for</w>
<w lemma="life">life</w>
<w lemma="may">may</w>
<w lemma="be">be</w>
<w lemma="more">more</w>
<w lemma="strong">strong</w>
<w lemma="than">than</w>
<w lemma="death">death</w>;</l>
<l n="69"><w lemma="and">And</w>
<w lemma="this">this</w>
<w lemma="poor">poor</w>
<w lemma="flash">flash</w>
<w lemma="of">of</w>
<w lemma="sense">sense</w>
<w lemma="in">in</w>
<w lemma="life">life</w>, <w lemma="that">that</w>
<w lemma="gleam">gleams</w></l>
</lg>
</pre>

==General Guidelines for Attribute Usage==

Some general advice on the use of particular attributes
follows.
<ul>
<li>type=: 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 and that this list be made available to people
using the texts. It is worth noting that, at present, [http://www.tei-c.org/Roma/ Roma], the web front-end editor for ODD files, does not have a mechanism for providing this documentation — it should be added to the ODD file directly. For
a list of standard names and definitions of bibliographic
features of printed books, see ABC for Book Collectors by John
Carter (8th edition, New Castle, Del. and London: Oak Knoll Books and the British Library, 2004, available online at http://www.ilab.org/images/abcforbookcollectors.pdf). 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. Example: <tt><div1 type="volume"></tt></li>

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

<li>xml:id=: 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 <tt>@xml:id</tt>
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. Example: <tt><note xml:id="n5" n="5"></tt></li>

<li>target=: A URI. May be used to point internally within the same document by preceding the value of the target element's <tt>@xml:id</tt> with a number sign (U+0023). E.g., in the case of footnotes where
the <tt><anchor xml:id="n5" n="5"></tt> is at a specific place in the
text and is referred to by the <tt><note target="#n5" n="5"></tt>
which contains the actual content of the footnote itself
elsewhere.</li>
<li>rend=: Difficulty using <tt>rend=</tt> 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 <tt>rend=</tt> value. Rendition
ladders consist of categories of renditional features with values of each of those features
enclosed in parentheses. rend= should only be used to override a default value. For
instance, if all text encoded as <tt><hi></tt> is defined as being rendered in italics,
there is no reason to encode text as <tt><hi rend="slant(italics)"></tt> Combining
renditional features would result in an element with attributes such as <tt><l
rend="slant(italics)align(right)"></tt>
{| border="1"
|-
! keyword
! some possible values
|-
| <tt>slant</tt>
| <tt>italics</tt> or <tt>upright</tt>
|-
| <tt>weight</tt>
| <tt>bold</tt> or <tt>normal</tt>
|-
| <tt>case</tt>
| <tt>allcaps</tt> or <tt>lower</tt> or <tt>smallcaps</tt> or <tt>upper</tt> or <tt>mixed</tt>
|-
| <tt>align</tt>
| <tt>left</tt> or <tt>right</tt> or <tt>center</tt> or <tt>centre</tt> or <tt>inside</tt> or <tt>outside</tt> or <tt>none</tt>
|-
| <tt>indent</tt>
| a number
|}
</li>
<li>xml:lang=: Used to indicate the natural language of the content of an element. Generally not used at levels 1 or 2. At levels 3 or 4 should contain the appropriate language subtag; further subtags (script, region, variant, extension, private use) are rarely appropriate. If only the language subtag is present (the most common case), a corresponding <tt><language></tt> element should '''not''' be present in the TEI header. If a private use subtag is present, a corresponding <tt><language></tt> element must be present in the TEI header. See [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-data.language.html the TEI documentation].</li>
</ul>

==Acknowledgements==
This document is the result of a group of individuals with a range of experience with TEI text encoding, which formed together under the TEI Special Interest Group on Libraries and Digital Library Federation umbrellas. We would like to thank and acknowledge all of those who have given their time and expertise to develop these best practices.

The individuals who have contributed to the writing of this document are:

* Syd Bauman, Brown University
* Michelle Dalmau, Indiana University
* Matthew Gibson, University of Virginia
* Kevin Hawkins, University of Michigan
* Lisa McAulay, University of California, Los Angeles
* Melanie Schlosser, Ohio State University
* Natasha Smith, University of North Carolina, Chapel Hill
* Richard Wisneski, Case Western University

The individuals who have contributed to the planning of this document are:

* Syd Bauman, Brown University
* Michelle Dalmau, Indiana University
* Matthew Gibson, University of Virginia
* Kevin Hawkins, University of Michigan
* Lisa McAulay, University of California, Los Angeles
* Chris Powell, University of Michigan
* Andrew Rouner, Washington University in St. Louis
* Melanie Schlosser, Ohio State University
* Natasha Smith, University of North Carolina, Chapel Hill
* Perry Willett, California Digital Library
* Richard Wisneski, Case Western University
* Glen Worthey, Stanford University

Lastly, we would like to thank the Digital Library Federation (DLF) for sponsoring two in-person meetings as part of the Spring 2008 Forum in Minneapolis, Minnesota and the Spring 2009 Forum in Raleigh, North Carolina in support of our revision work. The DLF also provided teleconferencing support for our regularly scheduled meetings.

==Appendix A: History of this Document==
The Text Encoding Initiative Guidelines for Electronic Text Encoding and Interchange (referred to as
the TEI Guidelines) 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.

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 TEI Guidelines 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 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 section on the header is based on a draft of those recommended practices. It was submitted to various constituencies for
comment. In 2008 and 2009, it was heavily revised by Melanie Schlosser, Kevin Hawkins, and other members of the TEI SIG on Libraries.

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:

<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>
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 TEI in Libraries
Guidelines). 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.

Written in 1998, this first iteration of TEI in Libraries Guidelines 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 TEI in Libraries Guidelines
required substantial revision. In 2002, the TEI Consortium published a new edition of the complete
TEI Guidelines that conformed to XML specifications. In order to remain useful, the TEI in
Libraries Guidelines had to be updated to reflect these developments.

Furthermore, librarians need more guidance than the original TEI in Libraries Guidelines
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.

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.

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.: 
<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>
These representatives met to revise the original TEI in Libraries Guidelines in order
that they: 
<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>
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: 
<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>Chris Powell, The University of Michigan</li>
<li>Merrilee Proffitt, RLG</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>

[[Category:SIG:Libraries]]

Minutes for March 24, 2009

2009-03-24T17:49:13Z

Pwillett: New page: TEI in Libraries conf call 3/24/09 Kevin Hawkins (co-chair), Melanie Schlosser, Chris Powell, Natasha Smith, Perry Willett (notes), Rich Wisneski, Glen Worthy * Header: only outstanding ...

TEI in Libraries conf call 3/24/09

Kevin Hawkins (co-chair), Melanie Schlosser, Chris Powell, Natasha Smith, Perry Willett (notes), Rich Wisneski, Glen Worthy

* Header: only outstanding issue concerns how to link to outside metadata. We hope Syd has an idea. KH, MS and RW will keep on this.

* Linking to page images: we don't explicitly address this issue. We need to include section on new PB attribute "facs" in P5

* Level 1: KH will substitute new text as example; one that includes running heads and other (unencoded) features

* Level 2: figure and graphic elements are out of place in the example and should be removed

* Level 3: example is fine (NS)

* Level 4: example is fine? NS would be happy to hear from anyone who's looked at this closely. MG has added section on drama; NS has worked on section on oral history and thinks is pretty much done.

* Level 5: GW will add example. Should name encoding belong in level 4 or 5? need to decide. Michelle?

* Finish revisions to BPG by April 7.

* Still plan to meet at DLF on Wed from 1-5ish. Room TBA.

* Next call is scheduled for April 14. Should we reschedule for 4/7?

Minutes for March 10, 2009

2009-03-10T17:55:06Z

Pwillett: New page: TEI conf call 3/10/09 Michelle Dalmau (co-chair), Kevin Hawkins (co-chair), Melanie Schlosser, Perry Willett (notes), Rich Wisneski, Glen Worthy * Recommend using external pointers to no...

TEI conf call 3/10/09

Michelle Dalmau (co-chair), Kevin Hawkins (co-chair), Melanie Schlosser, Perry Willett (notes), Rich Wisneski, Glen Worthy

* Recommend using external pointers to non-MARC and other metadata rather than include in header.
** What's the mechanism?
** Is there a global attribute available: uri? xmlbase?
** Can there be some description about what is being pointed to (e.g. collection of MODS records for journal issue)?
* We tabled the page break discussion. Syd was the main proponent for making a change.
* FW forme work: Should we include in BPG? KH will follow up with Paul Schaffner (Text Creation Partnership) and Chris Powell. TCP uses FW, and Chris has some experience in promoting texts from level 1 to 4. Was content (such as running head) stripped out or something else done with it?
* Name tagging: we recommended that people use external authority files. They will be easier to maintain than inline <choice> content. MD will propose some explicit examples.
* Header section is almost complete. Everyone should look at it again. There is a column in the element table for MARC equivalent. The first version of the header BPG included equivalences, but it hasn’t been looked at in 10 years. KH will look at those, and MD will call on some catalogers who attended a TEI training workshop. We will revisit after DLF.
* MD reported that Level 3 is almost finished. She will send out an email to the list asking everyone on the working group to look at it again.

SIG:Libraries

2009-03-10T17:53:55Z

Pwillett:

Convenors: Michelle Dalmau and Kevin Hawkins

The goal of the TEI Special Interest Group on Libraries is to discuss topics regarding the use of TEI in libraries, including the creation of guidelines and best practices that encourage the consistent and predictable encoding of TEI documents. Greater consistency and predictability will facilitate the interchange of documents, interoperability of systems, and the creation of standard tools for libraries to use in the creation and publication of TEI documents.

It will do this by:
* Updating and improving the current TEI Text Encoding in Libraries: Guidelines for Best Practices, available at http://www.diglib.org/standards/tei.htm.
* Creation of standard XSL style sheets for use.
* Exploring the use of other metadata standards commonly in use in libraries, such as METS, MODS, EAD, MARC, in conjunction with TEI documents
* Guides to implementing TEI collections that follow the best practices guidelines, using open source digital library software such as Greenstone.
* Other items as they occur to us.

(from [http://www.tei-c.org/Activities/SIG/Libraries/index.xml TEI in Libraries SIG web page])

==Join the List==
* [https://listserv.indiana.edu/cgi-bin/wa-iub.exe?SUBED1=teilib-l&A=1 Join the TEILIB-L] list to participate in discussions, post questions or just to stay informed.

==Meetings==
* TEI in Libraries Joint Meeting with DLF and SIG, May 6, 2009
** [[Registration, May 6, 2009]]
* Best Practices Conference Call, March 10, 2009
** [[Agenda for March 10, 2009]]
** [[Minutes for March 10, 2009]]
* Header Conference Call, March 3, 2009
** [[Agenda for March 3, 2009]]
** [[Minutes from March 3, 2009]]
* Best Practices Conference Call, February 24, 2009
** [[Agenda for and Notes of February 24, 2009]]
* Header Conference Call, February 17, 2009
** [[Talk:TEI_in_Libraries:_Guidelines_for_Best_Practices#The_TEI_Header|Agenda for February 17, 2009]]
** [[Minutes from February 17, 2009]]
* Best Practices Conference Call, February 10, 2009
** [[Agenda for February 10, 2009]]
** [[Minutes from February 10, 2009]]
* Best Practices Conference Call, January 27, 2009
** [[Minutes from January 27, 2009]]
* Best Practices Conference Call, December 2, 2008
** [[Agenda for December 2, 2008]]
** [[Minutes from December 2, 2008]]
* TEI Members' Meeting, Libraries SIG, November 8, 2008
** [[Agenda for November 8, 2008]]
** [[Minutes from November 8, 2008]]
* Conference call of members of the April 2008 group
** [[Agenda for September 30, 2008]]
** [[Minutes from September 30, 2008]]
* TEI in Libraries Joint Meeting with DLF and SIG, April 28, 2008
** [[Registration]]
** [[Invitation and Agenda]]
** [[Minutes from April 28, 2008]]
* TEI Members' Meeting, Libraires SIG, November 3, 2007
** [[Agenda for November 3, 2007]]
** [[Minutes from November 3, 2007]]

==Working Groups==
* [[TEI in Libraries: Guidelines for Best Practices Working Group]]

==Documentation==
* [[TEI in Libraries: Guidelines for Best Practices]]
** [[Syd Bauman's comments on Guidelines]] (from Mar. 22 2006)
** [[TEI Header]] (Work in progress)
** [[Review of Levels for Best Practices]]
* [[TEI Tite]] (Issues under investigation)
** [[Review of Tite Scheme]]

[[Category:SIG|Libraries]]
[[Category:SIG:Libraries|!]]

Registration, May 6, 2009

2009-03-06T23:20:04Z

Pwillett:

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

== TEI in Libraries Joint Meeting, Digital Library Federation Spring 2009 Forum ==

[http://www.diglib.org/forums/spring2009/ DLF Spring 2009 Forum] 
Raleigh, North Carolina 
Monday, May 4th – Wednesday, May 6th
 
'''Meeting Details''' 
Date/Time: Wednesday, May 6th, Time TBD 
Room: TBD 
----

The TEI in Libraries Joint Meeting with members of the TEI DLF Task Force and the TEI in Libraries Special Interest Group is sponsored by the Digital Library Federation. Participation in the meeting is open to members of the [http://wiki.tei-c.org/index.php/TEI_in_Libraries:_Guidelines_for_Best_Practices_Working_Group Guidelines for Best Practices Working Group], and additional people interested in participating in the GBP Working Group. Attendance must be capped at 20. Non-DLF members participating in the meeting are welcome to attend the Spring 2009 Forum.

----

 

{| border="1" cellpadding="2"
!width="25%"|Name
!width="25%"|Affiliation
!width="15%"|Email
!width="10%"|DLF Member
!width="10%"|Attending DLF
|-
|Michelle Dalmau || Indiana University || mdalmau@indiana.edu || Yes || Yes
|-
|Matthew Gibson || University of Virginia || msg2d@virginia.edu || Yes || ?
|-
|Kevin Hawkins || University of Michigan || kevin.s.hawkins#ultraslavonic.info || Yes || Yes
|-
|Glen Worthey || Stanford University Libraries || gworthey@stanford.edu || Yes || Yes
|-
|Perry Willett || CDL || Perry.Willett@ucop.edu || Yes || Nope
|-
|Lisa McAulay || UCLA || emcaulay@library.ucla.edu || Yes || ?
|-
|Andrew Rouner || Washington University || arouner@wustl.edu || Yes || ?
|-
|Natasha Smith ||University of North Carolina at Chapel Hill || nsmith@email.unc.edu || No || Yes
|-
|Chris Powell ||University of Michigan|| sooty@umich.edu || Yes || ?
|-
|Melanie Schlosser ||The Ohio State University|| schlosser.40@osu.edu || No || Yes
|-
|Syd Bauman ||Brown University|| Syd_Bauman@brown.edu || No || ?
|-
|Rich Wisneski ||Case Western|| rlw54@case.edu || No || ?
|-
|David Seaman ||Dartmouth|| David.Seaman@dartmouth.edu || Yes || ?
|}

Registration, May 6, 2009

2009-03-02T20:50:16Z

Pwillett:

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

== TEI in Libraries Joint Meeting, Digital Library Federation Spring 2009 Forum ==

[http://www.diglib.org/forums/spring2009/ DLF Spring 2009 Forum] 
Raleigh, North Carolina 
Monday, May 4th – Wednesday, May 6th
 
'''Meeting Details''' 
Date/Time: Wednesday, May 6th, Time TBD 
Room: TBD 
----

The TEI in Libraries Joint Meeting with members of the TEI DLF Task Force and the TEI in Libraries Special Interest Group is sponsored by the Digital Library Federation. Participation in the meeting is open to members of the [http://wiki.tei-c.org/index.php/TEI_in_Libraries:_Guidelines_for_Best_Practices_Working_Group Guidelines for Best Practices Working Group], and additional people interested in participating in the GBP Working Group. Attendance must be capped at 20. Non-DLF members participating in the meeting are welcome to attend the Spring 2009 Forum.

----

 

{| border="1" cellpadding="2"
!width="25%"|Name
!width="25%"|Affiliation
!width="15%"|Email
!width="10%"|DLF Member
!width="10%"|Attending DLF
|-
|Michelle Dalmau || Indiana University || mdalmau@indiana.edu || Yes || Yes
|-
|Matthew Gibson || University of Virginia || msg2d@virginia.edu || Yes || ?
|-
|Kevin Hawkins || University of Michigan || kevin.s.hawkins#ultraslavonic.info || Yes || Yes
|-
|Glen Worthey || Stanford University Libraries || gworthey@stanford.edu || Yes || Yes
|-
|Perry Willett || CDL || Perry.Willett@ucop.edu || Yes || ?
|-
|Lisa McAulay || UCLA || emcaulay@library.ucla.edu || Yes || ?
|-
|Andrew Rouner || Washington University || arouner@wustl.edu || Yes || ?
|-
|Natasha Smith ||University of North Carolina at Chapel Hill || nsmith@email.unc.edu || No || Yes
|-
|Chris Powell ||University of Michigan|| sooty@umich.edu || Yes || ?
|-
|Melanie Schlosser ||The Ohio State University|| schlosser.40@osu.edu || No || Yes
|-
|Syd Bauman ||Brown University|| Syd_Bauman@brown.edu || No || ?
|-
|Rich Wisneski ||Case Western|| rlw54@case.edu || No || ?
|-
|David Seaman ||Dartmouth|| David.Seaman@dartmouth.edu || Yes || ?
|}

Registration, May 6, 2009

2009-03-02T20:49:57Z

Pwillett:

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

== TEI in Libraries Joint Meeting, Digital Library Federation Spring 2009 Forum ==

[http://www.diglib.org/forums/spring2009/ DLF Spring 2009 Forum] 
Raleigh, North Carolina 
Monday, May 4th – Wednesday, May 6th
 
'''Meeting Details''' 
Date/Time: Wednesday, May 6th, Time TBD 
Room: TBD 
----

The TEI in Libraries Joint Meeting with members of the TEI DLF Task Force and the TEI in Libraries Special Interest Group is sponsored by the Digital Library Federation. Participation in the meeting is open to members of the [http://wiki.tei-c.org/index.php/TEI_in_Libraries:_Guidelines_for_Best_Practices_Working_Group Guidelines for Best Practices Working Group], and additional people interested in participating in the GBP Working Group. Attendance must be capped at 20. Non-DLF members participating in the meeting are welcome to attend the Spring 2009 Forum.

----

 

{| border="1" cellpadding="2"
!width="25%"|Name
!width="25%"|Affiliation
!width="15%"|Email
!width="10%"|DLF Member
!width="10%"|Attending DLF
|-
|Michelle Dalmau || Indiana University || mdalmau@indiana.edu || Yes || Yes
|-
|Matthew Gibson || University of Virginia || msg2d@virginia.edu || Yes || ?
|-
|Kevin Hawkins || University of Michigan || kevin.s.hawkins#ultraslavonic.info || Yes || Yes
|-
|Glen Worthey || Stanford University Libraries || gworthey@stanford.edu || Yes || Yes
|-
|Perry Willett || CDL || Perry.Willett@ucop.edu || Yes || mebbe
|-
|Lisa McAulay || UCLA || emcaulay@library.ucla.edu || Yes || ?
|-
|Andrew Rouner || Washington University || arouner@wustl.edu || Yes || ?
|-
|Natasha Smith ||University of North Carolina at Chapel Hill || nsmith@email.unc.edu || No || Yes
|-
|Chris Powell ||University of Michigan|| sooty@umich.edu || Yes || ?
|-
|Melanie Schlosser ||The Ohio State University|| schlosser.40@osu.edu || No || Yes
|-
|Syd Bauman ||Brown University|| Syd_Bauman@brown.edu || No || ?
|-
|Rich Wisneski ||Case Western|| rlw54@case.edu || No || ?
|-
|David Seaman ||Dartmouth|| David.Seaman@dartmouth.edu || Yes || ?
|}

Talk:Best Practices for TEI in Libraries

2009-02-10T00:39:21Z

Pwillett: /* Numbered Divs (resolved on 2009-01-27) */

Some comments for TEI Header Guidelines

* You probably want to change the @id in a few places to @xml:id. And the examples have TEI.2 as the root. [[User:Piotr Banski|Piotr]] 22:48, 19 October 2008 (EDT)

Yes, at some point soon we will need to change
* id= to xml:id=
* <TEI.2> to <TEI xmlns=...>
* target="blah" to target="#blah"
passim. Will also need to ditch the bit on entities. Maybe I can get to these later today. — done.

We also need to figure out what to do about the recommendation for lang=. That's a tougher issue, because it's not just a syntax change. Our guildelines for best practice are at odds with the TEI Guidelines and the IETF best current practices. [[User:Syd|Syd]] 2008-10-21T19:09Z.

== Referencing the P5 Guidelines ==

I think when ever possible, we should link to the P5 guidelines to further illustrate examples or even as additional reference to prose. These guidelines mention "text hierarchy" which is akin to structure of a text so we should link to Chapter 4, Default Text Structure for illustrations of the various forms, etc. Not only do we leverage existing, robust documentation, but we help all TEI users, novice or expert, "penetrate" the monolithic guidelines when relevant. [[User:Mdalmau|Mdalmau]]

agreed. [[user:emcaulay|emcaulay]]

== Issues Pending ==

===General Recommendations section ===

==== To do ====
* Link to corresponding sections of the P5 Guidelines when ever possible (for each recommendation)

==== Filenaming ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====

{snippet from BPG text; comments about file naming}
[This recommendation also seems dated (and the standard is targeted for CD-ROM file naming). I think we should
recommend a consistency in file naming according to respective digital object storage practices. For example, [http://wiki.dlib.indiana.edu/confluence/x/Sw8 IUDLP has guidelines in place] and perhaps we can mine the more general recommendations from there like only ASCII, no spaces, 3 letter extensions, etc. ([[User:Mdalmau|Mdalmau]])] sounds like a good idea to remove or revise; as is it seems weird. ([[User:emcaulay|emcaulay]])
I'll just point out that people still use CD-ROM as an archival storage medium (I'm looking at you, Chris) as well as a file transfer mechanism [pwillettt]
{end snippet}

The question isn’t is anyone still using CD-ROM, lots of folks probably do. The question is, is anyone still using ISO 9660 (as opposed to UDF, ECMA-168, or ISO 13490) CD-ROMs '''whithout''' using Rock Ridge or Joliet extensions. Anyone even know how to do that? -- [[User:Syd|Syd]]

File naming is still an issue. Perry pointed out that some folks store TEI files on CD-Rom (makes sense). Perhaps it just needs to be teased out for those who use CD-ROM for storage and more general filenmaing guidelines for server storage/delivery, like:

Standardized file naming for a particular encoding project is key for reliable online storage and delivery of these files. Consider the following best practices when determining the file name scheme for your project:

* Each filename should contain an identifier that uniquely specifies a single digital object within the parent collection (e.g., a parent collection of text, images and other related materials)
* Each filename should be fully specified. It should not just be a sequence number that is dependent on location within a directory structure for context
* Filenames should not include spaces
* Filenames should following a predicatble case constructions (e.g., all lowercase, camelCase, etc.)
* The first character of the filename should be an ASCII letter ('a' through 'z' or 'A' through 'Z') to comply with current restrictions on identifiers by many programming and metadata languages such as METS
* The "base" filename may include only ASCII letters ('a' through 'z' and 'A' through 'Z'), ASCII digits ('0' through '9'), hyphens, underscores, and periods. Refrain from using other characters and limit period usage to only once (to separate base name from file extensions).

For those saving files to CD-ROM for storage or file transfer, file naming should follow ISO 9660 conventions: 8-character filenames, 3-character extensions, using A-Z, a-z, 0-9, underscores and hyphens.

([[User:Mdalmau|Mdalmau]])

While I actually think my recommendation of 2008-12-03T11:57-05 (“I was wrong”) is syntactically slightly superior, it’s time to apply ''Syd’s wheel reinvention prevention convention'' in full force. The conventions MD refers to above (i.e., [http://wiki.dlib.indiana.edu/confluence/x/Sw8 IUDLP has guidelines in place]) are perfectly workable. We should just refer the reader there and be done with it. [[User:Syd|Syd]]

I did steal these from the IU DLP guidelines, but I was selective because there's a lot of "Fedora" construct influencing our filenaming conventions. Wouldn't want the users to go there and feel overwhelmed. I selected the more "basic" factors for consideration, but certainly a pointer to DLP documentation or anywhere else could be helpful (as a footnote?). ([[User:Mdalmau|Mdalmau]])

I hate to throw another comment into the mix on this issue, but I seem to recall reading somewhere that underscores are now discouraged in file naming, because they can be mistaken for blank spaces between words. If this is incorrect, my apologies. [[User:rwisnesk|rwisnesk]]

: It's true about underscores: http://www.education.umd.edu/ETS/web/webNamingConventionRP.html .

==== Numbered Divs ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====

[This seems worth revisiting. Do we really need such a software-specific recommendation? ([[User:Kshawkin|Kshawkin]])]
[I agree. We generally avoid numbered divisions. Recent survey revealed a nearly 50/50 split on the topic, but we shouldn't advocate one or the other. ([[User:Mdalmau|Mdalmau]])] I disagree pretty strongly — many perceive it a shortcoming of the TEI Guidelines that they often offer more than one way to do something when there is not much gain in the difference. For our purposes, I think this is one of those cases, and we should avoid causing the same confusion. We should pick either numbered or unnumbered and stick with it throughout. (And I don't think it matters much which we pick.) — [[User:Syd|Syd]] For a discussion of whether to use numbered or unnumbered divs, see the TEI P5 Guidelines [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html#DSDIV3 Chapter 4: Default Text Structure]([[User:emcaulay|emcaulay]]) 
I'm not sure when Syd added his comment--before or after the conference call? We did pick one for the original best practices but there has been significant unhappiness about that decision ever since. As Michelle points out, the community out there is split 50-50. It's not a disagreement that's going away.([[User:Pwillett|Pwillett]] 19:37, 9 February 2009 (EST))
I just now see the "resolved" banner above, so ignore my comments just above. ([[User:Pwillett|Pwillett]] 19:38, 9 February 2009 (EST))

Chapter 4 of the P5 Guidelines make allowances for both, with a preference towards unnumbered as it more easily suports arbitrary levels of nesting (as opposed to a fixed number). Unnumbered is also preferred because designated levels to parts of a text may change from project to project or even book to book within the same project. The guidelines make allowances for both: unnumbered divisions using the @type to designate the level. For those who type more semantically and for those who need numbered divisions for more predictable processing how about we re-write the section thusly:

We recommend the use of unnumbered divisions throughout the electronic text with proper values inserted in the @type attribute. For those of you who require numbered divisions for software processing, populate the @ type attribute with a number, 1-7 (?), that corresponds to the appropriate level. For those of you who prefer a semantic label (e.g., chapter, section, etc.), determine a typology beforehand and designate the appropriate level in the @type attribute. The ability to do both is also possible if it is important to maintain an explicit connection between the numbered and unnumbered labels by using @ type and @subtype accordingly. However, a combination of numbered (e.g., <div1>) and unnumbered (e.g,, <div>) divisions is not supported. For a more detailed discussion about numbered and unnumbered divisions, consult [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html#DSDIV3 Chapter 4: Default Test Structure] of the TEI P5 Guidelines. ([[User:Mdalmau|Mdalmau]])

This revision may impact how we display examples throughout the text. We need to keep this in mind if accepted. [Mdalmau].

The construction of "typologies" is a common activity for many of us when performing document analysis. When we are ready to expand the guidelines, I think including a section on "document analysis" is key. We can then explore issues of typology-building and how to constrain those values in the schema (or even Schematron). But defining the value list is not an easy task, which is one benefit of using numbered divs. ([[User:Mdalmau|Mdalmau]])

Using type= to mimick numbered <div>s seems too close to tag abuse for comfort. I completely agree that typologies are part of document analysis and enthusiastically support having a section on that. But I don't see how using numbered <div>s has anything to do with it. A project '''should''' develop a useful typology whether they are using numbered or unnumbered. Many projects ''won’t'', anyway.

Would this wording be one possible compromise: Use unnumbered divisions <div>, unless your text has obvious divisions, such as chapters with no complex subdivisions, in which case begin with <div1>([[User:rwisnesk|rwisnesk]])

====Page Breaks ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====

[Always including page breaks within a div seems quite software-specific. I suggest revisiting. ([[User:Kshawkin|Kshawkin]])]
As we've discussed on a conference call, this isn't software specific. There are two points here. The historical point is that we wanted to recommend a practice, as a way of creating consistency and uniformity among encoded documents. There's a choice to be made about where to stick page breaks, so we chose one. But more importantly, it's about any software (eg XSLT) that will grab and return an entire DIV. You'll want to include the page break in that chunck of encoded text. In my experience, this generally works, except at the beginning of the volume, which typically would have <TEXT><BODY><PB><HEAD>Book Title</HEAD><DIV><HEAD>Chapter title</HEAD> [pwillett]

It seems that the page break blurb we have in place is not really an issue that needs to be revisited. I agree with Perry that promoting consistency is helpful (and also aids processing of text in most cases; page breaks as are all milestone tags, are hard to reckon with sometimes). The suggestion seems neutral enough that it can remain as-is. If someone disagrees, please provide the rational for further review. Thanks!([[User:Mdalmau|Mdalmau]])

While I am, of course, willing to be outvoted, this strikes me as less than a Best Practice, for both theorhetical and practical reasons.

Theorhetically, I think, as Snoopy said, “honesty is the best policy”. In general in these cases, the page break does '''not''' occur inside a division, it occurs between them. To encode it otherwise seems to me to be asking for trouble.

Practically, this recommendation favors <div> above all others. For any other element, if you wanted to know “on what page did this occur”, you would ask the question “What is the value of n= of the most recent <pb> on the preceding:: axis?”. This works for <quote>s, <said>s, <lg>s, <head>s, etc. If page breaks are encoded where they lie, it works for <div>, too. If they are moved into the division as per this recommendation, then a different question has to be asked: “What is the value of n= of my first child <pb>?”. Neither question is difficult to ask. But how do you know which to ask? [[User:Syd|—Syd]]

===Level 1 section===

====Paragraphs or Anonymous Block ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====
Currently, level 1 contains a table with the following information for the tag:

At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using in order that the document be open to being extended to other encoding levels).I don't remember this discussion. It doesn't seem very difficult, once the decision is made to upgrade, to transform all ab's to p's. Or? [pwillett]


I agree with Perry and our goal is be conformant. So the could simply be changed to <ab>. Do we want to address the legacy any further or maybe as an end note?
([[User:Mdalmau|Mdalmau]])

Talk:Best Practices for TEI in Libraries

2009-02-10T00:38:39Z

Pwillett: /* Numbered Divs (resolved on 2009-01-27) */

Some comments for TEI Header Guidelines

* You probably want to change the @id in a few places to @xml:id. And the examples have TEI.2 as the root. [[User:Piotr Banski|Piotr]] 22:48, 19 October 2008 (EDT)

Yes, at some point soon we will need to change
* id= to xml:id=
* <TEI.2> to <TEI xmlns=...>
* target="blah" to target="#blah"
passim. Will also need to ditch the bit on entities. Maybe I can get to these later today. — done.

We also need to figure out what to do about the recommendation for lang=. That's a tougher issue, because it's not just a syntax change. Our guildelines for best practice are at odds with the TEI Guidelines and the IETF best current practices. [[User:Syd|Syd]] 2008-10-21T19:09Z.

== Referencing the P5 Guidelines ==

I think when ever possible, we should link to the P5 guidelines to further illustrate examples or even as additional reference to prose. These guidelines mention "text hierarchy" which is akin to structure of a text so we should link to Chapter 4, Default Text Structure for illustrations of the various forms, etc. Not only do we leverage existing, robust documentation, but we help all TEI users, novice or expert, "penetrate" the monolithic guidelines when relevant. [[User:Mdalmau|Mdalmau]]

agreed. [[user:emcaulay|emcaulay]]

== Issues Pending ==

===General Recommendations section ===

==== To do ====
* Link to corresponding sections of the P5 Guidelines when ever possible (for each recommendation)

==== Filenaming ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====

{snippet from BPG text; comments about file naming}
[This recommendation also seems dated (and the standard is targeted for CD-ROM file naming). I think we should
recommend a consistency in file naming according to respective digital object storage practices. For example, [http://wiki.dlib.indiana.edu/confluence/x/Sw8 IUDLP has guidelines in place] and perhaps we can mine the more general recommendations from there like only ASCII, no spaces, 3 letter extensions, etc. ([[User:Mdalmau|Mdalmau]])] sounds like a good idea to remove or revise; as is it seems weird. ([[User:emcaulay|emcaulay]])
I'll just point out that people still use CD-ROM as an archival storage medium (I'm looking at you, Chris) as well as a file transfer mechanism [pwillettt]
{end snippet}

The question isn’t is anyone still using CD-ROM, lots of folks probably do. The question is, is anyone still using ISO 9660 (as opposed to UDF, ECMA-168, or ISO 13490) CD-ROMs '''whithout''' using Rock Ridge or Joliet extensions. Anyone even know how to do that? -- [[User:Syd|Syd]]

File naming is still an issue. Perry pointed out that some folks store TEI files on CD-Rom (makes sense). Perhaps it just needs to be teased out for those who use CD-ROM for storage and more general filenmaing guidelines for server storage/delivery, like:

Standardized file naming for a particular encoding project is key for reliable online storage and delivery of these files. Consider the following best practices when determining the file name scheme for your project:

* Each filename should contain an identifier that uniquely specifies a single digital object within the parent collection (e.g., a parent collection of text, images and other related materials)
* Each filename should be fully specified. It should not just be a sequence number that is dependent on location within a directory structure for context
* Filenames should not include spaces
* Filenames should following a predicatble case constructions (e.g., all lowercase, camelCase, etc.)
* The first character of the filename should be an ASCII letter ('a' through 'z' or 'A' through 'Z') to comply with current restrictions on identifiers by many programming and metadata languages such as METS
* The "base" filename may include only ASCII letters ('a' through 'z' and 'A' through 'Z'), ASCII digits ('0' through '9'), hyphens, underscores, and periods. Refrain from using other characters and limit period usage to only once (to separate base name from file extensions).

For those saving files to CD-ROM for storage or file transfer, file naming should follow ISO 9660 conventions: 8-character filenames, 3-character extensions, using A-Z, a-z, 0-9, underscores and hyphens.

([[User:Mdalmau|Mdalmau]])

While I actually think my recommendation of 2008-12-03T11:57-05 (“I was wrong”) is syntactically slightly superior, it’s time to apply ''Syd’s wheel reinvention prevention convention'' in full force. The conventions MD refers to above (i.e., [http://wiki.dlib.indiana.edu/confluence/x/Sw8 IUDLP has guidelines in place]) are perfectly workable. We should just refer the reader there and be done with it. [[User:Syd|Syd]]

I did steal these from the IU DLP guidelines, but I was selective because there's a lot of "Fedora" construct influencing our filenaming conventions. Wouldn't want the users to go there and feel overwhelmed. I selected the more "basic" factors for consideration, but certainly a pointer to DLP documentation or anywhere else could be helpful (as a footnote?). ([[User:Mdalmau|Mdalmau]])

I hate to throw another comment into the mix on this issue, but I seem to recall reading somewhere that underscores are now discouraged in file naming, because they can be mistaken for blank spaces between words. If this is incorrect, my apologies. [[User:rwisnesk|rwisnesk]]

: It's true about underscores: http://www.education.umd.edu/ETS/web/webNamingConventionRP.html .

==== Numbered Divs ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====

[This seems worth revisiting. Do we really need such a software-specific recommendation? ([[User:Kshawkin|Kshawkin]])]
[I agree. We generally avoid numbered divisions. Recent survey revealed a nearly 50/50 split on the topic, but we shouldn't advocate one or the other. ([[User:Mdalmau|Mdalmau]])] I disagree pretty strongly — many perceive it a shortcoming of the TEI Guidelines that they often offer more than one way to do something when there is not much gain in the difference. For our purposes, I think this is one of those cases, and we should avoid causing the same confusion. We should pick either numbered or unnumbered and stick with it throughout. (And I don't think it matters much which we pick.) — [[User:Syd|Syd]] For a discussion of whether to use numbered or unnumbered divs, see the TEI P5 Guidelines [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html#DSDIV3 Chapter 4: Default Text Structure]([[User:emcaulay|emcaulay]]) 
I'm not sure when Syd added his comment--before or after the conference call? We did pick one for the original best practices but there has been significant unhappiness about that decision ever since. As Michelle points out, the community out there is split 50-50. It's not a disagreement that's going away.([[User:Pwillett|Pwillett]] 19:37, 9 February 2009 (EST))
I just now see the "resolved" banner above, so ignore my comments just above. ([[User:Pwillett|Pwillett]] 19:38, 9 February 2009 (EST))

Chapter 4 of the P5 Guidelines make allowances for both, with a preference towards unnumbered as it more easily suports arbitrary levels of nesting (as opposed to a fixed number). Unnumbered is also preferred because designated levels to parts of a text may change from project to project or even book to book within the same project. The guidelines make allowances for both: unnumbered divisions using the @type to designate the level. For those who type more semantically and for those who need numbered divisions for more predictable processing how about we re-write the section thusly:

We recommend the use of unnumbered divisions throughout the electronic text with proper values inserted in the @type attribute. For those of you who require numbered divisions for software processing, populate the @ type attribute with a number, 1-7 (?), that corresponds to the appropriate level. For those of you who prefer a semantic label (e.g., chapter, section, etc.), determine a typology beforehand and designate the appropriate level in the @type attribute. The ability to do both is also possible if it is important to maintain an explicit connection between the numbered and unnumbered labels by using @ type and @subtype accordingly. However, a combination of numbered (e.g., <div1>) and unnumbered (e.g,, <div>) divisions is not supported. For a more detailed discussion about numbered and unnumbered divisions, consult [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html#DSDIV3 Chapter 4: Default Test Structure] of the TEI P5 Guidelines. ([[User:Mdalmau|Mdalmau]])

This revision may impact how we display examples throughout the text. We need to keep this in mind if accepted. [Mdalmau].

The construction of "typologies" is a common activity for many of us when performing document analysis. When we are ready to expand the guidelines, I think including a section on "document analysis" is key. We can then explore issues of typology-building and how to constrain those values in the schema (or even Schematron). But defining the value list is not an easy task, which is one benefit of using numbered divs. ([[User:Mdalmau|Mdalmau]])

Using type= to mimick numbered <div>s seems too close to tag abuse for comfort. I completely agree that typologies are part of document analysis and enthusiastically support having a section on that. But I don't see how using numbered <div>s has anything to do with it. A project '''should''' develop a useful typology whether they are using numbered or unnumbered. Many projects ''won’t'', anyway.

Would this wording be one possible compromise: Use unnumbered divisions <div>, unless your text has obvious divisions, such as chapters with no complex subdivisions, in which case begin with <div1>([[User:rwisnesk|rwisnesk]])

====Page Breaks ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====

[Always including page breaks within a div seems quite software-specific. I suggest revisiting. ([[User:Kshawkin|Kshawkin]])]
As we've discussed on a conference call, this isn't software specific. There are two points here. The historical point is that we wanted to recommend a practice, as a way of creating consistency and uniformity among encoded documents. There's a choice to be made about where to stick page breaks, so we chose one. But more importantly, it's about any software (eg XSLT) that will grab and return an entire DIV. You'll want to include the page break in that chunck of encoded text. In my experience, this generally works, except at the beginning of the volume, which typically would have <TEXT><BODY><PB><HEAD>Book Title</HEAD><DIV><HEAD>Chapter title</HEAD> [pwillett]

It seems that the page break blurb we have in place is not really an issue that needs to be revisited. I agree with Perry that promoting consistency is helpful (and also aids processing of text in most cases; page breaks as are all milestone tags, are hard to reckon with sometimes). The suggestion seems neutral enough that it can remain as-is. If someone disagrees, please provide the rational for further review. Thanks!([[User:Mdalmau|Mdalmau]])

While I am, of course, willing to be outvoted, this strikes me as less than a Best Practice, for both theorhetical and practical reasons.

Theorhetically, I think, as Snoopy said, “honesty is the best policy”. In general in these cases, the page break does '''not''' occur inside a division, it occurs between them. To encode it otherwise seems to me to be asking for trouble.

Practically, this recommendation favors <div> above all others. For any other element, if you wanted to know “on what page did this occur”, you would ask the question “What is the value of n= of the most recent <pb> on the preceding:: axis?”. This works for <quote>s, <said>s, <lg>s, <head>s, etc. If page breaks are encoded where they lie, it works for <div>, too. If they are moved into the division as per this recommendation, then a different question has to be asked: “What is the value of n= of my first child <pb>?”. Neither question is difficult to ask. But how do you know which to ask? [[User:Syd|—Syd]]

===Level 1 section===

====Paragraphs or Anonymous Block ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====
Currently, level 1 contains a table with the following information for the tag:

At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using in order that the document be open to being extended to other encoding levels).I don't remember this discussion. It doesn't seem very difficult, once the decision is made to upgrade, to transform all ab's to p's. Or? [pwillett]


I agree with Perry and our goal is be conformant. So the could simply be changed to <ab>. Do we want to address the legacy any further or maybe as an end note?
([[User:Mdalmau|Mdalmau]])

Talk:Best Practices for TEI in Libraries

2009-02-10T00:37:25Z

Pwillett: /* Numbered Divs (resolved on 2009-01-27) */

Some comments for TEI Header Guidelines

* You probably want to change the @id in a few places to @xml:id. And the examples have TEI.2 as the root. [[User:Piotr Banski|Piotr]] 22:48, 19 October 2008 (EDT)

Yes, at some point soon we will need to change
* id= to xml:id=
* <TEI.2> to <TEI xmlns=...>
* target="blah" to target="#blah"
passim. Will also need to ditch the bit on entities. Maybe I can get to these later today. — done.

We also need to figure out what to do about the recommendation for lang=. That's a tougher issue, because it's not just a syntax change. Our guildelines for best practice are at odds with the TEI Guidelines and the IETF best current practices. [[User:Syd|Syd]] 2008-10-21T19:09Z.

== Referencing the P5 Guidelines ==

I think when ever possible, we should link to the P5 guidelines to further illustrate examples or even as additional reference to prose. These guidelines mention "text hierarchy" which is akin to structure of a text so we should link to Chapter 4, Default Text Structure for illustrations of the various forms, etc. Not only do we leverage existing, robust documentation, but we help all TEI users, novice or expert, "penetrate" the monolithic guidelines when relevant. [[User:Mdalmau|Mdalmau]]

agreed. [[user:emcaulay|emcaulay]]

== Issues Pending ==

===General Recommendations section ===

==== To do ====
* Link to corresponding sections of the P5 Guidelines when ever possible (for each recommendation)

==== Filenaming ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====

{snippet from BPG text; comments about file naming}
[This recommendation also seems dated (and the standard is targeted for CD-ROM file naming). I think we should
recommend a consistency in file naming according to respective digital object storage practices. For example, [http://wiki.dlib.indiana.edu/confluence/x/Sw8 IUDLP has guidelines in place] and perhaps we can mine the more general recommendations from there like only ASCII, no spaces, 3 letter extensions, etc. ([[User:Mdalmau|Mdalmau]])] sounds like a good idea to remove or revise; as is it seems weird. ([[User:emcaulay|emcaulay]])
I'll just point out that people still use CD-ROM as an archival storage medium (I'm looking at you, Chris) as well as a file transfer mechanism [pwillettt]
{end snippet}

The question isn’t is anyone still using CD-ROM, lots of folks probably do. The question is, is anyone still using ISO 9660 (as opposed to UDF, ECMA-168, or ISO 13490) CD-ROMs '''whithout''' using Rock Ridge or Joliet extensions. Anyone even know how to do that? -- [[User:Syd|Syd]]

File naming is still an issue. Perry pointed out that some folks store TEI files on CD-Rom (makes sense). Perhaps it just needs to be teased out for those who use CD-ROM for storage and more general filenmaing guidelines for server storage/delivery, like:

Standardized file naming for a particular encoding project is key for reliable online storage and delivery of these files. Consider the following best practices when determining the file name scheme for your project:

* Each filename should contain an identifier that uniquely specifies a single digital object within the parent collection (e.g., a parent collection of text, images and other related materials)
* Each filename should be fully specified. It should not just be a sequence number that is dependent on location within a directory structure for context
* Filenames should not include spaces
* Filenames should following a predicatble case constructions (e.g., all lowercase, camelCase, etc.)
* The first character of the filename should be an ASCII letter ('a' through 'z' or 'A' through 'Z') to comply with current restrictions on identifiers by many programming and metadata languages such as METS
* The "base" filename may include only ASCII letters ('a' through 'z' and 'A' through 'Z'), ASCII digits ('0' through '9'), hyphens, underscores, and periods. Refrain from using other characters and limit period usage to only once (to separate base name from file extensions).

For those saving files to CD-ROM for storage or file transfer, file naming should follow ISO 9660 conventions: 8-character filenames, 3-character extensions, using A-Z, a-z, 0-9, underscores and hyphens.

([[User:Mdalmau|Mdalmau]])

While I actually think my recommendation of 2008-12-03T11:57-05 (“I was wrong”) is syntactically slightly superior, it’s time to apply ''Syd’s wheel reinvention prevention convention'' in full force. The conventions MD refers to above (i.e., [http://wiki.dlib.indiana.edu/confluence/x/Sw8 IUDLP has guidelines in place]) are perfectly workable. We should just refer the reader there and be done with it. [[User:Syd|Syd]]

I did steal these from the IU DLP guidelines, but I was selective because there's a lot of "Fedora" construct influencing our filenaming conventions. Wouldn't want the users to go there and feel overwhelmed. I selected the more "basic" factors for consideration, but certainly a pointer to DLP documentation or anywhere else could be helpful (as a footnote?). ([[User:Mdalmau|Mdalmau]])

I hate to throw another comment into the mix on this issue, but I seem to recall reading somewhere that underscores are now discouraged in file naming, because they can be mistaken for blank spaces between words. If this is incorrect, my apologies. [[User:rwisnesk|rwisnesk]]

: It's true about underscores: http://www.education.umd.edu/ETS/web/webNamingConventionRP.html .

==== Numbered Divs ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====

[This seems worth revisiting. Do we really need such a software-specific recommendation? ([[User:Kshawkin|Kshawkin]])]
[I agree. We generally avoid numbered divisions. Recent survey revealed a nearly 50/50 split on the topic, but we shouldn't advocate one or the other. ([[User:Mdalmau|Mdalmau]])] I disagree pretty strongly — many perceive it a shortcoming of the TEI Guidelines that they often offer more than one way to do something when there is not much gain in the difference. For our purposes, I think this is one of those cases, and we should avoid causing the same confusion. We should pick either numbered or unnumbered and stick with it throughout. (And I don't think it matters much which we pick.) — [[User:Syd|Syd]] For a discussion of whether to use numbered or unnumbered divs, see the TEI P5 Guidelines [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html#DSDIV3 Chapter 4: Default Text Structure]([[User:emcaulay|emcaulay]]) 
I'm not sure when Syd added his comment--before or after the conference call? We did pick one for the original best practices but there has been significant unhappiness about that decision ever since. As Michelle points out, the community out there is split 50-50. It's not a disagreement that's going away.([[User:Pwillett|Pwillett]] 19:37, 9 February 2009 (EST))

Chapter 4 of the P5 Guidelines make allowances for both, with a preference towards unnumbered as it more easily suports arbitrary levels of nesting (as opposed to a fixed number). Unnumbered is also preferred because designated levels to parts of a text may change from project to project or even book to book within the same project. The guidelines make allowances for both: unnumbered divisions using the @type to designate the level. For those who type more semantically and for those who need numbered divisions for more predictable processing how about we re-write the section thusly:

We recommend the use of unnumbered divisions throughout the electronic text with proper values inserted in the @type attribute. For those of you who require numbered divisions for software processing, populate the @ type attribute with a number, 1-7 (?), that corresponds to the appropriate level. For those of you who prefer a semantic label (e.g., chapter, section, etc.), determine a typology beforehand and designate the appropriate level in the @type attribute. The ability to do both is also possible if it is important to maintain an explicit connection between the numbered and unnumbered labels by using @ type and @subtype accordingly. However, a combination of numbered (e.g., <div1>) and unnumbered (e.g,, <div>) divisions is not supported. For a more detailed discussion about numbered and unnumbered divisions, consult [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/DS.html#DSDIV3 Chapter 4: Default Test Structure] of the TEI P5 Guidelines. ([[User:Mdalmau|Mdalmau]])

This revision may impact how we display examples throughout the text. We need to keep this in mind if accepted. [Mdalmau].

The construction of "typologies" is a common activity for many of us when performing document analysis. When we are ready to expand the guidelines, I think including a section on "document analysis" is key. We can then explore issues of typology-building and how to constrain those values in the schema (or even Schematron). But defining the value list is not an easy task, which is one benefit of using numbered divs. ([[User:Mdalmau|Mdalmau]])

Using type= to mimick numbered <div>s seems too close to tag abuse for comfort. I completely agree that typologies are part of document analysis and enthusiastically support having a section on that. But I don't see how using numbered <div>s has anything to do with it. A project '''should''' develop a useful typology whether they are using numbered or unnumbered. Many projects ''won’t'', anyway.

Would this wording be one possible compromise: Use unnumbered divisions <div>, unless your text has obvious divisions, such as chapters with no complex subdivisions, in which case begin with <div1>([[User:rwisnesk|rwisnesk]])

====Page Breaks ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====

[Always including page breaks within a div seems quite software-specific. I suggest revisiting. ([[User:Kshawkin|Kshawkin]])]
As we've discussed on a conference call, this isn't software specific. There are two points here. The historical point is that we wanted to recommend a practice, as a way of creating consistency and uniformity among encoded documents. There's a choice to be made about where to stick page breaks, so we chose one. But more importantly, it's about any software (eg XSLT) that will grab and return an entire DIV. You'll want to include the page break in that chunck of encoded text. In my experience, this generally works, except at the beginning of the volume, which typically would have <TEXT><BODY><PB><HEAD>Book Title</HEAD><DIV><HEAD>Chapter title</HEAD> [pwillett]

It seems that the page break blurb we have in place is not really an issue that needs to be revisited. I agree with Perry that promoting consistency is helpful (and also aids processing of text in most cases; page breaks as are all milestone tags, are hard to reckon with sometimes). The suggestion seems neutral enough that it can remain as-is. If someone disagrees, please provide the rational for further review. Thanks!([[User:Mdalmau|Mdalmau]])

While I am, of course, willing to be outvoted, this strikes me as less than a Best Practice, for both theorhetical and practical reasons.

Theorhetically, I think, as Snoopy said, “honesty is the best policy”. In general in these cases, the page break does '''not''' occur inside a division, it occurs between them. To encode it otherwise seems to me to be asking for trouble.

Practically, this recommendation favors <div> above all others. For any other element, if you wanted to know “on what page did this occur”, you would ask the question “What is the value of n= of the most recent <pb> on the preceding:: axis?”. This works for <quote>s, <said>s, <lg>s, <head>s, etc. If page breaks are encoded where they lie, it works for <div>, too. If they are moved into the division as per this recommendation, then a different question has to be asked: “What is the value of n= of my first child <pb>?”. Neither question is difficult to ask. But how do you know which to ask? [[User:Syd|—Syd]]

===Level 1 section===

====Paragraphs or Anonymous Block ([[Minutes_from_January_27%2C_2009|resolved on 2009-01-27]]) ====
Currently, level 1 contains a table with the following information for the tag:

At least one "container" element per div is required (while <ab> is another option for this case, the Task Force suggests using in order that the document be open to being extended to other encoding levels).I don't remember this discussion. It doesn't seem very difficult, once the decision is made to upgrade, to transform all ab's to p's. Or? [pwillett]


I agree with Perry and our goal is be conformant. So the could simply be changed to <ab>. Do we want to address the legacy any further or maybe as an end note?
([[User:Mdalmau|Mdalmau]])

Minutes from January 27, 2009

2009-01-28T17:06:13Z

Pwillett:

Attending: Syd Bauman (notes), Kevin Hawkins (chair), Chris Powell, Melanie Schlosser, Natasha Smith, Rich Wisneski, Perry Willett (notes)

* Header:
** see e-mail sent 2009-01-25 by KH for more details
** everyone should read and response (deadline?)
** The BPG recommends including series title in <sourceDesc> but doesn't mention any other series information. Should we recommend other info like ISSN or series editor?

* Levels
** Level 1: CP: thinks AB is fine.
** Level 2: RW: nothing to report
** Level 3: NS: needs a P5 example
*** discussion of LBs and genesis of Level 3; does anyone have a true example?
** Level 4: Linda Cantara no longer working on this, but Matt Gibson is
** Level 5: same is w/ L4
*** we need to add an example or two, although don't need to go into full detail

* Filenaming:
** agreed to point to or incorporate IUDLP guidelines
** agreed to 8-dot-3 health warning
** question on ".tei" vs ".xml" extension: agreed to use *.xml extension
** agreed that internal consistency is more important than following a particular set of restrictions [I'm going to suggest this become a general recommendation--SB]

* AB vs. P:
** in the pseudo-paras of Level 1 and Level 2 we agreed to AB

* Numbered/unnumbered divs: we agreed that there is no consensus on this issue, and we shouldn't make a recommendation for one over the other. Instead, we should:
** encourage consistency within texts and collections
** describe the reasoning behind choosing one
** describe process of converting one to the other (and provide tools?)
** recommend a place in the header to record the decision
** schema should enforce consistency within text

* PBs
** leave recommendation as is

* meeting at DLF Spring Forum in Raleigh NC (May 4-6)
** KH will check with Barrie about getting a meeting room
** propose a paper/panel about it?

* People should remove comments from BPG if they feel the issue has been resolved. KH will oversee the process.

Minutes from January 27, 2009

2009-01-28T17:05:36Z

Pwillett: New page: Attending: Syd Bauman (notes), Kevin Hawkins (chair), Chris Powell, Melanie Schlosser, Natasha Smith, Rich Wisneski, Perry Willett (notes) * header: ** see e-mail sent 2009-01-25 by KH fo...

Attending: Syd Bauman (notes), Kevin Hawkins (chair), Chris Powell, Melanie Schlosser, Natasha Smith, Rich Wisneski, Perry Willett (notes)

* header:
** see e-mail sent 2009-01-25 by KH for more details
** everyone should read and response (deadline?)
** The BPG recommends including series title in <sourceDesc> but doesn't mention any other series information. Should we recommend other info like ISSN or series editor?

* Levels
** Level 1: CP: thinks AB is fine.
** Level 2: RW: nothing to report
** Level 3: NS: needs a P5 example
*** discussion of LBs and genesis of Level 3; does anyone have a true example?
** Level 4: Linda Cantara no longer working on this, but Matt Gibson is
** Level 5: same is w/ L4
*** we need to add an example or two, although don't need to go into full detail

* Filenaming:
** agreed to point to or incorporate IUDLP guidelines
** agreed to 8-dot-3 health warning
** question on ".tei" vs ".xml" extension: agreed to use *.xml extension
** agreed that internal consistency is more important than following a particular set of restrictions [I'm going to suggest this become a general recommendation--SB]

* AB vs. P:
** in the pseudo-paras of Level 1 and Level 2 we agreed to AB

* Numbered/unnumbered divs: we agreed that there is no consensus on this issue, and we shouldn't make a recommendation for one over the other. Instead, we should:
** encourage consistency within texts and collections
** describe the reasoning behind choosing one
** describe process of converting one to the other (and provide tools?)
** recommend a place in the header to record the decision
** schema should enforce consistency within text

* PBs
** leave recommendation as is

* meeting at DLF Spring Forum in Raleigh NC (May 4-6)
** KH will check with Barrie about getting a meeting room

* People should remove comments from BPG if they feel the issue has been resolved. KH will oversee the process.

SIG:Libraries

2009-01-28T16:48:48Z

Pwillett: /* Meetings */

Best Practices for TEI in Libraries

2009-01-13T00:27:55Z

Pwillett: /* LEVEL 2: Minimal Encoding */

Best Practices for TEI in Libraries

2009-01-13T00:26:30Z

Pwillett: /* LEVEL 2: Minimal Encoding */

Best Practices for TEI in Libraries

2009-01-09T21:57:12Z

Pwillett: /* LEVEL 2: Minimal Encoding */

Best Practices for TEI in Libraries

2009-01-09T21:54:55Z

Pwillett: /* LEVEL 1: Fully Automated Conversion and Encoding */ Note on

Best Practices for TEI in Libraries

2009-01-09T21:47:00Z

Pwillett: /* LEVEL 1: Fully Automated Conversion and Encoding */

Best Practices for TEI in Libraries

2009-01-09T21:45:07Z

Pwillett: /* LEVEL 1: Fully Automated Conversion and Encoding */

Best Practices for TEI in Libraries

2009-01-09T21:44:25Z

Pwillett: /* LEVEL 1: Fully Automated Conversion and Encoding */

Best Practices for TEI in Libraries

2009-01-09T21:43:42Z

Pwillett: /* LEVEL 1: Fully Automated Conversion and Encoding */

Best Practices for TEI in Libraries

2009-01-09T21:36:14Z

Pwillett: /* The TEI Header */

Best Practices for TEI in Libraries

2009-01-08T01:05:02Z

Pwillett: /* General Recommendations */

Best Practices for TEI in Libraries

2009-01-08T00:56:36Z

Pwillett: /* General Recommendations */