slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Benefits of NCIP PowerPoint Presentation
Download Presentation
Benefits of NCIP

Loading in 2 Seconds...

play fullscreen
1 / 49

Benefits of NCIP - PowerPoint PPT Presentation


  • 138 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Benefits of NCIP' - hazina


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Benefits of NCIP

John Bodfish

Senior Technical Designer

click06

September 19, 2006

agenda
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
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
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
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
Object Classes
  • Users
  • Items
  • Agencies (Libraries)
service types
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
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 Service
  • Lookup Agency
  • Lookup Item
  • Lookup User
  • Lookup Version
  • Authenticate User
  • Lookup Request (version 1.01)
lookup service restrictions
Lookup Service Restrictions
  • Lookups require a Unique Id
  • They do not support discovery or searching
update services
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
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
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
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
Notification Response
  • Notifications occur after the fact
  • The only permitted responses are
    • Did not understand message
    • Understood message
message structure
Message Structure
  • Syntax and Encoding
  • Enumerated Types: Scheme/Value pairs
  • Datatypes
syntax and encoding
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 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
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 cont1
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 cont2
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 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
Datatypes
  • Taken from XML Datatypes
    • http://www.w3.org/TR/xmlschema-2/
  • 6 datatypes:
    • boolean
      • “true”, “false”, “1”, “0”
    • integer
    • nonNegativeInteger
    • positiveInteger
datatypes cont
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
Technical Foundation
  • Application Roles
  • Messaging
  • Required Behavior Rules
  • Security
application roles
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.
application roles cont
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
Messaging
  • State Tables
  • Transport Requirements
  • Transport Protocol(s)
messaging state tables
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
Defined Transport Protocols
  • Initiator chooses from these 3:
    • TCP/IP
    • HTTP
    • HTTPS
  • Responder must reply on same connection
omission of requested elements
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
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
Messaging Errors
  • Indicate lack of understanding of the message:
    • Invalid XML
    • XML not conformant to the DTD
    • Unknown scheme
processing errors
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
Document Structure
  • Protocol Definition
  • Implementation Profile 1
  • XML DTD/Schema
  • Application Profiles
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
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 cont1
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
Example Implementations
  • Interlibrary loan
  • Patron self-service
  • Direct Consortial Borrowing
interlibrary loan example ship

Shipped message

with due date

Check Out Item with user and item IDs

Check Out Item Response with due date

Interlibrary Loan Example: Ship

Requesting

Library

Supplying Library

Circulation

System

interlibrary loan example renew

Renew message

Renew Item with item ID

Renew Answer message with due date

Renewal Notice

Renew Item Response

Renew Item with item ID, due date and Mandated Action flag

Renew Item Response with due date

Interlibrary Loan Example: Renew

Requesting

Library

Supplying Library

Circulation

System

Circulation

System

patron self service example registration

Create User with name, address and email address

Create User Response with user ID

Patron Self-Service Example: Registration

Learning

Management

System

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

Lookup User Response with privileges

Item Checked Out with due date

Item Checked Out Response

Direct Consortial Borrowing Example: Check Out Item

User’s Home

Library

Item Owning

Library

direct consortial borrowing example overdue notice

Send User Notice with ‘Overdue’ data

Send User Notice Response

Direct Consortial Borrowing Example: Overdue Notice

User’s Home

Library

Item Owning

Library

what implementers should know
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
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
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
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
Future Directions
  • Simplification
  • Relationship to ISO ILL
  • Library standards as a whole
  • Web 2.0