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

2011-01-27 Thread Mark A. Matienzo
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

Re: [CODE4LIB] javascript testing?

2011-01-27 Thread John Loy
Bess, Good to hear from you! I've been using Jasmine with its jQuery extensionhttps://github.com/velesin/jasmine-jqueryfor HTML fixtures and DOM-related expect methods in tandem with Google's JsTestDriverhttps://github.com/ibolmo/jasmine-jstd-adapter . For data fixtures, take a look as Jupiter's

Re: [CODE4LIB] javascript testing?

2011-01-27 Thread Graham, Wayne (wsg4w)
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 loy.j...@gmail.com wrote: Bess, Good to hear from you! I've been using Jasmine with its jQuery

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

2011-01-27 Thread Shearer, Timothy J
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 peter.mur...@lyrasis.org wrote: So that will teach me to post a moderately controversial opinion, then leave to take the

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

2011-01-27 Thread 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 persistence of URLs -- whether through an

[CODE4LIB] [code4libcon] QA fodder for the What's New in Solr 1.4 preconference??

2011-01-27 Thread Erik Hatcher
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?

2011-01-27 Thread Jason Ronallo
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)

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

2011-01-27 Thread Kyle Banerjee
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 get

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

2011-01-27 Thread Brad Baxter
2011/1/27 Jonathan Rochkind rochk...@jhu.edu: 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

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

2011-01-27 Thread Pottinger, Hardy J.
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

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

2011-01-27 Thread Brad Baxter
On Thu, Jan 27, 2011 at 12:05 PM, Pottinger, Hardy J. pottinge...@umsystem.edu 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

[CODE4LIB] Unexpected ruby-marc behavior

2011-01-27 Thread Cory Rockliff
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

Re: [CODE4LIB] Unexpected ruby-marc behavior

2011-01-27 Thread Ross Singer
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

Re: [CODE4LIB] Unexpected ruby-marc behavior

2011-01-27 Thread Cory Rockliff
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 expects as