Future changes to Best Practices for TEI in Libraries

milestone element

<milestone unit="typography" n="******"/> -- Is this TEI-conformant? Is there a better way to do this in any case?

The TEI Header

• 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

element	status	comments
appInfo
application
authority
availability
cRefPattern	delete
catDesc	delete
catRef	delete
category	delete
change	change
classCode	delete
classDecl	delete
correction	delete
creation
distributor
edition
editionStmt
editorialDecl	replace
encodingDesc
extent
fileDesc		REQ
funder
geoDecl	delete
handNote	delete
hyphenation	delete
idno	change
interpretation	delete
keywords	delete
langUsage
language	change
namespace	delete
normalization	delete
notesStmt
principal
profileDesc
projectDesc
publicationStmt	change	REQ
quotation	delete
refState	delete
refsDecl	delete
rendition	delete
revisionDesc
samplingDecl
segmentation	delete
seriesStmt
sourceDesc	change	REQ
sponsor
stdVals	delete
tagUsage	delete
tagsDecl	delete
taxonomy	delete
teiHeader		REQ
textClass	delete
titleStmt		REQ
typeNote	delete

Identifiers for outside metadata?

Should we have a place in the header to indicate an identifier for an outside metadata record for the item? Examples:

• 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

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)

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), <classCode> inside <classDec>, or is that too much of a stretch? (—Syd)

While at the Swinburne conference with John I happen to look over his shoulder while he was encoding and I noticed his use of <relatedItem> in the <biblStruct>: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-relatedItem.html. You may have come across this already in your break-out meetings, but at a quick glance, the application seems to fit our needs: <relatedItem> contains or references some other bibliographic item which is related to the present one in some specified manner, for example as a constituent or alternative version of it. John was using it in conjunction with an embedded <note> to provide additional context. <ptr> and <ref> are also valid within <relatedItem>. (—Mdalmau)

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

NOTE: we talked about this during our conf call on 2/10/09; we decided to have a sub-group conference call on 2/17/09 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:

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

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:

<sourceDesc id="sourceDesc_1">
[. . .]
</sourceDesc>

for which you'd find elsewhere in the document:

<link type="MARCsource" target="#sourceDesc_1 http://mirlyn.lib.umich.edu/F/?func=direct&doc_number=000601789&local_base=MIU01_PUB"/>

link elements might be grouped together in one of these places:

• TEI/teiHeader/profileDesc/creation/ab/linkGrp
• 1st child of <text> last child of <text>
• TEI/text/back/div[@type='editorial']/linkGrp

---

UPDATE: We'll probably use <idno> in various header elements: see https://sourceforge.net/tracker/index.php?func=detail&aid=2493417&group_id=106328&atid=644065 . In any case, we'll need to tell people how much metadata to include in TEI header if they will also have external, possibly canonical, metadata sources.

extent element

Instead of

<extent>viii, [7]-215 p</extent>
<extent>20 cm.</extent> 

we might use elements from the msDescription module and do it this way:

<extent>viii, [7]-215 p</extent>
<extent>
  <height quantity="20" unit="cm"/>
</extent>

Had a width been given for this item in the catalog record, in the header it would have been:

<extent>viii, [7]-215 p</extent>
<extent>
  <width quantity="30" unit="cm"/>
  <height quantity="20" unit="cm"/>
</extent>

providing stylesheets

providing stylesheets for header-MARC and header-MODS

providing tools

providing tools for workflows