Job Posting: Integrated Library Systems Librarian VCU Libraries

2008-06-09 Thread Jimmy Ghaphery

Greetings,

Apologies in advance for duplicate cross-postings.

POSITION: Integrated Library Systems Librarian
REPORTS TO: Head, Library Information Systems

SUMMARY: The VCU Libraries invites applications and nominations for the 
position of Integrated Library Systems Librarian responsible for 
providing exemplary discovery of our collections and increasing 
efficiencies for all aspects of technical and public services 
processing. In addition to being the lead agent for the integrated 
library system (Aleph 500), this position will manage related systems 
for statistics (ARC) and electronic resource management (Verde). The 
position offers maximum opportunity for professional growth and impact 
for a talented and creative individual. The successful candidate will 
join a culturally and academically diverse faculty of the highest caliber.


RESPONSIBILITIES: Manages major enterprise library applications, 
including Aleph 500, ARC, and Verde. Ensures availability of the 
Integrated Library System for two locations (VCU Richmond and VCU Qatar) 
and takes a lead role investigating next generation interfaces. Liaisons 
with the University Computer Center’s Database and Systems 
Administration Team. Works with other units of the library on system 
development and troubleshooting. Plans ongoing customization, 
maintenance, and periodic upgrades for Aleph 500. Continues development 
of ARC and serves as a lead in fielding Verde. Anticipates the need for 
design and programming enhancements to fulfill the information and 
research needs of the University community. Meets with Library 
Information Systems Managers on a regular basis to set priorities for 
the department. The Integrated Library Systems Librarian is expected to 
be active professionally and to contribute to developments in the field. 
Faculty with the VCU Libraries are evaluated, and promoted, on the basis 
of job performance, scholarship, and professional development and service.


QUALIFICATIONS:
Required: ALA-accredited graduate degree or accredited graduate degree 
in Information Systems or other related disciplines.
Preferred:  Experience implementing and/or supporting enterprise 
applications. Working knowledge of software applications needed to 
manage the Aleph environment, including UNIX command structure and 
system administration utilities, Apache, Perl, Oracle SQL, SFTP, XML, 
etc. Experience in a research library with knowledge of public and 
technical services operations as well as library standards (MARC, 
Z39.50, OAI-PMH). Proven ability to manage multiple projects and 
assignments concurrently and effectively. Strong analytical, 
troubleshooting, and problem solving skills. Excellent oral and written 
communication skills and the ability to interact professionally with a 
diverse group of clients and staff. Ability to work successfully with 
external vendor support and documentation. Availability and willingness 
to work a flexible schedule, including some nights, weekends, and 
holidays. Experience in training, customer support, and/or writing 
technical documentation. A passion and talent for creating easily 
understood systems that offer transparent yet complex functionality. 
Experience working in a culturally diverse environment highly preferred.


SALARY: Commensurate with qualifications, but not less than $48,000 
annually. This is a full-time, non-tenured faculty position. Normal 
faculty benefits apply, including 24 vacation days annually and choice 
of retirement and annuity plans. For more information about benefits, 
see http://www.hr.vcu.edu/benefits/.


A complete job posting is available at 
http://www.library.vcu.edu/admin/jobs/


For more information about the VCU Libraries, please visit our home page 
at http://www.library.vcu.edu/. Review of applications will begin July 
15, 2008, and will continue until the position is filled. Submit cover 
letter, resume, and the names, addresses, and telephone numbers of three 
references to:

Kathleen McColgan
Personnel Administrator
VCU Libraries, Virginia Commonwealth University
901 Park Avenue
PO Box 842033
Richmond, VA 23284-2033
804-828-2730
804-828-0151 (fax)
[EMAIL PROTECTED]

Virginia Commonwealth University is an Equal Opportunity/Affirmative 
Action employer. Women, minorities, and persons with disabilities are 
encouraged to apply.


--
Jimmy Ghaphery
Head, Library Information Systems
VCU Libraries
http://www.library.vcu.edu
--


Can't parse MARC Authority XML files with mx: prefixes in their tags

2008-06-09 Thread Christopher Morgan
I have been successfully using MARC::File::XML to process MARC subject
authority files from the LOC, such as this sample record:

 



http://www.loc.gov/MARC21";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.loc.gov/MARC21
http://www.loc.gov/standards/marcxml/schema/MARC21.xsd";>

 



00495cz   2200169n  4500

sh 0014 

DLC  

2508151507.0

000321i| anannbabn  |a ana




sh 0014 





DLC

eng

DLC 





Tacos   





 

The following script prints subfield "a" of tag 150:

 

MARC::File::XML->default_record_format('UNIMARCAUTH');

my $batch = MARC::Batch->new( 'XML', '../filename');

while (my $record = $batch->next()) { 

  for my $field ($record->field("150")){

my $name= $field->subfield('a'); 

print "$name", "\n";

 }

}

 

However, I'm having trouble parsing the name authority records online at
http://alcme.oclc.org/eprintsUK/index.html 

 

Here is part of one of these records (from

http://errol.oclc.org/laf/n50-7168.MarcXML): 

  

   

  http://www.loc.gov/MARC21/slim";
xmlns=http://www.w3.org/TR/xhtml1/strict

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

  

  0cz 220n  

  oca00042708 

  . . . . .

  . . . . .

  etc.

 

There are "mx:" prefixes in all the tags. What format is this? Is there any
way I can get MARC::File::XML to parse these files? 

 

A related question: When I first tried to process the subject authority
files from the LOC (in my first example, above), the program complained that
the "Leader must be 24 bytes long". All the leader tags in the authority
files I got from the LOC have five trailing blank spaces at the end. I
manually removed the spaces to get the test files to work. I can always
preprocess the files to take out the trailing spaces, but I wonder if
there's a way around this with MARC::File::XML. (These LOC subject authority
XML files are five years old. I wonder if the XML spec has changed since
then?)

  

Many thanks for any help!

 

- Chris Morgan



Re: Can't parse MARC Authority XML files with mx: prefixes in their tags

2008-06-09 Thread Jonathan Gorman


>However, I'm having trouble parsing the name authority records online at
>http://alcme.oclc.org/eprintsUK/index.html 

[snipped code examples]
>
>There are "mx:" prefixes in all the tags. What format is this? Is there any
>way I can get MARC::File::XML to parse these files? 

The prefixes are the namespace.  The parser should be able to handle this, but 
I don't honestly know if it does it correctly.  What also might be the problem 
is the second namespace in there.  It might help us if you included some 
information about what is not working (what error are you getting etc).  I 
don't have the time right now to run my own test, but actual error messages 
might provide some clue.

>A related question: When I first tried to process the subject authority
>files from the LOC (in my first example, above), the program complained that
>the "Leader must be 24 bytes long". 

Right, that comes from the MARC specification, there are 24 bytes.

>XML files are five years old. I wonder if the XML spec has changed since
>then?)

Doubt it, again it doesn't have anything really to do with the XML spec but the 
underlying xml record.  More likely it is some error in creating the files.  
Can't give any more info though, sorry.

Jon Gorman


RE: Can't parse MARC Authority XML files with mx: prefixes in their tags

2008-06-09 Thread Christopher Morgan
Jonathan,

Many thanks. I get no errors on the command line or in the error log when I
run the script. The file just executes with no output. If you have the time
to run it, I've included the scriupt below, and have attached the name
authority record it tries to process:

#! /usr/bin/perl
use strict;

use MARC::Record;
use MARC::Batch;
use MARC::File::XML;
use constant MAX => 20;

MARC::File::XML->default_record_format('UNIMARCAUTH');
my $batch = MARC::Batch->new( 'XML', 'name_authority_file');
while (my $record = $batch->next()) { 
  for my $field ($record->field("100")){
my $name= $field->subfield('a'); 
print "$name", "\n";
 }
}

I think you're right about the LOC files -- they probably got the extra
spaces by accident. That's easy enough to fix. 

As far as the name authorities go, if I can't get MARC::File::XML to process
them, I can always use XML::Tokeparser. Not as elegant, but it would get the
job done.

- Chris

-Original Message-
From: Jonathan Gorman [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 09, 2008 4:43 PM
To: Christopher Morgan; perl4lib@perl.org
Subject: Re: Can't parse MARC Authority XML files with mx: prefixes in their
tags



>However, I'm having trouble parsing the name authority records online 
>at http://alcme.oclc.org/eprintsUK/index.html

[snipped code examples]
>
>There are "mx:" prefixes in all the tags. What format is this? Is there 
>any way I can get MARC::File::XML to parse these files?

The prefixes are the namespace.  The parser should be able to handle this,
but I don't honestly know if it does it correctly.  What also might be the
problem is the second namespace in there.  It might help us if you included
some information about what is not working (what error are you getting etc).
I don't have the time right now to run my own test, but actual error
messages might provide some clue.

>A related question: When I first tried to process the subject authority 
>files from the LOC (in my first example, above), the program complained 
>that the "Leader must be 24 bytes long".

Right, that comes from the MARC specification, there are 24 bytes.

>XML files are five years old. I wonder if the XML spec has changed 
>since
>then?)

Doubt it, again it doesn't have anything really to do with the XML spec but
the underlying xml record.  More likely it is some error in creating the
files.  Can't give any more info though, sorry.

Jon Gorman


name_authority_file
Description: Binary data