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

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


Last message.

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


Hi Conal,

I think our proposal does generalize yours a lot, but it still includes
everything you need, as far as I can see; you can associate any set of
coordinates on any image with any block of markup or milestone. Is that
not the case?

I think this might be easier to evaluate if we had a description of some
data which we could mark up under the two systems, to make sure that we
are fulfilling the needs of pg, as well as allowing more varied usage.
I'm pretty sure we were able to cover what's in Dot's example document;
do you have any others we could have a go at?

Cheers,
Martin

Conal Tuohy wrote:
> Hi Martin
>
> 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
> appropriate page.
>
> 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
> <area/>).
>
> Does that make sense?
>
> Cheers
>
> Con
>
> 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
>> header:
>>
>> <sourceMedia type="hi-res" corresp="#page_5">
>>         <graphic url="Bodley340_157r_hi.jpg" />
>> </sourceMedia>
>>
>> <sourceMedia type="low-res" corresp="#page_5">
>>         <graphic url="Bodley340_157r_lo.jpg" />
>> </sourceMedia>
>>
>> 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" />
>> </sourceMedia>
>>
>> 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.).
>>
>> Cheers,
>> Martin
>>
>> 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
#####
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