Hi Marcus and all,
I think I'd like to weigh on this one, as one who spent lots of time
worrying about how to apply METS to scanned print (i.e. digitized analog)
material. What we at Harvard ended up with is on display at the METS web
site examples section.
Some digital objects that you can model with METS have only a logical
structure, e.g. "born digital" items, or those with no relationship to
their analog parent (i.e. TEI-encoded texts). But many of the digital
objects we're dealing with obviously do have physical structure, e.g.
scanned books and journals, digitized audio, etc. And when there is a
physical structure you MUST ALSO HAVE a logical structure to overlay it
in order for an application to do anything useful with it.
You could, I suppose, have more than one logical structure that you want
to overlay one physical structure, but I think that's going to be a rare
since most of what we're dealing with is reformatted analog material for
which the logical structure comes from the original item (i.e. chapters
and subchapters of books, articles in journal issues, LP tracks, etc.).
And if you want to _reuse_ parts of the physical structure in new digital
objects (e.g. a digital anthology) then I think that's a a separate METS
However, I can see the possibility of having both cases at once: a scanned
book for which you also have a TEI-encoded full text version, and maybe a
PDF too. Then you might want multiple structMaps for the different
versions, and you _might_ want to link between them (Jerry, don't you
agree that could be useful?). Supporting this is just a matter of adding a
"STRUCTID" to the div attributes, so if we agreed to support this it
wouldn't be hard to do.
> In my eyes the enduser is not and should not be the central point when
> describing a format for a digital library. It's more or less the
> question how we could/would present the METS-file (or METS-object) to
> the user, what kind of navigation possibilites we will offer him. Or do
> you really plan to give the METS-file to the user?
> In my view it is the task of the software to rearrange the METS-object
> in a way so that the enduser may work with it as he would expect.
This is getting seriously confused... Jerry isn't proposing to give METS
files to users, he's saying exactly the same thing you are: that structure
maps enable applications that support what real users want to do with
digital objects, not some Ideal Inherent Physical Structure of an object.
This gets back to the point that physical structure in a vacuum is pretty
useless, and it's the logical structure that allows you to build useful
applications, so you need both, so why add the overhead of separating
So my conclusion from all this weighty debate: you wouldn't want to
divorce the logical and physical structures when you have both, but that
there could be cases where you have multiple logical structures (or
physical/logical structures) that have relationships between them and so
METS should consider adding support for linking between structMaps. If
others agree with that then we can either add it now or put it on the
docket for a future editorial board meeting... I leave it Jerry to decide.
MacKenzie Smith [log in to unmask]
Digital Library Program Manager phone: (617)495-3724
Office for Information Systems fax: (617)495-0491
Harvard University Library %\%\%\%\%\%\%\%\%\%\%\%\%\%