Home » Posts tagged 'serials'

Tag Archives: serials

Help!

Problem? Check out the OLS Knowledge Base or open a ticket by emailing support@cuny-ols.libanswers.com.

Aleph Item Process Status: Bindery status

The Aleph Item Process Status (IPS) in Aleph is sometimes misunderstood, as it is sometimes (but not always) more than a display field. The functionality built into some of the IPS is complex, so it will probably be best to approach them separately. Let’s please take a look at the Bindery related statuses:

BD   At Bindery        
BP   In Repair             
PB   Binding Preparation     
SB   Sent to Binding

While these statuses are not assigned by every CUNY library in the same way, we know that all four cause items to function in Aleph the same way. In Aleph, they block items from being CLICS eligible. They suggest that the items are not readily available. (The only difference between these four is the screen display text.)

These IPS will all migrate to our new LSP in the same way. These Aleph Item Process Statuses will ONLY appear as a comment on the items for staff to see – assuming that they look up each individual item. These comments will give no indication to patrons that these items are not actually available on the shelf. Also, the items would follow the circulation policy of their collection. For example, patrons could suddenly place holds for these items, if they are in a request-able collection.

I discussed the following plan with the Director of our new LSP’s Data Migration Services. She concurs that the below is probably the best method for migration of these particular statues. (She has a history of work in our new LSP, as well as with Aleph.)

It would be recommended to set up in Aleph a collection called “Bindery,” or some similar verbiage of your library’s choosing. The on screen description should indicate as intuitively as possible to patrons that the items are unavailable due to being out for re-binding or repair.

Next, all of these items should be placed in this location of “Bindery” as a temporary location. The Aleph Item Process Status should then be removed BEFORE we migrate to Alma. When the item returns to the library at some future date, one only needs to remove the temporary location check box. The items will revert back to their permanent location as listed in the holdings record.

An added benefit is that this will also work well in our current Aleph environment. It will communicate clearly to patrons that items are temporarily unavailable, or at least not available now. Reverting back to a permanent location (in Aleph) this can be done manually or as a batch process. (In Alma, you can also set the temporary location to automatically expire at a pre-selected date.)

This would not apply to all Aleph IPS. Some are very much more than just a display field. There is software functionality tied to the Item Process Status. We will not want to lose that functionality in Aleph, nor in the new LSP. For example, we would specifically not want to use a temporary collection location for misplaced (missing, searching, lost, etc.) items.

Related topic: Aleph IPS – New Book

Serials order record clean up

Libraries are now working on clean-up of Serials order records. An open serials record not attached to a Bibliographic record is not going to have a clear purpose when we eventually migrate. It is also unclear today for staff working in Aleph.

At one library (just before Thanksgiving 2017), we found 262 open serials orders. Of those, 154 orders are not attached to a Bibliographic record. The order creation dates range from 1994 to 2008. Setting those orders aside, this leaves 108 orders (41%) attached to a Bibliographic record where there is a clear journal title.

Now, we know that those ‘unattached’ orders were not all for budget transactions. We do not know which are the ones still being used as a dummy record.

For an order used for ordering / budget transactions purposes having an attached Bib record (with STA=SUPPRESSED) provides better identification. Since it is a suppressed record, never to be displayed to patrons. It would be more direct and maintainable to keep track of how the orders are intended to be used. Anytime staff look at a record to figure something out, people will want to naturally look at the title.

Consider the purely hypothetical record, with

STA	SUPPRESSED
245	Ebsco Melbourne Scholars Package

Without knowing anything else about this example, you already know what the record’s purpose is.

Also, the Bibliographic record should have a brief holdings and item record. The Item record should be set to Item Process Status = NA (not arrived), SU (suppressed), WD (withdrawn), or CA (Order Canceled). These are the Item Process Statuses that will result in the ‘Title’ being suppressed from patron view.

WD might be a good idea if you do not want the record to be migrated, but this would also depend on how you weed Bibliographic records that have these statuses. It will have an implication depending on which software we use to replace Aleph. If you do not weed by IPS, then it frees your hand in choosing an appropriate IPS.

Orders being closed should be marked as Order Status = ‘CLS,’ Invoice Status as ‘Complete,’ and depending on the type of order as ‘Arrived.’ One would also want to look at any related Subscription records. (No reason to show items as still being expected then they are not.)

Please contact OLS for help with specific questions.

How is the “Journal” filter in OneSearch populated?

When you click on the “Journal” facet after doing a search, it almost always displays about 20 journal titles. However, in a search with thousands of results, you are obviously retrieving many more journals than that. And it doesn’t look like it’s the top 20 journals, either, because some of the hits for the same title are quite low. So what’s going on?

Most facets are created dynamically from search results. The 200 top-ranked records in a search result are used to create the list of facet values which will display in the “Expand My Results” section. All hits in the search results for those values are counted and the number is displayed in parentheses to the right of the facet value. So, really, it is not the 20 most common journals in the result, it is (at least in theory) the 20 most relevant journals.

Furthermore, the “Journal” facet includes newspaper titles, too, since it’s really a category consisting of serials. The resource type “Newspaper Articles,” on the other hand, refers to just articles within newspapers and “Articles” refers to articles in journals and other periodicals. Material types depend on the way the content is cataloged, whether it is by local catalogers (in the CUNY Catalog and CUNY Academic Works) or by the vendor (in the Primo Central Index).

New in OneSearch: Journal Issue Filtering

Problem

Years of journal issues can be impossible to wade through when trying to locate specific issues.

Solution

Filters on Location, Year, and Volume.
This tool was already available in the CUNY Catalog and has now been added to OneSearch, too.

Now, when there are sufficient issues to make filtering useful, filters will be offered above the issue list, as seen below (to view issues, open the “Locations” tab):

OneSearch Issues Filter

Source

This filtering, both in the OPAC and in OneSearch, is based on three Aleph item fields:

  • sub-library
  • volume, aka Enum.Level.1(A)(Vol.) or enumeration-a
  • year, aka Chron.Level.1(I)(Year) or chronological-i

Missing Filters?

There are two situations in which filtering may appear incomplete.

  1. missing volumes and/or years
  2. missing filter selection boxes

1. Missing Volumes and/or Years

If you select volume 181 in the example above, it appears that Baruch does not own the issues. However, if you select the year 2008, the result clearly shows that Baruch does own volume 181 and the issues are listed.

This problem is caused by an empty Enumeration Level 1 (Volume) field in Aleph:

Aleph GUI Screenshot, open to record 637363, showing item's "Serials Levels" tab

This is an example of how enhanced software and search capabilities make consistent cataloging more important than ever.

2. Missing Filter Selection Boxes

This is not actually a problem. Filters do not display for all periodical results.

Filters appear when there are sufficient issues to make filtering useful. The exact threshold (number of issues) at which filters are offered is not documented, but testing shows that the lower limit is definitely greater than four. In one example we found during testing, there are two locations – one with two issues and one with five issues. In this case (two locations, total of seven issues), the filters do display.

Also, if there is only one location or one volume or one year in a record, then that individual type of filter (location, volume, or year) does not display.

Behind the Scenes

The metadata cataloged in Aleph gets communicated to OneSearch in XML format. This is the item record for the record mentioned above, showing the underlying data structure (note the empty enumeration-a field):

<item>
<rec-key>000637362006890</rec-key>
<barcode>31716004953919</barcode>
<sub-library>Baruch Periodicals</sub-library>
<collection>PER</collection>
<item-status>02</item-status>
<note/>
<call-no-1>$$hShelved$$iby title.</call-no-1>
<call-no-2/>
<description>v.181 (2008:May-June)</description>
<chronological-i>2008</chronological-i>
<chronological-j/>
<chronological-k/>
<enumeration-a/>
<enumeration-b/>
<enumeration-c/>
<library>CUN50</library>
<on-hold>N</on-hold>
<requested>N</requested>
<expected>N</expected>
</item>

 

Archive

March 2024
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031