NISO TR04-2006 Networked Reference Services Question Answer Transaction Protocol《网络参考服务 问题 答案交换协议》.pdf

《NISO TR04-2006 Networked Reference Services Question Answer Transaction Protocol《网络参考服务 问题 答案交换协议》.pdf》由会员分享，可在线阅读，更多相关《NISO TR04-2006 Networked Reference Services Question Answer Transaction Protocol《网络参考服务 问题 答案交换协议》.pdf（85页珍藏版）》请在麦多课文档分享上搜索。

1、NISO TR04-2006 Networked Reference Services: Question/Answer Transaction Protocol Abstract: The Networked Reference Services Question/Answer Transaction Protocol covers processing transactions for interchange of messages between digital reference domains. It defines a set of messages and associated

2、rules of syntax and semantics for this interchange that will support processing and routing of questions and responses and packaging of other information to be exchanged. Metadata element sets needed to identify and describe key components of both question and answer data and institutional and perso

3、nal data are defined, although some sets are maintained outside the standard. A Technical Report sponsored by the National Information Standards Organization December 2006 Published by the National Information Standards Organization Bethesda, Maryland Published by NISO Press Copyright 2006 by the Na

4、tional Information Standards Organization. All rights reserved under International and Pan-American Copyright Conventions. For noncommercial purposes only, this publication may be reproduced or transmitted in any form or by any means without prior permission in writing from the publisher. All inquir

5、ies regarding commercial reproduction or distribution should be addressed to: NISO Press 4733 Bethesda Avenue, Suite 300 Bethesda, MD 208114 Telephone: 301-654-2512 Email: nisohqniso.org About NISO Technical Reports NISO Technical Reports are developed by a working group commissioned by NISO to deve

6、lop recommendations outside the formal standards process or may be based on a proposed standard that did not result in consensus. Conclusions or recommendations in Technical Reports do not represent a consensus of the NISO membership. ISSN: 1081-8006 National Information Standards Organization Techn

7、ical Report Series ISBN-10: 1-880124-71-8 ISBN-13: 978-1-880124-71-0 Networked Reference Services: Q/A Transaction Protocol NISO TR04-2006 2006 NISO i Contents Foreword iv 1 Purpose and Scope 1 1.1 Purpose . 1 1.2 Scope 1 2 References and Related Standards 1 3 Definitions 1 4 Protocol Model 2 4.1 Ba

8、sic Model. 2 4.2 Exposition of Protocol Model. 4 4.2.1 The Basic Question/Answer Model 4 4.2.2 Clarification Model . 5 4.2.3 Constraint Model 7 4.2.4 Action/Status Model. 8 4.3 Topological Models . 8 4.3.1 Referral 8 4.3.2 Forwarding. 9 4.3.3 Chaining. 9 4.3.4 Patron Redirect 10 5 Identifiers 10 5.1

9、 Transaction Identifiers . 10 5.2 Message Identifiers . 10 5.3 Reference Identifiers . 10 5.4 URIs. 11 6 Timers and Lack of Activity 11 7 Abstract Data Structures 12 7.1 The NetRef Package . 12 7.1.1 Protocol Messages 12 7.2 Auxiliary Data Types for Protocol Messages 16 7.2.1 ContentInfo 16 7.2.2 Me

10、tadataElementType. 16 7.2.3 ContentWrapper. 17 7.2.4 ContactInfoType. 17 7.2.5 MsgInfoType 18 7.2.6 TransactionInfoType 18 7.2.7 TransactionIdType . 19 7.2.8 TransactionHistoryType. 19 NISO TR04-2006 Networked Reference Services: Q/A Transaction Protocol ii 2006 NISO 7.2.9 QuestionHistoryType . 19 7

11、.2.10 QuestionEventType . 19 7.2.11 RelatedTransactionType 20 7.2.12 ConstraintType. 20 7.2.13 ConstraintReplyType . 21 7.2.14 ConstraintInfo. 21 7.2.15 DiagnosticType 21 7.2.16 AcceptForwardType. 21 7.2.17 ForwardedType 22 7.2.18 ForwardInfoType 22 7.2.19 RequestPatronRedirectType . 22 7.2.20 Statu

12、sReportType 22 7.2.21 TransactionHistoryType. 23 7.2.22 AssignmentType 24 7.2.23 ReferralType 24 7.2.24 TextType 24 7.3 Profile Information . 24 7.3.1 ProfileType. 25 7.3.2 PersonInstIdType. 25 7.3.3 AgentInfo 26 8 Protocol Procedures 26 8.1 Rules . 26 8.2 State Tables 26 8.3 Error Handling . 27 8.4

13、 Out-of-Band Messages . 27 8.5 Termination 27 9 Mappings to Lower Layer Protocols 27 9.1 Lower layer protocols used by QATP 27 9.2 Bindings. 27 Appendix A: XML Schema 28 Appendix B: NetRef “info“ URIs 44 B.1 Syntax of an NetRef “info“ URI 44 B.2 Object Types . 44 B.3 Authorities 44 B.4 Schema . 45 A

14、ppendix C: Question/Answer Transaction Protocol Use Cases 46 C.0 Simple Question/Answer, Non-protocol Use Cases 47 C.1 Simple Question/Answer, Via Protocol Use Case. 47 C.2 Multipart Question Use Cases. 47 C.3 Multipart Answer Use Cases. 47 C.4 Additional Multipart Cases. 48 Networked Reference Serv

15、ices: Q/A Transaction Protocol NISO TR04-2006 2006 NISO iii C.5 Clarification Use Cases. 49 C.6 Transaction Progress Use Cases . 50 C.7 Constraint Use Cases . 51 C.8 Conversation Use Cases. 53 C.9 Question Acknowledgement Use Cases. 54 C.10 Reply to Patron Use Cases. 54 C.11 Patron Redirect Use Case

16、s. 54 C.12 Forwarding Use Cases55 C.13 Multiple Questions Use Cases 55 C.14 Topological Scenarios Use Cases 56 C.15 Reference to Archived Transaction Use Cases 57 C.16 Timer Use Cases. 57 Appendix D: Functional Model and Topology 58 D.1 The Reference Environment . 58 D.2 The Functional Model 58 NISO

17、 TR04-2006 Networked Reference Services: Q/A Transaction Protocol iv 2006 NISO Foreword Digital reference, also called virtual reference and online reference, is a relatively new but rapidly growing extension of the traditional reference service offered to library patrons. Digital reference allows a

18、 user to submit questions to library staff to be answered by electronic means, such as real-time chat, asynchronous email, or a combination of both. It is most often implemented using customized or modified versions of commercial software designed for managing call centers, web contact centers, e-co

19、mmerce customer service centers, and similar functions. The software provides forms for users to submit questions, notify reference staff when questions arrive, allow interaction between the questioner and responder, track the status of requests, and record questions and answers in a searchable data

20、base (“knowledgebase“). Often it is possible for the librarian to push web pages and filled-out forms to the user, and for the questioner and answerer to exchange screens. Networked Digital Reference takes this process one-step-further by involving multiple institutions. Collaborative networked digi

21、tal reference requires additional software support in order to route queries to the most appropriate participant. There is a growing interest in evolving localized digital reference services into more fully interconnected, collaborative reference services. NISO-sponsored a workshop on Networked Digi

22、tal Reference Services in Washington, D.C. on April 25-26, 2001 to explore to explore potential areas of standardization to facilitate the development and implementation of services in this new arena. Further information on the workshop and the final report are available online at: . Following the w

23、orkshop, NISO convened a standards committee that was tasked to 1) develop a question processing transaction protocol for the interchange of messages between digital reference domains to support processing and routing of questions and responses and packaging of other information to be exchanged; and

24、 2) develop metadata element sets to identify and describe key components of both question and answer data and institutional and personal data. The committee issued a Draft Standard for Trial Use describing the proposed protocol in April 2004 for a one-year trial that was later extended for a second

25、 year. At the conclusion of the trial use period, it was determined that the need to share reference questions among a variety of systems has not evolved to the extent that had been predicted. Most libraries are still focusing on local non-networked implementations. NISOs Standards Development Commi

26、ttee decided to no longer pursue a consensus standard in this area. However, it was felt that the committees work should be preserved so that if the need for a standard for networked reference emerges at a later time, the community can build on this work. Thus, the committees recommendations have be

27、en published in this technical report. For this specification to become an implemented protocol, further development of object types and registration of objects (see Appendix B) are needed and a maintenance agency for the protocol would be necessary. Networked Reference Services: Q/A Transaction Pro

28、tocol NISO TR04-2006 2006 NISO v Committee Members This technical report was developed by the following members of NISO Standard Committee AZ: Sally H. McCallum Chairperson Library of Congress Ray Denenberg Library of Congress Donna Dinberg Library and Archives Canada Cary Gordon The Cherry Hill Com

29、pany R. David Lankes Syracuse University Michael McClennen Internet Public Library Alison Morin Library of Congress Mary Parker MINITEX Jeff Penka OCLC Online Computer Library Center Joan Stahl University of Maryland Michael Teets OCLC Online Computer Library Center John Fallon (observer) T, Inc. Sh

30、irley Forster (observer) Altarama Systems system is the preferred term, but because it is such a common term, DRD is used when there is a possibility of ambiguity or when the specific connotation of DRD is intended to be emphasized. Networked Reference Services: Q/A Transaction Protocol NISO TR04-20

31、06 2006 NISO 3 A Protocol is the specification of a set of rules for communication between systems to carry out a particular type of task. Protocol defines the messages exchanged, their semantics and format, and the rules governing their exchange. Specifically, the QAT Protocol (QATP) governs messag

32、es exchanged between DRDs collaborating to process a question. If a DRD is itself capable of performing a function without external communication, then it need not employ protocol to perform that function, and the protocol does not address internal processing or communication within the system used

33、to carry out the function. The protocol describes communication between DRDs only. Thus a DRD is atomic and autonomous from the point of view of another DRD. However, a DRD may itself include DRDs, not externally visible. Suppose A and B are DRDs. A itself may includes logically distinct components

34、that communicate among one another to process a question. For example, suppose A includes the logical components A1 and A2, where A1 receives questions and determines either: (1) A is itself capable of answering the question, or (2) external communication with B is necessary. In the first case, A1 s

35、ends the question to A2 who processes it and sends the answer to A1 (as perhaps in Use Case 0.1 which is shown in Appendix C). In that situation, from the point of view of the world outside of A, none of the communication among As components is externally visible or subject to standardization. The s

36、econd case requires communication between A and B which is not possible unless governed by some agreed-upon protocol. However, protocol may indeed be necessary even in the first caseA1 and A2 might be distinct DRDs from each others point of view (for example, they may be from different vendors). Whe

37、n two DRDs communicate via QATP, the communication is described in the context of a transaction. QATP is a client/server protocol; the client is the questioner and the server is the answerer. Any system may play either role, though not in the same transaction. (A DRDs role is fixed within a given tr

38、ansaction.) A system may be a client in one transaction and a server in another. A protocol operation is the transfer of a protocol message from client to server or from server to client. An operation is an instance of an operation type, and a message is an instance of a message type. A transaction

39、includes one or more operations. Example: A client sends a Question message (which includes a question) to the server. Question is both a message type and an operation type. The act of sending the Question message is a Question operation. The server then sends an Answer message in response to the qu

40、estion. The act of sending the Answer message is an Answer operation. This concludes the exchange (the Question operation followed by the Answer operation), for this particular question; the Question operation and the Answer operation comprise a transaction. All operations for this protocol are one-

41、way; that is, the operation type defines a single message type. (For example, although a RequestClarification message from the server is normally followed by a Clarification message from the client, these are modeled as separate operations. There are other protocols that define operations in terms o

42、f more than a single message, for example a request followed by a response. Each operation type is given the same name as the message type it defines. Table 1 lists the operation/message types defined in this protocol. Table 1: Operation / Message Types Operation/Message Invoked/Sent by : Question C

43、lient Answer Server RequestClarification Server Clarification Client Constraint either client or server NISO TR04-2006 Networked Reference Services: Q/A Transaction Protocol 4 2006 NISO Operation/Message Invoked/Sent by : ConstraintReply either client or server ActionRequest Client Status Server Err

44、or either client or server Memo either client or server Other either client or server 4.2 Exposition of Protocol Model To begin describing the QATP Protocol model, we examine and contrast two of the use cases presented in Appendix C. (And similarly, by convention, we use “A“ and “B“ to refer to the

45、client and server respectively.) 4.2.1 The Basic Question/Answer Model As in Use Case, assume two DRDs: A and B. System A has received a question from a user. Use Case 0.1: A chooses to answer the question itself. Use Case 1.1: A chooses not to answer the question itself, but instead sends the quest

46、ion to B, requesting an answer. B processes the question, determines the answer and sends it to A, who then supplies the answer to the user. Examining these two cases in some detail, in terms of how the protocol is involved, the Use Case 0.1 process could be modeled as three events: 1) User sends qu

47、estion to A. 2) A processes the question. 3) A supplies answer to user. The Use Case 1.1 process could be modeled as five events: 1) User sends question to A. 2) A sends question to B. 3) B processes the question. 4) B sends answer to A. 5) A supplies answer to user. None of the steps in Use Case 0.

48、1 has protocol significance and only steps 2 and 4 of Use Case 1.1 do. The protocol is not concerned with how the question got from the user to A or how A supplies the answer to the user. Nor does the protocol govern or care how a system processes the question: how A processes the question in Use Ca

49、se 0.1 or B in Use Case 1.1. Two protocol operation types so far are identified: Question Operation: The transfer of a question (Question message) from A to B. Answer Operation: The transfer of an answer (Answer message) from B to A. Networked Reference Services: Q/A Transaction Protocol NISO TR04-2006 2006 NISO 5 A transaction may include multiple operations of either type. Thus a transaction might consist of: A Question operation (Question message from client to server), followed by An Answer operation (Answer message from server to client); Or Que