[tei-council] Fwd: Re: Notes on chapter 11 (part one)

[Martin Holmes]

Hi Lou (and everyone else),

Thanks for doing all this. A couple of comments inline below.

By the way, Jim-lad has what we owe you from the other day.

On 11-11-10 01:02 PM, Lou Burnard wrote:
> Hello chaps!
>
> On the eurostar, I tried to apply all comments emailed by Martin, Brett,
> and Piotr during the meeting
>
> here are my comments
>
> -------- Original Message --------
> Subject: Re: [tei-council] Notes on chapter 11 (part one)
> Date: Thu, 10 Nov 2011 09:17:52 +0000
> From: Lou Burnard<lou.burnard at retired.ox.ac.uk>
> To: Martin Holmes<mholmes at uvic.ca>
>
> On -10/01/37 20:59, Martin Holmes wrote:
>> "...to identify individuals appearing in a group portraits and link them
>> to data about the person represented." [Delete "a", change "person" to
>> "people".]
> done
>
>
>
>> "...<surface>   defines a written surface in terms of a rectangular
>> coordinate space, optionally grouping one or more graphic
>> representations of that space, and rectangular zones of interest within
>> it." ["rectangular" is obsolete.]
>
> which one? Here's my revision of the desc anyway:
>
>>> defines a written surface in terms of a rectangular
>> coordinate space, optionally  grouping one or more graphic representations of
>> that space, zones of interest within that space, and transcriptions of the
>>    writing within them.

That's great. It was the second "rectangular" I meant; <zone>s don't 
have to be rectangular.

> The coordinate space, i believe, must be rectangular.

I think that's true.

>> The first example showing a zone on the left side of the page doesn't
>> make much sense; the graphic is provided as a child of<zone>, rather
>> than<surface>, so the coordinate system provided by<surface>   is not in
>> the context of anything, whereas the coordinate system provided by
>> <zone>   seems only provide the width and height of the graphic. This
>> example needs reworking, I think.
>
> Possibly we need a simpler example first, since this one is of the
> (slightly) unusual case where a zone is not topologically contained by
> parent surface. I dont understand your comment about the width and height.

I don't remember what I meant, but I like the idea of a simpler example. 
I'll try and dig something out from the Mariage project. But real-life 
examples tend to be too big.

>> The second example is much better, but it has a<desc>   on the first
>> <zone>   with a description of the content, while the subsequent<zone>s
>> have their descriptions in comments. There should be consistency here;
>> suggest<desc>   throughout.
>
> I agree we should be consistent, but I have perversely chosen to make
> them XML comments throughout

You contrary bugger.

>> "Zones need not nest within each other; they must however be
>> rectangular, as previously noted." [It's not true that they must be
>> rectangular.]
>>
>
>
> Corrected. We need an example of a non-rectangular zone though.

I don't have any of those -- IMT doesn't produce them. But I'll try and 
come up with something. Perhaps I could use an example page from the 
Despatches project.

>
>
>> "If the transcription is regarded as a text in its own right, organized
>> and structured independently of its physical realization in the document
>> or documents represented by the facsimile, then the recommended practice
>> is to use the<text>   element, provided as a sibling of the facsimile
>> element." [This suggests that a<zone>   is linked directly to a<text>;
>> what it should imply is that a<zone>   is linked to a descendant of<text>.]
>
> revised version:
>
>>   If the transcription is regarded as a text in its
>> own right, organized and structured independently of its physical
>> realization in the document or documents represented by the facsimile,
>> then the recommended practice is to use the<gi>text</gi>  element to
>> contain such a structured representation. The<gi>text</gi>  element is
>> a sibling of the<gi>facsimile</gi>  and<gi>sourceDoc</gi>
>> elements.

Perfect.

>> _______________________________________________
>
>
> On -10/01/37 20:59, Martin Holmes wrote:
>   >  11.1.1:
>   >
>   >  "<p rend="it" facs="#B49rPara2">" [Suggest changing @rend="it" to
>   >  @rend="italic" for consistency with other examples elsewhere in the
>   >  Guidelines.]
>
> Jusyt out of curiosity i checked to see whether the Glines are at all
> consistent in their suggested values for the rend attribute. No prizes
> for guessing the answer! For values beginning with "it", here are the
> results:
>
> it (25
> ital (2
> italic (27
> italics (5
>
> I obstinately think this is not entirely a bad thing.

I thought we had come to an agreement that we would avoid such 
inconsistency, because people tend to use what they find in the 
Guidelines, and interoperability is undermined when they may 
accidentally find any of four different values with the same meaning.

Can I get a bit of feedback on this? I really think it looks a bit 
shabby, as if we can't make our minds up.

That's it from me for now. Going in search of food.

It was good to see (almost) everybody again.

Cheers,
Martin


>   >  "Further discussion of the encoding choices made in the above
>   >  transcription is provided in the remainder of this chapter." [This
>   >  doesn't make much sense; the remainder of the chapter goes on to show
>   >  genetic encoding with different examples.]
>   >
>
> True. Deleted the para
>
>
>   >  "@flipping    indicates whether the patch is attached and folded in
> such a
>   >  way as to provide two writing surfaces" [Should this be "two or more"?]
>
> Not sure how that could work. I can't imagine a "flipping" surface with
> more than two writing surfaces. But if we replace patch with nested
> surface and introduce surfaceGrp I am not sure we want this attribute
> anyway.
>
>   >  Numbering of figures: some examples appear to be treated as figures,
>   >  with numbering, and some seem to be left out of the numbering scheme.
>   >  Suggest consistent identification and numbering of figures, including
>   >  all examples, since some examples need to be referred to with e.g.
>   >  "Figure 3".
>
> Yes. Will check this, but I think what happens is that all the<figure>s
> are numbered but if they have no<head>  then no heading
> is produced.
>
>
>   >
>   >  "Equally, the encoder may choose to provide only graphics without
>   >  transcription, or with a structured (non-embedded) transcription, or any
>   >  combination of the three." [Delete "with"?]
>
> yes, Revused as
>
>    Equally, the
> encoder may choose to provide only graphics without any transcription,
> to provide only a structured (non-embedded) transcription, or to provide
> any combination of the three.</p>
>
>   >  _______________________________________________
>   >  tei-council mailing list
>   >
> On -10/01/37 20:59, Martin Holmes wrote:
>   >  GENERAL COMMENT:
>   >
>   >  The whole chapter proceeds as if<sourceDoc>   did not exist, and all the
>   >  genetic material is to be embedded inside<facsimile>; then suddenly
>   >  <sourceDoc>   is used in an example without explanation. Am I missing
>   >  something here?
>
> No, this is an oversight,  Working on it.
>
>   >
>   >  (11.2 ff)
>   >
>   >  "Transcriptions of this kind are closely focussed on the physical
>   >  appearance of specific documents, needing to distinguish the traces of
>   >  different writing activities on them, such as additions, and deletions
>   >  but also other indications of how the writing is to be read..." [Delete
>   >  the third comma (after "additions").]
>
> Done
>
>   >
>   >  "then, methods of describing important extra-linguistic phenomena in the
>   >  source: unusual spaces, lines, page and line breaks, change of
>   >  manuscript hand, etc." [Suggest pluralizing "changes" for better
>   >  parallel structure.]
>   >
>
> Done
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived