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

Dot Porter dporter at uky.edu
Tue Jul 17 08:21:00 EDT 2007


---------- Forwarded message ----------
From: Conal Tuohy <conal.tuohy at gmail.com>
Date: Jun 22, 2007 2:10 AM
Subject: Re: Facsimile meeting, 6/20
To: Dot Porter <dporter at uky.edu>
Cc: Syd Bauman <Syd_Bauman at brown.edu>, Martin Holmes <mholmes at uvic.ca>


Hi Dot, Syd and Martin

Sorry i couldn't make this meeting, and I've been off work with a
cold, so I'm playing catch-up.

On 22/06/07, Dot Porter <dporter at uky.edu> wrote:
> Hi Syd, Martin, Conal,
>
> Here are the notes from yesterday's meeting between me, Syd and
> Martin. We took a look at the facsimile odd and came up with several
> recommended modifications:
>
> 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).

I can see how you might want to extend this to handle other types of
media; audio for instance, but I don't think that's a great idea at
this stage. Audio recordings of a text might not be broken down into
pages (as images typically are), and they would have no graphical
projection, but only time markings. They would be quite different, in
short. The encoding is already complicated enough handling graphics.

> 2) We also discussed making a @sourceMedia or @sourceImage attribute
> available to milestoneLike elements (not only <pb/>) in the text. This
> could allow for two-way linking (so we could link from the text into
> the header), but would also serve the same purpose as @URL - to link
> to external files.

I don't see the use case for generalising to using <cb/> or other
milestoneLike elements in place of just <pb/>. Can you explain what
one might expect to gain by it? I don't think it's necessary to
achieve what you want (though I'm not exactly clear as to what this
might be), and it just seems like an extra complication to me.

> 3) In the ODD file with my modifications (though I'm not sure for
> Conal's file that I modified), <area> is nested within <pg> along with
> <graphic>. There is no clear relationship between the <graphic> and
> <area> elements except that they are within the same <pg>.

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.

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

> So if I want to store coordinates for
> every line on a manuscript page, I have a separate <graphic> for each
> line, each with different coordinates attached:

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

> <pg start="#D157r">
>   <graphic corresp="#D157r20" url="Bodley340_157r.jpg" coords="1,2,3,4"/>
>   <graphic corresp="#D157r21" url="Bodley340_157r.jpg" coords="5,6,7,8"/>
>   <graphic corresp="#D157r22" url="Bodley340_157r.jpg" coords="11,121,3,14"/>
>   <graphic corresp="#D157r23" url="Bodley340_157r.jpg" coords="15,352,388,124"/>
>   <graphic corresp="#D157r24" url="Bodley340_157r.jpg" coords="11,26,33,74"/>
> </pg>
>
> We didn't discuss how this might work when mapping betwen different image files.

Yes ... see above. :-)

> (Martin and Syd, I didn't take very good notes of this discussion so
> please chime in if I've misrepresented our discussion.)

Talk to you all again soon!

Con


-- 
***************************************
Dot Porter, University of Kentucky
#####
Program Coordinator
Collaboratory for Research in Computing for Humanities
dporter at uky.edu          859-257-9549
#####
Editorial Assistant, REVEAL Project
Center for Visualization and Virtual Environments
porter at vis.uky.edu
***************************************



More information about the tei-council mailing list