Thanks very much for the great module. I had a question about something that may be beyond the scope of this module, but I thought I'd ask. (If there's a better place to pose the question, I'd appreciate it if anyone could point me to it.)

I've been able to use the MARC module to import .mrc records to CCK nodes, but I wondered if there's any mechanism for creating .mrc files *from* the resulting CCK nodes.

I'm working on a project that will involve importing MARC records to create nodes for a Drupal site—getting that bibliographical information into a proper database is going to make it possible to do new things with it that we just haven't been able to do before. It's still going to be important that we be able to get the data out again in a format that can be easily shared with libraries and their OPACs.

I see that the MARC module grabs all of the MARC fields upon import (not just the ones that are mapped to the fields of the content type) and stores them in the marc_bib table. Is there a way to draw on that data to generate new .mrc files that we could share with libraries?

Sorry for the oddball question. I fully understand if this isn't something this module is designed to do.

Comments

aaustin’s picture

aaustin commented

This is not an oddball question at all.This is something I have been wanting to implement for a while. The issue is that it is a whole lot easier (code-wise) to just grab all the information you want from a MARC record, than it is to rebuild the same record. But I really do want to add that functionality and have a relatively immediate need to add it for a project that I am working on.

This might be easier to implement using the FILE_MARC PEAR package. But I have mixed feelings about requiring a PEAR package be installed in order to use the module.

Hypothetically, would you be willing to install the FILE_MARC PEAR extension on your server, in order to export MARC records?

benjamin.pauley’s picture

benjamin.pauley commented

Absolutely I'd be willing to do that. Um, as soon as I figure out how to install PEAR packages, that is. But I've been reading up on doing that, and don't see that that would any problem to do.

It seems like a good solution, allowing you to keep a "default" installation as straightforward as possible while providing a path for people who need to do something more. I'm afraid I'm not much of a coder, but I'd be happy to do some testing if it gets to that point.

BoogieBug’s picture

BoogieBug commented

subscribing

aaustin’s picture

aaustin commented

Ok, I needed to ask Dan for some help with File_MARC, he posted the example here:

http://coffeecode.net/archives/243-Creating-a-MARC-record-from-scratch-i...

I will work on adapting and getting the code in to the module.

benjamin.pauley’s picture

benjamin.pauley commented

Oh, that's very cool, and will be a welcome addition to the next release!

In the mean time, I'd worked up a solution that involves using Views Bonus Pack to output a View with the fields I need as an XML file, and then using various tpl.php files for the fields in the View to format the output of my fields so that they'd have the appropriate tags. That works, but it's kind of a roundabout solution.

mrc9’s picture

mrc9 commented
Issue summary: View changes

This might be easier to implement using the FILE_MARC PEAR package. But I have mixed feelings about requiring a PEAR package be installed in order to use the module.