Jerry: Thanks for the walk back thru the history of philosophy, and
we ALL hope you are soon recovered from your antihistimine-requiring
ailment! Next, I think we should move from philosophy to myth: are we in
the circumstances of Procrustes, Sisyphus, or (thinking of Jerry) Thor?
There is something of a procrustean bed to this page-structure talk.
Our comparative note is that for phonograph record albums, we decided to
do the structmap this way:
Side A [audio]
Side B [audio]
Side A [image]
Side B [image]
We actually had long and agonizing discussions: was not the structure
"really" like this:
We ended up in Jerry's hedonist camp: we thought our users wanted to
listen above all so we put the audio at the top of the heap. But
obviously one could and some did make the other case. METS doesn't care.
Now, to get back to pushing that boulder up the hill . . . no, wait a
minute, don't I hear Sirens calling . . . .
On Tue, 11 Dec 2001, Jerome McDonough wrote:
> At 10:10 AM 12/10/2001 -0800, Merrilee wrote:
> I'm genuinely confused about how to deal with
> >drawings/figures/illustrations in a printed work. These undeniably are
> >content and somehow part of the logical structure, but can be identified as
> >physical structure. Herm...
> I'm going to risk having this conversation delve into the murkiest, blackest
> of philosophical holes and mention that it was this kind of problem that made
> me start thinking that the logical/physical distinction was ultimately somewhat
> bogus, a nasty little bit of holdover Cartesian dualism that doesn't hold
> up well
> under close examination. That's one of the reasons why I eliminated the
> controlled vocabulary of 'logical/physical' for structMap type.
> Having settled into a happy amalgam of Physicalism, Empiricism, Epicureanism,
> and Antihistimine, I'm currently of the opinion that 1. logical structure
> and does not exist separate from physical structure; therefore 2. worrying
> how to encode that separate is barking up a philosophically dead tree, and
> so 3. instead
> of that approach, we should be thinking about what our users want to see
> when they
> look at a METS object (hence, a modified Epicureanism where our users' pleasure
> is the highest good), and encode a structMap that supports what they want
> to do.
> The painful but obvious fall out for this type of thinking is that there is
> no general
> answer to the question 'how to deal with drawings.' It depends on what
> your users
> want, or, for you more self-centered Epicureans out there, what you want
> your user
> to experience. Do you want a very realistic impression of the original,
> physical work?
> Then you're probably going to want a structMap that closely matches the
> structure, e.g., <div type='book'><div type='page'><div
> You could give a hang about maintaining a close resemblence to the original
> physical work? <div type='book'><div type='text'></div><div type='list of
> <div type='figure1'></div>etc.</div></div>.
> The even more painful but obvious fall out for this type of thinking:
> Creating structural
> metadata for METS objects requires not only knowledge of XML encoding and METS,
> but a good working knowledge of your users and how they're going to want to
> with your information. Which is to say, creating METS objects that
> actually *work* for
> users may not be a process as easily subject to automation as we'd like to
> think, or
> at the very least, will require a lot of working with your local user base
> to determine
> how they want a class of objects structured before you start trying to
> automate the
> process. Which is to say, that structural metadata, properly done, is
> going to be
> damned expensive to create.
> Hm. My philosophy seems to have a problem....
> Jerome McDonough
> [log in to unmask]
> Digital Library Development Team Leader
> Elmer Holmes Bobst Library, New York University
> 70 Washington Square South
> New York, NY 10012
> (212) 998-2425