National Information Standards Organization (NISO)
Standards Committee AV
U.S. National Z39.50 Profile for Library Applications
Open Issues For Resolution By SC AV
Issued May 2001
Revised August 21, 2001
Introduction
This document lists open issues in need of resolution by SC AV members. The Committee will need to reach consensus on this list of issues, and if necessary, a vote by the committee will be taken for those issues for which we are unable to reach consensus. This follows the standards development procedures of NISO. The issues are grouped by Functional Areas and Levels of Conformance.
Functional Area A: Basic Bibliographic Search and Retrieval in Online Library Catalogs
Issue #1 (May 2001): Should support of result set names (with 2 named results sets required) be a general requirement for all Levels of Functional Area A? Should this be a requirement introduced at Level 1?
August 21, 201 Note: There was not clear consensus from the committee members when this was first posted back in May. The August 21, 2001 draft does not specify result set name requirements within Section 5, Conformance for any levels. We still need to address and agree on this.
Proposal to consider: I propose that the support for named result sets be in effect at Level 1 and above. This would be a departure from Bath that has it as a Level 0 requirement.
Issue #2 (May 2001): Based on discussions with Poul Henrik Jorgensen from the ONE-2 project, I would like to revisit the decision on choosing the Library of Congress MARC DTD to use with XML Record Syntax in Levels 1 and 2. I would like us to be clear whether or not we need complete/both way transformations in and out of XML for MARC 21 records. In particular, why is important for the client to take a MARC 21 record in XML and transform it back into a legitimate MARC 21 record. Why doesn't it just ask for this record in MARC 21 syntax in the first place?
August 21, 2001 Note: Based on a number of comments on this issue, I have put in the August 21, 2001 draft, that the LC MARC XML DTD will be required. This topic will also be discussed at the October Bath meeting.
Issue #3 (August 21, 2001): The use of the Structure Attribute "phrase" is used in several searches that is causing some confusion (per messages from Ralph LeVan, Slavko Manojlovich, and Ed Riding. In some ways, the concept "phrase" can be interpreted as either:
a string of characters with blank spaces separating some characters (thereby creating words)"
a sequence of words with an implied adjacency operator.
For the searches that we define as "first characters in field," the first interpretation holds for parsing the query. For the searches we define as "first words in field," the second interpretation holds for parsing the query. A potential solution would be for the ZIG to define a new Structure Attribute "AdjWordList" that would more explicitly express the "sequence of words with an implied adjacency operator."
August 21, 2001 Note: I have contacted Ray Denenberg at the Maintenance Agency to begin the process of requesting a new structure attribute value: AdjWordList. We expect this to go forward as a request to the ZIG at the October meeting.
Issue #4 (August 21, 2001): Ed Riding proposed the inclusion of several "unanchored phrase searches" for Level 1. Specifically Ed proposes that there be three unanchored phrase searches: Title, Subject, Any. The following would be the attribute combination:
Attribute Type Attribute Values Attribute Names Use (1) 4, 21, 1016 title, subject, any Relation (2) 3 equal Position (3) 3 any position in field Structure (4) 1 phrase Truncation (5) 100 do not truncate Completeness (6) 1 incomplete subfield
A counter proposal by Ralph LeVan is that we get the ZIG to define a new Structure Attribute "AdjWordList" and use that as the Structure attribute for these searches.
If we do add these searches, should they be at Level 1 or Level 2? Please comment.
Issue #5 (August 21, 2001): Should there be different Use Attribute values used for the Format of Materials Search (Level 1) and the Type of Material Search (Level 2). For example, we could use "1001 Record Type" for the Format of Materials Search, and use "1031 Material-type" for the Type of Materials Search. Or, we could just use 1031 for both and have the difference implied based on the coded value that is sent as the query? Please comment.
Issue #6 (August 21, 2001): The Level 0 requirement for using the Latin-1 character set to encode the query term. A series of messages between Dan Iddings, Mark Needleman, Larry Dixson, Ray Denenberg, Dana Dietz, and Ralph LeVan raised the issue about this requirement. Dan's message discussed the problems of search results whether or not the diacritics in a search term are sent by the client to the server (and of course, what the server does with them upon receipt). There is a sense that the Latin-1 requirement may be meaningless without character set negotiation, and specifics on doing that negotiation.
August 21, 2001 Note: I have removed this requirement from the August 21, 2001 revised draft awaiting further discussion about this. One approach would be to be silent on what gets sent by the client. The character set negotiation issue will be an agenda item at the Bath meeting. At the very least, can we agree that at Level 0, our profile is silent on this? And then if we get the character set negotiation issue settled within Bath, maybe we can include a more specific requirement for Level 1 and above? Please comment.
[Date Page Last Revised: August 21, 2001]