Child pages
  • Meeting Notes 02032009

This space has moved to IU's Confluence.
It is located at

Skip to end of metadata
Go to start of metadata


Rob Chavez, Jon Dunn, Nate Trail, Bill Parod (scribe)

We want to define our scope broader than just imaged text, to include bound materials more broadly, for example music.

We defined one method for books which for now we are calling 'getTOC'. It will return a potentially nested <div> structure. Each page is expressed in a DIV element containing an xlink:href attribute to a screen size image of the page. A typical 'screen size' would be in the range of 640 pixels wide, but the specific size is left to the provider. Each page DIV will also contain an additional link attribute to the page's Asset Action. We didn't name that attribute. We'll discuss this attribute naming with other groups, as other Action Groups might also need to encode explicit reference to an item's Asset Actions.
Page DIV elements can also include a 'label' attribute.

GetTOC can also include DIV elements that don't include page links, but that are used to mark structural - to group pages and/or groups of pages. DIV elements that are purely structural and do not contain a page link are required to have a @label attribute. Finally we decided that the entire DIV structure should be enclosed in a <response> element. We did not discuss other contents of the <response> element.

We briefly considered if there is need to support multiple hierarchies for bound items. We discussed the typical scenario of a logical structure of a book, expressed in transcript markup differing from page level markup for that book. We decided that structured text access and page image access for a book are best treated with separate Asset Action Groups.

We also considered if a getPages() Action, which returns a flat list of pages, in addition to the potentially nested getTOC() action would be useful. We decided that a flat representation could be easily obtained by transforming the getTOC response and so a getPages Action is not needed.

We considered if the getHeader action, defined in an earlier draft, is useful. We decided that its purpose is usually descriptive and that function is best left to the item's metadata Actions. A getHeader Action might be useful in a homogeneous collection of TEI texts where its format would predictably be a TEIHeader, for example. But is less useful in a heterogeneous collection. We prefer to eliminate it and rely on metadata actions in the default or metadata action sets for description of the bound item.

Some questions we noted for our next discussion:
What Asset Actions are required for a 'page' object?
What can/should the <response> element contain?

We will meet at the same time next week (Tuesday 4:00 EST), but shift topic to the hi-res image Asset Actions, which Nate is convening, Bill is on, and Jon and Rob have interest. We'll return to the Page Imaged Book discussion at a latter meeting after we've defined image actions more fully.

  • No labels