Juice and DAIA and Sakai and Primo

From Owen Stephens:

Juice is a javascript library built on JQuery developed with the intention of making it easier to add additional functionality to library interfaces – see http://juice-project.org/ for more details.

I’ve been working on a project with the University of Oxford called Sir Louie (funded by JISC) which is integrating some of their library systems with their online learning environment (locally called ‘Weblearn’, but the software is Sakai – https://confluence.sakaiproject.org/). Specifically we wanted to add the display of ‘availability’ information in the Sakai Citation Helper tool – basically a tool which allows a tutor to build a reading list – details at https://confluence.sakaiproject.org/display/RES/Citations+Helper

The approach we decided to take was to use Juice to add the functionality, and use DAIA as the format for the availability information. The intention is that using Juice, this functionality could be added to any web environment displaying bibliographic information that can speak to a DAIA compliant availability service.

The result is documented at http://juice-project.org/node/41 (with a few screenshots). If anyone wants to have a go at implementing in an independent environment I’d be very happy to work with them on it and make sure it works.

A few notes on some issues encountered with DAIA – for feedback and if anyone has suggestions how we might have dealt with them it would be very welcome:

Biggest issue was with online vs physical availability. DAIA doesn’t allow (as far as I can see) you to make this differentiation explicit. Which means that if you have a ‘loan’ service with a ‘href’ there is no way of knowing if you have a loanable physical item with a url to some service/display (e.g. reservation, record in OPAC) or an online item with the link to the full-text. We had to work around this by setting up two DAIA services – one for ‘online’ availability, and one for other availability. The Juice extension is designed to allow different display of ‘online’ and ‘other’ as well – partially driven by this issue.

A second issue is that the use of ‘available’ vs ‘unavailable’ with ‘delay’ and ‘expected’ respectively seems slightly unclear to me. It feels like saying something is ‘unavailable until’ or ‘available only after this delay’ are basically the same thing?

The final issue was the more mundane challenge of translating DAIA availability statements into something compact and digestable in the ‘citation helper’ user interface. The decisions I made in implementation were:

If there is an Open Access copy always offer a link to it first above any other information

Aside from this categorise things as either ‘For loan’ or ‘For reference’ – essentially stuff you can take away or stuff you can only use in the library. This is a slightly false division and doesn’t reflect some subtleties like stack request services, but in terms of summarising the available options for an end user it feels like enough – after all for physical items they are going to have to visit the library anyway.

Due to the nature of the service and the available information in this instance all ‘available loans’ are counted as ‘copies for loan’ – so the service summarises overall availability, not current availability (i.e. 3 copies, 2 currently on loan). Clearly being able to express this would be ideal, but we don’t have access to this level of detail from the library systems in question at the moment – which puts the problem of displaying this information in an understandable format to one side for the moment.

Posted in Uncategorized | Tagged , , , , | 1 Comment

One Response to “Juice and DAIA and Sakai and Primo”

  1. Adam Marshall says:

    Comments made by Uwe Reh (University of Frankfurt)

    > Biggest issue was with online vs physical availability. DAIA doesn’t
    > allow (as far as I can see) you to make this differentiation explicit.

    Not really. The attribute ‘href’ may used in the elements ‘available’ and ‘unavailable’ too. But i think to use them is not the best practice.

    DAIA is developed according to rules for cataloging bibliographic records. One of this rules is that material is a mandatory and unique attribute of a title/document/manifestation: http://www.rdatoolkit.org/backgroundfiles/Manifestation_6_1_09-1.pdf

    > Which means that if you have a ‘loan’ service with a ‘href’ there is no
    > way of knowing if you have a loanable physical item with a url to some
    > service/display (e.g. reservation, record in OPAC) or an online item
    > with the link to the full-text.

    (At the level of ‘[un]available’ this is defined by the referenced service) Since material is unique, the information about physical and online availability are implicitly mutually exclusive, so there is no need to
    provide more then one reference.

    > We had to work around this by setting up
    > two DAIA services – one for ‘online’ availability, and one for other
    > availability. The Juice extension is designed to allow different display
    > of ‘online’ and ‘other’ as well – partially driven by this issue.

    Your workaround fits prefect to the rules of cataloging, you are using two different manifestations. 😉
    But I agree, having two services for the same job is quite ugly and it’s a potential performance bottleneck. Let me suggest an other workaround: Rewrite your DAIA service to create two items for printed titles with a link to a online version. One with the informations on physical loan and a link to the lending system, the a second with infos and link to the online document. The second item should have the itemid of the
    ‘physical’ item, padded with some constant string. This may give your client a hint, to render both items together.

    > A second issue is that the use of ‘available’ vs ‘unavailable’ with
    > ‘delay’ and ‘expected’ respectively seems slightly unclear to me. It
    > feels like saying something is ‘unavailable until’ or ‘available only
    > after this delay’ are basically the same thing?

    You are right, the definition is weak. But this weakness is wanted and necessary to express some semantic details.

    Assume two cases in the service ‘loan’:

    1. The item is on loan. The period expires in two days.
    2. The item is on stock, but it takes two days to get the item to the counter/reading room. (external stockrooms)

    In both cases the item is unavailable at loan at the moment, but there are important differences.

    In the first case it is impossible to tell the date of return. It may be something between five seconds or never. We just know the item is not here now, and it is ‘expected’ in the next two days.

    In the second case the date is fix. After the order it takes a ‘delay’ of two days to prepare the item for the patron. It is not possible to describe these and a lot of other cases with a strict orthogonal definition.

    > The final issue was the more mundane challenge of translating DAIA
    > availability statements into something compact and digestable in the
    > ‘citation helper’ user interface.

    “It’s not a bug, it’s a feature.” (hopefully, should be) In the design of DAIA we tried to abstract from the concrete needs of any loan systems.

    Each ILS that I know uses “availability” as a single attribute of a item. This allows compact solutions, but needs a lot of unstructured extensions to handle other services than physical loan.We extended the definition of availability to be a attribute of the tuple (item, service). This makes DAIA powerful, but in some cases it makes the interpretation tricky.

    As you wrote, it is possible to cumulate the availabilities for a compact display information, or you can offer detailed informations.