The Mellon Fedora project is looking at both issues. The Fedora
architecture assumes that executable code modules will change or be
replaced over time. Executables will probably need to be upgraded or
migrated more frequently than content. The Fedora object model makes a
clean distinction between the content and its encoding format, and the
executables that read content (wrapped in Disseminators). The design of
the architecture is meant to enable the switching in and out of
executables as needed.
This leads to your second question. In the Cornell Fedora research we
have the notion of a "structoid" which essentially defines a sort of
encoding format characterized mainly by roles (e.g. "page") matched with
formats ("image/gif"), plus some other info. In Fedora, a structoid has
a unique identifier and thus can be registered as a known
structural/encoding pattern. In the research version of Fedora, you can
do a search of Disseminators that use a particular structoid pattern. We
are currently still thinking about how this plays out in Mellon and
METS. Maybe something having to do with METS profiles. Maybe something
with typing of structMaps. In any event, when we identify an encoding
format that's supported by a Disseminator, we need to speak both of
structure (roles that different files play) and formats of different
I'll be working with Jerry McDonough this week to firm up details on how
we will specify the basic Disseminator notion in the METS schema. We'll
continue to look at the finer issues in the Mellon project.
From: Reagan Moore [mailto:[log in to unmask]]
Sent: Wednesday, November 14, 2001 3:47 PM
To: [log in to unmask]
Subject: Re: [METS] Proposed METS changes from Mellon Fedora project
For long term persistent archives, a concern is that executable code
will become obsolete as the underlying operating systems evolve. One
can characterize digital objects by their encoding format, and then
identify executable code which is able to read the encoding formats.
Will the METS system support the specification of encoding formats
for digital objects? Is it possible to identify which Disseminators
are able to read which encoding formats?
>Cornell and UVA are working jointly on a Mellon-funded project to
>develop open source repository software based on the Fedora design for
>objects and repositories. As part of this project we would like to use
>METS as an underlying encoding scheme for storing our digital objects.
>We have mapped the Fedora object model to METS and most things relate
>nicely, however, Fedora has the notion of a "Disseminator" which
>essentially associates executable code with the object. We have a
>proposal for the METS group to consider on allowing METS to support the
>association of disseminators with an object. We have run our ideas by
>Jerry McDonough and he was supportive of the concept, however, the
>details of how we would do this requires some discussion.
>I have sent along a set of attachments for your consideration.
>Hopefully these will help you see what we have in mind, and not
>overwhelm you with more detail! :-)
>Thorny Staples and I will be attending the METS meeting at the end of
>this week, so maybe this topic can be addressed at some point in the
>Here's a rundown of the attachments:
>1. proposedChanges.doc - this describes what we are thinking. If you
>only have time to read one thing, this will summarize our ideas with
>examples. The other attachments are complete examples of Fedora
>encoded in METS.
>2. METS_image_dobj3a.xml - this is a sample Fedora digital object
>encoded in METS. It represents UVA's content model for their image
>3. METS_Img1_sig.xml - a Fedora "Behavior Definition Object" encoded
>METS. This Behavior Definition Object stores metadata and content that
>essentially defines an interface for viewing images. The image content
>object (#2 above) points to this object via a METS <mptr>.
>4. METS_Img1_servlet.xml - a Fedora "Behavior Mechanism Object"
>encoded in METS. This Behavior Mechanism Object stores executable code
>that implements the image viewing behaviors defined in #3 above. The
>image content object points to this object via a METS <mptr>.
>5. METS_FedoraDC_sig.xml - just like #3 above, except this object
>defines a set of behaviors for obtaining Dublin Core records from a
>Fedora digital object.
>6. METS_FedoraUVAtoDC_servlet.xml - just like #4 above, except this
>object implements the Dublin Core behaviors defined in #5.
>See you in Pittsburgh,
>Sandy and Thorny
>Attachment converted: Macintosh HD:proposedChanges.doc (WDBN/MSWD)
>Attachment converted: Macintosh HD:METS_image_dobj3a.xml (TEXT/MSWD)
>Attachment converted: Macintosh HD:METS_Img1_sig.xml (TEXT/MSWD)
>Attachment converted: Macintosh HD:METS_Img1_servlet.xml (TEXT/MSWD)
>Attachment converted: Macintosh HD:METS_FedoraDC_sig.xml (TEXT/MSWD)
>Attachment converted: Macintosh HD:METS_FedoraUVAtoDC_servlet.xml