Hello this is Jan Waterhouse from the university at Albany. This recording is an overview of electronic resource management that Rebecca Nelson, I put together for enough
in Albany last October. I hope it will be helpful for you as a very high level view of what we've been doing what the electronic resources over the years.
The impetus for this discussion came from my father, who's 84 and lived in the country. So, as he was coming of age cars were relatively new and because they were in remote
Kind of far away from a city he and his brothers did their own repairs. So as technology was added to vehicles over the years rack and pinion steering or carburetors he was able to incorporate these new pieces into what he already knew about automobiles.
my granddaughter's. On the other hand, who are four and six by the time they're driving automobiles are going to seem
Very highly technological and probably difficult to understand. And it occurred to me at one point in time that electronic resource management kind of fits this model a little bit, those of us who've been around.
We're working in libraries as different pieces were added. But the Alice P that we're moving to it is fully integrated and very complex. So I'm going to kind of step through
Where we've started where we are now with our 1990s Honda in the form of all of it all of its various components so that the
electronic resource management in the MSP might make a little bit more sense. So I'm going to start very basically which is
The resources that libraries using recommend all have something in common, and that is that their access through the web browser.
That even though we're using the same browser for all of them, they are in fact different sources of information and this is the crux of any libraries relevance. Right.
We kind of have a feel for whether resources are good or bad, but we began competing with Google over 10 years ago. And this is why single searches spend so important than yet so elusive.
It's also the beginning of the confusion with respect to managing and accessing resources because everything is getting filtered through a single tool, the browser.
Unlike books that have a fixed Table of Contents contents and an index the periodical indices
Are always changing. The data is always changing as new issues are published so early databases were just basically electronic indices
With maybe some citation information when the user found a citation of interest sheer he had to then search the library catalog to see if the library. Subscribe to the periodical remember those days maybe CD ROM towers.
Then databases began to have full text content and some libraries accommodated this by adding a link in the mark record.
But those links would have been title level only not article level because obviously we're not cataloging all of these articles.
The user would need to still navigate to the correct volume, issue and article
And remember that even though we had some full text, the user might find a citation and an abstract index or selected full text database and then would need to go back to the catalog to find out if the library owned it somewhere.
Or search all of your different databases to find it. Now, approximately, in parallel to different organizations, we're working on different solutions to this problem of making it
Easier to move between electronic resources and the solutions ended up merging merging at least conceptually
So cereal solutions was creating a way for libraries to have a list of what electronic titles were available full text for their patrons the journals. A to Z list.
You may remember the days where a patron would search a database and find a citation of interest and then look in your journals. A to see less to see if the library owned any full text for it.
This included coverage dates with links to journals and then also around the same time, Herbert Monta sample created the FX link resolved that was purchased by X Libra. And that was being developed to use
A URL from a browser to include citation information that to resolve or could parse to determine if a library owned any full text resources.
Now,
These merged to be what we refer to as a knowledge base or KB or journals. A to Z list or open your resolve or resolved or these are all synonymous.
The technologies. The same. And the important thing to know about this is the purpose was to provide access to full text resources. That's the purpose of these knowledge bases.
The data in them is minimal. It has we'll look at a list here in a little while, but basically it is the link to the full text, the title, the publisher coverage information.
Another important aspect of this knowledge base data is that libraries may select what they subscribe to
But the data itself is managed by the vendors, the vendors are constantly updating all of this data from the publishers. So we might be able to create a few local collections. But in general, this vast amount of data is managed kind of outside of our hands.
So here we've moved along our timeline, a little bit. We have a user
Who's performed a search and maybe they have found some full text, but they find something they're interested in that isn't available full text in that database.
They follow up find it link that sends a URL to the resolve over that looks at the library's holdings and, if possible, sends the user on to full text database.
Or perhaps in interlibrary loan for we're very used to this now, but this was, if you remember when they started about 15 years ago.
This was a game changer for libraries users, no longer needed to look in multiple places they could simply follow links to navigate between resources.
For the most part, as you if you around, you probably did a lot of troubleshooting. But remember, this is a separate product from the iOS.
A separate piece of the puzzle that we had to manage. Now another thing that was happening, which is a little more straightforward, but it's worth mentioning is related to authentication.
Clearly, in the early days with libraries, you had to come into the library to handle these physical items.
Then libraries had in house workstations, the CD ROM towers, the dedicated terminals
Then publishers would give libraries credentials usernames and passwords that they needed to kind of manage and pass out to patrons. Then came IP address recognition where libraries gave pools of IP addresses to the vendors. So the vendors could recognize
Internet traffic coming from particular institutions that required library patrons to be in the library to be able to use the resources so proxy servers came along and
That allowed remote access to resources for people who wanted to connect from home, the proxy server had an IP address for the campus and was allowed to access the resources.
It's in gray here because it's still in its early stages, but the next evolution is a single sign on systems using something like Shibboleth so that each user can be identified with the institution or institutions that they belong to by the vendors
Very briefly, I'm just going to talk about federated search, which was a bit of a flash in the pan. But again, if you were here throughout the course of the events, you will recognize some of this.
Technology. This was a user performing a search in a federated system that then perform simultaneous searches in various databases.
If they weren't around for very long. You might recognize some of the product names listed here because they had connectivity issues very slow response. Many of these connections may have been
Didn't scale well duplication was an issue complexity. So they didn't. They didn't last long. But they set the stage for what was originally called web scale discovery. Now we just refer to them as discovery services.
And similar to the Kb. We're now talking about yet another product for libraries to procure implement and manage
And if you were around for your libraries first implementation of a discovery system. Several years ago, you may remember that when you were
Reviewing products. There are two primary components. The Central Index, which is what the users search to get search results from and then the user interface. So you may have checked the size and the breadth of the central, central index to see
how large the set of metadata was that users could search and you may have looked at the functionality in the user interface and how easy it was for the user to perform searches and limit and do advanced searches.
And the discovery systems that are in play now include Google Scholar, eds. OCLC World Cat discovery primo pre Mobi and summon
I'd like to take a minute just to talk about the central index, because it is a completely different data source. And for those people who've been around with the electronic resource management, it's kind of obvious because you were adding A DIFFERENT VENDOR system.
Months or years after the other systems. But again, looking to the future with everything integrated. It's kind of hard to separate these out. So the central index.
Is going to have a way to bring in your bibliographic data.
It has its own licensed content and includes article level metadata for the various publishers that it has contracts with
That is officially the central index. There may be other content with network connectivity possible. For example, an institutional repository that the discovery system can harvest and integrate
Data and then there are going to be other databases and electronic resources. So a customized discovery system than
Has your bibliographic data, the licensed content that you have selected that you want your users to be able to search it may be everything in the Central Index, it may not
You may have your network connectivity configured for any external resources that can be harvested, but you will have some other databases and electronic resources that just for one reason or another, are not integrated and so you have your website and your lip guides as
Places for your patrons to use to find those systems.
Now it's time to pause and take a look at the schema overview and remember that these three buckets that we have represent not only different types of data, which we're going to look at here.
With different purposes, but these are different products that you have to manage integrate move data between and more more most importantly troubleshoot
So you have your catalog your iOS with your traditional bibliographic data in Mark and Muffet formats.
You may have electronic resource records that you're loading in there, but the format is the same old format as before.
And the any links to those resources are going to be at the title level and the purpose is to make that bibliographic metadata available for searching. Then along came the Kb a different product a different type of data.
And the purpose of this is to provide links to full text resources. The only things you have in your KB are things you want people to be able to link to for full text.
The data itself isn't the title level, but the resolve or can create article level links from the resolve or URLs that come through.
Then you have your discovery system and the data is the central index with Article level at your resource.
Metadata and it has your bibliographic data folded in the links come, both from the bibliographic and the Kb data and will display with results.
And the purpose. Remember discovery was because we were competing with Google. We wanted to try to prove to provide as much of a single search as possible. So the discovery is searching across maybe not all library resources, but as many as possible.
So what it looks like in practice. And again, we're in our 1990s Honda Accord right this is technology that we're moving away from. We have our iOS, with its online public access access catalog.
And the records came from local cataloging and management. We may be bringing master records in from OCLC we may be batch loading.
Records, either from OCLC or directly from the publishers for electronic resources.
We also have our knowledge base that functions as our journals agency list and it may provide a mark record loading service for E books and journals. If we want to pay for that.
We also may have a database as A to Z list for some institutions, it's just a web page or a locally created web portal.
Some institutions may use a lip guides database. A to Z list.
You may have some institutional repositories or special collections that people go to separately through various websites.
And you may have added a discovery system. And again, that's going to have your bibliographic data and your article level metadata and the Central Index.
As the pool for users to search, we also may have an ER mass yet another system that I'm going to talk about a little bit more in just a minute.
And so our 1990s Honda. We've got a lot of different parts and pieces that we're managing to keep it all together. And if you were here as all if you worked in a library as all of these were added.
You kind of got used to these pieces, one by one, similar to the way my father did with cars, but new people coming along are going to see everything integrated and
It's a little bit harder to understand these different pieces of data. I also want to take a minute.
Just to talk about troubleshooting electronic resources in very general terms, and the most general terms, we're trying to get users to the resources that we subscribe to
And when a user emails or calls or chats or text with a problem. There may very well be a problem with the library systems that we support.
But they may have issues not related to library systems. And in those cases, you're not going to submit a ticket to the people who troubleshoot electronic resources.
One category is that the results they got are correct, just that the search that they performed was wrong and I think we refer to those as teachable moments. That's a chance for us to, you know, give them instruction. They may also have personal technology problems there may be a problem.
With their personal computers firewall. They may be trying to connect from work and there's a work firewall.
Those types of issues are best REDIRECTED TO IT staff to help the user
And the way that those can be identified, is if you can reproduce the problem or not. So if you have a way to mimic remote access, whether it's through a VPN connection or a dedicated off campus computer
That's how you will know whether it's really a problem accessing the resource or it's just an IT problem that that user needs to work out through a different type of expert.
There's also problems with the resources themselves. I mean directly with the publisher that aren't related to our systems and therefore not solvable by us.
Errors from within the vendor systems. For example, a vendor of streaming video the streaming box instead of displaying the video maybe throwing a job at error.
You may have also lost access because of accounting problems with the vendor now in these cases, the people who manage electronic resources.
Are very likely to make a phone call, send an email or open a ticket with the vendor, but we can't actually resolve the problem because the problem is outside of our hands.
Every other problem falls within this bucket of many, many applications that we pieced together to make electronic resources available, it might be
A bad link in our iOS, it might be a problem with our KB data having something selected that we no longer own or not selected that we've purchased
It might be a problem with the way our discovery system is configured or with the with our proxy server or it could be one of our other data silos or other applications that we're supporting cross all of these
Needs that our patrons have just a quick note about an era mass, I think.
For libraries that have looked into an era mouse before moving to an MSP what they do, makes sense because you knew the gap that you had. Now that everything is integrated what an era MS did is gets a little blurry.
These are some kind of formal definitions. This first one is a little more applicable to our 1990s technology that we needed a series of products to be able to manage our resources. The second one is really closer to what we're going to have with our MSP
It is not a Kb though it does use KP data, you would want it integrated with a KP it's not our acquisitions module, though, you would like it to be able to access cost data so that you can
Generate information on usage. It isn't just about usage stats, though you may be able to load stats are you stats for
Analysis of your usage. It was really created to integrate holdings cost usage and metadata metadata such as your administrative information the URL and credentials to log in as admin to your various databases.
To upload or provide a link to your license to select various license terms that are important for you to be able to look out for example, whether or not something can be interlibrary loan.
To enter notes about your resources and to provide workflows and alerts for managing things. So now we're going to move forward into the new world of our DeLorean and just take a quick look at Alma and primo
The Library Services platform is all mine It's most similar to what we're used to, with all of
Except that it was designed for multiple formats, not just physical. It accommodates electronic resource information in a way that the older iOS is just couldn't do. And that allows us to streamline and consolidate the management of the these resources.
The Discovery Service is replacing our own pack and it searches the alma bibliographic records as well as the central index metadata that we talked about.
And with a new system comes new vocabulary, a portfolio refers to an individual ebook or a journal
And there is minimal KB metadata about these full text resources that we subscribe to individually and that information includes the provider, the URL, the coverage and availability for our institution identifiers like an eye SSN or is bn
And electronic collection is a collection of portfolios and these are full text collections.
Again, with a Kb. What we're trying to do is get links to full text for our patrons. Now, many of us would have in the past, refer to any electronic collection as a database.
Actually verse language for database, however, is very specific and that refers to abstract in index databases with no full text content. So there are no individual portfolios or titles. It's just the name of the database.
And now that we're in our DeLorean. And we're no longer looking at all of these pieces separately. The way we're used to things can get kind of confusing.
So we're going to take a look here at, you know, which does what Alma is about access and when it comes to electronic resources.
We get access through URLs and the bibliographic record through links in the Kb with portfolio or if we have external repository records harvested will have links that way primo is about discovery.
And that discovery.
The user is going to be searching
The metadata from Alma bibliographic records as well as the article level metadata through the subscription and possibly non subscription content, depending on how you have it configured from the Central Index.
Alma doesn't know about article level metadata. It doesn't have the information that's in the Central Index.
It only knows whether you have access to an eternal or E book at the title level and supports connecting the full text.
That article level link comes through the resolve our and the information that's passed that way primo doesn't know what you own. It just knows what you're allowed to search what you're allowing your patrons to search, you may allow your patrons to search things that you don't
Subscribe to. In that case, you might have a link that would allow them to request it through interlibrary loan it supports finding library resources almost supports connecting default text.
And where do we manage all of this stuff. Well, the institutions own will have local bibliographic records, hopefully minimal amount of those local bibliographic data.
electronic portfolios and any local collections, we may have added the network zone is where our consortium bibliographic records are going to be
And other possibilities that may come along in the future would be consortiums subscriptions to electronic resources or shared vendor records the community zone is available to all x sleepers customers, and that includes some bibliographic records for
Electronic collections and databases, as well as the Kb data for electronic collections and databases and how actually verse me I just authority. Now remember that I mentioned before libraries.
Create and borrow and share bibliographic metadata through Mark records.
KB data is created and managed by publishers and vendors
And why is it important to understand the difference now with an MSP researchers aren't necessarily seeing library control data, not just the Kb data. I just mentioned that publishers, manage, but the central index data that's also managed by vendors and publishers
The primo discovery metadata is not the same as just the MSP bibliographic or portfolio data.
This does, however, get us closer to that single search interface that we wanted to provide for our patrons.
What else does it mean from the staff point of view.
Because the LSD was designed around
multiple formats including and especially electronic resources we have the possibility for streamline processes the Kb is fully integrated. It's so integrated that you don't actually hear much talk about KB.
You when you watch training or you. Listen to recordings, you hear them talk about activating resources activating portfolios or electronic collections.
Without understanding that what's happening is that data that's going to link your users to full text or your KB data is actually what's being managed primo and Omar fully linked together.
And the RMS that I alluded to before, is also fully integrated isn't a separate product. And it's a place to enter admin and license term metadata, as well as licenses and other information.
Now if we go back to troubleshooting. We're going to have the same problems we had before, because we have users who want to get to our resources.
Those users may have issues that are not related to our systems, the same as before, and our resources may have technological or accounting problems that we can't directly fix the same as before, but now
It is a problem instead of having multiple separate products multiple separate entry points for people search the data and applications are much more integrated on the hazard bibliographic and Katie. Katie data and primo has the index in any harvest of data and we may have
That's all I have. And I'd like to take a moment to thank Rebecca nows for her hard work with me on this presentation from last fall.
I'd like to mention that a PDF of the slides will also be made available. And if you have any questions I asked you to please email info at SLC NY dot live answers com and one of the SOC project managers will be in touch with you.