Atlantic Scholarly Information Network Portal

1. Atlantic Scholarly Information Network Portal Slavko Manojlovich Memorial University of Newfoundland(ASIN Portal Project Manager)and Stephen Sloan University of New Brunswick(ASIN Portal Content Manager) SIRSIDynix European Users Group Conference September 2006

5. Atlantic Scholarly Information Network • Initiative of the Council of Atlantic University Libraries (CAUL). • 17 universities in the Atlantic provinces. • 80,000+ FTE students (+ faculty + staff). • ASIN Borrower’s Card. • Centralized off-site storage. • Consortial Licensing of Digital Resources. • Relais ILL/Document Delivery. • Bath Profile indexing of Z39.50 servers. • ASIN Portal.

6. ASIN Member Institutions

7. ASIN Member Institutions COMPREHENSIVE 20,000+ students

8. ASIN Member Institutions SPECIALIZED – 300+ students

9. ASIN Member Institutions UNILINGUAL – FRENCH

10. ASIN Member Institutions ALEPH ILS

11. ASIN Member Institutions BIBLIOMUNDO ILS

12. ASIN Member Institutions UNICORN ILS

13. The Vision To be the Atlantic resource for scholarly information.

14. Back To The Future(from a CAUL/CBUA Press Release – January 2001) • You should expect to see: • A button on your local library catalogue allowing you to search all CAUL/CBUA catalogues simultaneously (2001 -- technicalities permitting); • A "deliver it to me" option that will supply the work to you from the holding institution quickly (2001-- ditto on technicalities); • Coordinated licensing of electronic resources in the name of the project, allowing all users at all sites remote access (2001-2002);

15. Original Goals of the Project • To give the inexperienced researcher a better way to find information. • Results from LibQual and anecdotal evidence suggested that students were not benefiting from our instruction programs as much as we would have liked – need to improve access independent of instruction. • To build resources co-operatively; provide things collectively that we could not achieve acting alone. • Recent goal: accommodate our differences.

16. Reasons why our users hate us These are the barriers to information

17. Reason 1: ‘Siloed’ Web sites

18. Reason 2: Database Interfaces

19. Reason 3: Confusing Citations

20. Reason 4: No links to full-text

21. Reason 5: Difficult and obscure ILL

22. Reason 5 (cont’d)

23. Reason 5 (cont’d)

24. Reason 5 (cont’d)

25. Reason 5: (cont’d)

27. Goals Re-stated: No Dead Ends! • For an inexperienced user, a dead end is any display where it is not immediately obvious - with little or no instruction - how the user is to obtain the information or the document. A dead end will cause the user to stop seeking the information. • If we examine the previous reasons why users have a hard time with library research, we find these can be seen as dead ends.

28. The first Dead End : Information by format • User often has a subject in mind, not a format. • User wants information, not “journal articles” or “books”. • Explanation needed from Reference staff - not always sought. • User makes a bee-line to Google. There, they know they will get information without having to make a decision on the material’s format.

29. Another Dead End : Database Interfaces • Confusing presentation of information. • Even a user familiar with one database may balk at using a new database with a different look. • Users dealing with a multi-disciplinary topic or faculty (Kinesiology) face the daunting prospect of learning multiple user interfaces. • The same can be said for the user searching cross-disciplinary databases such as Academic Search Elite, Web of Science, Cisti Source, etc. • Especially lost may be those who wish to search outside the normal subject databases (Oscar Wilde as a topic in medical or science databases).

30. Yet another Dead End : Confusing citations • Presenting citations in a common format would lead to greater clarity.

31. Yet another Dead End : No links to full-text • A killer. • User will often abandon the idea of using an item if it involves a manual search to locate local library rights.

32. The last Dead End : Difficult and obscure ILL • When no local rights exist, we need to make it easy and inexpensive (in time and money) for the user to obtain a wanted item.

33. What to do? How can new technologies eliminate the dreaded

34. If we can present the user with one search interface that will present results clearly and consistently, we will eliminate one

35. Federated Search does this

36. Results

38. Federated Searching Features • Searches database targets through Z39.50, API, or HTML screen scraping. • Converts all results to a common XML record syntax. • Search defaults may be configured to match an institution’s requirements (e.g. only search metadata in full-text databases). • Makes links for each record that are appropriate for the resource (full-text, full record from native display, to Resolver for further exploration). • This last is a key point: makes ALL resources (where possible) openURL aware – works well with Resolver.

39. A Brief DigressionFour Methods of Discovering Everything • Multiple searches of native interfaces. • Federated search of native interfaces, APIs, Z39.50, etc. • Harvest, index, and search metadata with links to full-text. • Load, index, and search full-text.

40. Very precise. Each UI can be manipulated by the user to get the best results from each database. Requires an expert user – in subject and in searching. Multiple UIs. Cataloguing and organizing resources can be somewhat taxing. Multiple Searches of Native Interfaces (what most of us offer now) ASIN resources include 400+ resources from 250+ information providers.

41. Fast and easy for the user. Less knowledge of subject and databases required. Results are consistent in presentation. User cannot take advantage of special features of UIs. Vocabulary for searching may differ across databases (books vs. journal databases, subject specific vs. generalized). Requires maintenance by the host of the federated search engine. Federated Searching of Native Interfaces (what the ASIN Portal will do)

42. Scalable. Established procedures and standards (OAI). Quick and easy searching for the user. Vendors, libraries, digital repositories keen to make metadata available freely. Not all sources support metadata harvesting or support it in a standard way. Lots of contacts / maintenance to do by the host. Links to full-text may be difficult to maintain. Software development needed. Harvest, Index, and Search Metadata(the OAI and Google Scholar approach)

43. Full-text always available for the user – no linking problems. User can search metadata or full-text. Long-term preservation of scholarly content. Massive infrastructure and staff support required. Not all vendors would be eager to participate in such a project. Very expensive. Load, Index, and Search Full-Text (Ontario’s Scholar’s Portal built on licensed content and CSAIllumina)

44. If we can link search results to the full-text (where we own it) we can eliminate another huge An OpenURL link resolver doesthis.

45. For some types of resources, Federated searching can do this… But for resources where full-text is in doubt, a Resolver is needed.

46. Steps in Building a Resolver • Install Resolver software and configure each institution. • Multilingual – English and French required. • Load ‘packages’ of journal subscriptions. These form the main part of the knowledgebase. • Handles embargoes. • DOI aware – join CrossRef. • Load local holdings of e-journals and print subscriptions. Knowledgebase complete. • Build links to the catalogue and Relais ILL. • Inform vendors of URLs for Resolvers. • Obtain the blessing of the Godess of PubMed.

47. Resolvers appear in vendor sites… From EBSCO The links lead to a check of the knowledgebase and a “we have it” / “we don’t have it” response. From CSA

48. … but not all Remember this one – we will return to it

49. Resolver links appear in Federated Search results….