From mproffit@LIBRARY.BERKELEY.EDU Tue Oct 26 10:12:57 1999
Date: Mon, 18 Oct 1999 14:24:59 -0700
From: Merrilee Proffitt <mproffit@LIBRARY.BERKELEY.EDU>
Reply-To: TEI Medieval Manuscripts Description Work Group
    <TEI-MMSS@LISTSERV.UIC.EDU>
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
<hi> 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
<p> 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.

<persName> versus <respStmt>.  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.

<iconterm> 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 <incipit>, <explicit>, <rubric>, <summary>.
This is problematic in combination with type attribute values defective and
supplied.

Summary of changes to be made to the DTD

1. Rename <msSummary> as <msHeading>; remove <msHeading>; allow PCDATA,
<langUsage>, <author> within the contents of <msSummary>

2. Add new phrase-level elements <signatures> and <catchwords> within
<collation> (somehow, Lou to figure out a good content model

3. Add ATTESTED and CORRECT (?) attributes to <author>, <persName> and <title>

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.
