Minutes for June 30, 2009

Attendees: Renee, Glen, Rich, Kevin, Michelle

TEI Header Mapping

Renee:

• Changes based on Vitus' comments
• MARC record for the TEI document is based on the TEI document (534 field)
• Renee incorp. Vitus' suggestions; needed to account in the mapping for two approaches for cataloging the TEI doc
  • 533 field to capture as reproduction
    • Cataloging microfilm repro. of the book; body of the bib. record represents the book; the 533 captures the microfilm portion
  • 534 field to capture the TEI document; the TEI description is based on the TEI document solely
• Renee's personal preference is that we get a more consistent description base the description on the TEI document; use 534 field

in the source document

• • 533 accomodates limited metadata about the reproduction

Glen:

• 533 is structured?
• Has subfields.
• Do 533 and 534 have parallel structures?

Glen:

• Feels that some notes can be moved down into a "table" footnote to explain the 533 and 534.

Kevin:

• Summarizes surrograte cataloging; 2 practices:
  • 533 field: the whole rest of the MARC record describes the source doc; give brief info about surrogate
  • 534 field: describes mostly the MARC the TEI document

Glen:

• Our approach with best practices does not assume that a library does not have the source document; so it's better to have

the TEI document as the source for description (thus the 534 approach)

• Kevin also supports 534

• Only 3 fields left that have 533 mappings: date of pub for TEI document, seriesStmt title level ="f" and publisher of TEI document
• Renee can adjust the mappings if we all agree to treat the TEI document as source
• Our guidelines preference the electronic source, but we leave room for referencing the "source"
• Include original source as a footnote for internal consistency
• We don't need to change mappings.
• The three instances of 533 are only used in 3 cases with the parenthetical note. Use non-533 fields if you use the 534.
• Can only use one or the other; Kevin will make it clearer (534 v. 700s and 100s)
• Renee recommenda two tables, if based on source doc versus surrogate doc
• Kevin will split the cell with the MARC mapping; Glen agrees

• Encoded texts are not as identical as the original; need for separate metadata is more relevant

• Renee incorporated several of Vitus' suggestions (see her email)

Syd Stuff

Extent:

• extent element; only in mss description module of the TEI to encode extent in more machine readable way
• it may not matter which way it went; chris powell worries the MARC metadata will be messy (based on her extensive experience)
• so no need to break out the extent further
• Kevin read AACR, following rules, strings can be parsed out (due to punctuation). It should be quite clear.
• Michelle suggests to add this to list of future revisions; explore case studies
• Concern about intro. elements from manu. dss.

Refs:

• notes: how ref points to notes; target attribute on note element or on the ref element?
• bi-directional linking should be supported
• we agree on the direction of pointing; from ref to note (and not vice-versa)
• still waiting for syd to ID where in the P5 it says we should do notes a certain way.

Pending List to Syd:

• editor, role
• proof ref/key attributes
• check hypenation text
• 2 letter v. 3 letter language codes
• pointing to outside metadata
• level 4 Hiss example; root element has a bunch of attributes, but not in other sample docs
• Kevin re-wrote the section on notes from Level 3; group should have a look at that

Wrap Up

• If any issues require group weigh-in, we'll do it over email or setup a call in early July.
• Glen: Hiss examples; for level 4, there's only one extra attribute xml:ns and xml:id on root
  • Kevin: should we also have an ID at the root?
  • Can add a recommendation in the general table above the Header for a unique identifier in the TEI root (in xml:id)
  • Do we need both the idno and xml:id root
  • Header can be removed from body for metadata interchange
  • Ask Syd what he thinks about idno v. xml:id
  • We may not need it in both places
  • Glen raises the issue that workflow or process may rely on xml:id more so than IDNO; Michelle supports
  • Kevin suggests IDNO is mandatory; xml:id in the root element is recommended