Future changes to Best Practices for TEI in Libraries

This page describes changes to the Best Practices for TEI in Libraries which will be made at some point but which did not delay release of version 3.0.

These items will be migrated into the GitHub issue tracker.

milestone element
-- Is this TEI-conformant? Is there a better way to do this in any case?


 * This is not TEI conformant, unless you think that "*****" is a valid way of naming something (here this particular milestone). I would suggest


 * Or possibly


 * Or you could use if you have followed tite in adding it. LouBurnard


 * I agree with Lou that “typography” is not really a unit, and stars are not really a label for the unit, whatever it is. I’m not fond of &lt;space> for this purpose, but perhaps there are convincing arguments I haven’t considered. I quite like
 * except that I think, in general, these units are structural. So I would prefer "undetermined" as the value of unit=. Syd Bauman
 * except that I think, in general, these units are structural. So I would prefer "undetermined" as the value of unit=. Syd Bauman


 * Note that these values of @rend do not conform to our general recommendation to use CSS for values of @rend. (Kshawkin 12:38, 13 November 2011 (EST))

deprecate key
The section on "key and ref" needs to be revised so that the Shakespeare example points to a Linked Data URI for this authority record, which is now this would be done now that id.loc.gov is available. Furthermore, the use of &lt;taxonomy&gt; in this example is not even warranted in its current form in the BP, where we recommend it simply to gloss a string used as part of the value of @key even when not for a typology of any sort.

So once both of these things are fixed, the Shakespeare example no longer illustrates a magic token, so a new example should be created that uses a "tag" URI for the value of @target as implemented in P5 in feature request 3437509. Then we will really no longer be recommending use of @key, so the title of this section in the BP should be revised. (Kshawkin 22:20, 17 June 2012 (EDT))

alternative handling of ISBNs
See outcome of http://purl.org/TEI/fr/3500566. Solution (e) on this ticket seems especially good for machine processing, though we should probably use ref instead of ptr so that there is a way to represent the ISBN printed on an item (which might not be the real one). See AACR2 for how to represent the stated and known ISBNs.

persName
Consider whether various MARC 1xx and 7xx subfields could be broken out into components of persName. If so, we'll change recommendations for persName@type.

list of elements deleted and changed by our ODDs
Syd's list of elements is now on a different wiki page because this page is meant for things to be addressed once version 3.0 is complete. (Which is now entirely out of date. —Syd)

Pending Issues Discussed
Should we have a place in the header to indicate an identifier for an outside metadata record for the item? Examples: Having such a link would allow a delivery system to provide an unambiguous link to this full metadata without relying on matching other information in the header like a title, ISBN, or call number. (Kshawkin)
 * record number for the source document in the local catalog
 * record number for the source document in WorldCat
 * record number for this TEI document in the local catalog
 * record number for this TEI document in WorldCat

Yes, I think we should. How about the spot where the TEI Guidelines recommend putting the code for the classification of the text (in some scheme), &lt;classCode> inside &lt;classDec>, or is that too much of a stretch? (—Syd)


 * During the call on 2009-02-10, Syd said he no longer thinks use of classCode (and a corresponding classDecl</tt>) is a good idea. Instead, he suggested we createa new element, otherDesc</tt>, to contain elements from outside the TEI namespace for metadata not covered by the TEI header. The BP could specify how this element is used. (Kshawkin)

NOTE: we talked about this during our conf call on 2009-02-10; we decided to have a sub-group conference call on 2009-02-17 to talk in more detail about this. Emcaulay


 * We didn't get to this on 2009-02-17, so we postponed to 2009-03-03. However, few people showed up, so we postponed again.  As Syd put it, there are two issues to consider here:


 * A. What mechanism should we use to we point from the TEI header to metadata located outside the TEI document? (For example, how do you identify a MARC, METS, or MODS record that provides additional metadata about the TEI document and/or the source document?)


 * B. Should we provide a recommendation on storing non-TEI metadata within the TEI document (using a different element namespace)? For example, should we allow Dublin Core elements anywhere in the TEI header?

Email discussions in late March 2009 and early April 2009 with Syd, Melanie, Kevin, Michelle and Glen did not reach a conclusion. Tentative plans for the future would do this sort of thing when an element has the @ref attribute:

<persName xml:id="persName_1" ref="http://authorities.loc.gov/cgi-bin/Pwebrecon.cgi?AuthRecID=1563939&amp;v1=1&amp;HC=1&amp;SEQ=20090404152214&amp;PID=wRSbpUQ7Uptm_ypRikIdNPzF">Welles, Gideon, 1802-1878.</persName>

except that in your example there's no @type or other method for describing the relationship between the content of <persName> and the value of @ref. P5 says that @ref "provides an explicit means of locating a full definition for the entity being named by means of one or more URIs", but we are looking for a typology of some sort for these links and need a place to indicate the type of link.

And we'd do this when there's no @ref:

(noting that a line-break was rendered in the source document).


 * See http://purl.org/TEI/fr/3523225.