[tei-council] Fwd: Facsimile meeting, 6/20

[Lou Burnard]

Conal wrote:

>> 1) The header <pg> element is very specific to a codex structure. We
>> discussed changing this element to something more general such as
>> <sourceImage> or even <sourceMedia> (which leaves the door open to
>> other media besides image files). This element would contain a pointer
>> to class milestoneLike, so one could point not only to <pb/> but to
>> other milestones as well (<cb/> for example). Presumably once the
>> physical bibliography work is incorporated into the TEI this kind of
>> functionality would be directly available there as well.
> 
> I don't follow this at all. As I see it, the point of <pg/> is to
> model the flat surfaces on which texts are inscribed (call them pages
> or not). Perhaps <pageDesc> would be better.
> 
> I would be amenable to renaming <pg/> to <surface/> or <plane/> or
> something, but I think sourceMedia or sourceImage are open to
> misinterpretation (i.e. that they represent electronic image files or
> something). I think it's important that we keep the distinction clear
> between the <pg/> (or however it's named) which describes the physical
> page, and the image media (e.g. TIF files).
> 

Let me reiterate that I agree with Conal on this one -- the purpose of 
this element is to define the two-dimensional space within which 
(potentially) writing occurs, and of which we have a non-textual
representation. That collection of non-textual representations 
constitutes something that is like a text in that we can "read" it, 
which is why I propose we should wrap them all in a <text>like element.


> The relationship between the area and graphic elements is indeed
> defined only through their relationships to the page which they belong
> to. In the case of the area elements, they represent areas on the page
> which have some analytic function, whereas in the case of the graphic
> elements, they represent graphical facsimiles of the page, or a
> specific part of the page.

I agree with this too.

> 
>> We
>> recommend removing <area> from <pg> and instead allowing several
>> <graphic> tags which could point to the same image, but with different
>> coordinate values attached.
> 
> This is already allowed, so that's not an issue, but why remove <area/>?

I would remove the need for area at all, by making <zone> (or whatevrer 
we call the thing) self-nest.

> 
> The problem with this (and the raison d'etre for <area/>) is that you
> may have multiple versions of those images. If you want to link each
> line of the manuscript to a portion of a "visible-light" image, a
> portion of a UV image, a portion of an "access" image, a portion of a
> "master" image, etc, then you will need to duplicate a lot of
> graphical data. 

I don't follow this argument, sorry. I would do this by saying

<zone>
   <graphic url="xyz.png"><!-- this is the UV image -->
   <graphic url="abc.png"><!-- this is the access image -->
   <zone xml:id="line1" coords="5,6,7,8">
     <!-- if you had an additional image of line1 it would behere -->
   </zone>
   <zone xml:id="line2" coords="5,6,7,9">
     <!-- if you had an additional image of line2 it would behere -->
   </zone>
</zone>

<zone> co-ords are always understood relative to their sibling graphic, 
if there is one, or to that of their parent if there isn't


The point of <area/> is to support this analysis - you
> relate the lines of text to <area/> elements, and hence indirectly you
> have related the lines of text to any <graphic/> elements which belong
> to that page (and whose bounding box overlaps the bounding box of the
> area).
> 

Could you give us an example?