From mproffit@LIBRARY.BERKELEY.EDU Tue Oct 26 10:12:57 1999 Date: Mon, 18 Oct 1999 14:24:59 -0700 From: Merrilee Proffitt Reply-To: TEI Medieval Manuscripts Description Work Group To: TEI-MMSS@LISTSERV.UIC.EDU Subject: DRAFT meeting minutes All, Please read an get your comments back to me within a week. I think it's pretty important that we get these out for general circulation ASAP. Merrilee Attending: Consuelo Dutschke, Merrilee Proffitt, Ambrogio Piazzoni, Eva Nylander, Lou Burnard, Peter Kidd, Anne Mette Hanson, Peter Robinson, Belinda Egan, special guest appearance by Charles Faulhaber 13 October 1999 Discussion of funding and what we need to accomplish in this meeting. Peter R. led us through a review of MASTER documentation. msSummary and msHeading are problematic, but left as is for the current purposes of MASTER. Status attribute on the msDescription element with legal values. Does TEI work group also want this to be a fixed list of attribute values? Peter Kidd points out that we should have the status attribute at the part level also. Look at status more generally, because this was unresolved in Prague. Review of phrase level elements, especially those that are particular to msDescription. Consuelo suggests coming back to origDate and origPlace and discussing this. They can currently only contain pcdata, which is a problem (problem with superscript, etc). Corrections noted for MASTER document in regards to dimensions. Peter Kidd may want to come back to discuss dimensions. Question whether leaf and leaves should both be legal values? Example given is wrong. Maybe paragraphs should be available here (this is also true other places). Definition of depth needs to be worked on (Peter Kidd). In definition for "from" attribute in locus, should be folio and not page. Ambrogio: what to do with multiple foliations? We need to come back to this. Two issues. Maybe we need a foliation element in paratext, but also look at how this works in regard to locus. Peter Kidd said that the current definition of the "supplied" attribute makes no sense. P proposed as needed within dimensions, origPlace, and origDate (need for for superscript, eg). Discussion of msIdentifier. Peter Kidd and Consuelo have documentation about these. Group is fairly agreed that idno attribute "type" should go away or receive less weight in documentation. Does the alternate issue falls at the msIdentifier level, instead of in altName? Decided to leave as is, but again, clarification is needed. Again, there are good definitions and examples in Peter Kidd and Consuelo's document. msHeading. Will discuss later along with msSummary. msContents. In msItem, consensus is that locus should be allowed to appear anywhere, not just at the beginning. And all elements in any order. Consuelo suggests we come back and discuss text later this afternoon. Physical description: MASTER has these things in a fixed order. Consensus that having things in a fixed order is problematic. We need to come back to the elimination of catchword and signature and readers catchwords. Definition in documentation of extent seems to be flawed and not consistent with what has been decided. Watermark needs to be encoded separately as an element or an attribute, perhaps under support. We will look at this tomorrow. The way that msWriting is laid out is confusing in the documentation. Paratext: Peter Kidd doesn't like foliation and pagination in there. Another thing to revisit. Marginalia: needs a better definition, needs examples (Matthew has). Condition: in definition, strike words: "in its original state". It is the condition you expect it to be in. In history, attribute currently called conjecture, needs to be changed. Dated and datable added back in as attributes but related to origPlace and origDate. Should surrogates be plural? Should is be surrogates with surrogates inside, as with binding? Definition needs to be fixed. Type = gmd is confusing for non-librarians. End of review of MASTER documentation Peter Kidd presented his document on msHeading, which corresponds to msSummary in MASTER draft. A lot of discussion and misunderstanding about the tight versus loose models. Maybe the solution is to have author and langUsage available as phrase level element. Call it msHeading which has

with phrase level elements. Return to text. What to do about completeness issues with text? Expert group wanted this, but do they really want a tag or an attribute for this, or do they just want it covered in cataloging. Too complex, maybe we should drop this (again). A definition of a complete manuscript is a difficult thing. Decision to drop again. Question about type of author; definition here is the primary author, which is problematic. Other problems are is the authors name written in the text, did it come from Ambrogio's head, and other types of authors: translators, editors, commentators, etc. Difficulty in discussion with concept of author being much broadly used than is typical. Idea of persName and orgName surface again. Ambrogio: example from page 13 of the example packet, pseudo Bonaventura. Concept of author is too important to dismiss, Consuelo says. What are the variants on author? Suggestion: use persName and orgName with a role attribute. Role needs to be an open list. Author then stands as author (no role). Translator, abridger, glossator, compiler, binder, editor, scholar, annotator. Shift from discussion of author to other things, like title. Need for an attribute or an element to indicate that this is or is not how author name or title appear in manuscript. Decided on suggested attributes: attested = yes/no and correct = yes/no. Attributes on persName and author. Reg needs to be an attribute on both of these. Undecided: key attribute for names as in PhiloBiblon and Brown Woman Writers Project. 14 October 1999 Lou joins group. Return to discussion of author versus persName with a role attribute. Author currently can be used only in bibl-like contexts, so outside of msContents, author could be used in bibl (as with citing other manuscripts). Return to discussion of mistaken attribution. Another example of this on page 107 of packet. Peter suggests accepted rather than correct. Eva points out that the use of correct or wrong is already common. No decision on what wording should be. Same mechanism (attested/correct) is needed for title. Discussion of whether we need the same mechanism exactly, or if we can use the type attribute on title. Decided to use the same mechanism. msSummary vs. msHeading discussion. Loose model again generally approved. msHeading is then a special kind of bibl, so that it includes author, langUsage, and other special ms tags. langUsage to be added to msPhrase. To be called msHeading. Question of gap versus damage versus lacuna^Å What prompted this discussion is a need for a mechanism to indicate if something begins or ends defectively. Lou suggests attributes on incipit and explicit to indicate this. Differences in definition of incipit versus opening words (Oxford variant, first words of the text versus first words of the manuscript); same difficulties with rubric. Consuelo suggests putting attributes on incipit and explicit to indicate that they aren't really incipits. Should we use q or q within a note when it's not really an incipit in the Oxford sense of the word? Arguments for and against. You have to understand what you are using and why, and use attributes to clarify if necessary. Use type = supplied for the Oxford type incipit, type = defective for Consuelo type. No use of type indicates that the incipit is just a regular old incipit. Some people have a problem with the use of the word defective. Discussion of different types of incipits (prologue, dedication letter, translators). Peter Robinson suggested that types of incipits could be indicated via an attribute on msItem itself, which would work by nesting msItems. Consuelo sees nesting as functioning in another way. Consuelo, will go away and bring this back on email. This also applies to explicit and rubric. Discussion of use of supplied tag for a missing letter. Need to return to secFol. What is abstract? Seems like it could be used as docket is in Digital Scriptorium database. Change name of abstract to summary. Blow away final rubric. versus . Is there a danger in using both of these, and explaining what the difference is? Eg: A translator versus the translator. Peter Robinson will type this up, since it's in his head. Phrase level elements: Type attributes on dimension: eliminate leaf from examples, change measurements to dimensions in documentation. Merrilee will do a list of dates, places to show different ways of representing these items. Collation formula is another thing, which may be properly treated through some means. Peter Kidd suggests that this should be looked at to see if it can be dealt with via something other than typographical signals. Physical description: The return of signatures and catchwords. Discussion about phrase level elements, and having the same (or similar) content model throughout the dtd. Should signatures and catchwords be phrase level elements. Put signatures and catchwords back under collation, contain paragraphs. Still outstanding, readers catchwords. 15 October 1999 Continuation with discussion of collation. Content model collation for collation (signatures | catchwords | p ) + OR (%msPhrase | catchwords | signatures) + OR (p+) + (catchwords | signatures ) (not xml compliant). BUT later decided to go with a specialized type of paragraph (see under decoNote) Problem with missing "list" in any of these^Å. Put the issue of content model aside for the time being. Lou to work on. Content model for catchwords and signatures is p+ Belinda questions use of attributes in layout and handDesc. Does the scribe attribute make any sense, in light of the decisions about persName, respStmt? Yes, because it ties a person to a particular hand. Some unease with this. Using the scribe attribute allows one to say this is the scribe of the hand, in addition to being able to list other scribes cited (using persName) in the prose description, which is useful. Peter R. will try to clarify this in his examples with respStmt and persName. Perhaps we should have a parallel mechanism with decoration, binding, author. Peter Kidd makes a suggestion that we might want a phrase level element for material or medium, which could eliminate medium in handDesc. Decided to leave it. Problem of indexing scripts. Return of the discussion of term (see minutes from Rome meeting). Mark things that an expert would want to pull out and have a look at. Persuading argument for shifting to term is potential use in decoration, music notation, and binding. Music is an area we don't know enough about. And it's musicNotation, not musicNote (documentation) Decoration: Peter Kidd feels it's too restrictive to have decoration in physical description alone. Example given is a manuscript with medical recipes, anatomical drawings, and more medical recipes. Proposes decoration to be in msItem, in bindDesc and in physDesc (where it is now). Maybe a way to do this is to have decoNote available a number of different places. With msItem, the shorter the description, the more likely decoration is to creep into the description of contents. Consensus is the decoNote should be where it is now, in msItem, and in binding and bindDesc. Lou disagrees with putting decoNote in msItem but too bad. Peter Robinson thinks this is all wonderful. Discussion of attributes presented in Peter Kidd's document. Examples are needed. Discussion of border versus margin. Lou feels the need for better definitions, or leans towards eliminating. Belinda suggests putting this on the EAMMS list, for clarification. Do we need size? Kill size because we have dimensions. Technique and style? Do we need both, both combined, one and not the other? We have a unspec attribute; we need an 'other' attribute in order to cope with cases (such as that thought up on the spot by Ambrogio) which do not fit the Peter Kidd typology. Ambrogio asked: can we have images anywhere. Answer: from Lou, through the standard TEI mechanisms (figure?) Decisions about the attributes of deconote: we remove the size attribute because we now have the dimensions element. We think quality might be controversial, but we will leave it in play for now. Over lunch Lou got troubled: are we using these attributes to describe the thing in the manuscript, OR to characterize what the discussion in the deconote element is about. This caused some brain strain but some of us finally got it. Lou (followed eventually by PR and PK) wanted it spelt out that decoNote contains a DISCUSSION of decoration, and that the attributes state what the discussion is about. That is: the decoNote should NOT be seen as a means of stating the character, qualities, attributes etc of the individual image. Thus: we may use decoNote to discuss a whole bunch of images and the attribute then states that right here we are talking about these images under the aspect of historiation, initials, etc. And, by the way, one could infer from the fact that we have a decoNote discussing historiated initials etc in the manuscript, that indeed there are examples of historiation and initials etc etc in the manuscript. The attributes and use of the decoNote element need to be very clearly spelled out in the documentation. Lou quibbles with figurative attribute. Figurative is an important concept in the world of decoration, for which a flag would be useful. Decide to stay with names of attributes the way they are listed in MASTER draft. Peter will "shake his money box" to get Peter Kidd and Anne K. together with some others to further discuss decoration. same as Studley; attributes term, key, source, reg. Content model is specialized type of paragraph (and this will go for collation as well). Term should have these things also. Phrase level element. More problems with content model. We need lists, multiple paragraphs, and iconterm in all places under decoNote. Maybe the solution is to add key, source, and reg to term, and then we can blow away iconterm. So decided. How does this discussion of term affect things like Briquet for watermarks? You could use term and also use bibl in the normal way to spell out the actual reference to Briquet the work (as opposed to the Briquet reference number). Also can be used for Stegmuller. Some tension because are they really terms, or are they really bibls? Lou: terms work well for a lot of things we have looked at, but not things like Stegmuller. Seems for this that one should use ref. For things like Briquet, where there is no term to be referenced, only a number, term doesn't work so well. Another example is the Index of Middle English Verse. Taxonomy versus bibliography. Documentation needs to clarify when to use term and when to use ref. Paratext: Danes are using this for pagination and foliation, also in Eva's examples. Also being used by the Danes as a place to record signatures, catchwords (which cannot be tagged as such). This is really no good. Peter Kidd: foliation is a unique enough thing that it should have its own element. Should foliation have attributes, like type of numbering (Arabic), location, when they were done (unresolved). Difficulty in dealing with paratext because it has become a catch all for leftover things. Difficulty also in the position of descriptive components in description text. Right now, we can only have paratext occurring once, which is problematic. Consuelo proposes that we have a tag called foliation. Foliation, says Peter Kidd, is mostly modern, and is therefore different than other things in paratext, like running heads and readers catchwords. Foliation (which will be defined to include pagination) has a content model of p+. Marginalia: Discussion of if these are really texts. But for the Danes, these are viewed not as texts but as marginals. Maybe the name is the problem. "Additions" suggested and carried. Order of items in physDesc: Items in physDesc now to be in any order. Lou: order cannot be flexible unless they can also be repeated. Lou claims that input, output and storage are all separate (although not easily). We must spell out why items should not repeat VERY STRONGLY in documentation. SecFol: needs a good definition. Needs a place to live. Examples from catalogs. If we could find a more generic name for this it would be good. Condition: left for another time. Binding: likewise History: likewise AdminInfo: likewise All of these above really seemed fine in the review on Wednesday. AdminInfo: Merrilee, pass around look at, get some examples. History: Consuelo provide examples Binding: Eva provide example, rest of codicology (except script, which goes to Consuelo) Peter Robinson: persName, respStmt Peter Kidd: decoration Ambrogio, contents in Italian Agreed that discussion will continue on EAMMS list. 12th November everyone will have posted something. >From recap 17 October 1999 Attested and correct do these belong on other elements other than author, persName and title? Not sure that secFol goes in physDesc (this was decided in Rome). On #10, use of attested in , , ,

. This is problematic in combination with type attribute values defective and supplied. Summary of changes to be made to the DTD 1. Rename as ; remove ; allow PCDATA, , within the contents of 2. Add new phrase-level elements and within (somehow, Lou to figure out a good content model 3. Add ATTESTED and CORRECT (?) attributes to , and 4. Add ROLE attribute to <persName> 5. Add <secFol> as a child of <physDesc> with (p+) content. [giant NOTE: we never formally decided if <secFol> belongs in <physDesc> and this should still be considered as under discussion.] 6. Add <foliation> as a child of <physDesc> with (p+) content (not within <paratext>) 7. Allow <decoNote> within <binding>, <bindingDesc> and <msItem> 8. Rename <marginalia> as <additions> 9. Rename <abstract> as <summary> 10. Add TYPE attribute to <incipit>, <explicit>, <rubric>, and <summary> [note: still under discussion, adding ATTESTED and CORRECT attributes to < incipit>, <explicit>, <rubric>] 11. Remove LEAF option from TYPE attribute of <dimension> (but retain LEAVES} 12. Add OTHER as another value of TYPE attribute on <decoNote>. Remove SIZE attribute. 13. Allow children of <physDesc> to appear in any order (but preferably not repeating). Summary of suggested changes to documentation Definition of depth needs to be worked on (Peter Kidd). 1. In definition for "from" attribute in locus, should be folio and not page. 2. Current definition of the "supplied" on locus attribute makes no sense. 3. Peter Kidd and Consuelo have documentation for msIdentifier 4. Group is fairly agreed that idno attribute "type" should go away or receive less weight in documentation. 5. Definitions and examples in Peter Kidd and Consuelo's document for altName in msIdentifier, and they will work on making these better 6. Definition in documentation of extent seems to be flawed and not consistent with what has been decided. 7. The way that msWriting is laid out is confusing in the documentation 8. Marginalia: needs a better definition, needs examples (Matthew has). 9. Condition: in definition, strike words: "in its original state". 10. Definition of surrogate(s) needs to be fixed. 11. And it's musicNotation, not musicNote (documentation) 12. Lou (followed eventually by PR and PK) wanted it spelt out that decoNote contains a DISCUSSION of decoration, and that the attributes state what the discussion is about. Furthermore, the attributes and use of the decoNote element need to be very clearly spelled out in the documentation. 13. Peter will "shake his money box" to get Peter Kidd and Anne K. together with some others to further discuss decoration. 14. Because of new content model, we must spell out why elements should not repeat VERY STRONGLY in documentation. Summary of outstanding items for discussion. 1. Look at status attribute more generally, because this was unresolved in Prague. 2. What to do with multiple foliations? 3. In msItem, consensus is that locus should be allowed to appear anywhere, not just at the beginning. And all elements in any order. 4. What to do about watermark? Watermark needs to be encoded separately as an element or an attribute, perhaps under support. 5. In history, attribute currently called conjecture, needs to be changed. Dated and datable added back in as attributes but related to origPlace and origDate. 6. Should surrogates be plural? Should is be surrogates with surrogates inside, as with binding? Type = gmd is confusing for non-librarians. 7. Discussed but undecided for persName: key attribute for names as in PhiloBiblon and Brown Woman Writers Project. 8. Consuelo to bring back discussion of incipit types, etc. on email. 9. <persName> versus <respStmt>: Peter Robinson to type this up on email 10. Merrilee will do a list of dates, places, collation formulas to show different ways of representing these items and we will see if these can be reasonably handled through character entities. 11. Problem we are missing (I think) the capability to have "lists" in any of these^Å. 12. Peter Kidd made a suggestion that we might want a phrase level element for material or medium, which could eliminate medium in handDesc. Never fully discussed. 13. Relates to discussion of decoNote and border versus margin. Lou feels the need for better definitions, or leans towards eliminating. Belinda suggests putting this on the EAMMS list, for clarification. 14. Should foliation have attributes, like type of numbering (Arabic), location, when they were done (unresolved). 15. SecFol: needs a good definition. Needs a place to live. Examples from catalogs. 16. Condition: left for another time. 17. Binding: likewise 18. History: likewise 19. AdminInfo: likewise 20. All of these four above really seemed fine in the review on Wednesday.