Utilize data from multiple fields (LDR and fixed fields 006,007,008) in Primo VE resource type configuration
Related to a previous idea now marked as Completed
(see: https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/35488570-utilize-ldr-and-marc-fixed-fields-006-007-008-in)
The functionality introduced in the April 2019 release only allows you to specify ONE field in the source MARC record that contains the resource type that you want to map to the local resource type.
Primo VE should to be able to determine the resource type from combinations of data in MORE THAN ONE of the fields in the MARC record; i.e. fixed-field coding in the 006/007/008 field in conjunction with the LDR field.
This is particularly crucial for complex resources not coded as language material (LDR pos. 06 = a) as changing LDR position 06 to m for computer file or p for mixed materials changes the definitions of positions 18-34 in the 008 field.
Data in the LDR/006/007/008 fields cannot be assessed in isolation, but must be combined together in order to accurately determine the resource-type.
In Primo VE August 2020 we have added the option to add up to four conditions when defining custom resource type. With this we attempt to cover the need to define multiple conditions while keeping indexing performance time
See in release notes of August 2020 https://knowledge.exlibrisgroup.com/Primo/Release_Notes/002Primo_VE/2020/010Primo_VE_2020_Release_Notes
-
Kelley McGrath commented
+1 for the ability to use more than just LDR and fixed fields. We use 035 (to identify CKB records), 3xx, 5xx, 6xx and 9xx in our current back office rules.
-
Manu Schwendener commented
-
Stacey van Groll commented
I believe that the earlier idea referenced is incorrectly marked as Complete.
I have added a similar comment to this on that idea, noting that the content of the request was clearly for AND, and yet the development in-system is OR, in that only one field can be used.
In this way, it is also not correct that this functionality is marked as Complete on the Primo VE Feature Alignment page when it is also there as AND: "Local Resource Type Normalization for MARC Leader and Fixed Fields".
It is not right that a clear request can be submitted, be accepted and Planned with no indication it would be limited, and then the community waits for release six months, only to find that it is not what was asked for or what was promised.
Then the whole cycle starts over again with the idea here. -
Laurent Nabias commented
Hello
Thanks for your post. That is a very important idea. I gave three votes too.
-
Manu Schwendener commented
+1
-
Peta Hopkins commented
Great idea, but I’m down to 1 vote, and might need it to create my own new idea.
-
Nancy Babb commented
The ability to utilize multiple criteria (fields, subfields, etc.) in local resource type configuration is absolutely crucial; Ex Libris utilizes multiple criteria in default resource type configuration and this functionality should be expanded to local resource types. It is impossible to accurately configure useful resource types without multiple criteria.
-
Mike Rogers commented
This is an excellent idea, and I sincerely hope ExLibris implements this. Currently, in Primo BO users can utilize multiple fields and subfields from the MARC records to configure resource types. In Primo VE, it is currently only possible to utilize one subfield from one MARC field for creating new local resource types. This forces the user to essentially add a 9xx field with a pre-mapped subfield that matches a local resource type. We just spent two months re-mapping our resource types from Primo BO to Primo VE, and we still don't have it quite right due to the complexities of MARC data and the limitations of the tools at our disposal in Alma. Having the functionality that Emma describes will make it worlds easier for sites to map new local resource types, and also make it much more attractive for sites to switch from Primo BO to Primo VE.
In addition - I hope ExLibris considers making this more flexible/powerful by allowing the *entire* MARC record to be made available for resource type mapping. There are cases where we need to consider other fields as the 300, 5xx, 8xx, 9xx, etc. and not just the LDR and fixed data fields.