Honestly I try to switch to Chrome every month or so, but it just doesn't do
what Firefox does for me. I've actually been using a Firefox mod called Pale
Moon [1] that takes out some of the not so useful features for work (parental
controls, etc) and optimizes for current processors. It's not a
On Fri, Aug 6, 2010 at 8:19 AM, Joel Marchesoni jma...@email.wcu.edu wrote:
Honestly I try to switch to Chrome every month or so, but it just doesn't do
what Firefox does for me. I've actually been using a Firefox mod called Pale
Moon [1] that takes out some of the not so useful features for
I tried Vimium and found it lacking, which actually led me to Vimperator. If I
remember correctly, though, Vimium allows you to set your own bindings so
perhaps the emacs bindings are already out there somewhere.
Joel
-Original Message-
From: Code for Libraries
Jason,
Thanks for the info. Nokogiri is alright, but I've found that, as far as
XML processing goes, Saxon is above and beyond the best. Is it possible
fire off a Java call from Ruby to have Saxon handle it, or not? Are you
using Nokogiri to call an XSLT process or using Ruby to generate the
Hi, Ethan.
You can see another example of blacklight being used to search and display EAD
guides at
http://nwda.projectblacklight.org/?f%5Bformat_facet%5D%5B%5D=Archival+Collection+Guide
I've used solr and/or lucene for EAD documents a few times, and here are some
observations:
I've also
On Aug 6, 2010, at 9:10 AM, Jonathan Rochkind wrote:
We indexed each EAD guide into separate lucene documents for each EAD
section, then collapsed them under the main EAD title in the search results,
Curious how you impelemented that: Did you use the Solr field collapsing
patch that's not
On Fri, Aug 6, 2010 at 1:09 PM, Bess Sadler bess.sad...@gmail.com wrote:
On Aug 6, 2010, at 9:10 AM, Jonathan Rochkind wrote:
We indexed each EAD guide into separate lucene documents for each EAD
section, then collapsed them under the main EAD title in the search results,
Curious how you
I also think it's better to store EAD in a separate system rather than in
the Solr index, that way you can use blacklight to serialize it or store a
reference to a separate delivery system. Bess's and Matt's approach to
storing the whole collection (EAD file) as a solr document in addition to
On Aug 6, 2010, at 10:53 AM, Mark A. Matienzo wrote:
On Fri, Aug 6, 2010 at 1:09 PM, Bess Sadler bess.sad...@gmail.com wrote:
On Aug 6, 2010, at 9:10 AM, Jonathan Rochkind wrote:
We indexed each EAD guide into separate lucene documents for each EAD
section, then collapsed them under the
Mark,
How are you creating the EAD docs in Fedora? At present, we're using
archivist's toolkit to dump out ead xml files and then I index them in solr,
with blacklight displaying the entire document as well. It's messy and it
would be nice to make a more efficient connection between the
Hi Adam,
I posted an update last Friday on a project I have been working on since
last fall called EADitor, an XForms application for creating, managing, and
publishing EAD collections. I'm using an eXist datastore, but one could
adapt the XForms application to load and save data to and from
On Fri, Aug 6, 2010 at 12:10 PM, Jonathan Rochkind rochk...@jhu.edu wrote:
You can definitely have Blacklight handle the display while still keeping the
EAD out of solr stored fields. There's no reason Blacklight can't fetch the
EAD from some external store, keyed by Solr document ID (or by
On Fri, Aug 6, 2010 at 2:17 PM, Bess Sadler bess.sad...@gmail.com wrote:
On Aug 6, 2010, at 10:53 AM, Mark A. Matienzo wrote:
We indexed each EAD guide into separate lucene documents for each EAD
section, then collapsed them under the main EAD title in the search
results,
Curious how you
I wonder how the field collapsing patch holds up on an index that contains 3
million documents, probably larger than your EAD-only one, but thinking about
combining EAD in an index with many many other documents (like with a library
catalog). Might be fine, might not.
(Even without field
On Aug 6, 2010, at 8:07 PM, Jonathan Rochkind wrote:
I've been brainstorming other weird ways to do this. This one is totally
wacky and possibly a bad idea, but I'll throw it out there anyway. What if
you only indexed the entire EAD as one document, BUT threw the entire EAD in
a stored
Huh, since the highlighter only needs to run on the documents in the actual
returned section of the result set (10-50?), I wouldn't think total number of
documents would matter much (I certainly could be wrong), but total size of
each document's stored field definitely has a known performance
16 matches
Mail list logo
