Minutes for May 26, 2009

DRAFT DRAFT: NEEDS CLEAN UP SO DON'T READ NOW!

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 deal with 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? Need to develop a local scheme for referencing authority files under General Recommendations. Also add ref/key elements under GR sections.

Linking to outside Metadata schemes --Syd doesn't like it: 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. METS handle this so should we even embed metadata. --Linking doesn't exist as fully (but then we need to provide recommendations for what a minimum header looks like) --TEI document has an xml:id that references a METS. --Melanie recommends that the Header subgroup reforms to work on these issues. --Not part of version 3. --Kevin will revise this text slightly.

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? --Every time a new style is discovered in the document; add to the Header and represent in CSS. Only create the short cut when used a lot. --Rendition placed in external file and xinclude it in the Header or define it in the Header; minimizes errors and keystrokes. --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. --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 could add the other bits.

Hyphenation --Recommend the Tite way (to facilitate conversion) --EOL hyphens in Tite (distinguish between hard and soft hyphens; use soft hyphen document if there weren't a line break; and use ASCII for hard hyphen). Preference to hard hyphens. --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 to next call. --Subgroup needs to form

Schedule next call a week from today to wrap up the pending issues.