IPIG
ILL Protocol Implementation Test Beds
For More Information,
contact
the ILL Application Standards
Maintenance Agency,
Library and Archives Canada
Last Update:
2001/02/19
Interlibrary Loan Application Standards Maintenance Agency
Issue: No "reason-unfilled" in FORWARD-NOTIFICATION service
Consolidation of Postings to the IPIG Mailing List
Monday, 23 March - Friday, 27 March 1998
During the week of 23-27 March 1998, there was broad discussion on the IPIG mailing list because there currently is no way to record information on the "reason-unfilled" in the FORWARD-NOTIFICATION service.On 23 March 1998, Linda Driver, RLG, identified the problem:
In the protocol, if a requester has supplied a list of lenders in the send-to-list, and if the permission-to-forward flag is set TRUE, then the responder may forward the ILL-request and send a Forward-Notification APDU to the requester. In this scenario, the responder doesn't send an ILL-Answer with reason-unfilled. Thus, there is no way to generate statistics on reason-unfilled on requests that have been forwarded.
Obviously, you could instruct your application to count Forward-Notification as an "unfilled" transaction, and perhaps use the notification-note to place a reason, but this is not a very reliable solution. It seems as if Forward-Notification needs to have additional parameters to capture this type of information.
In RLIN ILL, the forward command allows the responder to indicate that the request is unfilled and to give a reason; this data is then captured for statistics.
I know that our users want this type of statistical data. I'm sure others out there will feel the same way.
Barbara Shuh, NLC, asked Linda to clarify her scenario: Is the reason why the original responder has forwarded the request useful to the requester or only to the responder?
As you are describing it, you talked of the responder wanting to record the reasons it has not been able to fill requests (which it has then forwarded to another potential responder). But does the requester need to know this information?
If the requester probably doesn't care, although is keen to know that the request has been forwarded on to another potential responder, then it is not necessary to communicate this information back to the responder, but just to record it in the ILL application used by the responder. If the info is not being communicated between the ILL partners, then it probably doesn't have to be part of the protocol spec. But RLG and others can set up the local application so that system users can record the reason unfilled in the ILL transaction record for local system use.
Linda responded:
Yes, the requester needs to know this information. The requester is gathering statistics for all "unfilled" transactions (usually via ILL-Answer, which has the parameter reason-unfilled), but when a request is forwarded, the requester has no way to collect this data.
Mary Jackson, ARL, commented, as a former manager of a high volume ILL operation:
Many users do want to know why particular libraries are unable to lend the item. If the ILL request is ultimately unfilled, users will want to know if the item is available for on-site use (reference, special collection, etc.) if the item cannot be photocopies but filmed (response from another special collections), or is not owned/lost (response from a third library). The user could make plans to visit the first or second libraries, or initiate a request for a film copy from the second library, and would know not to "bother" the third library.
So, it is most definitely info the requester needs/wants. As the second or third library on that lender string, I really don't care (as a responder) why the first or second library could not fill the request. The fact that another library couldn't find the item is not helpful to me, the next responder in line.
So, Barb I am not sure if you are correct in interpreting Linda's question, and as I reread Linda's posting, I suspect the confusion may have stemmed from third paragraph in which Linda states that there is no way FOR THE REQUESTER (or the responder) to generate stats on reason-unfilled. The stats are being used for two separate purposes.
And, Barb, can you clarify what you meant by the first sentence in your third paragraph...specifically..."then it is not necessary to communicate this info back to the responder." It is the requester that wants to receive this info (not send back to the responder info send by that responder).
I agree with Linda that there may be something missing...
Barb responded to Mary's message:
When reading Linda's original message, it was unclear to me whether the requester wanted the information - but Linda has since clarified that. I'll discuss with Joe after he gets back from holidays.
Ruth Moulton commented:
I suppose one solution is not to let the intermediary do the forwarding but let the original requester send requests to each of the responders on its list directly, that way the requester will get all the answer responses itself and be able to analyse them.
Linda responded to Ruth:
The scenario you described requires user intervention to redirect the request to the next potential responder in the send-to-list. Perhaps the application could be made smart enough to redirect the request without user intervention, but it seems more logical to use the forward service and make the Forward-Notification APDU more informative. Perhaps this is a version 3 enhancement?
Ruth responded to Linda's comment about a smart application:
Yes - this is what I was assuming. I guess your app is already smart enough to
- get a list of responders from the user to put in the request that's sent to the intermediary
- process ill-Answer messages in order to gather statistics on failed requests
So maybe the next step (try more than one responder) is not so large to take "the forward service and make the Forward-Notification APDU more informative."
But what you are suggesting is sending a request to an intermediary and using the intermediary as a smart forwarding facility, if I understand your point correctly?
John Leahy, ALS, commented to Linda:
It just happens that we have taken the approach that you described - if we receive a negative response via an Ill-Answer message, such as Unfilled or Retry, we try the next lender in the list of lenders assigned to the request. It's an action that's "outside" of the state machine, strictly speaking.
It does seem that the Forward Notification APDU needs more information, explaining why the targeted provider wasn't able to fill the request. If that were present, then the requester would have the information it needs for reports. Gotta have the reports!
Margi Mann, WLN, responded to Linda and asked a question about the FORWARD-NOTIFICATION service:
I agree with you wholeheartedly that we need to improve the protocol so, "automatedly", responders/intermediaries can tell requesters why they declined filling the item and forwarded it to new responders/intermediaries.
That said, is there some reason we can't use the notification note in the FORWARD-NOTIFICATION service? The service definition is vague about the values, if any, that can go in this field.
I have another question. When I was grappling with the subtleties of the FORWARD and the FORWARD-NOTIFICATION services, I noticed that the FORWARD service has a notification note which is defined as "additional information supplied by the responder to the requester...". Yet the FORWARD service itself is defined as a service used by the responder to forward the request to the next responder, not the requester. What am I missing here?
John commented to Margi:
Even though the FORWARD service goes to another potential Responder, perhaps the intention is to tell that responder what the intermediary told the requester in its FORWARD-NOTIFICATION service, so everyone's on the same page.
Barb clarifies the use of the FORWARD-NOTIFICATION and FORWARD services for Margi (and others):
One of the subtleties that perhaps you have missed when looking at the FORWARD service and the FORWARD-NOTIFICATION service is that the FORWARD-NOTIFICATION service is used by the service-provider, while the FORWARD service is used by the responder.
The FORWARD-NOTIFICATION SERVICE and the EXPIRY service are the only services which are "provider-initiated". (Check ISO 10160 Table 1 for a tabular representation of the Mapping of Service Features to Services that indicates this.) These two services differ from the other ILL services that are initiated by a request from a service user (i.e., a requester, a responder or an intermediary).
Another thing to note is that the FORWARD Service is the only ILL service which does not have an equivalent APDU, but uses the ILL-REQUEST with a "forward-note" added. And note that forwarded ILL-REQUEST does not carry the "notification-note."
In the FORWARD service, the requester can record the "notification-note" information in the ILL-transaction as part of the FORWARD service. But that note is used, not in the forwarded ILL-REQUEST APDU, but in the provider-initiated FORWARD-NOTIFICATION APDU which is sent back to the requester. If I understand it correctly, the protocol machine (i.e., the service-provider) automatically initiates the FORWARD-NOTIFICATION service (generated automatically by the protocol machine) rather than having it initiated by a service-user.
As to whether the notification note is an appropriate place to send back to the requester the reason why the request was unfilled, it could be done, but unless we agreed on formats for the information, it would only be eye-readable and couldn't be used when compiling statistics.
As I said earlier, Joe is off painting this week. And I don't write code and I don't want to make any suggestions as to how we can handle this until I can confer with him as my "technical advisor." Probably there could be some sort of extension...
John thanked Barb for clarifying the issue and asked:
Is it preferable to add an extension (to FORWARD-NOTIFICATION) because that means the IPIG can just add this to the IPIG profile, as opposed to adding a "reason" as in ILL-Answer, which would be something that would have to wait for version 3?
Barb responded to John's question, talking generally about the use of extensions and the reasons for placing the change in the standard rather than in the IPIG profile:
If you want to use code now, then it's preferable to add an external for an extension. This gives us a chance to try things out in a less structure environment before adding it to the actual protocol specification. And it's much faster. Once the decision is firm on what is required, changes can be made to the ISO Standard through the amending process.
Although the IPIG profile should specify the external objects that will be used by IPIG implementors, the use of the public externals registered with the ILL ASMA won't be limited to IPIG members.
Most of our attention has been paid to the externals that we have defined for extensions, so I find myself using the terms interchangeably. But the "extension" is only 1 of 13 classes of externals defined for use specifically in the ILL protocol. (Remember the long threads of messages about externals and extensions that we had on the mailing list over a year ago.) I've just registered an external object for defined by RLG for e-delivery-mode and today have been looking at one that has been hidden away on page 34 of the IPIG profile for system-number and should be moved into the public register.
By the way, I'd prefer that we refer to such changes as "proposed amendments", without specifically focusing on the next edition of the standard. Some changes will make it into the 3rd edition of 10161, but I expect that other "proposed amendments" will be tossed around for years before any action is taken, and some could be rejected.
Linda responded to Ruth's comment about sending a request to an intermediary and using the intermediary as a smart forwarding facility:
No, I don't think that was my point. Barb probably covered this in her previous message, but basically forward service allows a responder who can't fill a request to forward the ILL-Request APDU to the next potential responder in the send-to-list, and, at the same time, send a Forward-Notification APDU to the requester (See 10161, Section 8.2.1.)
I'm suggesting that Forward-Notification carry one additional piece of information--the reason the request was not filled. Ideally, Forward-Notification should have a parameter that mirrors Reason-Unfilled.
Currently, in RLIN ILL, when a request is forwarded to the next potential responder (based on a list of responders provided by the requester), RLIN ILL supplies the code "unfilled" and allows the user to give the reason it was unfilled, prior to forwarding the request to the next responder. This information is then used for compiling statistics.
Basically, this functionality already exists within RLIN ILL. Therefore, we would like to provide the same information about forwarded requests when we move into a protocol-based ILL environment.
Barb's suggestion of an extension may be the best short-term solution.
Mike Wheatley gave his support to the creation of an extension:
I agree that it would be useful to have the Reason-Unfilled (optionally) returned as part of the Forward-Notification. For greater flexibility it could be even more useful to have the extension for Unfilled-results rather than just Reason-Unfilled. Then this could then be used to pass back Locations-Info as well as the Reason-Unfilled. This would enable any possible added value of the responder to be captured. And the locations thus provided to be used if the forwarded request eventually fails.
Ruth answered Linda, voting for an extension:
Thanks, I had a different model in my head! - I understand your problem better now - yes, I would add my vote to an extension - the only way to have machine readable extensibility....
Richard Wilson, A-G Canada, also supported an extension:
Adding Reason unfilled to the Forward notification would certainly be useful and I agree that an extension is the way to go.
Ed Davidson, Fretwell-Downing, gave his support to developing an experimental extension:
If this is the model then I'm happy to see the field added in V3 and the extension put in for V2.
In a 2nd thread, Mike asked John what would the RSS do if the responder provided locations with the negative ILL-Answer:
The user should possibly have the option of looking at the locations list (if present) as the user may want to add some of them to the send-to-list (or even to "the next lender list" presumably in your local system). Otherwise the locations would be lost?
And John responded:
Thanks for the suggestion! We allow the user to change the next lender list at any time, but capturing this information would be very useful.
Richard Wilson commented on this second thread:
I'm not so sure about locations. Presumably the forwarding library could just add locations to the send-to-list, assuming the Requestor set Permission-to-change-send-to-list to true. In this case the Requestor would only become aware of the additional locations one at a time when she received a succession of Forward notifications, but perhaps that is OK.
If Permission-to-change-send-to-list was set to False, then presumably the Requestor knows what she wants to do and doesn't require additional locations.
Interlibrary Loan Application Standards Maintenance Agency