MLA 2009 conference summary

On Oct. 15 I attended the MLA conference in St. Cloud. It was a bit of a long day with driving to & from, but well worth it! There really were a wide range of presentations to attend--split into four sessions. Here is a summary of the presentations I attended:

Best Practices for Creating Online Tutorials by Matt Lee

Matt noted that tutorials are most effective in situations where there is a task to learn, the content is fact-based, the content provides introductory knowledge, when it is an advantage for the learner to move at her own pace, when it is difficult to bring the group of learners into one place at the same time, and when a multi-media/multi-learner style is preferred.

· Be clear about audience (focus the content, take users point of view into account)
· Be clear about outcomes (define the scope of the tutorial)
· Be clear about content (make the structure & scope clear)
· Encourage interaction (engage active learning & multiple learning styles)
· Employ varied design (keep it interesting)
· Be a resource beyond the tutorial (encourage follow-up & periodically review & update tutorials)

He also mentioned that one may not always be able to incorporate all of these practices into a tutorial, but it is a guide for things to think about when planning the design of an online tutorial. He also gave a demonstration of Camtasia a video screen capturing software that can be used to create online tutorials (Captivate is another).

Trends in Tech Services presented by Emily Asch (SCU)

Emily Asch outlined some trends that the tech services community is following and finding ways to engage in: digitization, institutional repositories, electronic vs. print resources, social cataloging/tagging, discovery layers, and tech services 2.0 (creative ways to utilize technology in work-flow). Other challenges/opportunities include re-thinking the functions and work-flow of tech services and working with non-traditional resources and people with which tech services don't normally collaborate.

RDA Update presented by Mary Huismann (U of Minn)

Resource Description and Access (RDA) will be the new standard to replace AACR2 cataloging. Its main features include being compatible with the digital environment (both the descriptive elements and the usability of the records), being compatible with international standards, being adaptable for use outside of the library community, and incorporating FRBR. New to the descriptive elements, it will include "core" elements and the General Material Designations (GMD) will be replaced by Content Types, Media Types, and Carrier Types.

Twenty-three institutions & vendors were chosen to test RDA, and formal testing and assessment will happen in 2010. It was discussed at the session that RDA won't be approved until after Oct. 2010, and that after that time institutions will make the change when it makes sense for them. Its availability through an institution's current ILS may be the first factor to take into account in planning the move to using RDA.

Workflows for Outsourced Technical Services

This panel discussed their experiences in receiving and using vendor supplied cataloging records. It seems that overall, the librarians thought that it was a cost saving measure over original cataloging, but that one must factor in time needed to fix up unsatisfactory records and the changes in work-flow to accommodate this--a time vs. cost savings challenge. Some were very frank in admitting that there needs to be minimum "good enough" established within an institution's tech services in order to keep some sort of standard, while making the best use of time. From the panel's experiences, they listed main questions to ask before entering a vendor agreement:

The work-flow for working with these supplied records when received within a consortia was also discussed. Factors to consider are if a record is shared or for the individual institution, how to coordinate the loading of records, if downloading affects the speed of the system, and how to avoid overlay of records by another institution in the consortium.

Strategic planning for E-Resources Management

Presented by Minn. State Mankato librarian and E-resources Librarian and Serials Manager of Gustavus Adolphus. The presentation started with overview of how a strategic plan for this aspect of library collections can be useful and followed up with experience in creating strategic plan at Gustavus Adolphus. It was used as a way to clarify and define roles and workflow for overlapping resources between the E-resources Librarian & Serials Manager.

Koha...

It seems that the problems in Koha were related to the operating system being used. I guess it doesn't play nice with Zebra. So, we waited for some late summer updates, & I became absorbed in some other activities related to the MLIS curriculum. I will be using Koha shortly for my advanced cataloging class; so maybe there will be more musings, soon!

Koha 3.0--answer to the problems?

I was just looking back at old posts and seeing the hopes that the new version would address some of the search problems--new version, new problems! I think some of the problems may come from the administrative/global preferences set up.

I didn't look too closely at biblio record linking or item linking because it seems there are some other issues that maybe should be addressed first. One thing of interest in regard to the problem of where the item type information came from (bib record or item record) that we had in the previous version: in the "Global Systems Preferences: Cataloging" it shows a line item "item-level_itypes" which controls whether "the item type stored at the bib or item level is used for circulation policies."(Koha manual page) This line item doesn't exist in our version of Koha in "Global Systems Preferences: Cataloging."

Onto the present problems...in the same screen there is a somewhat confusing line: "NoZebra." We have this set to "ON" which means Zebra indexing is off, and on the line below, in "NoZebraIndexes" the value is "0" instead of a string of index definitions for the internal search engine to use when "NoZebra" is set to on. The above mentioned manual page has the string if we're not going to be using zebra. The page also offers these warnings for using "NoZebra:"

• If your library's collection is over 25,000 you must have this preference to OFF to get fast searching.
• Using this feature on a busy Koha installation has proven to be rather resource intensive.
• It is recommended that this setting NOT be changed after initial installation of Koha.

(oops, I initially changed the "NoZebra" setting before I had read that warning. I did set it back to the original setting.)

In looking at some of the Koha mail-list archives I found some messages that may help, but I'm afraid a lot of it is over my head, so I'm not sure if they will be helpful...It seems that even if the searching gets to working in the librarian interface, there may be other issues to address in order to get the searching to work in the public interface. A December 16 post talks about "rebuild_zebra" and it sounds like groups are running this at least once a day. Here is a Feb. 15 response to the same message, too. A Nov. 15 thread also offers some suggestions that I'm not sure if they are helpful or not--user and file owner are not the same-?

If we later encounter problems in the OPAC interface maybe the "hide lost items" needs to be disabled. If we run into problems with branch search later, check out the Jan. 28 thread.

I also ran the "MARC bibliographic framework test" and found that it returned some errors. In order to make it happy with the MARC to Koha field mapping I needed to put all of the subfields of a tag within the same folder (default and Basic Book frameworks):

049 a changed to tab 0
246 d and e changed to tab 1 and set to ignore (the field title says "obsolete")
696 a to tab 6
945 a to tab 9

Also, biblio.biblionumber Koha field needed to be linked to MARC 090c and biblioitem.biblioitemnumber needed to be linked to MARC 090d.

What is Koha?

In doing a little Googling on this question, I ran across a page that defines and also gives an interesting philosophical interpretation behind the word's meaning: http://solari.com/blog/?p=68 According to a native New Zealander quoted in Catherine Austin Fitt's Blog: Mapping the real deal, "Koha" is a Maori word, and a short definition " is "a gift brought by the visitor to the people of the land, often food or treasures, and it is part of the process of Manakitanga which defines the realm of hospitality or the sharing of information." I think the naming of this shared instrument for the organization of information sources is a nice touch.

Koha, in the cataloging sense, is the first open-source Integrated Library System (ILS). Open source=it is collaboratively created and updated and users help each other with problems. More specifically it is distributed under the General Public License (GPL). This license holds for the user:

• the freedom to use the software for any purpose,
• the freedom to change the software to suit your needs,
• the freedom to share the software with your friends and neighbors, and
• the freedom to share the changes you make. (from A Quick Guide to GPLv3 http://www.gnu.org/licenses/quick-guide-gplv3.html)
  

ILS= database based "modules for circulation, cataloging, acquisitions, serials, reserves, patron management, branch relationships, and more."

According to Wikipedia, there are several other open source ILS, but after a quick look at information on these, I think Koha may be the most user friendly, i.e. less specific technical knowledge needed. It is also widely used by libraries world-wide.

public display of item information

item type: see "random Koha bits" posting. Also, one exciting (have I been staring at this too long?!) breakthrough: I found information about the "Link to Field." In someone's comment for help they mentioned: "automatically copy [tag] to your new tag using the "Link to Field" feature. I used this field in the 952c and had it fill with the 942c. Then, when I created a new item by receiving, it both sorts by the item type in the bib record in 942c and shows correctly in the "item type" column. No information shows within the item record, but I think that it is pulling the information correctly! (unfortunately, I don't think these bibliographic framework changes update existing item records--just new ones. I think this is why I didn't think this worked previously--I was looking at existing item records)

branch location: It seems that this information is linked to the "holding branch" information in the items tab, unfortunately, the branch information added when receiving an order auto-fills to the "home branch" field. I don't know if this is a parameter that can be changed. Of course these fields are pulling information because of their mapping to the Koha fields: 952b/homebranch=items.homebranch and 952d/holdingbranch=items.holdgingbranch. I did try reversing the linking of the above Koha fields, but this of course just reversed my problem instead of fixing it.

I don't think any other combinations are possible (such as not using items.holdingbranch or using one of them twice because they all must be used and used only once). I also tried using the "link to field" to have the holdingbranch (what displays) just fill with information from the homebranch (what comes from the order info), but it didn't seem to work when I created a new item by receiving. I don't see any solution other than manually filling this information as each new item is created.

The search by branch option uses the information in the homebranch to sort (just like the auto-filled info from the order), but the display shows the information in the holding branch. If these two fields don't match, then a search by a particular branch may not work/make sense--why have both of these fields?! One thing that makes sense is that it shows more than one branch location when there is more than one item (associated with more than one branch).

Also, non-reservable items (reference/microform) have a (1) in addition to the branch abbreviation in the branch location column. I'm not sure what purpose this has, other than it is tied to being a "Not Reservable" item.

items: this is a running tally of how many item records are associated with a bibliographic record. It seems to me that since most of the existing items were not "ordered" & "received" that there is no item associated and therefore no information shows or it displays "on order." (ditto for why no location information, either)

random Koha bits

Information for sorting item type in searching comes from tag 942c because this is linked to the biblioitems.itemtype field in Koha. If one tries to link this Koha field to the 952c items instead it returns an error message because only Koha fields with the label item.____ can be linked to the items (10) tab. It also seems that the 942c field is used for sorting, but the information displayed in the public search display has the text from the 952c field. For example if one searches nonfiction books it will sort by this item type in the 942c field, but next to the book title in the public display it may say "audio recording" (952c field).

Question: does info in the order of an item (such as price etc.) transfer to the item information associated with a bibliographic record?

I created an order with brief bibliographic info (title/author). After I "received" the item, I edited the bibliographic record using the z39.50 search that auto-filled the bib record, "save and go to item"--and information that I had filled in in the order was already in the item fields (date of acquisition, costs). Additionally, when I used an already existing bib record and associated it to the order, there were two items, one that used the item information that I had filled in when I had created the bib record and one item that had all of the information from the order that I later created. I guess this makes sense, since a library may have more than one copy associated with the same bib record.

Revisit with 3.0 version: "Data Migration" in 3.0 manual

"Notices: Database Fields": I checked these suggestions for linking MARC fields to Koha fields. It looks like it is mostly set up to the specifications outlined. There are only a few suggestions that are not met that probably won't matter:
biblio.biblionumber link to 999c
biblio.serial link to 942s
biblioitems.biblioitemnumber link to 999d
biblioitems.volumeddesc link to 362a

Why is author not searchable in public display as an authorized heading, but subjects are?

I tried adding an added author in the 700 field (of a name already in the thesaurus) to see if this might shed some light. The name showed in the public display, but it was not linked to search on it, either. I didn't gain any insight from this experiment. The 650a tag is linked to the bibliosubject.subject field. I thought maybe this might be the key, but 100a (where the authorized author name resides) is linked to the biblio.author field as suggested in the manual. Is it somehow tied to information in the "System Preferences: Authorities"?

Koha breakthrough--I think...

So, I think I've figured out how to get the item type information to show correctly when searching--except for one record! Is it possible that one record could be corrupt?

Starting at the beginning, Koha has a MARC Check in the Parameters menu, and when I ran it, it gave me the error:
ALL item fields must:
*be mapped to same tag
*all be in (10) tab

I played with a few things relating to the 952 tag and(10 tab) that actually gave me more errors. I finally realized that the "ALL" meant all of the "item.____" Koha fields needed to be linked/mapped to a MARC field. One can see how these two different sets are linked in the "Links Koha-MARC DB". I went through and linked all of the "item.___" fields with MARC 952 subfields, even though many of the field/subfield titles don't really correspond/make sense between Koha & MARC. I just wanted to see if it would work--and it did! The MARC Check did not find any errors.

So, the item type info needs to be in only one MARC field (we have it in 952) and this field needs to reside in the (10) tab which is also the "Item" tab when editing. Also, "item.itemnumber" needs to be set to "ignore" (it is linked to MARC 952u).

I used the public display to search for records for each item type. There were still some items that displayed the wrong item type (even though they were sorted with the correct item type) and some items that displayed no info (even though they were sorted with the correct item type). It seems that the system is sorting using the 942 "item type" field, but that the display information is coming from 952 subfield c. I was able to fix the display for the items that did not display item type information when searching by selecting the appropriate item type in 952c.

I wonder if "item count" and "location" are also affected in this way.