NCIP (NISO Circulation Interchange Protocol)

1. NCIP (NISO Circulation Interchange Protocol) Mark Needleman Sirsi Corporation Steve Gregory Colorado State Library Access 2004

2. Agenda • NCIP Tutorial • Update on NCIP Maintenance Agency and Implementers Group • Questions/Discussion

3. Committee Charge • Define transactions • needed for circulation systems • among independent “library” systems • Facilitate • direct patron borrowing • remote patron authentication • circulation/ILL interaction • online payment • controlled access to electronic resources

4. Committee Makeup • Representation • ILS Vendors • ILL Vendors • Libraries • Around 20 members with some additional observers • Skills • Computing/Technical • Library Service Orientation

5. Scope of Standard • A repertoire of messages & associated rules of syntax and semantics • Between and among computer based applications • Does not define circulation functions or policies • Does not define user interface • NCIP is not a Search and Retrieval Protocol !!

6. Applications Supported • Direct consortial borrowing • Circulation/InterLibrary Loan Interaction • Self-service Circulation • Access to Electronic Resources • The standard’s test bed • it had to support those, may be able to support others

7. Design Goals • Keep it simple and within purpose • Promote wide adoption • Promote rapid adoption • Build in flexibility • Goal of adoption by existing library vendors and perhaps non traditional vendors

8. Technical Architecture • 3 Service Types • 3 Object Classes

9. Service Types • Lookup • “Tell me these things about this object.” • Update • “Please take this action.” • Notification • “I have taken this action.” • Service Types are comprised of Services.

10. Object Classes • Users • Items • Agencies (Libraries) • Transactions are associations between one or more of the objects

11. Service Definitions • Every “Service” is a pair of messages: • an “Initiation Message” • and a “Response Message” • Each message provides complete context for it to be understood • The protocol is designed NOT to require any particular sequence of services.

12. Lookup Service • Lookup Agency • Lookup Item • Lookup User • Lookup Version • Authenticate User • Lookup Request (proposed/accepted in Implementers Group)

13. Lookup Service Restrictions • Lookups require a Unique Id • They do not support discovery or searching

14. Update Services • Typical Circulation Transactions: • Request Item and Cancel Request Item • Check Out Item and Undo Check Out Item • Renew Item • Recall Item and Cancel Recall Item • Send User Notice • Check In Item

15. Update Services (2) • Object maintenance: • Create Agency and Update Agency • Create Item, Update Item and Update Request Item • Create User and Update User • Update User Fiscal Account • Create Services used for new objects • Update Services include modify and delete

16. Notification Services • Typical Circulation Transactions: • Item Requested and Item Request Cancelled • Item Checked Out • Item Renewed • Item Recalled and Item Recall Cancelled • User Notice Sent • Item Checked In

17. Notification Services (2) • Object maintenance: • Agency Created and Agency Updated • Item Created, Item Updated and Item Request Updated • User Created and User Updated • User Fiscal Account Updated

18. Notification Response • Notifications occur after the fact - no ability to say “don’t do that” • Only possible responses: • Did not understand message • Understood message

19. Message Structure • Syntax and Encoding • Scheme and Values • Datatypes

20. Syntax and Encoding • XML DTD (Currently) • Discussion in Implementers group of converting to an XML Schema • UTF-8 encoding of Unicode • ASCII is valid in this encoding. • But other systems are NOT restricted to ASCII, and you should be prepared to receive such data.

21. Scheme/Values • Mechanism for extensibility • Some defined in NCIP • Provides ability for locally defined values

22. Scheme/Values (2) • Handles enumerated types • e.g., Language • Defined by ISO 639-2 Bibliographic Language Codes • e.g., Currency Codes: • Defined by ISO 4217:1995 Codes for the representation of currencies and funds.

23. Scheme/Values (3) • Allows for extensibility • e.g., Bibliographic Record Identifier Code: • ANBN • BGF • BNBN • CN • LCCN • NLM TCN • OCLC • RLIN

24. Scheme/Values (4) • Allows for local agreements • e.g., Agency User Privilege Type • Adult • Agency Head • Colonel • President • Representative • Senator • Senior • Senior Staff • Staff • Youth

25. Scheme/Values (5) • Three kinds of Schemes: • Required and Restricted (Closed Enumerated) • Must be supported in order to conform • Cannot be extended • Required and Extendable (Open Enumerated) • Must be supported in order to conform • Can be extended • Undefined (Open Not Enumerated) • Not NCIP defined

26. Scheme Registration • Scheme names conform to URI spec. • Values within any Scheme must be unique • Once published, the list of Values must not change in any way

27. Datatypes • Taken from XML Datatypes • http://www.w3.org/TR/xmlschema-2/ • 6 datatypes: • boolean • “true”, “false”, “1”, “0” • integer • nonNegativeInteger • positiveInteger

28. Datatypes (2) • timeInstant • Restricted to ISO 8601’s “Extended format” • Expressed in Coordinated Universal Time (UTC). • “CCYY-MM-DDThh:mm:ss.sssZ” • string • You can append “-hh:mm” or “+hh:mm” to indicate local time as a difference (plus or minus) from UTC. • In DTD expressed as attributes – but not enforceable – will be in XML Schema

29. Technical Foundation • Application Roles • Messaging • Required Behavior Rules • Security

30. Application Roles • For a given connection, there is: • 1 and only 1 initiating application (e.g., self-service machine), and • 1 and only 1 responding application (e.g., circ system). • Initiators may NOT send a second message until the first is responded to. • Responders may NOT send initiation messages EVER on that connection

31. Application Roles (2) • Applications MAY establish multiple connections at the same time. • The Standard is written in terms of “initiating application” and “responding application”; this is always in the context of a given connection, not in the broader context of the application as a whole.

32. Messaging • State Tables • Transport Requirements • Transport Protocol(s)

33. Messaging State Tables • Do NOT govern the state of the circulation transaction • DO govern the state of the exchange of the initiation/response message pair • Initiating application is in IDLE or WAITING state • Responding application is in IDLE or PROCESSING state

34. Defined Transport Protocols • Initiator chooses from these 3: • TCP/IP • HTTP • HTTPS • Responder must reply on same connection

35. Omission of Requested Elements • Applies to entire Lookup Service Type and to “piggy-backed” lookups on Update Services. • Permits omission of some of the data the initiator asked for. • Permits omission of the “Electronic Resource” element if the responder would rather not supply it in the response message.

36. Update Processing • Responding application will behave as if all deletions requested were performed before all additions requested in the same message • If an update to one element causes an update to another element not specifically asked - a Notification message may be used to inform the other side • Example - change of birthday causes user category to change

37. Messaging Errors • Indicate lack of understanding of the message: • Invalid XML • XML not conformant to the DTD • Unknown scheme

38. Processing Errors • Indicate inability or unwillingness to perform the action requested • User Delinquent • Unknown item • Item does not circulate (Checkout) • Maximum renewals exceeded (Renewal)

39. Document Structure • Protocol Definition • Implementation Profile 1 • XML DTD/Schema • Application Profiles

40. Application Profiles • Currently three application areas: • Consortial borrowing • Circulation / ILL • Self-service • May be multiple profiles per application area • Define how to use NCIP within a given application context

41. Application Profiles (2) • Profiles can define • Messages used • Message sequencing • Optional data elements that are mandatory • Transport protocols required • Schemes required or available • Security requirements • Use cases

42. Application Profiles (3) • Some Application Profiles Written by NCIP Committee – meant as proof of concept for what Application Profiles should contain • Intent is that Application Profiles will be developed to define requirements of specific Applications/Implementations

43. Current Status • Standard/Implementation Profile Approved and Published in 2002 • Z39.83-2002 Part I Protocol • Z39.83-2002 Part 2 Implementation Profile 1 • XML DTD • XML Schema (currently Non Normative) • Application Profiles (Non Normative) • Avaialble at: • http://www.niso.org/standards/index.html • http://www.cde.state.co.us/ncip/NCIP-MG.htm • Maintenance Agency Assigned • Implementers Group Organized and Operating • Implementations beginning to exist – in production, in testing/beta, in development