[tei-council] MS Manuscript Description chapter: notes (part 1)

[Lou Burnard]

Thanks for this Arianna. Here's a quick report on how far I've got so 
far with your very helpful comments on this chapter.


Arianna Ciula wrote:

> - "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.
> 

Agreed; added a cross reference.


> - att.measurement/att.dimensions
> 
> I know that thanks to Syd's work these classes 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).

This is the result of an unresolved disagreement between the editors. 
The current situation is that
att.dimensions (members being depth, dimensions, height, space, width) 
gives you @unit, @quantity, @scope
att.measurement (members being measure and measureGrp) gives you @unit, 
@quantity, @commodity

The definitions for the attributes in common should be consistent, 
clearly, and the best way to do this would probably be to move the 
attributes not shared between the two out of the class.

The unresolved disagreement (as far as I recall) is about what the 
specification for @unit should say. I take the view that we should not 
include (as att.measurement currently does) all SI units here, but 
simply those which are most likely to be useful to text encoders, with a 
reference to the others.

> 
> - I think the attribute @targets for <locus> should be @target instead,
> for consistency with <ref>

I agree that consistency is desirable, but as you point out, this 
attribute duplicates the function of the @facs attribute available when 
PH is loaded. So the easiest thing would be to remove it.

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

Yes.

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

@facs can be used in *exactly* the same way as the current @targets -- 
i.e. without benefit of intervenming <facsimile> -- this was one of the 
things that some council members expressed reservations about, but it is 
clearly stated in PH as an option, though a deprecated one. So I have 
now removed @targets.


> - "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.

This example is most peculiar! To avoid confusion, I've trimmed it down 
to exclude the "up to fol.182v" bit completely.

> 
> - example with multiple foliation schemes: TO DO
> 
> I could provide one.

Please do!


> 
> - "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.

Done

> 
> - "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.

Indeed yes. Done. I have also added some discussion on @key as distinct 
from @ref


> 
> - 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."
> 

Fine.


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

This does seem problematic. Can an institution have more than one 
physical location? I would rather think that it can: hence it seems to 
be more like an orgName than a placeName. Maybe we should throw out 
institution in favour of orgName ?

Is a <repository> a kind of orgName or a kind of placeName? It seems 
more like the latter. the BL Sound Archive for example has more than one 
repository in different places.

No change yet, pending further contemplation.


> - "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.
> 

Wording changed:

  <p>As mentioned above, the smallest possible description is one that
contains only the element <gi>msIdentifier</gi>; good practice in all
but exceptional circumstances requires the presence of the three
subelements <gi>settlement</gi>, <gi>repository</gi>, and
<gi>idno</gi> are required, since they provide what is, by common
consent, the minimum amount of information needed to identify a
manuscript.</p>

> - "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."
> 

Correct. Also added a sentence to point ouit that msItemStruct can also 
self-nest, bizarrely. The more I look at it, the more I think this 
element is a Bad Idea, but I suppose I'd better not kill it just yet.

[... more to come later! ...]