Re: [CODE4LIB] Let's go somewhere
Some of us have been doing a good job introducing new concepts and processes by writing to, or discussing with, fellow librarians. Many of us have been in the situation where a librarian who doesn't want a change (i.e. add homework and work for her/his load) would hide that by saying 'I don't understand, let's discuss it some more, reach a consensus', etc. Alas, those who refuse a change can be re-programmed only by the administration. Anything else is a democratic waste of our time. Ya'aqov Ziso On Sun, Oct 31, 2010 at 8:00 AM, Eric Lease Morgan emor...@nd.edu wrote: On Oct 30, 2010, at 10:50 AM, Peter Schlumpf wrote: And you are correct in pointing out that the natural response of librarians to a problem is to seek consensus in a self-absorbed way. Form committees and all that nonsense which never goes anywhere. They are happy enough going around in circles, like the Nowhere Man making all his nowhere plans for nobody. The above certainly does seem to jive with my experience. Going around in circles. Endless consensus. Librarianship could use a bit more democracy and/or science to their (our) method. At the same time I agree that E V E R Y T H I N G ! ! ! is wrong with the profession creating our own language. -- EL Morgano -- ya'aQov
Re: [CODE4LIB] Let's go somewhere [was PHP vs. Python...]
Peter - I was bewildered at the notion of needing yet another scripting language, let alone one as library domain-specific (that wording alone throws up red flags everywhere), but I'm not here to bash ideas. Instead I looked up your site and read the small blurb about Nova. It seems that the main objective behind your pursuit is creating a language that provides a specific data type for semantic objects (or relationships). I have to ask, what about semantic maps makes you believe that they require a specific data type rather than just being an object type? Are other scripting languages too slow to suit certain needs such that a new data type is necessitated? I really can't see this being the case. That being said, while it can be an invaluable experience to learn about making scripting languages, if there's to be any community movement toward a particular language (php, ruby, java, scheme or what have you) there has to be some very real and significant benefit. Or more directly, you seem to have specific ideas about a library domain-specific language. What do today's languages not have that you believe is so essential that you'd be willing to write a new scripting language? - Patrick E. On Sat, Oct 30, 2010 at 10:51 AM, Peter Schlumpf pschlu...@earthlink.net wrote: Bill, you hit a nail pretty squarely on the head. I believe this decades long fetish with MARC has to go. It was designed to efficiently store data on magtapes and doesn't make any sense in today's world. It's a huge millstone around the neck of Libraryland and it keeps them stuck in that tiny little ghetto. Anything can be a mind-prison, even PHP, Python or Django. They are all arbitrary anyway. And you are correct in pointing out that the natural response of librarians to a problem is to seek consensus in a self-absorbed way. Form committees and all that nonsense which never goes anywhere. They are happy enough going around in circles, like the Nowhere Man making all his nowhere plans for nobody. My hope is that some among us would just undertake these problems ourselves. Outside of the realm of the libraries and the limiting mindsets many of us work in. We've all got ideas. Fire up vi and get busy and make something happen, like a library domain-specific language. Start fresh. There is nothing wrong with that. What's wrong is how the library community goes about such things. Let's go somewhere. Peter Schlumpf www.avantilibrarysystems.com -- Patrick K. Etienne Systems Analyst Georgia Institute of Technology Library Information Center (404) 385-8121
Re: [CODE4LIB] Let's go somewhere [was PHP vs. Python...]
I would be very unlikely to use someone's homegrown library specific scripting language. However, if you want to make a library for an existing popular scripting language that handles your specific domain well, I'd be quite likely to use that if I had a problem with your domain and I was comfortable with the existing popular scripting language, i'd use it for sure. Odds are your domain is not really libraries (that's not really a software problem domain), but perhaps as Patrick suggests dealing with relationships among semantic objects, and then odds are libraries are not the only people interested in this problem domain. Some people like ruby because of it's support for creating what they call domain specific languages, which I think is a silly phrase, which really just means a libraryAPI at the right level of abstraction for the tasks at hand, so you can accomplish the tasks at hand concisely and without repeated code. Patrick Etienne wrote: Peter - I was bewildered at the notion of needing yet another scripting language, let alone one as library domain-specific (that wording alone throws up red flags everywhere), but I'm not here to bash ideas. Instead I looked up your site and read the small blurb about Nova. It seems that the main objective behind your pursuit is creating a language that provides a specific data type for semantic objects (or relationships). I have to ask, what about semantic maps makes you believe that they require a specific data type rather than just being an object type? Are other scripting languages too slow to suit certain needs such that a new data type is necessitated? I really can't see this being the case. That being said, while it can be an invaluable experience to learn about making scripting languages, if there's to be any community movement toward a particular language (php, ruby, java, scheme or what have you) there has to be some very real and significant benefit. Or more directly, you seem to have specific ideas about a library domain-specific language. What do today's languages not have that you believe is so essential that you'd be willing to write a new scripting language? - Patrick E. On Sat, Oct 30, 2010 at 10:51 AM, Peter Schlumpf pschlu...@earthlink.net wrote: Bill, you hit a nail pretty squarely on the head. I believe this decades long fetish with MARC has to go. It was designed to efficiently store data on magtapes and doesn't make any sense in today's world. It's a huge millstone around the neck of Libraryland and it keeps them stuck in that tiny little ghetto. Anything can be a mind-prison, even PHP, Python or Django. They are all arbitrary anyway. And you are correct in pointing out that the natural response of librarians to a problem is to seek consensus in a self-absorbed way. Form committees and all that nonsense which never goes anywhere. They are happy enough going around in circles, like the Nowhere Man making all his nowhere plans for nobody. My hope is that some among us would just undertake these problems ourselves. Outside of the realm of the libraries and the limiting mindsets many of us work in. We've all got ideas. Fire up vi and get busy and make something happen, like a library domain-specific language. Start fresh. There is nothing wrong with that. What's wrong is how the library community goes about such things. Let's go somewhere. Peter Schlumpf www.avantilibrarysystems.com
Re: [CODE4LIB] Let's go somewhere [was PHP vs. Python...]
This is one of my favorite passage from SICP: It is no exaggeration to regard this as the most fundamental idea in programming: The evaluator, which determines the meaning of expressions in a programming language, is just another program. To appreciate this point is to change our images of ourselves as programmers. We come to see ourselves as designers of languages, rather than only users of languages designed by others. In general I think there is too much fear of using language as just another means of abstraction. While I certainly agree that creating an entire language from scratch is a bad idea, I don't think it would be insane to create a dsl to solve a common set of problems on top of an existing runtime. I actually think this would be particularly useful in the library world since there is such a range of programming talent, a dsl that simplified some common library related tasks could certainly be useful, especially if there was full language underneath. Of course there is the problem that even DSLs are not simple to create, the number of library programmers with experience in parsers and language design is probably very, very small. But the ease of creating dsl is increasing and I think their use will get more popular over time (hopefully). From: Jonathan Rochkind rochk...@jhu.edumailto:rochk...@jhu.edu Date: November 1, 2010 11:03:13 AM PDT To: CODE4LIB@LISTSERV.ND.EDUmailto:CODE4LIB@LISTSERV.ND.EDU CODE4LIB@LISTSERV.ND.EDUmailto:CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Let's go somewhere [was PHP vs. Python...] Reply-To: Code for Libraries CODE4LIB@LISTSERV.ND.EDUmailto: CODE4LIB@LISTSERV.ND.EDU I would be very unlikely to use someone's homegrown library specific scripting language. However, if you want to make a library for an existing popular scripting language that handles your specific domain well, I'd be quite likely to use that if I had a problem with your domain and I was comfortable with the existing popular scripting language, i'd use it for sure. Odds are your domain is not really libraries (that's not really a software problem domain), but perhaps as Patrick suggests dealing with relationships among semantic objects, and then odds are libraries are not the only people interested in this problem domain. Some people like ruby because of it's support for creating what they call domain specific languages, which I think is a silly phrase, which really just means a libraryAPI at the right level of abstraction for the tasks at hand, so you can accomplish the tasks at hand concisely and without repeated code. Patrick Etienne wrote: Peter - I was bewildered at the notion of needing yet another scripting language, let alone one as library domain-specific (that wording alone throws up red flags everywhere), but I'm not here to bash ideas. Instead I looked up your site and read the small blurb about Nova. It seems that the main objective behind your pursuit is creating a language that provides a specific data type for semantic objects (or relationships). I have to ask, what about semantic maps makes you believe that they require a specific data type rather than just being an object type? Are other scripting languages too slow to suit certain needs such that a new data type is necessitated? I really can't see this being the case. That being said, while it can be an invaluable experience to learn about making scripting languages, if there's to be any community movement toward a particular language (php, ruby, java, scheme or what have you) there has to be some very real and significant benefit. Or more directly, you seem to have specific ideas about a library domain-specific language. What do today's languages not have that you believe is so essential that you'd be willing to write a new scripting language? - Patrick E. On Sat, Oct 30, 2010 at 10:51 AM, Peter Schlumpf pschlu...@earthlink.netmailto:pschlu...@earthlink.net wrote: Bill, you hit a nail pretty squarely on the head. I believe this decades long fetish with MARC has to go. It was designed to efficiently store data on magtapes and doesn't make any sense in today's world. It's a huge millstone around the neck of Libraryland and it keeps them stuck in that tiny little ghetto. Anything can be a mind-prison, even PHP, Python or Django. They are all arbitrary anyway. And you are correct in pointing out that the natural response of librarians to a problem is to seek consensus in a self-absorbed way. Form committees and all that nonsense which never goes anywhere. They are happy enough going around in circles, like the Nowhere Man making all his nowhere plans for nobody. My hope is that some among us would just undertake these problems ourselves. Outside of the realm of the libraries and the limiting mindsets many of us work in. We've all got ideas. Fire up vi and get busy and make something happen, like a library domain-specific language. Start
[CODE4LIB] Last call: survey on staffing for Drupal websites
(Cross-posting to Web4Lib, Code4Lib, and Drupal4Lib - apologies for any duplication.) Hello, all- Last call! Thanks so much to the people that have already responded. I've received multiple requests for the results, so there's a lot of interest and I will definitely post to the list. We're looking at developing a new library website in Drupal, and would like to create a sensible staffing model for future development and maintenance. We are a large academic library looking to do moderate to heavy customization. What sort of staff do we need to support a large, relatively complex Drupal site? Please feel free to either take our 5-10 minute online survey at http://goo.gl/Oqx3 or reply to me directly to respond via email. Thanks in advance, Amanda _ Amanda Rust Research Instruction Librarian Northeastern University, 270 Snell Library 360 Huntington Avenue Boston, MA02115 a.r...@neu.edu / 617-373-8548 _
[CODE4LIB] JOB OPENING : Web Developer at the Stanford University Libraries
To view the position description and apply: 1. Go to http://jobs.stanford.edu/find_a_job.html 2. Keyword search for 40447 - Stanford University Libraries is seeking a talented web developer to support scholarship in the digital age by delivering on the promises of the digital library. This is a 21-month, grant-funded position. The Web Developer will primarily develop digital library software to enable online discovery, viewing and collaborative annotation of digital library materials. He or she will develop and deploy web services to enable interoperability between digital library repositories at different institutions, and will integrate image annotation and transcription tools into digital library applications. The Web Developer will be a member of a core team dedicated to the successful completion of a grant-funded project, and will work closely with the project manager, the information architect, digital library infrastructure developers, the user experience designer and other web developers involved in digital humanities initiatives. This particular project is highly collaborative, and will involve interactions with developers, scholars and staff from other institutions. Developing and implementing open standards and open source software is an explicit objective of the project. As a member of SULAIR’s web development team, the Web Developer will contribute to the overall development of the Stanford Library’s web and digital library infrastructure, and help plan, specify, and build the technologies needed to support the University’s goal of ubiquitous access to scholarly information. Primary Responsibilities: • Design and deploy RESTful web services for exposing and delivering metadata and images from digital library repositories at Stanford and elsewhere. Develop technical documentation describing the web services framework, and work with partners to deploy these web services at other institutions. • Analyze, enrich, and transform digitized content and associated metadata into defined formats, schema and systems. This will involve automated manipulation of XML-based metadata as well as bulk conversion and ingestion of digital image files into digital library repository systems (such as Fedora). • Develop and deploy an online discovery environment that allows visitors to search metadata and full-text indexes of digital library data, and provides users tools to interact with those data. These web-based tools will support text transcription (from scanned images), image annotation and online group collaboration. • Develop and deploy technologies to deliver to the web large digitized images. This includes implementation of a load balanced JPEG2000 image server, supporting web services for streaming images over http and implementation of an image viewing application. • Produce documentation and provide technical support within SULAIR and to partner institutions in deploying and implementing these technologies in different digital library environments. Required Knowledge and Skills • Participation in at least one web development project using Ruby on Rails, Java or PHP. Familiarity with a range of programming and scripting languages is essential; Ruby on Rails expertise is highly desirable. • Demonstrated ability to write solid, simple, elegant code both independently and in a team-programming environment and within schedule limitations. • In-depth knowledge of HTML and related website development technologies and software (especially Javascript, CSS and PHP). • Demonstrated expertise with XML and related tools and technologies (e.g., XML schema, schema management and databases, XSLT, X-forms). • Experience with relational database design and management. Experience implementing database applications for SQL Server, Oracle, or MySQL. • Demonstrated ability to work independently on a project from specification to launch; communicate effectively, orally and in writing; and work with all levels of staff, vendors, and consultants. • Demonstrated proficiency working on a cross-functional web development team, including human-computer interaction specialists, system administrators, database programmers, librarians and end users. • Demonstrated proficiency applying best practices to technical projects, especially test-first development and automated testing. Also must make effective use of team collaboration tools, build management, and version control systems. • Demonstrated success participating in and contributing to open source software development projects. • Demonstrated experience with library applications and technology, including experience participating in relevant library open source efforts. • In-depth knowledge of library policies and practice, metadata standards and the scholarly communication framework • Quick and self-bootstrapping learner. Particularly adept at quickly learning new scripting and programming languages. •
Re: [CODE4LIB] Let's go somewhere [was PHP vs. Python...]
On Tue, Nov 2, 2010 at 5:03 AM, Jonathan Rochkind rochk...@jhu.edu wrote:
I would be very unlikely to use someone's homegrown library specific
scripting language. However, if you want to make a library for an existing
popular scripting
language that handles your specific domain well, I'd be quite likely to use
that if I had a problem with your domain and I was comfortable with the
existing popular scripting language, i'd use it for sure.
Hmm. The balance between the old and tried, and the new and
experimental will, forever, cause these kinds of discussions. Now, I
agree with the basic sentiment of what you're saying, but ...
Odds are your
domain is not really libraries (that's not really a software problem
domain), but perhaps as Patrick suggests dealing with relationships among
semantic objects, and then odds are libraries are not the only people
interested in this problem domain.
I've worked in the three basic tiers of library development world; the
plain vanilla programming world, the semantic web world, and the dark
dungeons of the Cult of MARC. Is the domain of library IT solved by
the generic technologies used? No.
There's nothing bad about a DSL, in fact, I encourage it. If you want
to get away from MARC, say, then having a DSL that approaches meta
data on the programmatic level directly is a wonderful abstraction.
But yes, we have to separate API from language. And API is, mostly
these days, simply a function/method call on top of an abstraction,
and it processes your request with your input. A language, on the
other hand, will let you deal directly with that problem. Most DSLs
are functional abstraction pre-compiled.
The line between a library and a language perhaps these days are more
blurred than ever before, however there are certain things that I
think justifies a library DSL ;
* focus on identity management
* mergability on entities
* large distributed sets
* more defined line between data and meta data
* controlled vocabularies and structures
There's generic tools for all of these, however no one central thing
that binds them all together in a seamless way, elegant or otherwise.
No platform binds these together in an easy nor elegant way, and
perhaps such a thing would be beneficial to the library community, to
create a language that tries to create a bridge between computer
programming and what you learn in library school.
But even if we all concede that a library DSL perhaps is not a
practical solution, I'd still like to see us work on it, for nothing
more than sussing out our actual needs and wants in the process. Don't
underestimate the process of doing something that will never
eventuate, even knowingly.
Some people like ruby because of it's support for creating what they call
domain specific languages, which I think is a silly phrase, which really
just means a libraryAPI at the right level of abstraction for the tasks at
hand, so you can accomplish the tasks at hand concisely and without repeated
code.
Depends on the language. Perhaps this doesn't make sense in Ruby, but
it certainly does in Scala, Haskell, and perhaps more than any, Rebol.
Even Lisp and derivatives, who can create custom structures on the
fly, are well suited to create actual languages that redefine the
language's original syntax and structure. You can redefine the hell
out of C to create any language imaginable, too, even when you
shouldn't.
A well-defined API is not a bad thing, though, but an API are
basically semantic entities in a language to parse structures.
However, a language redefines the syntax used by that language. Sure
you can create a word record in an API that mimics, say, a MARC
record, but the interesting part is when you redefine the syntax to
work *with* that semantic concept, like ;
external_repository {
baseURI: 'http://example.com/',
type: OAI-PHM
}
my_repository {
baseURI: 'http://example.com/',
type: RIF-CS
}
some_vocabulary {
baseURI: 'http://example.com/vocab'
type: thesauri
}
foreach record in external_repository [without tag 850] {
inject into my_repository {
with: exploded words ( tag 245 )
when: match words in some_vocabulary ( NT 2 )
merge into: tag 850
}
}
Creating classes that deal with record merging based on identity
management and various standards would be trivial to script together
super-fast, because the underlying concepts for us is rather
well-known. Hacking this together in Java or otherwise is a test on
patience and sanity, because they are generic tools, even when known
library-type APIs are used. Of course lots of stuff is assumed in the
example, but these are well-understood assumptions (about merging
subject headings (like multiple tags handling, LCSH lookup, etc.),
about identity control, about word lookup (for example, I'm assuming
some form of stemming before matching), and on and on. A language that
half text manipulation and lookup, and
