You might want to have a look at Zebra for the indexing engine.
http://indexdata.dk/zebra/

Great tool for making a file of MARC records Z searchable.


John

On 27-Oct-05, at 2:58 PM, Eric Lease Morgan wrote:

> On Oct 27, 2005, at 2:06 PM, Andrew Nagy wrote:
>
>
>>>  http://mylibrary.ockham.org/
>>>
>>
>> I have been thinking of ways, similiar to what you have done that you
>> mentioned below with the Ockham project, to allow more modern day
>> access
>> with our library catalog.  I have been beginning to think about
>> devising
>> a way to index/harvest our entire catalog (and allow this indexing
>> process to run every so often) to allow our own custom access
>> methods.
>> We could then generate our own custom RSS feeds of new books, allow
>> more
>> efficient/enticing search interfaces, etc.
>>
>> Do you know of any existing software for indexing or harvesting a
>> catalog into another datastore (SQL Database, XML Database, etc).
>> I am
>> sure I could fetch all of the records somehow through Z39.50 and
>> dump it
>> into a MySQL database, but maybe there is some better method?
>>
>
> I too have thought about harvesting content from my local catalog and
> providing new interfaces to the content, and I might go about this in
> a number of different ways.
>
> 1. I might use OAI to harvest the content, cache is locally, and
> provide services against the cache. This cache might be saved on a
> file system, but more likely into a relational database.
>
> 2. I might simply dump all the MARC records from my catalog,
> transform them into something more readable, say sets of HTML/XML
> records, and provide services against these files.
>
> The weakest link in my chain would be my indexer. Relational
> databases are notoriously ill-equipped to handle free text searching.
> Yes, you can implement it and you can use various database-specific
> features to implement free text searching, but they still won't work
> as well as an indexer. My only experience with indexers lies in
> things like swish-e and Plucene. I sincerely wonder whether or not
> these indexers would be up to the task.
>
> Supposing I could find/use an indexer that was satisfactory, I would
> then provide simple and advanced (SRU/OpenSearch) search features
> against the index of holdings. Search results would then be enhanced
> with the features such as borrow, re-new, review, put on reserve,
> save as citation, email, "get it for me", put on hold, "what's new?",
> view as RSS, etc. These services would require a list of authorized
> users of the system -- a patron database.
>
> In short, since I would have direct access to the data, and since I
> would have direct to the index, I would use my skills to provide
> services them. For the most part, I don't mind back-end,
> administrative, data-entry interfaces to our various systems, but I
> do have problems with the end-user interfaces. Let me use those back-
> ends to create and store my data, then give me unfettered access to
> the data and I will provide my own end-user interfaces. Another
> alternative is to exploit (industry standard) Web Services computing
> techniques against the existing integrated library system. In this
> way you get XML data (information without presentation) back and you
> can begin to do the same things.
>
> --
> Eric Lease Morgan
> University Libraries of Notre Dame
>

--
John Durno
Project Coordinator
BC Electronic Library Network
~~~~~~~~~~~~~~~~~~~~
Phone: 604-268-7002
Fax: 604-291-3023
Email:   [log in to unmask]
Web: http://www.eln.bc.ca