Thanks for forwarding this.
I'm tied up with other projects for the next
few months at Auburn, so I probably won't
contribute much to VuFind's Driver project.
I'm CC'ing Clint Bellanger (the lead VuFind developer at Auburn),
but I think he's tied up too.
I think the driver project has a different philosophy than
what we took at Auburn.
Vufind currently stores the raw MARC source data in the
SOLR index together with the SOLR search fields
(title, author, publisher, whatever).
Auburn does not store the raw MARC, because we found
that we could drive our UI using only the SOLR search fields as data.
As I understand it -
the driver project continues down the "store the raw source in SOLR"
path, but provides a format-neutral DRIVER API to access the
raw data rather than rely on MARC-specific code.
I prefer the Auburn approach of only storing key data
(title, author, whatever) in the SOLR index,
then link off to the source (Voyager, Content-DM, whatever)
server if the user needs more details. The Auburn design does
not require the Driver, but we'll watch to see what develops.
>>> "Ya'aqov Ziso" <ziso@...> 1/7/2010 1:57 PM >>>
Reuben, you probably saw this, but just to make sure (and thank you so
I imagine that Auburn's solution is structured a bit differently than
driver project will be, but if they're interested in participating, I'm
there's a good chance that their work is adaptable to the driver
and if not, it may offer ideas for a better and more flexible
I'm certainly happy to discuss this further if Reuben is interested.
> As I understand it -
> the driver project continues down the "store the raw source in SOLR"
> path, but provides a format-neutral DRIVER API to access the
> raw data rather than rely on MARC-specific code.
> I prefer the Auburn approach of only storing key data
> (title, author, whatever) in the SOLR index,
> then link off to the source (Voyager, Content-DM, whatever)
> server if the user needs more details. The Auburn design does
> not require the Driver, but we'll watch to see what develops.
The driver approach should actually be able to satisfy people who prefer using only Solr and those who want to access specific types of raw metadata. When a record is encountered, VuFind will try to find a driver to handle the record's format. If no format-specific driver is found, it will default to a driver that works entirely using the Solr index fields. If that's all you need, you can simply index your records and skip the step of writing a custom driver -- the Solr-based one will get used automatically.
Obviously, when the driver mechanism is first introduced, the MARC driver is going to have the strongest functionality, since it will be based on the existing code... My first step is simply to rearrange what we have, rather than rethink everything. However, I'm hopeful that as things develop over time, the Solr-based driver will be able to do the majority of the work, and the functionality specific to the MARC driver will be minimized.
Another important thought -- while the initial intention of this driver mechanism is to distinguish between different metadata formats, the underlying mechanism could be used for other things as well. Since this basically amounts to "a Solr field value causes different presentation code to get loaded," you could create drivers to display different types of records (i.e. books vs. videos) differently. But I'm probably getting ahead of myself here!