On 17 Jun 2010, at 4:44 PM, Deborah Kaplan wrote: > On Thu, 17 Jun 2010, [email protected] wrote: >> This may be a question of institutional personality, as it were, but our >> approach in such cases is to try to wire exports to API-M. We try to avoid >> setting up workflows that require running many batch scripts, preferring, >> when possible, to use messaging and event-driven pipelines. Usually it is >> easier and more natural to use the API in such cases. We've found that using >> the API lets us create more flexible scripts and protects us against any >> changes in FOXML down the road. The APIs, as I understand the matter, are >> intended to change more slowly and continuously than a serialization format >> like FOXML. (Viz. the jump from FedoraMETS to FOXML.) Our experience is that >> relying on the API encourages us to think about transforming our data (into >> the Fedora model) instead of transforming particular XML serializations of >> data (into FOXML), and that has tended to be a more sustainable way to work. > > It really depends on what your needs are. The exports from our legacy systems > aren't guaranteed to be correct, and require so much massaging anyway that > there's a real utility in having lots of opportunities to touch the files in > the interim stages. > > Moreover, there's an archivist/programmer conflict here. In an archives > without a dedicated programmer, you're a lot more likely to have somebody who > can do some regular expressions and file manipulation -- and then run the > Fedora-provided foxml creation scripts! -- than you are to have somebody who > can program to the APIs.
The batch scenario (as Deborah & Peri have described) is really the only scenario I've (personally) come across where building up the FOXML in advance has significant benefits. In particular, when ingests are measured in days (or even weeks) batch processing especially in conjunction w/ eliminating or delaying indexing tasks like the Resource Index can make a marked improvement in the ingest times. Deborah's point about an archivist/programmer conflict is well taken, too. I'll take that as an opportunity to plug a project I've been working on recently to provide a convenience library/wrapper for the Fedora REST API that aims to make (Java) programming against the Fedora APIs easier: http://mediashelf.github.com/fedora-client ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
