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 Bodﬁsh - 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 brieﬂy introduced himself
or herself.
Agenda Review
Dicus reviewed the agenda with the group. No signiﬁcant changes were found to be
necessary.
Implementer Updates
Dicus asked each person in attendance to provide implementer updates.
Bodﬁsh reported that OCLCʼs Circulation Gateway is designed to be able to speak
NCIP. OCLC has tested its ﬁrst implementation with Biblionicsʼ Apollo product. This will
be OCLCʼs ﬁrst 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 workﬂows 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 signiﬁcant 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 Bodﬁsh 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 deﬁned by the “GetAvailability” service in the ILS-DI
speciﬁcations
Page 4 of 26Discussion:
Bodﬁsh 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 deﬁned 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.
Speciﬁcally, 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. Bodﬁsh 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 signiﬁcantly 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 sufﬁcient 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 identiﬁers 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.
Bodﬁsh responded that some responders already support NCIP but not Z39.50.
Further, NCIP deﬁnes 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. Bodﬁsh and OʼBrien both
indicated that they do not believe NetLibrary currently has this functionality.
OʼBrien clariﬁed 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. Bodﬁsh
added that the decision to support only a single identiﬁer 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 speciﬁc
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. Bodﬁsh 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. Bodﬁsh 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 modiﬁcation. 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 modiﬁcation. 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 speciﬁed 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 modiﬁcation. 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 modiﬁcation. 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 modiﬁcation. 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 modiﬁcation. 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 modiﬁcation. Change the standard to properly indicate that the
presence of the NonReturnableFlag empty element signiﬁes 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 beneﬁt to drafting some suggested
language for how the questions should be phrased so that the answers are useful and
meaningful. Bodﬁsh 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 deﬁne 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 Proﬁles. Historically, Application Proﬁles have been too dependent on
speciﬁc products and speciﬁc versions of those products. Ideally, Application Proﬁles
should deﬁne functionality and the messages that make that functionality possible.
Anyone should be able to implement an Application Proﬁle to embed that functionality in
an application. The original self-service Application Proﬁles 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 speciﬁcs of each
Page 10 of 26productʼs implementation may affect the way in which an Application Proﬁle should be
written. An effort was made to harmonize the various resource sharing Application
Proﬁles, 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 workﬂows are, in fact, vendor speciﬁc to some degree and if
useful implementations exist with as few as one or two services, then Core Services,
Application Proﬁles, 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.
Bodﬁsh indicated that the Implementer Registry could become at least a ﬁrst 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 deﬁne 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 identiﬁed 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
Bodﬁsh 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? Bodﬁsh 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-ﬁnal amount for overdue items. Some
systems donʼt put the overdue ﬁne 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. Bodﬁsh, 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, Bodﬁsh 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-ﬁnal amount of accrued ﬁnes 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 signiﬁcant hacker activity. As a
result, the group decided to ofﬁcially 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 clariﬁed 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.
Bodﬁsh 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 conﬁrm 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 ﬁnd 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
Bodﬁsh 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.
Bodﬁsh 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 conﬁrmed,
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"?>





<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>

<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>

<xs:element ref="BibliographicId" minOccurs="0"/>
<xs:choice>
<xs:sequence>
<xs:element ref="BibliographicDescription"
minOccurs="0"/>

<xs:element ref="TitleHoldQueueLength"
minOccurs="0"/>

<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>

<xs:element ref="HoldingsSetId" minOccurs="0"/>
<xs:choice>
<xs:sequence>
<xs:element ref="BibliographicDescription"
minOccurs="0"/>

<xs:element ref="Location" minOccurs="0"/>

<xs:element ref="CallNumber" minOccurs="0"/>

<xs:element ref="SummaryHoldingsInformation"
minOccurs="0"/>
<xs:element ref="ElectronicResource" minOccurs="0"/>
<xs:element ref="ItemInformation"
maxOccurs="unbounded"/>

<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>

<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"/>

<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