Primo

OPERATIONAL REQUIREMENTS

1. Equipment needs
2. Authentication
   • CCLA - Users need to be able to access as unidentified "guest" or as authenticated user
   • FCLA - Ditto
   • CCLA - If user is authenticated, the default search should filter their searches and point to the collection in that users home library (sub-library). They should be able to expand the search incrementally; to holdings of the institution, union catalog, Z39.50 search of other catalogs, etc.
   • FCLA - Ditto plus the need to include/suppress specific digital content based on rights management
   • CCLA - If user is authenticated, the default search should filter access to e-resources that are licensed for use by the user
   • FCLA - ditto
3. Authorization
4. Setting priorities
5. Flexibility independent of the design of the product works for all libraries – one install
6. Assumptions for stated architectures are known
7. Economies of scale and scalability
   • FCLA: we would want to be able to create a single PRIMO instance for a "union" catalog with the ability to allow users to search institutional subsets for a logical catalog otherwise the cost and maintenance would be unacceptable
8. Integration capabilities
   • what are the product suites
9. Monitoring and troubleshooting
10. Redundancy?
11. Hosting services
12. Batch services/real time (how maintained on a regular basis)
13. Maintaining currency
14. Design issues – harvesting; extract process time consuming
15. Upgrades
16. Hosting: Purchase or a service
17. Authority
18. Cost
    • ISSUES NOT DISCUSSED added by FCLA (Michele) Cost: we just got a quote from Endeca. For our 13 million bib records, with the kind of discount NCSU got and with their willingness to "work with us": $950,000. If we weren't higher ed, it would be more like $3 million. If we wanted to add our DL metadata and do separate PRIMOs for each university as well as a "union" one, then we're talking astronomical numbers instead of merely ridiculous.
    • Ex Libris required 3rd party software - the impact of licensing costs and restrictions on scalability (Maureen, SUNY)
19. Impact on levels of service
    • operational support for Aleph, SFX and MetaLib is already overwhelming
20. Backup and recovery process

FUNCTIONAL REQUIREMENTS

1. Interface needs
   • Carey SUNY - Interface should have 2 levels of customization. The default should be minimal, branding only. The second should be complete customization through x-services like functions such as with Metalib. Options for faceted browsing or defined by ongoing assessments. Include spellchecking, stemming and synonyms.
   • Linda PALS - Interface should be customized for the user. That is, show what full text is available through their institution's license agreements, know what their institution owns, and show a Get It button for items that need to be requested.
   • CDL - need greater flexibility in ExL UI – too many things are hard-coded and it is way too graphics intensive. The ability to modify the UI and have those changes in place after an upgrade is essential. At a minimum, variable names and functions need to be the same across versions.
   • CCLA - complete separation of data presentation, display logic and data retrieval, preferably through XML, to simplify customization and long-term maintenance.
2. Interoperability
   • Carey SUNY - interoperate with knowledgebases from multiple vendors, open source options. Same with metasearch tools and OpenURL and major higher ed portal providers. Interface with standard databases including Oracle, Postgress, SQLserver. Harvest from Blackboard, Angel, etc.
   • CCLA - develop PRIMO in such a way as to openly allow both the generation and consumption of XML and Web Services. This will insure future compatibility and interoperability with other third-party products, as well as the ability to customize the product in ways that make sense to individual institutions
   • CDL (we want greater interop between products, and reduced costs because of it. Example is paying for 3 versions of the global KB, when we own Metalib, Verde and SFX. Permissions/access, workflow all need to be designed in from the ground up. Example – who can push from Verde to SFX, or who can push from SFX to Verde? How is this enforced, and what visual cues in the interface are needed.
3. Branding at what level
   • Carey SUNY - Branding should be at the campus/library level. Graphics and names only
4. Structured user testing
   • Carey SUNY - Test how undergrads, grad students and faculty use faceted browsing tools.
   • Linda PALS - add public library patrons and school patrons to the list. Also test ease of use of the product.
   • CDL - this is a MUST!!! We need to see the ExL test plans and cases and have an opportunity to review them and give input. otherwise, we spend time re-testing what’s been done.
5. Indexing
   • Carey SUNY - Indexing should take advantage of multiple processors in machine. Indexing options should be minimal.
   • CCLA - indexing should be done in parallel mode with little or no downtime.
   • Linda PALS - Indexes should be easy to change/add/delete. Need to be able to re-index without downtime.
   • CDL – must be done faster.
6. Faceted Browsing (CH SUNY Added)
   • Carey SUNY - leverage LC Authorities for topical. Allow some options for type/display based on user testing.
7. Speed/processing
   • What does it take to run it – background processes
   • Linda PALS - Must not require downtime. Must not degrade functionality or response time. Have option to make available to library staff without requiring direct access to UNIX server.
   • CDL – must be done faster. must be scalable, and be reflective of our consortial environments.
8. What does it take to run it – background processes
9. Documentation
   • Linda PALS - Needs to be available in its entirety at or before product release. Updated documentation needs to be available at the time of upgrade releases.
   • CDL - it is not acceptable to have a 1400 page document. Ever. there is no feedback loop between the CRM system and online documentation. Documentation is stale, it should be constantly improved. It should NOT be written by programmers, ExL should hire industry experienced documentation specialists to write and test the documentation.
10. Scalability – tie with economies of scale
    • CH SUNY - searching and indexing should be spread across multiple servers for scaling and redundancy.
    • Linda PALS - Works for large numbers of libraries and large numbers of records from many different sources. Easy to add or remove a library.
11. Resource sharing
    • How it is integrated
      • delivery options and how configurable
      • how to outline the options “get it”
      • mediated
      • delivery format
    • CCLA - in the delivery options, need compliance with standards such as ISO and NCIP
    • Linda PALS - mediated and unmediated.
12. Enrichment services – List services LaSSSI would like to see
    • Carey SUNY - Book art, first chapters, reviews, etc. Tie to Syndetics, Content Cafe, Amazon, etc.
    • Carey SUNY - allow folksonomy, reviews, linking to content in qualified repositories. Chat?
13. Social Software (social computing – user driven)
14. Privacy
15. Stability - (added by Linda PALS)
    • Functionality must be stable in large scale shared systems. Functionality must be tested in a large scale shared system, with at least 10 libraries. New versions must be tested to ensure no regression takes place.
16. Deduplication (added by FCLA)
    • If desired, there should be an ability to de-duplicate the bibliographic records loaded into PRIMO while retaining the necessary data to link back to the relevant Aleph records so that a) the database size can be reduced and b) FRBRization can be more efficient
17. Statistics
    • what does Ex Libris see as statistical output
18. How does this differ from SFX/MetaLib