Reminder: the t-shirt design contest ends this Friday. Get your
submission in and ensure your place in code4lib history... ;)
--Brad
LaJeunesse, Brad wrote:
Hi Folks,
As we did last year, we're holding a design contest for the code4lib
conference t-shirt. We are accepting submissions until
Hey cats,
I'm starting to think (very excitedly) about the Lucene session, and
realized that I'd better get our data into an XML form, so I can do
interesting things with it.
Anyone here have experience (or code I could steal) dumping data from
Voyager into... anything? I'm happy working in
Nathan,
Ed Summers' ruby-marc is an excellent way to get Voyager's generally
pretty crappy MARC batch export into XML.
http://www.textualize.com/ruby_marc
Use the MARC::ForgivingReader and then you output everything using
MARC::XMLWriter.
For a collection the size of yours it's going to take
Nathan Vack wrote:
Hey cats,
I'm starting to think (very excitedly) about the Lucene session, and
realized that I'd better get our data into an XML form, so I can do
interesting things with it.
Anyone here have experience (or code I could steal) dumping data from
Voyager into... anything? I'm
On Jan 17, 2007, at 2:26 PM, Andrew Nagy wrote:
Nate, it's pretty easy. Once you dump your records into a giant marc
file, you can run marc2xml
(http://search.cpan.org/~kados/MARC-XML-0.82/bin/marc2xml). Then
run an
XSLT against the marcxml file to create your SOLR xml docs.
Unless I'm
On Wed, 17 Jan 2007, Nathan Vack wrote:
On Jan 17, 2007, at 2:26 PM, Andrew Nagy wrote:
Nate, it's pretty easy. Once you dump your records into a giant marc
file, you can run marc2xml
(http://search.cpan.org/~kados/MARC-XML-0.82/bin/marc2xml). Then
run an
XSLT against the marcxml file to
On Jan 17, 2007, at 3:26 PM, Andrew Nagy wrote:
One thing I am hoping that can come out of the preconference is a
standard XSLT doc. I sat down with my metadata librarian to
develop our
XSLT doc -- determining what fields are to be searchable what fields
should be left out to help speed up
Hi Nate,
I've just started playing around with this a bit myself, although I have
to confess that it's quite recent and a hack. But here's what I've been
doing.
Due to consortium issues and the like here's the track I'm taking. I'm
using Perl, since I haven't yet started playing with Ruby. I
On Jan 17, 2007, at 3:59 PM, Bess Sadler wrote:
Is there an elegant way to use your fancy new faceted browser to
search
against circ data w/out re-dumping the whole thing every night?
I'm not sure about this, but given the unique identifier of a thing
borrowed or in question, you might be
Many ILSes give the ability to export item data in the MARC record in a 9xx
tag, (usually the 949 since BT and other book jobbers like to put holdings
data for newly-acquired items there so the ILS can automatically create an item
record when the MARC record is loaded). That is how I've been
Bess Sadler wrote:
As long as we're on the subject, does anyone want to share strategies
for syncing circulation data? It sounds like we're all talking about
the parallel systems á la NCSU's Endeca system, which I think is a
great idea. It's the circ data that keeps nagging at me, though. Is
Bess,
I do have a ruby class that gets current holdings, but it would only
work for Voyager.
My guess is it depend greatly on the ILS -- the RDBMS based ones
(Voyager, Aleph, Horizon, VTLS, etc.) and the rest (Unicorn, III,
etc.).
Unicorn has its API to draw from, but you'd have problems
Very cool, Andrew. I can't wait for your talk.
Bess
On Jan 17, 2007, at 5:10 PM, Andrew Nagy wrote:
Bess Sadler wrote:
As long as we're on the subject, does anyone want to share strategies
for syncing circulation data? It sounds like we're all talking about
the parallel systems á la NCSU's
Eric Lease Morgan wrote:
I'm not sure about this, but given the unique identifier of a thing
borrowed or in question, you might be able to write a Z39.50 query
designed to return circulation status.
Getting the circ data info a known item should be fairly trivial in any
ILS.
The problem is
As long as we're on the subject, does anyone want to share strategies
for syncing circulation data? It sounds like we're all talking about
the parallel systems á la NCSU's Endeca system, which I think is a
great idea. It's the circ data that keeps nagging at me, though. Is
there an elegant
Nathan Vack wrote:
Unless I'm totally, hugely mistaken, MARC doesn't say anything about
holdings data, right? If I want to facet on that, would it make more
sense to add holdings data to the MARC XML data, or keep separate xml
files for holdings that reference the item data?
As others have
On Wed, 17 Jan 2007, Doran, Michael D wrote:
The mfhd has a location, but in Voyager
I find the item perm_location to be more
accurate, at least with our practice
For Voyager, I've found this to be a useful algorithm for getting accurate
location information:
if item record
then
if item
I really think we need to look at ways to manage dynamic record-level data like
circ status separately from the bibliographic metadata. To display that info,
we can do a real-time lookup; but to use it in the faceted search interface we
need a smarter solution. If we can figure out how to
On Jan 17, 2007, at 2:59 PM, Bess Sadler wrote:
As long as we're on the subject, does anyone want to share strategies
for syncing circulation data? It sounds like we're all talking about
the parallel systems á la NCSU's Endeca system, which I think is a
great idea. It's the circ data that keeps
Nathan,
I don't think that will scale to showing status information for a result set.
I think a compromise needs to be reached with your Systems folks.
Maybe they could review the queries?
After all, hitting Oracle directly is more efficient than any single
part of Voyager.
-Ross.
On
Any Real System Guy worth their salt would know how to set up an account
for you to use for SQL queries like these with read-only rights and low
processing priority/throttling so there would be little to no chance of
it affecting system performance. Even if they don't know, they could
find out
Sure isn't elegant, but as our Real Systems Guys don't want us to
look at the production Oracle instance (performance worries), we've
had pretty good luck screen-scraping holdings and status data, once
we get a Bib ID. Ugly, but functional, and surprisingly fast.
A big repercussion of hooking
On Jan 17, 2007, at 6:16 PM, Casey Durfee wrote:
So it sounds to me like they're stonewalling you because they flat out
don't know what they're doing and don't care to find out. In which
cases, condolences.
Nope, I really think it's for fear of someone writing a huge runaway
SQL statement
This is DBA 101 stuff here. [...]
So no here doesn't mean it's not possible, and
if they're as good as you say they are, it doesn't
mean we don't know how to. By my reckoning,
that just leaves we don't feel like it...
The Voyager ILS only comes with an Oracle run-time license, so
On 1/18/07, Doran, Michael D [EMAIL PROTECTED] wrote:
So you may find that there is a well-founded reluctance among
Voyager systems people to get too carried away with the DBA 101 stuff. ;-)
We're routing around the problem by creating a webservice that is
Voyager specific and let other apps
Patrons definitly want to be able to limit on availability. And I don't
think anyone's figured out a good way to do that in this generation of
export and index search tools we are experimenting with. (Heck, I know
a major commercial ILS that won't let you do it in the OPAC either!). I
believe
Wow, spend a day in meetings and you come out to find a huge thread
about OPAC scalability.
Have those of you worried about scaling for repeated hits looked into
just stuffing this data into memory? Heck, a lot of us could
probably serve our whole opacs out of memory these days, query
indexes
27 matches
Mail list logo
