Minutes from February 17, 2009

Notes from the TEIHeader BPG subgroup conference call on 2/17/09 from ~1:00-2:40PM eastern

Participants: KH, MS, SB, RW, and LM (recorder)

Goal of Call: Discuss larger questions related to the teiHeader section of the Best Practices Guidelines, as well as remaining in-line comments.

Relationship (policy-wise) between the TEI Header and MARC

When Melanie and Kevin did their rewriting of the TEI Header section of the BPG, they were included some guidance that was based on AACR2 (Anglo American Cataloging Rules: 2nd edition) practice. Later they wanted to abstract that to a more international audience. We need to cleanup and consolidate and make clearer. Indeed, there a couple of paragraphs of introduction in the TEI Header section of the BPG and all of these paragraphs need to be revised. Needs a new set of eyes. A big re-write is needed. Lisa volunteers. Lisa will email the BPG group once she has made a first pass at the introduction section of the TEIHeader section. Lisa is not terribly familiar with MARC or AACR2, so her perspective will be fresh, but her work will need refining.

@type for element teiHeader

type attribute for teiHeader -- there is consensus that the @type is not the best place to describe the content standard (AACR2, DACS, ISBD(ER), etc.) that is being used to create the teiHeader values

DECISION: do not use teiHeader @type to note what description standard is being used to determine values of elements (that is, drop AACR2, ISBD(ER), etc.)

Group consensus that recording what description/content standard (AACR2, etc.) you're using in creating the teiHeader is useful information and that it serves a human-readable audience and possibly a machine-readable audience. What value is there in recording this information in a machine read-able format? If you were processing a large group of documents, then it would be easier to group the like docs together. But group still feels teiHeader @type is not the correct place to place this information, even though it's easily machine-readable there.

Can we create a paragraph (prose) in encodingDesc? Consensus that we should try that for now.

Use of @level in the title element inside the teiHeader

What does @level@ mean in this titleStmt in the teiHeader? -example of Moby Dick; -TEI guidelines say "required when applicable"

why use level for the title element? -when mentioned in prose, -when used in citations

DECISION: we don't think level is useful inside the TEI Header title elements

DISCUSSION: it should be clear whether this document is prescriptive. (Lisa handle in the introduction) (all elements and values and attributes listed in the section or not) LISA CAN'T REMEMBER EXACTLY WHAT WAS DECIDED BUT THINKS THAT BECAUSE WE PLAN TO DO AN ODD AND A SCHEMA THAT WE ARE GOING TO DESCRIBE ALL ELEMENTS THAT ARE ALLOWABLE.

ResptStmt order of responsibilities

Does it matter what order the different responsibilities are listed in? No. We don't perceive a functional benefit.

Multiple elements are allowed, so we might want to constrain the allow only one resp per respStmt; allow mutliple respStmts to reflect multiple responsibilities, eg, Melanie Schlosser as translator and compiler. <respStmt><resp>translated by</resp><persName>Melanie Schlosser</persName></respStmt> and <respStmt><resp>Compiled by</resp><persName>Melanie Schlosser</persName></respStmt>

Availability

the values in the tei guidelines for attribute are not helpful -- too vague; we would like some more specificity.

explain in prose -- we should revise

we should advise TEI to revisit the status attribute. [keep for a later "to do" list of this group -- toward the end of our work, we might make several requests to the TEI based on our work]

we still believe in staying conformant on this issue

Author within Source Desc

In cataloging, you sometimes don't record the author as a main way of finding the record (aka main entry); Rich confirms that Case's process is to enter an author value even if it's not considered a "main entry"

is author required inside the monogr element?

<persName> and <orgName> within author ; and then using neither when it's a commentary (author unknown, etc.)

discussion on "anonymous" and whether there is a MARC 100 field

leaning toward using three approaches: persName, orgName, or neither -- neither is for a prose annotation of a statement of authorship (sourceDesc and FileDesc should be the same)

do the same for editor, too.

this practice will make the author and editor tag practice similar to respStmt

what to do when a respStmt addresses something that's not named -- an unknown translator

element idno

will people want to record the LC Call Number? if we can point to another metadata record (such as MARC), then people can get the LCCN from the record There is ambiguity on the phrase LCCN -- there is a LCCN that is used for the object in the LoC, and then there is a LCCN schema created call number

Extent

Extent element -- we should set this to be optional. Bring over from MARC if you have it; otherwise do a page tally. Melanie argues that the variety of situations in which the teiHeader is created means that it's difficult to assert the page tally in all cases.

title

Main and Sub as the values in the type element -- leave it open and don't validate against that.

If we use a MARC record as a source for the teiHeader, then it won't neatly parse to the main and sub values 245a - title proper 245b - generally a subtitle, but sometimes includes other stuff

attribute value should be marc245a, marc245b, main, sub, alt, short, desc [only inside the sourceDesc and not for other uses of titles] -- we can see if there's any objection of this approach

ACTION ITEMS

[Lisa is assigning some edits to Kevin or Melanie for ease of having a responsible party, but K and M can delegate to others, too]

1. Lisa McAulay rewrites the intro paragraphs to the TEI Header section of the BPG and email the BPG group for review, making sure that the approach of the BPG is clear that all available / appropriate elements are discussed in the BPG and that anything not in the BPG would presumably not be used (rationale: we're keeping in mind that we're going to a make a schema out of these docs)
2. Kevin or Melanie will remove @type from the teiHeader element
3. Kevin or Melanie will suggest phrasing for the encodingDesc p element that addresses the content standard that was used in creating the teiHeader (replacing what was previously being referenced in the teiHeader@type)
4. Anticipated next teiHeader subgroup call -- March 3, 3PM Eastern
5. We should keep a running list of good topics for BoF discussion and later items we want to bring to the TEI's attention for possible revision