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
be recommended when applicable)
 * use of level on title; Guidelines ambiguous; got clarification via SourceForge
 * Guidelines said the attribute was required when applicable (supposed to
 * 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/Raleigh --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.

--level 3 in ToC should use to tag for specific pages. The there's no page numbers, but 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.