[tei-council] Further update on PH

[Arianna Ciula]

Lou Burnard wrote:
> How about 
> 
> "It should be noted that, as elsewhere in these Guidelines,  this
> chapter places more emphasis on the problems of representing the
> textual components of a document than on those relating to the
> description of the document's physical characteristics such as the
> carrier medium or physical construction. These aspects, of particular
> importance in codicology and the bibliographic study of incunables,
> are touched on in the chapter on Manuscript Description (<ptr
> target="#MS"/>) and also form the subject of ongoing work in the TEI
> Physical Bibliography workgroup."

Great!


> AC] 
> AC] I think some people may understand better this note and the concept
> AC] behind it whit the help of an image of a grid superimposed on a figure.
> AC] 
> 
> A figure inside the footnote? I hope you don't mean that. I suppose a
> figure in the text might be useful, but it might look as if we were
> trying to teach is fairly elementary geometry. The footnote is just
> there as an aide memoire for those (like me) whose memory of O-level
> maths is starting to fade...

A grid superimposed on the image after the original image would be good, 
but if nobody thinks is necessary may be I am just underestimating our 
audience.

> AC] 
> AC] - "Since this image contains more than one page however, and has not
> AC] been cropped, it might be better to define two distinct surfaces, one
> AC] for each page."
> AC] 
> AC] I would add "...one for each page, including the illuminated margins" to
> AC] make clear that we are not considering the writing frame only as cropped
> AC] section.
> AC] 
> 
> have added ", including its illuminated margins" before the
> fullstop. But note that this may need further revision if Conal
> persuades us that "surface" means something different.

Sure.
> 
> AC] - written part --> writing frame
> AC] 
> 
> Hmm, is this a technical term? I havent come across it before (and am
> not online so cannot check) I've changed it to "written area" for the
> moment. And note that we are not talking about the area actually
> marked for writing in in the original (e.g. by pricking); it includes
> margins etc.

Written area is fine, but yes, writing frame is a technical term (see 
http://vocabulaire.irht.cnrs.fr/vocab.htm when you have the network).

> 
> AC] - I think the proposal with expan/ex is great! [I asked Elena's opinion
> AC] as well and she seems very satisfied by this]. My only doubt is about
> AC] nesting. Indeed both <ex> and <expand> seem to have the possibility to=20
> AC] self nest. Has this been done on purpose?
> AC] 
> 
> Well,  <ex> (and <am>) cannot self nest. It's true that <expan> and
> <abbr> can though. The problem is both defining a content model to preclude
> this or coming up with a good reason why you might not want to. Some
> mad person will always want to treat e.g. USAF as two abbreviations
> ("US" and "AF"), and hence producing two nested expansions ("United
> States" and "Air Force").... it's the TEI Way. (trademark)

Let's leave it as is then.


> 
> AC] 
> AC] - "This encoding asserts that the reading wyf found in Gg is regarded as
> AC] a correction by Parkes."
> AC] 
> AC] I am not sure about this example where @resp is within <corr> in a
> AC] <rdg>. I understand it, but I think in general an editor would use the
> AC] <lem> element, wouldn't he? it is true that <lem> can occur only once in
> AC] an <app> and therefore it would be difficult to express multiple
> AC] responsibilities on different corrections as this examples shows, but in
> AC] general to use a single reading to make a new edition you would use
> AC] <lem>.
> AC] 
> 
> It seems strange to me too, because elsewhere we use  <corr>
> only for things that are not witnessed at all, whereas here it means
> "not witnessed in the source being encoded". I am agnostic on whether
> or not to keep this discussion; removing it is quite a big change
> though.

I think it would be good to have others'opinion here. It may be just me 
seeing confusion where things are clear.

> 
> AC] - "If no other source is indicated (either by the source attribute, or
> AC] by the wit attribute of a parent <rdg>), the reading supplied within a
> AC] <corr> has been provided by the person indicated by the resp attribute."
> AC] 
> AC] As above I understand this, but the meaning of <rdg> is a bit stretched
> AC] here, since it is not a variant witnessed in a source we are talking
> AC] about in this case, but rather what is normally considered in these
> AC] guidelines as a 'supplied' string.
> 
> But it is witnessed, surely? It's in Gg. The encoding is saying  (a)
> there is a different reading at this point in a certain ms and (b)
> Parkes thinks that this different reading should be used to correct
> the others. 

But in the bracket in the prose you envisage the possibility of not 
having neither @source in <corr> nor a @wit in <rdg>....oh ..it occurs 
to me only now that I am reading that 'or' as an 'and'...one of the two 
NEEDS to be there, right?

> AC] 
> AC] - <hand xml:id=3D"mb" scribe=3D"Max Beerbohm holograph"/>
> AC] 
> AC] if <hand> will get the same attributes of the current <handNote>, this
> AC] should be:
> AC] 
> AC] <hand xml:id=3D"mb" scribe=3D"#Max_Beerbohm scope=3D"sole"/>
> AC] 
> 
> This loses the fact that Max is the author as well as the writer,
> doesn't it? But you're right that the attribute value should not be a
> string of words

what about <hand xml:id=3D"mb" scribe=3D"#Max_Beerbohm scope="holograph"/>

> AC] 
> AC] - <hand xml:id=3D"heol" n=3D"Helgi =C3=93lafsson"/>
> AC] 
> AC] Why is @n used instead of @scribe here?
> 
> No idea. I#'ve changed it to scribe for now. Do you think @scribe
> should be analogous to @key or to @ref ?

mh...could we have both? certainly @ref should be recommended, but there 
are cases in which you may want to have an internal reference system.

Also, as I think I have mentioned before, I realize that in lots of 
cases a scribe is just a numbered hand rather than a real person (we 
don't know anything about him), so neither @ref nor @key pointing to a 
<person> element would do the trick.

> AC] We could also add in the prose that when the sequence of authorial=20
> AC] intervention in a manuscript cannot be determined with certainty=20
> AC] (subjective time) the @resp and @cert attributes should be used within=20
> AC] <subst>.
> AC] 
> 
> Not sure what you are implying here? 

Just that the prose could expand on the use of att.editLike in <subst> 
as it does for other elements. In this element, the 
responsibility/certainty on the determination of a sequence of 
alternative changes helps to say: look this is what I think the author 
has done, but the hands don't really allow me to be sure. I think my 
author wrote first A, then deleted it and then substituted it with B. He 
may have first added B and then deleted A...who knows? 'subjective time' 
I think it's called in genetic editions.

> AC] - I understand the example with @varSeq, but in general I think @varSeq
> AC] should be used to express dependency between variants found in different
> AC] witnesses as the specs say, rather than for tracking the genesis of
> AC] authorial manuscripts (where @seq should be used instead).
> AC] 
> 
> This is another occasion where I am simply preserving what was
> originally proposed by the chapter without really thinking it is a
> good idea. Maybe this possibility should be explicitly removed, or at
> least clearly distinguished? 

I would remove it to avoid confusion, but we need others'opinion.

> AC] - "The rules for combinations of the <add> and <del> elements, and for
> AC] the interpretation of such combinations, are similar:"
> AC] 
> AC] I think that after this section something should be said about the new
> AC] @seq element that allows to disambiguate the sequence of interventions.
> 
> OK: how's this.

?


> AC] 
> AC] - "The <note> element allows us to record that the scribe wrote nota,
> AC] but is not well-adapted to show that the nota points both at all four
> AC] lines and at two pairs of lines within the four lines."
> AC] 
> AC] Well...these are the cases where we can say that the digital facsimile
> AC] elements facilitate representation even if they privilege an image-based
> AC] approach. I assume the physical bibliography chapter will cope, as
> AC] far as the text-base approach can deal with this, with this sort of=20
> AC] encoding in the future.
> AC] 
> 
> OK, how's this:
> 
> <p>At the lowest level, all such features could be captured by use of
> the <gi>note</gi> element, containing a prose description of the
> manuscript at this point, enhanced by a link to a visual
> representation (or facsimile) of the feature in question.  
> Markup languages in general are limited in their abilities to describe
> all possible features of layout or realization.  For example,...

Ok


> AC] 
> AC] - again, shouldn't <fw> be member of att.typed?
> 
> Why should it? I suspect you of being a secret member of FTG (the Front for
> Type Globalization).

Because it can be so many different things...yes I am a member, is it 
illegal?


> AC] 
> AC] - I wander whether <floatingText> should be mentioned in this chapter.
> AC] 
> 
> Well it could be, but so could any number of other things e.g. <div>
> <head> <p>... or do you think it is particularly important in
> transcription? 

I just thought of transcriptions of letters within novels (mentioned 
both by Julia Flanders and Elena Pierazzo in the TEI list, I think) 
which are not used in any of the examples here. It isn't necessary. It 
was just a thought and you are right that we can't include everything.


> AC] - I think I agree with Matthew that <unclear> is a bit redundant and=20
> AC] <supplied> should be used instead eventually in combination with=20
> AC] <damage> or detailed values for @reason.
> AC] 
> 
> I beg to differ. <unclear> encloses text that is (you think, but
> you're not sure) present in the source. <supplied> encloses text that
> you know is not there, but ewhich you think should be.
> 
> I agree that the distinction between <unclear> and <damage> is pretty
> vague though: is that what you meant?

It could be improved....will have another look.


Arianna

> AC] Arianna
> AC] 
> AC] P.S. I finished reading the chapter last night, but just saw you have=20
> AC] added <am> today. I think it's good to have an element to enclose the=20
> AC] abbreviation sign; although some may complain for the proliferation.
> AC] 
> 
> It's not only to enclose abbreviation signs of course: probably a
> better exmaple is needed to make this clearer.
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

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