September 8-9, 2010 (In Person Meeting)
NCIP Standing Committee
Minutes - In-person Meeting
September 2010
Present
Voting Members
Susan Campbell - College Center for Library Automation
Rob Walsh - EnvisionWare (NCIP Maintenance Agency)
Mike Dicus - Ex Libris
Eric Leckbee - Innovative Interfactes
John Bodfish - OCLC
Tony OʼBrien - OCLC
Robert Gray - Polaris Library Systems
Kevin Stewart - Relais International
Gail Wanner - SirsiDynix (Chair)
DJ Miller - The Library Corporation
Observers
Karen Wetzel - NISO
Collete Mak - Notre Dame University
Minutes prepared and submitted by:
Rob Walsh, EnvisionWare / NCIP Maintenance Agency
Editorʼs Note: As part of this meeting, Wetzel reminded the group that NISOʼs official
name for it is the NCIP Standing Committee. Previously, the group referred to itself as
the NCIP Implementers Group. References in these minutes to the group will be the
NCIP Standing Committee.
Page 1 of 30Table of Contents
Welcome and Introductions 4
Agenda Review 4
Implementer Updates 4
Other Standards News 5
Review Version 2 Changes 5
Review Items previous marked for further study 6
Review Schema Changes Resulting From Items Reviewed at April
2010 Meeting 8
Future Version 2.x Changes 10
Performing Item Lookups Using Bibliographic Id 10
Identifying Deprecated Services 11
Provide Displayable Text for Enumerate Types 12
Break Out Groups to Review Changes Made to Section 5 12
Continuous Maintenance Procedures Changes 13
Overview of NCIP Forum (WebEx - Presented by John Barr, Polaris
Library Systems) 13
NCIP Implementer Registry 14
Next In Person Meeting 15
2011 Call Schedule 15
NCIP as a RESTful Web Service 15
Break-Out Group Work on Documentation 16
Review Action Items 16
Page 2 of 30Adjourn 17
Appendix A - NCIP Implementer Registry Handout 18
Appendix B - Email Draft Describing NCIP as RESTful 28
Appendix C - Action Items 29
Page 3 of 30Wednesday, September 8, 2010
Welcome and Introductions
Wanner called the meeting to order and asked Dicus to provide a logistical overview of
the facilities. Each person in attendance briefly introduced him- or herself.
Agenda Review
Wanner led a review of the agenda and asked if anyone had any changes to suggest.
She reminded the group, too, that some people not present have planned to join the
discussion on some topics by telephone, and we need to mindful of the schedule to
ensure those topics start at the designated times.
Implementer Updates
Wanner asked if anyone had implementer updates to share.
Leckbee reported that Innovative Interfaces is testing in a consortium in Michigan with
Polaris. They are working to convert functionality currently using an implementation
based on Direct Consortial Borrowing (DCB) to NCIP by eliminating some request
messages, primarily with respect to user authentication. Innovative is nearly finished
implementing messages to exchange with Relais International for PALCI, but they
continue to work on the internal implementations behind the message exchanges.
Miller reported that TLC Library.Solution is working in Maryland with SirsiDynix. Two
libraries are in final testing, and no failures have yet been identified. TLC is preparing to
move all libraries that are part of this project to final system testing. Their next project
will be with Melcat. Library.Solution is working also with Auto-Graphics in Louisiana.
TLC CARL is working in Northbay. All work is with NCIP Version 1.
Gray reported that Polaris is working in Maryland with SirsiDynix. They, too, will be
working on Melcat.
OʼBrien reported that OCLC WorldCat Navigator has an NCIP implementation, originally
using Version 1. OCLC is committed to Version 2 and is beginning to develop a toolkit.
Bodfish added that the code being written for Version 2 will be donated to the eXtensible
Catalog (XCO) project and will be available under MIT license. Anyone interested in
using the toolkit should contact XCO and get involved in the project. The toolkit
supports the use of extensions, but none are presently implemented.
Page 4 of 30Other Standards News
Wanner asked if anyone had news from other related standards to share.
Wetzel reported that the Institutional Identifier (I2) working group has published a draft
for feedback. They are working on how to better integrate with ISNI (International
Standard Name Identifier). Their biggest issues are how to manage the data, how to
maintain registries, and how to avoid conflict with existing identifiers (OCLC, ISIL, etc.).
Walsh reported that he recently assumed a co-chair role with the Discovery to Delivery
Topic Committee. This position was held previously by OʼBrien.
Dicus asked if anyone had any updates regarding SIP 3.0. Walsh indicated that little
mention has been made in the community outside of a reference made as part of the
Massachusetts state-wide sorter project. Dicus indicated a comment made in the UK
suggested that NCIP was dying and SIP 3.0 would be the next standard. Bodfish has
heard similar comments. However, no one is aware of any definition or specification for
SIP 3.0, so it is easy for it to be the “next best thing.” The group indicated that it will be
interesting to see how 3M manages to achieve some of the goals theyʼve set for SIP
3.0. OʼBrien suggested that, as a committee, we need to think about what our next
steps will be if SIP 3.0 is introduced and begins to gain traction in the industry. We need
to attempt to maintain contact with 3M to stay abreast of any developments.
Stewart commented that one of the biggest barriers to NCIP continues to be price.
When vendors charge more for NCIP than SIP, customers are reluctant to pursue NCIP.
Wetzel indicated that we should continue to look for Version 2 success stories that can
be highlighted and published to show the community that NCIP is working.
Review Version 2 Changes
Walsh reviewed changes being made in Part 1 and Part 2 of the NCIP Standard. The
group discussed ways to simplify Section 5 in Part 1. Campbell expressed concerns
over the tedious manual efforts associated with keeping the schema and the Standard
in sync. She suggested that there should be some way, via an XSL stylesheet
transformation for example, to automate the generation of Sections 5 (and 6) and
reduce both the amount of work and the likelihood of additional errors. Bodfish said that
there are some rules and semantics described in the Standard that cannot be
adequately represented in the schema. He used the “if requested” model as an
example.
Page 5 of 30Review Items previous marked for further study
Walsh reviewed three items that had been accepted for further study at the April 2010
meeting.
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 (Apr. 2010): User Id can be used both as an identifier and as data. When
used outside of User Optional Fields, it is a key. When used inside, it is simply data.
Decision (Apr. 2010): Accept for further study. Attempt to find concrete use cases
that require Item Id to be used outside of Item Optional Fields.
Decision (Sept. 2010): Reject. The group was unable to identify a compelling use
case to justify this change.
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, specifically in the area of
element repeatability. The Standard allows for tightening of rules via application profiles
(e.g., marking an optional element mandatory), but it does not 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 (Apr. 2010): 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
title 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
Page 6 of 30them where necessary through profiles. 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 significantly 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 (Apr. 2010): Accept for further study. Attempt to find use cases for how it
might be used effectively and provide examples to the submitter showing potential
problems.
Decision (Sept. 2010): Reject. The group was unable to identify a compelling use
case to justify this change.
Number: 2010-01-0021
Type: Enhancement
Submitted By: Brent Jensen ([email protected])
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 (Apr. 2010): 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 (Apr. 2010): Accept for further study. Ask Jensen whether Pickup
Location within Accept Item Response meets his needs or if there are additional use
cases.
Decision (Sept. 2010): Reject. The group was unable to identify a compelling use
case to justify this change. Further, it was noted that Accept Item Response permits the
use of Pickup Location in Version 2.
Page 7 of 30Review Schema Changes Resulting From Items
Reviewed at April 2010 Meeting
OʼBrien showed two specific schema changes that resulted from change requests
accepted at the April 2010 meeting.
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 (Apr. 2010): Jackson clarified 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 field is used only to carry information, never to identify an
item, so allowing it repeat should not cause any problems.
Decision (Apr. 2010): Accept without modification. Change the schema to make
Bibliographic Record Id repeatable within Bibliographic Description. Then update the
Standard document to match the changed schema.
Page 8 of 30Number: 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 Id.
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 (Apr. 2010): 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 specific 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 (Apr. 2010): Accept for further study. Attempt to find 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 modification.”
Bodfish explained that, at least initially and with respect to both changes, the context
should be understood to mean a transaction on a single item identified by any of the ids
supplied in the elements that have now been made repeatable. This distinction should
be captured in the Standard, possibly in the Data Dictionary (Section 6) and/or in
Section 5. As it stands, the response message is able to supply only a single Request
Id (or Item Id in the case of Accept Item).
It was noted that the new version (deemed 2.01) is backwards compatible with the
original Version 2 (2.0) with respect to an initiator at Version 2. However, an initiator at
Version 2.01 cannot communicate with a responder at Version 2.0. This should be
clarified in the version notes in the Standard.
Page 9 of 30Future Version 2.x Changes
Performing Item Lookups Using Bibliographic Id
Bodfish described a scenario where another future change may be necessary. The
eXtensible Catalog (XC) is developing a discovery interface, a replacement for ILSspecific OPACs to augment and extend functionality. The basic process is to extract
bibliographic information from the ILS, index it, and, using Drupal, build a patron
interface. The next step is to add empowerment features for the patrons - the ability to
place holds, check out, etc. NCIP becomes more relevant in this final stage. What
theyʼve extracted from the ILS are bibliographic records, and what they are displaying to
the patrons is bibliographic information. Their are additional data that could be
displayed in the form of metadata about each item. However, NCIP does not permit
lookups by bibliographic id. If that were added, we would have to address the issue of a
response including multiple items rather than only a single entity since a bibliographic id
may not represent a unique holding. XC added a custom message to address this in
their Version 1 implementation. In Version 2, they can use an extension. They have
drafted a proposal to put a bibliographic id in a lookup item request and allow the
response to include a set of items.
Walsh said on the surface it would not seem to introduce too many issues, at least in a
lookup. Bodfish noted, though, that some requests might generate many items and the
size of the response might be unwieldy. OʼBrien showed how the hypothetical change
would not be technically complex in the schema. Gray suggested that it might be best if
it were implemented with a new message because it could be implemented in the most
appropriate way without any preconceived restrictions. Wanner asked if there is a need
to expand the Standard this significantly, or if this is an isolated change where we could
live with fitting it into the existing structure. Bodfish indicated that the big issue is the
repetition of the bibliographic information that would be expected to be the same for
each item in the set.
Another approach might be to make the subelements within NCIPMessage repeatable.
That still may not address the problem of repeating the bibliographic data in each
message. It may work in some contexts to assume that all members of the set share
the same data, but in other contexts, it would be impossible to determine which are
meant to be shared and which simply do not have bibliographic data.
OʼBrien suggested that new messages give us more opportunity to properly express the
intent and the semantics for the exchange.
Walsh asked if the discussion would be different if we considered what happens if we
expand the scope to include transaction oriented messages rather than just lookup
messages. He said he might be willing to support simply changing the current structure
if we limit the scope to only meeting immediate needs. However, if we consider the
impact of potential future needs, we might be better served by adding new messages.
Page 10 of 30OʼBrien expressed concern over adding new messages since we have spent much time
and energy trying to simplify. Wanner, however, indicated that clarity in the resulting
messages should be considered.
Campbell asked why the Ext element is not appropriate to this change. OʼBrien
indicated that it would be, but that we should consider how useful Ext implementations
can be later incorporated into the Standard.
Gray said he thinks looking up an item by bibliographic id is conceptually different than
lookup up an item by item id. A lookup by bibliographic id should carry a bibliographic
payload, not an item payload. Bodfish agreed, noting that a Lookup Item Response that
could be used for either type of request might become very confusing.
Bodfish added that, while this request comes from XC, it is fairly common among those
working with ILS discovery products. He agreed to take the XC proposal and attempt to
produce a schema structure to support it. His approach is likely to center around adding
a new message. He invited others who may prefer making Lookup Item Response
repeatable or overloading Lookup Item Response to handle both single and multiple
items to draft their own proposals.
Identifying Deprecated Services
Wanner said that she would like to undertake a project to review existing services in an
attempt to determine if any are unused and could be deprecated. OʼBrien suggested
that we could do this here by going very quickly through the list to see if any are
consensus targets for elimination. Campbell suggested that she could add a survey
page to the Implementer Registry to allow implementers to provide feedback about each
message: Important, Not Important, etc.
The group quickly reviewed each service and identified the following candidates for
deprecation:
Agency Created
Agency Updated
Circulation Status Change Reported
Circulation Status Updated
Create Agency
Item Created
Item Recall Canceled
Item Recalled
Item Request Updated
Report Circulation Status Change
Send User Notice
Update Agency
Update Circulation Status
Page 11 of 30User Created
User Fiscal Transaction Created
User Notice Sent
User Updated
The group acknowledged that the results of this impromptu survey are non-binding and
simply represent a “gut-feel” about which services may no longer be useful. Wanner
agreed to draft a proposal to deprecate these (or a subset of these) services.
Provide Displayable Text for Enumerate Types
Bodfish described another item of interest for the XC. They would like to be able to
display the ILS-specific wording for enumerated types such as circulation status.
Break Out Groups to Review Changes Made to
Section 5
The group split into small groups to review the changes made to Section 5 of Part 1 to
ensure they agree with the schema. It then reviewed as a large group the various
findings. The group noted a discrepancy in Update Request Item Response where
Required Item User Restriction Type is missing (as compared to Request Item and
Renew Item). It was decided this was an oversight and should be corrected. OʼBrien
made the change to the schema.
The group also reviewed Request Scope Type as being optional in Cancel Request
Item. The thought was that it was required in Update Request Item; however, it appears
that it is not required there. Therefore, no change is necessary.
Some discussion was held around using alphabetical or schema order for the
subelements listed in each message described in Section 5. The group agreed to add a
sentence to 5.2 to explain that the table is in alphabetical order and serves as an index
to the rest of Section 5, but that the data elements listed in each message are in
schema order.
The other minor typographical errors were reported to Walsh, and he agreed to make
the appropriate corrections to the document.
Page 12 of 30Continuous Maintenance Procedures Changes
Wanner asked if anyone felt a need to propose any changes to our Continuous
Maintenance procedures. Walsh reported that the delays that caused us to miss the
initial revision deadline after the April 2010 meeting were largely logistical and due to
insufficient infrastructure. He indicated that he is now comfortable with the timelines
associated with each revision and feels confident that we will be able to publish future
revisions in accordance with the procedures.
Wanner asked if anyone has concerns about the twice-per-year revision schedule.
Various views were presented. On the one hand, it may be burdensome on responders
and customers. On the other, it provides the ability to respond to needs identified in the
community. No one expressed a strong opinion, and the group decided to retain the
ability to release twice-per-year.
Wanner indicated a need to have a designated back up for schema changes. Stewart
volunteered to serve as OʼBrienʼs back up.
Thursday, September 9, 2010
Overview of NCIP Forum (WebEx - Presented by John
Barr, Polaris Library Systems)
Barr provided a demonstration of the NCIP forum (available at http://ncipnow.com). He
explained that the site is very configurable, and we expect to see things change as we
get feedback from the group about what is and would be useful. People may join the
forum, but it is possible to view the content without being a member. Barr showed how
one might start a discussion topic and post messages to the forum, and he
demonstrated other features and functions available within the forum. Currently,
registration is moderated and requires approval of the forum administrators (Barr and
Dhaval Kotecha). However, Barr feels this may be temporary. The group discussed this
topic and views on both sides were presented. Mak said that it should be open to
encourage participation. OʼBrien cautioned that this might be overly trusting. If the
forum gets the attention of some sort of automated bot, it may wreak enough havoc to
force a fairly large clean up effort. However, he indicated that even unmoderated
registration should help, and we might further limit unmoderated participation to a single
forum. Bodfish said that we likely will not have sufficient information at registration to
know whether a user should be banned. More likely, we would discover only later that a
userʼs behavior warrants moderation or deactivation. Therefore, it would be better to
allow people to register and post immediately (without specific activation) rather than
force them to register and wait for activation, possibly losing the incentive to post. Barr
agreed to change the registration policy so that new users do not have to be activated
by an administrator.
Page 13 of 30OʼBrien indicated that it might be beneficial to have some sub-forums accessible to
anyone and others available only to certain users (members of the NCIP Standing
Committee, for example). Barr agreed to create an Implementers Lounge forum that
only members of the NCIP Standing Committee can join. OʼBrien expressed a
preference that the private forum should not even be visible to those who cannot post to
it.
Wanner said that a link to the forum should be added to the NCIP website. Walsh
agreed to add the link. Wetzel asked if the forum has links to the NCIP and the NISO
websites. Barr indicated that those links are available in the “About this forum” forum.
OʼBrien added that useful posts (like the one with the links) can be “pinned” and locked
so that they cannot be changed and they remain at the top of the forum in which they
exist.
NCIP Implementer Registry
Campbell demonstrated the NCIP Implementer Registry she has been building in
Drupal (http://ncip.dev3.webenabled.net). (See Appendix A for a copy of the handout
she provided.) She showed how a user can search the site to determine what vendors
support which NCIP messages and data elements. Most of the data in the site is
fictitious at the moment (using names from mythology to make them easy to identify and
remove later). She explained, too, how a user can download the data from the siteʼs
database as an Excel spreadsheet. NCIP Implementers are able to create an account
that will permit them to provide information about the use of NCIP in their products. An
account manager (TBD but likely to be Wanner as the Chair or Walsh as the
Maintenance Agency) will be responsible for approving and activating the account once
the various information in the request is verified.
The group was overwhelmed with the work Campbell has done. Campbell
acknowledged the assistance she received from Jackson and Wanner.
Wetzel asked for a timeline for moving the site from BETA to live. Walsh indicated that
there are some technical issues that need to be resolved in order to migrate from the
current hosting provider to the Maintenance Agencyʼs Drupal site. However, the
responsibility for administering the site could be transferred earlier if the site can remain
hosted with the current provider for now. The group agreed to aim for the end of
October for bringing the site “on-line.” Group members agreed to send their company
and product information to Campbell directly, and she will enter the information into the
site.
Page 14 of 30Next In Person Meeting
The group reviewed various dates in April 2010. Easter and Passover are the week of
April 19-25. Computers in Libraries is March 21-23. The week of April 18 (with a
meeting to be held April 20-21) seemed to be open for everyone. The group agreed
tentatively to schedule a meeting for April 20-21 with a full day scheduled for
Wednesday and a short day on Thursday (ending around 3 pm). NISO offered to host
in Baltimore, and Relais International offered to host in Ottawa. Wanner agreed to add
an agenda item for the next call to discuss again and make a decision.
2011 Call Schedule
Wanner asked if the group wants to retain the current call schedule. Presently, a
monthly call is held the third Thursday of each month at 1 pm Eastern. No one
expressed any objections. The group agreed that there is no need to hold the
scheduled call on September 16. Wanner agreed to send a note to the list announcing
that the call is cancelled. The next call will be October 21, 2010.
NCIP as a RESTful Web Service
Wanner asked the group to review Stewartʼs draft of a statement on whether NCIP is
RESTful. (See Appendix B for a copy of the email sent by Stewart on May 10, 2010.)
Bodfish expressed a concern over bullet point #4 (“Resources are accessed with a
generic interface (e.g. HTTP, POST, GET”) and explained that NCIP uses POST.
However, “good form” for HTTP and REST suggests that a message should be sent via
an HTTP GET unless it performs some sort of update. For example, the Lookup
Services should use GET since they do not cause any updates in the responding
systems.
Bodfish asked why this group feels the need to claim that NCIP is RESTful. Stewart
indicated that the motivation is to make NCIP more accessible to some implementers,
specifically the ILS-DI group. Bodfish added that some in the ILS-DI might challenge
the claim that NCIP is RESTful, even with the provided justification, on the basis of a
strict definition of REST.
Wanner asked if we continue to see value in having a statement like this. If so, she
asked whether it should it be revised to minimize objections to it. Wanner suggested
that we might post this topic to the forum to generate some discussion. Gray asked if
the XC was relying on NCIP as a RESTful web service to obtain a grant. Bodfish
explained that others in the ILS-DI, not just the XC, were interested in a RESTful web
service (which would not be NCIP). However, in subsequent discussions, the group
agreed to use some of the NCIP work from the XC for its purposes, and the
“requirement” that the web service be RESTful became less significant. Therefore, it
would seem that there is no longer a need to convince the ILS-DI that NCIP is RESTful.
Page 15 of 30Walsh asked what those in the ILS-DI who preferred REST were after in terms of
benefits. Bodfish explained that the motivation was two-fold. First, many in the group
are familiar with RESTful web services. Second, some wanted a simpler query syntax
that did not involve parsing large XML data streams. Walsh added that the interest,
then, was more in simplification than in REST itself. An NCIP that allowed for the XML
payload to exist in a URI would be RESTful since it could be passed via HTTP GET, but
it would not necessarily accomplish the objectives. Also, NCIP could be easily
implemented as a RESTful web service where the service name and various data
elements were expressed as URI attribute/value pairs. This would accomplish the
groupʼs goals, but it would bifurcate the universe of implementations into those that use
the traditional XML and those that use a simpler URI format.
Bodfish and OʼBrien suggested that a statement similar to: “Like RESTful web services,
NCIP shares the following characteristics” and list those from Stewartʼs email except #4.
OʼBrien further suggested that it could be voiced more aggressively by indicating that,
while NCIP uses POST rather than GET, the Standard makes no presumption about
whether the responding application generates side-effects (like logging or statistics
gathering). Bodfish disagreed stating that REST implies that various objects need to be
accessible via GET, and that the issue is not limited to whether side-effects are
generated.
Bodfish volunteered to revise the statement to make it more appropriate, and Stewart
and OʼBrien agreed to review Bodfishʼs draft. He plans to have something for the group
to review by the October 21 conference call. He further agreed to involve people from
the ILS-DI and/or the XC in order to ensure we meet their needs. Gray asked if their is
still a need to make this statement. Various members of the group indicated that they
see value in making the statement even if the ILS-DI and the XC are no longer
concerned.
Break-Out Group Work on Documentation
The groups broke into two small working groups and reviewed draft documents on
NCIP Core Messages and the RFP Writerʼs Guide. Both groups had many comments,
so Wanner decided that each should send the comments to her to incorporate into the
documents.
Review Action Items
The group reviewed the action items from the meeting. (See Appendix C.)
Page 16 of 30Adjourn
Wanner thanked Dicus and Ex Libris for hosting, thanked the group for attending, and
adjourned the meeting.
Page 17 of 30Appendix A - NCIP Implementer Registry Handout
Page 18 of 30Page 19 of 30Page 20 of 30Page 21 of 30Page 22 of 30Page 23 of 30Page 24 of 30Page 25 of 30Page 26 of 30Page 27 of 30Appendix B - Email Draft Describing NCIP as RESTful
From: "Kevin Stewart" <[email protected]>
Subject: [NISO z3983maint] NCIP and RESTful web services
Date: May 10, 2010 11:34:49 AM EDT
To: <[email protected]>
1 Attachment, 3.2 KB
It was great to see everyone in Syracuse last week. During the meeting I was tasked with researching the requirements for RESTful web services
and if NCIP meets the requirements.
First of all the basic structure of NCIP consists of sending an xml message via http or https and receiving an xml response which makes
NCIP a web service. In order to call NCIP a RESTful web service we need to look at the basic requirements.
1. REST is an architectural style, not a standard.
2. A RESTful web service must be completely stateless.
3. Should be based on a Client-Server architecture with a pull-based interaction style.
4. Resources are accessed with a generic interface (e.g. HTTP, POST, GET)
5. The service producers and consumers must agree on a schema that describes the data being exchanged.
6. There should be documentation describing how to process the data meaningfully.
The original definition of RESTful web services was based on the idea of a simple URL where something like
www.niso.org/RESTful/patrons could be used to ask for an xml response listing all patrons. This being said the concept of web services
has evolved over the past decade and I believe NCIP meets the basic requirements for RESTful web service status. I would like to
suggest an agenda item for the next meeting to discuss the possibility of adding text to the NCIP standard indicating that NCIP
messages are exchanged using RESTful web services.
I would appreciate comments from those more familiar with RESTful web services.
Kevin
Kevin G Stewart
Chief Technology Officer
[email protected]
Phone: 613-226-5571 x241 Toll Free (NA): 888-294-5244 x241
Skype: relais.kevin
http://www.relais-intl.com
Page 28 of 30Appendix C - Action Items
What Who When
Draft proposal to add a message similar
to Lookup Item that accepts and returns
information relating to more than one
item, probably keyed on Bibliographic Id
Bodfish Before spring deadline for
change requests
Remove activation requirement on new
user registrations to the NCIP forum
Barr
Add an Implementers Only sub-forum to
the NCIP forum and make it visible only to
those who are allowed to access it
Barr,
OʼBrien
Add a link from the NCIP website to the
NCIP forum
Walsh Done
Add a link from the NISO website to the
NCIP forum
Wetzel
Transition the NCIP Implementers
Registry from BETA to live
Campbell,
Walsh
End of October
Send company and product information
about implementations to Campbell
Group End of September
Add discussion item to agenda for
October conference call to decide on site
for spring meeting
Wanner October 21, 2010
Post to the NCIP general interest list that
September 16 conference call is canceled
Wanner Done (after the
meeting but
before Minutes
were published)
Revise the statement showing how NCIP
is similar to REST
Bodfish,
Stewart,
OʼBrien
October 21, 2010
Draft proposal to mark certain NCIP
services as deprecated based on the
results of our internal straw poll
Wanner
Page 29 of 30What Who When
Published the 2.01 schema to the NCIP
Standing Committee
OʼBrien Done
Send working group comments on NCIP
Core Messages draft documents to
Wanner
Walsh
Send working group comments on RFP
Guide draft document to Wanner
Leckbee Done (after the meeting
but before Minutes were
published)
Incorporate working group feedback into
NCIP Core Messages and RFP Guide
drafts
Wanner October 21, 2010
Page 30 of 30
Minutes - In-person Meeting
September 2010
Present
Voting Members
Susan Campbell - College Center for Library Automation
Rob Walsh - EnvisionWare (NCIP Maintenance Agency)
Mike Dicus - Ex Libris
Eric Leckbee - Innovative Interfactes
John Bodfish - OCLC
Tony OʼBrien - OCLC
Robert Gray - Polaris Library Systems
Kevin Stewart - Relais International
Gail Wanner - SirsiDynix (Chair)
DJ Miller - The Library Corporation
Observers
Karen Wetzel - NISO
Collete Mak - Notre Dame University
Minutes prepared and submitted by:
Rob Walsh, EnvisionWare / NCIP Maintenance Agency
Editorʼs Note: As part of this meeting, Wetzel reminded the group that NISOʼs official
name for it is the NCIP Standing Committee. Previously, the group referred to itself as
the NCIP Implementers Group. References in these minutes to the group will be the
NCIP Standing Committee.
Page 1 of 30Table of Contents
Welcome and Introductions 4
Agenda Review 4
Implementer Updates 4
Other Standards News 5
Review Version 2 Changes 5
Review Items previous marked for further study 6
Review Schema Changes Resulting From Items Reviewed at April
2010 Meeting 8
Future Version 2.x Changes 10
Performing Item Lookups Using Bibliographic Id 10
Identifying Deprecated Services 11
Provide Displayable Text for Enumerate Types 12
Break Out Groups to Review Changes Made to Section 5 12
Continuous Maintenance Procedures Changes 13
Overview of NCIP Forum (WebEx - Presented by John Barr, Polaris
Library Systems) 13
NCIP Implementer Registry 14
Next In Person Meeting 15
2011 Call Schedule 15
NCIP as a RESTful Web Service 15
Break-Out Group Work on Documentation 16
Review Action Items 16
Page 2 of 30Adjourn 17
Appendix A - NCIP Implementer Registry Handout 18
Appendix B - Email Draft Describing NCIP as RESTful 28
Appendix C - Action Items 29
Page 3 of 30Wednesday, September 8, 2010
Welcome and Introductions
Wanner called the meeting to order and asked Dicus to provide a logistical overview of
the facilities. Each person in attendance briefly introduced him- or herself.
Agenda Review
Wanner led a review of the agenda and asked if anyone had any changes to suggest.
She reminded the group, too, that some people not present have planned to join the
discussion on some topics by telephone, and we need to mindful of the schedule to
ensure those topics start at the designated times.
Implementer Updates
Wanner asked if anyone had implementer updates to share.
Leckbee reported that Innovative Interfaces is testing in a consortium in Michigan with
Polaris. They are working to convert functionality currently using an implementation
based on Direct Consortial Borrowing (DCB) to NCIP by eliminating some request
messages, primarily with respect to user authentication. Innovative is nearly finished
implementing messages to exchange with Relais International for PALCI, but they
continue to work on the internal implementations behind the message exchanges.
Miller reported that TLC Library.Solution is working in Maryland with SirsiDynix. Two
libraries are in final testing, and no failures have yet been identified. TLC is preparing to
move all libraries that are part of this project to final system testing. Their next project
will be with Melcat. Library.Solution is working also with Auto-Graphics in Louisiana.
TLC CARL is working in Northbay. All work is with NCIP Version 1.
Gray reported that Polaris is working in Maryland with SirsiDynix. They, too, will be
working on Melcat.
OʼBrien reported that OCLC WorldCat Navigator has an NCIP implementation, originally
using Version 1. OCLC is committed to Version 2 and is beginning to develop a toolkit.
Bodfish added that the code being written for Version 2 will be donated to the eXtensible
Catalog (XCO) project and will be available under MIT license. Anyone interested in
using the toolkit should contact XCO and get involved in the project. The toolkit
supports the use of extensions, but none are presently implemented.
Page 4 of 30Other Standards News
Wanner asked if anyone had news from other related standards to share.
Wetzel reported that the Institutional Identifier (I2) working group has published a draft
for feedback. They are working on how to better integrate with ISNI (International
Standard Name Identifier). Their biggest issues are how to manage the data, how to
maintain registries, and how to avoid conflict with existing identifiers (OCLC, ISIL, etc.).
Walsh reported that he recently assumed a co-chair role with the Discovery to Delivery
Topic Committee. This position was held previously by OʼBrien.
Dicus asked if anyone had any updates regarding SIP 3.0. Walsh indicated that little
mention has been made in the community outside of a reference made as part of the
Massachusetts state-wide sorter project. Dicus indicated a comment made in the UK
suggested that NCIP was dying and SIP 3.0 would be the next standard. Bodfish has
heard similar comments. However, no one is aware of any definition or specification for
SIP 3.0, so it is easy for it to be the “next best thing.” The group indicated that it will be
interesting to see how 3M manages to achieve some of the goals theyʼve set for SIP
3.0. OʼBrien suggested that, as a committee, we need to think about what our next
steps will be if SIP 3.0 is introduced and begins to gain traction in the industry. We need
to attempt to maintain contact with 3M to stay abreast of any developments.
Stewart commented that one of the biggest barriers to NCIP continues to be price.
When vendors charge more for NCIP than SIP, customers are reluctant to pursue NCIP.
Wetzel indicated that we should continue to look for Version 2 success stories that can
be highlighted and published to show the community that NCIP is working.
Review Version 2 Changes
Walsh reviewed changes being made in Part 1 and Part 2 of the NCIP Standard. The
group discussed ways to simplify Section 5 in Part 1. Campbell expressed concerns
over the tedious manual efforts associated with keeping the schema and the Standard
in sync. She suggested that there should be some way, via an XSL stylesheet
transformation for example, to automate the generation of Sections 5 (and 6) and
reduce both the amount of work and the likelihood of additional errors. Bodfish said that
there are some rules and semantics described in the Standard that cannot be
adequately represented in the schema. He used the “if requested” model as an
example.
Page 5 of 30Review Items previous marked for further study
Walsh reviewed three items that had been accepted for further study at the April 2010
meeting.
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 (Apr. 2010): User Id can be used both as an identifier and as data. When
used outside of User Optional Fields, it is a key. When used inside, it is simply data.
Decision (Apr. 2010): Accept for further study. Attempt to find concrete use cases
that require Item Id to be used outside of Item Optional Fields.
Decision (Sept. 2010): Reject. The group was unable to identify a compelling use
case to justify this change.
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, specifically in the area of
element repeatability. The Standard allows for tightening of rules via application profiles
(e.g., marking an optional element mandatory), but it does not 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 (Apr. 2010): 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
title 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
Page 6 of 30them where necessary through profiles. 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 significantly 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 (Apr. 2010): Accept for further study. Attempt to find use cases for how it
might be used effectively and provide examples to the submitter showing potential
problems.
Decision (Sept. 2010): Reject. The group was unable to identify a compelling use
case to justify this change.
Number: 2010-01-0021
Type: Enhancement
Submitted By: Brent Jensen ([email protected])
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 (Apr. 2010): 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 (Apr. 2010): Accept for further study. Ask Jensen whether Pickup
Location within Accept Item Response meets his needs or if there are additional use
cases.
Decision (Sept. 2010): Reject. The group was unable to identify a compelling use
case to justify this change. Further, it was noted that Accept Item Response permits the
use of Pickup Location in Version 2.
Page 7 of 30Review Schema Changes Resulting From Items
Reviewed at April 2010 Meeting
OʼBrien showed two specific schema changes that resulted from change requests
accepted at the April 2010 meeting.
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 (Apr. 2010): Jackson clarified 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 field is used only to carry information, never to identify an
item, so allowing it repeat should not cause any problems.
Decision (Apr. 2010): Accept without modification. Change the schema to make
Bibliographic Record Id repeatable within Bibliographic Description. Then update the
Standard document to match the changed schema.
Page 8 of 30Number: 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 Id.
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 (Apr. 2010): 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 specific 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 (Apr. 2010): Accept for further study. Attempt to find 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 modification.”
Bodfish explained that, at least initially and with respect to both changes, the context
should be understood to mean a transaction on a single item identified by any of the ids
supplied in the elements that have now been made repeatable. This distinction should
be captured in the Standard, possibly in the Data Dictionary (Section 6) and/or in
Section 5. As it stands, the response message is able to supply only a single Request
Id (or Item Id in the case of Accept Item).
It was noted that the new version (deemed 2.01) is backwards compatible with the
original Version 2 (2.0) with respect to an initiator at Version 2. However, an initiator at
Version 2.01 cannot communicate with a responder at Version 2.0. This should be
clarified in the version notes in the Standard.
Page 9 of 30Future Version 2.x Changes
Performing Item Lookups Using Bibliographic Id
Bodfish described a scenario where another future change may be necessary. The
eXtensible Catalog (XC) is developing a discovery interface, a replacement for ILSspecific OPACs to augment and extend functionality. The basic process is to extract
bibliographic information from the ILS, index it, and, using Drupal, build a patron
interface. The next step is to add empowerment features for the patrons - the ability to
place holds, check out, etc. NCIP becomes more relevant in this final stage. What
theyʼve extracted from the ILS are bibliographic records, and what they are displaying to
the patrons is bibliographic information. Their are additional data that could be
displayed in the form of metadata about each item. However, NCIP does not permit
lookups by bibliographic id. If that were added, we would have to address the issue of a
response including multiple items rather than only a single entity since a bibliographic id
may not represent a unique holding. XC added a custom message to address this in
their Version 1 implementation. In Version 2, they can use an extension. They have
drafted a proposal to put a bibliographic id in a lookup item request and allow the
response to include a set of items.
Walsh said on the surface it would not seem to introduce too many issues, at least in a
lookup. Bodfish noted, though, that some requests might generate many items and the
size of the response might be unwieldy. OʼBrien showed how the hypothetical change
would not be technically complex in the schema. Gray suggested that it might be best if
it were implemented with a new message because it could be implemented in the most
appropriate way without any preconceived restrictions. Wanner asked if there is a need
to expand the Standard this significantly, or if this is an isolated change where we could
live with fitting it into the existing structure. Bodfish indicated that the big issue is the
repetition of the bibliographic information that would be expected to be the same for
each item in the set.
Another approach might be to make the subelements within NCIPMessage repeatable.
That still may not address the problem of repeating the bibliographic data in each
message. It may work in some contexts to assume that all members of the set share
the same data, but in other contexts, it would be impossible to determine which are
meant to be shared and which simply do not have bibliographic data.
OʼBrien suggested that new messages give us more opportunity to properly express the
intent and the semantics for the exchange.
Walsh asked if the discussion would be different if we considered what happens if we
expand the scope to include transaction oriented messages rather than just lookup
messages. He said he might be willing to support simply changing the current structure
if we limit the scope to only meeting immediate needs. However, if we consider the
impact of potential future needs, we might be better served by adding new messages.
Page 10 of 30OʼBrien expressed concern over adding new messages since we have spent much time
and energy trying to simplify. Wanner, however, indicated that clarity in the resulting
messages should be considered.
Campbell asked why the Ext element is not appropriate to this change. OʼBrien
indicated that it would be, but that we should consider how useful Ext implementations
can be later incorporated into the Standard.
Gray said he thinks looking up an item by bibliographic id is conceptually different than
lookup up an item by item id. A lookup by bibliographic id should carry a bibliographic
payload, not an item payload. Bodfish agreed, noting that a Lookup Item Response that
could be used for either type of request might become very confusing.
Bodfish added that, while this request comes from XC, it is fairly common among those
working with ILS discovery products. He agreed to take the XC proposal and attempt to
produce a schema structure to support it. His approach is likely to center around adding
a new message. He invited others who may prefer making Lookup Item Response
repeatable or overloading Lookup Item Response to handle both single and multiple
items to draft their own proposals.
Identifying Deprecated Services
Wanner said that she would like to undertake a project to review existing services in an
attempt to determine if any are unused and could be deprecated. OʼBrien suggested
that we could do this here by going very quickly through the list to see if any are
consensus targets for elimination. Campbell suggested that she could add a survey
page to the Implementer Registry to allow implementers to provide feedback about each
message: Important, Not Important, etc.
The group quickly reviewed each service and identified the following candidates for
deprecation:
Agency Created
Agency Updated
Circulation Status Change Reported
Circulation Status Updated
Create Agency
Item Created
Item Recall Canceled
Item Recalled
Item Request Updated
Report Circulation Status Change
Send User Notice
Update Agency
Update Circulation Status
Page 11 of 30User Created
User Fiscal Transaction Created
User Notice Sent
User Updated
The group acknowledged that the results of this impromptu survey are non-binding and
simply represent a “gut-feel” about which services may no longer be useful. Wanner
agreed to draft a proposal to deprecate these (or a subset of these) services.
Provide Displayable Text for Enumerate Types
Bodfish described another item of interest for the XC. They would like to be able to
display the ILS-specific wording for enumerated types such as circulation status.
Break Out Groups to Review Changes Made to
Section 5
The group split into small groups to review the changes made to Section 5 of Part 1 to
ensure they agree with the schema. It then reviewed as a large group the various
findings. The group noted a discrepancy in Update Request Item Response where
Required Item User Restriction Type is missing (as compared to Request Item and
Renew Item). It was decided this was an oversight and should be corrected. OʼBrien
made the change to the schema.
The group also reviewed Request Scope Type as being optional in Cancel Request
Item. The thought was that it was required in Update Request Item; however, it appears
that it is not required there. Therefore, no change is necessary.
Some discussion was held around using alphabetical or schema order for the
subelements listed in each message described in Section 5. The group agreed to add a
sentence to 5.2 to explain that the table is in alphabetical order and serves as an index
to the rest of Section 5, but that the data elements listed in each message are in
schema order.
The other minor typographical errors were reported to Walsh, and he agreed to make
the appropriate corrections to the document.
Page 12 of 30Continuous Maintenance Procedures Changes
Wanner asked if anyone felt a need to propose any changes to our Continuous
Maintenance procedures. Walsh reported that the delays that caused us to miss the
initial revision deadline after the April 2010 meeting were largely logistical and due to
insufficient infrastructure. He indicated that he is now comfortable with the timelines
associated with each revision and feels confident that we will be able to publish future
revisions in accordance with the procedures.
Wanner asked if anyone has concerns about the twice-per-year revision schedule.
Various views were presented. On the one hand, it may be burdensome on responders
and customers. On the other, it provides the ability to respond to needs identified in the
community. No one expressed a strong opinion, and the group decided to retain the
ability to release twice-per-year.
Wanner indicated a need to have a designated back up for schema changes. Stewart
volunteered to serve as OʼBrienʼs back up.
Thursday, September 9, 2010
Overview of NCIP Forum (WebEx - Presented by John
Barr, Polaris Library Systems)
Barr provided a demonstration of the NCIP forum (available at http://ncipnow.com). He
explained that the site is very configurable, and we expect to see things change as we
get feedback from the group about what is and would be useful. People may join the
forum, but it is possible to view the content without being a member. Barr showed how
one might start a discussion topic and post messages to the forum, and he
demonstrated other features and functions available within the forum. Currently,
registration is moderated and requires approval of the forum administrators (Barr and
Dhaval Kotecha). However, Barr feels this may be temporary. The group discussed this
topic and views on both sides were presented. Mak said that it should be open to
encourage participation. OʼBrien cautioned that this might be overly trusting. If the
forum gets the attention of some sort of automated bot, it may wreak enough havoc to
force a fairly large clean up effort. However, he indicated that even unmoderated
registration should help, and we might further limit unmoderated participation to a single
forum. Bodfish said that we likely will not have sufficient information at registration to
know whether a user should be banned. More likely, we would discover only later that a
userʼs behavior warrants moderation or deactivation. Therefore, it would be better to
allow people to register and post immediately (without specific activation) rather than
force them to register and wait for activation, possibly losing the incentive to post. Barr
agreed to change the registration policy so that new users do not have to be activated
by an administrator.
Page 13 of 30OʼBrien indicated that it might be beneficial to have some sub-forums accessible to
anyone and others available only to certain users (members of the NCIP Standing
Committee, for example). Barr agreed to create an Implementers Lounge forum that
only members of the NCIP Standing Committee can join. OʼBrien expressed a
preference that the private forum should not even be visible to those who cannot post to
it.
Wanner said that a link to the forum should be added to the NCIP website. Walsh
agreed to add the link. Wetzel asked if the forum has links to the NCIP and the NISO
websites. Barr indicated that those links are available in the “About this forum” forum.
OʼBrien added that useful posts (like the one with the links) can be “pinned” and locked
so that they cannot be changed and they remain at the top of the forum in which they
exist.
NCIP Implementer Registry
Campbell demonstrated the NCIP Implementer Registry she has been building in
Drupal (http://ncip.dev3.webenabled.net). (See Appendix A for a copy of the handout
she provided.) She showed how a user can search the site to determine what vendors
support which NCIP messages and data elements. Most of the data in the site is
fictitious at the moment (using names from mythology to make them easy to identify and
remove later). She explained, too, how a user can download the data from the siteʼs
database as an Excel spreadsheet. NCIP Implementers are able to create an account
that will permit them to provide information about the use of NCIP in their products. An
account manager (TBD but likely to be Wanner as the Chair or Walsh as the
Maintenance Agency) will be responsible for approving and activating the account once
the various information in the request is verified.
The group was overwhelmed with the work Campbell has done. Campbell
acknowledged the assistance she received from Jackson and Wanner.
Wetzel asked for a timeline for moving the site from BETA to live. Walsh indicated that
there are some technical issues that need to be resolved in order to migrate from the
current hosting provider to the Maintenance Agencyʼs Drupal site. However, the
responsibility for administering the site could be transferred earlier if the site can remain
hosted with the current provider for now. The group agreed to aim for the end of
October for bringing the site “on-line.” Group members agreed to send their company
and product information to Campbell directly, and she will enter the information into the
site.
Page 14 of 30Next In Person Meeting
The group reviewed various dates in April 2010. Easter and Passover are the week of
April 19-25. Computers in Libraries is March 21-23. The week of April 18 (with a
meeting to be held April 20-21) seemed to be open for everyone. The group agreed
tentatively to schedule a meeting for April 20-21 with a full day scheduled for
Wednesday and a short day on Thursday (ending around 3 pm). NISO offered to host
in Baltimore, and Relais International offered to host in Ottawa. Wanner agreed to add
an agenda item for the next call to discuss again and make a decision.
2011 Call Schedule
Wanner asked if the group wants to retain the current call schedule. Presently, a
monthly call is held the third Thursday of each month at 1 pm Eastern. No one
expressed any objections. The group agreed that there is no need to hold the
scheduled call on September 16. Wanner agreed to send a note to the list announcing
that the call is cancelled. The next call will be October 21, 2010.
NCIP as a RESTful Web Service
Wanner asked the group to review Stewartʼs draft of a statement on whether NCIP is
RESTful. (See Appendix B for a copy of the email sent by Stewart on May 10, 2010.)
Bodfish expressed a concern over bullet point #4 (“Resources are accessed with a
generic interface (e.g. HTTP, POST, GET”) and explained that NCIP uses POST.
However, “good form” for HTTP and REST suggests that a message should be sent via
an HTTP GET unless it performs some sort of update. For example, the Lookup
Services should use GET since they do not cause any updates in the responding
systems.
Bodfish asked why this group feels the need to claim that NCIP is RESTful. Stewart
indicated that the motivation is to make NCIP more accessible to some implementers,
specifically the ILS-DI group. Bodfish added that some in the ILS-DI might challenge
the claim that NCIP is RESTful, even with the provided justification, on the basis of a
strict definition of REST.
Wanner asked if we continue to see value in having a statement like this. If so, she
asked whether it should it be revised to minimize objections to it. Wanner suggested
that we might post this topic to the forum to generate some discussion. Gray asked if
the XC was relying on NCIP as a RESTful web service to obtain a grant. Bodfish
explained that others in the ILS-DI, not just the XC, were interested in a RESTful web
service (which would not be NCIP). However, in subsequent discussions, the group
agreed to use some of the NCIP work from the XC for its purposes, and the
“requirement” that the web service be RESTful became less significant. Therefore, it
would seem that there is no longer a need to convince the ILS-DI that NCIP is RESTful.
Page 15 of 30Walsh asked what those in the ILS-DI who preferred REST were after in terms of
benefits. Bodfish explained that the motivation was two-fold. First, many in the group
are familiar with RESTful web services. Second, some wanted a simpler query syntax
that did not involve parsing large XML data streams. Walsh added that the interest,
then, was more in simplification than in REST itself. An NCIP that allowed for the XML
payload to exist in a URI would be RESTful since it could be passed via HTTP GET, but
it would not necessarily accomplish the objectives. Also, NCIP could be easily
implemented as a RESTful web service where the service name and various data
elements were expressed as URI attribute/value pairs. This would accomplish the
groupʼs goals, but it would bifurcate the universe of implementations into those that use
the traditional XML and those that use a simpler URI format.
Bodfish and OʼBrien suggested that a statement similar to: “Like RESTful web services,
NCIP shares the following characteristics” and list those from Stewartʼs email except #4.
OʼBrien further suggested that it could be voiced more aggressively by indicating that,
while NCIP uses POST rather than GET, the Standard makes no presumption about
whether the responding application generates side-effects (like logging or statistics
gathering). Bodfish disagreed stating that REST implies that various objects need to be
accessible via GET, and that the issue is not limited to whether side-effects are
generated.
Bodfish volunteered to revise the statement to make it more appropriate, and Stewart
and OʼBrien agreed to review Bodfishʼs draft. He plans to have something for the group
to review by the October 21 conference call. He further agreed to involve people from
the ILS-DI and/or the XC in order to ensure we meet their needs. Gray asked if their is
still a need to make this statement. Various members of the group indicated that they
see value in making the statement even if the ILS-DI and the XC are no longer
concerned.
Break-Out Group Work on Documentation
The groups broke into two small working groups and reviewed draft documents on
NCIP Core Messages and the RFP Writerʼs Guide. Both groups had many comments,
so Wanner decided that each should send the comments to her to incorporate into the
documents.
Review Action Items
The group reviewed the action items from the meeting. (See Appendix C.)
Page 16 of 30Adjourn
Wanner thanked Dicus and Ex Libris for hosting, thanked the group for attending, and
adjourned the meeting.
Page 17 of 30Appendix A - NCIP Implementer Registry Handout
Page 18 of 30Page 19 of 30Page 20 of 30Page 21 of 30Page 22 of 30Page 23 of 30Page 24 of 30Page 25 of 30Page 26 of 30Page 27 of 30Appendix B - Email Draft Describing NCIP as RESTful
From: "Kevin Stewart" <[email protected]>
Subject: [NISO z3983maint] NCIP and RESTful web services
Date: May 10, 2010 11:34:49 AM EDT
To: <[email protected]>
1 Attachment, 3.2 KB
It was great to see everyone in Syracuse last week. During the meeting I was tasked with researching the requirements for RESTful web services
and if NCIP meets the requirements.
First of all the basic structure of NCIP consists of sending an xml message via http or https and receiving an xml response which makes
NCIP a web service. In order to call NCIP a RESTful web service we need to look at the basic requirements.
1. REST is an architectural style, not a standard.
2. A RESTful web service must be completely stateless.
3. Should be based on a Client-Server architecture with a pull-based interaction style.
4. Resources are accessed with a generic interface (e.g. HTTP, POST, GET)
5. The service producers and consumers must agree on a schema that describes the data being exchanged.
6. There should be documentation describing how to process the data meaningfully.
The original definition of RESTful web services was based on the idea of a simple URL where something like
www.niso.org/RESTful/patrons could be used to ask for an xml response listing all patrons. This being said the concept of web services
has evolved over the past decade and I believe NCIP meets the basic requirements for RESTful web service status. I would like to
suggest an agenda item for the next meeting to discuss the possibility of adding text to the NCIP standard indicating that NCIP
messages are exchanged using RESTful web services.
I would appreciate comments from those more familiar with RESTful web services.
Kevin
Kevin G Stewart
Chief Technology Officer
[email protected]
Phone: 613-226-5571 x241 Toll Free (NA): 888-294-5244 x241
Skype: relais.kevin
http://www.relais-intl.com
Page 28 of 30Appendix C - Action Items
What Who When
Draft proposal to add a message similar
to Lookup Item that accepts and returns
information relating to more than one
item, probably keyed on Bibliographic Id
Bodfish Before spring deadline for
change requests
Remove activation requirement on new
user registrations to the NCIP forum
Barr
Add an Implementers Only sub-forum to
the NCIP forum and make it visible only to
those who are allowed to access it
Barr,
OʼBrien
Add a link from the NCIP website to the
NCIP forum
Walsh Done
Add a link from the NISO website to the
NCIP forum
Wetzel
Transition the NCIP Implementers
Registry from BETA to live
Campbell,
Walsh
End of October
Send company and product information
about implementations to Campbell
Group End of September
Add discussion item to agenda for
October conference call to decide on site
for spring meeting
Wanner October 21, 2010
Post to the NCIP general interest list that
September 16 conference call is canceled
Wanner Done (after the
meeting but
before Minutes
were published)
Revise the statement showing how NCIP
is similar to REST
Bodfish,
Stewart,
OʼBrien
October 21, 2010
Draft proposal to mark certain NCIP
services as deprecated based on the
results of our internal straw poll
Wanner
Page 29 of 30What Who When
Published the 2.01 schema to the NCIP
Standing Committee
OʼBrien Done
Send working group comments on NCIP
Core Messages draft documents to
Wanner
Walsh
Send working group comments on RFP
Guide draft document to Wanner
Leckbee Done (after the meeting
but before Minutes were
published)
Incorporate working group feedback into
NCIP Core Messages and RFP Guide
drafts
Wanner October 21, 2010
Page 30 of 30
