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

October 12-13, 2011 (In Person Meeting)

NCIP Standing Committee
Minutes - In-person Meeting
October 2011
Present
Voting Members
Chuck Jents - 3M
Susan Campbell - College Center for Library Automation
John Sandstrum - College Center for Library Automation
Rob Walsh - EnvisionWare (NCIP Maintenance Agency)
Mike Dicus - Ex Libris (Chair)
Randall Cook - eXtensible Catalog (Wednesday only; attended virtually via Skype)
Eric Leckbee - Innovative Interfaces
John Bodfish - OCLC (Wednesday morning only; attended virtually via Skype)
Tony O’Brien - OCLC
Robert Gray - Polaris Library Systems
Kevin Stewart - Relais International
Ranny Lacanienta - SirsiDynix (attended virtually via Skype)
Kristen Kokx - The Library Corporation
Juli Marsh - The Library Corporation (Thursday only; attended virtually via Skype)
Dave Faler - The Library Corporation (Thursday only; attended virtually via Skype)
Peter Collins - The University of Pennsylvania / BorrowDirect
Not Represented
VTLS
Minutes prepared and submitted by:
Rob Walsh, EnvisionWare / NCIP Maintenance AgencyTABLE OF CONTENTS
Welcome and Introductions 4
Defect and Change Requests 5
Clarification of current version of NCIP 5
Add repeatable, optional Bibliographic Id to the Loaned Item and 
Requested Item elements 6
Add optional Date Due to Item Optional Fields 6
Add UPC and GTIN to the Bibliographic Item Identifier Code Scheme 7
Add DVD to the Medium Type Scheme 7
Clarify the role and purpose of the Agency Id element 7
Lookup Item Set 9
Review Purpose, Structure, and Future Direction of the NCIP SC10
Agenda Review 12
The Future of the Implementer’s Registry 12
Marketing, Publicity, and Promotion 12
What’s Next for NCIP? 13
NCIP as a possible replacement for ISO ILL 13
Authorization and authentication 14
NCIP as a REST-ful web service 14
Allow NCIP requests to specify which Bibliographic Ids are desired in a 
response 15
Review Old Action Items 15
New Business 15
NCIP as a web service 15
2Wrap Up 15
Place and time for next meeting 16
Next call 16
Adjourn 16
Appendix A: Lookup Item Set Proposal 17
3Wednesday, October 12, 2011
Welcome and Introductions
Dicus welcomed everyone to the meeting and allowed each person the opportunity to 
introduce himself or herself. As part of the introductions, each member provided a brief 
implementation status update.
O’Brien reported that OCLC has been a long-time supporter of NCIP using both Version 
1 and Version 2. The original implementation used Version 1.01 and was a home 
delivery product employing DCB. WorldCat Navigator now uses NCIP Version 2.0 and 
is being used in production with Biblionics using a Circ-ILL-type profile. Navigator will 
soon be in production with OCLC’s Web-scale Management Service (WMS). According 
to O’Brien, Version 2 is sufficiently lean and customizable that it is being used as the 
internal interface between various OCLC services. OCLC will be implementing NCIP 
Version 2 in WMS libraries, and this means that those systems will be acting as NCIP 
responders. OCLC is beginning to work on self-service-style applications with WorldCat 
Local, and they hope to begin testing later this year. Finally, OCLC is working with 
Polaris on an NCIP interface with VDX using Version 1.
Campbell is planning to retire near the end of this year and Sandstrum will be taking her 
place as the CCLA representative to the NCIP Standing Committee.
Kokx reported that The Library Corporation (TLC) is planning to test NCIP Version 1 
with SirsiDynix for customers in the Solano-Napa Valley region in California. TLC is 
also planning to test with Baker & Taylor using Version 1 at Contra Costa.
Collins reported that the University of Pennsylvania’s BorrowDirect project is looking for 
additional ways to implement NCIP to provide greater services to users. BorrowDirect 
currently uses NCIP with Relais International’s D2D interface to facilitate resource 
sharing. They circulate approximately 160,000 items among the various participating 
partner libraries. These libraries use ILS products from Innovative Interfaces, Ex Libris 
(Voyager), and SirsiDynix. BorrowDirect would like to find ways to integrate with Kuali 
OLE using NCIP.
Gray reported that Polaris has integrated primarily with SirsiDynix using URSA and with 
a few consortia on the east coast using DCB. Their recent work with Innovative 
Interfaces is going well, and, while they are not yet in production, the delays seem to be 
more logistical than technical. Polaris is kicking off a re-testing effort with OCLC for 
VDX, but no issues are anticipated since the implementation is with Version 1 and no 
changes have been made recently. Polaris and OCLC have customers in Ohio ready to 
go live. Polaris is working with Baker & Taylor using NCIP Version 2 (Lookup User and 
Accept Item) with collections of electronic materials (eBooks, etc.). In general Polaris is 
the NCIP responder.
4Leckbee reported that Innovative Interfaces is working with Relais International on 
systems using DCB. Innovative has systems live at Brown, Dartmouth, and several 
other customers in that region. Further, they have installs pending at Temple, Lehigh 
Valley, and Drexel University. Innovative would like to expand its work with Relais to 
include systems that use ILL for resource sharing. Innovative is also working to publish 
an NCIP Developer’s Toolkit, and they have received interest from both Baker & Taylor 
and 3M for NCIP support for eBook circulation.
Stewart reported that Relais International has deployed several NCIP implementations 
using both Version 1 and Version 2.
Dicus reported that Ex Libris has three products (either released or in development) that 
use NCIP: Voyager (NCIP Version 1), Aleph (NCIP Version 1), and Alma (NCIP Version 
2). Ex Libris has existing implementations with Relais International and OCLC for 
systems using DCB.
Walsh reported that EnvisionWare does not currently have an NCIP implementation, 
primarily because SIP 2.0 has been sufficient to meet customer needs. EnvisionWare 
continues to evaluate the use of NCIP and will be weighing it against SIP 3.0 for future 
development.
Cook reported that the eXtensible Catalog (XC) recently released an NCIP Test Bed. 
This is an implementation of the NCIP ToolKit running against a Voyager test server. 
NCIP initiators can send requests using a limited set of messages and get NCIP 
responses to use as a testing aid. The XC has also developed a tentative road map for 
the next three releases of the NCIP Toolkit Core.
Lacanienta reported that he is new to SirsiDynix and will be taking Anne Arthur’s place 
as the primary representative to the NCIP Standing Committee.
Defect and Change Requests
Clarification of current version of NCIP
(Editor’s note: This discussion took place after the first change request was reviewed. 
However, for the sake of clarity and continuity, it has been moved here.)
O’Brien asked in what version of NCIP this set of change requests will be added. Walsh 
explained that the last official NCIP version is 2.0. Neither 2.01 nor what was to be 2.02 
was ever balloted before the NISO membership. However, a schema labelled “Version 
2.01” was published. The group agreed that it would ask NISO to delay the 2.02 ballot 
until the changes discussed at this meeting can be incorporated. Then (probably near 
the end of this year) a ballot can be issued that includes all the changes since 2.0. The 
resulting version of the standard (and the schema) will be Version 2.02.
5Add repeatable, optional Bibliographic Id to the Loaned Item and Requested Item 
elements
Bodfish and Cook described a use case for this proposal:
When a user is viewing items that s/he has out or on hold, the system might want 
to show additional information (like a thumbnail graphic of the cover art). 
However, the Loaned Item and Requested Item elements do not carry the 
bibliographic identifier of the item so the system would need to send an additional 
Lookup Item in order to get this data. By adding the Bibliographic Id element to 
the Loaned Item and Requested Item elements, the initiator would not need to 
send the extra message.
O’Brien suggested that the change seems low risk and easy to implement. Walsh 
asked if there would be any issues with making the Bibliographic Id repeatable. Gray 
said that it might be confusing for the initiator to receive a big bundle of various 
Bibliographic Ids, and he suggested it might be better if the initiator had a way to 
indicate which Bibliographic Id it wanted. Bodfish said that an application profile could 
define which Bibliographic Id(s) should be returned, but without one, the responder 
could just respond with all of the Bibliographic Ids associated with the item(s) in the 
result set. The initiator, then, would be responsible for filtering the list to get the 
appropriate one(s). Gray expressed concern over using an application profile to scope 
the response in this manner because it would potentially limit out-of-box interoperability. 
Bodfish agreed that the ideal solution would be some way for the initiator to ask for 
specific types of Bibliographic Id but that would be a change that affected the entire 
NCIP standard, not just this particular message. Further, even if this proposal is 
rejected and the initiator had to send the extra Lookup Item message, the responder still 
has to wrestle with which Bibliographic Ids to return. The group agreed to defer any 
further discussion of allowing the initiator to request specific Bibliographic Id types, and 
the group agreed with no votes in opposition to accept the proposal as submitted. 
Bibliographic Id will be added as a repeatable, optional element within the Loaned Item 
and Requested Item elements.
Add optional Date Due to Item Optional Fields
Bodfish and Cook described a use case for this proposal:
From a discovery perspective, the user wants to know when an item currently 
checked out to another user is due to be returned so that s/he can determine 
whether to simply wait, to place a hold, or to submit an ILL request.
Walsh asked if this proposal would expose an implementation detail that might cause a 
user to make certain assumptions that are not warranted. For example, knowing the 
item is due back does not necessarily guarantee that the user can have the item on that 
date. There may be other hold requests, the user may renew the item, or there may be 
other business and/or routing rules that would prevent circulation to this user. Campbell 
6agreed that this information might allow a user to potentially “game the system” by 
placing various hold requests that could allow the item to remain checked out for 
extended periods of time. Dicus added that, often, the policies for renewals and other 
actions can affect the due dates, so exposing it to a user and then having it change 
could be problematic. Cook asked if the concept of Date Due exists elsewhere in NCIP. 
O’Brien said that it does, but currently only in the context of providing information to a 
user about his or her own holdings. Stewart suggested that systems could provide an 
option to suppress this information if it is not appropriate for display. However, there 
may be valid reasons why the information should be provided. Bodfish agreed. “Much 
of the information available via NCIP might be exploited,” he said. “There are provisions 
for responders to omit certain information.” He added that many OPACs already display 
this information. Campbell explained that some libraries want users always to place 
holds when the item is unavailable because it provides the library with statistical 
information that can help make decisions about how many copies to provide. By 
displaying information that might cause a user to change his or her behavior, we may be 
hindering the library’s process. “However,” she said, “I’m comfortable with the notion 
that the Date Due could be omitted or disabled.”
The group agreed with no votes in opposition to accept the proposal as submitted. Date 
Due will be added as an optional element within Item Optional Fields, and a mechanism 
will be added to the Lookup Item request to allow Date Due to be requested.
Add UPC and GTIN to the Bibliographic Item Identifier Code Scheme
The group agreed with no votes in opposition to accept the proposal as submitted. UPC 
and GTIN will be added to the Bibliographic Item Identifier Code Scheme, and the URI 
for this scheme will be updated to reflect that the change was made in Version 2.02.
Add DVD to the Medium Type Scheme
Gray reminded the group that this proposal had been previously approved, but no 
actions had ever been taken to change the scheme. Walsh suggested that we should 
also add Blu-Ray. Lacanienta suggested that we should make an effort to add any 
value that could be used in the MARC 007 (Physical Description) field. “I don’t think,” 
said Bodfish, “that there is any moderate solution that provides completeness [with 
respect to the list used in MARC 007].” He suggested that we continue to allow people 
to request new items for the scheme on an “as needed” basis.
The group agreed with no votes in opposition to accept the proposal as modified in the 
discussion. DVD and Blu-Ray will be added to the Medium Type Scheme, and the URI 
for this scheme will be updated to reflect that the change was made in Version 2.02.
Clarify the role and purpose of the Agency Id element
Leckbee explained that, while working on their implementation with Relais, they 
discovered that people interpret Agency Id differently, specifically when used within 
7Accept Item. Sometimes, it represents the agency where the item is currently located, 
but at others, it may represent the agency that owns the item. Innovative, for example, 
expects the Agency Id to represent the owner library so that certain statistical 
information may be obtained. They use it also when a problem with a borrowed item 
requires a library to contact the owner library. Collins indicated that there were some 
implications associated with Agency Id during their implementation with Aleph. Stewart 
said, “The Agency Id has been misused in the past, sometimes to overcome limitations 
in the standard.” O’Brien asked whether the Location element could be used to meet 
Innovative’s and Relais’ specific needs. “Typically,” he said, “the Agency Id should be 
the agency that owns the item id being used in the message to identify the item.” 
Bodfish indicated, though, that in a resource sharing system, the broker may need to be 
identified and associated as the “owner.” Leckbee and Bodfish both would like to see 
the protocol allow multiple agencies to be identified. Stewart suggested that the 
Request Id’s Agency Id could be used to represent the owner library since this is the 
request that resulted in the item being delivered to its destination. O’Brien and Leckbee 
both indicated that this would feel like a work-around rather than a solution. Stewart 
then suggested that the Initiation Header could be used since it allows for both a From 
Agency and a To Agency. Leckbee indicated that this, too, would simply be a workaround. “Further,” he said, “people could interpret the From Agency and To Agency 
elements differently as well.” Bodfish agreed that using the From/To Agency elements 
could be confusing.
Campbell expressed a concern over changing the standard to address a system’s 
statistical needs when the information is already available in various places in the 
message. Collins, though, indicated that putting the information more clearly where it 
belongs will make it easier for systems to implement additional functionality.
O’Brien suggested that the contentious nature of the discussion suggests that this 
proposal should be deferred for additional study. Gray argued that there are systems in 
the field that are not working as a result of this confusion, and we should make some 
effort to fix the problem now. O’Brien asked if we need simply to identify the home 
agency or if we need the item id of the item in the home agency’s system. “It seems 
that having the item id from the home agency would be immensely valuable,” he said.
The group took a break for lunch. After lunch, Walsh recapped the discussion. The 
original proposal was to add a Home Agency Id (or equivalent) to Accept Item. O’Brien 
offered a modified proposal to add a secondary Item Id element to represent the Item Id 
in the home agency system, and this Item Id would contain the Agency Id of that 
system. Bodfish then added a third proposal which added a third Item Id that might 
represent the item/agency id of the pickup location.
O’Brien again suggested that Accept Item should carry the id from the original system, 
not the id that will be assigned in the receiving system. However, Stewart noted that 
many libraries have sheets of pre-printed barcodes. When an item arrives (physically), 
a barcode is affixed and then scanned. This barcode becomes the Item Id in the 
receiving system, and it needs to be conveyed in the Accept Item message. O’Brien 
8agreed that this describes a reasonable way to create temporary ids. He then 
suggested that we simply make the Item Id a repeatable element whose purpose or role 
could be determined by a new Purpose element (i.e., lender, borrower, pickup, temp, 
etc.). The value for this new element could come from a new scheme. Alternatively, the 
existing Item Id Type element could be used to convey the purpose (eg, “Barcode from 
Owner Library”). Walsh cautioned that overloading or repurposing an existing element 
might cause problems with existing uses of that element. “Adding a new Purpose 
element would allow people to continue using the Item Id Type element as they have 
been and use the new element to clarify the purpose.” Stewart asked whether the 
Purpose element should belong to the Item Id or to the Agency Id. O’Brien indicated it 
should belong to the Item Id since that is what is being clarified. Also, he explained, 
Agency Id is used widely outside of object identifiers, and in those cases, the purpose 
probably would have little value. Stewart countered, saying that there may be times 
when it is necessary to clarify the use of the Agency Id in those other contexts. 
However, it was noted that Agency Id is a simple string value and cannot, therefore, 
contain child elements. To use Purpose with Agency Id, Purpose would need to be an 
attribute rather than an element. To date, the standard has used attributes sparingly.
Gray observed that making Item Id repeatable inside Accept Item introduces the 
potential for abuse where Accept Item is misused in an attempt to create multiple items 
with a single message. (In other words, the Item Ids within Accept Item would represent 
distinct items rather than alternate identifiers for a single physical item.)
O’Brien reiterated that we should defer the proposal for further study. Alternatively, he 
suggested that we could make a change to address this specific problem and not 
concern ourselves with the larger context until later. Stewart expressed his preference 
to make a change now rather than waiting for additional proposals to address a bigger 
problem. Leckbee, though, preferred a comprehensive solution that addresses all 
possible uses. Ultimately, the group agreed to defer the proposal for further study. 
Leckbee agreed to refine the proposal and to make suggestions for specific changes in 
the protocol.
Lookup Item Set
Bodfish reminded the group that this item was discussed at the last meeting and was 
accepted for future study. At that time, he agreed to supply some additional 
explanations and proposed schema changes to support a new Lookup Item Set service. 
The group reviewed the documentation Bodfish had prepared.
Lacanienta asked what is meant by a “set” in this context. Bodfish answered that a set 
is one or more than one item corresponding to the identifier supplied in the request. 
Gray asked where an initiator would get a Holdings Set Id. Bodfish explained that some 
ILS have the concept of a set of related items known as a holdings set. If the initiator 
has a way to discover that id, it can be used to retrieve the items in that set. Cook 
added that the concept may not be applicable in some ILS. The real intent of this 
proposal is for an initiator system to be able to provide a single id that might represent 
9one or more items in the responder system and to get information about those items 
with a single request.
Kokx asked if there is any consideration given to limiting the size of the response. “It 
seems that they could be quite large for some queries,” she said. Bodfish explained 
that the Maximum Item Count and Next Token elements allow the initiator to request a 
scoped set of limited size and then continue traversing the full result set with additional 
requests. Likewise, the responder could voluntarily limit the number of items returned 
and give the initiator the option to get more. There is a slight risk with this approach that 
some items might be omitted, and others could be duplicated. Cook added, though, 
that the same omissions and duplications could occur in a system using a series of 
sequential single item requests with Lookup Item. O’Brien observed that the Next Item 
Token would not need to be an ordinal value. It could be some kind of an anchor value 
that the responding system could use to find its place in the original result set and 
minimize the potential for missing or duplicating items. Bodfish said that it is up to the 
responder to specify the semantics of the Next Item Token, but he agreed that the 
responder could choose to use a Next Item Token that represents some kind of internal 
pointer or key to allow the responder to find the next item in the original list even if the 
list has been modified.
The group agreed to accept the proposal as submitted. A new service called Lookup 
Item Set will be created according to the documentation Bodfish submitted (see 
Appendix A).
Review Purpose, Structure, and Future Direction of 
the NCIP SC
Walsh explained that, from his perspective, the focus of the group has shifted in recent 
years from marketing and promotion to the technical details of implementations. While 
this may very well be a good thing, he suggested that the group should recognize the 
change and make a conscious choice rather than drifting aimlessly. Dicus proposed 
that we start by reviewing the group’s purpose and procedures as posted on the NCIP 
website (http://www.ncip.info).
The group discussed two items from the list of procedures that had been marked 
Pending Review at the April 2009 meeting. Walsh read from the minutes of that 
meeting and determined that the item “List discussions follow the same rules but have a 
duration, exceeding of which amounts to abstention” pertained to votes taken on the 
NCIP list. The related item “Default email vote duration is one week; the chair may 
reduce or extend at own discretion” set the standard period for votes conducted on the 
list. At this meeting (October 2011), the group decided to further modify both items as 
follows:
10* Votes may be taken at an in-person meeting, on a regularly scheduled conference call, 
or via on-line ballot conducted through the NISO website (assuming that a quorum is 
present in any of the referenced forums).
* Default on-line vote duration is one week, exceeding which amounts to abstention; 
chair may reduce/extend this at own discretion.
Further, the group added that while the chair is elected by the group, s/he must be 
approved by the NISO Discovery To Delivery Topic Committee.
Lacanienta asked how membership in the group is governed and to whom the group 
reports. Walsh explained that membership is voluntary and is open to anyone 
interested in the use of NCIP. The NCIP SC reports to the NISO Discovery to Delivery 
(D2D) Topic Committee (TC). The D2D TC, in turn, reports to the NISO Architecture 
Committee who reports to the NISO Board. (Editor’s note: This point was not made 
during the meeting, but it is important in the context of membership. New group 
members must be approved by the D2D TC, but approval is almost always a formality.)
Walsh explained that there are membership requirements governed by NISO’s 
guidelines for working group conduct and participation (http://www.niso.org/apps/
group_public/download.php/3246/NISOprocedures_ansiapproved9dec09.pdf, Section 
2.3). Regarding participation, Section 2.3.3 states, “Failure to attend more than three 
consecutive meetings, failure to accept or complete assignments, and/or disruptive 
behavior are grounds for dismissal.” At this time, VTLS is the only NCIP SC member 
not in compliance with this requirement.
The group suggested that we consider recruiting new members from the following 
organizations as a result of their implementation partnerships with existing members:
* Biblionics
* Baker & Taylor
* CybraryN
Additionally, Campbell and Collins suggested that we should encourage most 
customers to join, particularly large public libraries. These people would be able to 
provide fresh perspectives and real-world use cases. Leckbee suggested that we might 
consider setting aside time during these meetings to engage customers with existing 
implementations in Q&A sessions. Cook indicated that it would be great to see more 
vendor-side support for the XC NCIP Toolkit.
Walsh asked if there are things NISO could do to help us be more successful. Only a 
few things were mentioned:
* Ballot revisions in a timely manner
* Put documents at the various scheme URIs that list the current values of those 
schemes. While URIs are not required to actually resolve to a document, many expect 
them to and would be pleased to see the scheme contents at those locations.
11* Publish the revised NCIP section of the NISO RFP Writer’s Guide and the 
“Introduction to NCIP document.”
Walsh again asked the group to consider its focus. Campbell suggested that the current 
focus on implementation is good. However, we might reach a point where we need to 
move back to promotion. “For now, though,” she said, “we should continue to get more 
implementations.” Leckbee added that we should strive to promote the implementations 
that each of us completes to continue to show the industry how much is going on.
Agenda Review
The group reviewed its progress against the agenda and adjourned for the day.
Thursday, October 13, 2011
The Future of the Implementer’s Registry
Campbell explained that the Implementer’s Registry is currently hosted at 
WebEnabled.net (http://ncip.dev3.webenabled.net/). Additionally, she is personally 
funding the hosting service. When she retires (in early December), the site needs to be 
taken over by someone else or it will go away. It is written in Drupal, and there is a 
document describing what she thinks could be made better. Sandstrum offered to take 
over the site’s administration, but he indicated that we would still need to find a 
volunteer to fund the hosting. Dicus said that, in the past, NISO has expressed a 
willingness to provide hosting services. It is not clear whether their assistance would be 
actual on-line space or funding. He and Walsh agreed to check with Lagace to 
determine what NISO could provide. Campbell noted that WebEnabled has a backup 
utility that should aid with migration, and the people there have been helpful and easy to 
work with. Gray offered to fund the hosting services until a more permanent, final 
solution can be found.
Marketing, Publicity, and Promotion
Dicus asked the group how much marketing and promotion we should be doing right 
now. “We’re getting a lot of traction with implementations,” he said, “but in the past 
we’ve done more publicity and promotion about NCIP. We don’t have any current 
projects pending in this area.” O’Brien suggested that we should coordinate with NISO 
on a press release talking about the current state of NCIP, how customers are using it, 
and what benefits they are seeing. “We’ve got data on several implementations, and 
we should find a way through NISO to publish it.” Walsh asked if we should try to get 
NISO to publish press releases on specific, individual implementations much like KBart 
does when a new implementer signs on. Dicus indicated that they often struggle to get 
the appropriate permissions to reference specific sites in their own press releases. 
12O’Brien agreed that we are better off working with generic issues and topics related to 
the standard itself.
Dicus asked if there are industry-specific events (like LITA) that we should be targeting 
for presentations. Campbell asked who we want to reach. O’Brien indicated a level of 
comfort with the notion of leaving the audience undefined. “We want input,” he said. 
“We want people to tell us what they want from the standard, where it next should go.” 
He continued, saying that Version 2 has been a great leap for NCIP, and it provides a 
great platform for discussion. Collins suggested that NCIP remains a mystery to many 
in the library, particularly those doing the work that NCIP can help to streamline. “It is 
hard for them to know what they want from the standard,” he said, “because they don’t 
know what it is or what it can already do.” He said that we should work to present use 
cases and other examples of how people are using NCIP to make their work more 
efficient. Examples like this give people ideas for how they could implement NCIP and 
allows them to being thinking about what else it might be able to do.
What’s Next for NCIP?
O’Brien suggested three ideas that could be the “What’s Next?” for NCIP. First, given 
what has happened (or not happened) with Rethinking Resource Sharing, could NCIP 
be a viable replacement mechanism for ILL? Second, is there interest in having a 
REST-ful implementation for NCIP, possibly through another implementation profile? 
Third, should we implement a richer authentication/authorization system within NCIP? 
Collins agreed that these concepts would be good places to start, especially with people 
who are already using NCIP. Marsh indicated that TLC is particularly interested in 
improving the authentication and authorization mechanism. O’Brien noted, however, 
that these ideas could result in another major revision of the standard, possibly a 
Version 3. 
NCIP as a possible replacement for ISO ILL
Lacanienta asked if there is already a standard for ILL. Dicus indicated that ILL is 
governed by ISO ILL (ISO 10160 and 10161). O’Brien added that the last ISO ballot on 
that standard failed, and that has restricted its future. Stewart said that he attended a 
Rethinking Resource Sharing discussion a few weeks ago, and many there commented 
that nothing has happened in the last two years. ISO ILL is considered to be 
complicated and to use obsolete technologies. “I suggested possibly trying to use 
NCIP,” he said. “It uses current technologies, and because it is extensible and is being 
actively maintained, new services could be added incrementally.” Stewart reported that 
some in attendance resisted the idea because NCIP is perceived to be a circulation 
protocol. Others, though, seemed to think it might be a good idea. O’Brien observed 
that of the three original intended uses for NCIP, two relate to resource sharing: ILL and 
DCB. Lacanienta agreed that using NCIP for ILL might be a good idea. “We would 
need to ensure that NCIP has all of the necessary data elements,” he said. “However, 
because NCIP is extensible, any missing elements could be added.” He did note, 
13though, that ILL might require richer discovery services than NCIP currently provides. 
Stewart indicated that one of the challenges with ISO ILL was keeping up with many 
older systems and technologies. Much of what exists in ISO ILL for use with these 
legacy systems could be eliminated. “We could focus on keeping things simple,” he 
suggested. O’Brien agreed, saying that we should focus on defining what it really 
means to share resources and then solving that problem. He pointed out, though, that 
he is not proposing that this effort would replicate ISO ILL.
Authorization and authentication
Faler explained that when NCIP is used to perform staff functions, the staff generally 
does not have the full set of patron credentials to act on the patron’s behalf. For 
example, if the staff does not know the patron’s PIN, the responding system may reject 
the request. Gray indicated that the responder should respond to the request with the 
information provided. The initiator has the responsibility to ensure it is sending the 
appropriate credentials for the usage context. If the responder holds this responsibility, 
then certain use cases may be prohibited (as is illustrated with the example given be 
Faler). O’Brien suggested that, while a valid issue worthy of discussion, this is not a 
problem that can be solved today. He suggested that the ultimate solution might require 
the concept of a temporary authorization token. Much like giving one’s car keys to a 
valet allows him or her to drive the car a short distance, a token might allow a third-party 
to act on a user’s behalf to perform a subset of services for a temporary duration.
Marsh and Faler were encouraged to work with Auto-Graphics to present a proposal, 
along with a use case, for an improvement to the current authentication mechanism in 
NCIP.
NCIP as a REST-ful web service
O’Brien indicated that Bodfish is interested in working on this, and he asked if anyone 
else shared that interest. Stewart suggested that making NCIP a true REST-ful service 
might be a daunting task. O’Brien explained that REST expects requests to use HTTP 
GET (NCIP uses POST); REST is stateless (as is NCIP); REST uses XML (as does 
NCIP); and REST-ful services expose a directory structure for objects through 
hierarchical URIs. “The last,” he said, “might represent a significant change to the way 
messages are structured.” Stewart asked what benefits might be had if NCIP were 
made truly REST-ful. “I think we already do the important parts of REST,” he said, “and 
it seems like a lot of work to do the rest.” O’Brien replied, saying that REST is wellunderstood by tech-savvy people. He agreed, though, that the work required might 
outweigh the potential benefits. Stewart said he would like to see an outline of what is 
required and what would be gained. Additionally, he pointed out that this would break 
backwards compatibility. Gray suggested the effort would be counter productive. “It 
would present an impediment to additional implementations.” O’Brien suggested that 
simple requests could probably be implemented without much difficulty (like GET /user/
12345). However, more complicated requests with many arguments and attributes 
could get messy.
14Allow NCIP requests to specify which Bibliographic Ids are desired in a response
The group returned to an item that had been added to the parking lot the previous day. 
Walsh explained that there may be cases where an initiator is interested in only one 
type of Bibliographic Id (the OCLC number, for example). The initiation message should 
allow this to be specified so that the responder does not have to generate a list of all 
possible Bibliographic Ids for an item or to return a single Bibliographic Id that is not 
useful to the initiator. Gray indicated that Polaris today returns only its own internal 
Bibliographic Id because it assumes that will be most useful to the initiator in composing 
its next request. Walsh observed, though, that this assumes the next request will be to 
Polaris and not to some third-party, external system that needs a different Bibliographic 
Id. The group encouraged anyone interested in pursuing this idea to submit a change 
request for consideration.
Review Old Action Items
Dicus asked the group to review some outstanding action items posted at the NISO 
website. These were quickly determined to have been completed, and they were 
closed. Additionally, the group recognized that the NISO website may be a poor place 
for it to track action items.
New Business
Dicus asked if anyone had any new business or topics to raise.
NCIP as a web service
Lacanienta asked if any implementers were looking to use web services in place of 
NCIP. O’Brien indicated that this relates closely to the discussion of making NCIP 
REST-ful. Stewart added that NCIP already is a web service; it simply isn’t a REST-ful 
web service. O’Brien agreed that, for at least a very generalized definition of “web 
service,” NCIP could be considered one. Leckbee added that Innovative sees web 
services more for information sharing that for conducting transactions. O’Brien found 
the W3C definition for web services, and he explained that there are two categories: 
REST-ful and arbitrary. He suggested that NCIP could be considered an arbitrary web 
service, primarily because the responder must read and parse the XML associated with 
the request in order to determine what action to take. REST-ful web services, on the 
other hand, tend to have a smaller set of commands that typically correspond with the 
database concept of CRUD (Create, Retrieve, Update, Delete).
Wrap Up
15Place and time for next meeting
Dicus reminded the group that TLC had expressed an interest in hosting the next 
meeting. Marsh indicated that TLC was still interested, and would like to host a spring 
meeting in Winchester, VA. O’Brien offered OCLC’s facilities in Dublin, OH, as a 
backup. Marsh agreed to check on the last week in March (specifically March 28-29, 
2011) and the last week in April (25-26). These times appear to avoid Easter (April 8), 
PLA (March 13-17), Computers in Libraries (March 21-23), and the Innovative User’s 
Group (April 15-18). She will report back to the group during an upcoming call.
Next call
The group agreed that there is no reason to hold the call scheduled for next Thursday, 
October 20. The next call, then, will be November 17, 2011, at 1 pm Eastern.
Adjourn
Dicus adjourned the meeting.
16Appendix A: Lookup Item Set Proposal
Jus$fica$on:
Many libraries today are implemen2ng new discovery interfaces (e.g. the eXtensible Catalog,
VuFind, WorldCat Local, Blacklight, Summon, Primo) that integrate the library’s collec2on with
other resources and offer features not available in their ILS’s OPAC such as faceted browsing.
OMen these discovery interfaces use indexes built from an extract of their catalog’s
bibliographic informa2on. With this architecture there is a requirement to retrieve real-2me
circula2on status, loca2on and other item data from the ILS, as defined by the “GetAvailability”
service in the ILS-DI specifica2ons (hVp://www.diglib.org/architectures/ilsdi/
DLF_ILS_Discovery_1.1.pdf#page=26).
NCIP’s Lookup Item is limited to one item per service and using that would be inefficient, and in
some cases impossible to retrieve, say, all of the items for a search result list that displayed 20
2tles. This service is intended to overcome that limita2on.
An alterna2ve approach would be to use Z39.50 or SRU to retrieve this informa2on, but that
would impose a requirement on the discovery interface that it support that protocol, which is
otherwise not required. Addi2onally there is liVle support in exis2ng Z39.50 servers for the
item-level detail that is desired, whereas NCIP does currently provide this data.
This service has been designed by members of the ILS-DI discussion group and the eXtensible
Catalog Organiza2on’s NCIP Toolkit developers. Current proof-of-concept code is available in
the NCIP 2 Toolkit repository (hVp://code.google.com/p/xcncip2toolkit/source/checkout), and
implementa2ons for this service against a variety of ILS types are in progress.
Note:
This extension is based on version 2.01 of the NCIP standard, but it requires a single small
change to the standard NCIP schema (make BibliographicItemId repeatable in
BibliographicDescrip2on). When we adopt the extension we'll need to include that change
along with incorpora2ng the Lookup Item Set service into the standard schema.
A/achments (see h/p://www.niso.org/apps/org/workgroup/z3983maint/documents.php?
folder_id=923):
ncip_v2_0x_lookup_item_set.xsd: Made BibliographicItemId repeatable in
BibliographicDescrip2on. This was necessary to ensure that a responder could always include
the same bibliographic id that was in the ini2a2on message.
ncip_v2_0_lookup_item_set_extension.xsd: Defini2ons of new elements: Lookup Item Set,
Lookup Item Set Response, BibInforma2on, HoldingsSet, ItemInforma2on,
SummaryHoldingsInforma2on, TitleHoldQueueLength, HoldingsSetId, ItemNote,
MaximumItemsCount, and NextItemToken.
Lookup Item Set Service Defini2on.doc
17Data Dic2onary Entries for Lookup Item Set.doc
Using Maximum Item Counts and Next Item Token.doc
18
Powered by Create your own unique website with customizable templates.