Planet Cataloging

April 24, 2014

First thus

Re: [ACAT] Metadata 101 - Post-graduate training?

Posting to Autocat On 4/17/2014 8:43 PM, J. Adalia wrote: <snip> ... I'd love to get recommendations from you all about how to structure a self-taught program from beginner to where you think I ought to be and possibly some ways to obtain experience. Does anyone know of how a novice could gain experience even if it's not within a library? </snip> Metadata is a huge area, but traditional

by noreply@blogger.com (James Weinheimer) at April 24, 2014 09:01 AM

April 21, 2014

First thus

Re: [ACAT] Advantages of RDA - get rid of disbelievers

Posting to Autocat On 4/18/2014 11:10 PM, MULLEN Allen wrote: <snip> It is unfortunate that I, a largely ignorant cataloger on the sidelines in a small city public library, feel a need to explain the goals and possibilities of RDA/Bibframe. It is likely I'm off-base in one or several respects, but this is my best take on it, and I really have not seen a clear, easy overview of this for

by noreply@blogger.com (James Weinheimer) at April 21, 2014 03:46 PM

Re: [ACAT] Advantages of RDA - get rid of disbelievers

Posting to Autocat On 4/18/2014 6:25 PM, MULLEN Allen wrote: <snip> These twin strategies - incorporating library metadata into the web and defining relationships so that users can follow their interests using structured metadata - build on the legacy and work of the cataloging community. Whether they are adequate or will be successful remains to be seen. I really don't care whether RDA

by noreply@blogger.com (James Weinheimer) at April 21, 2014 03:37 PM

April 20, 2014

Lorcan Dempsey's weblog

The decentered library network presence

Think of two trends in the development of the library's network presence. These have emerged successively and continue to operate together.

  1. A centripetal trend producing a library network presence centered on the institutional website, as the library wants to offer an integrated service.
  2. A centrifugal trend, unbundling functionality and placing it in a variety of decentered network presences, as the library wants to be in the flow of its users (think of how communication has been unbundled to social networking sites for example, or of how metadata may be shared with various aggregation sites, or of how a resolver may be configured for use with a third party site).


The decentered library network presence is an important component of library service although it still appears to be an emergent interest in strategic or organizational terms.

In the centripetal trend, the focus was on integration around a singular, 'centered' network presence: the library website. The library website was the principal de facto network manifestation of the library, and the integration of library services in the website was a goal. Early examples of this were discussions around 'portals', one-stop-shops and metasearch. Later, this trend continued with more consolidated approaches which overcame some of the cost and inefficiencies of integration. Included here were the use of unified search systems often deploying integrated discovery layer products, the use of resource guides to manage resources with a consistent approach, the adoption of content management systems. Service consolidation, a stronger focus on providing a coherent user experience, a move to cloudsourced applications (discovery and resource guides for example), and an emerging emphasis on full library discovery help create a more unified experience at the library website.

In the centrifugal trend, the network library presence is decentered, unbundled or decoupled to an evolving ecosystem of services, each with a particular focus or scope. Think for example of how aspects of user engagement have been unbundled to various social networking sites (Facebook, Twitter, Pinterest, Flickr, ...), or of how parts of the discovery experience has been unbundled to Google Scholar or PubMed or to a cloud-based discovery layer, or of how some library services are atomized and delivered as mobile apps, toolbar applications, or 'widgets' in learning management systems and other web environments external to the library's. The library website is now a part, albeit an important part, of this evolving network presence. In this way, the library network presence has been decentered, subject to a centrifugal trend to multiple network locations potentially closer to user workflows. There are two important drivers here. One is the desire to reach into user workflows, acknowledging that potential library users may not always come to the library website. A second is the desire to make institutional resources (digitized special collections, research and learning materials, for example) available to external audiences in more effective ways. This is an aspect of the 'inside-out library'.

Here are some strands of the 'decentered' library network presence.

  • Unbundled engagement and communication. Several activities may have been decoupled from the website and sourced with web-scale services. For example, engagement and communications activities may be sourced with Twitter, Facebook, and WordPress. Promotional activity may take place on YouTube, Flickr, and Pinterest.
  • Syndication: We can define syndication as creating connections to library information services in other environments, by placing data, content or services in those other environments. Library resources may be made available, for example, as widgets in the learning management system, as an RSS feed, or in a LibX-style toolbar. There is also strong interest in apps for mobile phone and tablets. The library may syndicate data to other environments, passively through OAI-PMH harvesting or newer linked data approaches, or by more active transfers to WorldCat or some other metadata aggregation. The library may configure a resolver to ensure well-seamed access from Google Scholar or Pubmed Central, which is also a form of service syndication. The goal is to make the library resources discoverable in user workflows. The University of Minnesota discoverability reports are well worth reading in this context.
  • Cloudsourcing: Integration of systems and services, sourced from the cloud. It is now becoming more common to externalise systems provision to third party providers: think of the discovery layers that libraries are deploying in the cloud for example, or the LibGuides resource guides. The move to cloud providers is a major direction here, and one of the motivations is to reduce some of the systems integration complexity, while improving the user experience. By cloudsourcing here, I am referring to the selective move of library operations to the cloud. Of course, the unbundled communication activity is also sourced from the cloud, but is typically from non-library providers. As noted above, cloudsourcing can support the centripetal trend as external resources may be integrated in the website, but it also supports the centrifugal trend as services may be made available as independent external destinations, or may be syndicated to other network presences (e.g. access to a central index API).

Now, despite the fact that there is quite a bit of activity supporting what I am calling here the decentered network presence, it has not crystallized as a service or organizational category for the library. It is an area of emergent interest. There seem to be at least three factors at play.

  • Unquantified. Libraries don't have a holistic view of traffic against their entire network presence. The difficulty of compiling statistics across services is well known. Libraries are working across multiple environments and systems, with intermittent availability of good data about usage, no consistent approach across systems, and usually no aggregate view. This means that the library's knowledge of the use of its own services, and of the benefits of particular approaches, is limited in important ways. At the same time, while there is awareness of the benefits of better data, a data-driven approach to engagement, resource allocation, or service development is not yet prevalent. Anecdotal and local evidence shows the importance of syndicated approaches (including Google referrals) in general traffic against library resources, but we do not have a general picture.
  • Pre-strategic. The importance of unbundled communication, syndication and cloudsourcing is agreed. However, strategic attention to these areas is often rather more emergent than deliberate (in the sense in which Mintzberg uses these terms). Attention may be opportunistic, although is likely to be increasingly patterned in future.
  • Spanning organizational boundaries. A variety of parts of the library is interested in a network presence, and attention to these topics may not always be pulled together in a single planning context. This is clear of social networking, but may also be the case with the other areas I mention.

Clearly, there are different dynamics at play in the components of the decentered network presence of the library. However, we can expect a more holistic view to emerge in coming years.

Related entries:


by dempseyl@oclc.org (Lorcan Dempsey) at April 20, 2014 10:59 AM

Resource Description & Access (RDA)

Authorized Access Point - Meeting Name - MARC to RDA Mapping

MARC 21
FIELD
TAG
MARC 21
SUBFIELD CODE
MARC 21 FIELD /
SUBFIELD NAME
RDA
INSTRUCTION
NUMBER
RDA
ELEMENT
NAME
111Main entry—Meeting name19.2Creator
111Main entry—Meeting name19.3Other Person, Family, or Corporate Body Associated with a Work
111aMeeting name or jurisdiction name as entry element11.2.2Preferred Name for the Corporate Body
111aMeeting name or jurisdiction name as entry element11.3.3Location of Headquarters, etc.
111aMeeting name or jurisdiction name as entry element11.4.3Date of Establishment
111aMeeting name or jurisdiction name as entry element11.4.4Date of Termination
111aMeeting name or jurisdiction name as entry element11.5Associated Institution
111aMeeting name or jurisdiction name as entry element11.7Other Designation Associated with the Corporate Body
111cLocation of meeting11.3.2Location of Conference, etc.
111cLocation of meeting11.5Associated Institution
111dDate of meeting11.4.2Date of Conference, etc.
111dDate of meeting6.4Date of Work
111eSubordinate unit11.2.2Preferred Name for the Corporate Body
111fDate of a work6.10Date of Expression
111gMiscellaneous informationN/A
111jRelator term18.5Relationship Designator
111kForm subheading6.2.2Preferred Title for the Work
111lLanguage of a work6.11Language of Expression
111nNumber of part/section/meeting6.2.2Preferred Title for the Work
111nNumber of part/section/meeting6.3Form of Work
111nNumber of part/section/meeting6.4Date of Work
111nNumber of part/section/meeting6.5Place of Origin of the Work
111nNumber of part/section/meeting6.6Other Distinguishing Characteristic of the Work
111nNumber of part/section/meeting11.6Number of a Conference, etc.
111pName of part/section of a work6.2.2Preferred Title for the Work
111pName of part/section of a work6.3Form of Work
111pName of part/section of a work6.4Date of Work
111pName of part/section of a work6.5Place of Origin of the Work
111pName of part/section of a work6.6Other Distinguishing Characteristic of the Work
111qName of meeting following jurisdiction name entry element11.2.2Preferred Name for the Corporate Body
111tTitle of a work6.2.2Preferred Title for the Work
111tTitle of a work6.3Form of Work
111tTitle of a work6.4Date of Work
111tTitle of a work6.5Place of Origin of the Work
111tTitle of a work6.6Other Distinguishing Characteristic of the Work
111uAffiliation11.9Address of the Corporate Body

[Source: RDA Toolkit]

by Salman Haider (noreply@blogger.com) at April 20, 2014 03:50 AM

April 18, 2014

OCLC Cataloging and Metadata News

Connexion client 2.51 is released

Connexion client 2.51 is now available for download from the Software download area of Product Services Web.  All Connexion client 2.40 libraries must upgrade to either Connexion client 2.50 or 2.51 by July 31, 2014.  An upgrade warning message will begin appearing when you start version 2.40 beginning in June 2014.  View the upgrade instructions before installing version 2.50 or 2.51.

April 18, 2014 02:00 PM

First thus

Re: [ACAT] Advantages of RDA - get rid of disbelievers

Posting to Autocat On 17/04/2014 23.51, MULLEN Allen wrote: <snip> RDA, nor any cataloging code, is about the convenience to the cataloger. Our work remains the convenience of the user. </snip> This is one of those platitudes we are taught in library school and is repeated over and over again, much as a mantra. The fact is, people have complained loudly about library catalogs from the

by noreply@blogger.com (James Weinheimer) at April 18, 2014 11:00 AM

Re: [ACAT] Advantages of RDA - get rid of disbelievers

Posting to Autocat Of course, being against certain changes does not mean that someone is against all changes. That is a dead argument. Still, there needs to be at least some agreement on what are the challenges facing us before any kind of changes should be considered, and I don't think there is much agreement at all. As only one example, I think there is general agreement that we need to be

by noreply@blogger.com (James Weinheimer) at April 18, 2014 10:57 AM

April 17, 2014

Celeripedean

Jen

I recently attended the New England Technical Services Librarians 2014 Annual Spring Conference, or NETSL 2014. I’ve attended NETSL for some time now. My first time was in 2006 as a GSLIS student at Simmons. Later, I volunteered to help out with registration. Then I joined the board as Treasurer. This current board year, I’m the Past President, finishing up not only a three year term as I started as Vice President, but also after a year as treasurer and as a volunteer. Each year, NETSL hands out the NETSL Award for Excellence in Technical Services. This year, the NETSL Award went to Amira Aaron of Northeastern University and Diane Baden from Boston College. What I found particularly moving this year was Diane’s acceptance speech about networking and mentoring. In short, she explained that it was a great honor to receive this award. For her, her involvement in the profession was all about learning, networking, reaching out and giving back to the profession. This struck home. Many of us are on committees of one sort or another. Many librarians are also tenured or seek tenure or perhaps a promotion which involves showing evidence of professional activity and scholarly research. Being professionally active because it will count towards moving up the career ladder is one reason. Granted, many might this as myopic. But I see it as a good start to becoming involved if it leads to a greater understanding of what it means to be part of the profession and what it means to be professional. I would like to emphasize the “good start”. Being professionally involved cannot be solely about working up the career ladder. Well I guess it can but that would mean a very ambitious sort of climb that might be helpful only for the climber. I would prefer to see professional involvement as giving back to the profession and where librarians really excel at sharing and communicating amongst themselves their expertise and experiences. This passion to help our profession comes not from being ambitious towards greater professional peaks but the willingness to see our profession grow and evolve. Is this idealistic? Certainly, though not entirely! It is also practical. By being on committees, presenting, networking, being mentored or mentoring, we learn through engagement. With small steps, we breach the many silos that we work in and around each day to do a better job as librarians as a whole. To be engaged is to work collaboratively with our peers for better or worse.

This sentiment was echoed in the remembrance for Birdie MacLennan, a prominent New England librarian who passed away recently. The remembrance was delivered by two of Birdie’s mentees and one of Birdie’s mentors. They recalled how Birdie would selfless help those navigate a new career as a librarian. This was done not only through networking but also through engagement with others to further the field of technical services in librarianship.

Out of all the presentations that day, the most moving were Diane’s acceptance speech and this remembrance. Each reminded me that engagement is so much more than just an accomplishment. It is giving back to the profession by learning and collaborating with your peers.


Filed under: cataloging Tagged: engagement, giving to the profession, mentoring

by Jen at April 17, 2014 09:02 PM

Bibliographic Wilderness

Large collections in JS in the browser

Developers from the New York Times have released some open source software meant for displaying and managing large digital content collections, and doing so client-side, in the browser with JS.

Developed for journalism, this has some obvious potential relevance to the business of libraries too, right?  Large collections (increasingly digital), that’s what we’re all about, ain’t it?

Pourover and Tamper

Today we’re open-sourcing two internal projects from The Times:

  • PourOver.js, a library for fast filtering, sorting, updating and viewing large (100k+ item) categorical datasets in the browser, and
  • Tamper, a companion protocol for compressing categorical data on the server and decompressing in your browser. We’ve achieved a 3–5x compression advantage over gzipped JSON in several real-world applications.

Collections are important to developers, especially news developers. We are handed hundreds of user submitted snapshots, thousands of archive items, or millions of medical records. Filtering, faceting, paging, and sorting through these sets are the shortest paths to interactivity, direct routes to experiences which would have been time-consuming, dull or impossible with paper, shelves, indices, and appendices….

…The genesis of PourOver is found in the 2012 London Olympics. Editors wanted a fast, online way to manage the half a million photos we would be collecting from staff photographers, freelancers, and wire services. Editing just hundreds of photos can be difficult with the mostly-unimproved, offline solutions standard in most newsrooms. Editing hundreds of thousands of photos in real-time is almost impossible.

Yep, those sorts of tasks sound like things libraries are involved in, or would like to be involved in, right?

The actual JS does some neat things with figuring out how to incrementally and just-in-time send delta’s of data, etc., and some good UI tools. Look at the page for more.

I am increasingly interested in what ‘digital journalism’ is up to these days. They are an enterprise with some similarities to libraries, in that they are an information-focused business which is having to deal with a lot of internet-era ‘disruption’.    Journalistic enterprises are generally for-profit (unlike most of the libraries we work in), but still with a certain public service ethos.  And some of the technical problems they deal with overlap heavily with our area of focus.

It may be that the grass is always greener, but I think the journalism industry is rising to the challenges somewhat better than ours is, or at any rate is putting more resources into technical innovation. When was the last time something that probably took as many developer-hours as this stuff, and is of potential interest outside the specific industry, came out of libraries?


Filed under: General

by jrochkind at April 17, 2014 06:10 PM

“You build it, you run it”

I have seen several different approaches to division of labor in developing, deploying, and maintaining web apps.

The one that seems to work best to me is when the same team responsible for developing an app is the team responsible for deploying it and keeping it up, as well as for maintaining it. The same team — and ideally the same individual people (at least at first; job roles and employment changes over time, of course).

If the people responsible for writing the app in the first place are also responsible for deploying it with good uptime stats, then they have incentive to create software that can be easily deployed and can stay up reliably. If it isn’t at first, then the people who receive the pain of this are the same people best placed to improve the software to deploy better, because they are most familiar with it’s structure and how it might be altered.

Software is always a living organism, it’s never simply “done”, it’s going to need modifications in response to what you learn from how it’s users use it, as well as changing contexts and environments.  Software is always under development, the first time it becomes public is just one marker in it’s development lifecycle, and not a clear boundary between “development” and “deployment”.

Compare this to other divisions of labor, where maybe one team does “R&D” on a nice prototype, then hands their code over to another team to turn it into a production service, or to figure out how to get it deployed and keep it deployed reliably and respond to trouble tickets.  Sometimes these teams may be in entirely different parts of the organization.  If it doesn’t deploy as easily or reliably as the ‘operations’ people would like, do they need to convince the ‘development’ people that this is legit and something should be done? And when it needs additional enhancements or functional changes, maybe it’s the crack team of R&Ders who do it, even though they’re on to newer and shinier things; or maybe it’s the operations people expected to it, even though they’re not familiar with the code since they didn’t write it; or maybe there’s nobody to do it at all, because the organization is operating on the mistaken assumption that developing software is like constructing a building, when it’s done it’s done.[1]

I just don’t find that it works well to create robust, reliable software which can evolve to meet changing requirements.

 

Recently I ran into a quote from an interview with Werner Vogels, Chief Technology Officer at Amazon, expressing these benefits of “You build it, you run it.”:

There is another lesson here: Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.

I was originally directed to that quote by this blog post on the need for shared dev and ops responsibility, which I reccommend too.

In this world of silos, development threw releases at the ops or release team to run in production.

The ops team makes sure everything works, everything’s monitored, everything’s continuing to run smoothly.

When something breaks at night, the ops engineer can hope that enough documentation is in place for them to figure out the dial and knobs in the application to isolate and fix the problem. If it isn’t, tough luck.

Putting developers in charge of not just building an app, but also running it in production, benefits everyone in the company, and it benefits the developer too.

It fosters thinking about the environment your code runs in and how you can make sure that when something breaks, the right dials and knobs, metrics and logs, are in place so that you yourself can investigate an issue late at night.

As Werner Vogels put it on how Amazon works: “You build it, you run it.”

The responsibility to maintaining your own code in production should encourage any developer to make sure that it breaks as little as possible, and that when it breaks you know what to do and where to look.

That’s a good thing.

None of this means you can’t have people who focus on ops other people who focus on dev; but I think it means they should be situated organizationally close to each other, on the same teams, and that the dev people have to have share some ops responsibilities, so they feel some pain from products that are hard to deploy, or hard to keep running reliably, or hard to maintain or change.

[1] Note some people think even constructing a building shouldn’t be “when it’s done it’s done”, but that buildings too should be constructed in such a way that allows continual modification by those who inhabit them, in response to changing needs or understandings of needs.


Filed under: General

by jrochkind at April 17, 2014 04:45 PM

Mod Librarian

April 16, 2014

First thus

Re: [ACAT] Advantages of RDA

Posting to Autocat On 4/16/2014 7:47 AM, Hal Cain <hegcain@gmail.com> wrote: <snip> The alternative view is the pragmatic one: it's happened, we'll just do the best we can with it.</snip> I've been out for a few days, and just saw this thread. The advantages of RDA are primarily theoretical: based on entities and attributes, so that the public can navigate the works, expressions,

by noreply@blogger.com (James Weinheimer) at April 16, 2014 09:07 PM

April 14, 2014

Books and Library stuff

tower

 

20131007-071951.jpg

I’ve always suspected the protective power of books, the sense of sanctuary in a library or bookshop, and the calm that descends when reading. In his novel, Steven Hall describes the  intriguing premise that all human minds are linked by vast ‘streams’ of language and thought, and, swimming through these streams, are thought-fish. Not all fish are good, and from the most predatory of all, the Ludovician, we need protection or camouflage:

Books of Fact/Books of Fiction:  Books of fact provide solid channels of information in many directions.  Library books are best because they also link the book itself to every previous reader and any applications of the text.  Fiction books also generate illusionary flows of people and events and things that have never been or maybe have only half-been from a certain point of view.  The result is a labyrinth of glass and mirrors which can trap an unwary fish for a great deal of time.  I have an old note written by me before I got so vague which says that some of the great and most complicated stories like the Thousand and One Nights are very old protection puzzles, or even idea nets by which ancient peoples would fish for and catch the smaller conceptual fish.  I don’t know if this is true or not.  Build the books into a small wall around yourself.  My notes say three or five books high is best.’

The Raw Shark Texts

There have been times there is no denying, when the only thing to do, would be to come home to my favourite books, stack them up around me, and find peace enough to relax knowing that I was safe in my book tower. Now I know, they only have to be three or five books high…

tower

 

thoughts from scarlettlibrarian”


by venessa harris at April 14, 2014 07:47 PM

A portal to my Cataloguing Aids website

Knights Templar

I catalog a lot of fiction.  A popular topic  involves the historic Christian military order the Knights Templar – an organization that existed for nearly two centuries during the Middle AgesKnights Templar

When cataloging works about this historic order I notice that a lot of libraries incorrectly use the subject heading:

Knights Templar (Masonic order)  n 80001259

which is an international philanthropic group affiliated with Freemasonry

For works about the historic Christian military order of the Knights Templar the correct subject heading is:

Templars    n 80113860

These groups are easily confused.  I hope this posting sheds some light on this topic…

 

 


by Fictionophile at April 14, 2014 03:17 PM

April 11, 2014

Thingology (LibraryThing's ideas blog)

Come Learn PHP at ALA 2014

EnoughLogo_350

Summary: Tim, LibraryThing’s founder, is going to be giving a one-day, almost-free introduction to PHP programming on Friday, June 27, alongside the preconference day of ALA 2014 in Las Vegas, NV.

“Enough PHP to Be Dangerous” will cover the basics of PHP, the most common web programming language. It’s designed for people with little programming experience.(1)

Instruction will be project-based–a series of brief explanations followed by hands-on problem solving. You won’t emerge a PHP master, but you’ll know enough to be dangerous!(2)

We’ll presume some familiarity with the web, including basic HTML. You must bring your own laptop. We’ll ask you to set up a simple development environment before you come–we’ll send instructions. You should be connected to libraryland somehow. Prepare for a mental workout–there’s no point going slow when we only have a day.

Where? The session will be held Friday June 27, 9am-5pm at Embassy Suites Convention Center, three blocks from the Convention Center.

How do I sign up? Email tim@librarything.com. Say who you are and put “Enough PHP to Be Dangerous” in the subject line.

We’ll close applications on Monday, April 14 at 4:00 PM EST. If more than 30 people sign up, we’ll pick the winners randomly. If fewer, we’ll allow people to sign up after the deadline on a first-come-first-served basis.

What Does it Cost? On the day of we’ll pass the hat, asking $55 to cover the $45 cost of hotel-provided muffins, coffee and sandwiches, and some of the cost of the room, equipment and wifi. If $55 is a hardship for you, no problem–we’ll waive the fee, and you’ll still get a sandwich.

Why do I need this? Libraryland needs more programmers, and people who know what programming is. Libary software vendors exert outsized power and too often produce lousy software because the community has limited alternatives. The more library programmers, the better.

Why are you doing this? Conferences are hugely expensive to exhibit at. They’re worth it, but it’s a shame not to do more. If we’re going to be out there anyway, adding a day, a room and a projector doesn’t add much to the cost, and could help the community. Also, I’m a frustrated former Latin teacher, so it’ll be fun for me!(3)

Is this officially connected to ALA, LITA, Library Code Year, etc.? Nope. We’re doing this on our own. It’s easier that way. Of course, we love all these groups, especially our friends at LITA.(4)

Will the class be broadcast? No. That sounds fiddly. Maybe another time.

Want to help out? If you’re a programmer and want to help make this happen, email me. It would be great to have another programmer or two helping people figure out why their script won’t run. It’ll be fun, and you can put it on your resume.


1. If you tried to learn something years ago, or do a little cutting and pasting of JavaScript, fine. If you’re a master of another programming language, you’ll be bored.
2. We’ll focus on the most basic skills–variables, loops, functions, etc. We’ll focus on non-OO PHP. We’ll print up some funny diplomas, so you can show off your new-found dangerousness back at the library.
3. Alas, the hotel doesn’t provide chalk boards.
4. We take inspiration from Introductory Python Workshop at ALA 2013, put together by Andromeda Yelton and others.

by Tim at April 11, 2014 02:45 PM

Catalogue & Index Blog

cilipcig

The new issue of C&I is now available to members here. This issue features papers from our recent Linked Data event.


by cilipcig at April 11, 2014 11:25 AM

April 10, 2014

TSLL TechScans

Online Bibliographic Services and Technical Services Special Interest Sections' Joint Research Grant accepting applications.

Posted at the request of the AALL OBS-SIS and TS-SIS Joint Research Grant Committee.

The AALL OBS-SIS and TS-SIS Joint Research Grant Committee is now accepting applications for the 2014 Grant! 

The purpose of the Online Bibliographic Services and Technical Services Special Interest Sections' Joint Research Grant is to provide support to American Association of Law Libraries members conducting research specific to technical services law librarianship that will enhance law librarianship service to our clients.

Qualifications: AALL membership is required. Preference will be given to applicants who are members of the OBS-SIS and/or TS- SIS at the time of application. Evidence that the research and publication will directly or indirectly benefit technical services law librarianship must be shown.
Grant Awards: JRGC awards grants in a single year ranging in amount of no more than $1,000 at the discretion of JRGC, --and-- pending approval of each grant amount each year as authorized by OBS and TS Executive Boards. 

Deadlines: Applications are due to the JRGC Chair no later than May 15, 2014. Grant recipients will be announced at the annual AALL meeting. Award amounts will be mailed to successful grant recipients as soon as final approval is received by the JRGC Chair.

For more information on the grant and the application process, please visit: http://www.aallnet.org/sections/obs/committees/joint-research-grant-committee

If you have any further questions, please email the JRGC Chair, Kerry Skinner at Kerry.Skinner@asu.edu.

by noreply@blogger.com (Jackie Magagnosc) at April 10, 2014 07:12 PM