So DAIA is a nice little response format-slash-API specification from Jakob Voss.
It’s focused on a very specific goal: describing what services are available for a given item, possibly providing URLs to access that service for a given item, telling the user how long they’ll have to wait to get that service, etc.
Some more specific scenarios mapped to my library might make things more clear. For a given item and user, that user might be able to:
- Look at the item in the library. Which they might be able to do immediately (upon finding it in the stacks), or there might be a 1 or 2 business day delay because it’s in some kind of closed stacks or offsite storage, and they’re going to have to request it.
- OR, there might be a longer delay, because the item is currently checked out, and they’re going to have to wait until it comes back — or maybe they have ‘recall’ privileges, and there’s still a delay, but shorter!
- Check the book out? Again, maybe they can, or maybe they can’t at all. If they can, maybe they’re going to have to first ‘recall’ it (if they’re allowed to), with a longer delay.
- Request the book for delivery to a circ desk? Related to recall/checkout, but in rare cases they might be able to request delivery to a circ desk, but only view it in library! And there are cases where they might be able to check it out, but NOT request delivery. Or where they can request delivery, but they won’t get it until the book comes back on it’s own, they have no ‘recall’ privileges.
Now, the answers to these questions, once determined, are easily expressible in DAIA, no problem.
The problem is, as the complicated foregoing discussion may have hinted, that determining the answers to these questions from our ILS is enormously complex. All the info is in the ILS somehow. In the end, either the ILS is going to allow a ‘request’ or a ‘loan’ or a ‘recall’, or it’s not. And there’s info in the ILS to let us predict what’s going to happen, and estimate how long it’ll take until the user gets access (as DAIA allows us to express once we’ve figured it out). It’s all there somehow — but trying to figure out how to actually predict it, oh boy, I get confused really quick. There are dozens of different tables I need to consult in the ILS, and figure out how they interact and which takes priority or overrides which other. Privileges can be set on item statuses, locations, groups, etc. Borrower statuses, groups, types, etc. And they are not set, in my ILS Horizon, in only one place, but in dozens of different places with different semantics that all interact in ill-defined ways.
Phew.
It seems like something a user would expect, in this day and age, that when they look up a book the listing could actually TELL them if they can check the book out (and how long they’ll have to wait to get it, if there’s a recall involved, etc), if they can view it in the library, if they can request it for delivery, etc. Our ILS is currently incapable of doing that — to the extent that it even always displays a ‘request’ button, and the user has to actually click on it to find out if they actually can make a request or not. Which is generally the only way a user can find out what services are available, by trying them. Which depending on the service may or may not be able to be done over the web (can you look at it in the library? Who knows unless you go there and try. Or call a librarian and hope they aren’t as confused as I am!). You want to know how long you’re probably going to have to wait to get it? Too bad.
At first I optimistically thought I could calculate all this stuff from the ILS, deliver it in DAIA, and then use it in new interfaces to actually tell the users what they’re going to want to know. DAIA is quite up to it. But writing code to actually calculate these things — very non-trivial. Not so happy with Horizon right now.
Anyone reading this know about the open source ILS’s? Would this be easier in any of them?
Bibliographic Wilderness 
I’ve recently been pondering about how our (newly upgraded) Voyager web catalogue could provide this information – as you say it’s pretty poor.
I’d be really interested to hear if you happen to make any progress with this. My initial thought too was that it should be fairly easy to calculate this from the ILS, but I’ll accept your word that it’s not! :-)
Well, it might be easier in Voyager, don’t let me stop you! And anything i figured out would be very Horizon-specific.The challenges I ran into were very software-specific. Let us know if you manage something interesting with Voyager.
If its any consolation I doubt any of this is even possible in Millennium! For all Horizon’s limitations it does give you access to the tables, which Millennium does not…
Part of the problem of course is that each library has different rules for reservations, and the ILS suppliers have to code something which can manage the myriad of variations we come up with!
Quite true on both accounts, Ian.
I think another problem is that, looking at the relevant tables and parameters in Horizon, I can tell that they ‘just grew’ over time. My confident guess is that Horizon started with certain configuration related to this, and then someone asked to do something else, and they grafted on a new seperate configuration to over-ride the first and allow that — repeat five or 10 times, you wind up with kind of a confusing tangle of configuration.
Certainly configuration as flexible as Horizon’s is, is going to be nessarily complex in some ways. But if you look at what’s there now and imagine starting over and thinking carefully about how to support that flexiblity as ‘elegantly’ and succintly as possible — it would be possible to do a much better job.
This is a caution for over-source developers too, just like any other developers. Trying to do it ‘right’ instead of just grafting on features in kludgey ways as fast as possible — it DOES matter for future expansion and maintainability.
Software always ‘just grews’ over time. Most Open Source ILS are probably less complex just because they are still younger than closed source ILS. However *good* software is frequently refactored and covered by unit tests so the internals can more easily be changed when they become too complex! I bet that most closed source ILS software has become dirty old software over time just because lack of refactoring, documentation and tests. Let’s ensure that our new ILS projects do not take the same way.