Primary and Secondary Title Discussion

Background and Problem:

Whilst uploading MARC records and performing title merges in the portal, it has come to our attention that there is a problem that must be addressed concerning primary and secondary titles. Currently, a MARC record title in the portal can be designated either as a primary or secondary title for an item. Each item can have only one primary title associated with it. Additionally, a title cannot be "orphaned," meaning it has no items associated with it. As the current search function works, only primary titles are by default searchable. Each MARC title in the portal must have at least one item associated with it for which it is the primary title in order for that title to be searchable in the portal.

This distinction is important for title merges, because the way a title merge works is that more than one title is associated with the scans for that title, but one of the titles is then made primary, while the second (or third, fourth, etc.) are made secondary. Thus, since secondary titles are not by default searchable in the portal, users entering the title as their search term will get only one hit for that title in their search results - the title designated as primary.

This distinction is a problem, however, when considering the case of series and serial runs which also have monographic records for each item in the run. In this instance, BHL members want to be able to upload both records (the monographic and the serial) and point both records to a single scan. However, we want both the serial title and the monographic title to be searchable by the user.

In other words, we want a user that has a citation for a book as a monograph to be able to enter the monograph title into the search box and get the search result of that monographic title, but another user having a citation for the same item as a serial to be able to enter the serial title in the portal and still get a search result hit for the serial run, through which they can access the volume they want.

Additionally, if we have an instance of a bound with, we want to be able to associate the title of each independent piece bound together with the one item and have a user be able to find either title through their search. The current primary/secondary relationship does not allow for this.

Thus, in summary, our problem is:

• We want to be able to associate more than one title with a single item and have all titles associated with that item be searchable when necessary, while also having the ability to choose to have only one title searchable (as would be required in the case of a title merge).

While we do not know exactly how to solve this through coding, we have come up with two possible suggestions for how this might be accomplished.
- matt707 Dec 15, 2009comment 12/15: yes, serials title merges, also the whole host of serials related title scenarios: changes, absorptions, sectioning out, un-sectioning, title changing for one year then returning to the original title the next, being able to satisfy our users and ourselves, some of who see title changes as pivotal, others who consider the latest title as an umbrella; and all of the complex related title scenario searching neccessities therein involved.

Proposed Solutions:

Solution One: "Dummy" Place holder to retain searching option.

As a first solution, we suggest that, since, for each record, only one item must designate a title as the primary title in order for the title to be searchable, for titles that have many items that need to be associated with two records (say a serial record and a monographic record), a "dummy" item is created that can be associated with one title (say the serial title), and for which this title can be designated as the primary title.

(In other words, a "volume 0" item could be created and associated with a serial run record. It could have this serial run record be designated as the primary title for this dummy record. All real items within this serial record could then be associated with this serial title record as the secondary title, and their monographic record counterparts could be designated as the primary record).

This would allow both titles (such as the serial title and the monographic title for each item) to be searchable to users.

While this is a solution we have come up with, it would be important that the "dummy" record be made invisible to users, so as not to confuse them about the item. **Furthermore, this only solves the problem if the item only needs to be associated with two titles. When an item needs to be associated with more than 2 titles, this system no longer works.

Solution Two: "Searchable vs Non-Searchable" option

As our second (and preferred) solution, we suggest that the language "primary" and "secondary" titles be removed altogether, and the language and concept instead becomes searchable vs. non-searchable.

We envision the system something like this:
All item currently have a section on the item screen that displays all titles to which that item is associated. Here is where you can designate one of the titles as primary. We propose that the option to choose primary title, and by default all remaining titles as secondary, be replaced with check boxes labeled "searchable." Each title associated with that one item that BHL staff want users to be able to search for could then be checked, and each title that should not be searchable can be left unchecked. Thus, in the case of title merges, BHL staff can check the box for only one of the titles, thus allowing only one record to display to users who search for that title. However, in the case of series, serials/monographs or bound withs, BHL staff could check all of the boxes next to each title to allow users to search and get a hit for any of the titles associated with an item. Because this would allow us to associate as many titles as necessary with an item, we feel this is the best solution.

Remaining Problem: Navigation - User understanding - Labeling -

While the proposed solutions offer potential fixes for the primary/secondary title situation, there is still a problem associated with this situation that these proposed solutions do not address. That is the case of the "bibliographic information" option that is located in the drop-down menu when a user is viewing the scans of an item. Currently, that "bibliographic information" option takes the user back to the title record that is designated as "primary" for that item, regardless of whether it was the primary or secondary titles from which the item was accessed. Thus, we must either find a way to make the bibliographic information option take the user back to the title record from which they accessed the scan, or come up with a standard for what we want the bibliographic information button to return the user to (such as in the case of serials and monographs, always return the user to the monographic record screen when the user clicks on bibliographic information. This will not work, however, for the case of bound withs, when the two titles associated with an item are actually not at all associated with each other, and thus there would be no logical reason for a user to access the book under one independent title and be taken back to a completely different title if they click on bibliographic information).

Hyperlinking. In the future, we also need to discuss a way to have all "related titles" listed on a bibliographic page hyperlinked to their title record counterpart in the portal. Currently, this hyperlinking, if not ingested as such, must be manually performed, and this is time consuming and impractical for, say, a serial record with 500 items that are also monographs. In this case, we would want all of the monographic biblio pages for these items to have the serial title record articulated in the "related titles" field, and we would want that serial title to be hyperlinked to the serial record in the portal. For 500 items, this cannot be done manually. While this is a slightly different topic than primary/secondary, it is still a topic that must be addressed in the future.

Down the Road:

Screen design - what text needs to be modified in the results screen, the brief display, and the drop down box
Hyperlinks - navigational keys to get the user from title to title in these complex relationships

See also Problem Titles page for a list of selected titles that may be affected by this

Conference Calls

March 3, 2010 Conference

Action Item summary:

• Bianca:
  • To doodle call for end of March
  • To take broader search implications to CiteBank group
  • To create "search wishlist" that addresses broader search & discovery issues for BHL in general...+ CiteBank as BHL gateway/front door?
• SIL folks:
  • Once Mike does itemID association, to do work around portal edit for Fieldiana Zoo as primary
• Mike L.:
  • to associate itemIDs in spreadsheets for Bot and Zoo Fieldiana to titleIDs in the portal
  • to look into allowing a MARC record designation for portal editing
  • to consider how to address "search & discovery" aspect/module to separate from primary/secondary architecture
• Field:
  • To add titleID column to spreadsheets
  • To upload records for additional Fieldiana series that aren't in the portal
  • To upload monographic records
• Joe:
  • To continue working on the Memoirs of the MCZ until it can be further addressed as with Fieldiana example