NCIP (NISO Circulation Interchange Protocol) Mark Needleman Sirsi Corporation Steve Gregory Colorado...

Post on 14-Jan-2016

215 views 0 download

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