Elizabeth York
My feedback
27 results found
-
5 votes
Hello,
We will reach out to Alexander Street, and ask for the metadata for this collection.
Thanks,
Tamar Ganor
Content Product Manager
An error occurred while saving the comment An error occurred while saving the comment Elizabeth York
commented
We heard from Docuseek that Alexander Street has "created a discovery file with Ex Libris." We'd like to double-check with Ex Libris to see, has Alexander Street provided this 4th edition file to Ex Libris, and what is its status in the process of being added to the CZ? Thanks for helping us understand how this is progressing!
Elizabeth York
shared this idea
·
-
203 votes
Hi Elizabeth, Katie, and everyone,
Thanks so much for sharing this idea!
From what I understand, it includes two main parts:
- Allowing institutions to edit the list of values in various fields, with a specific example being the “Implemented Authorization Method” field.
- Adding more fields and making them reportable in Analytics, along with a request for a flexible mechanism to support this.
Regarding the second point — adding a flexible mechanism is quite a complex change and could impact the timeline.
If you can point out around three specific fields that are most important to add first, it might be easier.
Looking forward to hearing your thoughts!
Thanks again,
Tamar
An error occurred while saving the comment Elizabeth York
commented
Hi Tamar,
Thank you for taking a look at this request! It sounds like part 1, making the select list values editable by libraries, might be possible, right? We certainly would be in support of this, and we hope it can be implemented!
As for part 2, adding more fields, I agree with Karen that we want any newly created fields to be available in Analytics. The reason I conceptualized this as a "create your own" way was I suspected each library would want to record different types of information and would have different fields they wanted. Personally, if I were to pick 3 fields to create (with the hopes that more could eventually be added in the future!), I would pick:
1. Accessibility note (in Access Information tab): a free-text field where we can record information about the interface's accessibility. Free text allows us to enter the varied information different providers may give us about accessibility.
2.Accessibility statement upload (in Access Information tab): a place to upload a files for VPATs or other accessibility statements provided by vendors. This should give us the ability to upload multiple files.
3. Usage Stats Type (in Statistics Information tab): I envision this as a select list (with values each library could edit) where we could select the type of usage stats we collect for each platform. I currently have a spreadsheet of all our platforms where I have a column with this information, and I filter on this column when I do usage stats gathering projects. I'd like to be able to have this information in Alma instead of on the spreadsheet. The values I have in my spreadsheet at present are COUNTER 4 Spreadsheet, COUNTER 4 SUSHI, COUNTER 5 Spreadsheet, COUNTER 5 SUSHI, COUNTER 5.1 Spreadsheet, COUNTER 5.1 SUSHI, Non-COUNTER, and NA. However, those are just the values that work for me--I wouldn't want other libraries to have to use my list. So, I really hope Ex Libris can also implement the "make select lists editable" feature (part 1) so each library can make their own list of values!
Karen suggested the use case of recording whether IP addresses can be updated via an admin account, must be updated by contacting the vendor, or are updated via the IP registry. I think these use cases could likely all be covered by the existing field, "Ip Address Registration Method," if you implemented Part 1, making select lists editable by libraries. Currently, this field has a select list where the values are "Online" and "Provider." If a library could choose its own select list values for the "Ip Address Registration Method" field, we could enter options like "Vendor Admin Account," "Contact Provider," or "IP Registry," which would allow us to more granularly record the different ways of updating our IP addresses.
Elizabeth
Elizabeth
Elizabeth York
shared this idea
·
-
157 votesElizabeth York
supported this idea
·
-
65 votesElizabeth York
supported this idea
·
-
85 votesElizabeth York
shared this idea
·
-
53 votesElizabeth York
shared this idea
·
-
30 votes
An error occurred while saving the comment Elizabeth York
commented
I want to strongly suggest that if this were to be implemented, this would need to be an option where libraries could select to either create portfolios before or after the normalization process.
There is a very good reason for portfolios to be created before the normalization process--when we import bibliographic records for electronic resources, we want their portfolio links to be created or updated, but we do not want to create 856 fields in our bib records. So, we have a norm rule to remove 856 fields from bib records, and this rule goes into effect nicely after portfolio creation/update. In Alma, access to e-resources is provided via portfolio links, not 856 fields. The portfolio link is what should be maintained and updated to provide consistent access, and Alma gives us great tools to manage our portfolios in batches in our electronic collections. We don't want to be creating 856 fields on our bib records, which would unnecessarily duplicate our portfolio links and be hard to maintain--we want to maintain our links to e-resources in our portfolios alone!
So, I ask Ex Libris, if you implement this, please do not make this a global change so that norm rules are applied before portfolio creation for all customers. If you do implement this, please allow customers to choose whether norm rules should be applied before or after portfolio creation.
-
42 votesElizabeth York
supported this idea
·
An error occurred while saving the comment Elizabeth York
commented
I voted for this request, but I'd like to note that many libraries do not use Cloud Apps due to security concerns or technical limitations of the apps, so as part of implementing this idea, I suggest the option to update electronic-collection level linking parameters should also be built into the Change Electronic Collection Information job in Alma.
For context, I'd like to share the link to the November 2024 release notes that made it so customer linking parameters are configured at the electronic collection level for CDI database collections: Possibility to Define Linking Parser Parameters for Database Collections in Collection Level to be Used by CDI Direct Linking: https://knowledge.exlibrisgroup.com/Alma/Release_Notes/2024/Alma_2024_Release_Notes?mon=202411
-
107 votesElizabeth York
supported this idea
·
An error occurred while saving the comment Elizabeth York
commented
In response to the Anonymous comment on what should be done if multiple licenses apply to a book (i.e. a book is both owned and in an EBA)--following the precedent of the ProQuest Ebook Central autoholdings integration, there should be a series of checkboxes in the portfolio, one for each access model (owned, subscribed, in DDA, etc). If a book is in multiple categories, multiple checkboxes should be checked.
-
10 votesElizabeth York
shared this idea
·
-
38 votesElizabeth York
shared this idea
·
-
62 votes
An error occurred while saving the comment Elizabeth York
commented
I support this idea, as it would help address the confusing cases where a resource is available OA on one platform, but it is behind a paywall on another platform. The portfolio-level indication would accurately show whether that specific portfolio is available openly or not.
This idea would also help address cases where some (but not all) of a journal coverage range is OA. The bibliographic record OA indicator is not granular enough, as it does not show which parts of the journal are OA. A portfolio-level indicator could show whether that specific portfolio and its coverage ranges are OA or not.
Elizabeth York
supported this idea
·
-
45 votes
An error occurred while saving the comment Elizabeth York
commented
This is a good idea! Here is another use case: sometimes, a provider updates their parser parameters but fails to update their service parser, so all the parsers break. As a temporary fix, we need to locally override the service parser parameters to work with the new portfolio parser parameters. At present, we have to manually edit every affected service's parser parameters. With this job, we could manually override all the affected collections' service parser parameters in bulk.
Elizabeth York
supported this idea
·
-
2 votes
Hello,
We will reach out to Jove and ask for the metadata for these encyclopedias for CDI.
Kind regards,
Tamar Ganor
Content Product Manager
Elizabeth York
shared this idea
·
-
32 votes
Hello,
We are working with the provider to obtain MARC records to enrich JoVE collections.
Kind regards,
Tamar
Elizabeth York
supported this idea
·
-
50 votes
An error occurred while saving the comment Elizabeth York
commented
It's important to remember that the collections used for Autoholdings aren't just used for Autoholdings—they're often the vendor's "All Titles" collection, so institutions that don't use Autoholdings are often using them too.
So, if this idea is implemented, please don't just add a fixed "autoholdings" label onto every CZ collection that can be used for autoholdings, as that would be confusing to all libraries that are not using autoholdings. Instead, if an institution has set up autoholdings, part of the autoholdings setup could be flagging the collection in which the autoholdings are deposited as a collection where autoholdings is in use. This flag would only appear if a library had set up autoholdings for a collection.
-
46 votesElizabeth York
supported this idea
·
Elizabeth York
shared this idea
·
-
7 votesElizabeth York
shared this idea
·
-
40 votes
An error occurred while saving the comment Elizabeth York
commented
I'd like to note that it is possible to make many linking parser parameters changes for multiple collections at the same time using the Change Electronic Collection Information Job, including setting the parser and parser parameters. That being said, the example given in the Idea Exchange Request, swapping out the ProQuest ClientID is not one of them (probably because the job only includes fields common to all collections, and different services require different IDs). I'm not sure if Ex Libris could make it possible to batch edit the ID fields that are not common to all collections/services. If they were to implement such a feature, I would hope they would add it to the Change Electronic Collection Information Job too.
-
51 votesElizabeth York
supported this idea
·
Elizabeth York
shared this idea
·
.png){kind=link}
Hi Tamar,
I was wondering, have there been any updates on this collection? Docuseek said Alexander Street told them they had "created a discovery file with Ex Libris," so we're hoping this collection will be available soon to activate in the CZ!
Elizabeth