Stacey van Groll
My feedback
164 results found
-
0 votes
An error occurred while saving the comment An error occurred while saving the comment Stacey van Groll
commented
I believe this is because a provider has given that record metadata to Ex Libris in English.
There is the record in English from ProQuest, and this matches to the ProQuest source platform showing the record metadata in English and the article in Chinese: cdi_proquest_journals_1858231693
There is also a record which has Chinese metadata also, rather than English. This is cdi_hyweb_hyread_00440336 and I believe this is from the Chinese Electronic Periodical Service (CEPS).
If you search by the Chinese characters, the Chinese version record will be returned in Primo.
Basically, Ex Libris is presenting what the provider has given them, which does seem reasonable and right to me and is their standard practice to not adjust provider metadata.
They also don’t Match & Merge when there are language variations, which does seem right to be also as that could get very messy trying to merge such varying data.
Are you thinking that Ex Libris should add a detection factor during provider feed ingestion to identify if the record metadata is in English, but there is Language metadata stating something else like Chinese, and try to employ a translation service to transform the data to that language?An error occurred while saving the comment Stacey van Groll
commented
We have access to this example content via a CDI record from ProQuest, same as yours. The metadata is in English, and it has a Language display field of Chinese.
When navigating to ProQuest, I see this is replicated by the English metadata, Chinese Language indication, and the pdf in Chinese.
In looking around your site, I see that you have a Language facet but in a random check of your records I can’t see any Language fields displayed in records. When using this facet to limit to Chinese after doing a search by the article title, this record appears, Have you deliberately disabled the Language display field? If not, I think it is a defect that you are not seeing the Language display field, to make clear the article is in Chinese on the source platform.An error occurred while saving the comment Stacey van Groll
commented
Is there an example of this?
Whenever I have seen this, it has appeared to be explainable by match and merge of multiple sources and the full text source content reflects the same. For example, the title in English in the source but the article in another language and in the Primo record the title is in English.
Or is this asking instead for something like that Ex Libris step in to change the metadata themselves for the title to match the article language despite what the provider may have made available to them, such as by AI generative tools? -
2 votesStacey van Groll
supported this idea
·
-
3 votes
An error occurred while saving the comment Stacey van Groll
commented
I'm wondering about the nature of the solution and if it would be better enhancing the matching process en masse, rather than adding a mechanism for manual individual flagging.
Can you advise the situation with example, which Ex Libris states currently has no technical solution? One of those instances where I wish we could still see cases so I could look up the details myself!
Is it something like an aggregator which just randomly doesn't have a particular article?An error occurred while saving the comment Stacey van Groll
commented
This seems like a metadata issue to me that would be best reported with a request for metadata correction in CDI and/or Alma, to ensure CDI records are not marked as available online per Alma coverage information when this is not true.
It would be helpful to have the details from the stated cases to understand why the metadata correction is not possible. -
101 votes
An error occurred while saving the comment Stacey van Groll
commented
This seems like a defect rather than an enhancement, as Primo VE is marketed as indexing for changes within 15 minutes.
-
86 votesStacey van Groll
supported this idea
·
-
14 votes
An error occurred while saving the comment Stacey van Groll
commented
No disrespect intended as this is so beautifully detailed and clear as to this issue, but I am concerned that this would be in Idea Exchange. The premise of this platform is for enhancements, not for defects which Ex Libris has decided not to prioritise fixing.
-
92 votes
An error occurred while saving the comment Stacey van Groll
commented
Please be aware that hiding GES or service by Display Logic Rules still shows the details in the OpenURL Context Object, and only hides the details from UI.
-
3 votes
An error occurred while saving the comment Stacey van Groll
commented
I suggest to move this submission to the Primo Idea Exchange, as submitted to Alma Idea Exchange but solely for Primo functionality.
-
90 votes
An error occurred while saving the comment Stacey van Groll
commented
I agree this is very clunky for VE.
In Primo with BO, you can see all the information easily by frame source and adding &displayCTO=true, which I added as a bookmarklet to be triggered in one click.
In Primo VE, first you have to trigger Display CTO, which very annoyingly refreshes the display from the full record overlay to a full page, losing your place in the search results. Then the CTO display is still missing the Target URL. So then you have to find the Incoming URL, copy this, paste it into a doc, add &debug=true&svc_dat=CTO to the URL, copy the URL, paste it back into the browser. -
3 votes
An error occurred while saving the comment Stacey van Groll
commented
I agree that the current development is misleading and unclear. It is completely obvious that there is a user expectation immediately established that the presence of such a visual element indicates a user-generated change, regardless of by form, text, whatever.
And that this visual element being not present indicates no such change.
It feels like lazy development that this feature was not made complete to match this user expectation and the desirable outcome to have Alma clearly indicate all user-generated changes without having to constantly click to see this instead. -
5 votes
An error occurred while saving the comment Stacey van Groll
commented
I know it doesn't match exactly your idea as a premise, but perhaps just disable the field if it is causing so many problems for you?
If it adds no value, there is no point having it, so that is a factor you'd have to consider if it's useful to you at all for some use case.
We decided several years ago to remove it when it was a display field only which was meaningless and only caused staff confusion as to what they should do if it had passed.
We haven't regretted it for a moment. -
22 votes
An error occurred while saving the comment Stacey van Groll
commented
The 'Search inside' functionality should perform an advanced search by keyword + the ISSN of the record.
This should therefore not show articles from completely different titles, in not matching to ISSN.
I checked one at a VE site by "Search inside" keyword of teaching, and the outcome Advanced search was: Any field contains teaching AND ISSN contains 0022331XCould you perhaps provide an example where you have articles returned which are for other titles?
-
2 votes
An error occurred while saving the comment Stacey van Groll
commented
I agree that there should be personalisation options in this area to allow patrons to set their own defaults, and for consistency this should be in the Personal Details and Settings area.
This should be for all Primo customers, not just those using Primo VE.I also wanted to note that there are technically 'locks' available but they are not clear to a patron as only shown by the URL and not as a UI feature.
These URL based locks ensure that features such as Saved Searches correctly record the search state saved by the patron to their Favourites and for any records sent by weekly email for Saved Search Alerts.Expand toggle
• Initial search – no indication in the URL
• Once expand toggle is enabled, the following is added to the URL: &pcAvailability=true
• If the expand toggle is then disabled, the following is change in the URL: &pcAvailability=falseFulltext toggle
• Initial search – no indication in the URL
• Once fulltext toggle is enabled, the following is added to the URL: &searchInFulltext=true
• If the fulltext toggle is then disabled, the following is change in the URL: &searchInFulltext=falseIt is definitely clunkier than simply allowing users to set defaults, but technically you could suggest that a patron bookmark a URL directly into Primo after using the toggles as above to set the URL element, or to use their Saved Searches for this to navigate from there, and you can provide saved URLs also with this.
Not ideal, but at least it is some answer to give to upset patrons to workaround this UI issue. -
805 votes
Thanks for the examples - we will review them and discuss our options.
Best,
Tamar
An error occurred while saving the comment Stacey van Groll
commented
In February 2023 Ex Libris advised more sources of Peer-Reviewed information:
"In CDI, records are marked as Peer Reviewed if they are published in a journal that is marked as Refereed/Peer-Reviewed in Ulrich's Periodicals Directory (Ulrichsweb).
In addition to the journal-level indication from Ulrich's, CDI also provides a Peer Reviewed indication from few other providers’ source records: ERIC, Onepetro, Erau digitalcommons and Almandumah."Stacey van Groll
supported this idea
·
-
136 votes
An error occurred while saving the comment Stacey van Groll
commented
Hi - Best to submit ideas to the forum where the issue is expressed ie a suggestion for Primo functionality to the Primo Idea Exchange.
Note: Ex Libris moved the submission from Alma to Primo after I added this comment.But regardless I don't hold much hope as Ex Libris has consistently denied indexing for item level information due to impact on performance and the high load of indexing it would require for constant changes.
Even for barcode which was delivered this year, it could only be fulfilled by API call, not indexing: https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/38113540-barcode-search-in-primo -
2 votes
An error occurred while saving the comment Stacey van Groll
commented
If implemented, please fulfill as an addition, not a change.
We find creation date valuable, but would appreciate also to have updated date.
There should be no need to sacrifice one for another. -
3 votes
An error occurred while saving the comment Stacey van Groll
commented
I've tested this and they all work to change to display the service or not depending on the setting and resource.
Who told you they don't work and that it would be an enhancement to correct an in-system non-functioning feature? -
92 votes
An error occurred while saving the comment Stacey van Groll
commented
An excellent idea. This is one of the reasons we don't use this feature. It is needed not just for VE though, but for all Primo customers.
-
17 votes
An error occurred while saving the comment Stacey van Groll
commented
I live in fear of accidentally clicking a default radio button for this reason! Or for one of my fellow admins at our site to do this.
I've never gotten around to doing a case myself, but I wonder if anyone has and been advised by Ex Libris that this is actually an enhancement request as opposed to a defect?
It certainly seems to me to be a defect that you cannot unselect a default, and wonder what justification there would be for deliberately designing this into a product. -
64 votes
An error occurred while saving the comment Stacey van Groll
commented
I wish I had more votes spare for this. I support it both for giving Admins autonomy to manage this area, including by cutting down on time wasted with Salesforce cases, plus also it is ridiculous that the admin customer sees only the view full of codes that often do not match the actual outcome of change, and the vendor gets the lovely clearly well-designed UI. This is completely opposite to what it should be, though ideally both admin and vendor gets both.
I wanted to add another comment to note that the person I was talking back and forth with here appears to have deleted their account.
I would expect their comments to remain in place, but they are missing now.
So, it's looks like I'm having a bit of a crazy conversation only with myself, which wasn't the case.