The presentations from the Kuali OLE track at Kuali Days 2012 are now available at: https://docs.google.com/folder/d/0B8COwsjidXDCTG43Z1QxUlBfOTg/edit?pli=1&docId=0B3c4Hq1jOIVcbDhMUk1pX0NIcWc
— Molly Tamarkin (Duke University)
Going to Kuali Days 2012 in Austin? Here’s a list of Kuali OLE events:
11: 45 to 12:30 pm Demonstration of the Open Library Environment (OLE) Software to date
2:00 pm to 2:30 pm Institutional Uses of Kuali OLE Document Store (DocStore)
3:15 pm to 4:00 pm Kuali OLE Project Update
4:15 pm to 5:00 pm Kuali OLE Editor Framework
8:45 am to 9:30 am Serving people and libraries with KRMS
9:45 am to 10:30 am Migration plans to Kuali OLE: A tale of two universities
11:00 am to 11:45 am Leveraging Commercial Affiliate in Kuali OLE Implementation
1:15 pm to 2:00 pm Kuali OLE Global Open Knowledgebase (GOKb)
3:30 pm to 4:15 pm Supporting Community and Open Source Software in Cultural Heritage Institutions
Recent conversations have highlighted the problem of libraries having easy access to core, non-proprietary data in a form that is readily usable across a range of systems. With OCLC’s welcome move in the direction of more open WorldCat data, libraries will be able to do much more with bibliographic records, whether in the form of MARC records or linked data.
But what about knowledge base data? KB records for electronic resources are core to acquisition, management and discovery systems. Carl Grant notes that libraries are having trouble getting their data out of their knowledge bases. Even where this is permitted, it is often not easy. At its core, KB data represents factual descriptions of information products that publishers, vendors and libraries all seek to either sell or purchase.
This is where the Global Open Knowledgebase (GOKb) can make a real contribution. GOKb is not a link resolver knowledge base; it is focused on global-level metadata about e-resources with the goal of supporting management of those e-resources across the resource lifecycle. GOKb does not aspire to replace current vendor-provided KB products. But it does aspire to make good data available to everybody, including existing KBs, and to provide an open and low-barrier way for libraries to access this data. Our goal is that GOKb data is permeates the KB ecosystem so that all library systems, whether ILS, ERM, KB or discovery, will have better quality data about electronic collections than they do today.
The GOKb project is still in the early development phase. We are working closely with the JISC KnowledgeBase Plus project to develop this authoritative data source and services for libraries. GOKb has a project page where you can follow its progress.
As Kuali OLE matures toward implementation, the Functional Council has begun to think about how we will reply to requests for proposals, the dreaded RFP with its myriad checkboxes and delightful administrivia. Does anyone like the RFP? Similar to a resume, it in itself is no guarantee of success yet somehow seems vital to the procurement (or hiring) process. Perhaps it’s time to rethink the RFP?
Fortunately, we are not the only ones considering change in this arena. The LMS Change blog has some nice posts on the topic specific to libraries, and there are many resources about this topic generally. My own thoughts, based on years of experience procuring technology both in and out of libraries, drift toward the Aristotelian view that the whole is greater than the sum of its parts (or than the number of boxes checked). I suppose few would disagree with this, but perhaps it’s worthwhile to note the parts which comprise this whole:
- software functionality (okay, these are the boxes… what does it do?)
- software provider: how enjoyable is it to work with them? how responsive are they to your needs? how do their customers get a “seat at the table” to provide input and to shape software development?
- software stack: how well do the component systems integrate with existing tools? if they don’t integrate well, does working on integration carry you forward in new directions or tie you to a legacy system? how open is the environment to external development?
- breaking away: what’s your exit strategy? how hard would it be to migrate to another system or to maintain your current system yourself without external support?
- dollars and sense: open source software isn’t free—we all get this. But how do you want to pay to play? Do you want to write a check and get a support line? Do you want to build skills locally? Do you want a little of both?
- your idea here [what am I missing?]
Even if your procurement process requires the RFP, it may be time to consider how those checkboxes could be altered to capture more about what might be the nature of the relationship with the software provider in addition to particular features. There’s what’s immediately necessary and what’s important for the long haul. Try to get both.