[OPEN-ILS-GENERAL] SPAM: Serials Management and the Collaborative Itch

[Mark Leggott]

Hi Dan,

Just to clarify on this - I am not suggesting that we throw out any  
support for print issues, rather that we enhance the support in the  
current CUFTS system for managing print. (For example, we can easily  
manage the print holdings statement for print journals in CUFTS as it  
is today - some changes would make it even better.) What I am  
suggesting is that we think carefully about how much we need in terms  
of print management, as some of the functionality in current ILS  
systems would be unnecessary.

We have been talking more about this issue at UPEI in the last few  
days and are thinking that the approach that you (and Mike) allude to  
at the end of your response is the most sensible: manage resources in  
the container that makes the most sense and reach in on behalf of the  
user when appropriate, using a native Evergreen, or non-Evergreen,  
interface to do that. A better approach than piling everything into  
the same database...

I'm also sure that grafting a multi-language function onto the CUFTS  
system would not be a huge requirement and one easily met by the open  
source community.

Mark

On 10-Sep-08, at 11:26 PM, Dan Scott wrote:

> 2008/9/8 Mark Leggott <mleggott at upei.ca>:
> <snip>
>> So, how about it? Would this work for other academic institutions  
>> looking to
>> make the switch to Evergreen? What else would you need not  
>> currently in
>> CUFTS? And please don't say predictive algorithms for pre-populating
>> check-in records for print issues - those things don't work well in  
>> any ILS
>> product and who needs them 2 years from now anyway?
>
> I think this would be worthwhile integration. I'm not convinced that
> everyone would be willing to throw out support for print issues, but
> agree that it's a waning concern.
>
> I had asked our electronic resources librarian to take a look at CUFTS
> this summer, because I suspect it would solve a couple of our current
> problems:
>  * maintaining a list of e-resources by subject, which we currently
> maintain manually
>  * providing an a-z list, for which we currently subscribe to EBSCO
> for the reason that they apparently provide better usage stats than
> the SFX a-z list that we already pay for as part of our consortial SFX
> install in Ontario
>  * giving us decent e-resource management (subscription costs,
> licensing information, etc) that we currently manage in a spreadsheet
> today
>
> I think the major barrier for us (Laurentian) is that we need a
> multilingual interface, which CUFTS currently doesn't offer; our
> university is officially bilingual and needs to support switching
> between languages in both the public and staff interfaces.
>
> As for the synchronization question, if both apps were playing in the
> same database, one could use triggers and/or rules to automatically
> and immediately propagate the data from CUFTS that would be meaningful
> to Evergreen. The advantage to a tighter coupling is that you can use
> a single reporting interface to generate reports across all of your
> data.
>
> On the other hand, back at Access 2007 Mike sketched out a small
> vision of (trying to remember, here) federating different search
> backends as OpenSRF search services: basically, wrap your
> non-Evergreen search in an OpenSRF service with some means of
> relevancy ranking across the various services -- ah, the joys of
> federated search! That would seem to be a reasonable means of pulling
> these services together. And now I'll step back and let Mike correct
> my extremely fuzzy memory.
>
> -- 
> Dan Scott
> Laurentian University