130 results found

1. Allow for an authority file to be addressed by different codes in $2 of various BIB fields

   In Alma the authority file, a subject or term stems from, is defined by the content of $2 in various 6XX fields. This code controls the F3 functionality, as well as the linking process and the various jobs like PTC. Each and every authority file is addressed by one specific code.

   In the German speaking countries we use an integrated authority file (GND), which amongst names and subjects, also includes genre/form terms. For historical reasons the genre/form terms in BIB field 655 are marked with the official LoC /MARC Genre/Form Code and Term Source Codes “gnd-content” and “gnd-carrier” in $2, while the terms are, as the code suggests, actually a subset of our integrated authority file “gnd”. The same goes for notated music terms in BIB field 348. These too are a subset of our integrated authority file and are marked by the official LoC /MARC code “gnd-music” in $2.

   Alma currently does not allow to link the above mentioned terms to said authority file, because the content of $2 does not exactly match the code for the authority file, which is “gnd”. This problem could be solved by allowing for different codes in $2 to address one and the same authority file.

   In Alma the authority file, a subject or term stems from, is defined by the content of $2 in various 6XX fields. This code controls the F3 functionality, as well as the linking process and the various jobs like PTC. Each and every authority file is addressed by one specific code.

   In the German speaking countries we use an integrated authority file (GND), which amongst names and subjects, also includes genre/form terms. For historical reasons the genre/form terms in BIB field 655 are marked with the official LoC /MARC Genre/Form Code and Term Source Codes “gnd-content” and “gnd-carrier” in $2,… more

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Metadata Management  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Save certain subfields from being overwritten via F3 and PTC

   When linking names, subjects etc. from authority files in various BIB fields, some cataloguing conventions require giving additional information in certain cases.

   One example for such a requirement, stemming from the German speaking countries, is to add the time and place of an auction when linking to the genre/form term “auction catalogs” in BIB field 655 (see attached screenshot). This additional information is, of course, specific for each BIB record and must not be overwritten or deleted, if at a later point in time either PTC processes said BIB record or a colleague invokes the F3 functionality.

   Since different subfields might be used for various types of additional information, based on the field number and the cataloguing tradition and/or authority file linked to, it would be sensible to allow to define specific subfields to be exempt based on the field number, but also the authority file in use ($2).

   When linking names, subjects etc. from authority files in various BIB fields, some cataloguing conventions require giving additional information in certain cases.

   One example for such a requirement, stemming from the German speaking countries, is to add the time and place of an auction when linking to the genre/form term “auction catalogs” in BIB field 655 (see attached screenshot). This additional information is, of course, specific for each BIB record and must not be overwritten or deleted, if at a later point in time either PTC processes said BIB record or a colleague invokes the F3 functionality.

   Since different subfields… more

   •  

   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Metadata Management  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Implement Checks on the Authority Heading Type for Institutions Using ID-based Authority Control

   Currently, when authority linking in Alma is based on ID rather than text, Alma does not check whether the authority heading type in the bibliographic record matches the heading type in the authority record. For example, Alma will link a 600 tag in the bib record for personal names with an authority record whose heading is in tag 110 for corporate names if their ID matches, even though Alma would not offer that option if F3 were pressed.

   We would like Alma to (1) avoid linking in such cases and (2) flag these instances in the authority control task list.

   We ran into this issue in the context of a migration from a non-MARC21 system, from where we still receive authority records that are mapped to MARC21. Initially, a certain sort of authority record was converted into personal name authority records (X00), which was changed later into corporate name authority records (X10). Consequently, we had to clean up instances where the authority heading type in the bib records does not match the heading type of the authority record.

   We had hoped to use the authority control task list to identify those instances where linking would fail due to a mismatch of authority types. However, according to Ex Libris, case 07775618, checking the authority heading type is only available for institutions using text-based authority linking.

   Ex Libris wrote: "The product manager thoroughly reviewed this case as a part of the issue handling and advised the designed behavior. The linking of direct ID authority is not dependent on specific heading types but is instead based on matching the 035 value of the authority with the $0 subfield of the bibliographic field. This means that direct ID authority linking does not involve additional checks for heading types. For example, it will correctly link a 650 field in the bibliography with a 110 field in the authority, as only the match in subfield $0 is considered. Similarly, any changes to the field tag in the linked authority record would not affect the field tag in the linked bibliographic record."

   We believe that adding checks on the authority heading type will benefit also other libraries that use ID-based authority linking.

   Currently, when authority linking in Alma is based on ID rather than text, Alma does not check whether the authority heading type in the bibliographic record matches the heading type in the authority record. For example, Alma will link a 600 tag in the bib record for personal names with an authority record whose heading is in tag 110 for corporate names if their ID matches, even though Alma would not offer that option if F3 were pressed.

   We would like Alma to (1) avoid linking in such cases and (2) flag these instances in the authority control task list.

   … more

   2 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. linked-data-powered sets and collections

   TL;DR: populate existing ALMA sets / collections infrastructure using retrieval of a list of LCCNs from an external URL to allow linked-data-powered sets and collections.

   Problem

   We've all seen the book displays that most physical libraries have in their high-traffic areas. These might be works by the in-house press, topical events, anniversaries of author's birth, etc, etc.

   In the digital space, there are shallow-functionality RSS feeds and then a yawning gap out to things that are typically called 'digital exhibitions' which are resource-intensive glossy displays.

   ALMA Collections can be used for digital exhibitions, but populating them is labour-intensive and slow.

   Concept

   It is relatively easy to use wikidata queries to return lists of LCCNs of authors which meet particular criteria. See https://www.wikidata.org/wiki/User:Stuartyeates/PeopleForBookDisplays for queries which display "people associated with an institution" "Writers of a particular genre" "Authors of a particular subject area" "New Zealand LGBTI+ people" "Māori people" and "New Zealand people born today / this month". The result set of these queries can be downloaded without as a TSV (Tab Separated Vector), which for a single-column result set is isomorphic with a white-space separated list of LCCNs.

   A method of populating ALMA bibliographic sets based on the holdings matching the LCCNs downloaded from an external source would hugely speed the making of these kinds of collections.

   Technical implementations options

   The simplest implementation would be a dialog to create a set of from a query URL, either an itimised set or a logical set (which would reload from the URL monthly or on demand). All the same set types and functionalities should be available. You'd need a drop down for which field to match against.

   A more sophisticated implementation might be uploading a CSV with the fields ID, CollectID, ParentCollectID, CollectName, CollectDesc, CollectionImage, LCCNsURL,... and having ALMA create a set for each row, retrieve the LCCNs and match to BIBs, load the BIBs into the set and create a collection (or reuse an existing collection if a CollectID has been specified) and populate the collection with the set and metadata provided.

   Possible complications (technical / ALMA related)

   • Very frequent retrieval of sets from an external source is likely to result in ALMA instances being blocked as bad netizens and needs to be avoided. In the very long term, if widely used, a clone of wikidata may be required; several organisations already maintain such things, refreshed weekly from the daily wikidata dumps.

   • The ability of anonymous third parties to update wikidata means that human oversight of public-facing changes in ALMA is needed.

   • There should not be any non-public or financial information here, but the connection probably still needs to be HTTPS not HTTP.

   • These URLs are VERY long because the entire query is in the URL; some pieces of infrastructure may not be prepared for such long URLs.

   • This being the corporate software, you’ll probably want a whitelist of hosts that you can connect to, similar to the FTP server list.

   Possible complications (wikidata / representation related)

   • Some concepts (LGBTI+, ethnicity, etc) are represented cumbersomely in wikidata, but by allowing any query this approach allows institutions to make their own choice among the options.

   • Some fields (dates of birth for living people, ethnicity, etc) are sparse in wikidata. Individual libraries are free to add / correct details for individuals they have sufficiently strong interest in and suitable sources on.

   • In theory it is possible to translate Library of Congress Subject Headings (P244) to wikidata main subject (P921) to bibliographic items. In my experience this does not work in practice due to excessive sparseness.

   • Wikidata representation of book banning is a work in progress.

   TL;DR: populate existing ALMA sets / collections infrastructure using retrieval of a list of LCCNs from an external URL to allow linked-data-powered sets and collections.

   Problem

   We've all seen the book displays that most physical libraries have in their high-traffic areas. These might be works by the in-house press, topical events, anniversaries of author's birth, etc, etc.

   In the digital space, there are shallow-functionality RSS feeds and then a yawning gap out to things that are typically called 'digital exhibitions' which are resource-intensive glossy displays.

   ALMA Collections can be used for digital exhibitions, but populating them is labour-intensive and slow.

   … more

   19 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. All MARC records in the Alma Community Zone should be sorted chronologically between MARC fields 500 - 899.

   The fact that the MARC fields between 500 and 899 are not sorted chronologically for all Alma Community Zone MARC records makes it difficult for us to use the “Collections” function in Primo.
   In the Collections function in Primo, we display the author on the overview page in addition to the title. The author is displayed via a small script in Primo. This script takes the “au” field from the PNX record of the title or, if “au” is not available, the “addau” field and displays the first value from “au” or “addau” in the title overview of the collections.
   Because the MARC fields are not sorted chronologically, we often have results that do not meet our expectations (e.g., because field 710 appears before field 700, the publishing house is shown as the author of the publication).

   The fact that the MARC fields between 500 and 899 are not sorted chronologically for all Alma Community Zone MARC records makes it difficult for us to use the “Collections” function in Primo.
   In the Collections function in Primo, we display the author on the overview page in addition to the title. The author is displayed via a small script in Primo. This script takes the “au” field from the PNX record of the title or, if “au” is not available, the “addau” field and displays the first value from “au” or “addau” in the title overview of the collections.… more

   • 

   33 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Arrow keys now 'stick' in fields in MDE

   When navigating through records in MDE, if you've previously typed anything in a field, you now cannot move out of that field using the arrow keys. It's not entirely consistent and sometimes does let you move out the field, while other times it 'sticks' randomly in fields you haven't edited at all, but in general it is extraordinarily inconvenient.

   I see using the arrow keys to move within a field was previously suggested as a feature, but even within that suggestion, the idea included the stipulation that if the cursor was already at the start/end of a line hitting up/down should then move to the previous/next field.

   When navigating through records in MDE, if you've previously typed anything in a field, you now cannot move out of that field using the arrow keys. It's not entirely consistent and sometimes does let you move out the field, while other times it 'sticks' randomly in fields you haven't edited at all, but in general it is extraordinarily inconvenient.

   I see using the arrow keys to move within a field was previously suggested as a feature, but even within that suggestion, the idea included the stipulation that if the cursor was already at the start/end of a line hitting up/down… more

   2 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Add Release Displayed Records in List to Record Actions menu and a keystroke combination

   In the metadata editor, the option to release all displayed records in the record list has only one button which is not accessible by a keystroke. This makes the action less accessible to different users, and is also challenging to document for library staff without including visuals.

   This button, with tooltext "Release displayed records in list," should also appear in the Record Actions menu in the section with other release records options. At minimum, the function should continue the current behavior of releasing the records in the selected records tab. Though it would be useful to have an option to release all records in all records tabs (e.g., MARC21 Bib, Holdings, DC, etc.)

   For accessibility purposes, this function should also have a keystroke shortcut, similar to the split editor having "F6."

   In the metadata editor, the option to release all displayed records in the record list has only one button which is not accessible by a keystroke. This makes the action less accessible to different users, and is also challenging to document for library staff without including visuals.

   This button, with tooltext "Release displayed records in list," should also appear in the Record Actions menu in the section with other release records options. At minimum, the function should continue the current behavior of releasing the records in the selected records tab. Though it would be useful to have an option to… more

   •  

   5 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Ability to add labels while creating set

   It would be very useful to be able to add labels to sets when they are created. Currently you have to save your set and only then you can add a label.

   1 vote

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Metadata Management  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. Add option to batch edit 852 $k and $m in Holdings through the Change Holdings Information Job

   Would love to see the option in the Change Holdings Information Job to be able to apply/remove/change a shared call number prefix or suffix on a set of records. This would greatly improve the efficiency of metadata management for collections of physical items.

   9 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. End date confusion

    Inconsistent formatting of dates in different places in Alma leads to confusion. Dates in coverage statements are fomatted mm/dd/yyyy but dates in other places, such as 'Creation date' or 'Modification date' are sometimes formatted dd/mm/yyyy. Ex Libris should start using a standard and consistent date format, namely, the ISO 8601 Date and time format, YYYY-MM-DD, see https://www.iso.org/iso-8601-date-and-time-format.html

    5 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. NR - Normalization rules editor -- fix display to ltr + use monospaced font

    1.
    Currently there's a problem with the NR editor when there are too many rtl characters (Hebrew, Arabic, etc.) in the NR, the whole display changes to rtl. This renders the NR unintelligible and makes editing it in Alma impossible -- you have to edit it outside Alma

    We would like the direction of the NR editor to be fixed to ltr regardless of the composition of the characters used

    2.
    We would like to have the NR editor use a monospaced font. This would make the code neater and easier to read

    •  

    24 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    Under Review  ·  AdminErez Shabo (Senior Product Owner, Ex Libris) responded

    Hello everyone,

    I’d like to share our plans to introduce support for XSL (Extensible Stylesheet Language) normalization rules. This new feature is designed to handle complex normalization tasks and offers the flexibility of a full programming language, enabling advanced data manipulation. It will complement our existing normalization rules based on DROOLS, preserving all of its current capabilities. 

    Would the addition of this new type of normalization rule address the requirement outlined in this idea?

12. Add the option to the item call number in the Table customization list

    Adding "Item Call Number" to the "Table customization" would be very helpful for us. Bib has holding call number, item call number. Item call number is also important to us, by the way, sort by item call number would make our job more easier. Thank you.

    1 vote

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. Add "search internal resources" option to MDE menu

    Our Acquisition staff's workflow is to create brief records at the IZ level for donations etc., when we bring it into the MDE to search for an existing full-level record we are only given the option to "search external resources". We'd like to be able to search internal resources (NZ records) within the MDE (find matches is limited and does not work in most cases--we often discover after we've brought in a record that it did indeed exist in the NZ).

    2 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. Index 532 field

    MARC21 field 532 should be indexed in Alma and Primo. This is important for accessibility notes.

    4 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Add Normalization Process to perform "Expand from Template"

    The "Expand from Template" offers an option to select a template and to expand the currently opened bib record in the Metadata Editor, supporting the options to Override, Add missing and add all.

    As a systems librarian, I would love to have an option to perform this action via a normalisation process.

    Currently, the only way to implement an expand from template via a normalization process is to translate it into normalization rules, which is rather tedious.

    If I could simply use the template in a normalization process, that would save me much time and effort.

    1 vote

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. MDE expand from template CZ records

    Alma currently doesn't have the ability to "expand from template" for Community records. The option will enable MDE users to use a template to apply multiple local extension fields to CZ records, minimizing the unintentional error of changing the CZ records for everyone.

    7 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Ability to sort subfields in holding records

    Currently, there is an option to sort subfields for BIB records, but there is no option to sort subfields for HOLDING records.
    As an administrator for Alma, it would be helpful to have the ability to sort subfields in holdings records. For example, I was adding a subfield 3 to 583 holding records via normalization rules and the subfield was added at the end of the holdings tag. I desired the subfield 3 to be listed first in the 583, but it was not possible to do.

    26 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. Add Alma support for microlanguages and language codes recognised by Library of Congress, including Austlang

    Alma’s support for Language for search indexing, facet, and display is hardcoded for 041 to the 3 digit MARC Code List for Languages.
    This excludes languages recognised by Library of Congress, such as Austlang languages which were recognised more than 6 years ago in 2018.
    This issue has been addressed in Primo in 2021 and 2022 with customer advocacy efforts, but remains a glaring omission within Alma.
    See details: https://igelu.org/primo-support-for-austlang-and-iso-639-3/

    The only option currently within Alma for searching this data is to use the keyword field to search by information such as C15, and then use the Language filter to limit to Australian languages (by MARC code aus).
    Even then, the Austlang language is not shown in the displayed metadata.
    Attempting to use the simple search Language field to query 041 metadata in Alma records when not on the MARC Code List is unexpectedly zero results.
    
    And for the advanced search Language field, Alma offers only a hardcoded dropdown menu of languages on the MARC Code List.

    Successful delivery of this idea would be:
    • Alma’s simple search by the Language field also returns results for all languages entered in the 041
    • Alma’s advanced search by the Language field also allows for text to be entered, and also returns results for all languages entered in the 041
    • Alma’s search results also displays in the Language field all languages entered in the 041
    • Alma’s Language facet also includes all languages entered in the 041 from results returned

    This is fundamental to reconciliation efforts to correctly recognise and represent First Nations peoples languages in the work of libraries worldwide, as well as hindering practical efforts by library staff to address past practices and report effectively on successful progress towards this in library systems.

    Note: This submission is related but not fully covered by https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/46338445-add-iso-639-3-microlanguage-names-to-alma-title-se

    Alma’s support for Language for search indexing, facet, and display is hardcoded for 041 to the 3 digit MARC Code List for Languages.
    This excludes languages recognised by Library of Congress, such as Austlang languages which were recognised more than 6 years ago in 2018.
    This issue has been addressed in Primo in 2021 and 2022 with customer advocacy efforts, but remains a glaring omission within Alma.
    See details: https://igelu.org/primo-support-for-austlang-and-iso-639-3/

    The only option currently within Alma for searching this data is to use the keyword field to search by information such as C15, and then use the Language filter to… more

    • 

    83 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    3 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. Suppress from Public Displayed on Export

    A field for indicating if records are currently suppressed from discovery should be standard on all exports directly coming out of Alma. Having this information directly available would greatly help in tracking data pulled from Alma without having to go into individual records first, or pulling a list from Analytics first to cross-reference.
    It seems to be a major component missing, especially from the Export (All Fields) list.

    4 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Improvements for the MDEs left pane

    The left pane in the MDE is a very helpful tool for navigation in daily business. With the following improvements it could be even more helpful:
    - Customization of the display of the different databases in all the tabs (records/templates/rules): it would be very helpful if one could select only the databases that are necessary for the daily work for display (example: I have in the record tab 14 different databases of which I only need 4, and one that I need is only accessible through the drop down menu); if a selection is not possible it would be helpful to be able to customize the sorting of the databases (which would help me in the above example to sort up the one in in the drop down)
    - Possibility to select records for release: it would be very helpful if one could select specific records in the list for releasing, because that is how most of us work with the list. Now we have to release the records one by one or all at once, which is not very helpful in daily business.

    The left pane in the MDE is a very helpful tool for navigation in daily business. With the following improvements it could be even more helpful:
    - Customization of the display of the different databases in all the tabs (records/templates/rules): it would be very helpful if one could select only the databases that are necessary for the daily work for display (example: I have in the record tab 14 different databases of which I only need 4, and one that I need is only accessible through the drop down menu); if a selection is not possible it would be helpful… more

    •  

    66 votes

    Vote Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close