Release 0.8 – Kuali OLE  Architecture and Design Principles  Overview of 0.8 Functionality  What is currently present  What is missing  What will 1.0 bring in Q4 2013?  Next steps for RUL/VALID

Architecture and Design Principles  OLE depends on a middleware application suite, known collectively as Kuali Rice, which: Provides the Kuali Service Bus – which provides messaging to synchronize, coordinate and load balance the message-driven services of Kuali OLE Provides the Kuali Nervous System -, the main technical infrastructure, storing common reusable codes which can be called upon by processes, enforcing workflow through document use and business processes, and provides a web development framework for further service development.

Architecture and Design Principles Kuali Rice contains: Provides the Kuali Enterprise Workflow– A content based routing engine which supports workflow by maintaining action lists for each individual engaged in a transaction and routing documents to manage each workflow Kuali Rules Management System is a rules repository that sets conditions for workflows involving documents, abstracts business rules from the documents they govern, so they can be readily reused with other documents, changed without changing documents, etc. Includes the new PeopleFlow, a lighter weight routing service that can be used instead of KEW as needed for workflows.

Architecture and Design Principles Kuali Rice contains: Kuali Identity Management– Manages individual person identifies, groups, roles, permissions and their relationships to each other. Works with CAS, Grouper, Shibboleth

Kuali OLE Design Principles Documents  All information stored as documents in a Jackrabbit Document Store, not as tables with individual cells related to databases.  Native documents are XML documents with internal schemas against which they validate.  Any type of document may be ingested, stored and indexed. DocStore is agnostic. So a license may be stored in scanned PDF and as an ONIX-PL XML document. Each are related to each other and can be searched and retrieved.  Associated with information, transactions or maintenance

Kuali OLE Design Principles Workflow  Processes are developed as workflows with documents routed to identified actors that call upon services to act upon the document in a transaction based on rules associated with the document and the actor role by the Kuali Rules Management System. Action List Process: Clickable list of actions awaiting response for each individual logged into OLE Primary actions: approve, acknowledge, complete (add additional info, take the next step), and FYI When required action is taken, it is written to event log and document is routed to the next individual in the workflow.

Select and Acquire Features  Integrates the Kuali Financial System, the enterprise wide financial system, but streamlined for acquisitions workflows  Supports full complexity of acquisitions workflows, with linked supporting documents, e.g.: Changes to purchase orders (adding titles after the fact, with optional re-approval process) Complex invoice processing, with line by line choices, such as replacement in kind, credit, partial payment, etc. Can pro-rate shipping, handling and processing costs per item.

Select and Acquire Financial management (fund accounting, accounts payable, etc.) depend upon the hierarchical documents known as charts, which manage accounts. The root chart is the University chart of accounts (chart at the “U” level, with lower hierarchical “child” levels of organization and responsibility center. COA supports and validates entries into the general ledger for encumbering, expending and accounting for funds Object codes “ Represent all income, expense, asset, liability and fund balance classifications that are assigned to transactions and help identify the nature of the transaction.”

It is not clear how funds management will occur in an organization that is not using KFS or where the library remains a “one off” from the university financial management. Do we make the library the “U” level chart, set up a dummy chart that reflects the University’s fund accounting, or…?

Fund Account Document Requires a stewardship workflow with individual accountability for changes, etc.

New ERMS Functionality  Core license workflows  Documentation of licenses in emerging standard ONIX-PL (as vendors begin to support, will be able to natively load licenses)  Accountability features: Each license must have a steward responsible for the license. May be routed to others with identified roles  Can associate multiple documents of any type with any licensing event, such as request for new license, PDF of signed license, etc.

Describe  Works as a document store, with the ability to associate documents with a bibliographic work.  Current support for MARC, Dublin Core (qualified and unqualified)  Has own Instance record which must include one and only one holdings records and one or more item recordsand may contain one or more items. Based on MFHD. Published XML schema now allows “extension” elements to support unique requirements of users and a new type of holdings record “sourceHoldings” for supporting an external standard such as MARC, MODS, etc.

Describe  Supports loading one record, batch loading, including from OCLC and manual record creation.  Version 0.8 now supports “bound with”. Version 1.0 will support analytics. Nothing is said about RDA in the 0.8 documentation  Appears that little has been done to describe since 0.6, other than some extensibility added to instance records and batch loading.

Deliver  Uses Rice Kuali Rules Management System for the loan matrix  Circulation Desks are set up as documents. Operators are associated with one or more circulation desks (transactions, such as pick up and fines management are associated with circulation desks.  NCIP support and APIs for external ILL services, such as Illiad and Relais will come with V. 1.0  Patrons cannot place holds, request books, etc. Also scheduled for V. 1.0

Deliver Document Types

Deliver Patron record is a concern. Like the instance record, an XML patron record has been developed for OLE. It is designed to interoperate with the Kuali document store for people and students. Documentation is ambiguous about whether this will work with other systems. RUL currently receives information in delimited text. SIRSI does not have XML export except for bib records.

Fund/Licensing Mgt GOKb Fund/Licensing Mgt Shared Bibliographic Database AA (shib, proxy) Patron DocStore OLE in a consortial environment

V 1.0 – Scheduled for 4thQ 2012  Batch ingest of records not mentioned.  Migration toolkit not defined  Integration with Discovery layer not defined.  Statistics not defined. Not clear if circulation history and acquisition history covers this. What about number of titles cataloged, items added, by format, for example?

Possible Next Steps  Install 0.8 on the AWS server (-) Based on comments, people are finding it somewhat problematic to install. (-) May take time and effort away from union catalog (+) Can really kick the tires in each module and determine what is needed to implement, are there deal breakers (+) Can provide feedback while there is still development $$$ (+) Can begin figuring out how to tailor to our needs. Apparently no funding provided to make OLE consortial.

Possible Next Steps Obtain Kuali Rice training for relevant staff. Proposed implementation: Rutgers – Dec 2015 VALID Alpha – July 2016