 |
April 2008 Volume 10 Number 2 Page 7 |
|
New and Improved! Standard Cataloging and Indexing Tables!Cover Story Features
|
The following article is brought to you by the xxx01, xxx60, and to some extent the xxx30 libraries, but not really by version 18. Cataloging Tables Those of us in cataloging have worked with standards for a long time – between the cataloging rules, MARC, and network (OCLC) requirements, this is not a new concept. Although sometimes a royal pain, standards allow us to share records, data, and problems according to a common understanding. We’re all in the same boat, using the same or similar oars. Now that we are finally through with migrations and major upgrades, we can take advantage of the standards which are possible through a shared system of tables within Aleph. The reader may not realize this, but even though we are all on Aleph, the migration period itself determined the tables you started with. Fredonia started with version 12 tables and the EXU training set; Oswego, Tompkins Cortland, groups 3 and 4 started with version 14 and EXU (and a SUNY template overlay); later groups on version 14 had USM tables (and a SUNY template overlay which had changed since the earlier versions); group 9 had version 16 with USM, but no SUNY template. This progression has always added a layer of complexity when trouble-shooting and also sharing information across campuses. Fortunately, we’ve had a period of time in a non-migratory mode when the OLIS can gain a deeper understanding of the Aleph table structure.There are many tables which have not been fully exploited, but could help all of us in our daily workflow. These tables can also help us adhere to SUNYConnect standards without a lot of angst. For instance, there is already in place a table which prevents someone from saving a record with an illegal (for SUNYConnect) STA value of “DELETED”; this table also prevents the cataloger from creating two 245 fields. But, this table also shows a raft of errors which aren’t major. Some sites have actually disabled the mandatory table because of the “pesky” errors. With version 18, “pesky” errors such as “tag 945 does not exist” are being corrected and should not appear. Another table which has not been fully explored is tab_type_config. This table allows for the creation of the virtual TYP field, which can be used to filter searches. The field is very much like the Multilis document type field and can be defined in the same way. Eventually (see below under Indexing), all sites on shared servers will be supplied with a tab_type_config which will consist of an amalgamation of the new version from Ex Libris, the older version which later implementations received, and additional selections from the few sites who have used the table. Additionally, the field will be directly indexed in both the browse and word indexes. There are also some sites which have created special tags for donors, selectors, fixed cataloging date, and other purposes. In some cases the tags for these are the same across sites, in other cases, the tags are unique to a site. These fields might be useful for everyone. To that end, the tags are being validated for all campuses on shared servers. In a few cases, the OLIS will decide which of two tags will be the standard tag – for instance, campus A may use “SEL” to mean selector and campus B may use “790”. In this instance, the OLIS will contact one of the campuses to run a global change on the tag. As with all standards, there are individual cases where a cataloging agency or a library has good reason to stretch the standard. Such stretching should still be possible with the new set of tables. The biggest advantage to having a truly shared set of tables is that if a problem is found at one site, then the correction can be provided for everyone very easily. Indexing Tables As we help each other on SUNY-LMS or LiSUG lists, a real aid to community sharing would be to know that we all share the same indexes, using the same codes and indexing the same elements. Problems which occur at one site could be corrected at that site and then the correction could be made at all other sites on a shared server. Unique indexes for an individual site could be created for all to use (or not). For instance, call number sorting and shelflisting has not worked properly at many campuses. As these have been reported via Footprints, the problems have been corrected. With version 18, all campuses on shared servers should expect their call number sorting and sheflisting to work properly. The clever reader will notice the use of the subjunctive mood in the previous paragraphs. In attempting to create a single set of indexing tables for the xxx01 (bibliographic) and xxx30 (course reserves) libraries, we encountered some difficulties, which are not insurmountable but will take time to resolve. The OLIS decided it was better to keep on the upgrade schedule, while still working on the indexes. Therefore, improved xxx01 and xxx30 indexes will not be applied until later in 2008. Despite this glitch, we are proceeding with new indexes for the holdings library (xxx60). These indexes will allow direct searching in the holdings library for data such as collection codes, call numbers, prefixes, etc. Prior to version 18, the way to retrieve a set of holdings records for manipulation was via p-ret-01 in the holdings library. As anyone with a large database knows, this can take an hour or more. Now, all that one will have to do is connect to the holdings library in the search database tab; search for the collection; save the file to the server; and your input file is created for other manipulation or reports. As part of the training package, the holdings indexes will be discussed. When the indexing problems in the bibliographic and course reserves libraries are resolved, then there will be a training module which will discuss those tables. The object of all these changes is to bring us all another step closer to the SUNYConnect concept of libraries within SUNY working together.
|
![[Image: Bobby Approved Logo]](approved.gif){kind=small}