Minutes from February 17, 2009

minutes

syd, lisa, kevin, melanie, rich

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

Melanie and Kevin were working on describing AACR2 (Anglo American Cataloging Rules: 2nd edition) practice.

A couple of paragraphs of introduction in the TEI Header and all of these paragraphs need to be revised. Needs a new set of eyes. A big re-write (lisa volunteers) and then forward to the BPG once it's cleaned up.

Identifiers that point to OCLC & other identifiers

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

recording what description standard you're using. what value is there in recording this in a machine read-able format? it's very important for human to read? if you were processing a large group of documents, then it would be easier to group the like docs together.

can we create a paragraph (prose) in encodingDesc?

How to link to outside stuff (MODS, database records)? discussion again of the @tpe

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)

ResptStmt -- 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 Melanie Schlosser as translator and compiler. <respStmt><resp>translate</resp>

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

- lisa rejoins here -

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

put off otherDesc discussion

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.

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

- BoF topic: Extent in SourceDesc -- possible or not? optional or not?

another call in two weeks march 3 @ 3PM eastern to discuss otherDesc