At 10:14 AM 11/1/2001 -0500, you wrote:
>1) Why do apparently administrative attributes such as CREATED,
>MIMETYPE, SIZE, and OWNERID survive in the file inventory, rather than
>being relegated to the amdSec like the old USE attribute? Is there some
>philosophy behind the assignment of attributes to the inventory vs the
>administrative metadata bucket? I know that the CREATED attribute allows
>for a degree of version control, which is useful in the inventory, but
>are there similar rationales for the others?
For CREATED/SIZE/OWNERID, it's helpful to think of this in terms of data
normalization (as in relational databases). In MOA2, we tried to take
that applied to a whole bunch of files (storage formats, data capture
and put them in a separate section. That way, you list the information once,
and have a whole bunch of files link to it. Putting the
information in a separate section and having files link to it saves you storage
space for the information, as well as ensuring that if the information ever
addition/amendment, you only have to do it in one spot. However, information
about file creation dates/times, file size, and ownerids are likely to vary
between files; there's therefore no reason to try to separate out the
from the file element. You could say that information is all
administrative and should
go in the administrative section, but ultimately all that's going to mean
is taking the
file inventory section and making it a subsection of administrative metadata.
MIMETYPE, obviously, is somewhat different, as it is something that is shared
across files. Rick can correct me if I'm wrong on this, but my recollection is
that we put the MIMETYPE attribute on the file element because it made it
way faster to process that information in a useful way in the MOA2 browser.
So, no real theoretical justification, just a practical one.
>2) Now that xlink is valid for both mptr and FLocat (thank you!) we're
>starting to wonder if there's still a functional or philosophical reason
>to keep <mtpr> as distinct from <ftpr>? The definition of <mptr> seems to
>get at two principles: a) that it points to METS files, and b) that such
>files are not inventoried, and these seem to be separable issues.
>It's not obvious why it's METS-ness justifies a separate element instead
>of using the usual fptr/FLocat pair. Are there cases where you really
>shouldn't bother with an inventory entry and just use an <mptr> alone?
>Are we just trying to be flexible here?
I'd say it's more a matter of historical cruft than flexibility. The
used a very different model than <FLocat>. Now that they're identical, there's
probably not a good reason to keep mptr around. Although if we ditch <mptr>,
we might want to add an optional METS attribute of type xsd:boolean to the
to make it clear whether an external file is a METS document or not. That,
could declare a new MIME type for METS and just store it that
[log in to unmask]
Digital Library Development Team Leader
Elmer Holmes Bobst Library, New York University
70 Washington Square South
New York, NY 10012