Jan 25, 2009

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)

Jan 16, 2009

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"?

Jan 13, 2009

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.

Jan 9, 2009

Introduction

Hi, I'm working on a graduate assistantship, and I hope to use this blog as a way of keeping track of what I'm working on and to organize my thoughts. At this point in the MLIS program, I am focusing on cataloging and also academic libraries, but I'm keeping the options open! I've dabbled in graphic design of small marketing publications, and I am looking forward to relating this experience with the Internet Fundamentals class.