Re: [CODE4LIB] Let's go somewhere

[Ya'aqov Ziso]

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  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...]

[Patrick Etienne]

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
 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...]

[Jonathan Rochkind]

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
 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...]

[Will Kurt]

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 mailto:rochk...@jhu.edu>>
> Date: November 1, 2010 11:03:13 AM PDT
> To: "CODE4LIB@LISTSERV.ND.EDU" <
> CODE4LIB@LISTSERV.ND.EDU>
> Subject: Re: [CODE4LIB] Let's go somewhere [was PHP vs. Python...]
> Reply-To: Code for Libraries  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
> mailto: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 domai

[CODE4LIB] Last call: survey on staffing for Drupal websites

[Rust, Amanda]

(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
_

Re: [CODE4LIB] Let's go somewhere [was PHP vs. Python...]

[Jonathan Rochkind]

DSL's are simple to create in ruby.  Becuase what people call a DSL in 
ruby is almost always just plain ruby methods -- it's in that context 
that I don't even like the phrase "DSL".  In ruby, developers very 
seldomly find a need to create actually another language with it's own 
grammar and parser and such -- people accomplish the same thing just by 
creating the right ruby methods.  The way that ruby supports the concise 
supplying of code blocks as arguments to methods is usually the key 
thing people rely on to do this.


Will Kurt wrote:

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 mailto:rochk...@jhu.edu>>
Date: November 1, 2010 11:03:13 AM PDT
To: "CODE4LIB@LISTSERV.ND.EDU" <
CODE4LIB@LISTSERV.ND.EDU>
Subject: Re: [CODE4LIB] Let's go somewhere [was PHP vs. Python...]
Reply-To: Code for Libraries >

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
mailto: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 nons

[CODE4LIB] JOB OPENING : Web Developer at the Stanford University Libraries

[Stuart K. Snydman]

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.
• Expert

Re: [CODE4LIB] Let's go somewhere [was PHP vs. Python...]

[Alexander Johannesen]

On Tue, Nov 2, 2010 at 5:03 AM, Jonathan Rochkind  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 looku