SC AV: Meeting 2 Summary, January 10-11, 2001

	National Information Standards Organization (NISO) Standards Committee AV
	Developing a U.S. National Z39.50 Profile for Library Applications

This document provides a summary of the second meeting of the National Information Standards Committee (NISO) AV that is charged with the development of a U.S. National Z39.50 Profile for Library Applications. Members of SC AV met for 2 days to continue its work to prepare a draft standard that NISO will submit for voting by its voting members. This summary does not detail all discussions at the meeting but rather is meant to communicate the important decisions and agreements based on committee discussion. This summary is ordered based on the agenda of the meeting.

The entire complement of the committee attended the second meeting of NISO Standards Committee AV (SC AV). Two observers were present. A list of the attendees is available. A list of agreements follows the body of the summary. In addition, specific tasks and assignment of responsibilities identified by SC AV members for follow-up are also included. Also a summary of the searches for each Level of Conformance discussed at the meeting is available.

The meeting began with a discussion of the Summary from Meeting 1. Dixson raised several issues regarding the proposed profile and some of the decisions that have been made and others that should be made but have been omitted. These included things such as the National Standard shouldn’t specify the “either/or” of MARC 21 and UNIMARC, that it should specify one or the other. This was deferred to discussion of the profile.

Dixson also questioned Standard Identifier Search. He preferred breaking them out. He also questioned the Format/Type of Material searches as being impossible to do without some sort of definitive list. These discussions were also deferred to the discussion of the profile.

In response to a member's comment about the need for a representative of the A&I database vendor community, Moen stated that he has worked with NISO to try to get some A&I vendor representation. NISO had asked Helen Akins of ISI but she declined. They are still pursuing representative from Cambridge Scientific.

Carrol Lunau, Bath Profile Maintenance Agency, offered the following report on the status of the Bath Profile:

There are still some outstanding issues to be taken up by the Bath Profile group:

Lunau discussed the procedures for maintaining the Bath Profile. There will be new versions of the profile when there are significant additions or changes rather than limit themselves to review every 5 years. Amendments would add new functionality without impacting the core of the current profile. Amendments would be discussed at a “developers group”. [The next meeting will be in conjunction with the ZIG in the UK later this year. This group would meet twice a year, once in conjunction with the ZIG and once in conjunction with some major library group.]

Defect Reports - Minor ones (editorial or clarifications) would be submitted through the Bath Profile Maintenance Agency web site, discussed on the listserv and the developers group, or if really minor, just done. Major items would stay on the web site as a separate item with an indication of status. Would be later incorporated with the next revision of the profile.

Moen referred the committee to the Preliminary Specifications for Review by SC AV Members (December 31, 2000) he had developed based on decisions at the first meeting. He first reviewed his suggestions on “Numbering” of the profile, with indications of Bath, the National Profile, and any state profile additions and/or changes.

Moen reviewed Functional Area A, Searching, Level 0. Dixson said that every implementor will wonder in perpetuity about “Precision Match for Established Name Heading”. This is really just an unanchored phrase search. This hasn’t been implemented in the US but has been implemented by some vendors in Europe. Manojlovich added that Sirsi has implemented it in their current release. Dixson will try to come up with examples to help future implementors. Concern was expressed that if the only reason for including this is for Bath compliance, then we should only include it in our profile for compliance without additional comment. Moen will get examples from Dixson and forward them to the Bath maintenance agency.

Denenberg questioned “hiding” features - whether a client is conformant if it can do all of the features to comply with the format but the client hides a number of features that it doesn’t want to present to their users. Several times during the meeting, the topic of what does it mean to conform was discussed. There was an acknowledgement that a product must be capable of all specifications at a given level of conformance, but a library may not choose to make all that functionality visible to all users.

Another concern is whether all of the Author searches, Title searches, etc should be grouped together. This may confuse the numbering and make the standard harder to read and understand. Committee members suggested that all similar searches be listed together, whether they were Bath or US National searches (e.g., all author searches together), rather than listing the Bath searches and then the US searches. Goldner suggested that US numbering be independent of the Bath numbering. Moen will start US numbering at 1. The National profile will include the BL numbering but the US numbering will start at one and moved into the other searches. Also it may be useful to have all of the changes to the Bath profile listed together for each Functional Area and Level. Riding is working on a table that he will forward to Moen for possible inclusion in the profile.

Moen reviewed Functional Area A, Searching, Level 1. Dixson will come up with additional examples for corporate names, unanchored, and truncated.

Dixson pointed out that Relation Attribute should be “3" instead of “2" throughout.

Goldner suggested that the listing for US1.15 Author Search — First Character in Field (Left-Anchored with Truncation) should
be “First Characters in Field” (plural).

There was a lot of discussion as to whether US1.15 be included in Level 0. Level 0 in Bath was supposed to be what current systems are doing. While that was true in Europe, it isn’t necessarily true in the US. Level 0 didn’t have any First In Field searches or Truncated searches. To include US1.15 in Level 0 may put significant burden on the vendors. Moen cautioned that we need to be cognizant of the “creaping feature syndrome”. We need to keep Level 0 at the “minimum” feature level. The group decided to leave Level 0 at the place currently defined.

Dixson again raised the “standard identifier” problem. Will vendors be upset with an index of “everything”? Several people had relatively strong feelings about usability of a generic “standard identifier” search. Needleman suggested that we need to accept this to maintain Bath compliance but that we may want to add additional items that should be considered in this index, such as LCCN. Moen will send a request to Bath to clarify the use this search.

Wilson questioned whether a system is compliant if a database had no ISSNs, since an ISSN search is required in Level 1. If there is no ISSN in the record, but the system could support the search if it was there, and if the system would respond with zero hits, it would be compliant. There is a difference between “the ability to support” and “indexing”. A given search may be able to be supported by a server, but a given implementor may choose not to index specific items for whatever reason.

What is appropriate diagnostic to send when there is no data in record for a Profile compliant search? (The suggested Bib-1 diagnostics are: 1056: Attribute not supported for database, 1025: Service not supported for this database) Guidance on the appropriate diagnostic should be in the profile.

Dixson questioned what types of “local system numbers” should have specified searches. Iddings said that OCLC number searching is as important at Level 1 as ISBN. A list of additional identifiers and associated levels was developed:

There was a lot of discussion on State Government Numbers and how to differentiate between the different states. Denenberg proposed a URI that would have a registered “state name” followed by a colon and the number. Then the State Government Number could be a Level 2 search with a “50" as the attribute. Moen asked that we talk about this again for 15 minutes on Day 2 when Chris Peterson from Texas Libraries is present. It was decided that this item would be deferred until the URI schema is approved. An alternative approach for such a search would be to have it be an Boolean search for number and the state code in the record ($2?).

Dixson proposed that Format/Type of Material Search be moved back to level 2. Dixson will try to create a definitive list of values which will include values from Leader 06-07, field 006/007, and the GMD. After a discussion of whether to include the GMD, it was decided to have a small group (Meyer, Needleman, and Dixson) develop the list and make recommendations.

Manojlovich had a request from a Maps librarian to add a search by coordinates. The Geospatial profile has searches dealing with many of the issues that come up with coordinate searches that may be more appropriate. Manojlovich and Bailey will work on a recommendation.

Goldner asked for a clarification on Searching by Language, whether the code list was Marc 21 or ISO. Since the records are Marc21, it was decided to leave it as is.

Dixson added a couple of small corrections. BL2.1 and BL2.2 should have Position specified as “3" for keyword.

Moen described what Texas has done in the area of expanding the subject and classification searching to specific subject and/or classification schemes and questioned whether any such searches would be appropriate in a National Profile. Texas introduced “optionality” because it was determined that different libraries use different controlled vocabulary schemes while some don’t really use any specific one. Randall suggested that these things don’t readily fall into Levels, where each level “inherits” the capabilities of the previous Level. MARC21 defines a number of controlled vocabularies based on indicator and/or subfield 2 values. A set of subject and classification searches will be defined, but will wait for an analysis by Dixson of what controlled vocabularies are identified in MARC 21.

Several times during Day 1, the discussion turned to the issue of Compliance. It was determined that Compliance is determined by what capabilities a given vendor has enabled a system to do. The library who purchases and implements the system may make choices that inhibit interoperability, regardless of whether a system is certified as compliant. Choices of indexing and mapping of attributes to indexes greatly affect the interoperability with other compliant systems.

Moen suggested that we have a number of pattern searches for “subject" (keyword, first words in field, etc) with the capability to assign different use attributes to different subject searches. Dixson will help Moen identify the controlled vocabularies referenced in the MARC 21 record. This will become the bases for specifying the searches.

There was much discussion about classification searches. It was decided there was not enough support to include these searches in a National Profile in Functional Area A.

Manojlovich stated that SCAN is very useful for searching a single catalog, but there is no easy mechanism to merge SCAN results from multiple catalogs. The Bath profile defines SCAN capabilities as part of Level 1.

Goldner brought up the Title, Subject, and Any keyword scans, asking if any vendor can really do this. DRA does it as part of their native system, but don’t know if they do that with Z39.50. OCLC said that SCAN isn’t really used very much. For vendors, Level 1 isn’t a big thing until SCAN is introduced. For other vendors, SCAN of keywords may be a big thing to have to develop to maintain compliance. Both Denenberg and Needleman brought up the problem with the semantics of SCAN for ANY keywords. The semantics need to be to be clarified as to what ANY means, especially for Scan.

There was considerable discussion about the end-user need for Keyword Scans. Moen cautioned the group about deviating from the Bath Profile as the core for the National profile, since it would be easier to keep deviating as we went on once we made a break. Moen suggested that an alternative would be to go back to the Bath folks asking what the reasoning was in requiring Keyword Scans in Level 1 and whether they would consider putting those Scans in Level 2. Moen asked that vendors and other user groups put their objections to or support of Keyword Scans on the Bath lists and he would enter a defect report on the Bath web site.

Moen asked if there are any other types of searches to consider for a National Profile. The following were identified:

Other items for discussion might be the Proximity operator. Randall will write up something on the need for this type of operator.

Moen said he would summarize the searches discussed and preliminarily agreed to. He would work with Riding who had been developing the list during Day 1. The summary would be ready for Day 2.

Williams pointed out that the Bath Profile specifies that a Z-Client needs to support “one or more” record syntaxes. Moen answered that the statement was a general statement about Z-clients but the profile specified additional syntaxes as specified in the conformance statement. Moen will ask the Bath maintenance agency to clarify the statement at the beginning of 4.3.3.

The National profile will specify that MARC21 will be required for both clients and servers. UNIMARC will be optional except for Level 1 Clients which must support both.

Iddings questioned the need to specify SUTRS in the National profile as a requirement. Goldner added that the client needs to be robust, but the server should only have to support those syntaxes that it needs to meet its business need. If it didn’t need to use SUTRS, why require it? Lunau answered that in order to support Cross Domain searching in Functional Area C, a non-MARC syntax needs to be supported. It also gives servers the capability to ship out non-MARC records when they don’t really want to ship out the entire MARC record, for whatever reason. COPAC, for instance, will not send out MARC records to just anyone. Lunau pointed out that when the question of dropping the XML requirement was raised on the list, many responses supported the need to keep XML in the profile. Peterson added that she supported the XML requirement, but really only wanted it required on the client. Both Williams and Needleman expressed the opinion that more and more information in libraries is becoming available in XML and having the servers being able to output XML would make our library information available to non-library clients. Moen suggested that we should accept Bath as is in regards to the SUTRS and XML requirements, but suggest to Bath that SUTRS and XML should not be required for servers.

The Bath Profile requires the ISO Latin-1 character set for Level 0 searching and the ASCII character set or the character set defined for use with the record syntax for Level 0 retrieval. Level 1 requires both the clients and the servers to recognize Character Set and Language Negotiation. This in effect requires more at Level 0 than Level 1 since clients and servers must support any and all character sets associated with a particular record syntax. This is an issue that needs to be taken up with the Bath Profile group.

Moen announced that there may be a special ZIG meeting in the late May timeframe in Washington, specifically devoted to looking to how to move Z39.50 to the next level, anticipating that the current review will reaffirm the current standard. Lunau and Manojlovich suggested that given the number of critical concerns the Committee had with some Bath Profile specifications, it might be worth trying to schedule a joint meeting between Bath Profile group members and members of SC AV. Moen asked if members of this committee could attend to express concerns and have discussions to resolve some of the concerns we have raised at this meeting.

[Chair's note: After discussions with Pat Harris and Ray Denenberg, it seems unlikely that there will be a May ZIG meeting. In further discussions with Lunau, Moen will contact the key Bath Profile Group members about specific issues to gain a better understanding of why certain specifications are in the Bath Profile. He will work with Lunau to try to resolve some of these issues via a teleconference with Bath Profile Group members and SC AV members.]

Randall asked if there was a DTD for encoding MARC records with XML. Needleman and others responded that there were multiple DTDs and/or schemas. Moen asked if we as a group could try to identify and standardize on one DTD or schema. If LC had one to recommend, it would make sense to standardize on that DTD. LC is working to identify which one they would use. LC would assign OIDs for the DTDs as Z39.50 schemas which could be assigned element set names if the number of DTDs was small enough. Moen asked if Needleman, Denenberg, and Dixson would be available to consult on this issue.

The current requirements for Bath Level 1 are support of the Holdings Attribute Set and Holdings Schema using two element sets: “B-1: Locations Only” and “B-2: Locations and Summary Information”. Level 0 conformance is “whatever you do now is conformant”. Bath has not addressed the Searching of holdings at all. Wilson asked what the urgency of finalizing this requirement is given that Bath hasn’t finished working on this requirement. Moen answered that there is a requirement that the National profile contain some method of a simple holdings retrieval.

There was a lot of discussion about the boundary between the Holdings Schema and NCIP. Bailey suggested that enough information needs to be passed in Z39.50 so that the retrieval-only applications (what the user needs to see and what the machine needs to have to take some action) aren’t crippled by lack of information. NCIP can be used for those applications that need to take automatic actions depending on the data retrieved.

Call number was also an issue. The call number retrieved by B-2 only represents the call number for the bibliographic item as reported to a union catalog. That would be problematic for those institutions or consortiums that had multiple physical locations or multiple classification schemes.

Davidson proposed that we follow Bath through Level 1 and add status and item information to Level 2. Moen will further develop this area in the next draft.

The Committed noted that Functional Area B, Level 0 doesn't provide any improvement in interoperability. To maintain parallelism with other Functional Areas, it was suggested that the Bath Profile Level 0 as it currently stands be removed, and what is now Level 1 becomes Level 0. Moen will take this to the Bath Profile Group.

Meyer proposed that we should begin specifying some searches against holdings information. She suggested::

Denenberg outlined what the model of retrieving “limited” holdings would be within the Z39.50 world. After a Z39.50 search had been done, a retrieval of specific holdings would be specified by using “e-spec-q” to limit the number of holdings retrieved. Another method would be to do the Z39.50 search with limitations based on institution, location, availability, etc (using the appropriate attributes), and then retrieve the results (the expectation would be that only the “limited” holdings would be retrieved, but without something specified in the profile outlining these expectations, the holdings may be more than just the limited holdings requested). In order to get both the bibliographic and holdings information together in one search, the database name must represent the “holdings database” and the result will be an XML structure. Within the XML structure is either the “actualBibItem” (for B-1) or a “targetItemId” (for B-2 and above). It is undetermined what the format of the “actualBibItem” would be -- XML or some form of MARC.

St. Pierre raised the question of efficiency in getting bib records and holdings, doing it in one round trip rather than several. While this may be an implementation issue, it's important to know if profile specifications will force certain, less-than-optimal/efficient transactions.

There was a suggestion to look at SCAN for Call Numbers as well. SCAN would provide the ordered list of Call Numbers (without Records) while a Call Number Search would provide a set of records (but not necessarily in Call Number order unless SORT was implemented).

Meyer also added that at some point, she would want a call number search that would indicate the classification scheme. Meyer also added that we would probably want to leave Level 0 and 1 as Bath has specified, and that since we have put the “circulation stuff” of the holdings retrieval in Level 2, we should probably put these searches in Level 2 also.

Moen suggested that Meyer and Moen work together to work out scenarios of use, models, and possible solutions. Randall asked about how this group will be synchronizing with the Bath group, since they haven’t dealt with Holdings Searching yet. Lunau said that the Bath group had asked some people (including Peterson and herself) to work on this issue.

The functional requirement is that users want to have sorted results sets. Sorting is also useful in being able to merge and de-dup results sets from multiple databases.

Useful sorts would be Title, Author, Date of Publication, ISBN, ISSN, LCCN, and Date Record Added to Database.

SORT would probably be a Level 2 service within Functional Area A. To keep this requirement from being too limiting, we may want to limit SORT compliance to Primary Sort Key only, Ascending or Descending, maximum threshold for sorting. Randall made the point that SORT is more of an optimization than a searching requirement and may be considered an onerous requirement on vendors. As such, it may want to be above Level 2 or added as something extra, like a Functional Unit (or a “thingy” or “ding dong unit”).

Moen distributed a “Basic Structure for NISO Standards”. Unfortunately, the outline omitted the standard itself (oops...). Needleman stated that the Forward tended to be the place where a lot of the justification of why decisions were made was placed. Denenberg pointed out that the material in the 1992 Z39.50 document was the object of most of the comments (and negative votes) in that standard, and that in 1996 he omitted the forward when it went out to vote and put it back in after the standard was approved. Denenberg also recommended that non-normative appendices shouldn’t be included until after the balloting is finished for similar reasons.

Moen will be asking the group for terms that need to be defined. Denenberg also suggested that a “model” section also be included. Moen responded that there is a need for a model in the Z39.50 document, but questioned the usefulness of such a model in a profile document.

Johnson added that we have talked in the group about conformance of the software and the need for conformance of how the libraries set up the software. The profile needs to explain the implications of what the libraries have responsibilities for. There was agreement that the conformance statement be positive, in the sense of what can be accomplished by conformance. Pattie suggested we need to articulate a hierarchy that affects conformance and interoperability:

Needleman suggested that we add something about “maintenance” of the profile -- how it can corrected and amended. Denenberg suggested that since this is a first NISO profile, we may want a section on its relationship to standards, IRPs, and other groups.

Moen asked how members of the group want to contribute to the writing of various sections. The chair doesn’t desire to write all of the narrative of the profile.

Moen distributed a Summary of Searching Requirements for Functional Area A. He also distributed “General Principles”: talking about Conformance, Capability vs. Availability, and Data. Moen requested that members post to the listserv, by early next week, any problems with either of the two documents. Moen will post on note on the listserv as a reminder.

Any indexing recommendations in the profile would probably be included as an appendix. They should be a (minimum or precise) list of fields and subfields in specific indexes (pretty wide disagreement on this). There should be a correlation between searches and indexing. Pattie stated that the relationship between capabilities specified in the profile, availability of the data, and indexing needs to be spelled out as part of the profile. Wilson added the need to address normalization of data.

Several members indicated that a local system might have separate indexes for local users and separate indexes for Z39.50 access. Putting it in these terms might make the indexing issue less of a flash point. Moen raised the question whether there is something to be gained by having common indexes for the Profile defined searches for both local and Z39.50 access.

Randall suggested that she didn’t mind working on Indexing Practices but the group is probably not the right group to do it. Reference and Technical Services librarians need to be added into this discussion. Meyer added that developing indexing specifications is a “big” job, that it might be too big to deal within the timeframe we have. Iddings stated that if we decide to put indexing recommendations in the profile, that we shouldn’t put it in until after the ballot. Indexing may be the most inflammatory part of the profile. Davidson stated that we may want to at least wait until after the testbed, since that may identify many more real issues than we can envision now. Williams agreed that putting indexing specifications in the profile would draw more fire than we wish to have and suggested that we put indexing “guidelines” in the standard after the ballot.

Lunau stated that there will be a non-normative indexing appendix in the Bath Profile. It was derived from part of the work done by the Z-Texas group on indexing to support the Bath Searches.

Moen summarized that we need indexes to support the searches specified in the profile. There are two ways to develop the indexes: specify the minimum fields and subfields in each index, or specify the precise fields and subfields in each index. Moen asked Pattie to work with him in developing a few indexes and share them at the next meeting to get vendors’ reactions to this. Moen would like the vendors that are willing to send him their indexing for the pertinent indexes.

It will be held at the Marriott at the Dallas Airport on April 2-3, 2001. Moen will be sending out a note in the next couple of weeks to confirm rooms. Indexing will be a major discussion item at that meeting. Moen will also pursue a joint meeting between some members of this group and some members of the Bath group to resolve some of the issues we have raised. He will also work with Ray on finalizing the special ZIG meeting.

1. SCAN: Justification, need, utility, and scenarios of use for the Keyword scans, including title, author, subject, and any scans. Reduce the number of Scans required.

2. Record Syntaxes: Justification for servers having to support (in Functional Area A) non-MARC record syntaxes. Ask for reasoning for the retrieval requirements for Level 0 Service for non-MARC syntaxes. Suggest that only clients must support SUTRS or XML at Level 0.

3. Standard ID Search: BL1.13 Standard ID search should clearly state that it is the server's choice for which IDs are indexed

4. Structure Attribute 101: Normalized name attribute was put in for personal names, not corporate names. Does it make sense for using this in the Level 0 search for author where it is a corporate name, conference name?

5. Need to get OID for profiles and then be able to assign OIDs for component parts (e.g., Functional Area A, Level 0 gets its own OID in the class of OIDs for the Profile.

6. Character Set Negotiation: Justification for character set negotiation in Level 1. Level 0 seems more strict than Level 1 in supporting character sets

7. XML DTD for MARC records: Is there a need for separate DTDs for MARC21 and UNIMARC? Check to see what work has been done on identifying an XML DTD for MARC.

8. Balancing Levels across Functional Areas -- specifically, Levels 0 and 1 in Functional Area A and B. Should the Levels be parallel? Specifically, revising Functional Area B, Level 0 to include current Level 1 specifications.

9. Section 4.3.3. on record syntaxes: Clarify wording to indicate that at least two record syntax may need to be supported.

The following list reflects agreements of SC AV based on discussions at its first meeting.

1. Numbering and Ordering of Searches: Committee members agreed that all similar searches be listed together, whether they were Bath or US National searches (e.g., all author searches together), rather than listing the Bath searches and then the US searches.

2. Capability versus Visibility for Compliance: Committee members are in general agreement that for compliance, a client or server must be capable of all the specifications listed in the profile for a specific level of conformance. However, the business case of the particular library may mean that it does not make visible to all users the functionality. The vendor's product would be compliant if it is capable, but an individual library who does not make all the functionality available could not claim conformance at a specific level.

3. Functional Area A, Level 0 Searching: The Committee agreed that the following are Level 0 searches for the US National Profile:

4. MARC 21 Record Syntax Required: The Committee agreed that the specifications should require MARC 21 for both clients and servers at Level 0 and Level 1. UNIMARC remains optional at Level 0 for clients and servers, and Level 1 for servers. It is required by clients at Level 1.

1. Request Bath Profile clarify the language in Section 4.3.3. regarding clients and servers needing to support “one or more” record syntaxes. Both clients and servers must "support two or more syntaxes." Completed.

2. Post to the listserv the General Principles for Conformance document for review by the Committee.

3. Request from vendor reps on the Committee the indexing policies for their systems.

Dixson: Develop some examples for Author Search (Level 0) for corporate authors and conference names.
Dixson: Develop additional examples for corporate names, unanchored, and truncated for Level 1 searches.
Dixson & Moen: Identify the list of controlled vocabularies referenced in the MARC 21 records (6XX fields)
Dixson, Meyer, Wilson: Develop a list of the values to be used in the Format/Type Search. Check on values available in the Leader 06-07, field 006/007, and the GMD.
Manojlovich & Bailey: Develop the requirements for geospatial searches. Suggest possible attribute type/value combinations for the searches.
Meyer & Moen: Develop scenarios for searching against holdings information to understand the requirements prior to specifying the searches.
Needleman, Denenberg & Dixson: Identify and suggest possible XML DTD (and/or Schemas) for use with MARC record interchange.
Pattie & Moen: Work on specific searches and the recommended indexing for each search.
Randall: Write up the search scenarios to identify requirement for proximity operator search.

[This document was prepared by Moen based on discussions on Day 1 and circulated on Day 2. The Committee has agreed only on Level 0 searches. Final agreement for all searches will await the April meeting.]

BL0.1    Author Search — Precision Match for Established Name Heading
US0.1    Author Search — Keyword
BL0.2    Title Search — Keyword
BL0.3    Subject Search — Keyword
BL0.4    Any Search — Keyword

BL1.1     Author Search — Precision Match for Established Name Heading with Right Truncation
BL1.2     Author Search — Keyword [NOTE: Defined as US Level 0 Search]
BL1.3     Author Search — Keyword with Right Truncation
BL1.4     Author Search — Exact Match
US1.1     Author Search — First Characters in Field (Left-Anchored with Right Truncation)
BL1.5     Title Search — Keyword with Right Truncation
BL1.6     Title Search — Exact Match
BL1.7     Title Search — First Words in Field
BL1.8     Title Search — First Characters in Field
BL1.9     Subject Search — Keyword with Right Truncation
BL1.10   Subject Search — Exact Match
BL1.11   Subject Search — First Words in Field
BL1.12   Subject Search — First Characters in Field
BL1.13   Any Search — Keyword with Right Truncation
BL1.14   Standard Identifier Search
US1.2    ISBN Search
US1.3    ISSN Search
US1.4    Remote System Record Number
BL1.15   Date of Publication Search
US1.5    Format/Type Materials Search -- Keyword [Tentative]
US1.6    Format/Type Materials Search -- Phrase [Tentative]
US1.7    Language Search

BL2.1    Key Title Search - Keyword
BL2.2    Key Title Search - Keyword with Right Truncation
BL2.3    Key Title Search - Exact Match
BL2.4    Key Title Search - First Word in Field
BL2.5    Key Title Search - First Characters in Field
US2.10 Uniform Title Search — Keyword
US2.11 Uniform Title Search — First Characters in Field
US2.12 Series Title Search — Keyword
US2.13 Series Title Search — First Characters in Field
BL2.6    Format/Type of Material Search - Keyword [NOTE: Defined as US Level 1 Search]
BL2.7    Format/Type of Material Search - Phrase [NOTE: Defined as US Level 1 Search]
BL2.8    Language Search [NOTE: Defined as US Level 1 Search]
BL2.9    Date of Publication Range Search
US2.1    LCCN Search
US2.2    OCLC Search
US2.3    Music Number (not ISMN) Search
US2.4    Technical Report Number Search
US2.5    State Government Document Number Search
US2.6    DOI/URN Search
US2.7    Notes Search — Keyword
US2.8    Notes Search — Keyword with Right Truncation
US2.9    Publisher Name Search — First Characters in Field
US2.14 Personal Author Search — Keyword
US2.15 Personal Author Search — Keyword with Right Truncation
US2.16 Personal Author Search — Exact Match
US2.17 Personal Author Search — First Characters in Field (Left-Anchored with Right Truncation)
US2.18 Corporate Author Search — Keyword
US2.19 Corporate Author Search — Keyword with Right Truncation
US2.20 Corporate Author Search — Exact Match
US2.21 Corporate Author Search — First Characters in Field (Left-Anchored with Right Truncation)
US2.22 Conference Author Search — Keyword
US2.23 Conference Author Search — Keyword with Right Truncation
US2.24 Conference Author Search — Exact Match
US2.25 Conference Author Search — First Characters in Field (Left-Anchored with Right Truncation)

Level	Client	Server
Level 0	MARC21 or UNIMARC SUTRS XML	UNIMARC or MARC21 SUTRS or XML
Level 1	MARC21 UNIMARC SUTRS XML	Same as Level 0

Affiliation	Name	Present
UNT/SLIS	William E. Moen, Chair	X
Data Research Associates, Inc.	Mark Needleman, NISO SDC Liaison to SC AV	X

AMIGOS Library Services	Chris Peterson	X (Day 2 only)
Blue Angel Technologies	Margaret St. Pierre	X
California State Library	Ira Bray	X
CIC, Penn State University	Eric Ferrin	X
Colorado State Library	Brenda Bailey	X
Epixtech	Ed Riding	X
Follett	Michael Johnson	X
Fretwell-Downing USA	Matthew Goldner	X
GALILEO, Georgia	Phil Williams	X
Innovative Interfaces	Laurie Davidson	X
Kentucky Commonwealth Virtual Library	Miko Pattie	X
Library of Congress	Larry Dixson	X
MINITEX	Christina Perkins Meyer	X
Bath Profile Maintenance Agency	Carrol Lunau	X
OCLC	Dana Dietz	X
PALCI	Dan Iddings	X
SIRSI	Slavko Manojlovich	X
The Library Corporation (TLC)	Mark Wilson	X
University of Illinois	Sara Randall	X

Observers
Z39.50 Maintenance Agency	Ray Denenberg

Level 1	Level 2
ISBN	LCCN
ISSN	OCLC
Remote System Number	Music Publisher Number
	Technical Report Number