Introduction to NCIP ALIA 2006

1
Benefits of NCIP
John Bodfish Senior Technical Designer
click06 September 19, 2006
2
Agenda

• Overview of the NCIP Standard
• Example implementations
• What implementers should know and expect from
  NCIP
• What libraries should know and expect from NCIP
• Future direction of NCIP

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
Scope of Standard

• Defines services, the messages that comprise
  those services and the structure and semantics of
  message elements.
• Does not define circulation functions or policies
• Does not define user interface

5
Applications Supported

• Circulation/InterLibrary Loan Interaction
• Direct Consortial Borrowing
• Self-service Circulation
• Access to Electronic Resources
• It had to support those, it may be able to
  support others

6
Object Classes

• Users
• Items
• Agencies (Libraries)

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

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

9
Lookup Service

• Lookup Agency
• Lookup Item
• Lookup User
• Lookup Version
• Authenticate User
• Lookup Request (version 1.01)

10
Lookup Service Restrictions

• Lookups require a Unique Id
• They do not support discovery or searching

11
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
• Accept Item

12
Update Services (cont.)

• Object maintenance
• Create Agency and Update Agency
• Create Item, Update Item, Update Request Item,
  Update Circulation Status and Report Circulation
  Status Change
• Create User and Update User
• Create User Fiscal Transaction
• Create Services used for new objects
• Update Services include modify and delete

13
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
• Item Shipped and Item Received

14
Notification Services (cont.)

• Object maintenance
• Agency Created and Agency Updated
• Item Created, Item Updated, Item Request Updated,
  Circulation Status Updated and Circulation Status
  Change Reported
• User Created and User Updated
• User Fiscal Transaction Created

15
Notification Response

• Notifications occur after the fact
• The only permitted responses are
• Did not understand message
• Understood message

16
Message Structure

• Syntax and Encoding
• Enumerated Types Scheme/Value pairs
• Datatypes

17
Syntax and Encoding

• XML DTD
• UTF-8 encoding of Unicode
• ASCII character encoding is the same in this
  encoding, but
• Other systems are NOT restricted to ASCII, and
  you should be prepared to receive such data.

18
Enumerated Types Scheme/Value pairs

• Enumerated data types are represented by a pair
  of elements Scheme and Value.
• Ensures that codes (the Value element) are in a
  context (the Scheme element).
• Provides for extensibility

19
Scheme/Values (cont.)

• Example enumerated types
• Language
• Defined by ISO 639-2 Bibliographic Language Codes
• Currency Codes
• Defined by ISO 42171995 Codes for the
  representation of currencies and funds.

20
Scheme/Values (cont.)

• Allows for extensibility
• The Standard provides a Bibliographic Record
  Identifier Code scheme including these values
• ANBN, BGF, BNBN, CN, LCCN, NLM TCN, OCLC, RLIN
• If you need a different list you can define your
  own scheme

21
Scheme/Values (cont.)

• Three kinds of Schemes
• Closed, Enumerated
• Those defined in the Standard must be supported
  in order to conform
• New schemes may NOT be defined
• Open, Enumerated
• Those defined in the Standard must be supported
  in order to conform
• New schemes may be defined
• Open, Not Enumerated
• None are defined in the Standard

22
Scheme Registration

• Scheme names conform to URI specification
• Values within any scheme must be unique
• Once published, the list of values must not
  change in any way
• NCIP maintenance agency will host a registration
  service.

23
Datatypes

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

24
Datatypes (cont.)

• timeInstant
• Restricted to ISO 8601s Extended format
• Expressed in Coordinated Universal Time (UTC).
• CCYY-MM-DDThhmmss.sssZ
• string
• You can append -hhmm or hhmm to indicate
  local time as a difference (plus or minus) from
  UTC.
• Expressed as fixed attributes in the DTD.
• In the non-normative XML Schema these are proper
  datatypes.

25
Technical Foundation

• Application Roles
• Messaging
• Required Behavior Rules
• Security

26
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 on
  that connection.

27
Application Roles (cont.)

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

28
Messaging

• State Tables
• Transport Requirements
• Transport Protocol(s)

29
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

30
Defined Transport Protocols

• Initiator chooses from these 3
• TCP/IP
• HTTP
• HTTPS
• Responder must reply on same connection

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

32
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

33
Messaging Errors

• Indicate lack of understanding of the message
• Invalid XML
• XML not conformant to the DTD
• Unknown scheme

34
Processing Errors

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

35
Document Structure

• Protocol Definition
• Implementation Profile 1
• XML DTD/Schema
• Application Profiles

36
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

37
Application Profiles (cont.)

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

38
Application Profiles (cont.)

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

39
Example Implementations

• Interlibrary loan
• Patron self-service
• Direct Consortial Borrowing

40
Interlibrary Loan Example Ship
Requesting Library
Supplying Library
Circulation System
41
Interlibrary Loan Example Renew
Supplying Library
Requesting Library
Circulation System
Circulation System
42
Patron Self-Service Example Registration
Learning Management System
Circulation System
43
Direct Consortial Borrowing Example Check Out
Item
Item Owning Library
Users Home Library
44
Direct Consortial Borrowing Example Overdue
Notice
Item Owning Library
Users Home Library
45
What Implementers Should Know

• Designers
• Protocol, particularly the services you will use.
• Programmers
• Protocol and Implementation Profile 1
• XML, Unicode UTF-8
• There are tools to help with mapping XML to
  objects (e.g. for Java theres Castor or JAXB).
• Internet transports (TCP/IP, HTTP, HTTPS)
• There are standard ways to pass messages over
  these transports dont roll your own if you
  can avoid it.
• The NCIP-IG has a Roadmap document to guide your
  staff through the learning process.

46
What Implementers Should Expect

• Like with all standards, there will be surprising
  differences of interpretation between
  implementers
• Expect early testing to be slow going
• Be mindful of what you expect from other
  standards (e.g. MARC, Z39.50)
• There are many differences that havent mattered
  because the results were being read by humans
  (e.g. contents of MARC 001 field) which you will
  now be using in an automated fashion so their
  contents must be right.
• It will help responders greatly if the initiators
  reach consensus if theyre doing similar things
• E.g., Circ/ILL and DCB-3 turned out to be
  virtually identical.

47
What Libraries Should Know

• NCIP can automate many routine tasks in many
  areas of the library.
• NCIP implementations will require two (or more)
  vendors to co-operate.
• Understand key NCIP enumerated types
• E.g., how does NCIPs Agency map to your
  circulation units (e.g. service desks, branches,
  etc.) this will depend on how your circ vendor
  implements NCIP.

48
What Libraries Should Expect

• Initial deployment of NCIP for any vendor is
  likely to be rough going.
• Multiple updates to two or more systems will have
  to be co-ordinated.
• This is a big part of the future of library
  automation (not just NCIP)
• Interoperation between systems for micro
  services
• Using XML, Unicode, HTTPS

49
Future Directions

• Simplification
• Relationship to ISO ILL
• Library standards as a whole
• Web 2.0