Introduction
Following examples from customers and discussions with the Copyright Licensing Agency (CLA), we have made some improvements to Talis Aspire Digitised Content (TADC) to ensure that the reason for an outcome is clearly communicated to you within a request's worklog so that any perceived disparities between actual results of the CLA Check Permissions API and the TADC concierge result are clearly explained.
How it works
Where the CLA Check Permissions API is positive and the TADC concierge outcome has been to refer or reject the request, there has been some concern about the disparity about the TADC concierge outcome and the CLA Check Permissions response.
The reason for this is that whilst a positive response is returned in the CLA Check Permissions API, there are specific uses outlined for a positive response, and we often see a disparity between the concierge outcome and the CLA Check Permissions positive response when it does not include digital copying amongst acceptable reuse, such as in the example below.
Because the CLA Check Permissions result does not know about your holdings, and where it has not been explicit about digital reuse (as above), TADC uses additional information which it does know about, whether the holdings of a resource are in print or digital to make a decision. TADC is able to detect when there are electronic holdings, but is sometimes unable to determine if there are also print holdings as merged library records are typical.
Where we get a positive response which does not explicitly state that digital copying is allowed, and we know that the institution holds the resource electronically, the concierge outcome would be a referral. Historically, it is understandable why users were confused, as TADC did not do a very good job of outlining the reason for the referral, particularly where there are several ISBNs on a request as well, which often compounded the issue.
We have now completed some improvements in our system to make this clearer to the user why something has been referred or rejected and the reasons why.
Starting with our worklog, we are now very explicit about the CLA Check Permissions result.
Historically, this would have referred or rejected as not permitted under the licence. We have changed this behaviour now so that the concierge is explicit about what the result we got for each ISBN is, and we have changed the outcome so that the user is clear that they should manually check this as we cannot determine based on the information we have whether the ISBNs they have are covered.
Additionally, for all other types of responses we are explicit about the exact response received from the CLA Check Permissions API.
Where the CLA Check Permissions API result is Not found - historically we would have just said we were unable to determine if request is covered under the CLA licence but the user would not have known why.
Where the CLA Check Permissioms API has been unresponsive - historically we would have just said we were unable to determine if request is covered under the CLA licence but the user would not have known why.
Additionally, we have included a new feature to enable users to see the exact CLA Check Permissions result (for each ISBN) within the application and the information we have about their holdings so that they can understand why they received the outcome. From the Actions Menu select “CLA Review” this allows you to see the exact CLA Check Permissions response and displays the holdings information we know about each of the identifiers we have used to query about the CLA Check Permissions API and that have contributed to the outcome.
If you get any responses from TADC which you believe varies from the information provided by the CLA Check Permissions, please raise a support ticket as we would like to review any such scenarios following these changes.