Transcript Benefits of NCIP John Bodfish Senior Technical Designer click06 September 19, 2006 Agenda • Overview of the NCIP Standard • Example implementations • What implementers should know

Benefits of NCIP
John Bodfish
Senior Technical Designer
click06
September 19, 2006
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
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
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
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
Object Classes
• Users
• Items
• Agencies (Libraries)
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.
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.
Lookup Service
•
•
•
•
•
•
Lookup Agency
Lookup Item
Lookup User
Lookup Version
Authenticate User
Lookup Request (version 1.01)
Lookup Service Restrictions
• Lookups require a Unique Id
• They do not support discovery or
searching
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
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
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
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
Notification Response
• Notifications occur after the fact
• The only permitted responses are
– Did not understand message
– Understood message
Message Structure
• Syntax and Encoding
• Enumerated Types: Scheme/Value pairs
• Datatypes
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.
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
Scheme/Values (cont.)
• Example enumerated types:
– Language
• Defined by ISO 639-2 Bibliographic Language
Codes
– Currency Codes:
• Defined by ISO 4217:1995 Codes for the
representation of currencies and funds.
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
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
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.
Datatypes
• Taken from XML Datatypes
– http://www.w3.org/TR/xmlschema-2/
• 6 datatypes:
– boolean
• “true”, “false”, “1”, “0”
– integer
– nonNegativeInteger
– positiveInteger
Datatypes (cont.)
– 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.
• Expressed as fixed attributes in the DTD.
– In the non-normative XML Schema these are
proper datatypes.
Technical Foundation
•
•
•
•
Application Roles
Messaging
Required Behavior Rules
Security
Application Roles
• For a given connection, there is:
– 1 and only 1 initiating application (e.g., selfservice 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.
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.
Messaging
• State Tables
• Transport Requirements
• Transport Protocol(s)
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
Defined Transport Protocols
• Initiator chooses from these 3:
– TCP/IP
– HTTP
– HTTPS
• Responder must reply on same
connection
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.
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
Messaging Errors
• Indicate lack of understanding of the
message:
– Invalid XML
– XML not conformant to the DTD
– Unknown scheme
Processing Errors
• Indicate inability or unwillingness to
perform the action requested
– User Delinquent
– Unknown item
– Item does not circulate (Checkout)
– Maximum renewals exceeded (Renewal)
Document Structure
•
•
•
•
Protocol Definition
Implementation Profile 1
XML DTD/Schema
Application Profiles
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
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
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.
Example Implementations
• Interlibrary loan
• Patron self-service
• Direct Consortial Borrowing
Interlibrary Loan Example: Ship
Requesting
Library
Shipped message
with due date
Supplying Library
Check Out Item with user
and item IDs
Check Out Item Response
with due date
Circulation
System
Interlibrary Loan Example: Renew
Renew message
Requesting
Library
Supplying Library
Renew Answer message
with due date
Renew Item with item ID
Renew Item Response
Renew Item with item
ID, due date and
Mandated Action flag
Renewal
Notice
Circulation
System
Renew Item Response
with due date
Circulation
System
Patron Self-Service Example:
Registration
Learning
Management
System
Create User with name,
address and email address
Create User Response with
user ID
Circulation
System
Direct Consortial Borrowing
Example: Check Out Item
Lookup Agency with Agency Id and Authentication Prompt Element Type
Lookup Agency Response with
Authentication Prompt data
Lookup User with credentials
User’s Home
Library
Lookup User Response
with privileges
Item Checked Out with due date
Item Checked Out
Response
Item Owning
Library
Direct Consortial Borrowing
Example: Overdue Notice
Send User Notice with ‘Overdue’ data
User’s Home
Library
Send User Notice
Response
Item Owning
Library
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 there’s Castor or JAXB).
– Internet transports (TCP/IP, HTTP, HTTPS)
• There are standard ways to pass messages over these
transports; don’t “roll your own” if you can avoid it.
• The NCIP-IG has a Roadmap document to guide
your staff through the learning process.
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 haven’t 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 they’re doing similar things
– E.g., Circ/ILL and DCB-3 turned out to be virtually identical.
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 NCIP’s “Agency” map to your
circulation units (e.g. service desks, branches,
etc.) – this will depend on how your circ
vendor implements NCIP.
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
Future Directions
•
•
•
•
Simplification
Relationship to ISO ILL
Library standards as a whole
Web 2.0