April 27-29, 2010 (In Person Meeting)

NCIP Implementers Group
Minutes - In Person Meeting
April 27-29, 2010
Present:
Voting Members
Sue Boettcher - 3M
Mary Jackson - Auto-Graphics
Susan Campbell - College Center for Library Automation (CCLA)
Rob Walsh - EnvisionWare (NCIP Maintenance Agency)
Mike Dicus - Ex Libris
Eric Leckbee - Innovative Interfaces
Tony OʼBrien - OCLC
Dan Iddings - PALCI
John Barr - Polaris
Rob Gray - Polaris
Kevin Stewart - Relais International
Gail Wanner - SirsiDynix (Chair)
Thalia Dickson - TLC
Observers
Karen Wetzel - NISO (Tuesday, Wednesday only)
Dhaval Kotecha - RapidRadio (Wednesday only, participated from India via conference
call)
Jennifer Bowen - Rochester University / eXtensible Catalog Project (Wednesday only)
Randy Cook - Rochester University / eXtensible Catalog Project (Wednesday only)
Minutes prepared and submitted by:
Rob Walsh, EnvisionWare / NCIP Maintenance Agency
Editorʼs Note: In some situations, the record of the conversations was reorganized
slightly from the way those conversations occurred chronologically in order to keep
related information together. Efforts have been made to ensure that that the
reorganization does not affect the meaning or the context of the discussions.
Page 1 of 47Table of Contents
Welcome and Introductions 4
Review of 2009 Goals 4
Review of Core Messages 8
Implementation Updates 9
Self-Service and NCIP 10
Core Messages 11
Recall Item 15
Implementer Registry 15
Continuous Maintenance 16
Taking NCIP to ISO 16
ALA Social Hour 16
Presentation by RapidRadio 17
Presentation by the eXtensible Catalog Project 17
Change Requests Review 19
Repeating the Bibliographic Id and Item Id in Request Item 30
Review of Action Items 31
Open Test Bed 31
2010 Goals 32
Technical Support for Implementers 33
Encouraging Implementation of Version 2 33
Page 2 of 47Planning for the Next Meeting 33
Conference Call Times and Technologies 34
Next Conference Call 34
Adjournment 34
Appendix A - Presentation by Dhaval Kotecha, RapidRadio 35
Appendix B - Handouts from eXtensible Catalog Project 41
Appendix C - Action Items 47
Page 3 of 47Tuesday, April 27
Welcome and Introductions
Wanner began the meeting with a quick round of introductions. Innovative Interfaces,
Polaris, and TLC were each represented by someone attending his or her ﬁrst NCIP
Implementers Group (NCIP IG) meeting. Wanner also thanked Gray and Polaris for
serving as the host organization for the meeting and for making the various logistical
arrangements.
Review of 2009 Goals
Wanner then reviewed an email she had previously sent to the Implementer Group list
serve outlining the groupʼs goals for 2009 and the progress that had been made for
each.
* Formal requirements for membership in the Implementers Group
At a previous meeting (April 2009), the NCIP IG agreed to abide by the NISO
Guidelines for committee membership (as outlined in the NISO Policies and Procedures
Guide, http://www.niso.org/about/documents/NISOprocedures2008ﬁnal.pdf). Over the
course of the past year, the NCIP IG has removed some organizations from the roster
for failing to meet the participation requirements. Wanner explained that there is no
intent to become overly formal, but we do need some way to ensure that we know who
is participating. Of those on the current roster, only VTLS is not actively participating.
Wanner, Walsh, and Wetzel will coordinate to contact VTLS to determine if they wish to
continue their participation and are willing to commit to the membership requirements.
Additionally, there has been interest from several entities who wish to be involved with
the NCIP IG, at least as observers. RapidRadio in India has participated in a few recent
phone calls and is planning to give a web presentation to the group on Wednesday.
The eXtensible Catalog Project also has participated in past calls and will be present on
Wednesday to talk about their progress. Finally, Mick Fortune, a consultant in the UK
has been in contact with both Wanner and Walsh asking about how NCIP might be used
to interoperate with RFID applications.
Gray asked if new members are required to pay NISO membership fees. Walsh
answered that NISO membership is not required for NCIP IG (or other NISO working
group) participation.
Wanner asked if anyone had any issues or problems with continuing to abide by the
NISO Guidelines for membership. No one present voiced an objection.
Page 4 of 47* Continuous Maintenance
Walsh provided a basic summary of Continuous Maintenance and the procedures
approved by ANSI (http://www.niso.org/workrooms/ncip/continuous). He explained that
there is some confusion within the group about what sorts of changes are allowed under
Continuous Maintenance. An agenda item exists for further discussion later in the
meeting.
* Encourage Implementation of NCIP
* Deﬁne core set of messages and responses
At the September 2009 meeting, there was discussion about whether Recall Item
truly belongs in the Core Message Set. Additionally, there was suggestions that
the Core should be pared down even further - from 9 to 4 or 5 since most selfservice applications need fewer messages than resource sharing applications do.
Finally, the previous discussion included how we deﬁne compliance against the
Core. Does an application comply only if it implements all 9 messages, or is
some level of partial support allowed.
Campbell asked how an applicationʼs role affects compliance. “Is is possible for
an application to be compliant as an initiator?” Wanner added that an ILS with no
ILL capabilities would always be a responder. “We need to be clear when an
application is playing only a single role,” she continued. “We should focus
compliance on Core Messages rather than on the applicationʼs context (DCB3,
Self Service Circulation, etc.).”
* Promote adoption of Version 2
Wanner reminded the group that NISO feels strongly that implementations should
be moving to Version 2. At this time, little progress has been made. We are
becoming aware of new implementers, like RapidRadio in India, who are using
Version 2. Likewise, some existing implementers are beginning to add support
for Version 2. Some implementers are struggling to ﬁnd a solid business case to
justify the additional development investment to add support for Version 2.
However, as we see more Version 2 implementations, implementers will have
more reason to support both, especially for initiators.
* Create educational documents for implementers
Wanner summarized that, while we have created tasks for preparing these
documents, we struggle to get them done. She hopes to have time during this
meeting to break into working groups to make some progress on this material.
* Outreach programs to potential implementers
Page 5 of 47Again, Wanner stated that, although we have discussed various ideas, we have
struggled to do anything signiﬁcant in this area.
* Encourage global dialog with implementers
Wanner said that, in this area, we have had some success. We have seen
interest from India and from some parts of Europe. However, weʼre also seeing
some resistance internationally to adopting a NISO Standard (rather than an ISO
Standard). NISO is seen to be a US-centric body. At times in our past, we have
discussed seeking ISO standardization for NCIP. It has always seemed like a
daunting task, but it is something we could reconsider. Presently, there is no
international analog to NCIP, and that may indicate that the level of
interoperability between international systems is low.
Iddings suggested that ISO standardization might be something we should
consider when we reach a point where we are ready to draft Version 3. Wanner
added that we could use that as an opportunity to clean up the existing version
by removing unneeded messages and reviewing the various data elements
available in each message. OʼBrien suggested that we could consider a means
for exchanging policy information.
Walsh asked how we deal effectively with international logistics. “Europe is 4-5
hours off of US Eastern time, but India, China, and Australia are closer to 12.
Would we be able to hold participants in those regions to our membership
standards?” Boettcher suggested that we could use video conferencing and
schedule conference calls for 8 am or 8 pm US Eastern time. Wanner added that
Wednesdayʼs presentation by RapidRadio in India will serve as a test case for
using remote technology to facilitate international participation.
* Educate the library community about NCIP
* Revise NISO RFP document section on NCIP
We have discussed revising NISOʼs RFP Guidelines to help explain to libraries
how they should be requesting NCIP, but no progress has yet been made.
* Create an implementers registry to track the use of messages
We have plans to create an implementer registry to track the use of messages in
each vendorʼs applications, and we have created forms for initiators and
responders to ﬁll out, but weʼre not sure how to deliver the information. Also, we
need to determine how the Core Messages relate to the implementer registry to
best show, in a way that libraries will understand, how applications interoperate.
* Create documentation to explain NCIP to librarians
Page 6 of 47Wanner acknowledged that this has been a real challenge. “It is difﬁcult to
explain NCIP,” she said. “There are lots of messages, but not are all necessary
in a given application. We use speciﬁc terminology (like DCB3) that many do not
understand, but there is no single context or purpose.” In the past, we have
discussed creating documentation that will explain NCIP to librarians. It should
talk about how NCIP works, and it should include information about how to
explain it to the information technology (IT) people in the library.
* Outreach programs, presentations, and activities
Wanner stated that we have been a regular participant in the LLAMA-SASS/
RUSA STARS panels at ALA. Wanner agreed to follow up with those groups
about participating again this summer. Also, we have given presentations at
LITA conferences. The most recent, though, did not seem to be particularly
effective. Attendance was low, and those who did attend seemed to have higher
levels of current knowledge and awareness than at previous conferences. We
held a social event at ALA annual in 2009, but it was poorly attended. We are
planning another for this yearʼs ALA in Washington, D.C., and we hope to do
more to let people know about it.
Wanner asked if anyone had other goals or ideas about additional ways to reach the
library industry. Gray stated that whatever momentum we seem to gain in the industry
ultimately stalls due to situations outside our control -- 9/11, a down economy, etc. The
library market wants to see NCIP succeed. They want standards, not one-off web
services. “If we had a big widespread use of the Standard in some region,” he
continued, “that would encourage more awareness and adoption. We seem to have
very low inertia right now.”
Wanner added that libraries are faced with low budgets. Even though NCIP could save
them money, they donʼt have enough money to get started. Jackson said that, at a
recent presentation she gave in Connecticut, people expressed surprise about how low
the vendor adoption rate is. “Libraries expect it to be ʻplug-and-playʼ at this point in it
evolution.” Wanner mentioned that testing has been so daunting that those who have
implemented have done only what is necessary. “Further,” she continued, “many of us
are not in a position to dictate what our companies do.”
Barr reported that Polaris has had some success when they are able to ﬁnd a local
champion in a library. That person can explain what the library wants, and he or she is
then available to help. Jackson said that she tried to convey that same message during
her presentation. Barr added that customers have some of the same challenges as
vendors - no time, no money, and too many other projects. Wanner asked how we get
libraries to step up and accept the challenge of being the champion. Barr responded by
saying that we need to ﬁnd the libraries that are in the best position to do it. Those
generally are the larger libraries or consortiums to have adequate resources. Iddings
agreed that has worked at PALCI. “However,” he said, “it took ﬁve years to get enough
libraries to commit to work with Innovative Interfaces to have NCIP added.” Boettcher
Page 7 of 47asked if we could emphasize the savings associated with implementing NCIP. Wanner
mentioned a time and motion studied conducted by a group in Minnesota that showed
signiﬁcant savings. Jackson added that one of her customers recently updated a study
showing that 75% of the staff time allocated to ILL had been freed up for other purposed
due to NCIP.
Iddings stated that, while there has been a demand for applications that NCIP could
support, some vendors have found others ways to implement. Wanner added that
developers still feel that alternatives to NCIP (like web services and SIP) are easier to
implement. OʼBrien said that the actual effort, however, to implement NCIP would have
been an order of magnitude less that the alternative (telnet screen scraping, for
example) that was used in situations where NCIP was not an option (for non-technical
reasons). “Commercial considerations,” he continued, “generally override the desire to
be standards based.” Wanner asked if that can be solved. OʼBrien said that we can
look to identify situations that are conducive to NCIP and focus on those. That might
provide a groundswell of activity on which to build. Campbell mentioned that NCIP
should be something that a vendor could use as a competitive advantage. “Having
NCIP should be more valuable and make vendors more competitive than not having it,”
she said.
Iddings noted that operations that use NCIP probably account for only about 2% of the
total functionality available within an ILS. “That isnʼt enough to compel its use,” he said.
“The customerʼs drive should be for an application that uses NCIP to achieve its goals
rather than for an NCIP implementation.” Walsh added that the customerʼs expectation
is to buy a solution comprised of components from multiple vendors and have them plug
in and work together. “The ʻhowʼ is unimportant,” he said, “but NCIP provides a
common platform that promises seamless interoperability.” Campbell said that she liked
the idea of focusing on applications. “NCIP might make implementations less difﬁcult,”
she said, “but it should not be necessary for libraries to understand the intricate details.”
Review of Core Messages
Campbellʼs comment provided a segue into a discussion centered on the Core
Messages. Wanner suggested that we might have a common core composed of four
messages, then an ILL core containing another 5 and a self-service core with others.
Gray noted that self-service might be better termed circulation since the messages that
would likely be included might be used for more than self-service. Leckbee said that his
preference would be for a circulation core in addition to a self-service core. “They have
different requirements,” he added. Wanner observed that we may be talking about
multiple cores that act like proﬁles. “However,” she continued, “we probably donʼt want
to use the term ʻproﬁleʼ.” Gray noted that we often use terms like “CIRC,” “ILL,” “RPA,”
etc., to communicate with other vendors about what we need them to support.
Page 8 of 47Implementation Updates
After a brief break, the group listened as each member presented implementation status
updates.
* Auto-Graphics is now in production with TLCʼs Library.Solution. They have
experienced some difﬁculty communicating with people at SirsiDynix, and this
highlights an issue inherent with interoperability testing. Auto-Graphicsʼ
implementations are against Version 1. They have no timeline for implementing
Version 2.
* SirsiDynix has ﬁnished testing with CARL and is working on testing with TLC. They,
too, are using Version 1 and have no schedule for Version 2 (because they have no
strong business case).
*Innovative Interfaces has ﬁnished coding for the Michigan project and is waiting on
other vendors to test and conﬁrm. This implementation is using Version 1. They are
working on a Version 2 implementation with Relais for PALCI, and they expect for this
to be ready for testing in the third quarter of this year.
* Relais International is working with Innovative Interfaces. Also, they have tested
against the latest version of Voyager from Ex Libris. They, too, are experiencing some
struggles communicating with people at SirsiDynix. Relais is supporting both Version
1 and Version 2.
* 3M is still supporting Version 1 and waiting on additional vendors. They had one
implementation in the US and another in the Czech Republic, but both have returned
to SIP because they were unable to use Lookup User to obtain sufﬁcient information
about user privileges.
* OCLC is supporting Version 1.01 in WorldCat Navigator as an initiator. They have
tested with several vendors (including SirsiDynix and Ex Libris), and they are willing to
test with any responders. They are currently testing a Version 2 toolkit, but they are
unsure as to when it will be ready for production. It works as a service layer, and it will
work in parallel with other available interoperability mechanisms.
* PALCI is in the process of implementing Relais. They are expecting to go live on
August 20, 2010, with NCIP in as many places as possible. They will support Voyager
(using both NCIP and SIP), TLC (using NCIP), and Innovative Interfaces (using telnet
until Innovative Interfacesʼ support for NCIP is complete). Their implementations will
be a mix of Versions 1 and 2.
* CCLA reports that the Florida legislature is looking for more ways to interoperate
among colleges, universities, K12, and public libraries. NCIP seems like it should be a
natural ﬁt.
* Ex Libris has done recent testing between Relais and Voyager using Version 1. They
found a few areas that need to be enhanced.
* TLC has implemented Version 1 with SirsiDynix.
* Polaris has a test bed that is always available. Not much has changed since the last
meeting. They will begin working on Version 2 as other vendors want support for
those messages. In the meantime, both Versions 1 and 1.01 will be available.
Page 9 of 47* EnvisionWare has nothing to report as they have not found a sufﬁcient business case
to implement NCIP.
Self-Service and NCIP
Wanner asked whether self-service belongs inside NCIP. Jackson said it might be
easier to answer after hearing more about 3Mʼs plans for SIP 3.0. Boettcher indicated
that NCIP started with self-service as a core piece and added ILL and other functions.
“Today, though,” she continued, “NCIP makes sense for ILL, but not enough have
implemented the appropriate support for self-service. I think that it will get there
eventually.” Walsh asked how many vendors support the various NCIP messages for
ﬁscal transactions. Most, though, support SIPʼs 37/38 fee paid messages. “Basic selfservice circulation stations,” he continued, “need Lookup User, Lookup Item, Check Out
Item, Check In Item, and Renew Item. However, thatʼs where the industry was 6-7
years ago. Today, we need messages that are not part of the Core Message Set, and
those donʼt overlap with the messages needed for ILL.”
OʼBrien noted that we often start with the messages rather than the services. “If we
started with wire frame diagrams to show what functionality is expected,” he said, “then
we could determine what messages are required on the backend. These might help us
better communicate, both amongst ourselves and with libraries.” Wanner agreed,
saying that we may have skipped a step. “We assume that we all understand the
requirements. However, we seem to have identiﬁed three potential message cores:
Patron Services, ILL, and Circulation.” Iddings suggested that we might consider
adding a Discovery-to-Delivery core.
OʼBrien suggested that we should review what “circ-to-circ direct” looks like and attempt
to see how it differs from DCB. “That might lead to a more consistent view of the
interactions that can then be applied to the more general case of DCB,” he said.
Jackson expressed a concern with the approach. “I would worry,” she said, “that, while
interesting as a theoretical discussion, we may not have a true business case.” Iddings
said we should talk to the people at the eXtensible Catalog (XC) project to see if they
have envisioned circ-to-circ connections or if they expect to have a middle component.
Wanner indicated that there focus thus far has been to talk to their own system.
OʼBrien added that we should consider, too, some of the details associated with an
intelligent client talking to a server (particularly for self-service and as opposed to server
to server). “We think about a user checking out,” he said. “Perhaps they owe a ﬁne and
pay it. However, there are more details like whether the user can browse a list of ﬁne
items owed and individually select them. Starting with a hypothetical user interface
showing the userʼs perspective might make it possible to more clearly differentiate selfservice from DCB or ILL.”
Page 10 of 47Core Messages
Wanner asked the group to continue the discussion of Core Messages. “Weʼve talked
about dividing them by application context and addressing Circulation, Patron Services,
and ILL,” she said. “Weʼve also talked about approach the messages as either Client/
Server or System-to-System.” The group decided to ﬁrst consider a circulation core by
focusing on functions rather than messages. It created the following list of tasks that
might be performed by a circulation system.
* Circulation
* Check In
* Check Out
* Patron Identiﬁcation
* Patron Veriﬁcation
* Renew
* Holds
* Reserves
*Item Availability
* Fines and Fees
* Overdues
* Notiﬁcation for Overdues, Hold Pickup, etc.
* Patron CRUD (Create, Update, and Delete)
*Inventory Control (Item CRUD)
*Item Identiﬁcation
* Blocks and Traps
The group then did the same for Patron Services.
* Patron Services
* Patron Identiﬁcation
* Patron Veriﬁcation
* Blocks and Traps
* Single Sign On
* Holds
* Reserves
* Home Delivery
* Fines and Fees
* Patron CRUD (possibly without Delete)
* Recall
* Download / Create (eResources)
*Item Expiration / Delete (eResources)
* Usage History and Reporting
Finally, the group addressed ILL.
Page 11 of 47*Inter-Library Loan
* Request (may be synonymous with Holds)
* Manage Temporary Resources
*Items
* Patrons
* Fines and Fees
* Overdues
* Recalls
* Notiﬁcations
* Patron Identiﬁcation
* Patron Veriﬁcation
*Item Identiﬁcation
* Check Out
* Check In
* Ship / Receive Item
* Download / Create (eResources)
* Renew
The group observed that there appeared to be much overlap among the items on the
three lists. OʼBrien, though, noted that things that are named similarly in different lists
may be handled subtly but signiﬁcantly differently.
Wanner asked if we need a separate category for DCB or if the core functions would be
the same even if the underlying steps are different. Gray stated that he thinks of ILL as
lending an item to another institution. “In that context,” he continued, “it doesnʼt matter
to me what patron or item the other institution uses. I know that eventually I will get the
item back.” OʼBrien said that he views DCB and separate from ILL. “There are
differences in the functions each supports at the conceptual level. When you include
the patron, DCB offers a richer set of functionality than ILL.” He cited “pick up
anywhere” as a concept that might require one system to copy patron records from
another. Jackson said that ILL can also allow a patron to pick up an item anywhere.
OʼBrien clariﬁed that ILL deﬁnes a relationship between two libraries and no patron is
involved. In DCB, the relationship is between a remote library and a local patron. DCB
allows patrons to perform functions in another libraryʼs system. Wanner said that
underneath the functions are similar. “The difference is in who performs them,” she
added. “It may be a matter of policy.”
Walsh said that we appear to have created the same list three times. “I imagined a
narrower view of circulation,” he continued. “Patron Services might include much of
Circulation, but it would add other functions. ILL would include Circulation, too, and it
would add its own functions which would be different than those added for Patron
Services.” Wanner suggested that we might consider trying to deﬁne the more narrowly
focused lists. Jackson, though, said that if we remove holds and overdues (for
example) from Circulation, then people look at the Circulation list and say, “You donʼt do
circulation because you donʼt do overdues and holds.” Wanner said she would make
that statement the other way. “I do circulation plus ILL.” Barr suggested that instead of
Page 12 of 47attempting to deﬁne 3 or 4 narrowly focused lists, we could create lists that build on
each other. OʼBrien expressed support for the idea so long as we are able to create
overlapping concentric circles rather than Venn diagrams. Gray and Jackson somewhat
simultaneously suggested that the proper separations might be “managing the user
(Patron),” “managing the items (Circulation),” and “managing my relationship with
another institution (Resource Sharing).”
Iddings observed that we have not yet begun to address the cases where the item is not
known. These cases all assume we have a known item. OʼBrien explained that NCIP is
all about having a known item and a known patron. “It isnʼt deﬁned to deal with
discovery to handle the special cases where the item is unknown,” he said. Jackson
asked if that is something we should address as we prepare documentation. Wanner
agreed that it might be good to add information explaining that NCIP assume that the
item and the patron are known.
OʼBrien asked what would happen if we assumed that Circulation, ILL, and DCB are all
the same and that anything can be a patron. Perhaps then we could have concentric
circles representing levels of minimum functionality. Level 1 might be Check Out, Check
In, ad Lookup User. Level 2 would represent additional functionality. Walsh indicated
that it might not take long, though, before we ﬁnd the need to branch. For example,
some applications might need ﬁscal transactions while others donʼt. Any functionality
that is deﬁned in a level beyond that which contains ﬁscal transactions is unavailable to
any application that does not need ﬁscal transactions.
Stewart noted that when we originally deﬁned the Core Message Set, the focus was on
simplifying. “It seems now like weʼre making things more complex,” he said. “If the
Core has too many messages, we should see if some can be removed.” Jackson
offered that the problem with the Core is that not everyone supports the whole Core.
Stewart suggested that, in cases where the vendor is missing only one or two
messages, it should just implement them. Alternatively, we could redeﬁne the core to
remove those considered to be extraneous. Iddings said that from his usersʼ
perspectives, everything in the Core is necessary. Wetzel suggested that we might
need to collect more user feedback on what messages and functions are truly
necessary.
The group decided to compare the current Core Message Set to SIP.
* Core Message Set
* Lookup User
* Lookup Item
* Request Item
* Cancel Request Item
* Accept Item
* Check Out
* Check In
* Renew Item
Page 13 of 47* Recall Item
* SIP (NCIP messages to perform tasks possible with SIP)
* Lookup User
* Lookup Item
* Check Out Item
* Undo Check Out Item
* Check In Item
* Create User Fiscal Transaction
* Renew Item
* Update User (limited availability in SIP; currently used to block a user)
* Create User (not available in SIP but needed)
Campbell said that this still does not address the issue of whether an application is a
responder or an initiator. If two vendors have only responders, then I cannot implement.
The circ-to-circ piece is missing. Jackson added that sometimes the messages deﬁne a
given workﬂow. For example, the item in an ILL transaction must be returned to a
speciﬁc location. OʼBrien noted that vendors will need to be clear about what roles they
play in given contexts. Wanner said that while we donʼt disagree philosophically with
the idea of circ-to-circ. “However,” she continued, “if that is required for Core Message
compliance, then the fact is that no systems will be compliant.” Campbell reiterated that
we need to stress the importance to be clear about the role. Wanner asked if
compliance is required only for a responder or if it is equally valid for an initiator.
OʼBrien suggested it makes sense only for a responder. Walsh suggested that it should
be possible for an initiator to be compliant if it makes sense in the speciﬁc context
associated with the application. OʼBrien also noted that initiators may need to be
careful about implementing messages beyond the core since compliant responders are
not guaranteed to respond.
Wetzel said that NCIP compliance has been (and should remain) a single message.
Compliance with the core, though, should be all messages in the Core. OʼBrien agreed
that we need to pick a label that indicates when an implementer says “I comply” that
there can be no misunderstanding. Stewart said that when an initiator claims to support
the ILL Core, it should support all of the messages in that Core. Wanner said that it
should be acceptable for implementers to say “No, I donʼt support all of the messages in
the Core because only one is needed for this application.”
Boettcher suggested using the term “Support” rather than the term “Compliant.”
OʼBrien suggested a system (using non-sensical animal names as placeholders for real
labels that would need to be determined) for claiming full or partial compliance with the
Core. Full support would be associated with one label, while partial support would use
another. Walsh suggested something like “Full support as an initiator,” “Partial support
as a responder,” etc. as labels that we might use.
Page 14 of 47Wanner asked whether responding to a message with some kind of “Message Not
Understood” is sufﬁcient for a responder to claim compliance. Jackson said that since
the result would not be that which is desired, this should not indicate compliance.
Ultimately, the group agreed to identify a common Core with extensions for Self-Serivce
and other extensions for Resource Sharing. Iddings, Campbell, and Wanner offered to
help draft some language describing the Core Message Sets and how an implementer
describes its support for them. They hope to complete this task before ALA in June
2009.
Recall Item
Wanner asked if anyone objected to having Recall Item as part of the Core Message
Set. Dickson said that it did not appear to be as important as other messages in the
Core. Wanner agreed that, in public libraries particularly, the need for Recall Item is
probably small. Boettcher asked whether it is truly necessary to do ILL. Walsh recalled
that at the September 2009 meeting Campbell suggested deﬁning a public and an
academic core. Dickson asked whether recall would become more important to public
libraries in the future, and Wanner observed that some consortiums have both public
and academic members. After some additional discussion, the group agreed that Recall
Item should remain in the Core Message Set for Resource Sharing.
Implementer Registry
Wanner noted that we will need to modify the submission forms that have been created
for responders and initiators to indicate their support for the Core Message Sets. She
asked how we want to capture and display the information. Wetzel showed a system
created by the SUSHI working group (http://sites.google.com/site/sushiserverregistry).
Dickson asked whether the system has support for version control. Wetzel was not
sure. She thinks they retain older versions manually.
Campbell asked whether only limited support for data elements undermines
compliance. Wanner said that the submission forms should indicate which data
elements are required and which are optional. “A compliant system must support all
required data elements,” she added. Jackson suggested that the form should group
data elements into categories for “Required,” “Optional,” and “If Requested.” Stewart
asked if the forms should go to the level of which User Optional Fields are supported.
Wanner said that this level of detail was not planned because it seems like too much
information for customers. It would, though, be necessary for other implementers.
Wanner, Campbell, and Jackson agreed to revise the existing submission forms and to
create analogs for Self-Service before ALA in June 2009.
Page 15 of 47Continuous Maintenance
Wetzel explained that, even though the Standard may change through Continuous
Maintenance, the ofﬁcial version will always be Z39.83-2008. Because the schema was
not part of what was balloted, it may change at any time. Jackson presented a
hypothetical example where we removed Recall Item from the protocol. “How would an
implementer know what ʻversionʼ has Recall Item and which does not?” she asked.
Wetzel said that we can track changes with information version labels. She suggested,
too, that we keep a change log. The Standard can change; the Standardʼs designator
cannot. It would be acceptable, for example, to identify a revision as Z39.83-2008
followed by some sort of revision indicator. To do that, we need to add language to the
Standard that deﬁnes the versioning structure. OʼBrien indicated that changes to the
schema require a new label for the schema. That implies a new version (2.0 -> 2.01, for
example), and the Standard should somehow reﬂect that versioning. Walsh
summarized the conversation by indicating that we should adopt a versioning scheme
beneath the Z39.83-2008, that we should add a preface that describes the versioning
process, and that we should keep some kind of change history (perhaps as an
Appendix) and/or explanation of the changes from the prior version.
Taking NCIP to ISO
Wanner reopened the discussion about whether we should ask ISO to standardize
NCIP. Wetzel said that this would require a proposal to the Discovery-to-Delivery Topic
Committee. “The fact that there are no Version 2 implementations,” she added, “would
make ISO adoption challenging.” Wanner observed that support is growing, and she
asked why we have to distinguish between Version 1 and Version 2 implementations.
Wetzel said that ANSI limits us to only the current version. Version 1 is no longer
consider “active.” OʼBrien said that he understands both sides of the issue. “It may be
embarrassing to submit Version 2 because there are so few implementations. At the
same time, though, Version 1 is 4-6 years old. It seems that the only real option is to
wait for more Version 2 implementations before submitting to ISO.” Wanner agreed with
OʼBrien.
ALA Social Hour
Wanner explained that the current plan is to meet Sunday afternoon or early evening at
some place near the convention center. Wetzel said that it may be challenging to ﬁnd a
place that will handle a group without committing to dinner seating. Wanner indicated
that we would like to ﬁnd a casual but relatively quiet place where we can converse.
Iddings suggested that we convene in the lobby bar in the Renaissance Hotel. The
group agreed that this would be an appropriate location. Wanner and Jackson agreed
to draft an invitation that can be sent to groups like the ILL-DD, Rethinking Resource
Sharing, LLAMA-SASS, and RUSA STARS. Given the low turn out at last yearʼs event,
we should not be too concerned about inviting too many people.
Page 16 of 47Wednesday, April 28
Presentation by RapidRadio
Kotecha gave a presentation (remotely from India) outlining RapidRadioʼs journey with
NCIP, NCIP awareness in Asian markets, and suggestions for improving the adoption of
NCIP. (Kotechaʼs presentation is included in Appendix A.)
Walsh agreed to follow up with Kotecha to get the additional information that he
indicated he would be willing to provide during the question and answer session that
followed his presentation.
Presentation by the eXtensible Catalog Project
Bowen provided a summary of the eXtensible Catalog (XC) Projectʼs efforts and how it
has incorporated NCIP. (Handouts were provided and have been reproduced in
Appendix B.) The project has four open source toolkits (available at
extensiblecatalog.org) that collectively allow applications to harvest data from the ILS.
One toolkit does the actual data harvesting, while another does metadata processing.
These do not use NCIP. The third and fourth toolkits are called the Drupal Toolkit and
the NCIP Toolkit. The Drupal Toolkit talks to the NCIP Toolkit which gets the information
from the ILS. When used together, the four toolkits provide an end-to-end solution.
Many libraries use various combinations of the four to do speciﬁc tasks. The XC Project
works with many libraries to develop the connectors to speciﬁc back-end ILS. Currently,
they have support for Voyager Classic versions 6 and 7 (developed by the University of
Rochester), Aleph version 1.8 (developed by Notre Dame; efforts are underway to
migrate to Aleph version 2.0), and Innovative Interfaces running on Oracle. Support for
Innovative Interfaces using the non-Oracle database is underway at the University of
North Carolina, Charlotte. Cornell has done some work to interoperate with ILLiad and
has portions in production. Some of their system uses NCIP. The XC Project hopes to
incorporate Cornellʼs work into the project soon.
Cook explained the Drupal and NCIP Toolkits in more detail, and he showed their NCIP
Test Bed implemented in Drupal. All of their work so far is with NCIP Version 1. He
explained that there are some messages in the Core Message Set that are not
implemented in the XC. Since they are primarily a discovery tool rather than a
transaction processing application, so they have no need to circulate. They are, though,
thinking of adding support for Renew. They did add additional verbs to their
implementation of NCIP in order to meet speciﬁc needs. They added XC Lookup User
and XC Get Availability, primarily to meet ILS-DI/DLF requirements. Walsh found the
ILS-DI/DLF recommendations on the Internet and explained that GetPatronInfo requires
that Contact Information, Fines, Holds, Loans, Recalls, and Messages be available. In
NCIP Version 1, some of this information is available via Lookup User. In Version 2, all
Page 17 of 47but Recalls and Messages should be available, but those could be implemented via
extensions.
Cook asked whether Version 2 supports a way to request a range of IDs to generate
results set. Wanner explained that we do have a proposal that would allow various item
IDs to be repeated in some messages. Wetzel suggested that the XC Project might
consider submitting a proposal to address its speciﬁc needs. She explained that, under
Continuous Maintenance, change requests are reviewed twice per year.
Wanner asked whether ILLiad is supporting NCIP messages directly. Cook indicated
that he thinks they are getting the information through some other manner and the
Cornell interface is formatting the response in NCIP.
Cook reported on a new code4lib group called ILS Interop that has formed to create a
standard mechanism for communicating with ILS backends in order to do discovery.
They are considering the use of the XC NCIP Toolkit, but they are also considering
Jangle and other options. Bowen added that the goal is to have one approach that is
standard for discovery applications to harvest information from the ILS. Cook said that
the XC believes that NCIP provides a good approach since it already exists. However,
some in the ILS Interop group feel that NCIP is overkill for this project. They cite NCIPʼs
option to use either structured or unstructured information (for patron names and
addresses, for example) as one reason why NCIP is inappropriate. The XC NCIP
Toolkit uses unstructured names, but the ILS Interop group wants to use structured data
so that the last name is easily identiﬁed. Also, some have said that NCIP moves too
slowly and does not respond to library needs. The concept of currency, too, is one that
seems overly complicated to use.
Wanner indicated that weʼve struggled before with structured versus unstructured data.
The NCIP IG is not in a position to dictate whether to use one or the other. She
volunteered that we would be happy to open lines of communication with the ILS Interop
group, either by participating in their calls or having them participate in ours. However,
if John Bodﬁsh of OCLC is part of that group, he is very knowledgeable about NCIP and
will represent it well. Cook indicated that the ILS Interop group has calls every two
weeks. Bowen added that anyone interested in participating should contact Karen
Coombs at OCLC.
Cook mentioned also that the ILS Interop group has discussed using RESTful web
services. OʼBrien explained that REST is a ﬂavor of web service that uses XML over
HTTP POST. When used over HTTP, the NCIP schema may be considered a RESTful
service. Wetzel and Stewart agreed to research whether NCIP could be considered
RESTful.
Wetzel asked what it would take for the XC Project to migrate to NCIP Version 2. Cook
explained that the project is currently understaffed, and it does not have the resources
necessary to undertake the migration to Version 2. The current issues list may be a
month of work for two developers. At some point, the Project will need to decide
Page 18 of 47whether to address the existing issues to make the current Version 1 implementation
compliant or whether to simply move to Version 2. If the ILS Interop group decides to
use NCIP, it will probably want to use Version 2. Wanner offered that we could review
the issues list and help determine whether any are already addressed in Version 2.
Bowen agreed that the Project might beneﬁt from having someone advise it on what it
could gain by moving to Version 2. OʼBrien volunteered to provide some guidance,
particularly as it relates to the schema. He added that many of the messages and data
elements have the same names and structures in Versions 1 and 2.
Cook explained that they XC Project roadmap has most of their efforts going toward the
metadata and Drupal Toolkits.
Wetzel asked if there is any value for the XC Project to move from Version 1 to Version
1.01. OʼBrien indicated that he did not think any of the 1.01 changes would justify the
effort.
Cook asked if anyone has ever requested a “Renew All” function. OʼBrien indicated that
Renew All could be supported today via iteration. However, this calls into question the
stateless nature of the protocol since subsequent requests may expect changes as a
result of earlier requests. Bowen asked whether GetAvailability used to get the status
on multiple items might have the same potential problem. OʼBrien said it may be
similar, but NCIP has no support for that function currently. Leckbee added that Renew
All also raises the question of partial success or failure. Some items may successfully
renew while others do not.
Cook asked if there is a list of people using NCIP. Wanner said that there is a list (http://
www.ncip.info/implementer_registry) but it may be dated. Wetzel added that we are
working on a more interactive Implementer Registry to provide this information.
Wanner closed the discussion noting that it was valuable. She invited the XC Project to
have a representative (or even a rotation of individuals) participate in the NCIP IG.
Change Requests Review
Walsh summarized the Continuous Maintenance process and explained that, for each
request, the group must decide whether to accept it without modiﬁcation, accept it with
modiﬁcation, accept it for further study, or reject it. Some discussion of versioning and
the challenges associated with changes that involve the schema and changes that
involve only the Standard. The group decided that, when viewed collectively, change
requests are unlikely to effect only one or the other.
Page 19 of 47Walsh led a review of the change requests that had been received prior to the March 1,
2010, deadline. He began with those reporting defects against the Standard.
Number: 2010-01-0001
Type: Defect
Subject: The optional Ext element is not reﬂected anywhere in the Standard
Description: The fact that Ext is optional in many elements is not reﬂected in the
Standard.
Discussion: OʼBrien noted that the Ext element is, in fact, optional in every
message in the protocol.
Decision: Accept without modiﬁcation. Update the Standard document to
show all of the places where the Ext element may be used.
Number: 2010-01-0002
Type: Defect
Subject: The optional Institution Header and Response Header are not
reﬂected anywhere in the Standard.
Description: The fact that Initiation Header and Response Header are optional in
every message is not reﬂected anywhere in the Standard. To be correct, they need to
be added as optional data in every element in Section 5.
Discussion: None
Decision: Accept without modiﬁcation. Update the Standard document to
show all of the places where Initiation Header and Response Header may be used.
Number: 2010-01-0003
Type: Defect
Subject: Accept Item Response “Required Data:” and “Optional Data:” may
be misleading.
Description: In Section 5.4.1, Accept Item Response - Required Data: and
Optional Data: may misleading. Currently, they read
Required data: Problem, or Request Id
Optional data: Item Id
That might lead one to think that the Item Id an be part of the Problem element.
However, Item Id is not valid within the Problem element; it is meant to be used only
with Request Id.
Discussion: None
Decision: Accept without modiﬁcation. Update the Standard document to
clarify that Item Id is valid only as part of Request Id.
Page 20 of 47Number: 2010-01-0004
Type: Defect
Subject: User Optional Fields in Item Recall Cancelled is an optional
element in the schema but not in the Standard.
Description: In Section 5.5.8, Item Recall Cancelled - User Optional Fields is an
optional element in the schema but not in the Standard. Given that in most cases
where both User Id and Item Id are valid, it is appropriate to have both Item Optional
Fields and User Optional Fields, it would seem that this represents a defect in the
Standard and the schema is correct.
Discussion: None
Decision: Accept without modiﬁcation. Update the Standard document to
match the schema.
Number: 2010-01-0005
Type: Defect
Subject: The text of “Required Data:” in Lookup Request Response should
be reworded.
Description: In Section 5.3.3, Lookup Request Response - The test of “Required
Data:” in the Standard should probably read:
{Item Id or {Request Id and, optionally Item Id}}
as it does in Section 5.3.2 Lookup Item Response. This reﬂects the structure of the
schema.
Discussion: None
Decision: Accept without modiﬁcation. Update the Standard document to
match the schema.
Number: 2010-01-0006
Type: Defect
Subject: Elements in Lookup Request are repeatable in the schema but not
in the Standard.
Description: In Section 5.3.3, Lookup Request - Item Element Type, Request
Element Type, and User Element Type are all repeatable in the schema but not in the
Standard. It seems that the schema is correct and the Standard needs to be changed
to match.
Discussion: None
Decision: Accept without modiﬁcation. Update the Standard document to
match the schema.
Page 21 of 47Number: 2010-01-0007
Type: Defect
Subject: Table 2 in Implementation Proﬁle 1 should have space between
Public and System Ids
Description: In the XML example in Table 2 in Implementation Proﬁle 1, there
should be a space between the PUBLIC and SYSTEM ids.
Discussion: OʼBrien found several examples of valid XML on the Internet and all
have a space between the PUBLIC and SYSTEM ids.
Decision: Accept without modiﬁcation. Update the Standard document to add
a space between the PUBLIC and SYSTEM ids.
Number: 2010-01-0008
Type: Defect
Subject: Table 2 in Implementation Proﬁle 1 gives a URI that does not
resolve to the NCIP schema.
Description: The NCIP schema does not appear to be located at http://
www.niso.org/ncip/v2_0/imp1/xsd/ncip_v2_0.xsd.
Discussion: None
Decision: Accept without modiﬁcation. Request that NISO move the schema
document to the location speciﬁed in Table 2 of Implementation Proﬁle 1.
Number: 2010-01-0009
Type: Defect
Subject: Table 2 in Implementation Proﬁle 1 has the wrong XML version.
Description: The example is Table 2 in Implementation Proﬁle 1 gives the XML
version as “2.0.” This should be “1.0.”
Discussion: None
Decision: Accept without modiﬁcation. Update the Standard document to ﬁx
the XML version number.
Number: 2010-01-0010
Type: Defect
Subject: User Id is allowed both inside and outside of User Optional Fields;
however, Item Id is not allowed inside Item Optional Fields.
Description: Need to determine which is “correct” and ensure that both are
handled consistently.
Discussion: User Id can be used both as an identiﬁer and as data. When used
outside of User Optional Fields, it is a key. When used inside, it is simply data.
Decision: Accept for further study. Attempt to ﬁnd concrete use cases that
require Item Id to be used outside of Item Optional Fields.
Page 22 of 47Number: 2010-01-0011
Type: Defect
Submitted By: Dushyant C. Upadhyay (dushyant@rapidradio.co.in)
Organization: RapidRadio Solutions Pvt. Ltd.
Submitted Date: 25 January 2010
Subject: Table 1 in Implementation Proﬁle 1 has incorrect XML structure.
Description: In Version 2.0, all of the Scheme/Value pair elements were replaced
with a simple string value and an optional scheme attribute. In other words, what in
Version 1.x was:
<Amount>
<CurrencyCode>
<Scheme>SomeSchemeURI</Scheme>
<Value>SomeValueForCurrencyCode</Value>
</CurrencyCode>
<MonetaryValue>TheAmountAsAnInteger</MonetaryValue>
</Amount>
would in Version 2 be:
<Amount>
<CurrencyCode Scheme=”SomeSchemeURI”>
SomeValueForCurrencyCode
</CurrencyCode>
<MonetaryValue>TheAmountAsAnInteger</MonetaryValue>
</Amount>
The example in Table 1 in Implementation Proﬁle 1 may be one that was overlooked
during the ﬁnal editing process for Version 2.
Discussion: None
Decision: Accept without modiﬁcation. Update the example in the Standard
document to be correct for Version 2.
Page 23 of 47Number: 2010-01-0012
Type: Defect
Submitted By: Robert Gray (Robert.Gray@PolarisLibrary.com)
Organization: Polaris Library Systems
Submitted Date: 27 January 2010
Subject: The order of the elements in Prompt Input is different in the
Standard and the schema.
Description: The Standard declares the subelements of Prompt Input as
Authentication Data Format Type, Authentication Input Type, then Sensitive Data Flag.
The schema presents these elements as Authentication Input Type, Authentication Data
Format Type, then Sensitive Data Flag (followed by Ext).
Discussion: Gray explained that the order in the schema may cause some code
to be forced to parse the Authentication Input Type element before it knows what format
the data is in. OʼBrien, though, indicated he did not see a compelling reason to
potentially break implementations in order to switch the order of the elements. Since
most implementations use generated classes to parse the XML, this should rarely be an
issue in practice since the all of the data is put into a class before it becomes available
to the application.
Decision: Accept without modiﬁcation. Update the Standard document to
match the schema.
Number: 2010-01-0013
Type: Defect
Submitted By: Robert Gray (Robert.Gray@PolarisLibrary.com)
Organization: Polaris Library Systems
Submitted Date: 27 January 2010
Subject: The order of the elements in Authentication Prompt is different in
the Standard and the schema.
Description: The Standard declares the subelements of Authentication Prompt
as Prompt Input and then Prompt Output. The schema presents them in the reverse
order.
Discussion: None
Decision: Accept without modiﬁcation. Update the Standard document to
match the schema.
Page 24 of 47Number: 2010-01-0014
Type: Defect
Submitted By: Dushyant C. Upadhyay (dushyant@rapidradio.co.in)
Organization: RapidRadio Pvt. Ltd.
Submitted Date: 22 February 2010
Subject: Loaned Items and Requested Items are named differently in the
Standard and the schema.
Description: On page 20 of the Standard (the printed number on the page is 10),
the data elements of Lookup User Request have been listed. In the list, “Loaned Items”
and “Requested Items” do not match the schema. According to the schema, the
element names should be “Loaned Items Desired” and “Requested Items Desired.”
Discussion: The group acknowledged that this was an oversight during ﬁnal
editing for Version 2.
Decision: Accept without modiﬁcation. Update the Standard document to
match the schema.
Number: 2010-01-0015
Type: Enhancement
Submitted By: OCLC
Submitted Date: During Version 2 balloting
Subject: Bibliographic Record Id is not repeatable in Bibliographic
Description of Accept Item.
Description: Bibliographic Record Id is not repeatable in Bibliographic
Description of Accept Item. It should be possible, for example, for an initiator to send
Accept Item using both an OCLC number and an LCCN number.
Discussion: Jackson clariﬁed that the requested change should be generic with
respect to the types of ids allowed and not limited to OCLC and LCCN. Gray asked
what the responder is accepting. Is it one item with two ids, or is it two separate items.
OʼBrien explained that, when one is creating a temporary record, one may need multiple
ids to represent a single item. “It seems like a fairly non-offensive change that would be
generally useful,” he said. Wanner added that it is primarily a resource sharing issue.
The lending organization may use one id, but the borrowing organization may use a
different one. The common record, then, needs both. Gray asked if this would make
Bibliographic Record Id repeatable everywhere it is used. OʼBrien indicated that the
ﬁeld is used only to carry information, never to identify an item, so allowing it repeat
should not cause any problems.
Decision: Accept without modiﬁcation. Change the schema to make
Bibliographic Record Id repeatable within Bibliographic Description. Then update the
Standard document to match the changed schema.
Page 25 of 47Number: 2010-01-0016
Type: Enhancement
Submitted By: OCLC
Submitted Date: During Version 2 balloting
Subject: Request Item does not allow a combination of Bibliographic Record
Id and Item It.
Description: Request Item does not allow a combination of Bibliographic Record
Id and Item Id, and it does not allow either to be repeated. An initiator should be able to
send both, and it should be possible to send more than one of each.
Discussion: OʼBrien explained that today one must choose to send either an
Item Id or a Bibliographic Id but not both. This proposal would allow an initiator to send
either or both. Gray asked if that meant the request would be for a speciﬁc item or any
item that matches the Bibliographic Id. OʼBrien said that he did not think that was
meant to be the case. It was meant to provide extra information. Wanner asked if it
was extra or alternative information. Gray said that his understanding is that an Item Id
always represents a single item. A Bibliographic Id would mean any item that matches
the given criteria. Stewart noted that the proposal also includes a request that each be
made repeatable. OʼBrien suggested that we need more information on why this
change was requested so that we donʼt risk an implementation that is ambiguous.
Decision: Accept for further study. Attempt to ﬁnd a use case that
demonstrates how multiple and repeatable Item Ids and Bibliographic Ids might be
used. However, through additional discussion, this decision was changed to “accept
without modiﬁcation.”
Number: 2010-01-0017
Type: Enhancement
Submitted By: OCLC
Submitted Date: During Version 2 balloting
Subject: NCIP is too cautious with respect to element repeatability.
Description: Recent implementation experience has shown that NCIP remains
too cautious in the design of its data structures, speciﬁcally in the area of element
repeatability. The Standard allows for tightening of rules via application proﬁles (e.g.,
marking an optional element mandatory), but it does allow permit loosening of rules as
would be the case if a non-repeatable element were allowed to repeat. If more
elements are allowed to repeat it will also be necessary to specify the semantics. In
some cases, it may be obvious how multiple or repeated elements are to be handled.
But where the element is part of a key (e.g., Request Itemʼs Bibliographic and Item Ids),
perhaps the semantics are that the initiator thinks any of them is valid, and the
responder gets to choose. In these cases the responder ought to return the key chosen
in the response.
Discussion: OʼBrien indicated that this seems to require open discussion within
the group. It may be quite useful, but it may lead to chaotic and ambiguous
implementations. Wanner explained that she could see making something like ISBN
repeatable since many bibliographic records contain multiple ISBN numbers. Two
disparate systems may not have identical bibliographic records. Repeating ISBNs,
then, would seem to make sense. Jackson asked if we would also allow elements like
Page 26 of 47title and author to repeat so that we could send different titles and different authors.
Gray indicated that would not be relevant since we cannot search on title and author.
Walsh noted, though, that the same example might be valid with ISBNs where two
ISBNs do not represent the same work. That could lead to a confusing implementation.
OʼBrien explained that the request is to make every element repeatable and to restrict
them where necessary through proﬁles. Jackson asked what problem the proposal is
trying to solve. OʼBrien said that the problem is philosophical rather than practical. He
presented an example using Accept Item. It contains User Id. Repeating that might
prove to be problematic. Jackson, however, said it could represent a book club.
Stewart asked what it would mean to repeat a Pickup Location. The group
acknowledged that would be a problem Gray indicated that the excessive repeatability
might signiﬁcantly increase the overall bulk of the messages. A Check In message with
many items could get pretty big. Walsh observed that if one plan to execute the same
number of check ins with separate messages, the aggregate would probably be less.
Gray said that the response would likely be slower, however.
Decision: Accept for further study. Attempt to ﬁnd use cases for how it might
be used effectively and provide examples to the submitter showing potential problems.
Number: 2010-01-0018
Type: Enhancement
Submitted By: The Library of Congress
Submitted Date: During Version 2 balloting
Subject: There is no way to distinguish individual users from institutional
users.
Description: There is no way to distinguish individual users (with personal
names, birth dates, etc.) from institutional users (libraries). This has been a shortcoming in our circulation patron data since our ILS was implemented.
Discussion: The group noted that there is nothing that precludes the use of
User Id to represent institutions. The “User” in NCIP is the entity requesting an action or
information, and patron type, agency, and other data elements could be used to
distinguish various types of users.
Decision: Reject
Number: 2010-01-0019
Type: Enhancement
Submitted By: The Library of Congress
Submitted Date: During Version 2 balloting
Subject: It is not possible to represent patrons “owned” by larger patron
entities.
Description: NCIP has no facility to allow patrons to be “owned” by larger
institutions (e.g., Congressional ofﬁces).
Discussion: The group noted that this is a function of the ILS rather than
something that should be provided through NCIP. Data elements may be used to
provide hints to the ILS as to the true nature of the “patron” identiﬁed through the User
Id.
Decision: Reject
Page 27 of 47Number: 2010-01-0020
Type: Enhancement
Submitted By: Brent Jensen (brent.jensen@sirsidynix.com)
Organization: SirsiDynix
Submitted Date: During Version 2 balloting
Subject: Allow the Problem element to repeat
Description: Ensure that the Standard and the schema agree on whether the
Problem element is repeatable.
Discussion: None
Decision: Accept without modiﬁcation. Update the Standard document to
match the schema.
Number: 2010-01-0021
Type: Enhancement
Submitted By: Brent Jensen (brent.jensen@sirsidynix.com)
Organization: SirsiDynix
Submitted Date: During Version 2 balloting
Subject: Add “transaction agency” or “transaction location” to Accept Item
message.
Description: Add “transaction agency” or “transaction location” to Accept Item
message.
Discussion: Wanner explained that Accept Item needs a third agency to
represent the pick up location. There may even be a need for a fourth agency
representing where the lending agency needs to send the item in order to get it into the
borrowing system. Jackson asked if that is simply a function of the borrowing system.
Wanner asked how the borrowing system knows where the user wants to pick up the
item. Stewart noted that Version 2 has Pickup Location within the Accept Item
Response.
Decision: Accept for further study. Ask Jensen whether Pickup Location
within Accept Item Response meets his needs or if there are additional use cases.
Page 28 of 47Number: 2010-01-0022
Type: Enhancement
Submitted By: Brent Jensen (brent.jensen@sirsidynix.com)
Organization: SirsiDynix
Submitted Date: During Version 2 balloting
Subject: Re-review the process for requesting optional information in the
Lookup User message.
Description: Towards the end of the Version 2 review process, some changes
were made to the way the Lookup User message allows an initiator to request optional
information. Some of those changes had to be “undone” during ﬁnal editing, and the
result is an inconsistent and suboptimal approach to requesting optional data. See
Loaned Items and Loaned Items Count for examples.
Discussion: OʼBrien noted that we should probably revisit the entire approach to
requesting optional data. We need a container that can hold all of the things that can be
requested, and that set of boolean elements would indicate what I want returned. This
would be consistent and much simpler. However, it would break backward compatibility.
Walsh said that weʼve discussed, at least informally, that compatibility breaking changes
are to be reserved for major revisions (i.e., when moving from Version 2.x to Version
3.0). OʼBrien suggested that, according to that rationale, we should not make this
change. Stewart acknowledged that while the current approach is message it does not
impact the functionality of the system. Wanner agreed that it does not seem like a
critical issue.
Decision: Reject. This change would break compatibility without adding any
new functionality.
Number: 2010-01-0023
Type: Defect
Submitted By: Rob Walsh
Organization: EnvisionWare
Submitted Date: During review of change requests at this meeting
Subject: Lookup User shows Loaned Items as a required element in the
Standard.
Description: Loaned Items should be moved into the list of optional elements in
the documentation for Lookup User in the Standard.
Discussion: None
Decision: Accept without modiﬁcation. Update the Standard document to
correct the error.
After a brief break, Wanner asked if we made enough changes to justify a new revision.
She reminded the group that it would be required to publish the revision within two
months because that is the process that was approved by ANSI. The group agreed that
we should publish a 2.01 revision with the accepted changes. OʼBrien agreed to make
the necessary schema changes, Walsh agreed to update the Standard as appropriate,
and Walsh and Wanner agreed to contact those who submitted change requests to let
them know the disposition of their proposals.
Page 29 of 47Repeating the Bibliographic Id and Item Id in Request Item
OʼBrien returned to the issue of repeating the Bibliographic Id and Item Id in Request
Item. He had been able to communicate with colleagues at OCLC and had some
additional information about the proposal. He said the intent of the change request is to
be able to place a hold on any copy of any of the ids submitted. Jackson asked whether
that would result on a single title. OʼBrien indicated that, yes, the request would be for a
single title. In other words, no matter how many ids were part of the request, the
responder should pick one and place a hold. The user might have found a only a single
bibliographic record, but the system could be smart enough to know that other options
exist. It could then send all of the various ids that match the userʼs request to another
system to place a hold. “Systems should be capable of bridging that gap and make
appropriate connections to improve customer service,” said OʼBrien. Walsh asked if the
same effect could be created through iteration. OʼBrien said that might result in multiple
holds. Jackson said that when the request goes to a particular vendor it should be
possible to say, “I know you have multiple versions of this item and I want any one of
them.” Walsh added that the potential for misuse is mitigated by having the system fail
to do what the abuser hopes it would. For example, if the requesting system wants the
responding system to place a hold on ALL matching items, the user will not get what he
wants. OʼBrien noted that this is a real world problem. “Weʼve seen it in practice,” he
added.
Wanner expressed a concern that NCIP has limited ability for distinguishing media
types. “It may be difﬁcult to restrict the scope to a certain subset of the available
formats,” she said. OʼBrien said that could be handled by including only the ISBNs for
the formats you want. Iddings added that there is a need to say I only want a particular
edition, and that should be handled in the application rather than in the protocol.
Wanner asked if anyone objected to the proposal after the additional discussion.
Stewart asked if it would break compatibility. OʼBrien answered that it would break
responders who receive a request with multiple ids and they expect to get only one.
Stewart asked whether all changes that affect compatibility should be implemented as
extensions. “Changing the structure up to twice each year may upset implementers,” he
said. Dickson asked if we want to make this kind of breaking change for a single issue
or if we should wait and compile them into a bundle. OʼBrien indicated that he could
see pros and cons to both approaches. Walsh asked if there are any changes that can
be made in the schema that do not cause the same problems. “Even an entirely
optional element would choke a responded that does not know it can exist,” he said.
Stewart suggested that we might want to limit our updates to less than twice each year.
Wanner noted that frequent changes might encourage more people to become active so
that their voices could be heard. Dicus observed that many of these proposals have
been pending for almost two years. Walsh noted that deciding to do changes only once
per year might contradict the process that weʼve had approved by ANSI. Jackson asked
how we deal with management when they resist the constant updates, and Gray added
that weʼll end up with customers nagging vendors. Wanner suggested that we could
Page 30 of 47explore what is required to change our process with ANSI. Boettcher suggested that we
go ahead with the changes and let vendors pick the appropriate (and hopefully the most
current) version to implement when they are ready. Wanner agreed that could work as
long as we deﬁne compliance against the original Version 2 instead of against each
minor revision.
Ultimately, the group decided to change the disposition for proposal 2010-01-0016 from
“accept for further study” to “accept without modiﬁcation.”
Review of Action Items
The group brieﬂy reviewed the various action items that had been assigned over the
course of the ﬁrst two days.
Open Test Bed
The group brieﬂy discussed the notion of an open NCIP test bed that could be used to
verify interoperability. In previous discussions on this topic, the group has struggled to
come up with a practical way to implement. Someone would need to volunteer to
develop a responder (and possibly an initiator) that other vendors could use to
exchange messages. Gray noted that this may not be particularly useful in practice.
“Validating the XML is the easy part,” he said. “Decisions about whether to use
structured or unstructured names or addresses is where the real problems occur.”
Walsh agreed that what needs to be tested when verifying interoperability are the
outcomes of the messages, not the format and structure of the messages themselves.
That is difﬁcult to do with a common and generic system. Leckbee noted also that we
would need to have test systems for each version of the Standard.
Page 31 of 47Thursday, April 29
2010 Goals
Wanner revisited the 2009 goals and asked the group to deﬁne goals for 2010. She
noted that some of the goals are on-going. “One of the things I would like to do,” she
said, “is to ensure that the goals we set are achievable. I would prefer to have fewer
goals that we can accomplish rather than many, even if it makes it look like weʼre being
less ambitious.”
The group decided on the following goals for 2010:
Editorʼs Note: The following goals were revised slightly by the Chair and the
Maintenance Agency following the meeting to improve the wording and to clarify the
intent. What is presented here is the revised version rather than the original.
* Support NISO guidelines for membership to ensure a balanced, actively contributing
group
*Improve processes to track and implement formal requirements for attendance
and contribution
* Encourage global participation by implementers outside of North America
* Seek to add library practitioners as members and observers
*Implement the continuous maintenance model for updating the Standard
* Clarify conformance for Version 2 and future versions
* Create, post, and utilize a form for submitting change requests and defects
* Review and act on requests for change in Spring and Fall meetings
* Finalize and publish changes with detailed documentation in a timely manner
* Encourage implementation of NCIP through education and outreach
* Promote adoption of Version 2 by implementers
* Publish Resource Sharing and Self Service Core Message Sets
* Publish an Implementer Registry to track support for Core Messages by
implementers
* Create educational documents for librarians and implementers
* Research other methods to simplify the NCIP learning curve for new
implementers
* Gather and publish NCIP-related case studies and success stories
* Conduct outreach programs to potential implementers, participants, and
observers
Page 32 of 47Technical Support for Implementers
Walsh asked what we recommend to RapidRadio as a means to get help with
implementing. Should we tell them to post a question to the general interest list as has
been done in the past? Jackson said that the general interest list has some inherent
overhead. Having to join and wait for conﬁrmation might discourage people who are
new. Campbell suggested that we create a link on the website where people could
submit questions. The questions (and answers) could then be used to create a
Frequently Asked Questions (FAQ) list. Wanner agreed that this could help us discover
those who are implementing NCIP. Walsh said that it is relatively easy to put a link on
the website, but we have to be prepared to respond to the requests. The group decided
to defer further discussion on this issue until the next conference call.
Encouraging Implementation of Version 2
Iddings noted that one of the issues that plagues implementers may be the lack of
backwards compatibility. “If the vendor community would stop supporting the older
versions, people would need to implement Version 2,” he said. “When Innovative
Interfaces agreed to move forward with NCIP development [using Version 2], we got a
very positive response in the library community.” Campbell added that some states are
beginning to mandate statewide interoperability among K-12, colleges, universities, and
public libraries. “NCIP needs to be ready to step in and make these systems possible,”
she said. Walsh observed that the K-12 vendor community is one that is not
represented in this group. Jackson noted that the question often is who will pay for the
development. Campbell said that she thinks the states will be willing to pay for the
systems, but they need to know what to buy. Walsh suggested that there would need to
be a single entity representing a collection of disparate vendors to serve as the analog
to the entity representing the customers (the states in Campbellʼs scenario). At PALCI,
Iddings has played both roles. Wanner agreed that the project needs to be driven by
someone.
Planning for the Next Meeting
Dicus reported that Ex Libris is willing to host the next meeting in Chicago. The group
tentatively decided to schedule a meeting for September 8-9. The plan is to start at
approximately 9 am on Wednesday and break at around 3 pm on Thursday. The group
decided to schedule only two days for this meeting since we know the signiﬁcant burden
participating in these committees often places on companies and institutions. Chicago
is a desirable venue since it is a central, easy-to-reach location that allows some
participants to limit the number of overnight stays required to attend.
Page 33 of 47Conference Call Times and Technologies
Wanner suggested that we should consider using WebEx or other remote conferencing
technologies to help make our conference calls more productive. The group also noted
that the standard 1:00 pm US Eastern time for calls is not particularly conducive to
people in India. Walsh suggested that we could rotate through a series of time slots
over a three or four month period. The group decided to retain the 1:00 pm US Eastern
for the monthly conference calls until we can determine whether it prevents or deters
global participation.
Next Conference Call
Wanner announced that the next monthly conference call is scheduled for May 20,
2010, at 1:00 pm US Eastern. Call in details are available on the NCIP website (http://
www.ncip.info).
Adjournment
Wanner adjourned the meeting.
Page 34 of 47Appendix A - Presentation by Dhaval Kotecha, RapidRadio
Page 35 of 47Page 36 of 47Page 37 of 47Page 38 of 47Page 39 of 47Page 40 of 47Appendix B - Handouts from eXtensible Catalog Project
Page 41 of 47Page 42 of 47Page 43 of 47Page 44 of 47Page 45 of 47Page 46 of 47Appendix C - Action Items
What Who By When
Check with LLAMA-SASS / RUSA STARS groups about
participating in ALA forum again this summer
Wanner
Draft language describing the Core Message Sets and
how an implementer describes its support for them
Iddings, Campbell,
Wanner
ALA Annual 2010
Revise existing implementer registry submission forms
and create versions for self-service
Wanner, Campbell,
Jackson
ALA Annual 2010
Draft an invitation to NCIP Social at ALA Annual Wanner, Jackson
Follow up with Kotecha at RapidRadio to get additional
details from presentation
Walsh
Attempt to determine whether NCIP can be considered
RESTful
Wetzel, Stewart May 7, 2010
Implement accepted change requests in schema OʼBrien
Update Standard to reﬂect accepted change requests Walsh June 30, 2010
Respond to those who submitted proposals to let them
know the disposition of their requests
Walsh, Wanner
Review codepad.org to determine whether something
similar might be possible for NCIP
Campbell
Contact VTLS to determine if they wish to remain active
in the NCIP IG
Walsh, Wanner,
Wetzel
Clarify with NISO how information is disseminated
publicly (i.e., Minutes moved to public NISO workroom
for NCIP)
Wanner, Walsh
Conﬁrm dates for September meeting with Ex Libris Dicus
Obtain list of those subscribed to the general interest list
serve
Walsh
Page 47 of 47