1 / 56

An Introduction to NCIP

An Introduction to NCIP . October 2, 2002 Mark H Needleman Sirsi Corporation NCIP Implementers Forum Revised January 2, 2008 Lynne Branche Brown Innovative Interfaces, Inc. NCIP Implementers Group. Scope of the Standard.

chaz
Download Presentation

An Introduction to NCIP

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An Introduction to NCIP October 2, 2002 Mark H Needleman Sirsi Corporation NCIP Implementers Forum Revised January 2, 2008 Lynne Branche Brown Innovative Interfaces, Inc. NCIP Implementers Group

  2. Scope of the 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

  3. Functions Supported • Direct consortial borrowing • Circulation/InterLibrary Loan Interaction • Self-service Circulation

  4. NCIP Structure NCIP Documentation has multiple parts: • Part 1: Protocol Definition • Part 2: Implementation Profile 1 • XML DTD and Schema • Vendor Application Profiles

  5. Circulation Interchange Part 1: Protocol • Defines the Services • Defines the Messages • Defines the Data Elements • Defines the error codes • Defines the extensibility mechanism • Provides some lists of enumerated data types • Provides a simple state table

  6. Circulation Interchange Part 1: Protocol, con’t • Defines the concept of profiles • Provides a template for building Implementation and Application Profiles • Provides guidelines for activities of maintenance and registration agencies • Not bound to any particular technologies

  7. Circulation Interchange Part 2: Protocol Implementation Profile 1 • Defines the message encoding (XML) • Defines the underlying Transport Protocols - HTTP/HTTPS and TCP • Defines Character Set - Unicode/UTF-8 • Defines some behavior rules • Provides an encoding of enumerated datatypes

  8. XML DTD and Schema • Provides the XML encoding of the messages • Used by a parser or application to ensure received message is valid

  9. Vendor Application Profiles • Define how to use NCIP within a particular application domain • Conform to an Implementation Profile • Describes application area and participating applications • Defines the business rules • Defines required services • Defines required and conditionally required data elements

  10. Vendor Application Profiles, con’t • Defines an event table and messages sent and received when those events occur • May provide additional enumerated data types • Defines transport protocols • May define security and privacy requirements • May provide additional implementation guidelines

  11. Vendor Application Profiles MAY NOT • Redefine data elements specified in the protocol • Add additional messages • Define new objects • Define additional transport protocols • Add data elements to messages • Make required data elements optional • Specify a data type inconsistent to how its defined in the protocol or implementation profile

  12. Technical Architecture • 3 Service Types • 3 Object Classes

  13. 3 Service Types • Lookup • “Tell me these things about this object.” • Update • “Please take this action.” • Notification • “I have taken this action.”

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

  15. 3 Object Types • Users • Items • Agencies (Libraries) • Transactions are associations between one or more of the objects

  16. Lookup Service Type • Lookup Agency • Lookup Item • Lookup User • Authenticate User • Lookup Version

  17. Lookup Service Type • Lookups are about a unique thing • They do not support discovery or searching.

  18. Update Services • Typical Update 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

  19. Update Services • Object maintenance: • Create Agency and Update Agency • Create Item, Update Item and Update Request Item • Create User and Update User • Create User Fiscal Transaction • Create Services used for new objects • Update Services include modify and delete

  20. Notification Services • Typical Notification Transactions: • Item Requested and Item Request Cancelled • Item Checked Out • Item Renewed • Item Recalled and Item Recall Cancelled • User Notice Sent • Item Checked In

  21. Notification Services • Object maintenance: • Agency Created and Agency Updated • Item Created, Item Updated and Item Request Updated • User Created and User Updated • User Fiscal Transaction Created

  22. Notification Services • Item Shipped • Item Received • Circulation Status Change Reported • Circulation Status Updated

  23. Notification Response • Notifications occur after the fact - no ability to say “don’t do that” • Only possible responses: • Did not understand message • Understood message

  24. Mandated Action • Flag on Request Messages • Used to turn a request into a de facto notification • May require out of band handling

  25. Syntax and Encoding • XML DTD • UTF-8 encoding of Unicode (UCS-2) • ASCII is valid in this encoding. • But other systems are NOT restricted to ASCII, and you should be prepared to receive such data.

  26. Scheme/Values • Mechanism for extensibility • Provides mechanism for NCIP to make use of other standardized lists • Some defined in NCIP Protocol • Provides ability for locally defined values

  27. Schemes and Values • Two kinds of Schemes: • Closed • Must be supported in order to conform • Cannot be extended • Open • Can be extended • For many (but not all) data elements NCIP provides some lists that must be supported for interoperability purposes

  28. Use of other Standardized Lists • Language Codes • Defined by ISO 639-2 Bibliographic Language Codes • Currency Codes • Defined by ISO 4217 Codes for the representation of currencies

  29. Allow for Extensibility • Bibliographic Record Identifier Code: • ANBN • BGF • BNBN • CARL: UNCOVER • CN • LCCN • NLM TCN • OCLC • RLIN

  30. Allow for Local Practice • Agency User Privilege Type (Public) • Adult • Child • Senior • Staff • Young Adult • Agency User Privilege Type (Academic) • Faculty • Graduate • Postdoctoral • Staff • Undergraduate

  31. Scheme Defintion • Scheme names are URI’s • Values within any Scheme must be unique • Once published, the list of Values must not change in any way - if changes are made a different URI is defined

  32. Example Scheme/Value <UserPrivilege> <UniqueAgencyId> <Scheme>http://www.librarylist.org </Scheme> <Value> Needleman Library </Value> </UniqueAgencyId> <AgencyUserPrivilegeType> <Scheme> http://www.needleman.com/patrons </Scheme> <Value> Platinum User </Value> </AgencyUserPrivilegeType> . . . </UserPrivilege>

  33. Datatypes • Each PCDATA element has a datatype associated with it • Datatypes are subset of those defined in W3C XML Schema Language: • dateTime • string • positiveInteger • nonNegativeInteger • Integer • In DTD datatypes defined using #FIXED attributes • NCIP Schema uses “real” datatypes

  34. Headers • Each message has a header • Initiation messages have an Initiation Header • Response Messages have a Response Header • Header provides for security and identification • From System and Agency • From System and Agency Authentication • To System and Agency

  35. Unique Id’s • Agency Id’s • Registration scheme to ensure uniqueness • Value in Scheme • User Id’s, Item Id’s and Request Id’s are compound; they include the Agency Id

  36. Element Id’s • Lookup initiation messages (except Lookup Version and Authenticate User) must include “Element Id” elements. • These are used to specify “these things,” as in “Tell me these things about this object.” • Element Id can be used to ask for data about the object in other messages as well

  37. Use of Element Id • One of these for each object class: • Agency Element Id • Item Element Id • User Element Id • Each of them has a corresponding Closed Scheme • Identifies which elements of the object are desired in a Lookup service (or other relevant messages)

  38. Element Id in a Request <ItemElementType> <Scheme> http://www.niso.org/ncip/v1_0/schemes/itemelementtype/itemelementtype.scm </Scheme> <Value>Bibliographic Description </Value> </ItemElementType>

  39. Optional Fields in Response <ItemOptionalFields> <BibliographicDescription> <Author> Mark Needleman </Author> <Edition> 1st </Edition> <PlaceOfPublication> St Louis </PlaceofPublication> <PublicationDate> 2003 </PublicationDate> <Title> A Nobel Prize Winning Novel </Title> </BibliographicDescription> </ItemOptionalFields>

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

  41. Application Roles • 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

  42. Application Roles • Initiating application waits for the response message or a timeout. • Applications may keep the connection open in an “Idle” state in anticipation of exchanging a series of message pairs (to avoid the costs of establishing a connection for each exchange).

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

  44. Messaging State Tables • INITIATOR RESPONDER IDLE IDLE Initiation Message WAITING PROCESSING

  45. Messaging State Tables • INITIATOR RESPONDER IDLE IDLE Response Message WAITING PROCESSING

  46. Transport Protocol Requirements • Confirmed Service • Initiation/Response message pairs • The Response message confirms the service. • The transport layer must indicate that the peer has disconnected.

  47. Supported Transport Protocols • Initiator chooses from these 3: • TCP/IP • HTTP • HTTPS • Responder must reply on same connection - and thus using the same protocol with which it got the initiation message

  48. Behavior Rules • Definition of Success • Omission of requested elements • Inclusion of unrequested elements • Update processing • Error identification • Messaging errors • Processing errors

  49. Omission of Requested Items • 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. • Example: Initiation message requests user’s date of birth but policy at responder does not allow it to be revealed

  50. Inclusion of Unrequested data • Some elements in the messages are defined so the requester can specify what information it wants to get back • Element Id fields • Information about holds on at item • Responder may not include such elements if not requested by Initiator

More Related