They created user profiles for the different types of users to help both their own staff and publishers understand how their users interact with different aspects of the metadata.
Historically, the library catalog was record of what the library held, but in the 90s, the library began including online resources, but not journal articles, and most library catalogs are still MARC-based.
The OpenURL link resolver takes a citation and formats it as a URL and links to relevant library services. A knowledgebase of the library’s holdings (print and electronic) supports this. [It appears we still need to have an explanation of how this works and why we need a tool like this to get to the appropriate copy?]
Library discovery services are a simple search of comprehensive content with a fast response time and includes local collections. They are meant for undergraduate or novice researchers in a discipline.
The discovery metadata typically comes from many sources of publishers and providers. It needs to be mapped to an underlying set of data elements in order to be indexed. It must be thorough enough to be searched and it must be accurate.
One place where discovery metadata fails is when there is a lack of journal history data. ISSN and title changes need to be associated with each other. Wiley, for example, submitted the current title and ISSN for the entire run of a journal, even when there were other titles and ISSNs in that history. This makes knowledgebases incorrectly tell users that we do not have content that we do. The discovery service providers are having to compensate for the missing data from publishers, who should know better what their journal histories are.
Another place where discovery metadata fails is the tagging of material types through incorrectly designed templates. Streaming audio should not be labeled as a book chapter. A review in Scopus is a “scientific review”, but these are sometimes included in limited searches for book reviews in some discovery services.
Libraries use more than just MARC records and the library catalog to provide access to publisher content. Publisher metadata is distributed to many systems, not just libraries. Any source that supports OpenURL can potential provide access to publisher content. Metadata accuracy is more than just correct transcription.
Publisher support can come from KBART, ODI, SerialsSolutions KnowledgeWorks, Project Transfer, PIE-J, MARC Record Guide for Monograph Aggregator Vendors, and MARCEdit.
Library catalogers can’t do it all. We’re relying more on publisher-supplied data.
Audience question about book chapters — Shadle thinks that those that are separately authored and easily cited, and so should have the same level of metadata as journal articles in our discovery services.
This session covers the types of needs users have, how discovery tools can help or hinder, and some discovery beyond the basic catalog.
Discovery in a library context happens in the discovery tools (catalog, next-gen layers, web-scale tools, external collections, etc.). A discovery tool that works for music will work well for (almost) anything. Just because a service works well for simple things or known items doesn’t mean it will work well for more complex resources.
Music searches may be a cluster of queries that can but not necessarily overlap. They could be known contributors/creators, but could also be forms and genres not necessarily covered by basic search facets.
MLA has created a document for music discovery requirements in 2012. The primary audience is not music catalogers, and it describes the characteristics of materials and their importance in discovery. It focuses on bibliographic records, but they recognize that the future of discovery will need to include authority data. There is also an appendix with a spreadsheet with some suggested MARC mappings.
Uniform titles are the way music cataloging has identified works for collocation. There is a long list of fields that contain this information, and often the differentiation is buried deep in subfields.
Compilations need to have their content notes displayed and indexed.
They use WorldCat Local for local/global holdings, their classic catalog (Voyager) for local holdings (what they usually push to users for music discovery), and Summon (articles, ebooks, streaming, A/V), as well as their music databases web page of links.
They are implementing Blacklight for a bento box approach (beta interface). They have the single search implemented, but won’t have the bento aspect until next year.
She is serving as the music library representative on the implementation team, and has been able to contribute feedback about the kinds of searching and facets that they need. One that they are most excited about is being able to search by the publisher number or record label catalog number.
[There were lots more examples of how Blacklight is working with music catalog records. Check the slides (when they are posted) and read the proceedings for more information. I kind of zoned out because it wasn’t the information I needed.]
Moderator: Dan Tonkery Panel: Roger Schonfeld (ITHAKA S + R), Jon Law (ProQuest), Amira Aaron (Northeastern University), Brian Duncan (EBSCO), & Susan Stearns (Ex Libris)
What features of discovery services do students prefer? What ones do they dislike?
Law: The search box is intuitive and familiar, and their expectations of speed are set by web search engines. Being able to quickly scan the abstract to see if it is relevant, and then quickly retrieve the content when they want it.
Stearns: Needs to be flexible and reflective of different user types and the environment they are in. Contextual searching based on who they are and how they look for information. Students also expect to access related content about their relationship with libraries (i.e. materials checked out, notices).
Duncan: Finding the results on the first page, and at least the second page. Metadata and relevancy are important.
What impact is open access having on discovery?
Aaron: Depends on the model of OA. Not really sure if it has an impact on discovery systems yet. It has and will have an impact on discovery in general, but not sure if it’s impacting library discovery systems any more or less than open web searches.
Law: Our customers are turning OA links on in the discovery service.
Stearns: It’s easy to make the OA content available, but are you managing it? How does this impact back-office workflows?
Will discovery services replace the online catalog?
Stearns: It’s been painful for some libraries, but yes. There is no OPAC in next generation library systems, it’s all about discovery. And we need to get over it. Discovery services need to have the functionality of the OPAC (things librarians like). This is an opportunity to rethink workflows and what you do with metadata in a discovery environment.
What are the advantages of selling both a family of databases and a discovery service?
Duncan: Users have automatic full-text because it’s built into the system and doesn’t need to go through OpenURL. Thinking a lot about how to make this simpler for students and integrating high-quality metadata from A&I sources along with the full-text.
Aaron: That’s fine for the vendor, but it takes away the choice for the librarian as to where to send the user. It’s taking away choice.
Law: We want our discovery service to be content-provider neutral.
What impact can libraries reasonably expect discovery services to have on traffic patterns?
Schonfeld: We see the majority of traffic coming from Google and Google Scholar, at least for JSTOR. If the objective is to change where users are starting their research, then we need different ways of measuring that and determining success.
Stearns: Our customers are thinking about not only having the one search box on the web page, but also where else can you embed linking and making sure the connections work, particularly when users come in from different sources.
Aaron: Success is not measured by how many people come to your website and start there, it’s how they get to the content from wherever they go.
What metrics do librarians expect from discovery services?
Aaron: Search statistics aren’t very meaningful in the context of discovery services. Click-through, content sources — those are the important metrics.
Schonfeld: This is not just a new product – it replaces old products, so we need to think about it differently. Libraries might want to know what share of their users is coming from what sources (i.e. discovery services, Wikipedia, Google, etc.). It’s still early days to be able to come to any strong conclusions.
Duncan: Need to measure searches that don’t result in any click-throughs as well.
Does your discovery product provide title-level information to the user community and how often is it updated?
Law: How do you measure your collection? We need some definition around this in order to know how to tell libraries how much of it is indexed in our discovery service. We are starting to do more collection analysis for libraries.
Duncan: The title list doesn’t equate to the deep metadata of an A&I database. If we don’t have the deep metadata, we don’t say we have the same coverage as that database. Full text searching is not a replacement for controlled vocabulary and metadata, it’s just a component of it.
Stearns: We also want to make sure the collections we expose are actually the ones the users access, by looking at historical usage information.
Aaron: It’s important to have the deep metadata, and it’s troubling that the content providers aren’t playing well together. I should be able to display content we purchase to our users in whatever interface I want. If I can’t, I may not continue to purchase or lease that content. It’s the same problem we had with link resolvers years ago. If you really care about the user and libraries, then start playing together.
[Missed the last question because I was still flying high from Aaron’s call-out, but it was something dull about how much customization is available in the discovery system, or something like that. Couldn’t tell from the responses. Go read product information for the answers.]
Speaker: Susan Stearns, VP of Strategic Partnerships of Ex Libris Group
Both library as a percentage of university expenditures and the number of library staff per student have been going down. The percentage of library expenditures spent on electronic resources has been going up dramatically.
There is a need to eliminate the duplication of data and workflows, and the silo systems in libraries today. Alma intends to unify both the data and the data environment: acquisitions, metadata management, fulfillment, and analytics.
Collaborative metadata management is a hybrid model to balance global sharing with local needs. In English, this means you can have a catalog that includes both an inventory of locally owned items and a collection of items shared by one or more “communities.” Multiple metadata schema are supported within the system in their native formats — no crosswalks required.
Individual library staff users can set up “home pages” within the system that includes widgets with data, alerts, and reports. This can help with making decisions about the collection. Analytics are also embedded directly in the workflow (i.e. a graph representing the balance remaining in a fund displayed when an order using that fund is viewed/entered).
Speaker: Maria Bunevski, Ex Libris
Preparation for moving to a new system, particularly a radically new system like Alma, requires spending some time thinking about workflows, data, technical aspects (integration points, etc.), and training.
Project initiation phase requires a lot of training sessions to fully grasp all of the change that needs to happen.
The implementation phase involves a mix of on-site work and remote tweaking. At some point work has to freeze in the old system before cutting over to the new one.
VCU is currently in the post-implementation phase. This is the point where un-configured things are discovered, along with gaps in workflow.
Speaker: John Duke, VCU Libraries
They had Aleph, SFX, Verde, MetaLib, Primo, ARC, ILLiad, university systems, etc. before, and they wanted to bring the functions together. They didn’t end up with a monolithic system for everything, but they got closer.
Workflows and other aspects have been simplified.
The system is not complete, either because Ex Libris hadn’t thought of it or because VCU hasn’t figured out how to incorporate it. Internet outages, security issues, and conceptual difficulties have thrown up road blocks along the way.
Updates from Serials Solutions – mostly Resource Manager (Ashley Bass):
Keep up to date with ongoing enhancements for management tools (quarterly releases) by following answer #422 in the Support Center, and via training/overview webinars.
Populating and maintaining the ERM can be challenging, so they focused a lot of work this year on that process: license template library, license upload tool, data population service, SUSHI, offline date and status editor enhancements (new data elements for sort & filter, new logic, new selection elements, notes), and expanded and additional fields.
Workflow, communication, and decision support enhancements: in context help linking, contact tool filters, navigation, new Counter reports, more information about vendors, Counter summary page, etc. Her most favorite new feature is “deep linking” functionality (aka persistent links to records in SerSol). [I didn’t realize that wasn’t there before — been doing this for my own purposes for a while.]
Next up (in two weeks, 4th quarter release): new alerts, resource renewals feature (reports! and checklist!, will inherit from Admin data), Client Center navigation improvements (i.e. keyword searching for databases, system performance optimization), new license fields (images, public performance rights, training materials rights) & a few more, Counter updates, SUSHI updates (making customizations to deal with vendors who aren’t strictly following the standard), gathering stats for Springer (YTD won’t be available after Nov 30 — up to Sept avail now), and online DRS form enhancements.
In the future: license API (could allow libraries to create a different user interface), contact tools improvements, interoperability documentation, new BI tools and reporting functionality, and improving the Client Center.
Also, building a new KB (2014 release) and a web-scale management solution (Intota, also coming 2014). They are looking to have more internal efficiencies by rebuilding the KB, and it will include information from Ulrich’s, new content types metadata (e.g. A/V), metadata standardization, industry data, etc.
Summon Updates (Andrew Nagy):
I know very little about Summon functionality, so just listened to this one and didn’t take notes. Take-away: if you haven’t looked at Summon in a while, it would be worth giving it another go.
360 Link Customization via JavaScript and CSS (Liz Jacobson & Terry Brady, Georgetown University):
Goal #1: Allow users to easily link to full-text resources. Solution: Go beyond the out-of-the box 360 Link display.
Goal #2: Allow users to report problems or contact library staff at the point of failure. Solution: eresources problem report form
They created the eresources problem report form using Drupal. The fields include contact information, description of the resource, description of the problem, and the ability to attach a screenshot.
When they evaluated the slightly customized out of the box 360 Link page, they determined that it was confusing to users, with too many options and confusing links. So, they took some inspiration from other libraries (Matthew Reidsma’s GVUS jQuery code available on Github) and developed a prototype that uses custom JavaScript and CSS to walk the user through the process.
Some enhancements included: making the links for full-text (article & journal) butttons, hiding additional help information and giving some hover-over information, parsing the citation into the problem report page, and moving the citation below the links to full-text. For journal citations with no full-text, they made the links to the catalog search large buttons with more text detail in them.
Some of the challenges of implementing these changes is the lack of a test environment because of the limited preview capablities in 360 Link. Any changes actually made required an overnight refresh and they would be live, opening the risk of 24 hour windows of broken resource links. So, they created their own test environment by modifying test scenarios into static HTML files and wrapping them in their own custom PHP to mimic the live pages without having to work with the live pages.
[At this point, it got really techy and lost me. Contact the presenters for details if you’re interested. They’re looking to go live with this as soon as they figure out a low-use time that will have minimal impact on their users.]
Customizing 360 Link menu with jQuery (Laura Wrubel, George Washington University)
They wanted to give better visual clues for users, emphasize the full-text, have more local control over linkns, and visual integration with other library tools so it’s more seamless for users.
They started with Reidsma’s code, then then forked off from it. They added a problem link to a Google form, fixed ebook chapter links and citation formatting, created conditional links to the catalog, and linked to their other library’s link resolver.
They hope to continue to tweak the language on the page, particularly for ILL suggestion. The coverage date is currently hidden behind the details link, which is fine most of the time, but sometimes that needs to be displayed. They also plan to load the print holdings coverage dates to eliminate confusion about what the library actually has.
In the future, they would rather use the API and blend the link resolver functionality with catalog tools.
Custom document delivery services using 360 Link API (Kathy Kilduff, WRLC)
They facilitate inter-consortial loans (Consortium Loan Service), and originally requests were only done through the catalog. When they started using SFX, they added a link there, too. Now that they have 360 Link, they still have a link there, but now the request form is prepopulated with all of the citation information. In the background, they are using the API to gather the citation information, as well as checking to see if there are terms of use, and then checking to see if there are ILL permissions listed. They provide a link to the full-text in the staff client developed for the CLS if the terms of use allow for ILL of the electronic copy. If there isn’t a copy available in WRLC, they forward the citation information to the user’s library’s ILL form.
License information for course reserves for faculty (Shanyun Zhang, Catholic University)
Included course reserve in the license information, but then it became an issue to convey that information to the faculty who were used to negotiating it with publishers directly. Most faculty prefer to use Blackboard for course readings, and handle it themselves. But, they need to figure out how to incorporate the library in the workflow. Looking for suggestions from the group.
Advanced Usage Tracking in Summon with Google Anaytics (Kun Lin, Catholic University)
In order to tweak user experience, you need to know who, what, when, how, and most important, what were they thinking. Google Anayltics can help figure those things out in Summon. Parameters are easy ways to track facets, and you can use the data from Google Analytics to figure out the story based on that. Tracking things the “hard way,” you can use the conversion/goal function of Google Analytics. But, you’ll need to know a little about coding to make it work, because you have to add some javascripts to your Summon pages.
Use of ERM/KB for collection analysis (Mitzi Cole, NASA Goddard Library)
Used the overlap analysis to compare print holdings with electronic and downloaded the report. The partial overlap can actually be a full overlap if the coverage dates aren’t formatted the same, but otherwise it’s a decent report. She incorporated license data from Resource Manager and print collection usage pulled from her ILS. This allowed her to create a decision tool (spreadsheet), and denoted the print usage in 5 year increments, eliminating previous 5 years use with each increment (this showed a drop in use over time for titles of concern).
Discussion of KnowledgeWorks Management/Metadata (Ben Johnson, Lead Metadata Librarian, SerialsSolutions)
After they get the data from the provider or it is made available to them, they have a system to automatically process the data so it fits their specifications, and then it is integrated into the KB.
They deal with a lot of bad data. 90% of databases change every month. Publishers have their own editorial policies that display the data in certain ways (e.g., title lists) and deliver inconsistent, and often erroneous, metadata. The KB team tries to catch everything, but some things still slip through. Throught the data ingestion process, they apply rules based on past experience with the data source. After that, the data is normalized so that various title/ISSN/ISBN combinations can be associated with the authority record. Finally, the data is incorporated into the KB.
Authority rules are used to correct errors and inconsistencies. Rule automatically and consistently correct holdings, and they are often used to correct vendor reporting problems. Rules are condified for provider and database, with 76,000+ applied to thousands of databases, and 200+ new rules are added each month.
Why does it take two months for KB data to be corrected when I report it? Usually it’s because they are working with the data providers, and some respond more quickly than others. They are hoping that being involved with various initiatives like KBART will help fix data from the provider so they don’t have to worry about correcting it for us, but also making it easier to make those corrections by using standards.
Client Center ISSN/ISBN doesn’t always work in 360 Links, which may have something to do with the authority record, but it’s unclear. It’s possible that there are some data in the Client Center that haven’t been normalized, and could cause this disconnect. And sometimes the provider doesn’t send both print and electronic ISSN/ISBN.
What is the source for authority records for ISSN/ISBN? LC, Bowker, ISSN.org, but he’s not clear. Clarification: Which field in the MARC record is the source for the ISBN? It could be the source of the normalization problem, according to the questioner. Johnson isn’t clear on where it comes from.
They wanted to create an author and publication repository. They maintain information about the authors with name variants and the codes for their divisions, in addition to identifying the relationships between the author and publication and among the authors themselves. The display of this information needed to be displayed with links to the full-text using their link resolver or by attaching full text files when allowed by copyright. Those needs helped identify requirements for the system they chose.
They were able to use the Homeland Security database of NASA employees to harvest information about the authors to begin populating that database. They then harvested data from a number of commercial sources to find their publications.
They developed crosswalks to move metadata from the various sources, and developed a utility to de-dupe the records and match author name variants. They also used the OpenURL standard to create full-text links.
They used Fedora Repository to store all of this. In order to use Fedora, you need to think in objects. Using relational queries, you can repurpose almost all of your data.
The author metadata was created using MADS in a separate tool and then exported to the format needed for Fedora. They used the local identification numbers for employees for the PID. On the public display of the author record, they show the author’s publications and the related authors (i.e. co-authors).
In the publications database, they used PUB_MD identifiers for publications to create unique PIDs. Unfortunately, there were problems with variations because they were pulling data from several sources.
The public end uses Drupal with Zen-based themes. For future consideration, they are looking at self-submission methods, Hydra, Islandora, BibApp, and whatever else may be developed which will plug into Fedora.
Talk to the end users early and often. We think like librarians and they don’t. Publisher metadata can be problematic — even they have trouble with author disambiguation. Automation can only go so far, and you still need human quality control. There’s always something new on the horizon.
Speaker: Amy Buckland
Many repositories are founded because someone at an institution wants one or sets it as a goal. But you need to know what that means.
Clifford Lynch calls it “a set of services that a university offers to the members of its community for the management and dissemination of digital materials created by the institution and its community members.”
If it’s a service, it impacts all areas of the library. It needs to be sustainable, and flexible as formats change. At McGill, they mediate the deposits in order to make sure copyrights are honored.
How do users find out about your IR? What kind of support will it have? You need to know this at the beginning so that you can market it to the stakeholders.
Who are the members of the community? Will students be included? At McGill, they are, and it’s a requirement for graduation that theses are deposited.
There is no way that what you are using for your IR will make it manageable and accessible. Be very wary of tools that promise this.
What goes in? What kinds of digital materials? Is it dark or open? Flat media (articles, papers, theses, etc) are easy, but it gets tricky with other objects and dynamic resources like blogs and websites.
The standards don’t stay standard for very long. Pick one and stick to it, because retro-fitting is challenging.
Who is a part of your institution? Do alumni get included? For public institutions, is the public included?
Institutional repository is a librarian term. Call it something else depending on who you talk to so that it has meaning to them.
“our goal is to take advantage of the web to make the knowledge created at our institution available to the world”
Speaker: Jim DelRosso
Digital projects are chronically understaffed. We need to be advocates to change that.
If you are going into digital repositories, copyright is going to be a pain in your butt.
Digitization isn’t magical. It takes people to figure out if it can be included and then do all the work to get it there. If it was possible to do this easily, libraries wouldn’t be doing it, Google would.
People are one of the toughest things to get support for. Tech is shiny and gets the attention, but it can be done without staff. Tell decision makers that technologies go obsolete, shiny gets dull, but people will last.
Our capacity to do works that will stagger our users and our peers is sometimes missed. There is right now more potential for the dissemination and preservation of knowledge than we have ever seen in human history. Go forth and do that!
The US ISSN Center (part of the Library of Congress) is primarily responsible for assigning ISSN and metadata to journals. They work with the international ISSN network as well as answering questions from libraries and publishers.
R.R. Bowker is a subdivision of ProQuest. They create metadata for libraries and publishers and several products like Ulrichs. They have one employee working in the ISSN Center assigning ISSNs, creating CONSER records, screens incoming requests, and solves problems. Initially, they worked mostly with the Ulrichs database, and now are working with the SerialsSolutions database.
The relationship began over metadata. Bowker wanted data for Ulrichs, and the ISSN Center needed more staff to do it. The contract is non-exclusive, but to date, no other company has been involved. LoC would like to develop more relationships like this, in part to reduce duplication of effort.
The benefit for publishers is a one-stop shop for ISSN registration, Ulrichs inclusion, and CONSER records in WorldCat. The serials community benefits from having a standard number for each publication, fuller records, and an advocate for gathering that metadata.
Some of the challenges have been technological (firewalls, different computers, etc.) and administrative (different bosses, holidays, etc,). They are looking to better ways of collaborating between the ISSN record creation and the Ulrichs record creation.
Standards matter. Common data elements can be mapped.
More detail in the current issue of Serials Review.
When creating a digital repository, start small. They started initially with getting faculty publications up. This required developing strong relationships with them.
While you may be starting small, you need to dream big as well. What else can you do?
Get support. Go to the offices of the people you want to work with. Get familiar with the administrative assistants. But, be ready to do everything yourself.
Plan ahead, but write it in pencil. They organizational structure of your repository needs to be flexible to handle outside changes.
Once you get going, take time to assess how it’s doing. Get familiar with the reports available in your system, or use tools like Google Analytics. Don’t rely only on anecdotes. Use both numbers and stories.
Presenters: Jason Price, Claremont Colleges Library and SCELC Consortium
KBART stands for Knowledge Bases and Related Tools (a NISO group). Standards and best practices are challenging to move forward, so why should we “back this horse” versus something else?
This group is a collection of publishers, aggregators, knowledge base vendors, and librarians who want to create a universally acceptable holdings data format. Phase one of the report came out in January of this year, and the endorsement phase begins this month.
KBART expresses title level coverage by date and volume/issue. It’s a single solution for sharing holdings data across the scholarly communications supply chain. Essentially, it’s a simple metadata exchange format.
It wasn’t a simple process to get to this schema. They thought about all of the data in knowledge bases, how data is transferred to and from other sources, and the role of licensing in this process. When a publisher produces content, it flows to hosts/databases then gateways then knowledge bases and then catalogs/lists/guides.
When a user has a citation, they initiate a process that queries the knowledge base, which returns a list of access points. However, this breaks down when the holdings information is incorrect or even worse, when it’s missing. We get stuck with a lot of inaccuracies and manual work. At some point, it gets to be too much to keep up with.
Everyone is working with the same kind of data, albeit slightly customized at a local level. If we can begin to move toward a standard way of distributing the data, we can then look at automating this process.
KBART is the end to our role as translators – no more badgering publishers for complete lists, no more teasing out title changes (including former titles and ISSNs), no more waiting for the knowledge base data team to translate the data, and no more out of date access lists.
What can librarians do? Learn more about KBART. Insist on “knowing” what you’re buying (require annual delivery of a useable holdings list before you pay). Enable publisher sales staff to make the case to their companies – show them that use goes up when it’s accurately represented in link resolvers. Follow up with continued requests as necessary.
The American Institute of Physics implemented the KBART standard on their own, and they’ve now officially joined the group. On the other hand “A Big Publisher” recognizes the problem, but they need to establish the priority of the change, which includes getting their hosting service to make appropriate changes. So, they need to hear from all of us about this.
Publishers who are interested should review the requirements and format the content availability data to meet those requirements. Check your work and make it available to customers. And, of course, register as a KBART member.
Vision for KBART: Currently in phase one of standardizing. Phase two is more content type coverage. Phase three is a dream of incorporating metadata distribution for consortia and institutional level holdings based on what is accessible from a particular IP.
Our users expect us to be available to help them when they need it. Many are used to the customer service options available to them from various online retailers. How do we bring these kinds of tools and services into our existing array of offerings?
Rather than the user having to figure out how we might classify or categorize content on our websites, we need to make it easier for them to do quick and dirty searches that pull up relevant content first. The silos of information most of us carefully maintain presents a barrier to information for users who expect to be able to do those quick and dirty searches. Discovery layers promise to pull all the silos together, and we will know we have succeeded when users go to the library’s search site as often as they go to Google.
Our silos contain rich content, but it isn’t obvious to our users. We need tools that will pull the metadata and display it in a visual way that emphasized the relevance and importance of it.
Lipstick on a pig 2.0? The discovery layer interfaces we have are good transitions, but they still don’t address the underlying problems with our ILS interfaces and how they do not make full use of the rich metadata we provide.
Our users are going to bypass the library website — we will have to take our content to them. We need to move our resources into the arena of our online competitors like Google and Amazon. One great example that I have heard often is including links to our digital collections in relevant Wikipedia articles.
“Discovery happens everywhere, and discovery without fulfillment disappoints.” –Lorcan Dempsey
In the future, we will capture publisher metadata, aggregate special collection content with traditional resources, and make use of the catalog in unconventional ways. One library created a record entitled “Oprah’s New Pick” so that users could get into the queue for copies even before it was announced.
“Take some chances. You can always swim, but maybe you can fly.”
Librarians understand what OpenURL is and what it does, but not all publishers understand it that well. One of the main problems with OpenURL is making sure that the links work and take users to the content, not to mention making sure that all the links are there which should be.
One thing that libraries often miss is that their link resolvers should include information about their print holdings as well as the electronic ones. [Side note: The non-portability of data from our ILS as noted by Breeding earlier today is part of why that is the case — it’s often more work than we have time for to accurately pull our print holdings data into our link resolvers.]
In order to make the OpenURL process work, content providers need to do most of the work, which includes generating the correct links from sources and sharing the correct information about targets. The library’s responsibility is to ensure that the coverage and content in the knowledge base reflects the license agreement.
The core of the problems we face is metadata. Data provided by publishers, libraries, and vendors all can potentially be broken or incorrect. In a perfect world, all of the metadata would be perfect, but it’s not.
Glen Wiley & the folks at Cornell are doing something about fixing OpenURL syntax errors. Part of the problem with these errors comes from publishers not knowing or understanding what users will be doing with OpenURLs. And, there is often no way to provide feedback to publishers.
Knowledge Bases and Related Tools (KBART) is a UKSG and NISO collaborative project working to provide better data for everyone as well as ensuring the timely transfer of accurate data to ERMS and link resolvers. The core working group meets monthly and includes link resolver/ERMS suppliers, publishers, subscription agents, aggregators, libraries, and consortia. Several groups, including NASIG, are monitoring the process.
KBart seeks to provide best practice guidelines, educational opportunities, and the creation of an information hub for all players. The group has looked at the problems facing the supply chain, developed an initial list of terms that need to be clarified and defined, and started to build a report based around the problems and a supply chain flowchart. They’ve now broken into subgroups to address specific parts and the most relevant bits for each group.
The plan is to finish by this time next year and will present at UKSG, and hopefully NASIG as well. They might go on to create a standard, but will need to determine if it’s appropriate at that time.
Phase II will be focusing on non-textual content. Digital collection managers rejoice!
OpenURL syntax errors potentially can be easily fixed across the board, but a greater challenge is to evaluate and improve the accuracy of the data.