Talk:Best Practices for TEI in Libraries

The following are revisions to make to the BP before making an official "release". There is a separate list of Future changes to Best Practices for TEI in Libraries.

Dependent upon pending revisions to Tite

Add Tite as Level 3.5

This was strongly recommended by Daniel Pitti in Ann Arbor because he felt certain that administrators and funders would be confused about the difference between TEI Tite and the Best Practices ("don't the libraries already have a TEI customization?"); in fact, Kevin has known this same confusion to arise among TEI Council members. While we have a section of the BP discussion its relationship to Tite, by having a Level 3.5, we can be more explicit about mapping between the two.

Naturally we will not be able to describe Tite the way we do other levels -- by simply saying "all the elements in the previous levels, plus the following". Tite uses different element names of all sorts. There's no point in having Syd make an ODD for Tite since one already exists. So what Kevin envisions here is a sort of "sidebar" about Tite, inserted between Levels 3 and 4 that discusses Tite in a bit more detail than we currently have in the beginning of the BP, with particular discussion of mapping between the two.

Would someone be willing to write a first draft of all of this? Two paragraphs are already written for you, and you can pull more information from Tite's discussion of an earlier version of the Best Practices.

Revise section on hyphenation

Revise the section on hyphenation per outcome of the discussion on TEI-L and perhaps also on how this is handled in the ongoing Tite revisions.

Other issues to resolve before releasing

Test ODDs and schemas derived from them

Test Syd's ODDs and schemas derived from them: http://bauman.zapto.org/~syd/temp/BestPractices/ . Just go to that URL, download the .rng files, and create a new XML document based on the schema. So if it allows you to insert all the elements you expect to be able to insert. Syd has been asked to make the following changes:

• in header ODD, allow only a structured <publicationStmt>
• lib1.rng: <oXygen/> says "Errors encountered: Probably no start pattern found".
• The only allowed child of front, body, or back *at any level* should be a div.
• note should not be allowed at in Level 1 or Level 2
• ab should be the only child allowed of any div (in both Level 1 and Level 2). This element seems to be missing from the schema.
• floatingText is missing in Level 3 or Level 4 schemas.

Use of any P5 attributes

Determine whether to change the prose of the BP to say that you can use any attribute you find in P5 for elements within <text> (as opposed to in <teiHeader>, where Kevin believes we've settled on using just the attributes given in the BP section on the header).

Direction of pointing between note references and notes themselves

Decide whether to change back to having <ref> point to <note> instead of <note> point to <ref>, as Syd recommended. See this ticket:

https://sourceforge.net/tracker/?func=detail&aid=2796148&group_id=106328&atid=644062

and this change to the Guidelines:

http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=6937&r2=6936&pathrev=6937

or, for the full story, see Kevin's email from Nov. 6 and previous quoted messages.

meeting element

Decide whether to include <meeting> in sourceDesc/biblStruct/monogr/ and/or in titleStmt. (Per a change on 2010-01-15 in SourceForge, meeting is now allowed in titleStmt.) As Kevin discussed in an email sent on Oct. 12, the name of a meeting is usually included in a MARC record, but it's not distinguished from an author or editor in the same way TEI divides up the world. The essential question is: if you digitize a volume of conference proceedings, is the name of the meeting, as opposed to the title of the volume, really important enough to warrant inclusion in the TEI header? If so, we need to wrestle with the questions Kevin brought up on Oct. 12.

appInfo and application

Decide whether to include <appInfo> and <application> in our header recommendations. In email discussions, Syd saw them as useful, but Lisa didn't think we need them.

[Comment from Lou: There is at least one proposal forthcoming for further work on defining the scope and usage of these elements, which have not yet reached the degree of stability desirable for inclusion in a BP document, imho ]