Name:
We're going on an adventure- the unique package ID is on its way
Description:
We're going on an adventure- the unique package ID is on its way
Thumbnail URL:
https://cadmoremediastorage.blob.core.windows.net/95f67087-cc72-497e-904d-6fc77e40d3e9/thumbnails/95f67087-cc72-497e-904d-6fc77e40d3e9.png?sv=2019-02-02&sr=c&sig=YRwf6Ck1smfwkUK8wGmQx1PW2NoarcYtIj2OShcxr%2Fc%3D&st=2024-11-11T19%3A04%3A34Z&se=2024-11-11T23%3A09%3A34Z&sp=r
Duration:
T00H22M44S
Embed URL:
https://stream.cadmore.media/player/95f67087-cc72-497e-904d-6fc77e40d3e9
Content URL:
https://cadmoreoriginalmedia.blob.core.windows.net/95f67087-cc72-497e-904d-6fc77e40d3e9/We%27re going on an adventure- the unique package ID is on its.mov?sv=2019-02-02&sr=c&sig=UNe5xBXfVW3sI4zg29pRiBjPkXD9I%2FuAq9%2B9Jy3oPCQ%3D&st=2024-11-11T19%3A04%3A34Z&se=2024-11-11T21%3A09%3A34Z&sp=r
Upload Date:
2022-08-26T00:00:00.0000000
Transcript:
Language: EN.
Segment:0 .
[MUSIC PLAYING]
AMY CASTILLO: Well, welcome, everybody. Thank you for joining us on the session. You're at We're Going on an Adventure-- the Unique Package ID is on the way. I am Amy Castillo. I'm going to be moderating the session. Today, our speakers are Athena Hepner, who is the discovery services librarian at University of Central Florida, and Christine Stohn. She is the director of product management for discovery and delivery at Ex Libris.
AMY CASTILLO: So I'm going to turn it over to Athena.
ATHENA HEPNER: All right. Let me get my screen share set up properly. And all right. So today, I'm going to be talking about a unique package IDs, and they are on the way. And we can say that now because there is a working group that is being formed. So we're very excited about that. So I'm going to be talking about the librarians perspective, but to set that up a little bit-- so first of all, what do we mean by package identifiers?
ATHENA HEPNER: And what we want to have is the same ID for a given package across all ERMs and knowledge bases. And we want it to be unique, persistent, and structured, ideally. So that's the idea behind this, and it would be used widely, hopefully. We want to use it anywhere it could increase clarity and support automation, so there's a lot of different places that could be.
ATHENA HEPNER: In ERMs to label KBART files on invoices, licenses, et cetera. So a lot of potential uses that would help us librarians, and probably others as well, understand exactly what we're talking about in different contexts. Different places where we talk about packages. So a librarians perspective. Let's launch into that. So as a eResource librarian, or any librarian regardless of their title that deals with eResources, you might be facing some of these problems.
ATHENA HEPNER: When you get your invoice, and you need to match it with what you're going to turn on for access in your discovery service, or match it to different statistics-- things like that. So you need to match your license to your knowledge base in your ERM. You need to match your invoice to the ERM. You'll also see that sometimes there's multipart databases, or packages.
ATHENA HEPNER: And I'll show some illustrations, examples of this. And then you might end up having to migrate too. And then, having a consistent name for a package across the different systems just doesn't exist right now. So if I'm looking at a Ex Libris product versus an EBSCO product for discovery layers, or for open URL resolvers. How they refer to different packages is going to not be the same.
ATHENA HEPNER: So it really gets confusing for librarians trying to know what to turn on, and is this the same thing here as over there. So let me get into some specific examples. So here I'm looking at an invoice that I've received. This is an EBSCO formatted invoice, and I don't mean to pick on EBSCO because this would be a problem, regardless of which subscription agent I might go through.
ATHENA HEPNER: So I have this invoice, and it's telling me what package it is. And then I have a list of titles with some information. It tells me I've got 37 pages to list all the titles that come in this package. And there's 249 titles that I'm dealing with on this particular package. So a medium sized package for us. I have here in the knowledge base, and again, I'm looking at an EBSCO holdings in linking management.
ATHENA HEPNER: And I'm not picking on them. I would have the same problem if I were looking in Alma's collections list. So you have the vendor name. That's great. And I can try and match that to what I have on my invoice, but then I have all these packages within the vendors. So there's 161 packages from them enrolled, and they all have different names.
ATHENA HEPNER: A whole bunch of them have different title counts available. But none of these title counts match what I have on my invoice, and none of these names exactly match what's listed on my invoice. There's a bunch of them that have specific initials after. They're probably for Consortias. And then, I have to try and figure out which of these is the best match for my particular invoice.
ATHENA HEPNER: And then, which of them is going to have the same date ranges available that I have licensed for access. So it's kind of a mystery, and I would have to open these up, and look at the specifics of each title list to see if it matches my invoice. Obviously, that's a lot of work, and then multiply that by a whole bunch of different other journal packages we get. And then, there's some cases where we get licensed content year-by-year.
ATHENA HEPNER: So what's exactly in the package changes every year. So we have been subscribing to Wiley for at least 20 years. And I would have to turn on each of these years, and then it's going to show when my users go into my discovery layer. And they run across an article that is from Wiley-- if they're looking at a Wiley journal, it may show a whole bunch of different Wiley entries as turned on.
ATHENA HEPNER: If that journal has been in that package for, say, 10 of the 20 years, it may say, Oh, yeah. This journal is covered with that date range. It's included in these 10 different packages. That's confusing. Confusing for users, confusing for librarians. And then, we have problems with database selections too. You'd think they'd be more straightforward, but they can be just as confusing.
ATHENA HEPNER: When you have abin form as the thing listed on your invoice. And the thing listed in your database list, but then I go to turn on, what is it that I get in this aggregator package. What do I turn on. Do I turn on the whole collection? Do I turn on like the complete, so there's different number of titles available in each of them. And it's not really clear which one exactly matches what I've subscribed to.
ATHENA HEPNER: All right. And then, multiply that across all of our databases and all of our journals over a number of years. So I have a million titles that I'm managing, a 1,500,000 titles I'm managing in our knowledge base. And that's thousands of packages, and hundreds of different vendors. So it's just a lot of work. And then I mentioned before migrating, that it's really not straightforward.
ATHENA HEPNER: You have to try and take all of the work you've built up over the years, selecting the right things, and figure out how to apply that in a new setting with different names. So what if we had a package ID? What would that look like if we had this wonderful tool to navigate through these different settings? So imagine if I had this package ID on my invoice, and then I went into the knowledge base and found that package ID listed.
ATHENA HEPNER: I could know exactly which of these emerald packages was the one that I licensed. So this is imaginary. Don't think that this is something that we've already got set up. This-- I just made up that number. And imagine if instead of saying, OK, well, here's the complete emerald package, and here's a sub package that matches exactly what you have.
ATHENA HEPNER: If it were hierarchical package IDs, you could have, say, here's the general one, and here's an x to indicate that it's just the base includes everything-- file from emerald. And then here's the dash seven that indicates it's the specific set of back files. And again, this is completely imaginary and hypothetical, but it could be something that might help us. So if we were able to take that idea and apply it across all of these settings where the same idea, or package idea appeared on our invoices, and in the knowledge bases, and in the KBART and MARC file selections that I can make on the vendor site, on our licenses, and brochures, and emails-- on statistics.
ATHENA HEPNER: Anywhere it's talking about the packages, and talking about the specific thing a customer has licensed, that would help librarians so much. And with that, I'm going to stop blathering, and let Christine talk a little bit about her perspective as a knowledge base provider.
CHRISTINE STOHN: Thanks, Athena. OK. So my presentation is kind of twofold. I'm going to first talk about the perspective on knowledge based provider in regards to the unique package ID. And then in my second part, discuss the NISO work item that was approved earlier last year. What the scope is, what the timeline is, and where we are. OK.
CHRISTINE STOHN: So let's start with the first part. Well, knowledge bases are in a sense sitting between a content provider, for example, publisher or aggregator and the libraries that purchased their content. Athena already mentioned a lot of things that also apply to us as a knowledge base provider. I'm just going to expand a little bit from my perspective.
CHRISTINE STOHN: Knowledge bases are often dealing with several thousands of providers in 10,000 of different packages. Like, libraries like Athena said, she's dealing with a million titles and thousands of packages. Obviously, this is multiplied in the knowledge base because we are trying to cover really everything that is available, and that a library could possibly purchase.
CHRISTINE STOHN: Usually, knowledge bases use internal ideas and package names, but that's not a good basis for identifying packages uniquely across the supply chain. Names can be ambiguous, and can lead to also misunderstandings. Therefore, the first that comes to mind here is that a unique package ID would make the communication between the different parties in the supply chain so much easier.
CHRISTINE STOHN: No more backwards and forwards with what exactly is meant when talking about a certain package name. This will also allow for better verification of data feeds from providers. We know instantly which feed-- what it's for. And this also works better with automation. And of course, it's a stable way to track changes in packages as well.
CHRISTINE STOHN: It could potentially save us a lot of time if we know what everybody is talking about, if we have a unique package ID. Currently this is all a little bit difficult with the different package names. Sometimes names have different meanings. It's really very problematic, and it echoes a lot of what also Athena was saying what her problems are.
CHRISTINE STOHN: In extension, a knowledge base can also help with discovery feeds. Knowledge bases are often the basis for a discovery index to know what is available in full text when a user is running a search for a specific institution. And so unique package IDs in the knowledge base could also impact the rights flow between a knowledge base and the discovery system. And lastly, especially in an electronic resource management system, the unique package ID could also help with recording packages in the license.
CHRISTINE STOHN: So everything what Athena mentioned from her perspective as a librarian also applies for the knowledge base provider. It would make a lot of things just so much easier if we could uniquely identify a package just with an ID across the entire supply chain. So there's a definite interest here too for the knowledge base perspective to have that unique package ID. What's wrong.
CHRISTINE STOHN: I'm going to go to the next slide. Another aspect to consider is KBART automation. I'm actually a big fan of KBART automation because it's so much about simplifying workflows, especially when we are dealing with a large number of items, for example, e-books. KBART automation-- it's a process to update the library's holdings in the knowledge base based on a feed coming directly from a content provider.
CHRISTINE STOHN: The system that manages the knowledge base, for example, library system, or an eResource management system initiates to download the holdings for the institution from the content provider, uploads it and localizes the title list for this provider with stat data. This process is usually scheduled, so it can, for example, run weekly. Especially for ebooks, it needs to run relatively frequently.
CHRISTINE STOHN: And without any manual intervention. This process is already available for a number of providers, including Elsevier, Springer, Wiley, of it. So it's a really nice way to save a lot of manual work, basically. At this point, the process only updates one complete provider package, or in some cases two if there's one for e-books and one for each article.
CHRISTINE STOHN: But it's just the one time complete offering. If a library buys, for example, sub packages, this would not be included as a separate fee. When we published the KBART automation recommendations some years ago now, I think about two years ago now. Originally, there was some interest in the second phase to include such sub packages, and this really brings us back to the unique package ID because this is basically the prerequisite for this.
CHRISTINE STOHN: It is too complex to do something that KBART automation for sub packages if you don't have any unique way to identify them, and need unique package IDs. So this is really the prerequisite for the next phase of KBART automation. Nothing in the knowledge base comes without challenges, and I would like to mention them here also to illustrate that we have to be careful in our expectations and definitions when working on a unique package ID recommendations.
CHRISTINE STOHN: First of all, it is easy to add unique package IDs to every package that is newly added to the knowledge base. But it will be a whole different story to add them retrospectively. Basically, we will have to create new fields and map them unique packages IDs somehow to the package names. We are talking about thousands of providers here and even more packages.
CHRISTINE STOHN: It will definitely take time for any such changes to make a greater impact. That's a major operational effort. And then, I'm sure there are functional implications. For example, if the package ID should be part of any features, or functions, automation, et cetera. And that means that there are also development tasks here. Many knowledge bases have existed for many years. Ours certainly have, and the content grew over time, not just based on feeds and feedback from content providers, but also based on additions and change requests from librarians.
CHRISTINE STOHN: And there is not always agreement about what a package contains. As a knowledge based provider, we usually follow our customer requests, but the result is sometimes that the content of the package in the KB may not reflect entirely the content listing on the provider side. But if we now assign a unique package ID to one of those packages, and there may be some expectation of what exactly the content of that package is.
CHRISTINE STOHN: That can easily create conflicts between what one party thinks the content is, and what the other party thinks. And also, we have cases where the content of a package is different depending on a geographic area. Basically geo-rights. Not the entire content is available in every country. So we have to be clear about what the expectation is as to the content of the package when we have a unique package ID.
CHRISTINE STOHN: This can become potentially a bit of a minefield. Such challenges do not stop us from going forward with creating the unique package ID. Recommendation-- we think it's very important. It's definitely going to be providing more benefits than stumbling blocks, but there are stumbling blocks and it just means that we have to be mindful of those issues, and see how we can overcome them when we go through the process of creating the recommendations.
CHRISTINE STOHN: And this brings me to the second part of my presentation, the new NISO work item. The work item was approved by NISO last year, and it's about to start. We have not finally put the list of members together, but we had a lot of interest. So the working group will be finalized hopefully in the coming week.
CHRISTINE STOHN: It's a bit later than we hope, but this is just because there were so many other NISO commitments. It was just a lot of work, a lot of things starting at the same time. In any case, we will be ready to start in the coming weeks. This is the process which is coming from the approved proposal. Basically, I copied it from the approved proposal into the slides here.
CHRISTINE STOHN: I would like to point out first though, that the goal of the work item is a practical solution that is workable by all stakeholders and provides also benefits to all stakeholders. I'm sure every stakeholder has their own idea about how to best do this. The libraries, the knowledge base providers, and the content providers. But we have to make sure that all agree that they can work with whatever we are coming up with, whatever we are recommending at the end of the day.
CHRISTINE STOHN: The success of NISO standard, or recommendation in that case, depends on really all parties being able to use them, and see benefit in implementing them. For example, if in any extreme case, one of the parties has all the costs or risks, while another one has all the benefits, then obviously that cannot work. Success for such things is always dependent on collaboration and consensus.
CHRISTINE STOHN: I'm sure you know this all, but it's just important for me to say this again here. We, of course, want to make this is success. This is why we're working on it. The work item is divided into two parts. One is the initial analysis, and the second are the actual recommendation. The purpose of the analysis is to make sure that we have all the use cases documented, that we understand every stakeholder's requirements and prerequisites.
CHRISTINE STOHN: And that we are aware of any possible showstoppers, problems, and we have solutions in place. We also need to look at possible requirements for KBART automation, as I just mentioned. And then, of course, very important-- we need to look at how the unique package identifiers can, or should be structured. Best is always to check if there are comparable cases that can give us some guidelines, if there are any.
CHRISTINE STOHN: A unique package ID needs to be really unique across all content providers. And in order to not create duplicates, we either have to use common parameters that could, for example, take a provider name into account. Or we need a sort of registry, but registries are more work intense because they need to be managed by someone really on an ongoing basis. We need to figure out what's the best solution here and that is also future proof.
CHRISTINE STOHN: We will have to decide how we are going to do all this analysis. Options are to phase this out, but we can also think of working in subgroups to maybe do some things in parallel. Finding an efficient process here will be one of the initial tasks. They may also conduct surveys of course. And if we do, we appreciate of course your input in participation.
CHRISTINE STOHN: That's really how everyone can contribute, even if you're not part of the working group. But the input is really needed specifically in the analysis part. And the second part of the process is to write up the actual recommendations, and make sure they meet all the requirements identified in the first phase. I know that there was some interest to make this work item an action standard.
CHRISTINE STOHN: It was initially discussed. That has to be decided at one point. Standards usually take longer. There's a whole additional process to go through, which is why many working groups prefer to publish recommendations instead of a standard, but it really depends whether there's enough benefit from having that system.
CHRISTINE STOHN: Coming to the timeline. This is the proposed timeline. We are still at the very beginning with the appointment of the working group. I think I said before that we had great interest, and we had enough people willing to work on this. So the expectation is that the working group will be finalized shortly. For the first few meetings we'll be busy with the initial work plan and to outline the scope better, and then to decide on how we tackle the analysis.
CHRISTINE STOHN: Then we have the information gathering phase with all the analysis work leading up to phase two with detailing all of the results, including identifying potential solution, possibly prototypes, before we in phase three write up the initial draft for the recommended practice. I think at that point, we also need to decide whether we want to go for a standard or stick with the recommended practice.
CHRISTINE STOHN: If we stick with the recommended practice, this will go into public comment-- a public comment period, as usual-- and then after all public comments have been reviewed and responded to, the final version is published. In total, we anticipate this to take about 20 months. I think that's the usual or the average time for such a work item.
CHRISTINE STOHN: We'll see how it goes. If possible, we can move forward quicker, but experience shows that it does take its time, especially the analysis work. So this is my last slide. We are about to go on this adventure, hopefully together with many of you. Thank you very much for listening and for your interest in the unique package ID.
CHRISTINE STOHN: We are looking forward to discussing this with you. Any example or input you can give that may help with the analysis would be great too. We are at this point not looking for more candidates for the working group. We already had enough interest, but we certainly need all the help we can get from every one of you. It's your examples, your experience that's very valuable for this work item to go forward.
CHRISTINE STOHN: Thank you.
AMY CASTILLO: Well thank you so much, Christine, and Athena, and everybody attending this presentation. We're going to move on over to the live discussion, and we look forward to engaging with you in your questions. So all right. Thank you so much. [MUSIC PLAYING]