Based on vufind-tech conversations, a proposed algorithm for determining the current user's home library. Note that this is untested code and probably needs some extra details added to validate values; however, it should demonstrate the basic idea.
function getHomeLibrary()
{
// Is home library already determined in the session? (This may be a cached value from
// the logic below, or it may have been set by the user via a UI control). If so, send it back:
if (isset($_SESSION['homeLibrary'])) {
return $_SESSION['homeLibrary'] ;
// Home library may be specified via GET/POST or cookie -- all show up in $_REQUEST;
// this allows flexibility in how different sites set up location-specific instances of VuFind.
// You can set persistent cookies on machines at particular locations, or you can create
// custom search forms or links from certain places.
} else if (isset($_REQUEST['homeLibrary'])) {
$_SESSION['homeLibrary'] = $_REQUEST['homeLibrary'];
// If setting did not come from a cookie, we should store one so the setting will remain
// in $_REQUEST even if $_SESSION gets cleared (for example, by a user logging out)
// and the GET/POST parameter is no longer present.
if (!isset($_COOKIE['homeLibrary'])) {
setcookie('homeLibrary', $_SESSION['homeLibrary']);
}
// If no home library was found in the session or the request, default to all available libraries:
} else {
$_SESSION['homeLibrary'] = 'All Libraries';
return $_SESSION['homeLibrary'];
}
}
Notes:
1.) It would be theoretically possible to add IP detection and mapping between the $_REQUEST case and the default case if we wanted to allow home library to be determined by IP range. However, since there is no current demand for such a feature, it was left out of the prototype code above.
2.) There was some discussion of using a user's home library (as defined by ILS) to determine their setting after they have logged in. However, it could be very confusing for users if logging in caused their search results to suddenly change (due to different location-specific filtering). If we want logging in to affect the home library setting, it would only really make sense as some kind of "opt-in" setting, and that seems of marginal value at best. We're omitting the whole possibility for now.
|
More ideas:
- individual themes for consortium member libraries, so libraries may create/configure their own user interface
- ranking based on "home library": boosting of locally held (or even "available) items (the bq parameter of the dismax handler is one way to do that)
- integration of ILL, but we'll need to investigate what can be done here because there seem to be many different ILL policies and ILL protocols out in the wild. Maybe ILL drivers like the ILS drivers?
|
Our implementation of VuFind for the Marmot Library Network has made good progress in implementing a great deal of support for consortia. Our consortium consists of public libraries, academics, and schools so we should be a worst case scenario. Our implementation includes:
Detection of library system based on a subdomain of the opac. I.e. aspen.opac.marmot.org sets up the opac for the Aspen school district. This has some custom code as well as a library table which stores parameters for each system.
Themes based on library system - when a subdomain is used, we optionally override the logos and add a custom css file to each page. Individual templates can also be overridden, but that feature doesn't have many users yet.
Facets based on library system - when a subdomain is used, we optionally override the default facet file for VuFind.
Detection of individual branch by IP address. We have an ip_lookup table that defines the IP address(es) that belong to each branch and custom code to correlate this to an entry in a location table that defines parameters for each branch.
Restriction of holdings to a library system or branch. To do this, we use settings in the library and location tables to apply default filters to the search which can't be removed by the user, and we use some of the scoping functionality built into Millennium to restrict the holdings which are shown (this could also be done by filtering the holdings list).
Sorting of holdings by branch. We sort holdings based on the physical branch a user is in, the user's home branch, nearby locations, and other locations. This involves some custom coding which currently resides in our driver but could be made more generic.
We will be looking into some of the relevancy ranking ideas in an upcoming sprint.
We would be happy to share any or all of this code with the VuFind community.
|
We use an IP based location switcher at http://bibnet.org/vufind
IP based detection in our case is very useful. We use it for individual print availability and for online availability over the german EZB, which affects automatically over 560 libraries without doing anything but transmitting the requesting IP.
The code is very simple. We took it straight from the language selecter. The code is documented here:
http://journal.code4lib.org/articles/4438
|
|
One major downside to using $_SESSION variable for libraries is that persistent URLs for search results can break. If I'm at library A and send a search results page to someone at library B then they could see different content on that page based on their session. To keep the persistent URLs something URL based is likely better, likely using the setevn option.
|
Good point. Of course, it's okay to store the value in the session so that it persists across searches as long as it is also embedded in URLs; a solution similar to that used for VUFIND-357 might be appropriate.
|
|
I am attaching a patch (courtesy of Joe Thornton and the Upper Hudson Library System) which adds a library selector to VuFind using the "building" field in a hidden filter in the search object. This does not address the persistent URL issue discussed above, but it might be a useful starting point for others. If anyone has time to adapt the patch to take the URL issue into account, please share!
|
The Keystone Library Network has implemented rudimentary support for consortia but would really like to see solutions implemented for multi-ILS accommodation, institutionally-themed interfaces, cross-institutional searching, per-institution authentication mechanisms, etc.
For campus detection, we implemented a method for grabbing the user's library either from a variable (campus=universitynumberone) or by IP detection. I think a domain-based solution would be better.
Our current implementation is at http://vufind.klnpa.org/vufind/
We have a few part-time developers who can work on this issue for the project.
Should we report progress here, or would it be better to open another JIRA ticket for each component?
|
|
It's probably easier to keep track of components if we assign each a separate ticket. We can link issues together, so each component can become a sub-issue of this one.
|
|
Sounds good. We're working on an implementation proposal for consortia in VuFind 2. We'll bring that general proposal to the community, refine the points based on the feedback, and then split up the issues from there.
|
|
I've expanded on the current library patch. One thing I noticed is that the autocomplete would return snippets that did not belong to the selected library. I also applied the $_COOKIE['location'] code to initBrowseScreen. I've attached the updated patch for Solr.php.
|
We've been looking into getting a well-established method for a consortial implementation in place. We'd like to stimulate more discussion and take a look at what needs to be done to make this a possibility.
Here's our first look (thanks to Demian for the help): https://docs.google.com/document/d/1R6zhj1JgTCzwP_1zwYk5BNnlkPCexqWhoxf944jeGjA/edit#bookmark=id.2utbhhmuouii
|
Some new consortial functionality (currently implemented only in the XCNCIP2 driver) has been added here:
https://github.com/vufind-org/vufind/pull/166
|
Generated at Thu Apr 25 19:54:11 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100251-rev:2d0d695520e7095763476433152508933e579798.
autocomplete_library.patch