[tei-council] Fwd: Facsimile meeting, 6/20
dporter at uky.edu
Tue Jul 17 08:21:12 EDT 2007
---------- Forwarded message ----------
From: Conal Tuohy <conal.tuohy at gmail.com>
Date: Jun 22, 2007 2:21 AM
Subject: Re: Facsimile meeting, 6/20
To: mholmes at uvic.ca
Cc: Dot Porter <dporter at uky.edu>, Syd Bauman <Syd_Bauman at brown.edu>
Following up on this discussion a bit late ... sorry for that.
I think your suggestions are based on based on a misunderstanding of
the intended role of the <pg/> (page) element in the draft schema:
It is emphatically NOT a representation of an image file (for which
the tei:graphic should be used).
Neither is intended to be used as a unit of analysis (i.e. to say -
here is a region on the page). The <area/> element is intended to be
used for that. So in your example below, the area on the page occupied
by column 1 would be represented by an <area/> element within the
I think if you consider the pg element in that light, and the <area/>
element as your unit of graphical analysis, then you can see that you
can associate arbitrary areas on a page with arbitrary bits of text.
When you come to present a graphical view of a piece of text, you can
pick from any of the graphic elements which are in the same pg as the
area, so long as those graphic elements have bounding boxes which
overlap the area's bounding box (i.e. so long as the area of the
coverage of the graphic overlaps with the area of coverage of the
Does that make sense?
On 22/06/07, Martin Holmes <mholmes at uvic.ca> wrote:
> Hi all,
> This is really clear -- thanks indeed. On reflection, I like the idea of
> mapping FROM the <sourceMedia> element TO the document element (<pb />
> etc.) best, because it would allow multiple images/media to be
> associated with the same document element. So you might have this in the
> <sourceMedia type="hi-res" corresp="#page_5">
> <graphic url="Bodley340_157r_hi.jpg" />
> <sourceMedia type="low-res" corresp="#page_5">
> <graphic url="Bodley340_157r_lo.jpg" />
> with this in the text:
> <pb xml:id="page_5" />
> so that the same page element can be associated with different
> resolutions of graphic. Also, you could then have this:
> <sourceMedia type="hi-res" corresp="#page_5_col_1">
> <graphic url="Bodley340_157r_hi.jpg" coords="10, 20, 1000, 500" />
> and in the text:
> <cb xml:id="page_5_col_1" />
> where the column can be associated with a segment of the page image.
> This seems to me to give us complete flexibility in associating any part
> of any image with any element on the page, and letting the rendering
> process determine the best image to use for a particular context based
> on all the options available. We also discussed putting an optional
> mimeType attribute on sourceMedia, so that if you want to make it clear
> that the file is (say) a QuickTime movie, you can do so.
> I think it's important that this be a generally applicable system (any
> appropriate element in the text, any type of media file) rather than
> specific (images and codex pages) because lots of real-life projects are
> not constrained to pages (e.g. the Graves diary, which has enclosures of
> postcards, bullfight tickets, telegrams etc.).
> Dot Porter 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.
> > 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.
> > 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>. 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. 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:
> > <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.
> > (Martin and Syd, I didn't take very good notes of this discussion so
> > please chime in if I've misrepresented our discussion.)
> > Thanks,
> > Dot
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca)
> Half-Baked Software, Inc.
> (mholmes at halfbakedsoftware.com)
> martin at mholmes.com
Dot Porter, University of Kentucky
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