Dear members of the USA and International Library
Community,
We want you to show the rest of the national and
international library community your best ideas!
Applications for presenting poster sessions at the
2007 ALA Annual Conference are now being accepted. An
application form is available on
On 11/29/06, Andrew Nagy <[EMAIL PROTECTED]> wrote:
So ... while we are on this topic. You wouldn't want to index marcxml
records in lucene, you would use marc21, right? Why deal with the
overhead of xml if it is not necessary. We have to format our data no
matter what for to best fit our sto
For an interesting read:
XQuery Processing with Relevance Ranking
Leonidas Fegaras
http://www.springerlink.com/content/em728eqn888nuer4/
OK, my last reply to a reply today, I swear, for this list at least :-)
>> * the indexer allows control of how the data is normalized
> Is this the indexers job? I say not.
I probably should have said that "the indexer does not preclude special
normalization", and for that matter, I probably sho
Kevin S. Clarke wrote:
Fwiw Andrew, I'd suggest you are not seeing the "true spirit of your
NXDB." Try to put MARC into a RDBMS and you are going to run into the
same problem. You have to index intelligently or reorganize the data
(which is the default when you put XML into a RDBMS anyway). P
As we move towards experimenting with a Solr-based opac I'm hoping to
persuade everyone involved that MODS is sufficient to drive the search
interface. Let MARC abide in the ILS, and become a mere spirit of malice
that gnaws itself in the shadows, but cannot again grow or take shape.
Peter
-O
>For all you Java savvy folks out there, how about "standards" like
>J2EE that make it easy to move an application from one vendors app.
>server to another. Works for the simplest of applications, but all
>vendors have their own specific custom deployment descriptors too.
One thing I really like
I think this is a data structure problem... MARC is well structured
for compact transmission (or was at one point) but not so much for
data (re)use (in my opinion).
One solution, as Erik has suggested, is to parse the data and build
intelligible indices. Another, as Andrew suggests (and which I
On Nov 29, 2006, at 10:27 AM, Art Rhyno wrote:
I am so behind in e-mail that I might be treading on ground that is
worn
out on this, but I would add to Eric's list that I don't care about
the
indexer if:
Here's how Lucene/Solr fares on these points:
* the indexer has an open and configurable
Clay Redding wrote:
Hi Andrew (or anyone else that cares to answer),
I've missed out on hearing about incompatabilites between MARCXML and
NXDBs. Can you explain? Is this just eXist and Sleepycat, or are
there others? I seem to recall putting a few records in X-Hive with no
problems, but I
> I don't care a whole lot whether I use this indexer, that indexer, or
> the other indexer as long as I can make sure I have an SRU, OpenURL,
> Z39.50, etc. interface to the index. This will always allow me to
> swap out the an older indexer for a new one as they become available.
I am so behind
Thom Hickey wrote:
Ralph LeVan here at OCLC has worked on an SRU interface to Lucene.
The combined indexer/SRU approach is the tack I've been taking
regarding search too.
I don't care a whole lot whether I use this indexer, that indexer, or
the other indexer as long as I can make sure I have
12 matches
Mail list logo
