Minutes from February 17, 2009 - Revision history

Kshawkin: added category

2009-02-19T14:43:05Z

added category

Kshawkin: /* ACTION ITEMS */ fixed wiki markup for numbered list

2009-02-19T00:14:38Z

‎ACTION ITEMS: fixed wiki markup for numbered list

Emcaulay: Cleaned up version of the notes from the feb 17 conf call

2009-02-17T20:47:25Z

Cleaned up version of the notes from the feb 17 conf call

Emcaulay: snapshot at the end of the call

2009-02-17T19:41:53Z

snapshot at the end of the call

Emcaulay: lisa taking minutes (snapshot at 11:15 ... I got kicked off the call and can't get back in) i also need to clean these up

2009-02-17T19:20:23Z

lisa taking minutes (snapshot at 11:15 ... I got kicked off the call and can't get back in) i also need to clean these up

Emcaulay: rough notes mid-call

2009-02-17T18:49:37Z

rough notes mid-call

Emcaulay at 18:39, 17 February 2009

2009-02-17T18:39:56Z

Emcaulay: New page: 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: ...

2009-02-17T18:08:05Z

New page: 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: ...

New page

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

← Older revision		Revision as of 14:43, 19 February 2009
Line 1:		Line 1:
		+	[[Category:SIG:Libraries]]
		+
	Notes from the TEIHeader BPG subgroup conference call on 2/17/09 from ~1:00-2:40PM eastern		Notes from the TEIHeader BPG subgroup conference call on 2/17/09 from ~1:00-2:40PM eastern

@@ Line 98: / Line 98: @@
 [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]
-. 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)
+# 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)
-. Kevin or Melanie will remove @type from the teiHeader element
+# Kevin or Melanie will remove @type from the teiHeader element
-. 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)
+# 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)
-. Anticipated next teiHeader subgroup call -- March 3, 3PM Eastern
+# Anticipated next teiHeader subgroup call -- March 3, 3PM Eastern
-. 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
+# 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

@@ Line 1: / Line 1: @@
-minutes
+Notes from the TEIHeader BPG subgroup conference call on 2/17/09 from ~1:00-2:40PM eastern
-syd, lisa, kevin, melanie, rich
+Participants: KH, MS, SB, RW, and LM (recorder)
-relationship (policy-wise) between the TEI Header and MARC
+Goal of Call: Discuss larger questions related to the teiHeader section of the Best Practices Guidelines, as well as remaining in-line comments.
-Melanie and Kevin were working on describing AACR2 (Anglo American Cataloging Rules: 2nd edition) practice.
+==Relationship (policy-wise) between the TEI Header and MARC==
-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.
+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.
-'''Identifiers that point to OCLC & other identifiers'''
+== @type for element teiHeader ==
-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.)
+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
-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.
+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.)
-can we create a paragraph (prose) in encodingDesc?
+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.
-How to link to outside stuff (MODS, database records)? discussion again of the @tpe
+Can we create a paragraph (prose) in encodingDesc? Consensus that we should try that for now.
-What does level@ mean in this titleStmt in the teiHeader?
+==How to link to outside stuff (MODS, database records)? discussion again of the @type; tabled; Identifiers that point to OCLC & other identifiers==
 -example of Moby Dick;
 -TEI guidelines say "required when applicable"
@@ Line 29: / Line 33: @@
 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)
+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 -- does it matter what order the different responsibilities are listed in? No. We don't perceive a functional benefit.
+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.
+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>translate</resp>
+<respStmt><resp>translated by</resp><persName>Melanie Schlosser</persName></respStmt> and
 the values in the tei guidelines for attribute are not helpful -- too vague; we would like some more specificity.
@@ Line 45: / Line 53: @@
 we still believe in staying conformant on this issue
-Author within Source Desc
+==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"
+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?
@@ Line 63: / Line 71: @@
 what to do when a respStmt addresses something that's not named -- an unknown translator
-- lisa rejoins here -
+== 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
-put off otherDesc discussion
+==Decision: 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.
@@ Line 80: / Line 90: @@
 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?
+== add to running list BoF topics for discussion: Extent in SourceDesc -- possible or not? optional or not?==
-another call in two weeks march 3 @ 3PM eastern to discuss otherDesc
+. 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)

← Older revision		Revision as of 19:41, 17 February 2009
Line 62:		Line 62:

	what to do when a respStmt addresses something that's not named -- an unknown translator		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

← Older revision		Revision as of 19:20, 17 February 2009
Line 37:		Line 37:

	Availability --		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

← Older revision		Revision as of 18:49, 17 February 2009
Line 30:		Line 30:

	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)		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 --

← Older revision		Revision as of 18:39, 17 February 2009
Line 7:		Line 7:
	Melanie and Kevin were working on describing AACR2 (Anglo American Cataloging Rules: 2nd edition) practice.		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	+	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)