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

Glen:

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)

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

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

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