Tag Archives: library 2.0

Commonplace.net blog

While not new, Commonplace.net is a new blog to me. The author, Lukas Koster, is Head of the Library Systems Department of the Library of the University of Amsterdam.

If you’re interested in Library 2.0 as it applies to library catalogues, cataloguing and basically, library 2.0 with a technical services bent, you’ll want to read this blog. 

Here are excerpts from more recent posts:
Relevance in Context

If you do a search in a bibliographic database, you should find what you need, not just what you are looking for, or what the database “thinks” you are looking for….You want the results that are the most relevant for your search, with your specific objectives, at that specific point in time time, for your specific circumstances, and you want them immediately….
So, how should search systems behave to make you find what you need?

Linked Data for Libraries

Some time after I wrote “UMR – Unified Metadata Resources“, I came across Chris Keene’s post “Linked data & RDF : draft notes for comment“, “just a list of links and notes” about Linked Data, RDF and the Semantic Web, put together to start collecting information about “a topic that will greatly impact on the Library / Information management world” …

No future for libraries? Will library buildings and library catalogs survive the web?

Who needs MARC?

Leave a comment

Filed under Our Profession

Using our in-house Wiki to keep cataloguers aware of subject heading changes

We recently received our hard copy of the Cataloging Service Bulletin from the Library of Congress. Our usual practice is to circulate this bulletin among all of the cataloguers so that they can make changes or add new subject headings in our own catalogue. In addition to the new subject headings that may or may not be adopted, there are subject headings that we alter or change. It is important to let all of the cataloguers know about these changes so that we maintain uniformity in our catalogue. Our practice in the past has been to send out group emails to advise everyone about these changes once all the decisions have been made.

Earlier this week, I had some great suggestions from two of my cataloguers. Rather than having a meeting to discuss the changes or additions, as we have in the past, one of the cataloguers suggested we add this information to the wiki. As each cataloguer has a chance to read the bulletin, they can add to the list of new, changed or old subject headings. Another cataloguer also suggested linking the pdfs of the Bulletin to the wiki. This will allow everyone to revisit decision made by LC, and in essence, everyone will then have a copy of the bulletin at their fingertips for reference.

Both of these are excellent ideas. Because of the format of the wiki, the entire department can also enter into discussions, or read the comments from the other cataloguers regarding any changes.

I’m looking forward to implementing these ideas.

1 Comment

Filed under Authority Work, In the Cataloguing Department, Subject Headings

Wikis and Cataloguers: Success for the First Step

Our new wiki was installed in the beginning of December. I was both nervous and excited. This is the first “big” project that could have a huge impact not only in the cataloguing department, but also throughout the rest of the library. If this pilot project works, I can write a report that recommends wikis for other departments throughout the library system, analyzing the strengths and weaknesses that I have encountered, as well as the learning curves, training challenges and staff participation.

The First Step
Although not fully implemented, my first step with our Wiki was to introduce the cataloguers to its possible functions and uses. I put up many of our cataloguing “cheat sheets”, links to relevant cataloguing sites, department announcements and recent cataloguing decisions from LC and LAC. Sending them the link to the Wiki, I asked them to have a look around, get use to the navigating aspects and layouts. Upon reviewing the site, I asked for their feedback: What did they like? Dislike? Ideas for adding new content?

With my excitement in this project and by taking the time to answer questions and explain the possibilities of the Wiki, all of the cataloguers began suggesting ideas or providing me with feedback. One of the most rewarding moments was when one of the cataloguers suggested we put our “working” New Lists on the Wiki.

Collaborative Lists
New Lists are created as we catalogue items. Like most cataloguing departments, each cataloguer is in charge of cataloguing specific materials (DVDs, CD, Fiction, Talking books, Non-fiction, Children’s Non-fiction, etc). As we catalogue, items published or released within the last two years are added to “New” lists which are provided to the public and are constantly being edited and updated. Each cataloguer is responsible for their list, which reflects the items they catalogue. However, when backlogs occur, several cataloguers may be assigned to a specific collection to reduce the backlog.

With several cataloguers contributing to these New lists, it was becoming difficult for the main cataloguer in charge of the list to keep track of the item, how long they had been on the list, and when they should be removed. In addition, many cataloguers have their own system for keeping track of the lists (I.e. Word documents, Excel Charts, Handwritten notes). The time to organize these lists when multiple cataloguers were contributing was becoming a concern.

Our solution was to place the New lists on the Wiki. Presently, we are actively contributing to the New! Latest CDs list. This is an internal list that can be seen and edited by all cataloguers.

Because of the backlog, there can be up to four cataloguers contributing to this list at once. Because of the Wiki, there is one master list for each collection and the items are sorted by date. The cataloguer in charge of the list can then see when the item was added, how long it has been on the list and who added the item. This makes editing the live list in the cataloguer much easier. The amount of time that this has saved is equivalent to a couple of hours a week. As a result of the hours being saved organizing and editing the lists, more time can be spent cataloguing and reducing backlogs in other areas.

This is the first of many steps that I hope to take in the department. My next step is to set up a tutorial to allow cataloguers to create a group page and to collaborate on a project, using the features a Wiki has to offer. Once they have completed this tutorial, they should have the skills and knowledge to jump in to using the Wiki on a regular basis.

2 Comments

Filed under In the Cataloguing Department, The Cataloguer

A Wiki in our cataloguing department

You won’t find any Star Wars characters in our department, but you will soon find a Wiki.

When you enter your cataloguing department every day, you bring with you information that cannot be found in AACR2 or MARC. In addition to the many tools we use such as DDC, Bookwhere, Cutter tables, Validator, LC and so on, there are internal cataloguing rules that many of us have not bothered to write down because we just “know it”. But, when I first started my position, I didn’t “know it” because I was new to the system.

After creating two handwritten binders full of notes and collecting “cheat sheets” from all of my cataloguers, I began to think that there had to be an easier way to organize this information. There are rules based on rules that were based on a meeting three years ago. This is the type of information that only exists as long as there is no turnover or retirement within the department. However, this information is vital to retain when people leave the department because we will no longer have them as our resource.

Having experienced this “cataloguer’s knowledge” firsthand, I began exploring different options to organize and retain this information. How can we have a shared space where the department can access “cheat sheets” and other resources? Can I create a space where we can collaborate as well? At first I considered creating a simple database. Then, I thought about having all of the documents typed up and creating one master binder for the department. All of these just didn’t feel right. I looked at blogs but wasn’t really sure that it was right for our department and then I stumbled upon wikis.

Wikis are free, open-source software created for the purpose of sharing information. This really grabbed my attention the first time I saw it. After further reading, I found myself attracted to the real-time factor and potential of the Wiki. The real-time factor means that I can spend less time fielding emails and sending around internal cataloguing rules in draft. Instead, I can post one draft and collaboratively have all of the cataloguers critique and edit it until it works. I like the idea of having the cataloguers play a role in creating internal rules and accessing them immediately. In addition to storing all of our in-house cataloguing rules, I plan on including minutes from our meetings, announcements from LC, SirsiDynix, other vendors and links to all of our online resources. I can even include a professional development element.

Currently, I am in the beginning stages of setting up a Wiki for our department. I have had the opportunity to “play” with the software and get a feel for its potential. I have also been speaking with staff, seeking their input and really pushing the buy-in factor. I’m fortunate because my cataloguing department is full of people who are really keen on new technology and are always willing to at least try something new. At the present time, I am organizing all of the information that we want on the Wiki. This is a bit labour intensive. Sorting through old meeting notes and cheat sheets is time consuming. Once I have chosen the base information for the Wiki, I still need to type it, organize it and assign access points to it. I need to design not only the content of the Wiki, but its general layout.

There are also privacy issues and editing restrictions that need to be addressed. Because it is open source software, I need to be careful who can edit the Wiki and who can see it. Should we store it on a web server or on our own intranet? Should all the cataloguers have editing access? Who should monitor the edits in addition to myself?

As this project goes on, I’ll be able to share my experiences with you. Overall, I see this as a very good thing for our cataloguing department. There are so many steps ahead and I am not naive about the time that it will take to create the Wiki. Once the Wiki is finally in place, there is always the staff training and evaluation. However, I am optimistic that this will be a great asset to our department.

4 Comments

Filed under The Cataloguer