(BTW I am well aware that there is quite a bit of disagreement over what actually counts as a known item search (more academic piece) but for simplicity , I am going to take known item here to mean finding an article if you know the article title at least and perhaps even the whole citation.)
But as time went by, after answering question after question on how to find if the library has a certain known article, I realized known item searches for articles while not as hard as subject searches, it is usually no piece of cake for users either.
It's not that users didn't ask about finding known titles of books, some do, particularly if they got the title wrong or in cases where they were looking for textbooks with common titles and dozens of editions like "Financial Accounting" (failure on identify in FRBR tasks).
Still in general they were dwarfed by users asking if a known article exists either because they were
- following up from a reference in a paper (online or print)
- looking for a paper that cited the one they were reading
- found it in a indexing and abstract database
- or a professor/colleague/friend mentioned it.
Why is it so difficult? Several reasons
- Users are used to searching by keywords in article titles thanks to web search engines and complete article index that covers everything accessible don't exist
- Difficulties in maintaining a clean knowledgebase/ source of journal titles means even if the user does a search by journal name he may still get misleading results
- Increasing amount of Open Access or Free material not in the usual library silos/database/OPACS
Today libraries support a bewildering list of options for finding known articles from searching
- Next generation catalogues e.g Encore (that do not list article titles)
- Journal A-Z Listings - e.g Serial Solutions E-Journal Portal, EBSCO A-to-Z
- Article finder/citiation linkers (OpenURL) - e.g Webbridge/SFX/360link
- Article index search engines like Google Scholar or the new Web scale/Unified discovery products like Summon or Ebsco Discovery Service or Pubget like services
Classic Library Catalogue - ASU Libraries
Serials Solutions EJ Portal - ASU Libraries
Citation Linker (SFX) - University of York
Summon - University of Queensland
Google Scholar - with Harvard
Of the two methods, users instinctively do an article title search unless first trained by a librarian. But we as librarians know that if we want to be sure if an article is available, a source title search approach by searching for journal title is the best method because search engines that index article titles don't cover everythng we own.
Warning : What follows is overly complicated, over-thinking that provides hold little value. Feel free to skip to the comments and post what method you use yourself or use to teach others when they ask you how to find a known article.
Phew! I am so used to doing this, I can almost do this instinctively but in fact there are many pitfalls, some specific to our system some not. Below are some fairly common one to most systems.
First the obvious. For this method to get reasonable amounts of accuracy the library has to have a policy of catalogues all journal subscribed even those subscribed in a database or aggregator. While many libraries do, some don't and simply create a MARC record to the database. E.g There are libraries that have a library record for Business Source Premier, but don't catalogue separately (or upload journal titles to the OPAC) each journal in it.
Depending on the size of the collection this can be a huge undertaking. Assuming this is done, there are other issues to do with user error.
4) Inaccurate journal holding or coverage dates
You need to navigate two different systems, the OPAC first, and once you reach the ejournal/database platform you will need to hunt around for the right way to access the article by either searching or browsing.
Add to the fact that there are so many platforms out there that are constantly changing, even an experienced reference librarian if sent to some unfamiliar interface may have to spend minutes looking for the right place to browse by issue, figure out where to click to download.
2) Depending on workflow for Journals subscriptions, may be the most accurate method
This varies from library to library. For my place of work, definitely this is true. I have no idea if OPAC centric journal collection is still the rule for most, or do libraries focus more on their Ejournal A-Z lists see below.
With economies of scale that come from mistakes found being corrected for everyone this can lead to a far more accurate journal search by title or issn then any one library can manage. This makes searches by journal abbreviations etc more likely to work.
Depending on your library workflow, the Journal A-Z listings may have more or less accurate data than the OPAC, depending on where your priotizes lie and where the source comes from.
I always wondered if one could also, maintain ejournal holdings in the A-Z listing like Serials Solutions 360Core, maintain print only MARC records of journals in the OPAC, then combine both in a web scale discovery product like Summon.
It gets even more complicated if you use SFX link resolver with Summon so you need to maintain two knowledgebases on top of the OPAC?
In particular, in some cases the target does not allow OpenURL linking to the article level and drops the user at the journal level, which of course is almost the same as first searching by journal title!
The disadvantages are similar as well
So you may have access via subscription agent like Swetwise or aggregator like Ebscohost but Google Scholar's would not know and send you direct to somewhere typically the publisher's version ("Publisher's full-text, if indexed, is the primary version") where you have no access.
You might think the article title first approach is is the fastest possible way to get a known article in terms of number of clicks, but you can in fact speed this up.
To repeat searching using Google Scholar or Web Scale Discovery involves
1. Typing article title in search box
2. Scan results list (hopefully only one) and clicking on result
3. Authenticate here or after step 4
4. Scan Link resolver page for results and click on appropriate result that brings you to the article page
5. Scan article page and click on download pdf link or button
If you are using Google Scholar with a link resolver or a WebScale Discovery product like Summon you will usually see the link resolver page (#4). But is that screen really necessary?
Of course, Google Scholar + proxy bookmarklet avoids #4 but that has drawbacks already stated since it doesn't take into account the library's collection.
The link resolver page can be bypassed if you turn on one-click functionality in SerialsSolution 360link (OpenURL resolver) so it always sends you to the first option available if multiple options are available if your library happens to have the article in multiple places.
One-click option is nice, but OpenURL linking is well known to be unstable sometimes, so SerialsSolutions tries to handle this problem with a "helper window", actually a Iframe so users can go to the link resolver screen if the direct link fails (See above).
Besides this option, depending on the Discovery platform you use there may be "direct linking" options that don't rely on OpenURL at all. Both ways you don't see the additional OpenURL screen.
In fact a study has shown that 23% of students tested actually got stuck at the link resolver screen! So perhaps it would be good to bypass that screen if possible. So let say you do that.
Still is the following the fastest (in term of clicks)?
1. Typing article title in search box
2. Scan results list (hopefully only one) and clicking on result
3, Authenticate if necessary and brings you to article page (with helper window for one-click OpenURL)
4. Scan article page and click on download pdf link or button
You can actually one up this by skipping #4 and offering downloading of the PDF from the search engine page . This is in fact the selling point of Pubget.
As shown below, you search for the article in Pubget and you don't even need to go to the ejournal page, there is a "Find PDF" button that will automatically get you the pdf so you don't even see the original Ejournal article page.
I am not familiar with the inner-workings of but I assume it's somewhat like a openurl resolver except it "knows" for a certain journal/platform the correct way to accesss the pdf direct with a contructed url so you don't even need to land on the ejournal page.
You might think this isn't a huge improvement to bringing you to the article page and then clicking download, but many users just want the pdf to download, they don't care to go to the ejournal page to struggle with the diverse and varying user interface to hunt for the link to the pdf etc.
But since this method usually requires at least a journal title or ISSN, it should be the former , in any case I left it for last.
This is actually using OpenURL with the user manually providing the data needed in a form. So there is no article level index, and theoretically this should outperform article level indexes even if both are using the same journal holdings or knowledgebase.
But basically article finder/citation linker is not relying on article index. It requires on 360core which is a journal level index. Given the journal and certain other metadata such as author, issue , date, starting page, the OpenURL can "guess" the correct url to construct that will get the user to the full-text.
4) Time confusing since you need the whole citation to maximize chances
Bonus method - DOI resolution
Articles have unique indentifers like DOI, PMIDs that can bring you to an article. The main problem with using that is, not all articles have this! Another problem, failure to cope with the appropriate copy problem unless paired with a OpenURL solution.
If the same knowledge base with holdings are used accuracy in descending order (online only) seems to be
1. Journal A-Z list/ OPAC - Browse by Journal
2. Citation Linker
3. Discovery service eg. Summon
#2 may fails to get articles by manually browsing #1 because of problems with OpenURL linking. While #3 even if informed by the same knowledge base and journal holdings is subject to the article being indexed on top of issues related to linking via OpenURL (usually).
For my library the most accurate method typically involves the following algorithm
So which is on average faster?
A) Search Google Scholar by article title and use proxy to access, if that fails, re-research by journal title in OPAC
B) Search by journal title in OPAC
While in 10% of the cases you would fail to find full text and need to search the catalogue by journal title to confirm if it exists. Say that takes 10 mins on average.
Simple maths should show it is more efficient on average to search using Google Scholar first then re-search in OPAC only if it fails, than to always try searching OPAC.
In any case I would estimate from fastest to slowest to complete/terminate one search (terminate could mean successfully find the article or failure)
2. Summon + OpenUrl (one click enabled or direct linking) or Google Scholar + OpenUrl (one click enabled), Google Scholar + proxy bookmarklet
3. Summon + OpenUrl (normal) or Google Scholar + OpenUrl (normal)
4. Journal title search using Journal A-Z
5. Journal title search using OPAC
But let's get back to the example where we compare searching Google Scholar first and a re-search in OPAC with journal title vs searching OPAC with journal title only.
It's fairly easy to estimate average time for each step, somewhat harder to estimate would be the probability of getting a hit so you stop the first time. This would be a function of a) How big the article index is (for cases where you search for article title in Summon or Google Scholar) and b) How large your subscription/collection is (for article title first approaches and source title first approaches).
A) is intuitively true, the larger the article index you searching for, the more likely the step will terminate with success. B) is true as well if you think about it. The larger your subscription/collection the more likely you won't have to do a re-search.
E.g If there are only 1,000 articles in the universe and Library A *really subscribes* to 990, vs Library B that *really subscribes* to 10. No matter what method you use, the search will tend to terminate the first time with less re-searches for Library A. The latter library B will almost always have to re-search and still fail anyway.
Think Google's auto-complete/auto-suggest as you type in the article title it would suggest closest matches drawn from it's known article index. Of course you could do this to assist in entering other fields for say Author, Journal name in the Citation Linker etc.
Talking about Google, how about a Google instant version? Yes, I know technically could be tough to display the full article due to authentication, though I wonder if it can just show the brief record with metadata.
I am not a system or even eservices librarian, so my understanding of systems relating to journals might be off-base, if so do let me know, I am always trying to learn.