Simon Hunt

My feedback

  1. 241 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    11 comments  ·  Alma » Other  ·  Admin →
    Simon Hunt supported this idea  · 
  2. 146 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Thank you for this ideas exchange request.
    For the purpose of clarification:
    Alma uses (among others) two levels of faceting the bibliographic records: Material type and Resource type.

    Regarding the Material Type: There are seven different distinct bibliographic material types in Alma, and this corresponds to the seven different distinct bibliographic material types used by the MARC standard. These MARC standards are explained at https://www.loc.gov/marc/bibliographic/bdintro.html under section “Scope of the Bibliographic Format”. Ex Libris will leave these distinct seven formats, and not add or subtract from them. This is because there are seven distinct formats in the MARC standard. For this reason we will not add another format or change the name of an existing format. Each bibliographic record has one bibliographic material type. The Material Type is considered “Music” if the LDR pos. 6 is one of the following: c d i j. This is explained in the Ex…

    An error occurred while saving the comment
    Simon Hunt commented  · 

    I agree that the Material Type index is largely worthless. However, the Resource Type index is much more granular, and is available as both an Alma search index and an attribute in the Bibliographic Details folder in Analytics. It has its quirks, but is much better for stats and other functions.

    Here's the documentation on how the Resource Type is calculated:

    https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/010Getting_Started/050Alma_User_Interface_%E2%80%93_General_Information/Searching_in_Alma#The_Resource_Type_Field

    (Cross-posted to Alma-L.)

  3. 24 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Alma » Other  ·  Admin →
    Simon Hunt supported this idea  · 
  4. 218 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Simon Hunt supported this idea  · 
  5. 57 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Simon Hunt supported this idea  · 
    An error occurred while saving the comment
    Simon Hunt commented  · 

    Holdings records in suppressed locations should be automatically tagged as suppressed so these values are indicated in publishing profiles and Analytics. This way, suppression indicators would function the same whether they are being published to Primo or another source.

    The presence of the "suppressed record" icon makes this even more confusing, since you can't tell if an individual record is tagged suppressed unless you open it in the MD Editor and look in the Tools menu (or run a report in Analytics).

  6. 38 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Simon Hunt supported this idea  · 
  7. 173 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Simon Hunt supported this idea  · 
    An error occurred while saving the comment
    Simon Hunt commented  · 

    I would expand that request to merge and indication rules as well. All three types can be used in import profiles, and it should be possible to write-protect individual rules.

  8. 12 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
  9. 91 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Simon Hunt supported this idea  · 
  10. 26 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Simon Hunt shared this idea  · 
  11. 69 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Simon Hunt supported this idea  · 
    An error occurred while saving the comment
    Simon Hunt commented  · 

    What appears to be happening - both with a normalization job and when a record is merged while importing - is that "new" fields (those affected by the normalization, or fields being added to a record via import merge) are placed below the "old" or unaffected fields in the record.

    For example, if your merge rules preserve the old 597 fields but replace all other 5XX fields, the final version of the bibliographic record displays the 597 field first.

    In AACR2, there was a prescribed order of note fields that catalogers applied, including how to order notes in repeated 500 fields. RDA rules simply specify that note fields should be arranged in numeric order.

    So, the placement of new/normalized fields at the bottom of the range violates both cataloging standards.

  12. 132 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Simon Hunt shared this idea  · 

Feedback and Knowledge Base