NCIP (NISO Circulation Interchange Protocol) Mark Needleman Sirsi Corporation Steve Gregory Colorado...
-
Upload
lindsay-ellis -
Category
Documents
-
view
215 -
download
0
Transcript of NCIP (NISO Circulation Interchange Protocol) Mark Needleman Sirsi Corporation Steve Gregory Colorado...
NCIP (NISO Circulation Interchange Protocol)
Mark NeedlemanSirsi CorporationSteve GregoryColorado State LibraryAccess 2004
Agenda
NCIP Tutorial
Update on NCIP Maintenance Agency and Implementers Group
Questions/Discussion
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
Committee Makeup
Representation ILS Vendors ILL Vendors Libraries Around 20 members with some additional
observers Skills
Computing/Technical Library Service Orientation
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 !!
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
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
Technical Architecture
3 Service Types
3 Object Classes
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.
Object Classes
Users Items Agencies (Libraries)
Transactions are associations between one or more of the objects
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 (proposed/accepted in
Implementers Group)
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
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
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
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
Notification Response
Notifications occur after the fact - no ability to say “don’t do that”
Only possible responses: Did not understand message Understood message
Message Structure
Syntax and Encoding Scheme and Values Datatypes
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.
Scheme/Values
Mechanism for extensibility
Some defined in NCIP
Provides ability for locally defined values
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.
Scheme/Values (3)
Allows for extensibility e.g., Bibliographic Record Identifier Code:
ANBN BGF BNBN CN LCCN NLM TCN OCLC RLIN
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
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
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
Datatypes
Taken from XML Datatypes http://www.w3.org/TR/xmlschema-2/
6 datatypes: boolean
“true”, “false”, “1”, “0” integer nonNegativeInteger positiveInteger
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
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., 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
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.
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 (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
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
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