The FCLA Endeca Project By Michele Newberry

M.Newberry2 Current OPAC environment  Aleph 500 v.15.5  Heavily customized to reflect pre- implementation objectives Based on familiarity of previous system Without full understanding of all the support implications  Includes heavy use of Javascript  Some workarounds created functional problems

M.Newberry3 FCLA ALEPH Architecture  11 universities  11 Aleph instances Bibliographic records =14 million Configuration files and tables Joblists and batch queues  11 OPAC configurations  1 OPAC config = >700 files/tables  4 Aleph regions (DEV/TEST/PROD/REPT) X 11 OPACs X 700 files = 30,800!

M.Newberry4 Pending upgrade  Jumping 2 releases to v.18  None of the v.15.5 customization will survive the upgrade process  Resources to sustain level of customization aren’t adequate  Familiarity with previous system is declining  Upgrade process will take 4 months for the 11 Aleph instances

M.Newberry5 Other objectives  Provide a consistent transition interface during the up upgrade process  Gain discovery and navigation functionality not currently available  Gain a union catalog – a byproduct of our previous system not yet available with the current one

M.Newberry6 Why ENDECA?  Already proven by NCSU  Can build on NCSU’s work instead of starting from ground zero  Product features: Guided navigation Facets Spellcheck Stemming Others yet to be fully explored

M.Newberry7 Endeca architecture  One instance of Endeca  One Endeca database  7 million records  One instance of user interface with individual institution views  Easy interface modification  Rapid, iterative development

M.Newberry8 Building the Endeca File  Extract bib records from 11 Aleph databases  Load 1 st into a 12 th Aleph bib file  Load 2 nd file-deduping on OCLC number merge unique and local data (e.g., call numbers/URLS/headings/notes…)  Repeat file 3 … file 11  Load Digital Library metadata  Extract merged bib file to load into Endeca

M.Newberry9 Maintaining the Endeca Catalog  Full extraction, reformatting and load takes 48 hours – will be done every few weeks  Incremental updates of adds/significant changes  Current holdings status retrieved from Aleph via SQL in real-time

M.Newberry10 Next steps …  OPAC Subcommittee is examining Data integrity Functionality Appearance Usability Accessibility  CIRC/ILL Subcommittee will be looking at future SUS-wide request capabilities

M.Newberry11 Next steps …  Technical Services Committee is looking at: Aleph indexing changes for v.18 and effect on Endeca Use of material type codes for more user-friendly results Processes to optimize the consistency of the bibliographic and holdings data feeding into Endeca

M.Newberry12 Much further down the road  Libraries will need to start looking at feasibility of sharing bibliographic records to: Reduce duplication of effort Share authority control Redirect resources into enhancing the data Reduce level of effort to produce the Endeca database

M.Newberry13 READY … FIRE … AIM!!! 

M.Newberry14 Basic Search

M.Newberry15 Search Results

A Closer Look at Facets

Browse the Virtual Shelf

M.Newberry18 Advanced Search

M.Newberry19 Advanced Search

M.Newberry20 Advanced Search

M.Newberry21 Advanced Search

M.Newberry22 Boolean Search

M.Newberry23 A Closer Look at Results Item status is dynamically displayed If item is requestable, displays request link Create RSS Feed for any result set

M.Newberry24 Export Options

M.Newberry25 Patron Empowerment

M.Newberry27 Full View with Holdings

M.Newberry28 Full View with Holdings

M.Newberry29 MARC View (Union)

M.Newberry30 MARC View (Local)

M.Newberry31 Monograph with many Holdings

M.Newberry32 Monograph Holdings Full View

Monograph Detailed Holdings

M.Newberry34 Serial with many Holdings

35 Serial Holdings Full View

36 Serial Detailed Holdings

M.Newberry37 Endeca Record

Endeca Record (large record) …

M.Newberry39 Endeca Record (large record) …

M.Newberry42 Endeca Record (large record) …