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