Just as before, in order to aid services in their own reporting, there will be a Custom Question Type where services may add an internally useful categorical variable.
Responder Information
Services are the least willing to collect information about the person answering the question. QuestionPoint actively removes this information, and maintaining no information about the expert will protect the privacy of the individual.13 One field about the expert would be useful–Responder Role, with the choices of:
- Subject Expert (someone answering the question because they are an expert in a topic area)
- Librarian/Researcher (someone answering the question because they know how to find information in resources)
- Unknown/Other
Another field involved with the responder identity is the Service Name field. This will be useful in conjunction with the referral information, as well as in creating individual reports for participating services. This field will undergo authority control as participants are added to DREW; eventually, this same authority file will be used for the Referral Service field.
Again, there will be a single Custom Responder Type that can be used by an individual service for categorical data to aid in reporting.
Response Information
All four fields listed on the survey are useful for research and many services are willing to collect them; therefore Response Date, Response Time, and Response Resources are all part of this proposed schema.
If available, the field Response Type will be added with the following choices (based on the NetRef standard):
- Answer (where the response answers the question)
- Clarification (where the response is a request for clarification)
- Out of Scope (where the question was not answered)
- Other (Thank You and other types of transactions)
Finally, there will be a Custom Response Type available for services to use for categorical data.
Observations
While those doing chat reference currently collect the least amount of information, they were the most willing to collect additional information for this research. Conversely, the Web form services were less willing to collect additional fields. There are several hypotheses as to the reason behind this finding. Administrators who filled out this survey for a chat service may be frustrated by the lack of data currently collected about a chat reference service, and thus are willing to collect more information if there is an opportunity. Conversely, those running Web form services may have noted that collecting more fields results in fewer questions. In addition, as a Web form-based service requires much more planning to develop fields that are collected, administrators of these services may be less willing to make changes. Further research is needed to explore these hypotheses.
Summary of Fields
Based upon this research, the types of information going into the DREW archival schema for digital reference transactions includes:
- Service Name
- Question Educational Level
- Patron Zip Code
- Patron Country
- Question Free-Text Subject
- Question Category
- Question Date
- Question Time (standardized)
- Previously Consulted Sources
- Question Referral
- Referral Service
- Responder Role
- Response Date
- Response Time (standardized)
- Response Resources
- Response Type
- Transaction Text
- Question Text and Response
- Text/Response Type, or
- Transaction Text (in the case of e-mail), or
- Chat Transcript
- Transaction Type
- Custom Patron Type
- Custom Question Type
- Custom Response Type
These elements will form the tagging system of complexity theory.
Current Challenges
The survey provides a starting point for exploration by providing the fields that will define the service. There are three current research challenges for this project: NISO standards and threading, subject list authority, and privacy.
NISO Standards and Threading
One goal of this process is to create a schema for archiving that is compatible with the networked reference services protocol NISO AZ, a.k.a. NetRef.14 In its current configuration, this standard is designed to assist with the operational needs of passing questions from one service to another.
As with most data warehousing applications, the data kept for archiving are usually in a different form than the data used in the operation of the system. In addition, the timing of the application of the standards is important; NetRef is applied when the question is passed to another service, while the DREW schema is applied to the transaction after it is completed.
It is important, therefore, that the archival schema be compatible with the operational standard. This is critical in improving participation with the DREW program; making a data warehouse structure compatible with the NISO standard will make it easy for services using the NISO standard to supply transactions for the warehouse.
One significant issue in the transition from the operational standard to archival form is the de-threading and cleaning of a reference transaction to extract the important components of the transaction needed for data warehousing. The structure of the data warehouse will be based upon the key elements of the transaction–question and initial response. If the thread continues, it will be separated into a second record that links back to the initial thread. There are several possibilities of what this second transaction could be–a new or follow-up question from the patron or a request for more information from the expert. As the data warehouse grows, one line of exploration will be to attempt to automatically classify transactions; this will prove useful in creating cleaner search mechanisms and automating reference processes.
The NetRef threading issues are a harbinger of the problems to come in attempting to incorporate chat reference into this type of knowledge structure. In chat reference, there is not usually a clearly defined question and answer; rather, these two parts of the transaction may be presented throughout the interchanges. One intriguing line of research is to use natural language processing to automatically extract the question and the answer from a chat transcript. A more realistic solution would be to take the chat platform and build in markup tools so that a librarian answering a question could quickly mark key phrases and components of an interchange for later cleaning and archiving. In addition, if the important parts are marked and the full text is available, it then becomes much easier to train systems using machine learning techniques to successfully pick out the key parts of the conversation.
Subject List Interoperability
One of the current challenges in crossing the boundaries between digital reference services, as well as other knowledge management systems, is that of subject assignments. Most services assign a subject term to a question at some point in the process: the user may assign a subject when the question is asked, the administrator may select a subject explicitly through a field or implicitly through expert assignment, or the expert may assign a topic during the answering process. Many times, these subjects come from a list that is unique to that service.
Different approaches to this problem of creating subject lists for multisource knowledge bases were discussed by Zeng and Chan in their review of interoperability between knowledge organization systems.15 To select a method for subject list interoperability, the key factors of this particular setting must be enumerated. The individual digital reference services will either be a general service or a subject-specific service. The subject-specific services will have a specific-subject list, and it is important to maintain that specificity so that subject-specific services on similar subjects can take advantage of that detail. However, the question classification term list used by a subject-specific service could be rolled up to a higher-level term that would be appropriate for the g eneral service.
Therefore, it is important to maintain the original selection and subject list established by the reference service to aid that service in management and reporting and to help that service work with similar services. From a knowledge-base perspective, however, it is important to map these varying subject lists to a common list to aid in interoperability.