Re: [CODE4LIB] Code4Lib Conference Registration

[Roy Tennant]

OMG, this one is for the ages. rsinger++


On Wed, Nov 20, 2013 at 8:33 PM, Ross Singer  wrote:

> I went to the code4lib list
> To get my share of abuse
>
> asked about the conf registration
> Or any information of use
>
> Now John, you can't always get what you want
> No you can't always get what you want
>
> But with a pull request
> Or thoughts on https
>
> You get a disturbing image of rainbows shooting from Sean Hannan's mouth
>
> -Ross.
> p.s. Mick might need to work on that last line a bit
> On Nov 20, 2013 3:52 PM, "John Blair"  wrote:
>
> > Thanks.
> >
> > As much as I love arguments about https and comparing notes on various
> > pet-projects, I wish the website was a little more … put together. This
> > list has added about 30-40+ mails per day to my inbox, and I'm only
> really
> > looking for one bit of information.
> >
> > I might have written "Hotel reservations will be able to be made after
> you
> > register (sometime early-mid Janueary 2014)
> > using the information provided in your registration confirmation."
> >
> > I'm hard to please. ;)
> >
> > -JLB
> >
> >
> > On Nov 20, 2013, at 1:53 PM, Cynthia Ng  wrote:
> >
> > > Registration hasn't opened yet. My guess is sometime in January which
> is
> > > when the program will be set. If you're subscribed to the list, it'll
> be
> > > hard to miss!
> > >
> > >
> > > On Wed, Nov 20, 2013 at 9:45 AM, John Blair 
> wrote:
> > >
> > >> Per the website (bolding mine):
> > >>
> > >> "Finally, the hotel has the capacity to host all of the attendees, and
> > >> we've negotiated a rate of $159/night that includes wireless access in
> > the
> > >> hotel rooms. Hotel reservations will be able to be made after you
> > register
> > >> using the information provided in your registration confirmation. We
> > will
> > >> be publishing more details as they become available."
> > >>
> > >> Where? When? How? Or does registration fall under "…more details…?"
> > >>
> > >>
> > >> -John Blair
> > >>
> >
>

Re: [CODE4LIB] Code4Lib Conference Registration

[Ross Singer]

I went to the code4lib list
To get my share of abuse

asked about the conf registration
Or any information of use

Now John, you can't always get what you want
No you can't always get what you want

But with a pull request
Or thoughts on https

You get a disturbing image of rainbows shooting from Sean Hannan's mouth

-Ross.
p.s. Mick might need to work on that last line a bit
On Nov 20, 2013 3:52 PM, "John Blair"  wrote:

> Thanks.
>
> As much as I love arguments about https and comparing notes on various
> pet-projects, I wish the website was a little more … put together. This
> list has added about 30-40+ mails per day to my inbox, and I'm only really
> looking for one bit of information.
>
> I might have written "Hotel reservations will be able to be made after you
> register (sometime early-mid Janueary 2014)
> using the information provided in your registration confirmation."
>
> I'm hard to please. ;)
>
> -JLB
>
>
> On Nov 20, 2013, at 1:53 PM, Cynthia Ng  wrote:
>
> > Registration hasn't opened yet. My guess is sometime in January which is
> > when the program will be set. If you're subscribed to the list, it'll be
> > hard to miss!
> >
> >
> > On Wed, Nov 20, 2013 at 9:45 AM, John Blair  wrote:
> >
> >> Per the website (bolding mine):
> >>
> >> "Finally, the hotel has the capacity to host all of the attendees, and
> >> we've negotiated a rate of $159/night that includes wireless access in
> the
> >> hotel rooms. Hotel reservations will be able to be made after you
> register
> >> using the information provided in your registration confirmation. We
> will
> >> be publishing more details as they become available."
> >>
> >> Where? When? How? Or does registration fall under "…more details…?"
> >>
> >>
> >> -John Blair
> >>
>

Re: [CODE4LIB] Should linked data URIs be https?

[Riley Childs]

No, because not every site yet supports HTTPS and there is no time in the
future I see such a thing happening because of the high price of SSL/TLS
Certs, my website doesn't have a signed HTTPS cert because I don't have
$150 to spend on it (unless someone wants to pony up, in which case I would
dig it), similar to the discussion of CODE4LIB.ORG (which has yet to be
resolved) moving to HTTPS. In short there are many more websites on HTTP
then there are on HTTPS (and we are talking millions more)  and until the
Administrative cost goes away (not for a long time!) not everyone will be
able to move to HTTPS and to ensure interoperablity we can't make https the
default!

*Riley Childs*
*Library Technology Manager at Charlotte United Christian Academy
*
*Head Programmer/Manager at Open Library Management Projec
t *
*Cisco Certified Entry Level Technician *
_

*Phone: +1 (704) 497-2086*
*email: ri...@tfsgeo.com *
*email: ri...@rileychilds.net *
*Twitter: @RowdyChildren *




On Wed, Nov 20, 2013 at 1:48 PM, Simeon Warner wrote:

> Connecting two recent c4l threads... It seems that the web is rapidly
> moving toward https. I'm tempted to wonder how soon it will be before https
> is the default protocol when you type a bare domain name into your browser?
> [1] With linked data we want cool URIs, where one element of coolness is
> persistence. If it is likely that http URIs will be seen to be "unclean"
> [2] in the near future that would surely be a pressure to change them.
> Should we just go ahead and always use https URIs for linked data now?
>
> Cheers,
> Simeon
>
> [1] Of course you can do this yourself much of time with HTTPS Everywhere <
> https://www.eff.org/https-everywhere> but I really mean when is it so
> much the norm that chrome/firefox/safari/etc. do that expansion out of the
> box, instead of assuming http.
>
> [2] Perhaps snoopability of http traffic doesn't matter in the bulk
> harvest case but in the case of an individual following a link, any use of
> an http URI could leak significant info about what is being looked at even
> the server immediately redirects to an ssl page.
>

[CODE4LIB] Canberra event -- Ed Summers at NLA, 2 December

[Tim Sherratt]

Hi all,

If you're in the Canberra region come along and hear Ed Summers talk about
cultural heritage and the web as part of the National Library of
Australia's Innovative Ideas program. It's on 2 December, 12.30-1.30pm at
the NLA:

http://www.nla.gov.au/event/6135

All welcome!

And thanks to New Zealand's awesome National Digital Forum for bringing Ed
to our part of the world.

Cheers, Tim


Dr Tim Sherratt
Manager, Trove
National Library of Australia
Parkes Place
Canberra ACT 2600
p: +61 (0)2 6262 1224
e: tsher...@nla.gov.au

Re: [CODE4LIB] Code4Lib Conference Registration

[Bohyun Kim]

That link should have come with a warning. 
*Too haunted to say anything further*

~Bohyun

On Nov 20, 2013, at 6:27 PM, "Michael J. Giarlo"  
wrote:

> Don't ever change.
> 
> 
> 
> On Wed, Nov 20, 2013 at 2:53 PM, Sean Hannan  wrote:
> 
>> Did someone say colors?
>> 
>> http://dysinterested.com/rainbows.html
>> 
>> -Sean
>> 
>> From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Doran,
>> Michael D [do...@uta.edu]
>> Sent: Wednesday, November 20, 2013 4:55 PM
>> To: CODE4LIB@LISTSERV.ND.EDU
>> Subject: Re: [CODE4LIB] Code4Lib Conference Registration
>> 
>>> I wish the website was a little more ... put together
>> 
>> 
>> 
>> What!  Then they would make us surrender our colors.
>> 
>> 
>> 
>> [cid:image003.jpg@01CEE608.F2CCD4C0]
>> 
>> 
>> 
>> -- Michael
>> 
>> 
>> 
>>> -Original Message-
>> 
>>> From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
>> John
>> 
>>> Blair
>> 
>>> Sent: Wednesday, November 20, 2013 2:52 PM
>> 
>>> To: CODE4LIB@LISTSERV.ND.EDU
>> 
>>> Subject: Re: [CODE4LIB] Code4Lib Conference Registration
>> 
>>> 
>> 
>>> Thanks.
>> 
>>> 
>> 
>>> As much as I love arguments about https and comparing notes on various
>> pet-
>> 
>>> projects, I wish the website was a little more ... put together. This
>> list has
>> 
>>> added about 30-40+ mails per day to my inbox, and I'm only really looking
>> 
>>> for one bit of information.
>> 
>>> 
>> 
>>> I might have written "Hotel reservations will be able to be made after
>> you
>> 
>>> register (sometime early-mid Janueary 2014)
>> 
>>> using the information provided in your registration confirmation."
>> 
>>> 
>> 
>>> I'm hard to please. ;)
>> 
>>> 
>> 
>>> -JLB
>> 
>>> 
>> 
>>> 
>> 
>>> On Nov 20, 2013, at 1:53 PM, Cynthia Ng > cynthia.s...@gmail.com>> wrote:
>> 
>>> 
>> 
 Registration hasn't opened yet. My guess is sometime in January which
>> is
>> 
 when the program will be set. If you're subscribed to the list, it'll
>> be
>> 
 hard to miss!
>> 
 
>> 
 
>> 
 On Wed, Nov 20, 2013 at 9:45 AM, John Blair > > wrote:
>> 
 
>> 
> Per the website (bolding mine):
>> 
> 
>> 
> "Finally, the hotel has the capacity to host all of the attendees, and
>> 
> we've negotiated a rate of $159/night that includes wireless access in
>> 
>>> the
>> 
> hotel rooms. Hotel reservations will be able to be made after you
>> 
>>> register
>> 
> using the information provided in your registration confirmation. We
>> will
>> 
> be publishing more details as they become available."
>> 
> 
>> 
> Where? When? How? Or does registration fall under "...more
>> details...?"
>> 
> 
>> 
> 
>> 
> -John Blair
>> 
> 
>> 

Re: [CODE4LIB] Code4Lib Conference Registration

[John Blair]

Was clicking on that sufficient punishment for my complaining, or must I look 
again?

-John Blair


On Nov 20, 2013, at 4:53 PM, Sean Hannan 
 wrote:

> Did someone say colors?
> 
> http://dysinterested.com/rainbows.html
> 
> -Sean
> 
> From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Doran, 
> Michael D [do...@uta.edu]
> Sent: Wednesday, November 20, 2013 4:55 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Code4Lib Conference Registration
> 
>> I wish the website was a little more ... put together
> 
> 
> 
> What!  Then they would make us surrender our colors.
> 
> 
> 
> [cid:image003.jpg@01CEE608.F2CCD4C0]
> 
> 
> 
> -- Michael
> 
> 
> 
>> -Original Message-
> 
>> From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of John
> 
>> Blair
> 
>> Sent: Wednesday, November 20, 2013 2:52 PM
> 
>> To: CODE4LIB@LISTSERV.ND.EDU
> 
>> Subject: Re: [CODE4LIB] Code4Lib Conference Registration
> 
>> 
> 
>> Thanks.
> 
>> 
> 
>> As much as I love arguments about https and comparing notes on various pet-
> 
>> projects, I wish the website was a little more ... put together. This list 
>> has
> 
>> added about 30-40+ mails per day to my inbox, and I'm only really looking
> 
>> for one bit of information.
> 
>> 
> 
>> I might have written "Hotel reservations will be able to be made after you
> 
>> register (sometime early-mid Janueary 2014)
> 
>> using the information provided in your registration confirmation."
> 
>> 
> 
>> I'm hard to please. ;)
> 
>> 
> 
>> -JLB
> 
>> 
> 
>> 
> 
>> On Nov 20, 2013, at 1:53 PM, Cynthia Ng 
>> mailto:cynthia.s...@gmail.com>> wrote:
> 
>> 
> 
>>> Registration hasn't opened yet. My guess is sometime in January which is
> 
>>> when the program will be set. If you're subscribed to the list, it'll be
> 
>>> hard to miss!
> 
>>> 
> 
>>> 
> 
>>> On Wed, Nov 20, 2013 at 9:45 AM, John Blair 
>>> mailto:john.bl...@usm.edu>> wrote:
> 
>>> 
> 
 Per the website (bolding mine):
> 
 
> 
 "Finally, the hotel has the capacity to host all of the attendees, and
> 
 we've negotiated a rate of $159/night that includes wireless access in
> 
>> the
> 
 hotel rooms. Hotel reservations will be able to be made after you
> 
>> register
> 
 using the information provided in your registration confirmation. We will
> 
 be publishing more details as they become available."
> 
 
> 
 Where? When? How? Or does registration fall under "...more details...?"
> 
 
> 
 
> 
 -John Blair
> 
 

Re: [CODE4LIB] Code4Lib Conference Registration

[Michael J. Giarlo]

Don't ever change.



On Wed, Nov 20, 2013 at 2:53 PM, Sean Hannan  wrote:

> Did someone say colors?
>
> http://dysinterested.com/rainbows.html
>
> -Sean
> 
> From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Doran,
> Michael D [do...@uta.edu]
> Sent: Wednesday, November 20, 2013 4:55 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Code4Lib Conference Registration
>
> > I wish the website was a little more ... put together
>
>
>
> What!  Then they would make us surrender our colors.
>
>
>
> [cid:image003.jpg@01CEE608.F2CCD4C0]
>
>
>
> -- Michael
>
>
>
> > -Original Message-
>
> > From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
> John
>
> > Blair
>
> > Sent: Wednesday, November 20, 2013 2:52 PM
>
> > To: CODE4LIB@LISTSERV.ND.EDU
>
> > Subject: Re: [CODE4LIB] Code4Lib Conference Registration
>
> >
>
> > Thanks.
>
> >
>
> > As much as I love arguments about https and comparing notes on various
> pet-
>
> > projects, I wish the website was a little more ... put together. This
> list has
>
> > added about 30-40+ mails per day to my inbox, and I'm only really looking
>
> > for one bit of information.
>
> >
>
> > I might have written "Hotel reservations will be able to be made after
> you
>
> > register (sometime early-mid Janueary 2014)
>
> > using the information provided in your registration confirmation."
>
> >
>
> > I'm hard to please. ;)
>
> >
>
> > -JLB
>
> >
>
> >
>
> > On Nov 20, 2013, at 1:53 PM, Cynthia Ng  cynthia.s...@gmail.com>> wrote:
>
> >
>
> > > Registration hasn't opened yet. My guess is sometime in January which
> is
>
> > > when the program will be set. If you're subscribed to the list, it'll
> be
>
> > > hard to miss!
>
> > >
>
> > >
>
> > > On Wed, Nov 20, 2013 at 9:45 AM, John Blair  > wrote:
>
> > >
>
> > >> Per the website (bolding mine):
>
> > >>
>
> > >> "Finally, the hotel has the capacity to host all of the attendees, and
>
> > >> we've negotiated a rate of $159/night that includes wireless access in
>
> > the
>
> > >> hotel rooms. Hotel reservations will be able to be made after you
>
> > register
>
> > >> using the information provided in your registration confirmation. We
> will
>
> > >> be publishing more details as they become available."
>
> > >>
>
> > >> Where? When? How? Or does registration fall under "...more
> details...?"
>
> > >>
>
> > >>
>
> > >> -John Blair
>
> > >>
>

Re: [CODE4LIB] Code4Lib Conference Registration

[Dan Eveland]

If only I could un-see that.


On Wed, Nov 20, 2013 at 5:53 PM, Sean Hannan  wrote:

> Did someone say colors?
>
> http://dysinterested.com/rainbows.html
>
> -Sean
> 
> From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Doran,
> Michael D [do...@uta.edu]
> Sent: Wednesday, November 20, 2013 4:55 PM
> To: CODE4LIB@LISTSERV.ND.EDU
> Subject: Re: [CODE4LIB] Code4Lib Conference Registration
>
> > I wish the website was a little more ... put together
>
>
>
> What!  Then they would make us surrender our colors.
>
>
>
> [cid:image003.jpg@01CEE608.F2CCD4C0]
>
>
>
> -- Michael
>
>
>
> > -Original Message-
>
> > From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
> John
>
> > Blair
>
> > Sent: Wednesday, November 20, 2013 2:52 PM
>
> > To: CODE4LIB@LISTSERV.ND.EDU
>
> > Subject: Re: [CODE4LIB] Code4Lib Conference Registration
>
> >
>
> > Thanks.
>
> >
>
> > As much as I love arguments about https and comparing notes on various
> pet-
>
> > projects, I wish the website was a little more ... put together. This
> list has
>
> > added about 30-40+ mails per day to my inbox, and I'm only really looking
>
> > for one bit of information.
>
> >
>
> > I might have written "Hotel reservations will be able to be made after
> you
>
> > register (sometime early-mid Janueary 2014)
>
> > using the information provided in your registration confirmation."
>
> >
>
> > I'm hard to please. ;)
>
> >
>
> > -JLB
>
> >
>
> >
>
> > On Nov 20, 2013, at 1:53 PM, Cynthia Ng  cynthia.s...@gmail.com>> wrote:
>
> >
>
> > > Registration hasn't opened yet. My guess is sometime in January which
> is
>
> > > when the program will be set. If you're subscribed to the list, it'll
> be
>
> > > hard to miss!
>
> > >
>
> > >
>
> > > On Wed, Nov 20, 2013 at 9:45 AM, John Blair  > wrote:
>
> > >
>
> > >> Per the website (bolding mine):
>
> > >>
>
> > >> "Finally, the hotel has the capacity to host all of the attendees, and
>
> > >> we've negotiated a rate of $159/night that includes wireless access in
>
> > the
>
> > >> hotel rooms. Hotel reservations will be able to be made after you
>
> > register
>
> > >> using the information provided in your registration confirmation. We
> will
>
> > >> be publishing more details as they become available."
>
> > >>
>
> > >> Where? When? How? Or does registration fall under "...more
> details...?"
>
> > >>
>
> > >>
>
> > >> -John Blair
>
> > >>
>

Re: [CODE4LIB] Code4Lib Conference Registration

[Sean Hannan]

Did someone say colors?

http://dysinterested.com/rainbows.html

-Sean

From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] on behalf of Doran, Michael 
D [do...@uta.edu]
Sent: Wednesday, November 20, 2013 4:55 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Code4Lib Conference Registration

> I wish the website was a little more ... put together



What!  Then they would make us surrender our colors.



[cid:image003.jpg@01CEE608.F2CCD4C0]



-- Michael



> -Original Message-

> From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of John

> Blair

> Sent: Wednesday, November 20, 2013 2:52 PM

> To: CODE4LIB@LISTSERV.ND.EDU

> Subject: Re: [CODE4LIB] Code4Lib Conference Registration

>

> Thanks.

>

> As much as I love arguments about https and comparing notes on various pet-

> projects, I wish the website was a little more ... put together. This list has

> added about 30-40+ mails per day to my inbox, and I'm only really looking

> for one bit of information.

>

> I might have written "Hotel reservations will be able to be made after you

> register (sometime early-mid Janueary 2014)

> using the information provided in your registration confirmation."

>

> I'm hard to please. ;)

>

> -JLB

>

>

> On Nov 20, 2013, at 1:53 PM, Cynthia Ng 
> mailto:cynthia.s...@gmail.com>> wrote:

>

> > Registration hasn't opened yet. My guess is sometime in January which is

> > when the program will be set. If you're subscribed to the list, it'll be

> > hard to miss!

> >

> >

> > On Wed, Nov 20, 2013 at 9:45 AM, John Blair 
> > mailto:john.bl...@usm.edu>> wrote:

> >

> >> Per the website (bolding mine):

> >>

> >> "Finally, the hotel has the capacity to host all of the attendees, and

> >> we've negotiated a rate of $159/night that includes wireless access in

> the

> >> hotel rooms. Hotel reservations will be able to be made after you

> register

> >> using the information provided in your registration confirmation. We will

> >> be publishing more details as they become available."

> >>

> >> Where? When? How? Or does registration fall under "...more details...?"

> >>

> >>

> >> -John Blair

> >>

Re: [CODE4LIB] Code4Lib Conference Registration

[Trevor Thornton]

I've updated the site with a note about registration, and added a link to
vote on prepared talks.

Now let's all be friends.

-Trevor


On Wed, Nov 20, 2013 at 4:55 PM, Doran, Michael D  wrote:

> > I wish the website was a little more ... put together
>
>
>
> What!  Then they would make us surrender our colors.
>
>
>
> [cid:image003.jpg@01CEE608.F2CCD4C0]
>
>
>
> -- Michael
>
>
>
> > -Original Message-
>
> > From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of
> John
>
> > Blair
>
> > Sent: Wednesday, November 20, 2013 2:52 PM
>
> > To: CODE4LIB@LISTSERV.ND.EDU
>
> > Subject: Re: [CODE4LIB] Code4Lib Conference Registration
>
> >
>
> > Thanks.
>
> >
>
> > As much as I love arguments about https and comparing notes on various
> pet-
>
> > projects, I wish the website was a little more ... put together. This
> list has
>
> > added about 30-40+ mails per day to my inbox, and I'm only really looking
>
> > for one bit of information.
>
> >
>
> > I might have written "Hotel reservations will be able to be made after
> you
>
> > register (sometime early-mid Janueary 2014)
>
> > using the information provided in your registration confirmation."
>
> >
>
> > I'm hard to please. ;)
>
> >
>
> > -JLB
>
> >
>
> >
>
> > On Nov 20, 2013, at 1:53 PM, Cynthia Ng  cynthia.s...@gmail.com>> wrote:
>
> >
>
> > > Registration hasn't opened yet. My guess is sometime in January which
> is
>
> > > when the program will be set. If you're subscribed to the list, it'll
> be
>
> > > hard to miss!
>
> > >
>
> > >
>
> > > On Wed, Nov 20, 2013 at 9:45 AM, John Blair  > wrote:
>
> > >
>
> > >> Per the website (bolding mine):
>
> > >>
>
> > >> "Finally, the hotel has the capacity to host all of the attendees, and
>
> > >> we've negotiated a rate of $159/night that includes wireless access in
>
> > the
>
> > >> hotel rooms. Hotel reservations will be able to be made after you
>
> > register
>
> > >> using the information provided in your registration confirmation. We
> will
>
> > >> be publishing more details as they become available."
>
> > >>
>
> > >> Where? When? How? Or does registration fall under "...more
> details...?"
>
> > >>
>
> > >>
>
> > >> -John Blair
>
> > >>
>



-- 
Trevor Thornton
Senior Applications Developer, NYPL Labs
The New York Public Library
phone: 212-621-0287
email: trevorthorn...@nypl.org

[CODE4LIB] Job: Archivist, Digital Archives at Canadian Centre for Architecture

[jobs]

Archivist, Digital Archives
Canadian Centre for Architecture
Montreal

JOB DESCRIPTION

**Job Identification**  
Job title: Archivist, Digital Archives

Division: Collection

Supervisor: Associate Director, Collection

Status: Permanent

Posting period: November 20 to December 6, 2013

Job entry: January 2014

  
**Job Summary**  
Reporting to the Associate Director, Collection, the archivist is responsible
for the supervision, coordination and monitoring of the archival activities
related to CCA's archives (including institutional archives), drawings, prints
and photographs, with a special attention to born-digital archives. For born-
digital material the incumbent will have to establish best practices for
managing born-digital material held and acquired by the CCA, and assist in the
strategic direction of archiving and accession to born-digital material. The
incumbent plays a key role in the documentation of CCA Collection through the
development of standards and procedures, classification and description.
Finally, the incumbent implements and maintains institutional archives
strategies and policies.

  
  
**Key responsibilities**  
_Management of born-digital material archives:_

• Establish a set of best practices for archives held and acquired by the CCA

• Develop (through hands-on work and experimentation) and document procedures
and policies for the migration, description, and management of (born-digital)
archives;

• Assist in prioritizing (born-digital) archives projects
to be processed and catalogued;

• Collaborate with the Program, Research and Publications divisions in
deciphering acquisition and research material, born digital archives and
evaluating the relevancy for public concern.

• Collaborate with IT to identify and engage the resources (hardware,
software, vendors, peer institutions) available to perform migration from
current and obsolete media containing born-digital material;

• Review and process archival collections;

• Negotiate agreements with donors and lenders archives and works for the
Collection;

• In collaboration with Conservation, locate (born-digital) archives in other
areas of the collection and institution and develop plans for their management
and preservation.

Acquisition of electronic records and personal papers:

• Enhance the CCA's capacity to responsibly acquire electronic records and
papers;

• Investigate potential acquisitions and evaluate proposed acquisitions;

• Develop and document techniques, procedures, and policies for acquiring;

• Coordinate acquisitions of electronic records, acting as a liaison between
records creators and the CCA's curatorial, archival, preservation and
technical staff;

• When necessary and possible, work directly with records creators to advise
on record- keeping practices that will facilitate the eventual transfer of
their archives.

  
_Advisory and administrative responsibilities:_

• Advise Collection staff of the functional requirements for acquiring,
preserving, and accession to (born-digital) archives and train archivist
trainees, curators and cataloguers as necessary;

• In collaboration with Development, initiate, write, and contribute to grant
proposals as appropriate;

• Contribute to broader discussions surrounding the management of digital
assets, metadata, and the representation and service of digital and digitized
materials;

• Serve as the Collection Division's internal and external representative and
authority on issues related to born-digital archives;

• Act as an advisor and specialist on institutional archives.

  
**Required qualification**  
• Education : Master's degree in library science, archival
science, or other relevant field

• Number of years of relevant experience: 3-5 years working in an archival
repository in a professional capacity, including experience working with born-
digital archival material.

  
_Key Competencies:_

• Fluency in French and English, oral and written; ability to write and revise
documents

• Ability to plan and manage schedules

• Project management experience an asset

• Demonstrated experience in reading, using and manipulating both digitized
and born-digital architectural records in common formats and programs
(AutoCAD/Revit, VectorWorks, Microstation, Rhino, Maya, etc.);

• Knowledge of RAD, DACS, and other archival descriptive standards;

• Demonstrated familiarity with data structure standards relevant to the
archival control of digital collection materials (EAD, Dublin Core, MODS,
METS, PREMIS);

• Strong command of archival theory and best practices;

• Knowledge of historical research methods, especially the use of archives and
born-digital repository systems;

• Understanding of issues related to both digitized and born-digital formats,
media, and migration is required;

• Excellent writing and editorial skills in French and/or English;

• Project management experience;

• Demonstrated ability to work independently as well as collaboratively and to
meet planne

Re: [CODE4LIB] Code4Lib Conference Registration

[John Blair]

I don't know that anything is really "broken." I just have this, preconceived 
notion that when you put together any event you'd want to communicate a few 
things like Where it is going to occur, When it will occur, how/when you may 
purchase a ticket/register.

For example, I've never gone to a concert that was advertised as: "Mega Guitar 
Shredders will be at AXE GRIND theater, January 17, 1993!!! Tickets Available: 
Somehow, somewhere, you can't really miss it."

I mean... I get it… I'm being all high and mighty. Sorry for that. But my 
institution is VERY competitive when it comes to securing funds/time for this 
sort of thing, and I'm under some amount of pressure.

To those suggesting "you do it, since your such the big man!" Thank you for the 
offer, and I didn't know that was how things operated, but in this case I don't 
think I could have done much to help (since I don't have access to the 
information). However, it seems like some of you guys DO have that information, 
and here I am saying "What up?"

-John Blair



On Nov 20, 2013, at 3:14 PM, Francis Kayiwa  wrote:

> On Wed, Nov 20, 2013 at 3:52 PM, John Blair  wrote:
> 
>> Thanks.
>> 
>> As much as I love arguments about https and comparing notes on various
>> pet-projects, I wish the website was a little more … put together. This
>> list has added about 30-40+ mails per day to my inbox, and I'm only really
>> looking for one bit of information.
> 
> 
>> I might have written "Hotel reservations will be able to be made after you
>> register (sometime early-mid Janueary 2014)
>> using the information provided in your registration confirmation."
>> 
>> I'm hard to please. ;)
>> 
> 
> 
> Is there anything in particular that is unclear or not put together? You
> can either *submit a patch* to fix it. Contact the person who posted this
> and ask for clarity. Ideally still *submit a patch*.
> 
> The organizers are all volunteering their time. You could make their lives
> and what one can imagine the others suffering in silence like you by
> volunteering to fix it... even by simply saying what is missing. Most of
> them (I dare say ALL) will gladly accept "pull requests".
> 
> Otherwise like Cynthiar suggested it will be impossible to miss when
> registration opens. Take a look at the Archives [0] if you need proof.
> 
> 
> Cheers,
> 
> ./fxk
> 
> [0] http://serials.infomotions.com/code4lib/
> 
> -- 
> 
> SUN Microsystems:
>   The Network IS the Load Average

Re: [CODE4LIB] Code4Lib Conference Registration

[Chad Nelson]

Hi John,

As code4lib is a community effort to which anyone can contribute, you don't
need to stop at saying what you might have written, you can actually go
write it. If you already have an account on the code4lib site, you can edit
that page  to improve everyone's
experience. If you don't yet have an account, you can sign up for
one and
then go edit that page.

If you want code4lib to do something better, you can suggest it and maybe
someone will implement. But, if you REALLY want something done, you are
better off just doing it yourself.

This idea is, without doubt, my favorite part about code4lib.

John, I sincerely invite you to fully participate in code4lib. We welcome
your feedback, and even more, so your actions, to make the community
better. The more you give, the better the community will be for all of us.

Thanks,
Chad


On Wed, Nov 20, 2013 at 3:52 PM, John Blair  wrote:

> Thanks.
>
> As much as I love arguments about https and comparing notes on various
> pet-projects, I wish the website was a little more … put together. This
> list has added about 30-40+ mails per day to my inbox, and I'm only really
> looking for one bit of information.
>
> I might have written "Hotel reservations will be able to be made after you
> register (sometime early-mid Janueary 2014)
> using the information provided in your registration confirmation."
>
> I'm hard to please. ;)
>
> -JLB
>
>
> On Nov 20, 2013, at 1:53 PM, Cynthia Ng  wrote:
>
> > Registration hasn't opened yet. My guess is sometime in January which is
> > when the program will be set. If you're subscribed to the list, it'll be
> > hard to miss!
> >
> >
> > On Wed, Nov 20, 2013 at 9:45 AM, John Blair  wrote:
> >
> >> Per the website (bolding mine):
> >>
> >> "Finally, the hotel has the capacity to host all of the attendees, and
> >> we've negotiated a rate of $159/night that includes wireless access in
> the
> >> hotel rooms. Hotel reservations will be able to be made after you
> register
> >> using the information provided in your registration confirmation. We
> will
> >> be publishing more details as they become available."
> >>
> >> Where? When? How? Or does registration fall under "…more details…?"
> >>
> >>
> >> -John Blair
> >>
>

Re: [CODE4LIB] Code4Lib Conference Registration

[Cynthia Ng]

Well, they will definitely announce it on the website too when registration
goes up.


On Wed, Nov 20, 2013 at 12:52 PM, John Blair  wrote:

> Thanks.
>
> As much as I love arguments about https and comparing notes on various
> pet-projects, I wish the website was a little more … put together. This
> list has added about 30-40+ mails per day to my inbox, and I'm only really
> looking for one bit of information.
>
> I might have written "Hotel reservations will be able to be made after you
> register (sometime early-mid Janueary 2014)
> using the information provided in your registration confirmation."
>
> I'm hard to please. ;)
>
> -JLB
>
>
> On Nov 20, 2013, at 1:53 PM, Cynthia Ng  wrote:
>
> > Registration hasn't opened yet. My guess is sometime in January which is
> > when the program will be set. If you're subscribed to the list, it'll be
> > hard to miss!
> >
> >
> > On Wed, Nov 20, 2013 at 9:45 AM, John Blair  wrote:
> >
> >> Per the website (bolding mine):
> >>
> >> "Finally, the hotel has the capacity to host all of the attendees, and
> >> we've negotiated a rate of $159/night that includes wireless access in
> the
> >> hotel rooms. Hotel reservations will be able to be made after you
> register
> >> using the information provided in your registration confirmation. We
> will
> >> be publishing more details as they become available."
> >>
> >> Where? When? How? Or does registration fall under "…more details…?"
> >>
> >>
> >> -John Blair
> >>
>

Re: [CODE4LIB] Code4Lib Conference Registration

[Francis Kayiwa]

On Wed, Nov 20, 2013 at 3:52 PM, John Blair  wrote:

> Thanks.
>
> As much as I love arguments about https and comparing notes on various
> pet-projects, I wish the website was a little more … put together. This
> list has added about 30-40+ mails per day to my inbox, and I'm only really
> looking for one bit of information.


> I might have written "Hotel reservations will be able to be made after you
> register (sometime early-mid Janueary 2014)
> using the information provided in your registration confirmation."
>
> I'm hard to please. ;)
>


Is there anything in particular that is unclear or not put together? You
can either *submit a patch* to fix it. Contact the person who posted this
and ask for clarity. Ideally still *submit a patch*.

The organizers are all volunteering their time. You could make their lives
and what one can imagine the others suffering in silence like you by
volunteering to fix it... even by simply saying what is missing. Most of
them (I dare say ALL) will gladly accept "pull requests".

Otherwise like Cynthiar suggested it will be impossible to miss when
registration opens. Take a look at the Archives [0] if you need proof.


Cheers,

./fxk

[0] http://serials.infomotions.com/code4lib/

-- 

SUN Microsystems:
The Network IS the Load Average

Re: [CODE4LIB] Tool for managing subscription content metadata

[Dycus, Jeff A]

Hi Hugh-

You may want to check out CORAL http://erm.library.nd.edu/ 

It is an open source MySQL/PHP system that seems like it would do most of what 
you want it to do, and could probably be modified to do it all.


Jeff Dycus
Library Specialist, Electronic Resources

University of Kentucky
William T. Young Library
500 S. Limestone 
Lexington, KY  40506-0456

(859) 218-0678
jeff.dy...@uky.edu



-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Barnes, 
Hugh
Sent: Monday, November 18, 2013 10:27 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: [CODE4LIB] Tool for managing subscription content metadata

Hi

An exercise we've just been through (don't ask!) has revealed a dire need to 
track information about subscription service vendors (e.g. serials, databases, 
e-book publishers) in a better way than Office documents. I am looking for a 
tool, ideally one to rule them all. Throwing it out here.

The sort of information I am wanting to manage and give everyone an easy 
reference to is:

* name
* previous and variant names (they do like to re-brand)
* login details (I can probably live with this being in a separate tool)
* contact names and numbers
* remote host URLs and URL patterns
* ways we interact with them (e.g. do we change registered IP addresses by 
online form or by email notification?)
* license information, maybe copies of them
* how we authenticate our users
* conditions of access (e.g. on/off campus, students/staff/alumni/walk-ins)
* a simple activity log or just notes field

Excluded or at least hidden from ordinary users:
* invoicing and financial information
* passwords (seems risky, happy to use a password safe for this)

Essentially it's a catalogue/inventory of subscriptions we have. In some 
respects it's a lightweight CRM.

Bonus points, I think, for having citable entries that we can share in emails 
(URLs probably, so a web interface).

It would be brilliant if salient information was structured enough to export 
summaries or, say, generate EZProxy configuration files.

I have been thinking along the lines of Mediawiki, maybe with a good template. 
From experience though, I worry about the willingness of new users to edit wiki 
content, especially in templates with lots of curly braces. I don't know if 
there is an actively maintained plug-in to turn a template into a 
non-threatening online form. Evan Prodromou's extension seems long abandoned 
[1]. Solving that issue, I think Mediawiki would be a good fit.

So what do folks in this list use for the above functionality and how does it 
work? Or what _would_ you use? All insight appreciated.

Cheers

[1] http://www.mediawiki.org/wiki/Extension:Form

Hugh Barnes
Digital Access Coordinator
Library, Teaching and Learning
Lincoln University
Christchurch
New Zealand
p +64 3 423 0357


P Please consider the environment before you print this email.
"The contents of this e-mail (including any attachments) may be confidential 
and/or subject to copyright. Any unauthorised use, distribution, or copying of 
the contents is expressly prohibited. If you have received this e-mail in 
error, please advise the sender by return e-mail or telephone and then delete 
this e-mail together with all attachments from your system."

Re: [CODE4LIB] Code4Lib Conference Registration

[John Blair]

Thanks.

As much as I love arguments about https and comparing notes on various 
pet-projects, I wish the website was a little more … put together. This list 
has added about 30-40+ mails per day to my inbox, and I'm only really looking 
for one bit of information.

I might have written "Hotel reservations will be able to be made after you 
register (sometime early-mid Janueary 2014)
using the information provided in your registration confirmation."

I'm hard to please. ;)

-JLB


On Nov 20, 2013, at 1:53 PM, Cynthia Ng  wrote:

> Registration hasn't opened yet. My guess is sometime in January which is
> when the program will be set. If you're subscribed to the list, it'll be
> hard to miss!
> 
> 
> On Wed, Nov 20, 2013 at 9:45 AM, John Blair  wrote:
> 
>> Per the website (bolding mine):
>> 
>> "Finally, the hotel has the capacity to host all of the attendees, and
>> we've negotiated a rate of $159/night that includes wireless access in the
>> hotel rooms. Hotel reservations will be able to be made after you register
>> using the information provided in your registration confirmation. We will
>> be publishing more details as they become available."
>> 
>> Where? When? How? Or does registration fall under "…more details…?"
>> 
>> 
>> -John Blair
>> 

Re: [CODE4LIB] Code4Lib Conference Registration

[Cynthia Ng]

Registration hasn't opened yet. My guess is sometime in January which is
when the program will be set. If you're subscribed to the list, it'll be
hard to miss!


On Wed, Nov 20, 2013 at 9:45 AM, John Blair  wrote:

> Per the website (bolding mine):
>
> "Finally, the hotel has the capacity to host all of the attendees, and
> we've negotiated a rate of $159/night that includes wireless access in the
> hotel rooms. Hotel reservations will be able to be made after you register
> using the information provided in your registration confirmation. We will
> be publishing more details as they become available."
>
> Where? When? How? Or does registration fall under "…more details…?"
>
>
> -John Blair
>

[CODE4LIB] Should linked data URIs be https?

[Simeon Warner]

Connecting two recent c4l threads... It seems that the web is rapidly 
moving toward https. I'm tempted to wonder how soon it will be before 
https is the default protocol when you type a bare domain name into your 
browser? [1] With linked data we want cool URIs, where one element of 
coolness is persistence. If it is likely that http URIs will be seen to 
be "unclean" [2] in the near future that would surely be a pressure to 
change them. Should we just go ahead and always use https URIs for 
linked data now?


Cheers,
Simeon

[1] Of course you can do this yourself much of time with HTTPS 
Everywhere  but I really mean when 
is it so much the norm that chrome/firefox/safari/etc. do that expansion 
out of the box, instead of assuming http.


[2] Perhaps snoopability of http traffic doesn't matter in the bulk 
harvest case but in the case of an individual following a link, any use 
of an http URI could leak significant info about what is being looked at 
even the server immediately redirects to an ssl page.

Re: [CODE4LIB] RHEV-M

[Cary Gordon]

We used Xen to manage our data center for about 8 years. We used the Cirtix 
"Enterpise" version, but I believe that most, if not all, of the features we 
needed are now in the community (FOSS) version.

It was troublefree, and we would happily use it again, if we every returned to 
running a datacenter, which happily we are never going to do. We are now happy 
AWS customers and partners.

Thanks,

Cary


On Nov 19, 2013, at 7:05 PM, Lynne E. Grigsby  
wrote:

> Is anyone using RHEV-M to manager their Linux virtual server environment?
> We are interested in talking to someone about their experience.  We have
> found plenty of people to talk to about VMware, but would like to
> investigate an alternative.
> 
> Thanks for your help.
> Lynne

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Scott Prater]

Thanks, Jonathan.  We'll definitely check it out.

-- Scott

On 11/20/2013 12:13 PM, Jonathan Rochkind wrote:

On 11/20/13 12:51 PM, Scott Prater wrote:

I think the issue comes down to a distinction between a stream and a
record.  Ideally, the ruby-marc library would keep pointers to which
record it is in, where the record begins, and where the record ends in
the stream.  If a valid header and end-of-record delimiter are in place,
then the library should be able to reject the record if it contains
garbage in between those two points, without compromising the integrity
of the entire stream.


I understand what you're saying, and why it's attractive. I am not sure
if ruby-marc can do that right now. I am not personally interested in
adding that at this particular time -- I just spent a couple days adding
Marc8 support in the first place, and that's enough for me for now.  I
was just soliciting some feedback on a point I wasn't sure about with
the new MARC8 api, honestly.

But pull requests are always welcome!  Also feel free to check out
ruby-marc to see if it accomodates your desired usage already or not,
and let us know, even without a pull request!

If you (or anyone) are interested in checking out the MARC8 support
added to ruby-marc, it's currently in a branch not yet merged in or
released, but probably will be soon.

https://github.com/ruby-marc/ruby-marc/tree/marc8
https://github.com/ruby-marc/ruby-marc/pull/23



--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
pra...@wisc.edu
5-5415

[CODE4LIB] Developer House Call

[Hostetler,Shelley]

OCLC is seeking nominations for participants in a new, intensive multi-day 
event that brings coders together to put OCLC web services to work solving 
practical library problems for colleagues and users.

Sponsored by the OCLC Developer Network, Developer House 
gathers a small group of library coders together, with support from OCLC 
technical staff, for five days of innovative development using OCLC Web 
services.  The event, which runs from February 3rd - 7th in Dublin, Ohio, 
promises to immerse participants in high-intensity effort in a relaxed 
environment where we can get down to the business of meeting library needs 
through code...and having a lot of fun while we do it.

Developer House is envisioned as an event longer than a 
hackathon, where we can carve out time and space away from competing priorities 
and really sink our teeth into something together with colleagues. The group 
will begin its work in the Developer House living room, where they'll decide 
which ideas to tackle, and then work alongside OCLC technical experts, who will 
also provide hands on support tailored to the group's interests.

The only pre-defined outcome for Developer House is time devoted to solving 
problems for libraries and sharpening coding skills. Solutions can be anything 
from applications to tutorials to code libraries-anything that supports 
libraries with code and uses OCLC Web services is fair game - and will be 
shared with the Developer Network community.

Whether you know someone awesome or want a seat on the sofa yourself, the OCLC 
Developer Network is now accepting nominations through Dec 13, 2013. 
Self-nominations are encouraged. You don't have to be an expert coder to 
participate -- we're looking for creative thinkers and effective problem 
solvers with a mix of skills to make a cohesive group. Some demonstrated 
familiarity with APIs and OCLC Web services will be considered beneficial.  
OCLC will provide for lodging and meals, with an additional travel stipend of 
US$ 250 for each attendee.
Nominate someone today!

Shelley Hostetler
Community Manager, WorldShare Platform
OCLC | 6565 Kilgour Place, Dublin, Ohio 43017
Phone: 847 701 8932
Email: 
hoste...@oclc.org
Skype: shelley_hostetler
http://www.oclc.org/developer

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Jonathan Rochkind]

On 11/20/13 12:51 PM, Scott Prater wrote:

I think the issue comes down to a distinction between a stream and a
record.  Ideally, the ruby-marc library would keep pointers to which
record it is in, where the record begins, and where the record ends in
the stream.  If a valid header and end-of-record delimiter are in place,
then the library should be able to reject the record if it contains
garbage in between those two points, without compromising the integrity
of the entire stream.


I understand what you're saying, and why it's attractive. I am not sure 
if ruby-marc can do that right now. I am not personally interested in 
adding that at this particular time -- I just spent a couple days adding 
Marc8 support in the first place, and that's enough for me for now.  I 
was just soliciting some feedback on a point I wasn't sure about with 
the new MARC8 api, honestly.


But pull requests are always welcome!  Also feel free to check out 
ruby-marc to see if it accomodates your desired usage already or not, 
and let us know, even without a pull request!


If you (or anyone) are interested in checking out the MARC8 support 
added to ruby-marc, it's currently in a branch not yet merged in or 
released, but probably will be soon.


https://github.com/ruby-marc/ruby-marc/tree/marc8
https://github.com/ruby-marc/ruby-marc/pull/23

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Robert Haschart]

When I first started working on marc4j, its behavior was to behave as 
suggested here, ie. expect the records to be correctly formed in almost 
every respect, and to throw an exception when an error was encountered, 
it was done in a way that didn't even allow the processing to continue 
with the next record, since the state of the Reader when the exception 
was detected was inconsistent.


The approach that I took in creating the MarcPermissiveStreamReader was 
to move as far as possible towards the other approach being suggested 
here.  ie, flag the error, fix it as best that it can, and allow the 
program to proceed on.  To this end, Marc4j has a ErrorHandler class 
that tracks all of the errors it encounters as it is processing a 
record.   The ErrorHandler is used by the MarcPermissiveStreamReader in 
general as well as by the Marc8 to UTF-8 translation code to note what 
errors were encountered, how severe they are, and a description of the 
corrective action that was taken.


In our implementation at UVa these error messages are included in the 
records that are built and sent to the solr index, so that they can be 
later reviewed and (perhaps) eventually fixed.   I think at present our 
index of 6.3M records has close to 600K records containing errors of one 
sort or another.


-Bob Haschart

On 11/20/2013 10:26 AM, Jonathan Rochkind wrote:
I am not sure how you ran into this problem on Monday with ruby-marc, 
since ruby-marc doesn't currently handle Marc8 conversion to UTF-8 at 
all -- how could you have run into a problem with Marc8 to UTF8 
conversion?  But that is what I am adding.


But yeah, using a preprocessor is certainly one option, that will not 
be taken away from people. Although hopefully adding Marc8->UTF8 
conversion to ruby-marc might remove the need for a preprocessor in 
many cases.


So again, we have a bit of a paradox, that I have in my own head too. 
Scot suggests that "In either case, what we DON'T want is to halt the 
processing altogether."  And yet, still, that the default behavior 
should be raising an exception -- that, is halting processing 
altogether, right?


So hardly anyone hardly ever is going to want the default behavior, 
but everyone thinks it should be default anyway, to force people to 
realize what they're doing? I am not entirely objecting to that -- 
it's why I brought it up here, but it does seem odd, doesn't it?  To 
say something should be default that hardly anyone hardly ever will want?



On 11/20/13 10:10 AM, Scott Prater wrote:

We run into this problem fairly regularly, and in fact, ran into it on
Monday with ruby-marc.

The way we've traditionally handled it is to put our marc stream through
a cleanup preprocessor before passing it off to a marc parser (ruby marc
or marc4j).

The preprocessor can do one of two things:

   1)  Skip the bad record in the marc stream and move on; or
   2)  Substitute the bad characters with some default character, and
write it out.

In both cases we log the error as a warning, and include a byte offset
where the bad character occurs, and the record ID, if possible.  This
allows us to go back and fix the errors in a stream in a batch;
generally, the bad encoding errors fall into four or five common errors
(cutting and pasting data from Windows is a typical cause).

In either case, what we DON'T want is to halt the processing altogether.
  Generally, we're dealing with thousands, sometimes millions, of MARC
records in a stream;  it's very frustrating to get halfway through the
stream, then have the parser throw an exception and halt.  Halting the
processing should be the strategy of last resort, to be called only when
the stream has become so corrupted you can't go on to the next record.

I'd want the default to be option 1.  Let the user determine what
changes need to be made to the data;  the parser's job is to parse, not
infer and create.  Overwriting data could also lead to the misperception
that everything is okay, when it really isn't.

-- Scott

On 11/20/2013 08:32 AM, Jon Stroop wrote:

Coming from nowhere on this...is there a place where it would be
convenient to flag which behavior the user (of the library) wants? I
think you're correct that most of the time you'd just want to blow
through it (or replace it), but for the situation where this isn't the
case, I think the Right Thing to do is raise the exception. I don't
think you would want to bury it in some assumption made internal to the
library unless that assumption can be turned off.

-Jon


On 11/19/2013 07:51 PM, Jonathan Rochkind wrote:

ruby-marc users, a question.

I am working on some Marc8 to UTF-8 conversion for ruby-marc.

Sometimes, what appears to be an illegal byte will appear in the Marc8
input, and it can not be converted to UTF8.

The software will support two alternatives when this happens: 1)
Raising an exception. 2) Replacing the illegal byte with a replacement
char and/or omitting it.

I feel like most of the time, users are going to 

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Scott Prater]

On 11/20/2013 11:18 AM, Jonathan Rochkind wrote:

On 11/20/13 11:40 AM, Scott Prater wrote:



I would suggest one or the other -- the default of leaving bad bytes in
your ruby strings is asking for trouble, and you probably don't want to
do it, but was made the default for backwards compat reasons with older
versions of ruby-marc. (See why I am reluctant to add another default
that we don't think hardly anyone would actually want? :) )


Thanks for your usage suggestions and work on this, Jonathan.  I work 
mostly with marc4j, not ruby-marc, so I'm pretty unfamiliar with the 
capabilities of the gem.  My comments are more oriented towards general 
error handling when processing MARC streams.


I think the issue comes down to a distinction between a stream and a 
record.  Ideally, the ruby-marc library would keep pointers to which 
record it is in, where the record begins, and where the record ends in 
the stream.  If a valid header and end-of-record delimiter are in place, 
then the library should be able to reject the record if it contains 
garbage in between those two points, without compromising the integrity 
of the entire stream.  So my final output would not contain bad data; 
it would simply be missing some records, records that contained bad data.


Here's some (partial) pseudo ruby code of how I'd like to handle it:

count=0
reader = MARC::Reader.new('marc8.dat')
writer = MARC::XMLWriter.new('marc-utf8.xml')
for record in reader
  count+=1
  begin
 utf8rec = record.convert_to_utf()
 writer.write(utf8rec)
  rescue => exception
 log exception, "Skipping record #{count}"
  end
  ... now read the next record...
end

This example doesn't capture the exception if the next record can't be 
retrieved, because the stream is corrupt, but that would be the other 
addition I'd make.  The larger point is that reading a MARC stream 
should be handled as reading a sequence of MARC records encoded in that 
stream -- one bad record does not automatically invalidate the entire 
stream; it only invalidates it if the next record can't be found.


-- Scott

--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
pra...@wisc.edu
5-5415

[CODE4LIB] Code4Lib Conference Registration

[John Blair]

Per the website (bolding mine):

"Finally, the hotel has the capacity to host all of the attendees, and we've 
negotiated a rate of $159/night that includes wireless access in the hotel 
rooms. Hotel reservations will be able to be made after you register using the 
information provided in your registration confirmation. We will be publishing 
more details as they become available."

Where? When? How? Or does registration fall under "…more details…?"


-John Blair

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Jonathan Rochkind]

On 11/20/13 11:40 AM, Scott Prater wrote:

Not sure what the details of our issue was on Monday -- but we do have
records that are supposedly encoded in UTF-8, but nonetheless contain
invalid characters.


Oh, and I'd clarify, if you haven't figured it out already, if those are 
ISO 2709 binary records, you can ask the reader to do different things 
there in that case (already avail in current ruby-marc release):


# raise:
MARC::Reader("something.marc", :validate_encoding => true)

# replace with unicode replacement char:
MARC::Reader("something.marc", :invalid => :replace)

This is already available in present ruby-marc release.

I would suggest one or the other -- the default of leaving bad bytes in 
your ruby strings is asking for trouble, and you probably don't want to 
do it, but was made the default for backwards compat reasons with older 
versions of ruby-marc. (See why I am reluctant to add another default 
that we don't think hardly anyone would actually want? :) )


Oh, and you may also want to explicitly specify the expected encoding to 
avoid confusing:


MARC::Reader("something.marc", :external_encoding => "UTF-8", 
:validate_encoding => true)


(It will also work with any other encoding recognized by ruby, for those 
with legacy, possibly international, data).


This stuff is confusing to explain, there are so many permutations and 
combinations of circumstances involved.  But I'll try to improve the 
ruby-marc docs on this stuff, as part of adding the yet more options for 
MARC8 handling.

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Jonathan Rochkind]

Yeah, the default in ruby-marc for encodings that _aren't_ MARC8 are to 
ignore bad bytes entirely -- leave them in the MARC::Record as bad 
bytes. This is likely end up raising an exception later when you try to 
DO something with those Strings, but was left this way for backwards 
compatiblity reasons.


You can optionally tell ruby-marc to raise or 'fix' these bad bytes 
instead, but the default is to leave them alone.


However, that's not really possible for MARC8->UTF8 conversion. Since a 
conversion is going on, bad bytes can't be 'left alone', something has 
to be done with them -- raise or replace.


My question here is solely about MARC8->UTF8 conversion, I am not 
changing anything else about the ruby-marc API at this time.


"I think raising an exception is fine, as long as we can still continue
 to walk the records with the reader."  Honestly, I'm not sure if 
that's true, I'm not sure how easy it's going to be to continue 
iterating through the records after an exception, I think the exception 
gets raised in a place that leaves the reader inconsistent. If so, there 
may not be any easy way to fix that. Bah. Scott, you want to beta test 
this new version of ruby-marc?


At any rate, pull requests always welcome once it gets released, having 
some MARC8->UTF8 conversion seems an improvement even if the details 
aren't right. We've always placed a premium on backwards compat in 
ruby-marc though, so I wanted to try and avoid making api/default 
choices we'd later regret but not want to change for backwards compat.



On 11/20/13 11:40 AM, Scott Prater wrote:

Not sure what the details of our issue was on Monday -- but we do have
records that are supposedly encoded in UTF-8, but nonetheless contain
invalid characters.

I think raising an exception is fine, as long as we can still continue
to walk the records with the reader.  The right thing for application
code to do then would be to catch the exception, log it, and continue to
the next record.  The more information in the exception, the better.

-- Scott


I am not sure how you ran into this problem on Monday with ruby-marc,
since ruby-marc doesn't currently handle Marc8 conversion to UTF-8 at
all -- how could you have run into a problem with Marc8 to UTF8
conversion?  But that is what I am adding.

But yeah, using a preprocessor is certainly one option, that will not be
taken away from people. Although hopefully adding Marc8->UTF8 conversion
to ruby-marc might remove the need for a preprocessor in many cases.

So again, we have a bit of a paradox, that I have in my own head too.
Scot suggests that "In either case, what we DON'T want is to halt the
processing altogether."  And yet, still, that the default behavior
should be raising an exception -- that, is halting processing
altogether, right?

So hardly anyone hardly ever is going to want the default behavior, but
everyone thinks it should be default anyway, to force people to realize
what they're doing? I am not entirely objecting to that -- it's why I
brought it up here, but it does seem odd, doesn't it?  To say something
should be default that hardly anyone hardly ever will want?


On 11/20/13 10:10 AM, Scott Prater wrote:

We run into this problem fairly regularly, and in fact, ran into it on
Monday with ruby-marc.

The way we've traditionally handled it is to put our marc stream through
a cleanup preprocessor before passing it off to a marc parser (ruby marc
or marc4j).

The preprocessor can do one of two things:

   1)  Skip the bad record in the marc stream and move on; or
   2)  Substitute the bad characters with some default character, and
write it out.

In both cases we log the error as a warning, and include a byte offset
where the bad character occurs, and the record ID, if possible.  This
allows us to go back and fix the errors in a stream in a batch;
generally, the bad encoding errors fall into four or five common errors
(cutting and pasting data from Windows is a typical cause).

In either case, what we DON'T want is to halt the processing altogether.
  Generally, we're dealing with thousands, sometimes millions, of MARC
records in a stream;  it's very frustrating to get halfway through the
stream, then have the parser throw an exception and halt.  Halting the
processing should be the strategy of last resort, to be called only when
the stream has become so corrupted you can't go on to the next record.

I'd want the default to be option 1.  Let the user determine what
changes need to be made to the data;  the parser's job is to parse, not
infer and create.  Overwriting data could also lead to the misperception
that everything is okay, when it really isn't.

-- Scott

On 11/20/2013 08:32 AM, Jon Stroop wrote:

Coming from nowhere on this...is there a place where it would be
convenient to flag which behavior the user (of the library) wants? I
think you're correct that most of the time you'd just want to blow
through it (or replace it), but for the situation where this isn't the
ca

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Scott Prater]

Not sure what the details of our issue was on Monday -- but we do have 
records that are supposedly encoded in UTF-8, but nonetheless contain 
invalid characters.


I think raising an exception is fine, as long as we can still continue 
to walk the records with the reader.  The right thing for application 
code to do then would be to catch the exception, log it, and continue to 
the next record.  The more information in the exception, the better.


-- Scott


I am not sure how you ran into this problem on Monday with ruby-marc,
since ruby-marc doesn't currently handle Marc8 conversion to UTF-8 at
all -- how could you have run into a problem with Marc8 to UTF8
conversion?  But that is what I am adding.

But yeah, using a preprocessor is certainly one option, that will not be
taken away from people. Although hopefully adding Marc8->UTF8 conversion
to ruby-marc might remove the need for a preprocessor in many cases.

So again, we have a bit of a paradox, that I have in my own head too.
Scot suggests that "In either case, what we DON'T want is to halt the
processing altogether."  And yet, still, that the default behavior
should be raising an exception -- that, is halting processing
altogether, right?

So hardly anyone hardly ever is going to want the default behavior, but
everyone thinks it should be default anyway, to force people to realize
what they're doing? I am not entirely objecting to that -- it's why I
brought it up here, but it does seem odd, doesn't it?  To say something
should be default that hardly anyone hardly ever will want?


On 11/20/13 10:10 AM, Scott Prater wrote:

We run into this problem fairly regularly, and in fact, ran into it on
Monday with ruby-marc.

The way we've traditionally handled it is to put our marc stream through
a cleanup preprocessor before passing it off to a marc parser (ruby marc
or marc4j).

The preprocessor can do one of two things:

   1)  Skip the bad record in the marc stream and move on; or
   2)  Substitute the bad characters with some default character, and
write it out.

In both cases we log the error as a warning, and include a byte offset
where the bad character occurs, and the record ID, if possible.  This
allows us to go back and fix the errors in a stream in a batch;
generally, the bad encoding errors fall into four or five common errors
(cutting and pasting data from Windows is a typical cause).

In either case, what we DON'T want is to halt the processing altogether.
  Generally, we're dealing with thousands, sometimes millions, of MARC
records in a stream;  it's very frustrating to get halfway through the
stream, then have the parser throw an exception and halt.  Halting the
processing should be the strategy of last resort, to be called only when
the stream has become so corrupted you can't go on to the next record.

I'd want the default to be option 1.  Let the user determine what
changes need to be made to the data;  the parser's job is to parse, not
infer and create.  Overwriting data could also lead to the misperception
that everything is okay, when it really isn't.

-- Scott

On 11/20/2013 08:32 AM, Jon Stroop wrote:

Coming from nowhere on this...is there a place where it would be
convenient to flag which behavior the user (of the library) wants? I
think you're correct that most of the time you'd just want to blow
through it (or replace it), but for the situation where this isn't the
case, I think the Right Thing to do is raise the exception. I don't
think you would want to bury it in some assumption made internal to the
library unless that assumption can be turned off.

-Jon


On 11/19/2013 07:51 PM, Jonathan Rochkind wrote:

ruby-marc users, a question.

I am working on some Marc8 to UTF-8 conversion for ruby-marc.

Sometimes, what appears to be an illegal byte will appear in the Marc8
input, and it can not be converted to UTF8.

The software will support two alternatives when this happens: 1)
Raising an exception. 2) Replacing the illegal byte with a replacement
char and/or omitting it.

I feel like most of the time, users are going to want #2.  I know
that's what I'm going to want nearly all the time.

Yet, still, I am feeling uncertain whether that should be the default.
Which should be the default behavior, #1 or #2?  If most people most
of the time are going to want #2 (is this true?), then should that be
the default behavior?   Or should #1 still be the default behavior,
because by default bad input should raise, not be silently recovered
from, even though most people most of the time won't want that, heh.

Jonathan






--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
pra...@wisc.edu
5-5415

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Jonathan Rochkind]

I am not sure how you ran into this problem on Monday with ruby-marc, 
since ruby-marc doesn't currently handle Marc8 conversion to UTF-8 at 
all -- how could you have run into a problem with Marc8 to UTF8 
conversion?  But that is what I am adding.


But yeah, using a preprocessor is certainly one option, that will not be 
taken away from people. Although hopefully adding Marc8->UTF8 conversion 
to ruby-marc might remove the need for a preprocessor in many cases.


So again, we have a bit of a paradox, that I have in my own head too. 
Scot suggests that "In either case, what we DON'T want is to halt the 
processing altogether."  And yet, still, that the default behavior 
should be raising an exception -- that, is halting processing 
altogether, right?


So hardly anyone hardly ever is going to want the default behavior, but 
everyone thinks it should be default anyway, to force people to realize 
what they're doing? I am not entirely objecting to that -- it's why I 
brought it up here, but it does seem odd, doesn't it?  To say something 
should be default that hardly anyone hardly ever will want?



On 11/20/13 10:10 AM, Scott Prater wrote:

We run into this problem fairly regularly, and in fact, ran into it on
Monday with ruby-marc.

The way we've traditionally handled it is to put our marc stream through
a cleanup preprocessor before passing it off to a marc parser (ruby marc
or marc4j).

The preprocessor can do one of two things:

   1)  Skip the bad record in the marc stream and move on; or
   2)  Substitute the bad characters with some default character, and
write it out.

In both cases we log the error as a warning, and include a byte offset
where the bad character occurs, and the record ID, if possible.  This
allows us to go back and fix the errors in a stream in a batch;
generally, the bad encoding errors fall into four or five common errors
(cutting and pasting data from Windows is a typical cause).

In either case, what we DON'T want is to halt the processing altogether.
  Generally, we're dealing with thousands, sometimes millions, of MARC
records in a stream;  it's very frustrating to get halfway through the
stream, then have the parser throw an exception and halt.  Halting the
processing should be the strategy of last resort, to be called only when
the stream has become so corrupted you can't go on to the next record.

I'd want the default to be option 1.  Let the user determine what
changes need to be made to the data;  the parser's job is to parse, not
infer and create.  Overwriting data could also lead to the misperception
that everything is okay, when it really isn't.

-- Scott

On 11/20/2013 08:32 AM, Jon Stroop wrote:

Coming from nowhere on this...is there a place where it would be
convenient to flag which behavior the user (of the library) wants? I
think you're correct that most of the time you'd just want to blow
through it (or replace it), but for the situation where this isn't the
case, I think the Right Thing to do is raise the exception. I don't
think you would want to bury it in some assumption made internal to the
library unless that assumption can be turned off.

-Jon


On 11/19/2013 07:51 PM, Jonathan Rochkind wrote:

ruby-marc users, a question.

I am working on some Marc8 to UTF-8 conversion for ruby-marc.

Sometimes, what appears to be an illegal byte will appear in the Marc8
input, and it can not be converted to UTF8.

The software will support two alternatives when this happens: 1)
Raising an exception. 2) Replacing the illegal byte with a replacement
char and/or omitting it.

I feel like most of the time, users are going to want #2.  I know
that's what I'm going to want nearly all the time.

Yet, still, I am feeling uncertain whether that should be the default.
Which should be the default behavior, #1 or #2?  If most people most
of the time are going to want #2 (is this true?), then should that be
the default behavior?   Or should #1 still be the default behavior,
because by default bad input should raise, not be silently recovered
from, even though most people most of the time won't want that, heh.

Jonathan

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Scott Prater]

We run into this problem fairly regularly, and in fact, ran into it on 
Monday with ruby-marc.


The way we've traditionally handled it is to put our marc stream through 
a cleanup preprocessor before passing it off to a marc parser (ruby marc 
or marc4j).


The preprocessor can do one of two things:

  1)  Skip the bad record in the marc stream and move on; or
  2)  Substitute the bad characters with some default character, and 
write it out.


In both cases we log the error as a warning, and include a byte offset 
where the bad character occurs, and the record ID, if possible.  This 
allows us to go back and fix the errors in a stream in a batch; 
generally, the bad encoding errors fall into four or five common errors 
(cutting and pasting data from Windows is a typical cause).


In either case, what we DON'T want is to halt the processing altogether. 
 Generally, we're dealing with thousands, sometimes millions, of MARC 
records in a stream;  it's very frustrating to get halfway through the 
stream, then have the parser throw an exception and halt.  Halting the 
processing should be the strategy of last resort, to be called only when 
the stream has become so corrupted you can't go on to the next record.


I'd want the default to be option 1.  Let the user determine what 
changes need to be made to the data;  the parser's job is to parse, not 
infer and create.  Overwriting data could also lead to the misperception 
that everything is okay, when it really isn't.


-- Scott

On 11/20/2013 08:32 AM, Jon Stroop wrote:

Coming from nowhere on this...is there a place where it would be
convenient to flag which behavior the user (of the library) wants? I
think you're correct that most of the time you'd just want to blow
through it (or replace it), but for the situation where this isn't the
case, I think the Right Thing to do is raise the exception. I don't
think you would want to bury it in some assumption made internal to the
library unless that assumption can be turned off.

-Jon


On 11/19/2013 07:51 PM, Jonathan Rochkind wrote:

ruby-marc users, a question.

I am working on some Marc8 to UTF-8 conversion for ruby-marc.

Sometimes, what appears to be an illegal byte will appear in the Marc8
input, and it can not be converted to UTF8.

The software will support two alternatives when this happens: 1)
Raising an exception. 2) Replacing the illegal byte with a replacement
char and/or omitting it.

I feel like most of the time, users are going to want #2.  I know
that's what I'm going to want nearly all the time.

Yet, still, I am feeling uncertain whether that should be the default.
Which should be the default behavior, #1 or #2?  If most people most
of the time are going to want #2 (is this true?), then should that be
the default behavior?   Or should #1 still be the default behavior,
because by default bad input should raise, not be silently recovered
from, even though most people most of the time won't want that, heh.

Jonathan



--
Scott Prater
Shared Development Group
General Library System
University of Wisconsin - Madison
pra...@wisc.edu
5-5415

[CODE4LIB] Library Open Source Software Survey - Research Project - Chance to Win a $35 Amazon Gift Card

[Namjoo Choi]

Dear library OSS developer,
 
(Please excuse the duplicate email message if you have already taken the 
survey.)

I am writing to invite you to participate in a research study that aims to 
examine the characteristics (i.e., demographics, educational background, and 
current and past job experiences) and motivations of developers contributing to 
library Open Source Software (OSS) projects.
 
The survey should take about 20 minutes to complete. Upon completion of the 
survey, you will be asked to provide your email address if you wish to enter a 
drawing for one of ten $35.00 Amazon.com gift certificates. Since we expect 
about 150 people to complete the survey, the chances of winning a gift 
certificate are about 1 in 15. Your email address will not be connected to any 
of your other responses, and it will not be used for any other purpose. This is 
an academic research study and has no relation to either Code4Lib. Your 
participation is completely voluntary, and you may quit at any time during the 
survey.
 
Please share your ideas and experiences with me through the online survey at:

https://uky.az1.qualtrics.com/SE/?SID=SV_71lj7tBz1c1czaZ

There are no known risks to participation in this survey. Your response to the 
survey is anonymous, which means no names will appear or be used on research 
documents or be used in presentation or publications. I will not know that any 
information you provided came from you, nor will I know whether you even 
participated in the study. If you have questions about the study, please feel 
free to ask; my contact information is given below. If you have complaints, 
suggestions, or questions about your rights as a research volunteer, contact 
the staff in the University of Kentucky Office of Research Integrity at 
1-859-257-9428 or toll-free at 1-866-400-9428.
 
Thank you in advance for your participation in the survey!
 
Sincerely,
 
Namjoo Choi
Assistant Professor
School of Library and Information Science/College of Communication and 
Information, University of Kentucky
Phone:  859-257-4113
E-mail: namjoo.c...@uky.edu

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Jonathan Rochkind]

Yes, it will be configurable -- "the assumption can be turned off."

The question is which the default should be.

Any opinions, especially from users of ruby-marc, or other MARC parsing 
libraries?


On 11/20/13 9:32 AM, Jon Stroop wrote:

Coming from nowhere on this...is there a place where it would be
convenient to flag which behavior the user (of the library) wants? I
think you're correct that most of the time you'd just want to blow
through it (or replace it), but for the situation where this isn't the
case, I think the Right Thing to do is raise the exception. I don't
think you would want to bury it in some assumption made internal to the
library unless that assumption can be turned off.

-Jon


On 11/19/2013 07:51 PM, Jonathan Rochkind wrote:

ruby-marc users, a question.

I am working on some Marc8 to UTF-8 conversion for ruby-marc.

Sometimes, what appears to be an illegal byte will appear in the Marc8
input, and it can not be converted to UTF8.

The software will support two alternatives when this happens: 1)
Raising an exception. 2) Replacing the illegal byte with a replacement
char and/or omitting it.

I feel like most of the time, users are going to want #2.  I know
that's what I'm going to want nearly all the time.

Yet, still, I am feeling uncertain whether that should be the default.
Which should be the default behavior, #1 or #2?  If most people most
of the time are going to want #2 (is this true?), then should that be
the default behavior?   Or should #1 still be the default behavior,
because by default bad input should raise, not be silently recovered
from, even though most people most of the time won't want that, heh.

Jonathan

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Timothy Prettyman]

Could you possibly replace the bad bytes with their NCR values, and raise a
warning?

-Tim


On Wed, Nov 20, 2013 at 9:32 AM, Jon Stroop  wrote:

> Coming from nowhere on this...is there a place where it would be
> convenient to flag which behavior the user (of the library) wants? I think
> you're correct that most of the time you'd just want to blow through it (or
> replace it), but for the situation where this isn't the case, I think the
> Right Thing to do is raise the exception. I don't think you would want to
> bury it in some assumption made internal to the library unless that
> assumption can be turned off.
>
> -Jon
>
>
>
> On 11/19/2013 07:51 PM, Jonathan Rochkind wrote:
>
>> ruby-marc users, a question.
>>
>> I am working on some Marc8 to UTF-8 conversion for ruby-marc.
>>
>> Sometimes, what appears to be an illegal byte will appear in the Marc8
>> input, and it can not be converted to UTF8.
>>
>> The software will support two alternatives when this happens: 1) Raising
>> an exception. 2) Replacing the illegal byte with a replacement char and/or
>> omitting it.
>>
>> I feel like most of the time, users are going to want #2.  I know that's
>> what I'm going to want nearly all the time.
>>
>> Yet, still, I am feeling uncertain whether that should be the default.
>> Which should be the default behavior, #1 or #2?  If most people most of the
>> time are going to want #2 (is this true?), then should that be the default
>> behavior?   Or should #1 still be the default behavior, because by default
>> bad input should raise, not be silently recovered from, even though most
>> people most of the time won't want that, heh.
>>
>> Jonathan
>>
>

Re: [CODE4LIB] ruby-marc api design feedback wanted

[Jon Stroop]

Coming from nowhere on this...is there a place where it would be 
convenient to flag which behavior the user (of the library) wants? I 
think you're correct that most of the time you'd just want to blow 
through it (or replace it), but for the situation where this isn't the 
case, I think the Right Thing to do is raise the exception. I don't 
think you would want to bury it in some assumption made internal to the 
library unless that assumption can be turned off.


-Jon


On 11/19/2013 07:51 PM, Jonathan Rochkind wrote:

ruby-marc users, a question.

I am working on some Marc8 to UTF-8 conversion for ruby-marc.

Sometimes, what appears to be an illegal byte will appear in the Marc8 
input, and it can not be converted to UTF8.


The software will support two alternatives when this happens: 1) 
Raising an exception. 2) Replacing the illegal byte with a replacement 
char and/or omitting it.


I feel like most of the time, users are going to want #2.  I know 
that's what I'm going to want nearly all the time.


Yet, still, I am feeling uncertain whether that should be the default. 
Which should be the default behavior, #1 or #2?  If most people most 
of the time are going to want #2 (is this true?), then should that be 
the default behavior?   Or should #1 still be the default behavior, 
because by default bad input should raise, not be silently recovered 
from, even though most people most of the time won't want that, heh.


Jonathan

[CODE4LIB] Job: Digital Resources & Web Development Librarian/Specialist at Milligan College

[jobs]

Digital Resources & Web Development Librarian/Specialist
Milligan College
Elizabethton

Milliganeastern Tennessee invites applications for a full time Digital
Resources & Web Development Librarian/Specialist to join
ourengaged, user-centered, and forward-thinking staff.
Responsibilities include maintaining and developing the Library website and
relevant web applications, assuring reliable access to all Library digital
resources, assisting in the development and management of the Milligan College
digital repository, assisting with data collection, and participating in the
provision of research assistance to Library users. The successful candidate
will have demonstrated experience in web design with strong usability and
aesthetic sensibilities, modern front-end web development, administrative
experience with discovery and ILS platforms, and a thorough knowledge of
Microsoft Excel. Additionally, the candidate should be familiar with digital
repository platforms, digitization, electronic document preservation, and
metadata schemes. Candidate must demonstrate strong written and verbal
communication skills, be self-motivated, detail-oriented, inquisitive,
adaptable, and capable of working collaboratively. The successful candidate
must demonstrate a strong Christian faith, commitment to the College Mission,
and a lifestyle consistent with the College's goals. Milligan is an EEO
employer and offers competitive salary and benefits.Visit
[www.milligan.edu](http://www.milligan.edu) for information about the College
and its mission statement.Minimum Bachelor's Degree in Web
Development, Computer Science, Library and Information Science, or related for
Specialist designation; MLS/MLIS or equivalent from an ALA-accredited
institution for Librarian designation. Send a letter of application, resume,
response to the mission statement, and supporting materials to
[librarysea...@milligan.edu](mailto:librarysea...@milligan.edu). Review of
materials will begin at once and continue until position is
filled.Desired start date is June 1, 2014.



Brought to you by code4lib jobs: http://jobs.code4lib.org/job/10769/

[CODE4LIB] Job: Web/Database Development Librarian at University of North Carolina at Chapel Hill

[jobs]

Web/Database Development Librarian
University of North Carolina at Chapel Hill
Chapel Hill

The University of North Carolina at Chapel Hill Health
Sciences Library (HSL) seeks an enthusiastic, innovative, collaborative, and
service-oriented individual to join the Web Development Group as the North
Carolina AHEC Digital Library (ADL) Web/Database Development Librarian. The
ADL Web/Database Development Librarian is the primary staff member responsible
for design, development, maintenance, testing, and technical management of the
ADL database, web applications, user interface, and administrative tools and
utilities.

  
  
A complete vacancy announcement, with application instructions, can be found
online:

[http://library.unc.edu/jobs/webdatabase-development-librarian-health-
sciences-library/](http://library.unc.edu/jobs/webdatabase-development-
librarian-health-sciences-library/)



Brought to you by code4lib jobs: http://jobs.code4lib.org/job/10776/

[CODE4LIB] Job: Digital Collections Librarian at Bryn Mawr College

[jobs]

Digital Collections Librarian
Bryn Mawr College
Bryn Mawr

The Digital Collections Librarian is responsible for coordinating the creation
and maintenance of digital collections and databases that draw upon the
holdings of the Special Collections Department, and for working with faculty,
students, and staff in the development of digital collections, including the
preservation of born-digital records which document the history of the
College. The Digital Collections Librarian is based in the Special Collections
Department, and is responsible for managing the collections of historical
photographs and for participating in patron services and other regular
business of the department. The Digital Collections Specialist will also work
closely with colleagues throughout the Information Services Department, and
with colleagues within the TriColleges (Bryn Mawr, Haverford, and Swarthmore
Colleges).

  
RESPONSIBILITIES INCLUDE:

In cooperation with other members of the Special Collections, Visual
Resources, and other departments within Information Services, coordinate the
development, implementation and maintenance of digital projects drawing upon
the College's Special Collections holdings, including The Albert M. Greenfield
Digital Center for the History of Women's Education.

Manage the databases and websites for Special Collections, including EmbARK
Collections Manager, CONTENTdm, Archivists' Toolkit/ArchivesSpace, and Omeka,
and coordinate the development and implementation of standards for data and
images across the digital collections.

Participate in the planning and implementation of digital projects at Bryn
Mawr and within the Tri-College Libraries, including training faculty, staff
and students in the use of digital collection technologies and processes, and
partnering with faculty in using digital resources in their research and
teaching activities.

  * Participate in the development of online exhibitions, finding aids and 
other digital publications.
  * Work with both computing and library staff at Bryn Mawr and throughout the 
TriColleges in support of digital projects.
  * In collaboration with the College Archivist and other administrative staff, 
develop plan for the preservation of born-digital historical records of the 
College.
  * Catalog and manage the historical photograph and ephemera collections, 
including providing reference services for students, faculty, staff, and 
outside researchers interested in using these collections.
  * Share responsibility with other Special Collections staff for monitoring 
the public reading room, and assisting researchers using the collections.
  * Participate in the hiring, training, and supervising of student workers.
  
EDUCATION AND ABILITIES:

  
REQUIRED: Master's degree from a Library/Information Science program or Museum
Studies program, or Master's degree in a relevant subject area with extensive
experience working with cultural collections and experience working with
collection management software, databases, and digital
collections. Knowledge of metadata and encoding standards,
strong written and oral communication skills, and the ability to work
collaboratively with a wide range of people are essential.



Brought to you by code4lib jobs: http://jobs.code4lib.org/job/10765/

[CODE4LIB] Job: PHP Web Developer (Free Library of Philadelphia, Pennsylvania) at Free Library of Philadelphia

[jobs]

PHP Web Developer (Free Library of Philadelphia, Pennsylvania)
Free Library of Philadelphia
Philadelphia

The Free Library of Philadelphia is seeking a creative, flexible and
enthusiastic temporary web developer for the period of 6 - 9 months to join
our team and work to upgrade and build enhanced functionality for our existing
web application. Required Education and Experience Bachelor's degree with
major coursework in information technology, information science, or a related
area Two years of experience performing web application programming to
develop, design, program, test and document web applications in the
construction and maintenance of web features and internet sites Required
Skills and Abilities Proficient skill and knowledge of PHP, JavaScript,
jQuery, AJAX, CSS, XML Proficient skill with MySQL and MSSQL Experience with
web services using SOAP, REST, and JSON Demonstrate experience with Apache
Solr Demonstrate knowledge of the LAMP stack Demonstrate experience with
Responsive Web Design Experience with QA and Beta testing Strong
organizational and interpersonal skills, demonstrating the ability to work
collaboratively in a small team-based environment with other developers,
graphic designers and network administrators Ability to write write clear
documentation Preferred Experience with the Zend Framework 2 Experience
building and optimizing Solr indexes Experience working and contributing to
Open Source applications Familiarity with digital library standards such as
MARC Experience with load testing Experience working in a library environment
is a plus Experience with ColdFusion is a plus Experience with a WAMP stack
environment is a plus To Apply: Send your cover letter and resume with "PHP
Developer" in the subject line to Camille Tomlin at
[toml...@freelibrary.org](mailto:toml...@freelibrary.org) (attachments as PDFs
or Microsoft Word only please). For more information: [http://libwww.freelibra
ry.org/jobs/JobDesc.cfm?type=C&jobID=1758](http://libwww.freelibrary.org/jobs/
JobDesc.cfm?type=C&jobID=1758).



Brought to you by code4lib jobs: http://jobs.code4lib.org/job/10756/

[CODE4LIB] Open Data Specialist position at the Chattanooga Public Library

[Nate Hill]

Don't hesitate to ask me any questions.
#
http://chattlibrary.org/jobs/open-data-specialist-ods

Open Data Specialist (ODS)

The Chattanooga Public Library (CPL) is seeking a qualified candidate for a
newly created Open Data Specialist (ODS) position.  The successful
applicant will join our fantastic digital projects team on The 4th Floor, a
14,000 sq ft public maker/hackerspace in Chattanooga’s city center.  This
is a unique library job that combines the diverse talents of a seasoned
collection development specialist, a web developer, a data scientist, and a
community outreach specialist. The ODS position is a year-long grant funded
position awarded to the CPL as one partner in the Open Chattanooga
collaborative. With demonstrated success, we intend to extend the position
beyond the duration of the grant indefinitely.

The ideal candidate for the ODS position is an open data evangelist and an
expert who can work with representatives from city government as well as
citizen groups like Open Chattanooga to coordinate contributions of data to
a public platform or portal. This portal will be hosted by the library and
accessed alongside our other digital collections. The portal’s exceptional
construction, performance, and maintenance are all the responsibility of
the ODS.  The ODS will coordinate with partners to ensure that all data
added to the portal is useful, useable, and accessible like all of our
other public library collections. While this position does not require the
candidate to be a degreed librarian, it is important that the candidate
demonstrates an understanding of professional collection development
principles, since this government-produced data will be treated as a
library collection.

The first and most important task the ODS faces is the buildout of the
platform itself, as well as the creation of a sustainability plan and
documentation of the open data portal as a library collection.  Currently,
the library has a beta version of a data portal available at
opendata.chattlibrary.org; this was created using DKAN.  The ODS will
either continue work using this platform, or will present a case for the
adoption of another open source platform, such as CKAN.

Chattanooga Public Library considers this data portal a key piece of our
digital infrastructure as we develop more online library services and
migrate some of our traditional library services into a networked
environment.  The ideal candidate will bring innovative and creative
thought and workflows to our already robust digital services team.
 Eventually, the CPL anticipates serving more than just open government
data from this platform.  A candidate with a passion for developing cutting
edge services, skills to build and deliver applications and products, and a
desire to have fun working collaboratively with the rest of us will find
CPL to be a satisfying work environment.

Other qualifications, requirements, and preferences:

   - Undergraduate degree or equivalent experience in CS or related field
   - Demonstrated understanding of data structures and APIs
   - Familiarity with the Drupal CMS and DKAN or with CKAN
   - Familiarity with the LAMP stack; demonstrated PHP development
   experience
   - A strong history of contributions and commitments to open source
   projects
   - Please provide a link to your github account or another online
   portfolio
   - Bonus points for the applicant with UI / UX / design experience

This is a full-time position with benefits.  Sorry, this is not a remote
work opportunity, you will have to work in the library.

The salary for this job is $55,000/year.

Email application, resume, and portfolio to coope...@lib.chattanooga.gov

-- 
Nate Hill
nathanielh...@gmail.com
http://4thfloor.chattlibrary.org/
http://www.natehill.net

[CODE4LIB] Position Announcement: Web/Database Development Librarian (NC)

[Eades, Lynn]

The University of North Carolina at Chapel Hill Health Sciences Library (HSL) 
seeks an enthusiastic, innovative, collaborative, and service-oriented 
individual to join the Web Development Group as the North Carolina AHEC Digital 
Library (ADL) Web/Database Development Librarian. The ADL Web/Database 
Development Librarian is the primary staff member responsible for design, 
development, maintenance, testing, and technical management of the ADL 
database, web applications, user interface, and administrative tools and 
utilities.





A complete vacancy announcement, with application instructions, can be found 
online:

http://library.unc.edu/jobs/webdatabase-development-librarian-health-sciences-library/

__
B. Lynn Eades
Web Development Librarian
Information Technology Services
Health Sciences Library
335 South Columbia Street
CB# 7585
University of North Carolina at Chapel Hill
Chapel Hill, NC  27599-7585

Phone: (919) 966-8012
Email: bea...@med.unc.edu
Website: http://www.hsl.unc.edu
__

Connecting people everywhere with knowledge to improve health

[CODE4LIB] OPF & SCAPE Hackathon, Hadoop-Driven Digital Preservation, 2-4 December, Vienna

[Rebecca McGuinness]

Hadoop Driven Digital Preservation
2-4 December,
Austrian National Library, Vienna

There is just one week left to sign up for our next hackathon: 
https://hadoop-driven-digital-preservation.eventbrite.co.uk.

This hackathon will focus on using Hadoop in two digital preservation scenarios:

Web-Archiving: File Format Identification/Characterisation
A web archive usually contains a wide range of different file types. From a 
curatorial perspective the question is: Do I need to be worried? Is there a 
risk that means I should take adequate measures right now? The first step is to 
reliably identify and characterise the content of a web archive. Linguistic 
analysis can help categorise the “text/plain” content into more precise content 
types. A detailed analysis of “application/pdf” content can help cluster 
properties of the files and identify characteristics that are of special 
interest. Using the Hadoop framework and prepared sample projects for 
processing web archive content, we will be able to perform any kind of 
processing or analysis that we come up with on a large scale using a Hadoop 
Cluster. Together we will discuss what are the requirements to enable this and 
we will find out what still needs to optimised.

Digital Books: Quality Assurance, text mining (OCR Quality)
The digital objects of the Austrian National Library's digital book collection 
consists of the aggregated book object with technical and descriptive meta 
data, and the images, layout and text content for the book pages. Due to the 
massive scale of digitisation in a relatively short time period and the fact 
that the digitised books are from the 18th century and older, there are 
different types of quality issues. Using the Hadoop framework, we provide the 
means to perform any kind of large scale book processing on a book or page 
level. Linguistic analysis and language detection, for example, can help us 
determining the quality of the OCR (Optical Character Recognition), or image 
analysis can help in detecting any technical or content related issues with the 
book page images. 

Take a look at the full agenda here: 
http://wiki.opf-labs.org/display/SP/Agenda+-+Hadoop+Driven+Digital+Preservation.

Highlights of this hackathon include:

* Talks from our guest speaker, Jimmy Lin, University of Maryland 
* Taking part in our competition for the best idea and visualisation
* A chance to gain hands-on experience carrying out identification and 
characterisation experiments
* Practitioners and developers working together to address digital preservation 
challenges
* The opportunity to share experiences and knowledge about implementing Hadoop

Who should attend?

Practitioners (digital librarians and archivists, digital curators, repository 
managers, or anyone responsible for managing digital collections) You will 
learn how Hadoop might fit your organisation, how to write requirements to 
guide development and gain some hands on experience using tools yourself and 
finding out how they work. To get the most out of this training course you will 
ideally have some knowledge or experience of digital preservation.
 
Developers of all experience can participate, from writing your first Hadoop 
jobs, to working on scalable solutions for issues identified in the scenarios.

We hope to see you in Vienna!

Kind Regards,

Rebecca McGuinness
Membership and Communications Manager