Present: Thorny Staples (Fedora Commons), Matt K., Stan, Stefan, Martin, Bill, John, James, Matt B.

Thorny provided a recap and update of Fedora:

Transition from Fedora (UVa/Cornell) to Fedora Commons ("foundation")
Two-year grant from Moore foundation
Fedora provides information management schemes for "durable data"
Fedora is software for maintaining digital objects in a repository
Content models (thumbnail, screen-size, master); together they are one image object with a "PID" (common identifier)

Martin on MONK:

large document space populated by heterogeneous text objects;
we make it possible for users to compare anything with anything;
we rely on various models or "surrogates" of documents

Thorny:

atomistic content model approach; art not science; decide at what level you want to peg an object; resources like a book become a graph of related objects, rather than a single object; each chapter of a text could be a separate object; or each word; each of the 24 million Unicode characters can be an object, and everything is an aggregate from there

disseminators on demand can get an part of an object; text object has the ability to give you different behaviors associated with your notions of what the sub-sets are

no clear answer to question of what is the right way of content modeling

Ben Shneiderman: literals, surrogates, constructed surrogates

Fedora is agnostic with respect to the above. You create "aggregation objects."

One object for book as a whole, disseminators for parts you want to analyze.

"As long as object recognizes and can act on its constructed parts, this model will work."

"Fedora is a way of expressing your decisions about modeling your content and then letting you live with those decisions."

"Asset Actions"
XML file expressing a bunch of named actions; i discovered this object, i can get a list of all of its possible behaviors; list comes with a name that names the object an a URL that will result in that action; exposing Fedora disseminator methods

John: If I were browsing UVa's text collections, Asset Actions would be the "shopping cart" mechanism.

Thorny: MONK could define a set of functions that all of its repositories would support.

John: This is a formal expression of "MONKability."

Thorny: If MONKability was in the asset action for some group of things, you know you could support MONK functions.

Fedora Commons and DLF Aquifer: the former is about maintaining the software and serving its user community; DLF Aquifer is an OAI exposing project; expose metadata in Open Archives Initiative format (Dublin Core and MODS). Aquifer would harvest among DLF members and build portals that would provide access to that; asset actions injected into DLF Aquifer as an experiment.

John: If MONK is open source, could Fedora Commons be our Source Forge?

Thorny: Unknown. UVa's "Academic Information Space" might be a better fit.

John: we could offer Fedora Commons examples of definitions for new kinds of functionality.

Thorny: data modeling for MONK around Fedora; asset actions especially relevant, since it makes Fedora more accessible and inter-operable

John: how do we avoid redundant text processing?

Thorny: you could publish a text object with another object in data stream

FedoraCommons could potentially assist in developing new statefull publication models for MONK

Plans to talk further at Maryland TEI meeting.