>3) We tried two different approaches with the minutebooks: for sequences
>1-5 we assumed when there was only one page for each date entry that it
>stands alone; multiple pages became children (thus you'll see some entries
>with page1 and page2 which are actually page 2 and 3 for that date. For
>sequences 6-12, we assumed that every date would have a child page so each
>child has a grandchild (page1, page2, page3 are really page 1, 2, and 3).
>Less confusing for the scanning person, but much more work in typing.
>Which procedure would others prefer?
The first approach is probably the better one, although if you are
defining a logical hierarchy for your document (e.g., a minutebook
consists of a series of date entries), you don't really need to add
the page level subdivisions; we derive that information automatically
from sequencing information in the MOA2 doc. Also, as John noted,
as a general rule mixing logical and physical hierarchical descriptions
of your object is playing with fire, big time.
While your second approach (a page has a subobject which is a page, which
has a subobject which is a page) would produce a MOA2 document out of
the database, I suspect it will look *very* odd to your users when
it appears on screen; most of us don't think of the next page in a
document as a subobject of the preceding one. Also, in the case of
more logically complex documents, the second approach could lead to
oddities such as a subentry of a dated entry appearing at the same
level in the document hierarchy as the following page.
>8) If all the information is in the EAD finding aid, how much needs to
>carry over into the database Title and description fields? Should it only
>be enough for the scanning person to identify the object?
>
Just to reemphasize John's point, do bear in mind that the data in the
database will not just be seen by your internal processing staff. It
also gets fed directly to users via the MOA2 XML document. So, the
Title field for an Object becomes the title used to identify the
document in the MOA2 browser. The title field for subobjects is used
to identify components of subdocuments in the table of contents displayed
to users in the MOA2 browser. I've just finised writing the conversion
code, and have identified all the fields which will be carried over
into the MOA2 document from the database. I'll be preparing shortly
a memo for all the participants outlining what database fields get used
for what purposes in the MOA2 document, so that everyone will have a
better idea of how they might want to enter their data.
>10) For diaries and minute books, where you have multiple pages for a
>single date, or multiple dates on a single page, how are you setting up the
>hierarchy?
>
>Response: This is probably a best practices issue to be decided on by the
>community. We've talked a lot about whether the hierarchies can or should
>be physical, or logical. I think we agree that they can be either, but you
>are flirting with trouble if you try to mix them. How you do this would
>probably depend on the kind of processing you are doing. That said, here's
>one possibility. You could define page subobjects, and then below them,
>define the subobjects for the entries that start on those pages. Process
>each entry separately, and do entry pagination in markup.
As John notes, this type of mixing of hierarchies can lead to trouble.
I would recommend that, in any case where a logical hierarchy exists
in a document use that and *only* that in delineating your subobject
tree. So, for example, define a minutebook as consisting of a series
of entries (and possibly subentries or paragraphs) but *don't* include
the pages. Using a physical hierarchy for large documents is going
to produce some unpleasant results for your users in the MOA2 browser,
where a table of contents for the minute book will look something like:
Minute book - Page 1 - Entry 1
- Page 2
- page 3 - Entry 2
- Page 4
- Page 5
- Page 6
etc. For a 300 page minute book, this probably isn't what you want
to achieve. In deciding how to create the subobject tree, the best
approach is to think of it as how you would want a table of contents
for this object to appear (since, in fact, that's exactly what's going
to happen).
Jerome McDonough -- jmcdonou@library.Berkeley.EDU | (......)
Library Systems Office, 386 Doe, U.C. Berkeley | \ * * /
Berkeley, CA 94720-6000 (510) 643-2058 | \ <> /
"Well, it looks easy enough...." | \ -- / SGNORMPF!!!
-- From the Famous Last Words file | ||||