NISO Circulation Interchange Protocol
  • Home
  • NCIP News
  • About NCIP
    • The Protocol
    • Extensibility
    • Implementer Profiles
  • About NCIP Standing Committee
    • Meeting Minutes>
      • 2014
      • 2013
      • 2012
      • 2011
      • 2010
      • 2009
      • 2008
      • 2007
      • 2006
      • 2005
      • 2004
      • 2003
      • 2002
    • Members
  • Documentation
    • Introduction to NCIP
    • The Standard
  • Links and Resources
    • Related Standards and Initiatives
    • XML Processing Tools and Utilities
    • Presentations and Publications

April 20-21, 2011 (In Person Meeting)

NCIP Standing Committee
Minutes - In-person Meeting
April 2011
Present
Voting Members
Susan Campbell - College Center for Library Automation (Thursday only; attended 
virtually via Skype)
Rob Walsh - EnvisionWare (NCIP Maintenance Agency)
Mike Dicus - Ex Libris (Chair)
Eric Leckbee - Innovative Interfaces
John Bodfish - OCLC
Tony OʼBrien - OCLC
Robert Gray - Pilot Consulting representing Polaris Library Systems
John Barr - Polaris Library Systems
Kevin Stewart - Relais International
DJ Miller - The Library Corporation
Juli Marsh - The Library Corporation
Observers
Patrick Zurek - The University of Illinois representing the eXtensible Catalog 
(Wednesday only; attended virtually via Skype)
Minutes prepared and submitted by:
Rob Walsh, EnvisionWare / NCIP Maintenance Agency
Page 1 of 26Table of Contents
Welcome and Introductions 3
Agenda Review 3
Implementer Updates 3
Defects and Change Requests 4
Lookup Item Set Service 4
Reported Defects 7
Documentation Projects 10
Recap from Wednesday and Review of Thursdayʼs Agenda 12
The Ambiguous Nature of the Amount Element 12
Introduction to NCIP Document 13
The Future of the NCIP Forum 13
The Implementer Registry 13
Wrap Up 14
ALA Social Event 14
Access Service Conference 14
LLAMA/RUSA STARS 14
Next In-Person Meeting 15
Adjournment 15
Appendix A: Proposed Schema for Lookup Item Set service 16
Appendix B: Draft RFP Writerʼs Guide for NCIP 20
Appendix C: Draft of “Introduction to NCIP” 23
Page 2 of 26Wednesday, April 20, 2011
Welcome and Introductions
Dicus called the meeting to order and welcomed all in attendance. He thanked Stewart 
and Relais International for hosting the meeting. Each person briefly introduced himself 
or herself.
Agenda Review
Dicus reviewed the agenda with the group. No significant changes were found to be 
necessary.
Implementer Updates
Dicus asked each person in attendance to provide implementer updates.
Bodfish reported that OCLCʼs Circulation Gateway is designed to be able to speak 
NCIP. OCLC has tested its first implementation with Biblionicsʼ Apollo product. This will 
be OCLCʼs first Version 2 implementation.
Stewart reported that PALCI is now live with Relais. Further, Relais has completed 
testing with Innovative Interfaces, and several libraries will be switching to NCIP. Relais 
also has implementations with several Voyager libraries, a few SirsiDynix libraries, and 
at least one TLC library. In addition, Lehigh University uses the NCIP Toolkit from the 
eXtensible Catalog (XC) Project to connect Relais to SirsiDynix. Relaisʼ
implementations are a mix of Version 1 and Version 2.
Leckbee reported that Innovative Interfaces is close to having both Dartmouth and 
Brown live with NCIP. These sites are leveraging work Innovative did for PALCI. In 
these settings, Innovative serves as the responder and supports four messages. Relais 
is the initiator. Implementations for Dartmouth, Brown, and the PALCI members will be 
using Version 2. Innovative continues to progress on implementations with MELCAT 
members in Michigan using Version 1.
Gray reported that sites that were using NCIP to connect 3M SelfCheck units to Polaris 
have reverted to using SIP. However, Polaris continues to work with CybraryN providing 
responses to Lookup User requests. Currently, this implementation uses Version 1, but 
CybraryN is working to migrate to Version 2. Polaris has other implementations with 
SirsiDynix sites using URSA in Michigan and Maryland and, more recently, with 
Innovative Interfaces sites using InReach in Michigan and Colorado. Polaris is testing 
with Auto-Graphics for sites in Louisiana. Finally, Polaris supports a Version 2 
responder used by Baker & Taylor for eBooks integration. This implementation supports 
two messages.
Page 3 of 26Walsh reported that, while EnvisionWare historically has struggled to justify NCIP 
development since current SIP2 implementations provide the necessary functionality for 
its applications, recent work on SIP3 has caused EnvisionWare to reconsider NCIP as 
its next generation self-service protocol. EnvisionWare will be seriously exploring which 
approach (NCIP or SIP3) will be most appropriate to serve its future needs. Walsh 
noted, though, that a choice to use NCIP would depend heavily on what support 
currently exists for self-service workflows in ILS products.
Miller reported that he will be leaving the committee and will be replaced by Marsh. 
(Thalia Dixson will continue to serve as the secondary representative for TLC.) All of 
the current TLC NCIP implementations use Version 1.
Dicus reported that Ex Libris has been focused on projects to get Voyager and Aleph 
customers up and running with NCIP. Many of these customers use Relais. Ex Libris 
has seen significant interest from library customers in the northwest United States to 
connect their ILS products to OCLC Navigator with NCIP, and Ex Libris hopes to begin 
working with OCLC on these projects in the near future. So far, all Ex Libris NCIP 
implementations are Version 1. For new projects, though, Ex Libris will reconsider 
whether to continue using Version 1 or migrate to Version 2.
Defects and Change Requests
Lookup Item Set Service
Note: Zurek joined this part of the meeting by conference call via Skype.
Number: 2011-009
Type: Enhancement
Submitted By: John Bodfish on behalf of OCLC, the ILS-DI, and the XC
Submitted Date: 2011-03-01
Subject: Add new Lookup Item Set service
Description: Many libraries today are implementing new discovery 
interfaces (e.g. the eXtensible Catalog, VuFind, WorldCat 
Local, Blacklight, Summon, Primo) that integrate the libraryʼs 
collection with other resources and offer features not 
available in their ILSʼs OPAC such as faceted browsing. 
Often these discovery interfaces use indexes built from an 
extract of their catalogʼs bibliographic information. With this 
architecture there is a requirement to retrieve real-time 
circulation status, location and other item data from the ILS, 
as defined by the “GetAvailability” service in the ILS-DI 
specifications
Page 4 of 26Discussion:
Bodfish outlined a proposal to add a Lookup Item Set service to NCIP. He explained 
that the proposal grew out of a group of people working on discovery interfaces. Their 
goal was to discover more information than was typically available through an OPAC 
search. As libraries began investigating 3rd party alternatives to the OPAC, the ILS-DI 
group defined a set of services that, if supported, would allow other applications to 
display the desired data. NCIP was selected as the protocol. However, as group 
members began to implement the ILS-DI Get Availability service, they realized that 
NCIP requires individual Lookup Item requests, each with its own response, to get 
information about a collection of items. They found this approach to be extremely 
burdensome, and they began drafting this proposal to create a Lookup Item Set service 
within NCIP. This new service would allow applications to request information about 
more than one item and receive all the response data in a single message.
Specifically, an initiator would send a LookupItemSet request that includes either:
* one or more BibliographicId elements
* one or more HoldingsSetId elements
* one or more ItemId elements
The response to this request would be a LookupItemSetResponse message with details 
about any items that match the request. Leckbee asked if the responder should 
respond with all the records that match the request. There may be some in which the 
user is not interested. He noted further that in some instances, this result set could be 
quite large. Bodfish indicated that, yes, all records should be returned and it is up to the 
initiator to determine which to display to the user and in what manner they should be 
displayed. To deal with large result sets, the request message allows the initiator to 
indicate the maximum number of records that should be returned. The responder, too, 
may choose to implement an arbitrary limit on the number of records returned in order 
to protect itself from queries that generate more records than the initiator expects. 
Processing these sorts of queries could potentially yet significantly impact the 
performance of the responding system. It is recommended, though, that the initiator 
always include a MaximumItemsCount element to ensure it cannot be “surprised” by 
overly large responses.
There is a NextItemToken element that allows the initiator to request additional items 
from the result set. This token can be anything so long as it can be used by the 
responder to regenerate the remaining result set at any arbitrary time in the future. This 
approach eliminates, at least in theory, the need for the responder to maintain any state 
associated with the query. The initiator should expect, however, that this approach may 
result in some missing or overlooked items due to changes in the underlying data that 
may have occurred between the initial and subsequent requests. Further, there may be 
instances where a given NextItemToken may simply expire and no longer be valid for 
retrieving any more records. When using the NextItemToken to retrieve additional 
records, the initiator must send the same payload that was sent in the original request. 
Page 5 of 26Otherwise, the responder may not have sufficient information to regenerate the correct 
result set.
Trial implementations using the proposed Lookup Item Set service are up and running in 
a few test environments. The current implementations use BibliographicId (with ISBN or 
OCLC numbers) and HoldingsSetId; however, no test implementation yet uses ItemId 
as the key for the query. It is believed, though, that ItemId would likely be used by selfservice applications where the item identifiers for charged or reserved items would be 
obtained through the Lookup User service.
HoldingsSetId is a new element introduced in this proposal. A holdings set may be 
synonymous with physical copies, but it could represent all copies at a particular 
location or some other grouping based on a shared trait. Some ILS may not have the 
concept of a holdings set, and until now, NCIP has not had a need to represent holdings 
sets since all existing services work with individual items. In the context of this 
proposal, though, one may need to know about a subset of the total holdings, and this is 
embodied as a holdings set. Stewart asked why the proposal does not use Z39.50. 
Bodfish responded that some responders already support NCIP but not Z39.50. 
Further, NCIP defines data elements for items that may not exist in either Z39.50 or 
SRU. Gray asked whether OCLC has implemented this new service in its NetLibrary 
product since that could allow a library to query the number of licensed copies that are 
available for an eBook and use that information to decide whether to purchase more. 
Also, it could be used to show a patron the current hold queue length for a particular title 
where the actual media format is not particularly important. Bodfish and OʼBrien both 
indicated that they do not believe NetLibrary currently has this functionality.
OʼBrien clarified that the LookupItemSet request message must contain either a 
collection of one or more BibliographicId elements, HoldingsSetId elements, or ItemId 
elements. The request may not contain a combination of the above elements. Bodfish 
added that the decision to support only a single identifier type in the request was made 
to avoid excess complexity.
In the LookupItemSet response message, the BibInformation element is new. This 
element serves as a wrapper for information shared by items with the same 
BibliographicId, and without the new BibInformation element, this information would not 
be allowed to be combined. BibInformation contains its own Problem element so that a 
responder may supply as much information as it can to satisfy the request and report 
any issues at a fairly granular level.
The response message is structured in a three tier hierarchy: bibs, holdings, and items. 
Even if the ILS does not have the concept of a holding set, the HoldingsSet element 
must be present, and it serves as a wrapper for the items that make up the result set. 
When the holdings set represents an ad hoc collection rather than some sort of specific 
collection within the ILS, it may be used without a HoldingsSetId. 
BibliograhicDescription is repeated at the holdings level since in some cases the 
bibliographic information may differ, possibly only slightly, from the parentʼs bibliographic 
Page 6 of 26record. In these cases, BibliographicDescription within HoldingsSet may contain only 
that data which differs from the parent. TitleHoldQueueLength represents the length of 
the hold queue if holds are implemented in the ILS at the title level rather than at the 
item or copy level. If holds are immediately resolved to a particular item or copy, the 
TitleHoldQueueLength element would be omitted.
The text of the proposed schema for this new service is included in Appendix A.
Decision:
The group indicated that the proposal is worthy of additional exploration, but some 
minor changes quite likely may emerge. Bodfish explained that the ILS-DI and the XC 
understand that minor changes might result, and they are prepared to address them in 
the early implementations as they arise. The group decided to accept this proposal for 
further study. Bodfish agreed to provide to the group the proposed schema, some 
proposed text for inclusion in the standard, and some examples of messages that 
illustrate the use of this service.
Reported Defects
The group then began a review of the defects reported against the standard since the 
last meeting.
Number: 2011-001
Type: Defect
Submitted By: Robert Gray on behalf of Polaris
Submitted Date: 2010-09-28
Subject: Part 2 of the standard refers to Section 5.4 of ISO 8601 for 
date and time format. However, Section 5.4 no longer exists 
in ISO 8601-2004.
Discussion:
The group compared ISO 8601-2001 with ISO 8601-2004 and discovered that what was 
Section 5.4 in the 2001 revision is Section 4.3 in the 2004 revision.
Decision:
Accept without modification. Update Part 2 of the standard to refer to Section 4.3 of 
ISO 8601-2004.
Number: 2011-002
Type: Defect
Submitted By: Robert Walsh on behalf of EnvisionWare
Submitted Date: 2010-09-28
Subject: In Part 1 of the standard, the Problem element description in 
the Data Dictionary in Section 6 shows the Problem Detail, 
Page 7 of 26the Problem Element, and the Problem Value all as being 
repeatable. In the schema, though, these sub-elements are 
not repeatable.
Discussion:
The group decided that the intent was that these elements should not be repeatable.
Decision:
Accept without modification. Change the standard to agree with the schema.
Number: 2011-003
Type: Defect
Submitted By: Robert Gray on behalf of Polaris
Submitted Date: 2010-11-27
Subject: The links in the Version Attribute section of the standard are 
not valid URLs.
Discussion:
The group agreed that the document should exist at the URL specified in the standard. 
However, that URL in Version 2 is not correct as the schema for Version Attribute was 
never supposed to change.
Decision:
Accept with modification. Update the standard and change the URL to the value 
contained in Version 1. Add text to explain that, as a result of this mistake, 
implementers should treat the URLs from Version 1 and Version 2 as equivalent and 
synonymous. Finally, ask NISO to ensure that the schema document is actually located 
at both URLs.
Number: 2011-004
Type: Defect
Submitted By: Robert Gray on behalf of Polaris
Submitted Date: 2010-11-27
Subject: In the standard, the link to the schema is incorrect.
Decision:
Accept without modification. Fix the standard to use the correct link.
Number: 2011-005
Type: Defect
Submitted By: Robert Gray on behalf of Polaris
Submitted Date: 2010-11-27
Page 8 of 26Subject: The URI schemes for AgencyElementType, 
ItemElementType, and MessagingErrorType are inconsistent 
with other NCIP schemes.
Discussion:
The group agreed that all of the schemes should use a consistent format. 
Decision:
Accept with modification. Update Part 2 of the standard to ensure that all referenced 
schemes use a consistent format that includes /imp1/ as part of the URI. 
Number: 2011-006
Type: Defect
Submitted By: Robert Gray on behalf of Polaris
Submitted Date: 2010-11-27
Subject: In Appendix C, the scheme URIs include a reference to 
v2_01. Should the scheme URI change if the contents of the 
scheme do not?
Discussion:
The group agreed that since the schemes themselves did not change in Version 2, the 
URIs should not have changed in the revision.
Decision:
Accept with modification. Change the URIs to be what they were in Version 1 and 
include text explaining that the URIs will not change in subsequent revisions unless the 
schemes themselves change. When a scheme changes, the new URI will indicate the 
version of the standard in which the change was made.
Number: 2011-007
Type: Defect
Submitted By: Robert Gray on behalf of Polaris
Submitted Date: 2011-01-17
Subject: The description of the NonReturnableFlag empty element 
indicates that the item is returnable when its presence is 
supposed to indicate that an item is not returnable.
Discussion:
The group agreed that this is a defect in the standard.
Decision:
Accept without modification. Change the standard to properly indicate that the 
presence of the NonReturnableFlag empty element signifies that the item is not 
returnable.
Page 9 of 26Number: 2011-008
Type: Defect
Submitted By: Robert Gray on behalf of Polaris
Submitted Date: 2011-01-18
Subject: The change in Version 2 to change VisibleItemTypeId to 
ItemTypeId introduced inconsistencies in the documentation.
Discussion:
This item was withdrawn by the submitter before the meeting, so it was not discussed 
by the group.
Decision:
Request was withdrawn.
Documentation Projects
Dicus opened a discussion of two pending documentation projects: a revision to the 
section of the NISO RFP Writerʼs Guide pertaining to NCIP and a basic educational 
document intended to serve as an introduction to the standard. Walsh asked if the 
needs that originally motivated the group to create these documents still exist. He 
indicated that there are more NCIP implementations in production use than ever before, 
therefore suggesting that a basic educational document many no longer be relevant. 
Further, are RFPs still the impetus that drives implementers to support NCIP, or has 
NCIP proven itself, particularly in resource sharing applications, to be considered the de 
facto standard? Dicus indicated that implementers still need to respond to RFPs that 
may be asking for NCIP, so there may still be benefit to drafting some suggested 
language for how the questions should be phrased so that the answers are useful and 
meaningful. Bodfish suggested that we might write an RFP Writerʼs Guide for the most 
general use cases like resource sharing and self-service. By scaling down the project, 
the group might be better able to complete it. Leckbee suggested that, rather than an 
RFP Writerʼs Guide, we should refer to the Implementer Registry to define what 
products are interoperable with what other products.
The group reviewed the section of the current NISO RFP Writerʼs Guide (http://
www.niso.org/publications/press/RFP_Writers_Guide.pdf) and discussed what might be 
used to replace the bullet point on p.18 asking the responder to identify supported 
Application Profiles. Historically, Application Profiles have been too dependent on 
specific products and specific versions of those products. Ideally, Application Profiles 
should define functionality and the messages that make that functionality possible. 
Anyone should be able to implement an Application Profile to embed that functionality in 
an application. The original self-service Application Profiles were well done in this 
regard because they focused on use cases rather than on implementations already 
present in various products. Stewart indicated, though, that the specifics of each 
Page 10 of 26productʼs implementation may affect the way in which an Application Profile should be 
written. An effort was made to harmonize the various resource sharing Application 
Profiles, and, while there is some similarity at the highest levels, the work required to 
make them similar at the lower levels was not worth the potential gain.
It was suggested that implementers be asked to indicate whether they support the Core 
Service sets. However, from the various implementation updates provided earlier in the 
meeting, it seems clear that there are useful implementations already in production that 
support less than the full Core Services. Gray, though, described the Core Service 
concept as one that is meant to provide guarantees to customers that Product X has 
enough functionality to meet their current and future needs.
Walsh observed that if workflows are, in fact, vendor specific to some degree and if 
useful implementations exist with as few as one or two services, then Core Services, 
Application Profiles, or guidelines for RFPs wonʼt solve the true problems. Even if two 
implementations share the same set of supported services, they may use different subelements (or even use the same sub-elements differently) and thus be incompatible.
Bodfish indicated that the Implementer Registry could become at least a first stop for a 
customer to determine whether two implementations have the possibility for 
interoperability. There might not be any guarantees that the two systems can actually 
work together, but it should be possible to show when they cannot. OʼBrien offered that 
the Implementer Registry should allow interested parties to define arbitrary sets of 
services that are interesting and relevant for their needs and then see how well various 
implementations might be able to meet those needs. To make this useful, the 
Implementer Registry would need to support all NCIP messages so that vendors could 
indicate which they support rather than being limited to just those already identified as 
Core. Leckbee suggested that the RFP Writerʼs Guide could recommend that 
implementers post the details for their implementations in the Implementers Registry so 
that libraries can consider that information as it evaluates the other portions of RFP 
responses and attempts to determine how well various systems will meet their needs.
The group engaged in a review and collaborative editing session to revise a draft RFP 
Writerʼs Guide for NCIP that was begun at the September 2010 meeting. The draft that 
emerged from this effort is included in Appendix B.
Page 11 of 26Thursday, April 21, 2011
Recap from Wednesday and Review of Thursdayʼs 
Agenda
The group quickly recapped the work from Wednesday and reviewed the agenda for the 
remainder of the meeting.
The Ambiguous Nature of the Amount Element 
Bodfish led a discussion that had begun during the March 2011 NCIP-SC conference 
call on the ambiguous nature of the Amount element as it is used within the LoanedItem 
element. FIrst, while the standard currently requires the presence of the Amount 
element, there may be cases where there may not be an Amount associated with each 
Loaned Item, or it may be that the data that should be placed in the Amount element 
may simply be unavailable. Also, there is no clarity around what the Amount element is 
intended to represent in this context. Is it what the patron has already paid to borrow an 
item? Is it the amount that would be owed if the item were to be returned right now? 
Finally, the LookupUserResponse message may also include a UserFiscalAccount 
element that contains thorough details about the various amounts owed by a patron. 
Should the Amount elements in the LoanedItem elements relate in any way to the 
amounts delivered through the UserFiscalAccount element? Bodfish suggested that, at 
the very least, Amount should be made optional inside LoanedItem, and it may need to 
be removed for that context altogether.
OʼBrien indicated that was a mistake to require the Amount element within LoanedItem, 
and it should be made optional. He explained that the most likely purpose for this 
element would be to convey the running, not-yet-final amount for overdue items. Some 
systems donʼt put the overdue fine on the patron record until the item is returned. This 
element might well represent the only place where that information could be delivered, 
and, therefore, it should not be removed. Further, this suggests that the sum of the 
Amount elements contained within LoanedItem elements should not match the 
information contained within the UserFiscalAcocunt element. OʼBrien noted that the 
only rationale he can think of for why the Amount element may have been made 
mandatory in this context was to force implementers to set it to zero when there is no 
amount. Bodfish, however, added that forcing the amount to be zero is problematic 
since it would not be clear whether that would indicate the amount actually is zero or the 
data is not available.
While reviewing the full context of LoanedItem, Bodfish noticed that ReminderLevel is 
also mandatory. This, too, should probably be made optional. Also, when it is present, 
it should allow zero as a valid value to assert that there have been no reminders. 
According to the current schema, zero is not a valid value for ReminderLevel. The data 
type for this element should be changed to “non-negative.”
Page 12 of 26The group decided to make the following changes:
* within LoanedItem, the Amount element will be made optional
* explanatory text will be added to the Data Dictionary in Section 6 of the standard to 
indicate that the Amount element, when used inside LoanedItem, is intended to 
convey the not-yet-final amount of accrued fines associated with a charged item
* within LoanedItem, the ReminderLevel element will be made optional
*the data type for ReminderLevel will be changed to “non-negative”
OʼBrien agreed to make the necessary changes in the schema, and Walsh agreed to 
make the necessary changes in the standard.
Introduction to NCIP Document
The group then reviewed and collaboratively edited the “Introduction to NCIP” document 
that was begun at the September 2010 meeting. The draft that emerged from this effort 
is included in Appendix C.
The Future of the NCIP Forum
The group discussed the NCIPNow Forum and observed that the Forum did not receive 
any real usage after it was posted. Further, it attracted significant hacker activity. As a 
result, the group decided to officially discontinue the NCIPNow Forum and rely instead 
on the general NCIP listserv to address comments and questions about NCIP.
The Implementer Registry
Note: Campbell joined this portion of the discussion via Skype.
Campbell noted that, while the NCIP Implementer Registry does work as it is now, there 
are things that could have been done differently. For example, we did not originally 
anticipate the need to have two individuals from the same organization separately 
providing information to the system. Campbell suggested that she could create a group 
and allow that group to have multiple members. There are other things, too, that could 
be improved. One is to eliminate the 255 character limit in most of the on-screen 
elements; another is to make the forms and the views more consistent with one another. 
However, the effort is likely to take several months since it may require a complete 
rewrite.
Leckbee reported that the tool has been useful for helping customers understand what 
is supported by an implementerʼs system. He did, though, indicate that customers are 
sometimes confused by the registration element. Campbell clarified that registration is 
Page 13 of 26not required to view the information, only to post. In the next revision, she will modify 
the layout of the page to make this more clear.
Bodfish added that we should anticipate much more use in the future since we are 
referencing the Implementer Registry in the various documents we are now creating. If 
Campbell is willing to invest the time, this tool should become a valuable resource to the 
NCIP community. Campbell agreed to confirm that she is able to take on this project. 
She noted, though, that the rewrite will likely be done in Drupal version 6. Even though 
Drupal 7 is currently available, all the necessary modules have not yet been ported to 
that version. Due to the nature of Drupal development, the site may need further 
attention when Drupal 8 is released and Drupal 6 is deprecated. She estimates that this 
might happen in approximately two years. Further, Campbell would like to have 
someone volunteer to serve as the “voice of reason” to validate the tool as it evolves. 
The group agreed to find someone to serve in this capacity.
Wrap Up
ALA Social Event
The group decided to host the ALA Social Event in the Lobby Bar of the Marriott across 
the street from the New Orleans Convention Center. The event will be held on Sunday, 
June 26, starting at 5:30. Walsh will ask NISO about having a sign made to let others 
know where we are gathered.
Access Service Conference
Bodfish indicated that the Access Service Conference will be held in Atlanta November 
9-11, 2011. He asked if we should try to get someone to present something about 
NCIP. Walsh suggested that implementers like Relais, Innovative Interfaces, or Polaris 
might be able to get their customers to talk about how NCIP either has (in terms of 
improvement) or has not (in terms of stability through a technical migration) changed 
their environments. Walsh agreed to participate in the presentation as a representative 
of the NCIP SC if we can get someone to present.
Editorʼs Note: As an afterthought, the eXtensible Catalog might be able to present on its 
model and how it is being used with NCIP to deliver improved or more appropriate 
searching capabilities.
Bodfish agreed to post the conference details to the NCIP SC listserv with hopes that 
someone will be able to get a customer to submit a presentation.
LLAMA/RUSA STARS
The LLAMA/RUSA STARS forum is planning a panel discussion at ALA. The event will 
be held Sunday, June 26, from 10:30-12. Dicus has been asked to participate.
Page 14 of 26Next In-Person Meeting
Walsh offered to host the next meeting in Atlanta, and Marsh agreed to check with 
Thalia Dixson about having TLC host the meeting in Denver. Once she has confirmed, 
the group will vote on the city. At this point, the group tentatively selected October 
12-13, 2011, for the meeting.
Adjournment
Dicus adjourned the meeting.
Page 15 of 26Appendix A: Proposed Schema for Lookup Item Set 
service
<?xml version="1.0" encoding="UTF-8"?>
<!-- ........................................... -->
<!-- NISO Circulation Interchange Protocol ..... -->
<!-- ILS-DI Extensions -->
<!-- ........................................... -->
<!--
Purpose:
 This file defines the XML Schema for extensions to the NISO Circulation 
Interchange Protocol adopted by the ILS Discover Interfaces group
Dependencies:
 ncip_v2_0.xsd.
Change history:
 Version 0.0a (22nd December 2010)
 1) Defined Lookup Item Set and subordinate elements.
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns="http://www.niso.org/2008/ncip"
 targetNamespace="http://www.niso.org/2008/ncip"
 elementFormDefault="qualified" attributeFormDefault="qualified">
 <xs:include schemaLocation="ncip_v2_01.xsd"/>
 <xs:element name="LookupItemSet">
 <xs:complexType>
 <xs:sequence>
 <xs:element ref="InitiationHeader" minOccurs="0"/>
 <xs:choice>
 <xs:element ref="BibliographicId" maxOccurs="unbounded"/>
 <xs:element ref="HoldingsSetId" maxOccurs="unbounded"/>
 <xs:element ref="ItemId" maxOccurs="unbounded"/>
 </xs:choice>
 <xs:element ref="ItemElementType" minOccurs="0" 
maxOccurs="unbounded"/>
 <xs:element ref="CurrentBorrowerDesired" minOccurs="0"/>
 <xs:element ref="CurrentRequestersDesired" minOccurs="0"/>
 <xs:element ref="MaximumItemsCount" minOccurs="0"/>
 <xs:element ref="NextItemToken" minOccurs="0"/>
 <xs:element ref="Ext" minOccurs="0"/>
 </xs:sequence>
 </xs:complexType>
 </xs:element>
 <xs:element name="LookupItemSetResponse">
 <xs:complexType>
 <xs:sequence>
 <xs:element ref="ResponseHeader" minOccurs="0"/>
Page 16 of 26 <xs:choice>
 <!-- A Problem element here means "the entire service 
failed." -->
 <xs:element ref="Problem" maxOccurs="unbounded"/>
 <xs:sequence>
 <xs:element ref="BibInformation" 
maxOccurs="unbounded"/>
 <xs:element ref="NextItemToken" minOccurs="0"/>
 </xs:sequence>
 </xs:choice>
 <xs:element ref="Ext" minOccurs="0"/>
 </xs:sequence>
 </xs:complexType>
 </xs:element>
 <xs:element name="BibInformation">
 <xs:complexType>
 <xs:sequence>
 <!-- Required to be present if the initiation message had 
this BibliographicId. -->
 <xs:element ref="BibliographicId" minOccurs="0"/>
 <xs:choice>
 <xs:sequence>
 <xs:element ref="BibliographicDescription" 
minOccurs="0"/>
 <!-- This is the length of all holds that are *at* 
the title level, *not* a total of all 
item-level holds. -->
 <xs:element ref="TitleHoldQueueLength" 
minOccurs="0"/>
 <!-- These are the requesters for holds *at* the 
title level, *not* item-level. -->
 <xs:element ref="CurrentRequester" minOccurs="0" 
maxOccurs="unbounded"/>
 <xs:element ref="HoldingsSet" maxOccurs="unbounded"/>
 </xs:sequence>
 <xs:element ref="Problem" maxOccurs="unbounded"/>
 </xs:choice>
 </xs:sequence>
 </xs:complexType>
 </xs:element>
 <xs:element name="HoldingsSet">
 <xs:complexType>
 <xs:sequence>
 <!-- Required to be present if the initiation message had 
this HoldingsSetId. -->
 <xs:element ref="HoldingsSetId" minOccurs="0"/>
 <xs:choice>
 <xs:sequence>
 <xs:element ref="BibliographicDescription" 
minOccurs="0"/>
 <!-- If all of the items in this HoldingsSet share 
the same Location data, place that
Page 17 of 26information here; otherwise include it in the 
ItemInformation. -->
 <xs:element ref="Location" minOccurs="0"/>
 <!-- This is the call number for the entire 
holding. -->
 <xs:element ref="CallNumber" minOccurs="0"/>
 <!-- This is a summary holdings statement covering 
the entire holding. -->
 <xs:element ref="SummaryHoldingsInformation" 
minOccurs="0"/>
 <xs:element ref="ElectronicResource" minOccurs="0"/>
 <xs:element ref="ItemInformation" 
maxOccurs="unbounded"/>
 <!-- TODO: Circulation Status Summary? -->
 <xs:element ref="Ext" minOccurs="0"/>
 </xs:sequence>
 <xs:element ref="Problem" maxOccurs="unbounded"/>
 </xs:choice>
 </xs:sequence>
 </xs:complexType>
 </xs:element>
 <xs:element name="ItemInformation">
 <xs:complexType>
 <xs:sequence>
 <!-- Required to be present if the initiation message had 
this ItemId. -->
 <xs:element ref="ItemId" minOccurs="0"/>
 <xs:choice>
 <xs:sequence>
 <xs:element ref="RequestId" minOccurs="0" 
maxOccurs="unbounded"/>
 <xs:element ref="CurrentBorrower" minOccurs="0"/>
 <xs:element ref="CurrentRequester" minOccurs="0" 
maxOccurs="unbounded"/>
 <xs:element ref="DateDue" minOccurs="0"/>
 <xs:element ref="DateRecalled" minOccurs="0"/>
 <xs:element ref="HoldPickupDate" minOccurs="0"/>
 <xs:element ref="ItemTransaction" minOccurs="0"/>
 <!-- If the Location information for this item 
differs from others in its containing 
HoldingsSet, place it in this 
ItemOptionalFields -->
 <xs:element ref="ItemOptionalFields" minOccurs="0"/>
 <xs:element ref="ItemNote" minOccurs="0"/>
 <xs:element ref="Ext" minOccurs="0"/>
 </xs:sequence>
 <xs:element ref="Problem" maxOccurs="unbounded"/>
 </xs:choice>
 </xs:sequence>
 </xs:complexType>
 </xs:element>
 <xs:element name="SummaryHoldingsInformation">
Page 18 of 26 <xs:complexType>
 <xs:sequence>
 <xs:choice>
 <xs:element ref="StructuredHoldingsData" 
maxOccurs="unbounded"/>
 <xs:element ref="UnstructuredHoldingsData"/>
 </xs:choice>
 <xs:element ref="Ext" minOccurs="0"/>
 </xs:sequence>
 </xs:complexType>
 </xs:element>
 <xs:element name="TitleHoldQueueLength" />
 <xs:element name="HoldingsSetId" />
 <xs:element name="ItemNote" />
 <xs:element name="MaximumItemsCount" />
 <xs:element name="NextItemToken" />
</xs:schema>
Page 19 of 26Appendix B: Draft RFP Writerʼs Guide for NCIP
Page 20 of 26
RFP Guide
Revision to the NCIP section
The NISO Circulation Interchange Protocol (NCIP) defines and specifies the objects, services, 
messages, and data elements needed to facilitate interoperability between dissimilar circulation 
systems. NCIP is designed for circulation interaction with consortia (or library groups) that 
have existing agreements to cooperate. NCIP differs from Interlibrary Loan (ILL) Resource 
Sharing (RS) systems in that ILL accepts requests and delivers material from libraries that do 
not have a pre-existing relationship.
Application Areas
Three high-level application areas are defined in the NCIP protocol: direct consortial borrowing, 
circulation/interlibrary loan interaction, and self-service circulation. Functions that permit a 
circulation system to manage controlled access to electronic materials, such as e-books and 
music files, are also included in the protocol. Each of these high level applications uses a set of 
NCIP messages and responses (see section on Structure, below) to exchange information. 
Any library system can design its own high level applications by using and combining messages 
in a way that meets their needs.
Direct Consortial Borrowing (DCB): Some library consortia now share materials among 
members and track them as circulation transactions. In this way the individual circulation 
systems record and track loans without the need for a separate interlibrary loan system. Most 
commonly, DCB has been implemented using a third-party software application interfacing 
between disparate circulation systems. The DCB application manages transactions and uses 
NCIP messages to communicate with local circulation systems.
Circulation/interlibrary loan interaction: The linking of a library’s circulation system and its 
interlibrary loan system is also supported by NCIP. Without NCIP, a library staff member must 
check out an item it is loaning on its circulation system and then update the request in the ILL 
system to indicate the item has been shipped. On the borrowing side, a library staff member 
may need to create a temporary bibliographic and item record in its circulation system to be able 
to check out the borrowed item to the patron. Use of NCIP allows a library’s circulation system 
and its ILL system to exchange information about patrons and items automatically – eliminating 
duplicate data entry, lessening manual intervention, and ensuring consistency in loan 
information and updates.
Self Service: Libraries provide self-service online circulation systems to allow patrons to do their 
own checkout and status tracking. The SIP2 protocol has been used for a self-service machine 
to interact with the circulation system. NCIP also supports self-service applications, including
offline recovery.
Structure
The NCIP protocol is composed of many services; each service has an initiation message (from 
the requesting client to the server) and a response message (from the server back to the client). 
Individual services are combined in groups that deliver high-level circulation interoperability 
between applications. In this way, the NCIP protocol can be considered to be a toolkit for 
building these applications.
Robert Walsh 4/20/11 3:41 PM
Deleted: Three high-level applications are 
defined in the NCIP protocol: direct consortial 
borrowing, circulation/interlibrary loan 
interaction, and self-service circulation. 
Functions that permit a circulation system to 
manage controlled access to electronic 
materials, such as e-books and music files, are 
also included in the protocol. Each of these 
high level applications uses a set of NCIP 
messages and responses (see section on 
Structure, below) to exchange information. 
Any library system can design its own high level 
applications by using and combining messages 
in a way that meets their needs.
Robert Walsh 4/20/11 3:38 PM
Deleted: Profile !reasGroups ... [1]
Robert Walsh 4/20/11 3:40 PM
Deleted: An Application Profile describes how 
the NCIP protocol is used to support a specific 
environment with a given set of practices and 
policies. Each application profile prescribes the 
set of NCIP messages needs to support that 
application.
Robert Walsh 4/20/11 3:35 PM
Deleted: n!as circulation transactions. In ... [2] this 
Robert Walsh 4/20/11 3:36 PM
Deleted: in an!offline recovery mode ... [3]
Robert Walsh 4/20/11 3:43 PM
Deleted: 
Robert Walsh 4/20/11 3:45 PM
Deleted: 46 !any different ... [4]
Robert Walsh 4/20/11 3:49 PM
Deleted: No vendor has yet implemented all 
46 messages; see the section “Sample RFP 
language” below. As mentioned in the 
Application Profile Groups section above, ... [5]Page 21 of 26
Core Services
The NCIP Standing Committee has defined a core set of services aimed at simplifying NCIP 
implementation and increasing interoperability between systems. The core service sets are:
Resource Sharing (DCB & Circ/ILL) Self Service
Lookup User Lookup User
Lookup Item Lookup Item
Checkout Item Checkout Item
Checkin Item Checkin Item
Renew Item Renew Item
Recall Item
Request Item
Cancel Request Item
Accept Item
Undo Checkout Item
Create User Fiscal Transaction
Update User
Create User
Version 2, approved in 2008, brought enhanced extensibility, improved self-service and error 
handling, and addressed issues that surrounded the first version of the standard. Version 2 
includes two parts:
• ANSI/NISO Z39.83-1 - 2008 NISO Circulation Interchange - Part 1: Protocol
This standard defines a protocol that is limited to the exchange of messages between 
and among computer-based applications to enable them to perform the functions 
necessary to lend and borrow items, to provide controlled access to electronic 
resources, and to facilitate co-operative management of these functions.
• ANSI/NISO Z39.83-2 - 2008 NISO Circulation Interchange Protocol - Part 2: 
Implementation Profile 1
A practical implementation structure for the NISO Circulation Interchange Part 1: 
Protocol (NCIP) is defined. 
The NCIP Implementation Group (later renamed the NCIP Standing Committee) was formed in 
2002 to oversee and support the standard and encourage implementation. The NCIP Standing 
Committee is a working group managed by the NISO Discovery to Delivery Topic Committee.
Recommended RFP Language
The following are important points that should be included in an RFP to address NCIP 
compliance:
• The system must support the NISO Circulation Interchange Protocol (NCIP), ANSI/NISO 
Z39.83-1, 2008, NISO Circulation Interchange – Part 1: Protocol 
• The system must support the NISO Circulation Interchange Protocol (NCIP), ANSI/NISO 
Z39.83 – 2 – 2008, NISO Circulation Interchange Protocol – Part 2: Implementation 
Profile 1
Robert Walsh 4/21/11 9:54 AM
Deleted: Another way of looking at NCIP 
messages is based on their behavior. There 
are three significant types of messages:
In 2009, t
Robert Walsh 4/20/11 3:58 PM
Comment [1]: Consider removing this entire 
section. It may be too basic for this particular 
document and would be better to be included in 
another.
Robert Walsh 4/20/11 3:59 PM
Deleted: Messages
Robert Walsh 4/20/11 4:00 PM
Deleted: In 2009, t
Robert Walsh 4/20/11 3:59 PM
Deleted: Implementation 
Robert Walsh 4/20/11 3:59 PM
Deleted: Group 
Robert Walsh 4/20/11 4:01 PM
Deleted: approved 
Robert Walsh 4/20/11 3:59 PM
Deleted: messages 
Robert Walsh 4/20/11 4:00 PM
Deleted: Direct Consortial Borrowing and ... [6]
Robert Walsh 4/20/11 4:00 PM
Deleted: message 
Robert Walsh 4/20/11 4:02 PM
Deleted: Undo Checkout Item
Robert Walsh 4/20/11 4:02 PM
Deleted: Create User Fiscal Transaction
Robert Walsh 4/20/11 4:02 PM
Deleted: Update User
Robert Walsh 4/20/11 4:02 PM
Deleted: Create User
Robert Walsh 4/20/11 4:04 PM
Deleted: and oversees
Robert Walsh 4/20/11 4:05 PM
Deleted: s
Robert Walsh 4/20/11 4:05 PM
Deleted: s
Robert Walsh 4/20/11 4:05 PM
Deleted: by vendors
Robert Walsh 4/20/11 4:04 PM
Deleted: Implementation 
Robert Walsh 4/20/11 4:04 PM
Deleted: Group
Robert Walsh 4/20/11 2:32 PM
Deleted: Sample 
Robert Walsh 4/20/11 2:31 PM
Deleted: are examples of
Robert Walsh 4/20/11 2:31 PM
Deleted: language that cPage 22 of 26
• Which of the following transport protocol(s) does the system support: HTTP, HTTPS, 
TCP?
• Which version(s) of the NCIP protocol does the system support?
• The supplier should ensure that the details of its NCIP implementation are recorded in 
the NCIP Implementer Registry (found at http:// !) so that the Library can determine 
how well the system may be able to meet its needs.
Assessing Interoperability
To assess interoperability, the Library should obtain a list of references with contact information 
for sites currently using supplier’s product(s) with NCIP.
If the supplier has no current NCIP implementations, then the Library should develop 
acceptance criteria that will be applied during the implementation of the selected system to 
determine whether that system successfully meets the Library’s needs.
The NCIP Implementation Profile includes requirements to ensure that different implementations 
will interoperate successfully. For example, the Implementation Profile requires the use of XML 
for message encoding, Unicode UTF-8 for character encoding, and one of three transport 
protocols – HTTP, HTTPS, or TCP/IP. Messages are to be encoded using the NCIP Schema.
NCIP has been implemented by a number of organizations and is currently in production use 
with both Versions 1 and 2.
For More Information
NCIP Standard, parts 1 & 2:
http://www.niso.org/kst/reports/standards?step=2&gid%3Austring%3Aiso-8859-
1=&project_key%3Austring%3Aiso-8859-1=2d46d484a625029ef698b96b7537c334348c8eb8
http://www.niso.org/kst/reports/standards?step=2&gid%3Austring%3Aiso-8859-
1=&project_key%3Austring%3Aiso-8859-1=599708d764b8a1cccb7fad45d74ec70c1b7cb235
NCIP Standing Committee website:
http://www.ncip.info/
ADD Susan’s site when it is done.
Robert Walsh 4/20/11 2:29 PM
Deleted: <#>The system must support the 9 
core messages for either resource sharing or 
self service or a combination of both.
Robert Walsh 4/20/11 2:30 PM
Deleted: Does the system also support 
NCIP version 1, and/or version 1.01?
Robert Walsh 4/20/11 2:59 PM
Deleted: <#>
Robert Walsh 4/20/11 2:30 PM
Deleted: <#>Which Application Profile(s) 
does the system support? ... [7]
Robert Walsh 4/20/11 2:59 PM
Deleted: Compliance
Robert Walsh 4/20/11 3:02 PM
Deleted: conformance 
Robert Walsh 4/20/11 4:09 PM
Deleted: vendors’ 
Robert Walsh 4/20/11 3:02 PM
Deleted: The 
Robert Walsh 4/20/11 4:07 PM
Deleted: Version 1
Robert Walsh 4/20/11 4:07 PM
Deleted: vendors
Robert Walsh 4/20/11 4:07 PM
Deleted: many
Robert Walsh 4/20/11 4:08 PM
Deleted: implementations are still in active 
use.
Robert Walsh 4/20/11 3:03 PM
Deleted: ... [8]
Robert Walsh 4/20/11 2:41 PM
Comment [2]: How does a Library obtain this 
compliance. Should this entire section be 
removed?
Robert Walsh 4/20/11 4:09 PM
Deleted: Implementation 
Robert Walsh 4/20/11 4:09 PM
Deleted: Group
Robert Walsh 4/20/11 3:43 PM
Deleted: NCIP Application Profiles: ... [9]
Robert Walsh 4/21/11 10:10 AM
Deleted: ... [10]
Robert Walsh 4/21/11 10:11 AM
Comment [3]: Make the For More Information 
sections of the two documents identical.Appendix C: Draft of “Introduction to NCIP”
Page 23 of 26
Introduction to NCIP
DRAFT
April 2011
Basics
NCIP (NISO Circulation Interchange Protocol, also known as Z39.83) is a North 
American standard with implementations in the US, Canada, and many other countries 
around the world. NCIP services facilitate the automation of tasks, the exchange of data, 
the ability to provide information to library staff, and the empowerment of patrons. Each 
service is comprised of a request from an initiating application and a reply from a 
responding application. It is possible for a single software application to play both the 
initiation and responding roles, but typically there are at least two applications involved. 
The original vision for NCIP identified three main application areas: Direct Consortial 
Borrowing (DCB), Circulation / Interlibrary Loan Interaction (C-ILL), and Self-Service 
Circulation. Over time, the NCIP Standing Committee (previously known as the NCIP 
Implementers Group) came to realize that the generic term “Resource Sharing” 
encompassed the workflows associated with both DCB and C-ILL.
In the context of Resource Sharing, the initiator is likely to be an application used by 
library staff to request an item from a remote system when the item is not available in the 
local system. NCIP services can be used to query the remote system to determine if the 
desired item is available and, if it is, ask the remote system to send the item.
For Self-Service, the initiator might be a self-service circulation terminal where users 
check out , and possibly check in, their own items. The terminal uses NCIP services 
exchanged with the Integrated Library System (ILS) to check items out to the patrons, 
provide details of the patron account, and allow patrons to perform other tasks like 
renewing items, placing holds, and even updating their own account information.
Because information about testing and implementation is important, the Standing 
Committee maintains an NCIP implementer registry that allows librarians to discover 
easily which initiators and responders have successfully worked together.
ServiceTypes
There are three broad categories of NCIP services: Lookup, Update, and Notification. 
Lookup services are used to obtain information and have no action associated with them. 
Update services direct the responder to take an action when the request message is 
received. Notification servicestell anothersystem that an action has been taken. The 
following table gives examples of the three service types:
ServiceType Examples
Lookup What is the name associated with ID 12345678?
How many books does he have checked out?
 9/14/10 9:42 AM
Deleted: NCIP
9/14/10 10:44 AM
Comment [1]: 
Sep 14, '10, 9:39 AM - Draft 
reviewed 10 Sept. 2010 by John 
Bodfsh, Tony O’Brien, DJ Miller, 
Collette Mak, and Rob Walsh. Edits 
compiled by Rob Walsh.
 9/14/10 9:42 AM
Deleted: CORE MESSAGES ... [1]
9/14/10 10:44 AM
Comment [2]: 
Sep 14, '10, 9:39 AM - Note about 
intended audience: our group 
assumed the audience to be those who 
have heard of NCIP but have little 
knowledge about what it is or how it is 
used. Our feedback is based on that ... [2]
Robert Walsh 4/21/11 9:34 AM
Deleted: by Gail Wanner
Robert Walsh 4/21/11 9:35 AM
Deleted: August …pril 2010 ... [3]
 9/14/10 9:42 AM
Deleted: stands for …NISO Circulation ... [4]
Robert Walsh 4/21/11 9:41 AM
Deleted: harge
 9/14/10 9:52 AM
Deleted: It can be difficult to determine ... [5]
Robert Walsh 4/21/11 9:38 AM
Deleted: I…nformation about testing and ... [6]
 9/14/10 9:48 AM
Deleted: new…NCIP implementer regis... [7] try 
Robert Walsh 4/21/11 9:43 AM
Deleted: is available soon, and it …hat ... [8]
 9/14/10 9:49 AM
Deleted: As soon as it is completed, it will ... [9]
 9/14/10 9:45 AM
Deleted: Message
 9/14/10 9:45 AM
Deleted: messages…ervices: Lookup, ... [10]
Robert Walsh 4/21/11 9:45 AM
Deleted: local 
 9/14/10 9:47 AM
Deleted: and, although no specific action is ... [11]
 9/14/10 9:47 AM
Deleted: Message…ervice Type ... [12]
Robert Walsh 4/21/11 9:59 AM
Deleted: Type Result
Robert Walsh 4/21/11 9:46 AM
Deleted: Item … Lookup ... [13]Page 24 of 26
What are their titles?
Update Check Out this item.
Place a reserve on this title.
Return this item.
Register this borrower as a new user.
Notification My system checked out this item.
My system returned this item.
Core Services
With over 40 services, NCIP provides a flexible toolkit with which to perform many 
types of tasks. At the same time this breadth of functionality can be daunting for new 
implementers. In an effort to flatten this initial learning curve, the NCIP Standing 
Committee has identified two core groups each consisting of 9 services: a resource 
sharing core and a self service core. Five services are shared by both groups and four are 
unique to each application area. The purpose of these core service sets is to allow 
librarians and suppliers to focus on the most commonly supported services and the tasks 
they can accomplish.
The five common services in the core service sets are:
*Check In Item
*Check Out Item
* Lookup Item
* Lookup User
*Renew Item
Check In Item asks the responding system to perform a check in (or discharge) an item 
by sending an item identifier, likely the item’s barcode.
Check Out Item causes the responding system to check out (or charge) an item to a 
specific user as identified by the user’s barcode. 
Lookup Item is used to discover information from the responding system about an item, 
such as title and call number, which is designated by a barcode or other identifier. 
Lookup User provides information from the responding system about a user which is 
designated by a barcode or other identifier. This service is commonly used to 
authenticate users who are accessing library resources online and to convey basic 
information about the user.
Renew Item asks the responding system to renew a loaned item that has been charged to 
a user. 
Robert Walsh 4/21/11 9:59 AM
Formatted: Indent: Left: 0.5", First line:
0.5"
Robert Walsh 4/21/11 9:57 AM
Deleted: Responder finds item &and sends 
desired information 
Robert Walsh 4/21/11 9:59 AM
Deleted: CheckOut Item
 9/14/10 9:47 AM
Deleted: Action
Robert Walsh 4/21/11 10:01 AM
Formatted: No Spacing
Robert Walsh 4/21/11 9:59 AM
Deleted: Triggers checkout of item in 
responding application
Robert Walsh 4/21/11 10:00 AM
Deleted: Item Checked Out
Robert Walsh 4/21/11 10:00 AM
Deleted: Indicates that an item has been 
checked out
Robert Walsh 4/21/11 10:01 AM
Formatted: No bullets or numbering
Robert Walsh 4/21/11 10:01 AM
Deleted: 
Robert Walsh 4/21/11 10:01 AM
Deleted: ... [14]
Robert Walsh 4/21/11 9:46 AM
Deleted: Messages
Robert Walsh 4/21/11 9:47 AM
Deleted: different 
Robert Walsh 4/21/11 9:48 AM
Deleted: , though,
Robert Walsh 4/21/11 9:47 AM
Deleted: recently 
Robert Walsh 4/21/11 9:48 AM
Deleted: message 
Robert Walsh 4/21/11 9:48 AM
Deleted: messages 
Robert Walsh 4/21/11 9:48 AM
Deleted: message 
Robert Walsh 4/21/11 9:50 AM
Comment [3]: Use descriptions from 
Section 5 of the standard rather than creating 
new ones.Page 25 of 26
Resource Sharing Core Services
The four core servicesspecific to Resource Sharing are:
* Accept Item
*Cancel Request Item
*Recall Item
*Request Item
Accept Item provides information about an item in order for the responding system to 
create a temporary record for the purpose of circulating the item to the library’s patron.
Cancel Request Item is used to ask the responding system to cancel a pending item
request.
Recall Item is generated by the lending library and is used to ask the responding system 
to shorten the loan period for an item that has been loaned. 
Request Item is used to request that the responding system place a hold on an item. This 
hold may be placed in the name of the borrowing library, for a “dummy patron,” or for 
the actual end user. 
Self Service Core Services
The four core services for self service are 
*Create User 
*Create User Fiscal Transaction
* Undo Checkout Item
* Update User
Create User allows users to register themselves for a library card. 
Create User Fiscal Transaction automatically records fees or fines charged for a 
service, including fines, fees for use of rental items or computers, and other similar 
transactions.
Undo Checkout Item requests that the checkout transaction immediately preceding this 
message is undone and treated as though it had not happened. This enables a system to 
quickly correct an error such as when the security mechanism on the item checked out 
cannot be properly disabled.
Update User allows the self service unit to update, add, or delete user fields in a user 
record in the responding system. 
Next Steps
Robert Walsh 4/21/11 9:50 AM
Deleted: Messages
 9/14/10 10:27 AM
Deleted: Direct consortial borrowing (DCB) 
and interlibrary loan (ILL) workflow models 
are included in resource sharing. DCB usually 
consists of a single brokering application that 
initiates messages to one or more circulation 
system responders. ILL generally consists of 
interaction between a library’s ILL system and ... [15]
Robert Walsh 4/21/11 9:50 AM
Deleted: messages
 9/14/10 10:28 AM
Formatted ... [16]
9/14/10 10:44 AM
Comment [4]: ... [17]
 9/14/10 10:34 AM
Deleted: ... [18]
Robert Walsh 4/21/11 9:51 AM
Comment [5]: Use the descriptions from ... [19]
 9/14/10 10:36 AM
Deleted: Cancel Renew Item is used when a ... [20]
 9/14/10 10:37 AM
Deleted: Renew Item asks for a renewal of a ... [21]
Robert Walsh 4/21/11 9:51 AM
Deleted: Messages
 9/14/10 10:39 AM
Deleted: Self service machines allow users ... [22]
Robert Walsh 4/21/11 9:51 AM
Deleted: messages 
 9/14/10 10:39 AM
Deleted: Lookup User, Lookup Item, ... [23]
 9/14/10 10:39 AM
Formatted ... [24]
 9/14/10 10:39 AM
Deleted: Undo Checkout Item, …reate User ... [25]
 9/14/10 10:39 AM
Formatted ... [26]
 9/14/10 10:39 AM
Deleted: , and 
 9/14/10 10:39 AM
Deleted: Create User. Since the first five are ... [27]
 9/14/10 10:40 AM
Deleted: 
 9/14/10 10:41 AM
Deleted: users to quickly remove a checkout ... [28]
 9/14/10 10:40 AM
Deleted: Create User Fiscal Transaction ... [29]
Robert Walsh 4/21/11 9:52 AM
Comment [6]: Use the descriptions from ... [30]Page 26 of 26
With this basic understanding of NCIP, you might wish to consult the Implementer 
Registry to determine what implementations exist today meet your needs. If you are a 
systems designer, the Registry contains contact information for appropriate individuals at 
other implemeters, and these people may be able to help you with testing. The NCIP 
general listserv is a place where you may ask questions of other implementers and get 
helpful advice and guidance on the use of NCIP. You may subscribe to this list at the 
NCIP website.
For More Information
For more information about NCIP, consult the following resources:
NCIP Standing Committee website http://www.ncip.info/
Subscribe to the NCIP General Interest ListServ: …
Implementer Registry (add when available)
 9/14/10 10:40 AM
Deleted: Create User allows users to 
register themselves for a library card. This is a 
unique NCIP message because it is not 
triggered by an id but instead requires a user 
name. Other fields that may be sent by the 
initiating application include user id, date of 
birth, physical and electronic addresses, 
language, user privilege, and proposed 
barcode. It is also possible to send a Block or 
Trap to alert staff to review the new user 
record. The successful response is a user id. ... [31]
 9/14/10 10:43 AM
Formatted: Font:14 pt, Bold
 9/14/10 10:43 AM
Formatted: Font:14 pt, Bold
 9/14/10 10:43 AM
Deleted: Implementers Group 
Robert Walsh 4/21/11 10:09 AM
Deleted: NCIPNOW Forum 
http://ncipnow.com/ ... [32]
Robert Walsh 4/21/11 9:52 AM
Formatted: Indent: Left: 0.5"
Robert Walsh 4/21/11 9:52 AM
Deleted: 
Robert Walsh 4/21/11 10:11 AM
Comment [7]: Make this section identical 
to the RFP Writer’s Guide
Powered by Create your own unique website with customizable templates.