This page last changed on Sep 26, 2007 by bill-parod@northwestern.edu.

Present: Matt K., Stefan, Matt B., John N., Jamees, Martin

AGENDA: Follow up with Thorny Staples (Fedora Commons)

Bill P. sends the following in advance of the meeting: "If I may, I would like to register my interest in Fedora and asset actions and willingness to implement them and advocate / explain their use in MONK. This would be a low cost value to add. It's been done already for NCF and can be easily expanded with other collections and evolved with MONK."

Stefan: how invasive is Fedora? do we need to revise what we have, or is it a matter of developing in parallel

Fedora can be positioned at various points in the architecture. Most probably we would put it behind the "proxy" layer, so it could be developed in parralel and work with existing calls. - Bill Parod

Martin: Bill P. thinks some aspects of MONK data store could be resolved in Fedora, especially summaries that are attached to chunks; for examples, aggregates of words and frequencies; this allows you to go to a look-up rather than pre-compiling on the fly

James: Fedora allows you to model your data as you like; if the relationships between MONK objects become fairly sophisticated, then capturing those relationship in Fedora might become trickier; Fedora works off of RDF

I would suggest we use Fedora for the various textual representations (source text, teisimple version, adorned version, various metadata for the item...). We may want to model those as various data streams within a single object or as separate objects. If separate objects, then we might want to use the RDF "Relationship Metadata" to assert and discover those relationships. We may or may not want to model all relationships in that manner. It would of course depend on a lot of specific factors. - Bill

Big Question: Can Fedora become MONK's repository (for MONK objects or MONK chunks)?

I would suggest it be the repository for the full texts and also provide access to their 'chunks' through disseminators that leverage external services (eXist, Lucene, sgrep,...) for chunk access. - Bill

Stefan: asset actions sound like they would allow MONK to communicate its collection behaviors to other projects

Yes, I think that is important and a real opportunity for MONK to help define access models to text's derivative quantitative data. - Bill

Next question: can we adopt asset actions without adopting the Fedora environment?

Absolutely. AA's are deliberately repository neutral. - Bill

Martin: MONK lexicon; if this was modelled in a Fedora environment such

James: asset actions are a DLF Aquifer effort, not a Fedora effort

Yes. - Bill

Matt B.: asset actions will be useful in terms of allowing our own tools to communicate across the interface

I would advocate that approach. - Bill

'
Stefan: are there specific, empirical things we can do with Fedora now?

I set up NCF in Fedora. You can search (via lucene), view html and xml, access chunks and TOC, and capture Zotero references out of various disseminations of the NCF texts. I would like to extend those object to support access to quantitative data (count vectors for word/chunks, for example). I'd be happy to demo or discuss any of this. - Bill

Martin: Matt K. should talk to Bill P.

Document generated by Confluence on Apr 19, 2009 15:04