# Presentation: 416912

## The NISO Question/Answer Transaction Protocol (QATP)

**Mark Needleman**
**Sirsi Corporation**

**Donna Dinberg**
**Library &  Archives****     of Canada**

**RUSA/MARS/MERS**
**ALA/CLA Toronto**
**June 22, 2003**

**Michael McClennen**
**Consultant**

## Agenda

**The Reference Environment & Network****      Models**
**The NISO Committee **
**Protocol Design Criteria**
**Envisioned Usage Scenarios**
**Protocol Messages**
**Protocol Technologies**
**Metadata Design Criteria**
**Possible Metadata, Other Considerations**
**Upcoming Activities**

## The Environment

**Libraries using digital reference to extend services and reach more users**
**Reference services evolving, moving from art to science**
**Cooperation and collaborative services growing:**
**Ask Eric, Virtual Reference Canada, QuestionPoint, 24/7 Reference, Internet Public Library, others**

## A Cooperative Model

**A Cooperative Model**

## A Networked Reference Model

**A Networked Reference Model**

## Background

**Question Interchange Protocol (QuIP)**** **
**Proposal to NISO**** **
**NISO-sponsored meeting April 2001 to explore areas for standardization**** **
**NISO AZ Committee on Networked Reference Services established December 2001**

## Committee Charge

**Develop question processing transaction protocol to support:**
**Processing and routing of questions and responses**
**Packaging of other information to be exchanged**
**Cross domain exchange**
** ****Develop metadata element sets to identify and describe key components of:**
**Question and answer metadata**
**Profiling metadata (institutional and personal data)**
**Conduct experimentation and/or research in both areas to test the proposed standard **
***Develop implementation guidelines & recommended best practices***

## Involved Parties

**Libraries and librarians**
**Reference service providers**
**Reference software and management providers**
**Integrated library system providers**
**Database and information systems**
**Other providers of community services**
** ****Tutoring programs **
** ****Research services**

## Protocol Design Criteria	

**Client/Server Design**
**Transaction based - transaction consists of one or more messages**
**Interaction is between 2 independent systems (although nothing precludes use inside a single system)**
**Must support a wide range of application areas**
**Protocol does not speak to interactions with end user**
**Automate the question/answer process but recognize actual answers will be provided by people**

## Usage Scenarios

**Subset of actual use cases being presented**
**Various scenarios are presented as being logically separate - in reality, they could be combined in multiple ways**

## Simple Question/Answer

**Client asks question**
**Server provides answer**

## Multiple Questions	

**Sent immediately**
**Client provides more information**
**Server sends answers when available**

## Multipart Answer	

**Server splits question into multiple parts and sends answers**
**Server sends an answer - subsequently realizes there is more information available and sends it**
**Server sends answer - informs client there will be more information coming - subsequently realizes there isn’t**
**Server acts as intermediary and forwards questions to other systems - receives answers and supplies them**
**Server answers some questions - informs client that it can not provide answers for others**

## Clarification Scenarios

**Server request clarification - client sends it**
**Server sends answer part - realizes it needs clarification **
**Multiple clarifications provided in response to multiple requests or bundled**
**Client does not provide clarification - but server can answer anyway**
**Client does not provide clarification - server gives up**

## Status Reporting Scenarios

**Client requests status of transaction - server provides it**
**Server ignores clients request**
**Server sends unsolicited status report**

## Suspend/Resume	

**Client asks server to suspend processing - subsequently asks for resumption**
**Client asks server to suspend processing until a specific date/time - automatic resumption**
**Client asks for suspension - subsequently cancels transaction**

## Cancellation

**Simple cancellation**
**Cancellation of part of a multipart question**
**Cancellation after a clarification request**
**Cancellation after receiving no answer**
**Client may continue to receive messages after after canceling**
**Server rejects cancellation because it has already done too much processing**

## Constraints

**Consents or binding constraints**
**client agrees**
**client rejects**
**Informational constraints**
**client does not need to reply**
**resource notifications****	**
**obligatory notices**

## Constraints (2)	

**Client-initiated constraints**
**server agrees**
**server rejects explicitly or implicitly**
**Prior constraints**
**Accompanying constraints**
**Partial constraints**

## Constraints (3)

**Negotiation**
**Multiple accompanying constraints**
**Constraint denied  - new constraint issued**
**Choices**
**Counter proposals**

## Other Scenarios	

**Failure**
**Completion**
**Never-ending transactions**
**Conversation**
**Reply directly to patron**
**Patron redirect**
**Forwarding**
**Chaining**
**Referral**
**Reference to archived transaction**
**Timers**

## Current Protocol Messages

**Question  . . . . . . . . . . . . . . **
**Answer   . . . . . . . . . . . . . . . **
**Request Clarification  . . . . **
**Clarification  . . . . . . . . . . . .**
**Constraint  . . . . . . . . . . . . .**
**Constraint Reply  . . . . . . . .**
**Request Progress  . . . . . . .**
**Progress Reply  . . . . . . . . .**
**Report Status   . . . . . . . . . . **
**Error  . . . . . . . . . . . . . . . . . .**
**Memo  . . . . . . . . . . . . . . . . . **
**Other . . . . . . . . . . . . . . . . . .****	**

**client initiated**
**server initiated**
**server initiated**
**client initiated**
**client or server initiated**
**client or server initiated**
**client initiated**
**server initiated**
**server initiated**
**client or server initiated**
**client or server initiated**
**client or server**** ****initiated**

## Protocol Technology       - Current Thinking

**Encoding**
**XML**
**XML Schema**
**Transports**
**SOAP over HTTP/HTTPS**
**SOAP over SMTP**
**Other technologies may be defined in the future**

## Metadata Design Criteria

**Able to be used independent of Protocol**
**Extensible where appropriate -- We don’t know what we don’t know**
**Flexible -- Provide facilities or services to carry service-specific information**
***Simple***** core data**
**           ****(Remember earlier lessons!)**

## Possible Metadata	

**Demographic information about the user**
**Information about the user’s library**
**Information about the question and the context in which it was asked**
**Information about the types of resources desired in the answer**
**Information about services desired**
**Metadata for describing various constraints**

## Other Considerations

**Needs in the community, e.g., directory services**
**Interaction with other protocols and standards**
**NCIP, OpenURL, Z39.50, ILL, others?**
**Additional models**
**Fee-based services (e-commerce)**
** ****Local systems**
**Knowledge bases**
**Measuring user satisfaction**
**Legal considerations:  privacy, copyright, jurisdictional law**
**Global considerations:  language, cultural and national relevancy**

## Upcoming Activities

**Prototyping and testing**
**Discussions at ASIST, VRD, ALA**
**Possible draft release end of 2003**
**Continued release of documents for review**

## Thank you for attending!

**NISO Web Site:**
**http://www.niso.org/committees/committee_az.html **
**Use Cases**
**http://www.niso.org/standards/resources/****    azusecases.pdf**