Minutes for May 26, 2009

In Attendance:
Syd, Kevin, Michelle, Matthew, Rich, Melanie, Natasha, Perry and Glen

Note taker: Michelle

Level attribute on title element

• use of level on title; Guidelines ambiguous; got clarification via SourceForge
• Guidelines said the attribute was required when applicable (supposed to

be recommended when applicable)

• Usage note now clarified; don't have to use it if value can be inferred (e.g. title in a series, don't need title level="s")
• Do we have in all cases, or only when it can not be inferred?
• Perry thinks we should avoid inference route; easier to process
• So have it in all cases

Pending revisions

• AACR questions pulled from the header element description (for editorialDecl).
• Rhetorical questions ... could be confusing.
• Kevin will re-word these so that they not rhetorical questions but examples of kinds of info. one would include in the editorialDecl.

Use <ref> for ToC example in Level 3

• level 3 in ToC should use to <ref> tag for specific pages. Use <ptr> when there's no

page numbers, but <ref> examples in the P5 Guidelines has page numbers.

• Why do we bother encoding ToC anyway? Michigan doesn't encode the ToC.
• Add a note you may not want to bother encoding the ToC (optiional) if system will generate this automatically, but you plan to manually encode the ToC, here's an example.
• Same for list of illustrations occurring in prefatory pages (add to level 3 description) about possibly removing these as well.

@type/@key persName/orgName

• Added type values for marc100 and marc110 (to better represent author names + dates).
• Did not add marc 111 or marc 130.
• Have a key attribute that would reference an authority file. Key is not really an ID/REF type.
• Need a taxonomy element in the Header.
• What's the difference between lccn-n78-#### (OCLC World Cat Identities) and lcnaf #? Should we align these?
• Explain the need to develop a local ref/key scheme for referencing authority files under General Recommendations. Also add ref/key elements under "General Guidelines for Attribute Usage".

Linking to outside Metadata schemes

• Syd doesn't agree: There's nothing at all that stops us for incorporating non-TEI metadata in the Header. Since we are making ODDs we can support the embedding of metadata schemes and values.
• But METS handle this so should we even embed metadata?
• Need time to provide thoughful recommendations for embedding
• Linking to other schemes can be hacked (but then we need to provide recommendations for what a minimum header looks like)
• TEI document has an xml:id that references a METS or some other file, but it doesn't provide sufficient context.
• Melanie recommends that the Header subgroup reforms to work on these issues.
• Neither embedding or linking recommendations will be part of version 3 of the best practices
• Kevin will revise this text slightly to clarify and to indicate future revisions will handle this.

Rendition in header

• Use CSS instead. Use the rendition element in the Header; css rules in the Header. Method of indirection.
• Inline CSS versus defining CSS in the Header? What are the pros and cons?
• Rendition placed in external file and xinclude it in the Header or define it in the Header; minimizes errors and keystrokes. Maximizes single renidtion reference for a set of documents.
• Level 3 use rend (with inline CSS) and not rendition and level 4 say that rendition have X advantages?
• Worth saying that rend SHOULD NOT be used in the Header
• Place under general attributes message and support both
• CSS inline (easier to process) or level of indirection (minimize errors) in the Header

Level 5

• Axed the examples and mimicked the sections for the other levels.
• Header and general recommendations still apply for Level 5
• Syd: feels that it's more than just the Header, level 4 + extra stuff + general recommendations.
• Glen will clairfy and add the other bits.

Hyphenation

• Kevin recommends the Tite way (to facilitate conversion)
• Should be an editorial decision?
• Improve recall when searching for a corpus (Tite rationale).
• hyphenation in the header needs to be re-worded
• Perry disagrees; Tite won't represent the majority of projects already created and many projects won't conform to this. Perry and Syd don't feel this is the best practice.
• Level 1/2 generated in OCR, OCR software can remove soft hyphens. Abbey FineReader (can remove soft hyphens).
• Defer issue to next call or email discussion.
• Subgroup needs to form

Conference Call Schedule

• Schedule next call a week from today to wrap up the pending issues.
• By July, calls can ease up or stop entirely