• Article Type: General
• Product: Aleph
• Product Version: 18.01

Description:
Continuing to work on getting course reserves to work with Primo in Aleph version 20, and I have a series of questions about Union View:

1. From the documentation, we had been led to understand that using Course Reserves in v.19+ required use of the Union View setup. (Sys libs guide Course Reading and Reserves, section 2.1 "In addition to standard BIB library setup, the course Reading Library requires setup for a Union View library." Is this mandatory, or optional?)

2. If Union View is applied, the web-opac full display is set up to use expand_doc_merge_union_crs, with expand_doc_course in the PRE-MERGE section, and a line is added to tab_base.eng to set up a U-xxx30 logical base. If I set up the expands per the Union View instructions, I get useful results at a non-configured opac view, but our usual base stops working. Removing the PRE-MERGE and merge_union_crs and adding expand_doc_course to WEB-FULL fixes the ABC30 view for some records (question 3 is about the problem records). Does this mean that the Union View is not compatible with Aleph Publishing routines? I'm struggling to figure out how we could get tab_publish to work with the Union View base...

3. Stand-alone ABC30 records migrated from v.18 (such as 000051989) do not contain SID id's and do not show course information using our current set of expands. It appears that somewhere in the upgrade process, the identifying course header information was moved from these records to new abc30 records. These are linked via entries in z120 and z127, so it is clearly Union View related. Interestingly, the original record without the SID is the "preferred doc number".

In light of all of this, it seems we have two options, neither of which we fully understand:

* Try to "undo" all of the Union View configuration and processing and start over with ABC30.
* Try to get tab_publish to work with Union View, and configure U-ABC30 as the local base for Primo's click-through links into the Aleph Course Reserves OPAC.

4. Is there a potential downside to using the non-Union-View entries in WEB-FULL / WEB-FULL1 and pointing to ABC30 rather than U-ABC30 even though we've set things up as union view?

Resolution:
1. CR Union View is not mandatory.

2. Yes, the "U-" tells the system that this local_base is using Union View. The fact that you are using U-ABC30 for the OPAC should be irrelevant to this specification in tab_publish.

Note: If you have suppressed abc30 records, you should add an ABC30PUB base:

ABC30PUB Course Reserve ABC30 ABC01 ABC30 N alldocuments not wst=(suppressed or
deleted)

and point to that (rather than "ABC30") in tab_publish.

3. Yes, in the case where the xxx30 record is not connected to an xxx01 record, it is connected to an xxx30 "connection record". This is described in section 4 of the "System Librarian’s Guide – Course Reading and Reserves". See KB 16384-21412 for more. So the lack of the SID in abc30 doc 000051989 should not be a problem.

4. The effect of not using Union View in the v19-up Course Reserves is that an abc30 title which is connected to multiple courses -- and has multiple abc30 doc records -- will display multiple times in the Brief List display, once for each course it's connected to. (The point of the Union View is to bring these multiple docs together in a single display. One problem with this is the fact that the doc shows *all* of the courses / Instructors it's linked to -- undesirable when the user has searched for a particular course or instructor.)
I suppose when you specify a particular U-xxxx base in tab_publish -- and have expand_doc_merge_union_crs in the publish section of tab_expand -- it will extract just one copy of the doc with each of the locations as a separate field in the record.... But I have never tried this so I don't know for sure.
You can assume that setting up the data to support union view and running the jobs to create z120 and z127 entries won't have any undesirable effects on standard non-union-view representations of records.

• Article last edited: 10/8/2013