[tei-council] MS Manuscript Description chapter: notes

[Arianna Ciula]

Hi,

I have sent the MS chapter to the editors (I have probably just added a 
full stop..don't remember) and here are my notes...sorry it's quite 
long, but some of these are things that need to be corrected, while 
other comments may ignored if useless right now.

- "The <msDesc> element will normally appear within the <sourceDesc>
element of the header of a TEI conformant document, where the document
being encoded is a digital representation of some manuscript original,
whether as a transcription, as a collection of digital images, or as
some combination of the two."

I think something should be said here about the new facsimile section on
the Representation of Primary sources chapter, at least in a footnote.

- att.measurement/att.dimensions

I know that thanks to Syd's work theseclasses had reached a more stable 
state
(and sorry it didn't get enough feedback or attention from us when
needed), but it seems really silly to have slightly different
definitions of @unit and @quantity (they should be uniformed to what is
now in att.measurement, in my opinion).

- I think the attribute @targets for <locus> should be @target instead,
for consistency with <ref>
  - by the way, this attribute of <locus> may conflict with @facs in its
function when the PH module is loaded even if here we are not 
transcribing but describing a manuscript. This raises the question: can 
the facsimile element be used in combination with a manuscript 
description without a transcription? I think it should.
We could may be mention that if the PH module is also used, the @facs 
attribute is preferred over @targets to connect less directly but more 
explicitly to image files.

- "The reference #txt182 in this example is assumed to reference the
section of the manuscript ‘up to fol. 182v’ which has been transcribed
elsewhere in the current document; the references
http://www.images.fr#F33R and http://www.images.fr#F59V link to images
of the relevant pages, held presumably in an image archive."

The first part of this sentence doesn't seem to refer to a pointer in
the example (#txt182 is not in the example). Probably the example has
been changed and the prose left as it was.

- example with multiple foliation schemes: TO DO

I could provide one.

- "In order for this second Hoccleve example to be valid, a <person>
element must be provided which has the value HOCCL1 for its xml:id
attribute; the same value will be used as the key attribute of every
reference to Hoccleve in the document (however spelled), but there will
only be one <person> element with this identifier."

@ref should be used instead of @key in the example and substituted in
the prose.

- "Similar mechanisms may be used to create and maintain canonical lists
of places or organizations, but no specific elements are defined for
this purpose."

There are now...so we need a reference to the new section on places here.

- the formal definition of <secFol> in the Specs is "(secundo folio) The
word or words taken from a fixed point in a codex (typically the
beginning of the second leaf) in order to provide a unique identifier
for it." This seems general enough but the prose is too restricted to 
one tradition and I think should be changed:

from:
"The <secFol> element (for ‘secundo folio’) is used to record the
opening word or words of the second leaf of a manuscript. Since these
words differ from one copy of a text to another, the practice originated
in the middle ages of using them when cataloguing a manuscript in order
to distinguish individual copies of a work in a way which its opening
words could not."

to something like the following:
"The <secFol> element (for ‘secundo folio’) is used to record the
“identifying phrase” (called also dictio probatoria) taken from a fixed
point in a codex.
Since these words differ from one copy of a text to another, the
practice originated in the middle ages of using them when cataloguing a
manuscript in order to distinguish individual copies of a work in a way
which its opening words could not."

- I wander whether <institution> should actually be part of
model.placeNamePart.
In this way, leaving the content model of <msIdentifier> as is, you 
would have a sequence
with:
* one or more elements -that may occur only once- defining the location 
in general (members of model.placeNamePart_sequenceOptional)
* one or two elements (repository/collection) defining the internal 
location

At the same time though <institution> seems to be a special case of what
is now <orgName>. Should this be at least mentioned?

- "As mentioned above, the smallest possible description is one that
contains only the element <msIdentifier>; internally to that element,
the three subelements <settlement>, <repository>, and <idno> are
required, since they provide what is, by common consent, the minimum
amount of information necessary to identify a manuscript."

But this is not what is enforced by the schema for <msIdentifier> which 
is - rightly in my opinion - more permissive.

- "In the latter, however, the subelements, if used, must be given in 
the order specified above; they may be repeated, with the exception of 
<rubric>, <incipit>, and <explicit>, each of which can appear only once."

unless I am wrong, should be substituted with:
"In the latter, however, the subelements, if used, must be given in the 
order specified above; they may be repeated, with the exception of 
<rubric>, <incipit>, <finalRubric>, <textLang> and <explicit>, each of 
which can appear only once."

- "Neither <msItem> nor <msItemStruct> may contain untagged running 
text, although <msItem> may contain one or more <p> elements as an 
unstructured alternative to the possible components listed above."

but also <msItemStruct> can contain, alternatively, one or more model.pLike.

- the examples with <expan> must be checked to see whether <ex> needs to 
be used instead.

- "If it is desired to retain the form of the author's name as given in 
the manuscript, this may be tagged as a distinct <name> element, nested 
within the <author> element with the normalized form of the name on its 
reg attribute. Alternatively, the normalized form of the name may be 
supplied as the value of a reg attribute on the <author> element."

The last sentence should be taken out.

- Specs for <textLang>: in the description for the attribute 
@mainLang/@otherLangs a link to the IANA Language Subtag registry could 
be added (http://www.iana.org/assignments/language-subtag-registry).

- if the work on stemmata will be included in the guidelines, a 
reference to that could be included under the 'Filiation' section in 
this chapter.

- I am not sure the example with the Old Church Slavonic language is 
appropriate since there is already a IANA subtag - Cyrs - for Old Church 
Slavonic written in Cyrillic. Same is valid for Russian and Greek.

- "<measure type="leaves" unit="count" quantity="10">10 Bl.</measure>"

I think this is wrong. 'count' cannot be a unit. The leaf is the unit here.

- I understand why the attribute @scribe for <handNote> has as value 
data.name, since most of the times we don't know much about scribes 
besides what their hand witnesses, but when we do, I think this 
attribute could be used as pointer to a person element. How could we 
allow for this second use?
The same attribute name (@scribe) has data type data.code for <hand>. 
[but see below]

- While I was looking at <handNote>, I realised how confusing is the 
situation with hands and this reminded me of an email read quickly after 
my holidays (30th of July TEI list - conversation between Elena 
Pierazzo/Lou).
In summary we have the elements:
- hand/ - PH
- handList - PH
- handShift/ - PH
- handDesc - MS
- handNote - MS

<hand> and <handNote> share various attributes, some of which describe 
the same thing with different names (e.g @ink vs. @medium). I propose that:

1) clean attributes for <hand> (take out redundant attributes such as 
@first) and include in a class e.g. att.handwritten:
scribe
hand
script	
medium	
scope

2) add additional attributes to <hand> e.g. @resp

3) model.handDescPart should contain only <handList>

4) <handDesc> can contain loose <hand> or model.handDescPart

4) <hand> should not be empty and include <handNote>

If it is  too much trouble for people to load the MS module when they 
just want a list of hands, they could still use <handList> within the 
profile description; although I would be tempted to eliminate this 
possibility to avoid confusion.

- the elements <origin>, <provenance> <acquisition> and <custEvent> are 
all events related to objects and have the same content. It would make 
sense to group them into a class e.g. model.objEventLike if they were 
all used by the element <history>, which currently uses them all, expect 
<custEvent> which is included in <custHisoty> instead.
This chapter is very granular and therefore useful, but sometimes new 
elements are used where old could be adapted (e.g. history and custHistory).

- under the surrogates section a reference could be added to the new 
digital facsimile material.

Arianna

-- 
Dr Arianna Ciula
Research Associate
Centre for Computing in the Humanities
King's College London
Strand
London WC2R 2LS (UK)
Tel: +44 (0)20 78481945
http://www.kcl.ac.uk/cch