[CODE4LIB] International Linked Open Data in Libraries, Archives, and Museums Summit (LOD-LAM)

The International Linked Open Data in Libraries, Archives, and Museums Summit (LOD-LAM) will be held in San Francisco on 2-3 June 2011. LOD-LAM will convene leaders in their respective areas of expertise from the humanities and sciences to catalyse practical and actionable approaches to publishing

Re: [CODE4LIB] javascript testing?

Bess, Good to hear from you! I've been using Jasmine with its jQuery extensionfor HTML fixtures and DOM-related expect methods in tandem with Google's JsTestDriver . For data fixtures, take a look as Jupiter

Re: [CODE4LIB] javascript testing?

Hi Bess, +1 for Jasmine. Used to dig blue-ridge for these things, but I don't think they're maintaining that any more. Wayne On 1/27/11 9:37 AM, "John Loy" wrote: > Bess, > > Good to hear from you! I've been using Jasmine with its jQuery > extension

Re: [CODE4LIB] to link or not to link: PURLs

Thanks Peter (and everyone), that's what I was fishing for. We haven't yet gone there, and this whole conversation has been very helpful. -t On 1/26/11 6:48 PM, "Peter Murray" wrote: >So that will teach me to post a moderately controversial opinion, then >leave to take the kids out for a pizza

Re: [CODE4LIB] to link or not to link: PURLs

"If the best you can do is an external Handle/PURL set-up, then it is better than nothing." I would say that it's SOMETIMES better than nothing. It depends on what you're doing, what your requirements and goals are. Not every application needs long-term persistence of URLs -- whether through an

[CODE4LIB] [code4libcon] Q&A fodder for the "What's New in Solr 1.4" preconference??

Just like I did last year, I'm requesting folks send me (on or off-list, as appropriate) issues/questions regarding Solr that I can factor into the session on Feb. 7 in Bloomington. Suggestions on specifics you'd like covered will be eagerly accepted and factored in too. Last year I had a ton

Re: [CODE4LIB] javascript testing?

One problem with webdriver (selenium 2) testing is that Firefox can pop up repeatedly when auto testing which can be really annoying. One work around is to use a virtual display. Rather than headless testing you can do something similar on a Linux system by using an X virtual framebuffer (Xvfb) [1]

Re: [CODE4LIB] to link or not to link: PURLs

> > I would say that it's SOMETIMES better than nothing. It depends on what > you're doing, what your requirements and goals are. Not every application > needs long-term persistence of URLs -- whether through an 'abstraction > layer' or not. ('abstraction layer' is just an implementation detail to

Re: [CODE4LIB] to link or not to link: PURLs

2011/1/27 Jonathan Rochkind : > "If the best you can do is an external Handle/PURL set-up, then it is better > than nothing." > > I would say that it's SOMETIMES better than nothing. It depends on what > you're doing, what your requirements and goals are. Not every application > needs long-term

Re: [CODE4LIB] to link or not to link: PURLs

Hi, this has been a really interesting and informative discussion. I wonder if I might be able to redirect it a bit back to my original question, with the understanding that, as the discussion has made clear, a PURL or Handle is not an ideal solution? If, for the sake of argument, you are deali

Re: [CODE4LIB] to link or not to link: PURLs

On Thu, Jan 27, 2011 at 12:05 PM, Pottinger, Hardy J. wrote: > If, for the sake of argument, you are dealing with software which provides > permanent URLs (say, for example, DSpace's out-of-the-box use of the Handle > system), would it be desirable to make these persistent links actual > hyperl

[CODE4LIB] Unexpected ruby-marc behavior

So I was taking ruby-marc out for a spin in irb, and encountered a bit of a surprise. Running the following: require 'marc' reader = MARC::Reader.new('filename.mrc') reader.each {|record| puts record['245']} produces the expected result, but every subsequent call to reader.each {|record| puts r

Re: [CODE4LIB] Unexpected ruby-marc behavior

No, that's expected behavior (and how it's always been). You'd need to do reader.rewind to put your enumerator cursor back to 0 to run back over the records. It's basically an IO object (since that's what it expects as input) and behaves like one. -Ross. On Thu, Jan 27, 2011 at 2:03 PM, Cory Ro

Re: [CODE4LIB] Unexpected ruby-marc behavior

Oh, gotcha. Thanks. C On Jan 27, 2011, at 2:11 PM, Ross Singer wrote: > No, that's expected behavior (and how it's always been). You'd need > to do reader.rewind to put your enumerator cursor back to 0 to run > back over the records. > > It's basically an IO object (since that's what it expect