Support Custom TOMs / TOM Override
While there are many advantages to way that Polaris calculates TOMs, there are currently some significant limitations for differentiating between formats. 4K BluRays, Playaways/Yotos, and video game systems are all very difficult to distinguish from one another when using only the MARC fixed fields. Additionally, many libraries are expanding their collections with Libraries of Things that are usually coded as "Kit" or "Three Dimensional Object" rather than describing what it actually is. These bib TOMS are also now featured prominently in Vega Discover's rollups.
Over on the Sierra side, the options for bibliographic format can be customized. If a library wants to add a specific format, they can add those options to a drop-down list. This approach wouldn't transfer over to Polaris perfectly, but it could lead to a hybrid system where Polaris still calculates TOMs, but certain conditions would allow a custom TOM to be used in place of the calculated one.
There are a couple different ways that this could potentially work, but I'm currently leaning towards something like a TOM override drop down box that is configured in SA and displays in the bibliographic record. When an option is selected, the bib's Primary TOM will be them term that is selected. If it's left blank, Polaris will calculate the TOM as normal. Since it's configured in SA, libraries will still be able to control the terminology used and can supply the necessary format icons in the PAC files. Ideally, when records are exported, this gets converted to a MARC tag so that it can be reimported.
Other options could be a designated MARC tag that contains specific wording. When the TOM is calculated, the system will look within this MARC tag just as it looks in the fixed fields. Another option could be some kind of calculated logic that determines custom TOMs based on the attached item's Material Types. ("If all items are X then display Bib as Y").
Polaris' current approach for TOMs works really well for traditional library items because that info is readily available in the MARC fixed fields. But this process starts to break down with newer, non-traditional library items that MARC does not account for. And now with Vega Discover, the format rollups (arguably the most popular feature) highlight many of these issues that we've been ignoring.
Matt Hammermeister
shared this idea
-
Thomas Brenndorfer
commented
Type of Material (TOM) code for preloaded audio players (Playaways, Wonderbook).
007/00=c and 007/01=s [standalone device -- this code is the key one]
and
007/00=s
Label: Preloaded audio player
Order of precedence: rank it above "Audio Books" (abk). -
Liz Mason
commented
It would also be very helpful to us if we could define TOMS. For example, our Vision Resource library would like "Tactile Graphic" to display as opposed to "2 Dimensional Non-Projected Graphic" or "Three dimensional Object (Artifact)." This enhancement would be great for libraries that have unique collections.
-
Celia Mulder
commented
Agreed! The one that is particularly frustrating for us is the "three-dimensional object" TOM. This is how the materials appear in Vega Discover and it's not the description we want public facing.
-
Kurt Boss
commented
This is critical to recommending Vega Discovery for Polaris users due to rollups and holds on works that roll up together as book rather than board book, picture book, audio-enabled book, and so on.
-
scarlson
commented
YES. The library world is changing quickly, as far as types of materials that are being circulated.
-
Lynn Reynish
commented
Agreed! The TOM functionality is deeply frustrating.
-
Penny Ramirez
commented
The lack of flexibility in the TOMS has been a source of frustration since we migrated to Polaris, as many items had to be squeezed into a non-descriptive category. I would love to see this improvement, especially as we move forward with our Library of Things!
-
Thomas Vineberg
commented
We lend a lot of non-traditional items now. Please implement custom TOMs!
-
Jennifer Hoffman
commented
Definitely support this!
-
Paul Lightcap
commented
+1 for a MARC-based method which allows custom mapping that includes a local field/non-standard field which we can protect to prevent change/overlay, esp. for those using any record updates service to continually enhance their catalog records. A bit skeptical of a TOM override non-MARC field (essentially similar to what Sierra uses) since this requires a means to export into MARC as well as import in a way that can map through. Same worry for an item material type approach as this could fail if a library has slightly odd itemization practices, (e.g., let's say a book club kit with items for every book in the kit coded as books as well as an item with a kit type for the bag/kit proper). And, finally, a plug for ensuring however this is done can be successfully surfaced to any discovery product.
-
Amy Stults
commented
We have a collection of Vox Wonderbooks that would be easier to find and identify in the catalog if we had custom TOMs. While it's possible to use a combination of fixed fields and 006/007 to indicate the added sound characteristics of these, they display as audiobooks in the PAC because of the TOM hierarchy. If we leave out those fields, they roll up in Vega as regular print books. That is confusing to customers. A custom TOM would allow us to clearly identify them in the PAC as physical books with optional audio capabilities. As formats and carriers evolve, it's crucial to be able to represent their specific characteristics beyond the limitations of MARC.