[tei-council] encoding page scans

[Dot Porter]

I agree that it is be preferable to provide image file references via
indexing - either through a  METS file or a list of files in the TEI
Header -  rather than including them in the text encoding itself using
something like pb/@url. My main reason is that a single page in TEI
may point to multiple scanned images - the same manuscript page under
different lighting conditions, for example. Building those links into
the pb element would make it cumbersome to link one encoded page to
several different files, while a index could group images of the same
page together providing a single reference for the pb.

Going a step further, what if we want to create relationships between
areas of that page scan and the corresponding range in the TEI text?
Is this something that the TEI should cover, or is it better to rely
on other standards (METS, SVG)? The Edition Production Technology[1]
depends on @coords, which can be added to any tag and which indicates
where the tag contents reside on the image. Unfortunately this only
allows for one set of coordinates, even if there are multiple image
files for the same page. For another project, I've been working on a
system for encoding multiple sets of coordinates in a METS Structural
Map (stored in a separate file, rather than as a wrapper for the TEI),
and it seems to work pretty well. The UVic Image Markup Tool[2] uses
SVG within the TEI body to link to both file and coordinates; another
approach might be to have a TEI module for incorporating image files
and their areas in a project.

Dot

[1] http://beowulf.engl.uky.edu/~eft/EPPT-Demo.html
[2] http://www.tapor.uvic.ca/~mholmes/image_markup/

On 12/14/05, Conal Tuohy <Conal.Tuohy at vuw.ac.nz> wrote:
> Afternoon all! My first post on the TEI Council list is about encoding
> images of page scans in TEI.
>
> A couple of months ago Jamie Norrish started a short thread on TEI-L
> about this issue, but I don't feel that the issue has been adequately
> addressed. Of course, it may be that I've missed something in P5 and
> that this is now all sorted. I hope so :-)
>
> If I haven't missed anthing, then at the moment there isn't a really
> good way to encode these scans (they are not figures, but graphics
> having a different relationship to the text). Many people are encoding
> these in TEI, but there's no consensus on how to do it. Recently I've
> come across another TEI customisation in which the URIs of scanned pages
> are encoded as pb/@url. I've seen others in which it is encoded as
> pb/@entity (a reference to an unparsed entity, like P4's
> figure/@entity). There are other practices in use too.
>
> At the NZETC we are encoding page scans (in P4) using a list of figure
> elements inside a note in the TEI.2/teiHeader/fileDesc/noteStmt, each of
> which is linked to the corresponding pb element with a @corresp. It
> seems awkward (to put it mildly) to encode the figures in a notesStmt,
> but it seemed preferable to encoding them as part of the text (as had
> been our practice).
>
> Of course METS provides one solution. But it seems like overkill to add
> a METS wrapper around a TEI file just to support a single feature which
> (to me) seems already like a natural piece of TEI, and which has several
> times been hacked into TEI anyway. In the earlier thread, Christian
> argued that the images were alternate representations of the whole text,
> and hence didn't belong in the file at all. I can see his point (I
> think), but I don't find it convincing.
>
> Can we establish a standard mechanism in TEI for this purpose? Off the
> top of my head I would prefer to nest a graphic element inside a pb, but
> to me the important thing is just that some simple mechanism is provided
> within the standard TEI schema without customisation.
>
> Cheers
>
> Con
>
> PS incidentally, I note that graphic/@scale has type data.probability.
> Shouldn't this be a real number?
>
> --
> Conal Tuohy
> Senior Programmer
> +64-4-463-6844
> +64-21-237-2498
> conal at nzetc.org
> New Zealand Electronic Text Centre
> www.nzetc.org
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>


--
***************************************
Dot Porter, Program Coordinator
Collaboratory for Research in Computing for Humanities
University of Kentucky
351 William T. Young Library
Lexington, KY  40506

dporter at uky.edu          859-257-9549
***************************************