It must be something in the air this spring - we were discussing this 
issue yesterday, also in the context of how we'd encode books in a 
Fedora repository. It seems like the decision could be made 
differently for monographs and for serials. The way we're 
TEI-encoding these materials now, we have a single TEI file for a 
monograph or a journal issue, and for page-image based works, we 
divide the work into <div1> chunks representing chapter- or 
article-level sections. However, for journals (or anthologies, I 
suppose) the articles are really the primary access level, and we'd 
certainly want them to be represented as Fedora objects (children of 
an Issue-level object). That may or may not be the case for 
monographic works, where the Volume tends to be the main object of 
interest. And those decisions about the granularity of our Fedora 
objects will definitely affect our METS encoding decisions.

One way to accommodate a TEI datastream in a more granular repository 
might be to include the TEI <div1>s in the child objects, and define 
and invoke them as general entities in the parent TEI, resolving (via 
Handles?) to the the child datastreams.

At 8:15 AM -0400 5/10/07, Riley, Jenn wrote:
>Hi Tim,
>We're facing this issue as we're implementing a new Fedora-based
>repository at IU. We need a "book-centric" representation (one METS with
>a structMap and fptr for all pages, a dmdSec with a MARCXML record,
>etc.) for our page-turner <>, but
>that's not necessarily what our repository needs. It needs things like
>page-level technical metadata for page images, a place for a TEI
>representation of the whole book, etc. I've very much come to the point
>of view that there is no one right representation for all purposes, but
>that there are many that each serve their own purpose. Our repository
>has one METS syntax for ingesting the book, a set of different syntaxes
>for storing the various parts internally, and (potentially, we haven't
>actually done this yet!) a different one for sharing the "book" with
>other repositories. I've been thinking all of these are separate from
>the one we generate for the page-turner, but it may be one of the
>existing representations will work for that too - we're still in the
>process of making that decision.

Peter C. Gorman
Head, University of Wisconsin Digital Collections Center
218 Memorial Library
Madison, WI 53706
[log in to unmask]
(608) 265-5291