From: Denise Troll Z39.50 Implementors Group Meeting Minutes 4-25-95 ******************************************************* 1. MINUTES - DT drafted to do minutes again. (If MH had pushed a little harder, LW would have succumbed to the pressure, but instead a compromise was reached: LW would take notes on his computer and DT would take manuscript notes; DT would then use all this data to reconstruct the meeting. Hence these minutes are brought to you by two worker bees. Although somehow the computer notes from day one disappeared so today's minutes are constructed from DT's manuscript alone.) ******************************************************* 2. AGENDA. The meeting convened in a large, comfortable, mauve room. MH asked for additions or changes to the agenda. Announced STAS Interest Group meeting today at 5:00. ******************************************************* 3. INTRODUCTIONS AND STATUS REPORTS Editorial aside: Shortly before the meeting began RD (or was it MH?) commented to me privately that the only complaint received about the recent (my) ZIG minutes was that they included only a list of attendees, not status reports for each implementor. I was encouraged to do a better job on this. What follows is my attempt to comply. I'm not sure I succeeded. The speed of delivery always makes capturing the status reports difficult (for me anyway), but the acoustics of the room (microphones were ordered for subsequent days of the meeting) and the soft-spoken, often heavy accents, and unfamiliar names of the non-American participants at this meeting made it even more difficult. People introduced themselves and gave updates on their Z39.50 work. Here's what I managed to capture of what was said. Forgive the spelling errors and omissions. I've organized the information in two major groups: first an alphabetical list of American organizations and institutions; second a list of non-American groups organized alphabetically by country (to the best of my ability). People whom I couldn't place in one of these groups appear at the end under an "Other" heading. (This organization was simply a way to satisfy my personal curiosity about the range of participation at this unusual ZIG.) SUMMARY OF ATTENDEES: Australia Participants: 1 Canada Participants: 2 Denmark Participants: 8 England Participants: 5 Finland Participants: 1 Germany Participants: 8 Ireland Participants: 1 Israel Participants: 1 Italy Participants: 2 Netherlands Participants: 3 Norway Participants: 3 Spain Participants: 1 Sweden Participants: 2 Switz. Participants: 2 _______________________________ Non-U.S: Participants: 40 Countries: 14 U.S: Participants: 33* Groups: 23 "Other" Participants: 3 Groups: 3 _______________________________ TOTAL Participants: 76 * In comparison with the previous ZIG (January, California), 35 U.S. participants did NOT make it to the April, Amsterdam ZIG. *** U.S. ORGANIZATIONS *** AMERITECH Graubart-Ceroone, Jeff (Ameritech), graubart@notis.com - Continuing development of a suite of products: WinPAC (GUI), TermPAC, Infoshare server, and Net Publisher. All have hooks to holdings and V3 scan. Running GILS servers. Implementing universal access to handle arbitrary record formats. Investigating Unicode. Randall, Sara (Ameritech), srandall@notis.com - Testing HTTP to Z39.50 gateway for release in the next few months. AT&T Waldstein, Bob (AT&T Library Network), wald@library.att.com - Z39.50 V3 server in production. CARNEGIE MELLON & SIRSI Dousti, Parviz (Computing Services, Carnegie Mellon University), dousti@cmu.edu - Working on stateful gateway (written in C++) called "WITZ" (WWW Interface To Z39.50). Z39.50 code from CNIDR. Project complete, but not stable or fully functional; out of funding. Want someone to take it and continue development. Troll, Denise (University Libraries, Carnegie Mellon University and Sirsi Corporation), troll+@andrew.cmu.edu - Working on Z39.50 V2 / 3 client and server. CD PLUS Giltner, Keith (CD Plus), keithg@cdplus.com Gursky, Mike (CD Plus), mgursky@cdplus.com - Database vendor and online search service. Z39.50 release planned for Summer 1995. CHEMICAL ABSTRACTS Wibberly, Les (CAS), les.wibb@cas.org - Recently shipped first commercial product called SCIFINDER. Working with German Library Project on a Z39.50 server. CNIDR Gamiel, Kevin (CNIDR), kevin.gamiel@cnidr.org - Continuing development of their Z39.50 product. Implementing gateways to email and the WWW. KG is chair of project interested in issues related to HTTP, character sets, and the integration of Z39.50 with document delivery and advanced reservations (e.g., reading room) services. Nassan, Nassih (CNIDR), nrn@cnidr.org CONQUEST SOFTWARE Blair, George (Conquest Software Inc.), gblair@cq.com - Building advanced search engine. Using WAIS client and server and a WWW browser. Working with Global Change Project (?). DIALOG Loy, David (Knight-Ridder Info), loy@dnt.dialog.com - Implementing Z39.50 V3. DRA Donelan, Sean (Data Research), sean@dra.com - Running Z39.50 V2 client and server. Windows client called DRA Find. Adding multimedia, e.g., sound and video. DRA purchased several automation vendors. Also a database vendor. LIBRARY OF CONGRESS Denenberg, Ray (Library of Congress), ray@rden.loc.gov Orlik, Ralph (Library of Congress), orlik@mail.loc.gov - Mainframe clients and servers running Z39.50 V2. Local databases handled with OCLC's Site Search. Plans to integrate Z39.50 into staff workstations and upgrade to V3 server to link text and images. Adding maps and other formats of information. LEXIS-NEXIS (ELSEVIER) Ryall, Peter (Lexis-Nexis), peterr@lexis-nexis.com - Working internationally to help Elsevier Science Publishers put resources online, i.e., doing Z39.50 work for Elsevier. Currently in production: a current awareness product that delivers information to re-distributors through a Z39.50 gateway to the WWW. Also building search forms to do form-based querying. MIT Cattey, Bill (MIT), wdc@mit.edu - Using and evolving Z39.50 client and server in collaboration with University of Washington (Willow). Implementing GEAC Advanced. Also run Site Search databases and First Search services to other databases. Production use of RLG's Avery (spelling?) index. Working on interoperability. OCLC Levan, Ralph (OCLC), rrl@oclc.org - Continuing development of Z39.50 First Search and Site Search. Gateway HTTP to Z39.50 will be in production in 1995. The API will be public domain. RLG Davison, Wayne (RLG), cc.wed@rlg.stanford.edu Fuchs, Richard (RLG), rbf@wally.stanford.edu - Running Z39.50 V2 client and server. Stovel, Lennie (RLG), bl.mds@rlg.stanford.edu - Running Z39.50 V2 server. Changes are being tested for MIT and the Library of Congress. Please test your client against their server. RLG has a mailing list about their server. Beginning to look at V3 and adding clients. Also investigating gateway project and SGML finding aids. TALIESIN Soffer, Stuart (Taliesin Software Research), soffer@acm.org - Working on Win 32 (?) and NT 95-96. ZEST (stateful Z39.50 Enhanced Server Tecnology) being tested by vendor; has API to interface with different database engines. TRW Lynch, Denis (TRW BIS), dml@bis.trw.com - Shipping their software (still un-named) in two months. Includes Z39.50 client, simple server and Explain services. UNIVERSITY OF CALIFORNIA Lynch, Clifford (Univ. of CA), clifford.lynch@ucop.edu - Production system access 14 remote Z39.50 databases. Involved in CIMI (Computer Interchange of Museum Information) project. Needleman, Mark (Univ. of CA), mark.needleman@ucop.edu - Linking circulation data as part of OPAC display. Handle 100,000 Z39.50 queries daily. Implementing Z39.50 gateway to the WWW. Tibbetts, Marjorie (Univ. of CA), margery.tibbetts@ucop.edu - Running Z39.50 V2 server; upgrading to production quality. Running V2 client with RLG databases and TULIP data. Van Petersen, Gerda (University of California), gerda.vanpetersen@ucop.edu UNIVERSITY OF FLORIDA Hinnebusch, Mark (FCLA), mark@mark.fcla.ufl.edu - Running Z39.50 V2 servers on an IBM mainframe, UNI and OS2. The client is built into the mainframe. Just completed Z39.50 gateway to HTTP. Member with IBM in Competency (?) Center to transport images and compound documents, e.g., journal articles and maps. UNIVERSITY OF MICHIGAN Prettyman, Tim (University of Michigan), timothy@umich.edu - Integrating Z39.50 (?). UNIVERSITY OF PENNSYLVANIA Newman, Lee (Penn State University), ewn@psulias.psu.edu - Running Z39.50 client and server. USPTO Mazur, Mojmir (United States Patent and Trademark Office), mazur@uspto.gov- Working on Global Project with TRW and CAS. WEST PUBLISHING Turtle, Howard (West Publishing), turtle@research.westlaw.com Van Dam, Dennis (West Publishing), dvandam@research.westlaw.com *** ATTENDEES from OUTSIDE of the U.S. *** AUSTRALIA Gatenby, Janifer (Stowe Computing, Australia), allen@stowe.e-mail.com CANADA Turner, Fay (National Library of Canada), fay.turner@nlc-bnc.ca - Project to investigate the impact of Z39.50 V2 on services such as retrieval, ILL, acquisitions, billing. Looking for Z39.50 client while working on gateway. Plans are to make client/target toolkit software available. Zeeman, Joe (Software Kinetics Ltd), zeeman@sofkin.ca - Running Z39.50 in Amacus (?). Integrates access to two search engines: a full text engine and a relational database engine. Host-based and Windows clients available now. Client gateway available in the future. DENMARK Dickmeiss, Adam (Index Data), adam@index.ping.dk - Falloz, Frank (Technology Knowledge Center), ff@drv.dk - Email server. Hammer, Sebastian (Index Data), quinn@index.ping.dk - Technology Knowledge Center, Denmark. Developing a toolkit for Z39.50 and HTTP. Free public release planned for 1-2 months from now. Providing email access to Z39.50 (?). Jorgensen, Poul Henrik (Danish Library Center), phj@find2.denet.dk Meulengracht, Hans (Danish Library Center), hmm@find2.denet.dk - Running SR. New project to implement ILL network in Denmark. Pedersen, Gordon (CEC Libraries Program), cpe@f-and-l.dk - Sandfaer, Mogens (Technology Knowledge Center), ms@dtv.dk - Implementing gateway project with many partners, e.g., University College in Dublin and Technology Knowledge Center. Working to bridge gap between ISO and TCP/IP implementations. Providing access to both using email. Running gopher and HTTP servers. Software is in the public domain. (?), Peter (Technology Knowledge Center), nwh@dtv.dk - Europagate. ENGLAND Comer, Kevin (Silverplatter, London), kevinco@london.silverplatter.com - Building Z39.50 gateway. Actively recruiting implementors. Working on German Library Project to interconnect information retrieval centers with German catalog and bibliographic systems. Phase 1: Z39.50 V3, including Item Order, with API; will also support SR. Phase 2: ILL protocol. To be tested late 1995. Kemp, Bob (SLA Information Systems - described as "like DRA, only multilingual"), kemp_r@sls.co.uk - Developer for academic libraries. Running Z39.50 V2 server with 9-million record database. SLA sells records. Their challenge is to get commercial clients to interoperate with their server. Moulton, Ruth (Consultant, British Library, London), ruth@muswell.demon.co.uk Smith, Nek (British Library), nek.smith@bl.uk Wheatley, Mike (British Library), mike.wheatley@bl-uk - Working on an OPAC network project in Europe. And the Cobra Chase (?) project to develop public domain software to convert to UNICODE and back; the project began in February and runs for 16 months. FINLAND Hakala, Juha (Helsinki University Library, Finland), juha.hakala@helsink.fl - Developing union catalog for public and research libraries. Cooperate with VTLS and other partners in ? project. Maintain an archive of Z39.50 materials, including public domain software: ftp funetfi pub/doc/library/z3950 GERMANY Gottswinter, Edith (University Library Karlsruhe), edith@ubka.uni-karlsruhe.de - Implemented SR. Plans are to do Z39.50. Herjek (?), Bernd (Danet Gmblt ?), herjek@danet-pmbh.danet.d400.de ? Kappus, Harold (DV Consulting HK), kappus@fiz-karlsruhe.de - German Library Project. Developing Z39.50 client and gateway from STN. Luchner, Bernd (Die Deutsche Bibliothek), luchner@dbf.uni.frankfurt.d400.de (?) - Technical Manager of German Library Project. Muwrer, Moel (?) (Center Development Group for Library Systems in Baden-Wurttemberg), muwrer@ubka.uni-karlsruhe.de - Development group of local library systems (?). Implemented SR and German record syntax. Will support Z39.50 in the future. Pauiewski, Arek (Bits [software company], Germany), arek@unix01.elimeli.de (?) - Developing client and server. Rinderspacher, Jurgen (Bits [software company], Germany), bits@unix01.elimeli.de - Partner in German Library Project. Rusnak, Ute (FIZ Karlsruhe), ur@fiz-karlsruhe.de - (?) STN International and German Library Project. Building Z39.50 client, server and gateway. IRELAND Andreadis, Dimitris (University College, Dublin), dimitirs@net-cs.ucd.ie ISRAEL Spruch, Yohann (ALEPH) - Z39.50 gateway. Want to connect Israeli libraries to the world. ITALY Favaro, John (Intecs Sistemi, Italy (?)), favaro@pisa.intecs.it - European library project. Language standards (?). Troina, Giuseppe (European Space Agency), giuseppe@esciu.esa.it (?) NETHERLANDS Dekkers, Makx (PICA), dekkers@pica.nl - Since Fall 1994 have been running V2 client with RLG, RLIN and OCLC databases. (Contact PICA for an account.) Version 3 Z39.50 being implemented in German Library Project; plans include implementing Item Order late in 1995. Running a new OPAC client, OpenCat (?), to access a Site Search server of newspapers. A Windows client, WinCat (?), will be available in June 1995. Received funding to rebuild the network to handle multiple protocols, e.g., Z39.50, HTTP, and the PICA protocol. Many projects underway related to electronic document delivery, e.g., WebDoc (?). Munsteus, Connie (Silver Platter, BU, Amsterdam), conniem@silverplatter.com Van der Meer (?), Jan-Metten (PICA), meer@pica.nl - NORWAY Foshaug, Roar (BIBSYS, Norway), roar.foshaug@bibsys.no Holm, Lynn (Oslo College) - Project manager on project with many partners, e.g., in Norway, England, Denmark, Germany, Austria, Sweden and Holland. The object is to link all of the systems together using a subset of Z39.50 features, including Explain. The project started in January 1995 and will continue through June 1997. The project will develop the service infrastructure and establish interoperability both technically and in terms of human factors. Husby, Ole (BIBSYS), ole.husby@bibsys.no - (?) Currently running Nordic SR ISO software, which will be replaced in the future. Developed an HTTP to SR gateway based on Nordic SR Net. SPAIN (?) Camarero, Nesto Garcia (Sabini Library Automation), sabini@b155.eunet.es - (?) (Chairman of [?] Information Systems, Spain) - Working on OPAC interconnectivity in European OPAC project. SWEDEN Nilsson, Arne (Royal Library, Sweden), arne.nilsson@libris.kb.se Skogmar, Goran (Royal Library, Sweden), goran,skigmar@libris.kb.se - Working with Swedish academic liraries on a union catalog. The Nordic (?) project. Test server running. Also working on OPAC network project to connect European libraries. SWITZERLAND Duguay (?), Monique (ILO, Geneva), frierson@itu.ch - "Information gathering." Nesbitt, John (Consultant, Geneva), 74020.355Z@compuserve.com - Studying the feasibility of implementing a Z39.50 server. *** OTHER *** Preston, Cecilia, cpreston@info.berkeley.edu - "Observing." Ward, Nigel (Distributed Systems Technology Center), nigel@dstc.edu.au - Building a tool to do relevance judgements (?). Implementing Z39.50, including Explain. Davidson, Ed (SLS), davidson.e@osls.co.uls (?) - ******************************************************* 4. REGISTER OF IMPLEMENTORS RD described and circulated the implementors register for updates. ******************************************************* 5. STATUS OF BALLOTING All "no" votes have officially been changed to "yes" votes with NISO. One late ballot came in: "yes" with comments. RD thanked RLG and DRA for their work in resolving the problems. Z39.50 V3 approved by NISO. Next step is acceptance by ANSI. Brief discussion of what to call V3. Previously called Z39.50-1994, but NISO made typo in document and called it Z39.50-1995. RD, DL, and BC wanted typo corrected. Others thought that since V3 was officially accepted in 1995, Z39.50-1995 was the accurate name. We agreed to stick with Z39.50-1995. (Although MH wants quid pro quo with NISO :-). ******************************************************* 6. STATUS OF DOCUMENT The current Z39.50 document is the "preliminary final text." A few places are subject to change at this meeting, e.g., Explain ASN. Other changes to be made are editorial, e.g., fix typos. The final text will be issued in about a month. The NISO will publish it. Z39.50 Maintenance Agency will maintain final version. Electronic version to be discussed later. ******************************************************* 7. WALK-THROUGH What follows is a brief overview of the changes from the previous draft and the current "preliminary final text." Page v (last page of Forward) - New services and facilities: discussion amplifies that the browse facility may have additional services in the future. Page 1, section 1.3 - References: ISO 10161 added (ILL protocol). Page 4 - Definition of "Item": reference applies only to point 2. Page 8, section 3.1.7 - Heading changed to "Model" of Extended Services. Section shortened based on ballot comments. (Text removed here is added to Extended Services section of document.) Page 24, section 3.2.6.3.3 - Resource-report-status failure-2 "Operation" terminated. Page 26, section 3.2.8.1.5 - Position in the list: technical change to resolve ballot comment from GEAC (after ballot). Value of 0 clarifies semantics of 0. Remove parentheses. Page 26, section 3.2.8.1.7 - Structure of entries returned: First three bullets agreed to at last ZIG. The fourth bullet, display term, part of GEAC request. Page 27, section 3.2.9.1 - Extended Services Service: example included (moved here from earlier "Model" section). Page 30, section 3.2.9.3 - Example included (moved here from earlier "Model" section). Page 30, section 3.2.10: Explain Use Attributes: appendix ATR reference (second to last bullet). Imports all BIB-1 non-use attributes. No requirement to support all, but recommended that target support attributes. (?) Page 32, table - New: VariantSetInfo and UnitInfo. Page 34, section 3.2.10.3 - DB Info for Explain: May have Explain dataase for different servers on one server, so call it something other than Explain. List of keywords for the database -- controversial and inappropriate. Page 38, section 3.2.11.1, table - New: Reference-ID parameter. Can't do resource control during idle periods without concurrent operations. Page 45, section 3.7 - Attribute Set changed to Attribute List. Page 49, section 4.1 - Prose prior to ASN following first paragraph: text deleted (form of external). Page 58 - ASN Scan Response: Changes corresponding to changes in List Entries: Implicit added to ListEntries; ListEntries is sequence (not choice); comment added. Page 59 - Term Info definition corresponding to Scan Response and Display Term. Page 61 - Close: Reference ID comment (cross reference). Page 72, section 4.2.4 - Protocol errors: last sentence (cross reference). Page ?, section 4.4 - Entire thing is new: Conformance clause. (Worked on after last meeting.) Page 79 - End of Appendix 1: OID.7. Section on experimental objects is new. Page 82 - End of Use Attributes for BIB-1: 1036 ATS. Page 83 - ATR.2: Use Attributes 22-26 are new (Variant Set OID, Unit System, Keyword, Explain Database). Notes 4-6 are new. Comment that the first paragraph o the page may not need the second sentence under the heading about ATR1.2 BIB-1 Attribute Combinations. Maybe move this sentence to the BIB-1 doc. Controversy arose. Discussion postponed until treat BIB-1 agenda item later in meeting. If a target does not support a given attribute combination, it should fail the search and supply an appropriate diagnostic. page 84 - Table A3-8: Added Explain Use Attributes VariantSetInfo and UnitInfo. Table A3-9: New table. Page 85 - Err.1: Last paragraph of prose is new (what to do if AddInfo is Object ID). AddInfo is visible string. Removed Column Type from table. Page 87 - New diagnostics 232-241. Will continue to add diagnostics. Page 89 - Attribute Type 1004: Term is optional. Type 1005: AttrCombo changed to attCombo (?). Page 90 - Attribute Type 1008 Scan: added 5-7 diagnostics. Type 1012: Access control changed words. Type 1013: Record syntax diagnostic. Page 92 - GRS-1 in object register. Lots of Explain changes. Skipped during walk-through. Page 108 - GRS Rec.5 comments delete about metaData and appliedVariant. Discussion of case sensitivity when expressing currency and use of the hyphen in "z39-50." Preference is case insensitivity (normative) for database names; case sensitivity for element set names and full / brief records. (See page 45.) Page 113 - Resource Report format.2. Comment added to value at MD request. Page 120 - Ext 1.4: Requested Item restructured and clarified. Page 125-126 - 3 comments added to OriginPartNot ? Fix brackets. Page 131-133 - ESPEC 1: Technical change during ballot resolution (default_tag_type). Renumbered elements. ******************************************************* LUNCH BREAK ******************************************************* 8. DISSEMINATION OF INFORMATION ABOUT Z39.50 This was a key issue raised at the NISO Forum in September 1994. NIST requested a series of implementation papers. Ten authors volunteered, including RL (OCLC), LW (CAS), MH (FCLA), KG (CNIDR), JZ (Software Kinetics), MD (PICA), DL ( TRW), BW (AT&T). The deadline is May 1, though some authors got extensions. Papers should be submitted as ASCII or Word Perfect files. The papers will be available as NIST monographs (sale and free copies ?) and via links to the Library of Congress WWW page. Pictures in electronic versions of the papers will be treated on a case by case basis. RD and P? of NIST will review the papers. Additional readers are needed. The "big picture": RD described a three-pronged approach to satisfying the need for information about Z39.50: 1. Implementation papers (described above). 2. Hypertext documentation, including ASN (forthcoming at http://lcweb.loc.gov/z3950/asn1.html) - send suggestions to RD 3. Technical overviews or tutorials, e.g., an issue of Library Hi Tech devoted to Z39.50. Deadline would be end of September. Send comments to RD. Must decide in 2 weeks. ******************************************************* 9. BIB.1 DOC BC mentioned a 1991 doc by Larry Dixon that clarified BIB-1 and described a 1994 effort to turn the doc into a non-normative appendix for BIB-1. Many issues remain to be sorted out, e.g., the distinction between Any and Anywhere (BW) and word list versus word list with adjacency (BC). The subgroup working on this typically argues 4-5 hours per attribute. CL asked the group to clarify what they intended to do. RD explained that he had no intention to publish the BIB.1 doc as part of V3. After some minor squabbling, at MH's request the group agreed to convene at this ZIG, on Thursday (day three). BIB.1 ATTRIBUTE COMBINATIONS Discussion resumed from walk-through, page 83, second sentence of first paragraph. Discussed not specifying bib-1 semantics, simply providing lots of syntax with no semantics. BC proposed clarifying three situations: 1. If 0 occurrences of an attribute, then ... 2. If 1 occurrence of an attribute, then ... 3. If more than 1 occurrence of an attribute, then ... MD, DL and others approved. RD proposed that the controversial sentence be cut. CL proposed that the document indicate that there is no concensus on target behavior in the absence of a profile. MH argued that target-specific behavior is not determined in any of these cases. DL characterized the cases as: 1. If 0, then the target is requested to choose appropriately 2. If 1, then do this ... 3. If more than 1, then you're either asking for trouble or you know what you're doing RD crafted a sentence. DL shot it down. RD crafted another sentence. The group agreed. CL commented that "we shouldn't be pleased with this." MH proposed that we recommend using Complex when there is more than 1 occurrence of an attribute. Some agreement, no concensus. Then JZ asked if there were objections to deprecating use of multiple occurrences of a BIB-1 attribute. RD said that we could maybe deprecate it in V4, but not V3. DL suggested that the V3 doc should just indicate that multiple occurrences are a bad idea. DL and RD agreed that multiple occurrences were a bad idea unless you use Complex and specify what you mean. RD summarized: 1. 0 means origin should not expect any particular default behavior. (Client tells target to choose.) 2. 1 means client specifies preferred target behavior, i.e., client tells target it wants X. (Target does not substitute.) 3. More than 1 means that the client makes an ambiguous statement that the target can interpret as it chooses. Recommend using Complex. RD called this a "pre-deprecation statement." CL asked: Will the Type-1 query go the same route as BIB-1? Is the mess of having no semantics for BIB-1 salvagable? Is Type 1? RD commented that if the concern is mixing attributes from different attribute sets in the same attribute combination, where are the semantics documented? If not in BIB-1, are they described in other attribute sets? LW then raised the question of whether we want to define parts of the standard in attribute sets that exist outside of the standard. JZ observed that this was incorrect; that Complex means that all attributes are from the same attribute set. WHAT ARE THE PROCEDURES FOR ADDING ATTRIBUTES TO BIB-1? Previously we agreed that people would (1) post additional attributes to the list and (2) then we would discuss them at the next ZIG. MD said he posted his attributes, but no one responded. The BIB-1 subgroup had many questions so the attributes were adopted by STAS. JZ offered a new proposal: (1) post additional attributes to the list, (2) specify an objection period in the post, (3) if no one objects, the attributes automatically become BIB-1 attributes at the end of the objection period. RD commented that he would not officially incorporate the attributes into BIB-1 until the next ZIG. LW said that we need an intellectual owner of the attributes to maintain exclusivity. RD wants no conflicts with existing attributes. LS said we need to be restrictive about the definition of an attribue included in the standard: if the target doesn't support the Attribute List, it should fail the search and return a diagnostic; note that this applies only to Attribute List, not Attribute Combination. BW and PR concerned about something (sorry, didn't catch it). MH wants to deprecate use of multiple attributes to mean Boolean "or" or "and". ******************************************************* 10. Z39.50 URLS DL posted RFC to list recommending changes in the URLs. (Check there for the syntax because, in an amazing show of stupidity or trust in LW's notes, I didn't record it in my notes! Please accept my apology.) DL wants universal characters, no blankspaces (escape them: %##). Client must turn URL into Search PDU; result of client processing URL is that server creates a result set. If the result set contains one record, the server Presents to client and Closes the session. Editorial comment: Up to this point, the ZIG meeting had been pretty sedate. People were polite and well behaved, even quiet. Unlike the two previous ZIGs I attended where "rowdy" characterized the crowd. I sat there thinking, "These people resemble the implementors I know, but they don't look or act the same," e.g., RL wore a pin-striped shirt and tie. Even with good-natured prompting from MH at the beginning of the meeting, DL did not behave "obstreperously." The rhetoric was actually kind of dull until Dennis took the floor on URLs. . . Standing by the overhead machine, using a pointer to describe his new syntax, sounding gentle but not quite unassuming, DL threw down the gauntlet. The severity of the challenge was marked by his opening words: "When DL loses an argument, it's lost forever" -- a reference to the Sept 1994 ZIG meeting where he championed a single URL in the face of growing concensus for two URLs. Naturally this kicked off a rehash of disagreements about the value of the session URL: MH commented that it was an artificial construct; DL countered that it was meaningful in nominal cases. BW needs a URL that will retrieve multiple records; DL countered that this was not the nominal case. A big debate ensued about whether the retrieval URL could return more than 1 record or document. In this exchange DL phrased what became the litany for this polite meeting: "Excuse me, may I finish my sentence?" CL simply stated the definition: a retrieval URL gets 1 record and closes the session. RL proposed that we restrict the retrieval URL to 1 record for now, but work out the semantics of multiple records later. PR claimed that we were making the whole thing too complicated; he pointed out that Web browsers bring 1 record back, but that 1 record has multiple pointers to other things. His simple solution was that multiple record retrieval be displayed in 1 HTML page. Then, as in all religious wars, the opposition found its grassroots voice and rallying principle: BW piped up: "We're making the limitations of Mosaic and Netscape drive us!" Resounding YES! With great resolve, RD put a philosophical spin on CL's definition of the retrieval URL: "the _intention_ of the fetch URL is to fetch a single document," and added that searches that result in 0 or more than 1 document be treated as error conditions. Such purity should not go unchecked, so MH counter-proposed that searches that result in more than 1 record be treated as errors, but that searches that result in 0 records simply Close the session. My notes are ambiguous about final agreement on this point. What follows are other points in my notes (marginalia) raised during this discussion. I'm not sure where they fit or why they were raised: Someone mentioned a concept I hadn't heard before: URC, Universal Resource Citation. CL clarified that the unique ID of a document is hostname + DBname + docID JG mentioned something about handling variants by Element Set Names and handling multiple variants with multiple URLs. Thus ended the first day, Amsterdam ZIG, April 1995. Minutes 4-26-95 Editorial comment: Today's minutes are a merger of LW's notes and mine. When I wasn't sure how to integrate the two, I set Les's notes apart. ******************************************************* The group reconvened early in the morning to drink coffee and watch men run wires and position speakers and microphones throughout the room. MN commented that there was enough hardware for a rock concert. MH observed (with a smile) that perhaps microphones should not be positioned in front of certain people.... We took our seats at MH's signal. RD announced that the Z register was still circulating. ******************************************************* 11. IDAUTHENTICATION ASN.1 AND COMPATIBILITY Idauthentication ASN.1 and comment on pages 50-51 deprecate ANY. When specifying ANY, you should still indicate what form it should take. Suggestion is to change open to CHOICE of InternationalString or VisibleString for compatibility with existing implementations that use VisibleString as CHOICE of ANY. RD recommended changing the comment, but not the ASN. (Changing the "preliminary final text" of the Z39.50 doc is tricky, i.e., it may be acceptable to change a comment, but not to change the ASN.1.) RL said with a smile that this was disingenuous, but OK with him. MH explained to the newcomers that that kind of response was why we took the microphone away from RL. JZ asked for clarification of the issue, so RD provided background. The issue is whether to change the ASN to match what implementors are doing, which is following a V2 implementors agreement to use VisibleString. DL disagreed with the proposal to simply change the comment and proposed instead that we change the ASN and solve the problem on the grounds that "If you introduce choices, all servers have to deal with them." Voices responded from around the room; too many words and speakers to capture. DL calmly intoned the litany: "Please, let me finish my sentence." JZ said "Why not make it VisibleString?" BW said, "Why not leave it VisibleString and comment the other choice?" MH suggested deprecating Open. RD reiterated JZ's proposal to change it to VisibleString, muttering that we shouldn't have changed it to InternationalString in the first place. The group agreed. One of the attendees from the British Library commented that since InternationalString isn't negotiated in the Init, implementations default to VisibleString. LW'S TECHNICAL NOTES: Here InternationalString is not IMPLICIT, so sending integer string is a different set of bits than a VisibleString. Some resistance, since practical situations include1992 version has Visible String. And every single server must now determine which of the CHOICES have been taken by the client (visiblestring or generalstring). Targets already exist on the net, which do not allow for the CHOICE, since you need to respond to the CHOICE. Open is only there for previous usage, and we really want implementors to move to the idPass. Perhaps change open back to VisibleString, rather than defaulting to GeneralString (since not Implicit), since it cannot be negotiated by character set. Resolution: change open back to VisibleString. The other fields will be InternationalString limited to the Visiblestring subset of GeneralString. ******************************************************* ITEM ORDER PROFILE At the January 1995 ZIG, Fay Turner proposed that we use the ILL protocol for certain parameters within Item Order, specifically the Request and Status/Error Report APDUs, to "throw [the Item Order transaction] over the wall" to the ILL protocol system. She agreed to write a profile that specifies the details of using these two APDUs. FT provided the document at the April 1995 ZIG. The profile details how Item Order would use ILL APDUs. The model defines two scenarios: 1. Use Item Order to transmit the ILL APDU to cause an ILL transaction. (later called "real ILL") 2. Use Item Order to transmit an ILL request to the target for processing in whatever manner the target has available. (later called "proxy ILL") BW asked what the distinction is and why it is important. The distinction is whether the client has the ILL protocol module or not. The issue raised was how the target knows whether the client has the ILL protocol module. The server/target needs an apriori agreement for how to respond to the transaction, e.g., return the Response APDU to what machine? RD described the problem as needing a better way to distinguish these two at the target. RD pointed out that Z39.50 ItemOrder offers more functionality than the ILL protocol, then asked for clarification of the scope of application for the two scenarios of operation of the ILL protocol. For example, if this is discussed in the OIW, what is the intended use of this profile? Scenarios and scope need to be separated. We need to profile ItemOrder to address the several EXTERNALs defined. DL asked, if another profile were written (is there another useful profile for ItemOrder?), how would an implementor be able to decide which profile to use? The scope should tell people which profile to use. Furthermore, how would you distinguish the bits on the wire? CL agreed that the two scenarios might be better served with two profiles; the problem is that requests from both scenarios look the same on the wire. Perhaps distinguish using a NULL Transaction ID, for example. It may be necessary to distinguish the two profiles dynamically. CL asked a hypothetical question about case 2 (where client is initiating proxy ILL protocol): are we passing enough information to the ILL target, so that it can get back to the original Z39.50 client? FT responded that in case 2, the ILL target never gets back to the 39.50 client -- the Z39.50 target responds that it got the request; the origin must then present the TaskPackage to find out the status. In scenario 1, there is sufficient information for the third party (supplier) to get back in touch with the user of the origin, but is there adequate information for the supplier to get back in touch with the origin? Does the ILL target have enough information to continue the ILL protocol? FT said yes, the ILL PDU contains that information. Great confusion followed, with people rewording other people's questions and people trying to clarify things they didn't understand themselves. MH invoked the litany, "Let me finish the sentence, please." At which point FT moved to the white board and drew a picture: Z39.50 ORIGIN Z39.50 TARGET ----> 1. Submit ItemOrder request (Z39.50 PDUs) -----> | | 2. Process ItemOrder request (Z39.50 PDUs) | | ILL Application (client) | ILL Application (target) REQUESTER | RESPONDER / SUPPLIER <---- 3. Process ILL request (ILL PDUs) -----> Agreed: Two profiles, one for each scenario. Profile for scenario 1 will require Requester ID and Responder ID. Profile for scenario 2 will make these optional. Did not agree: MH asked if parameters are excluded from use in this profile. JZ commented that they should be treated as externals in ILL or that they should not logically occur in these scenarios (?). So should we "exclude" or "ignore" them? Clearly we needed a break soon because RD said: "You can't completely exclude exclusion." I don't know what was decided here. Questions then arose about the future of ILL and Z39.50. ILL and Z39.50 are separate protocols now, but will they continue to be? Lots of implementors wondering about the future relationships between Z39.50 and ILL. RD said that there were no plans to integrate more of ILL into Z39.50. JZ explained that the only reason for Z39.50 to do any ILL was the convenience of connectivity. MH also mentioned the convenience of the ordinal position of an item in a result set.... ...which led to a discussion of mandatory item IDs. Does the Z39.50 client need to process a record to determine the item ID? Proposed change: for a simple ItemOrder request, the item ID is optional, but the server must create the item ID from the result set record before submitting an ILL request. CL finally asked: "Which problem are we trying to solve?" He phrased the problem: The Z39.50 target may be capable of both scenarios (real or proxy ILL), so how does the client tell the target which scenario to use? The issue then became who has the power to decide which scenario to use, the client or the server? JZ proposed that if either is possible, the target decides. MH asked why. RM said that JZ's proposal was insufficient, that the origin needs to know what the target is doing. Ray has technical nits that he'll post to the list. MD asked a question about delivery methods; he wants more delivery options, e.g., ftp. RD pointed out a flaw/change in Item Order at the top of page 126: TargetPart of item order: status OrErrorReport will be made optional. MH summarized: two profiles will be developed. Should profile be discussed at the next ZIG (September 1995) or should it go to the OIW for approval? LW recommended review at next ZIG. Agreed to post proposed profiles to the ZIG list, then discuss at the next ZIG meeting. The ASN.1 for the ILL protocol will be on the NLC server. The German Library Project will implement the profile before the next ZIG meeting. THE REMAINDER OF THIS SECTION IS FROM LW'S TECHNICAL NOTES Outside Z39.50, it would be ILL request, followed by ILL response. In Z39.50, the issue is how the ILL response comes back. Case 1 uses Z39.50 to initiate the ILL interaction, and then the rest of the ILL protocol goes on outside of Z39.50. The Z39.50 initiation allows additional information to be carried along with the ILL PDU in theItemOrder request. Case 1 only addresses use of the ILL request PDU. In scenario 2 the origin has Z39.50 only, no ILL protocol; the origin wants the target to take care of ILL for it. In the case where the ResultSet item is used, augmented by the ILL PDU. The resultset item is adequate to specify the item. Why would the ItemID be mandatory? All items are optional. Just fill in at least one. ILL PDU requires that at least one must appear. Just stick in a NULL? This is just an ILL PDU, not the protocol. The Z39.50 target populates the ILL PDU before passing it to the ILL requestor. The solution to this needs to be part of this profile. Resolution: change Item-Id from mandatory to optional. [...which led to a discussion of transaction IDs....] Need to distinguish between the two scenarios when sending the ItemOrder to the target? Use a distinguished value of the transactionid to do this? Make it a NULL in the case where the client has no ILL module? Target will know by Origin identifier whether it has ILL or not? Should we add a separate parameter in the Item Order PDU to control this? Or in the ILL PDU? Or negotiate the profile via INIT? No, this doesn't help when both profiles are supported. V3 change not requested. If origin doesn't submit an ILL PDU, then it has not initiated an ILL transaction. This is a Z39.50 profile, not an ILL profile. There are separate ILL profiles which cover what happens once the ILL transaction starts. The bytes transmitted will vary with the profile. [break] ******************************************************* 12. RFI ON TARGET IMPLEMENTATIONS FT explained that users need a more efficient mechanism than email messages and notes to find out what different targets support. She suggested using a form to store the info (until Explain is ubiquitous). The form could be based on a subset of Bill Moen's proposed data elements. FT recommended that it be the responsibility of the Z39.50 Maintenance Agency (1) to select the subset of data elements that comprise the form, (2) to update and archive the forms on a server (similar to the implementors register). Target sites would complete forms and send them to the Agency. FT would work with the Maintenance Agency to make this happen. RD accepted the responsibility for the Maintenance Agency. But, RL piped up, the problem belongs to the client supplier, not the end-user. DL agreed that users (libraries) should contact their client vendor to figure out how to configure the client to access a new target. Client providers need a place to get the info about the target. DL claimed that the info must be available via an Explain server, even if client providers don't (yet) do Explain. If the client isn't configurable, then that's a separate problem. If it is configurable, then the client provider can get the target information from an Explain server and provide it to their customers. If Explain is inadequate, then Explain should be fixed. LS responded that she has the data in another format, but doesn't have time to do Explain. But, DL protested, rather than create a new format, use Explain. LW said that something is needed right away and suggested that the Maintenance Agency should at least maintain pointers to the information. PD suggested that the Agency write CGI scripts to get the information from an Explain database and deliver it to sites in human readable form. RD mumbled that the Agency would not pay for that. BW observed that it would be too hard to develop a form based on a subset of data elements that would accommodate everyone. (If we give him BER Explain records, he will build the Explain database DL suggested.) Another alternative proposed (by LW?) was for the Maintenance Agency to provide pointers to existing documentation initially and move to what DL proposed as the long term solution. RD said that they could create a hypertext version of the register and use it as keys to point to each organization's target info. FT and RD will work on guidelines for the content of that information. (BW wants Z39.50 URL into Explain database.) RL suggested two pointers: one for Explain information, another for other database information. SD pointed out that all database vendors are not Z39.50 software vendors, so keying off of the register isn't the right starting point, i.e., it won't get all of the database information. BC described several steps that are needed: 1. People need help doing ASN for Explain. 2. We need a place to put (gather) all Explain target info. (DL and BW offered place to put the information.) 3. We need a human readable form of the Explain target info so people can configure the client. LW: But Explain doesn't capture everything that a client might want to know about a given target; the Other Info parameter is inadequate. He reiterated RL's distinction between dynamically discovered and configurable information vs. other server/database information and his suggestion that the Maintanence Agency maintain two pointers per database, one for the Explain data, the other for information that doesn't fit in Explain DL, RD and MH replied in unison: Explain is extensible! Put all of this information in Explain. MH pleaded that 230,000 users need configurable clients that dynamically discover database and target information. CL calmly retorted: "there is a big component of truth" in the claim that clients can't dynamically configure to all cases," e.g., local expansions of Extended Services, external objects, etc. RD responded that Explain "accommodates" (has info for) the end user, the developer (info for client to dynamically configure), and the system manager (general information, e.g., ASN.1 definitions). CL countered with "accommodating is different from developing a client that can dynamically adapt to everything." MD concluded that target suppliers must do Explain. He wants to provide the service, so let's define the information and implement. FT wants to provide a form for the information until Explain information service and clients exist, as an interim measure to provide information to those who need to know. MD commented that FT's suggestion (form-based target info) will help people who don't have Explain learn about targets and therefore help them do Explain. RD's plans for the register are to give each organization 5 lines plus a pointer (URL) to whatever else the implementor wants. (Some of the register entries are substantially longer than that now; RD edits.) Do we need guidelines? DL concluded that if "Faye's form" is different from Explain, then it's "absolutely disturbing, antisocial and a bunch of other things." If, however, it is not different from Explain, then it's reasonable." And because he just couldn't let it go at that, he had to add: "Either Explain is wrong or we don't need a form." RL called him a "purist." (They're just as charming as Jack Lemmon and Walter Mathau [sp?] calling one another Putz and Moron in the movie Grumpy Old Men.) MH outlined the next steps: FT will draft a form based on a subset of Explain (the critical data elements) and post it to the list. Target providers will discuss and complete the form and provide a pointer to the Maintanence Agency. (DL commented that his paper on Explain will address the critical elements that should be specified. ) PR asked whether comments on the draft form could also include observations about missing info (critical elements not covered in Explain). Answer: yes! ******************************************************* 13. SCAN BW outlined 3 topics: 1. Interoperability testing. 2. Origin controlling how much info it gets back from scan for V4 (additional scan info). 3. Profiles for scan. PROFILES FOR SCAN BC provided background: His client supports a scrollable list of terms, but when he tried to map this client functionality to Z39.50, he discovered that it was virtually impossible to do a scrollable list using Z39.50 scan. (He had local protocol for the database server, but found it difficult to get this out of implemented SCAN servers.) Several criteria needed to be profiled: 1. The target will never say that it ran out of resources searching for the next term. It will always be able to find the next term. ZIG response: Deemed impossible because you can't require the target to have enough resources. 2. Suggested new text for scan on p. 26, section 3.2.8.1.5. The comment in parentheses. Make it required, rather than preferred, that the target complies with the meanings of 0 (next term or end of list) and N+1 for position in response. 3. Fill in surrogate record for beginning and end of list. ZIG response: We want to be able to find more terms before and after this term, in a predictable way. BC's problem case was actually OCLC's target -- which just goes to show you that it is possible for the server to obey the standard and still return useless information. The diagnostic only correctly reports the problem. A profile could solve the problem. The solution is to require the target to honor the preferred position in response. If the target can't do what the client asks, it should return either (a) at least 1 term, (b) a beginning or end of list surrogate diagnostic, or (c) non-surrogate failure. Agreed. BC observed that if you get a non-surrogate failure diagnostic, you can't do a scrollable list because you don't know where the next term is. What do you do? Tell the user that it failed, and let the user choose another term. MH said this was the exception; just write your client so that it doesn't crash on the exception. This was an unresolved point of contention. Where does this go? Version 4? A profile? RD "provisionally, tentatively" agreed to put BC's point in V4 doc (linked to V3 hypertext doc). Additional interoperability issues will be discussed in the context of the testbed. 4. Optional: Return the total number of terms in the list. This request was dropped. [lunch] ******************************************************* At this point MH explained how to subscribe to the ZIG list: send to email address: listserv@nervm.nerdc.ufl.edu RD encouraged the attendees who were not from the United States to sign the register if they were implementing SR or Z39.50, as a show of support for interoperable protocols and an incentive for organizations to fund travel to an annual ZIG meeting outside of the United States. Non-U.S. attendees are welcome to attend the OIW meeting at 4:00 today; the agenda is to discuss ATS. Invitation to submit items for the agenda. OIW may only take a few minutes. If it is short, we may continue ZIG meeting. Character sets and the testbed will be discussed tomorrow morning. ******************************************************* SCAN continued... ORIGIN CONTROL OF SCAN PROCESSING BW: Why not control scan behavior by sending number of occurrences by attribute, e.g., BIB-1 Author, Title, Subject? Propose a structure to exert control. Other info could be tracked externally or allow the origin to control what comes back from scan. (See pages 59-62.) The structure should be something like: additionalScanInfo ::= sequence attributeSet attributelist Additional types of information retrievable via SCAN could also be included in the structure. BW will post structure to the list; he wants a single evolving structure that can invoke or suppress additional info. LW wants external OID maintained by RD. MH asked for further discussion on the list. ******************************************************* 14. TYPE 102 QUERY (RANKED LIST QUERY OR RLQ) Peter Ryall provided the history of the topic: Current work initiated by Chris Buckley's (Cornell) presentation on NLP or pseudo-NLP at a ZIG meeting (or TREC Conference?) a year ago. A ZIG subgroup was formed to develop a ranked query which was generally useful in searching any of the available relevance search engines. The subgroup is not trying to address all kinds of natural language techniques, but rather, to model their common characteristics in the form of a query definition. The concept has already been accepted by the ZIG. The paper PR distributed is not yet a proposal to the ZIG. Type 102 is already referenced from the standard, but this is the initial description of the model and its definition. The paper only documents what the group has agreed on. Only one operator is applied to a given set of N terms. This query type allows search systems to really distinguish themselves in terms of functionality. The goal may be to integrate it into V4, or perhaps to define it separately. This is a preliminary spec for experimental purposes. Implement it, try it out, and refine it. Working toward a spec to allow implementation. Some outstanding issues remain. Not everything is completely defined; various alternatives are identified. No agreement yet on any contents of additionalSearchInfo. So far all parms are included in the query proper, to insure that the query is self-contained during the experimental phase. Eventually, some of these may move into an additionalSearchInfo structure. Partially so that some of these features could be applied to the Type 1 query as well. There are some controversies and different possible approaches. Additional participants are invited, based on this document. PR will provide a pointer to this paper for retrieval. The paper will continue to evolve. Walked through the current draft and the fundamental components of the RLQ: Results are ranked. Certain criteria are used for ranking. May be applied by client, but not mandatory. Options can be applied to deterine how docs are ranked, e.g., hints, like weighting of terms. ZIG discussion: Is the result set order required to be in ranking order? Not an absolute requirement. Assumption is that target returns a ranked list of answers in rank order; client may request different order. Important to identify which requirements are already satisfied by type 1 RPN query. Could let client resort to the result set, if not ordered by rank. Default semantics of the query need to indicate that the result set be in descending rank order. Some systems (OCLC) have the 2-step approach (search, then sort by rank), but comfortable with saying that sort by rank is required for Type 102. MH described Type 102 as the "magical query" that will behave differently in different systems. The problem is letting the server make decisions about how to interpret requests and hints from the client, and possibly letting the server reformulate requests and hints according to its capabilities. PR conceded that the query will not have predictable results across servers; he said that there will be areas where user parameters are normalized, e.g., guidelines or requirements for "well-behaved servers." For example, different relevancy systems have different approaches to stopwords. JZ commented that one of the continuing problems over the past 5 years has been striking a balance between being helpful and doing what the user asked for. We should focus on the user. PR agreed, but said that users want (and can have) more control with Boolean than with NLP. NLP provides a range of options to help users; they may choose to use these options or not. We obviously have a need for this type of query. RL began a sentence, "We've run into trouble before..." that DL finished, "when servers did something other than what the user required." Then PR and LW discussed relevance feedback. Typical relevance feedback falls into one of these categories: 1. Get me more like this Use retrieved item as model of what to get. 2. Don't get me any more like this. Use retrieved item as model of what not to get. 3. Interact with me, i.e., offer alternatives, recommendations, to reformulate query. Queries may be reformulated or restricted. Restriction, e.g., limiting by date or language, has not yet been defined in detail. On the question of recall vs precision: some engines may be more effective than others. NLP gives control to the user -- recall or precision queries: * recallQ = expand terms, use synonyms, etc. * precisionQ = users mean what they say (e.g., only these words, not their semantic equivalents) The user is (of course) free to be wrong. The draft spec supports only 1 operator per term, and 1 operator across operands. It reuses the concept and structure of the Type 1 attributes, but defines a new set of attribute types. How does the reformulated query come back? In the search response, as a failed search, or what? Reformulated queries are returned as ASN structures in additionalSearchInfo in Search response or as surrogate diagnostic, not as failed query. RD asked why restriction component can't simply be a Type 1 query since it creates an ordinary result set? PR explained that a Type 102 result set is an ordinary result set that can be searched using Type 1 queries, but that the result set has added metadata. HT said that a Type 1 query can be a restriction clause, but it's not exclusive; he prefers that other restriction clauses also be allowed beyond Type 1 query. A type 102 query could degenerate to a type 1 query in the simplest case. Some Boolean operators may be embedded in Type 102. RD wants Type 102 to use as much of the existing standard as possible, e.g., restriction. BW: this addresses some his restriction requirements, which are harder to do in RPN query Type 1. The RLQ subgroup will discuss what is missing from the Type 1 restriction and try to determine how tp map them into the Type 1 query. Can Type 102 be used to do vector space searching? Yes. Retrieval Status Value (RSV) can accommodate vector space dimensions. (RSV is a measure of relevance of the results, not the input [not like a weighting scheme].) BW concerned about multiple terms in operand; wants syntax of Term strictly defined. RD asked if there was a need for a separate database list with restriction component for the RLQ query. Try to reuse existing functionality wherever possible, to minimize impact on the current standard. Disagreement about whether or how RLQ can accommodate Boolean operators. MH puzzled; where are Boolean operators in the ASN? PR said not documented yet. Disagreement about whether rankedAND can be turned into Boolean AND. Depending on the parameters, the two may not be identical. It's not clear what "satisfied" means with RLQ operators. MH: what about RLQ proximity? There is no ranked proximity operator. HT: there are no strong ranking models for proximity yet. This is partially addressed by the context, but proximity is not as common within ranked queries, beyond the context concept. This is what the context qualifier is for. Look at the proximity issue a little closer. MH: why restrict the weight for the operand between 0-1? PR: defined as IntUnit and therefore has a scale factor. Context qualifier only works currently across the terms within a given operand. Not across all operands. This provides some ability to express proximity among terms within an operand. This is like ranked proximity. Aspects similar to proximity but somewhat different. The context feature is correctly represented in the ASN.1. If RQOperator were a sequence of operators, it may buy the flexibility to express proximity along with the other RQOperator on a set of terms. Is the context concept orthogonal to the concept of an operator? That is the thinking of the group. MH: If RLQ operator could be sequence of operators...[what would results mean?] PR: The user controls how much reformulation the server can do (reform clause, see page 6 of the paper). The subgroup decided not to pursue the level of detail about expanding terms, e.g., synonyms, morphology, etc., thinking that users are likely to get confused. Can't standardize this now (the previous draft tried). Current approach is to keep it simple and extensible now and expand as needed. Can specify either or both of the following criteria in ClientServerInfo: * Number of records wanted * RSV threshhold value RD: Can you accomplish this through attributes, e.g., maxdocs? PR: RLQ attributes don't use BIB-1 because inadequate, i.e., RLQ is not intended for bibliographic data. Two recommendations: keep AddSearchInfo at a minimum, and use current mechanisms whenever possible. MH observed that the RLQ attributes solved the problems in BIB-1, and suggested using the RLQ attributes as a model when we do BIB-2. The subgroup has a specific set of RLQ attribute combinations in mind; will define small set of values and legal combinations. What now? Does the ZIG want to become involved en mass or should the subgroup go off and do more work? Keep this on the subgroup list for a while longer, but by the next meeting have something more mature. RD: polish it some more, then bring it back to the ZIG. PR will post it to the ZIG list in a couple of months. LW'S TECHNICAL NOTES Client can request return metadata about the results, section 3.8. This part is not yet flushed out. Just examples. Also not specified how this would be returned: as additionalSearchInfo for a lot of the information. But trying to minimize this use of AddSearchInfo. Record level metadata should use existing TypeSet-M elements in the Present Response. Comments on unspecified ASN.1 structures, like ServerClientInfo, where the comments are not useful. This ASN.1 will be fleshed out. Attribute types: relation reused from bib-1. Need to identify the portion of the document which was being searched, rather than the USE attribute. Location used in combination with other attribute types. These 4 attribute types 1-4 reflect different dimensions of the current bib-1 USE attribute type. RD: would it be better to define a new bib-2 attribute set that reflects this, rather than make this peculiar to RLQ? Response: this is not peculiar to bibliographic data. Need to define smaller set of well-defined attributes. MH: this helps move toward a solution toward some of the bib-1 attribute problems. Maybe move toward a new attribute set which is for general use, which embraces this. PR concerned about the flexibility of the experiment, and not getting slowed down by a lock-stepped attribute set development with the ZIG. Want to define a core set of values for these 5 types of attributes. Will values for content format be determined by the content of contentAuthority? In some cases. Some may be string values. The distinction between 3 & 4 is perhaps the weakest part right now. Thus ended the second day, Amsterdam ZIG, April 1995. ******************** Thanks a lot, Les. Minutes 4-27-95 Minutes taken by Les Wibberley les.wibb@cas.org Minor edits by Denise Troll troll+@andrew.cmu.edu ******************************************************* 15. UPCOMING ZIG MEETINGS September 25-27, 1995 at Library of Congress in Washington DC. February 7-9, 1996 in Gainsville, Florida. September 9-13, 1996 in Europe in Brussels. Tutorial on Sept 9-10 ZIG meeting Sept 11-13 (Sept. 1996 NIST meeting in Washington DC has been postponed.) Perhaps conduct both beginner and advanced tutorials in September 1996. This week's tutorial addressed lots of different levels. Perhaps half-day on real basics, second day on more advanced topics. ******************************************************* 16. INTEROPERABILITY TESTBEDS CL reiterated the need for an interoperability testbed for V3 implementation issues. The last time CNI sponsored the testbed; 10-12 implementors with short-term commitments participated. The purpose is to shake down the standard by implementation, achieve interoperability, find & fix bugs and report back to the ZIG. This feeds findings and problems back to the group to develop informal working agreements. Now we need the same framework for V3 interop testing. No formal profiling. V3 presents some unique problems because so much of it is optional. Proposal is to focus on 3 initial areas: 1. Scan. Scan presents some issues because several people are implementing it under V2. 2. V3 core (reflects changes to search, segmentation, etc.; create cookbook for migrating V2 to V3 core) 3. Explain. These will be 3 parallel activities running independently. No requirement to do all 3. These will be focussed activities for early implementors, no requirement for anyone to participate. 1 and 3 can be separated from 2, since 1 and 3 can be done independent of V3. __ SCAN interop testbed __ Coordinator: SR. 4 servers and 2 clients so far. Run for about a month. Call for more participation. It may be beneficial to insure some overlap between tests? No. SCAN testing over by August. __ V3 CORE interop testbed __ Coordinator: CL. We need a crisp definition of V3 core. Post strawman proposal to the list to convert your V2 implementation to V3. The V2 vs V3 conformance statement is a starting point for this. Timetable: call for participation in May, start in June. CL will generate a call for participation which will timeout around late May. By early summer, have beginnings of V2-V3 migration writeup in at least draft form. Will also gain experience with V2-V3 interoperability. Start with Explain mid-summer. Run June 95 through June 96. __ EXPLAIN interop testbed __ Coordinator: MD. Will be a later activity. Perhaps in the Fall. ******************************************************* 17. CHARACTER SETS AND NATIONAL LANGUAGE RM provided the history: At a meeting in September, the proposal for negotiating character sets only supported ISO 2022, so it wasn't accepted. Needed to also support ISO10646 and private character sets . New scheme now. General model: origin sends PDU including suggestions for character set use and national language. Target chooses what it wants to use. If origin doesn't like it, it can end. If Target doesn't reply, nothing has been negotiated. Origin proposes 10646, 2022, and/or private character sets, and/or national languages. For 10646, there are OIDs defined in Appendix M, which defines the level to work at, and the number of collections of character sets. So origin sends out 1 OID at the highest level it can work at. Also sends OID indicating 2-or 4-byte encoding. Target replies with what it can support. For 2022, ECMA has defined OIDs which can be used to negotiate the 2022 options. These OIDs identify a set of things, and control characters. The initial sets and encoding levels can also be negotiated. Initial set can be specified as an OID, the encoding is as in Sept. proposal. Private via private agreements. Via choice of sequence of OIDs or EXTERNAL, or NULL. __ Issue of national languages __ There is an ISO standards specifying 3-character national languages. Prefer ISO standard over USMARC standard. Strings affected were already posted by RD: name or message. Message strings subject to language negotiation. Name strings subject to character set negotiation. For 2022, set up initial set of character sets, and can then escape in and out of them. If a string contains an escape, it will only last for that string. Next string defaults back. Result of negotiation is a single 10646, OR a set of 2022 OIDS and encoding level, OR private. Question: Add a Z39.50 Object Class for character sets, especially private character sets. Answer: yes. There is no order of preference in the set of candidates. Would like Origin to be able to specify its preference within the request, by the order specified. This will be passed in the Other Info in the InitRequest. Should otherInfo or UserInfo be used to carry this in V3? Problem with using otherInfo if the target is V2. But this really only makes sense for V3, since V2 has visible string, anyway. Perhaps say that this is really a V3 feature. Agreed to carry this in OtherInformation in V3 INIT. This applies to term when term uses InternationalString. __ Issue of USMARC vs ISO language code __ NISO just balloted language codes which are different from ISO codes. Apparently the ISO code has some deficiencies. NISO Z39.53 is the NISO language code. It is compatible with the USMARC language codes (or will be soon). Z39.53 balloting has completed, so can be referenced. Should we use Z39.53 or ISO? The ISO standard will not be final for a long time. Eventually, the ISO standard will be made compatible. Use Z39.53 code for now. Qualify the language code with the standard authority (ISO or Z39). Perhaps add this same qualification for HumanString in EXPLAIN. Is there an OID for the authority in this case? Does Z39.53 have an OID, for example? CL and RD will work on this with NISO. This will be written up and posted to the list for discussion. If no negotiation, currently international string collapses to visiblestring. But that is not really current practice in general. Profile to state what the default character set is. Especially an issue for term. If character set negotiation does not occur, then you cannot use internationalstring as the term, if you send 8-bit characters. But this could be overridden by a profile agreement. ******************************************************* 18. RECORD 0 PROPOSAL PR described a need for retrieving metadata about a result set using a record 0. Saving a set and its metadata using the ES service would be one approach. V4 idea: ability to access metadata about the set at the present level. Current result set model doesn't include this. RD: do a search where result set is the operand, and ask for additionalsearchinfo for the metadata. Want to be able to retrieve the metadata at some later time after the search. Perhaps list this as a requirement for V4 for now, and not try to craft the solution right now. [break] ******************************************************* 19. OPAC CHANGES There is a small set of OPAC implementors who will work together to modify the OPAC record definitions. A subgroup of OPAC record implementors would get together and work this out. JG will coordinate the discussion. Perhaps look at using GRS-1 as an alternative to the current OPAC record. Take it to the list. ******************************************************* 20. FRAGMENTATION SYNTAX We need a fragmentation syntax with the structure in the first segment. Then we could use OCTET STRING for the subsequent segments. Use option 3 (as specified in the email). Only need the syntax in the first segment. Do subsequent segments use the fragmentation syntax or not? required or optional? Can use either the fragment syntax or octet string for subsequent segments. Agreed. Use EXTERNAL for every segment, using the fragment syntax for each. This same approach would be used to fragment SUTRS records.107 is the OID. This ASN.1 will be available on the Maintenance Agency Web page. ******************************************************* 21. ALTERNATE RECORD SYNTAX FOR MARC & THE INTERCHANGE OF BIBLIOGRAPHIC RECORDS Issue raised by German Library Project (Christine Bossmeyer). Interoperability problem with multiple MARC syntaxes. Define a new one, or standardize on a single existing MARC syntax. Perhaps agree to a profile, such as UNIMARC. Or perhaps define a new record syntax, independent of V4. ZIG Consensus: this is a profile issue. MD: this might use GRS-1. JZ: this is a big standardization effort. This is not really a ZIG issue. This is a political issue with technical aspects. JZ: defining a new record syntax is do-able. MARC record problem lies in the coded information, not the format. LH: this issue has been addressed by some project. Negotiation does not solve the problem. Not an issue of identifying which MARC record. The problem is that the code has to handle all of the MARC variants. Goal: create one syntax. But it might be progress to reach agreement on a smaller set of syntaxes (1-3). This is definitely a profiling issue. If there is some reasonable subset of MARC formats which implementors agree upon, then a reasonable subset can be constructed. Perhaps UNIMARC and USMARC. Is the issue whether to make a record syntax mandatory? NO. Excludes a large class of current implementors. Consensus could not be achieved on this. Goal is fine. What mechanism could be used to realize this? Someone could specify a Z39.50 profile specifying one or more syntaxes which are mandatory. Example: GILS specifies USMARC , SUTRS, GRS-1. Limits choice. ATS allows all MARC formats. This is an application semantics issue, not a syntactic issue. SIG/LA and EG/LIB work on this jointly? This will have no relationship to ATS-1. Eric/EWOS wants to pursue this jointly between EG/LIB and SIG/LA. Agreed. ******************************************************* 22. EWOS/EG-LIB TEAM REPORT Eric reports. Next meeting June 26. Project team 31 results report draft from mid-May In Europe, currently have public procurement policy. Requires Europeans to reference international standards and European norms. Have therefore been profiling ILL and SR. Things have changed, however. Priority is now to control migration and interoperability between OSI and other technology. Report addresses several issues: implementing SR and Z39.50 over mOSI stack. Potential advantages, changes, etc. Also issues on character sets, APIs, etc. Provides implementor guideline for interoperability between Z39.50/TCP and SR/OSI. Quick and dirty simple access. Report available on a server. LH and ? are the authors. Perhaps read, and come back and discuss further. Report touches on previous agenda item. Presentation by Poul Henrik Jorgensen. PT031 report. __ Issues __ * Incompatible transport scenarios: * SR over OSI * SR over combined OSI and TCP/IP * SR over TCP/IP only * Lack of standard transport layer APIs (winsock, etc.) * Inefficient protocol implementations * Multiple presentation contexts (MARC formats, character sets, etc.) __ mOSI concept and facilities __ * mOSI profile defines the functionality * ThinOSI cookbook describes the protocol * XTI/mOSI API provides the interface. __ mOSI profile __ Most basic applications only connect, read, write to the network, and only utilize a small subset of OSI Upper Layer Features. The mOSI profile (ISP 11188-3 CULR-3) identifies those Session, Presentation, and ACSE functions sufficient to support BCA (Basic Communications Applications) requirements. Most ACSE functions retained. __ ThinOSI cookbook __ Conformance to protocols is determined by data on the wire, not by emulation of abstract internal protocol layers. The IETF cookbook (RFC 1698) presents the elements of OSI upper layers as the corresponding byte-sequences wrapped around the application user data. __ XTI/mOSI API __ XTI is a family of compatible interfaces to different transport providers including mOSI, TCP, NetBIOS, SNA, and X.25. XTI/mOSI provider is responsible for building and parsing all of the OSI protocol information around the application data, following the spirit of ThinOSI. This is a more efficient approach than ISODE stack. This code is in the public domain. __ Benefits of using mOSI __ Presentation context negotiation supports use of ASN.1 EXTERNAL data types representing different MARC formats, etc. mOSI profile facilitates efficient transport implementations -- just core UL functions. XTI/mOSI API helps portability between different transport providers. Some fine points are still being discussed, re several concurrent context syntaxes being supported. Current Z39.50 has limited ways of handling syntax negotiation. __ Outstanding issues __ An OSE profile of the XTI/mOSI API functionality needed to support SR services could be produced as an aid to implementors. Negotiation of language and character set repertoire including the ISO/IEC 10646 should be incorporated in the SR protocol (ZIG is now doing this). Note that there is an implementation of Z39.50 over this. The address of the report was posted to the ZIG list. ftp.dknet.dk EWOS/EG-LIB/pt031fin.wp5 ZIG discussion: The ability to dynamically add presentation contexts is not supported by this. Public domain XTI implementations are available: mOSI over TCP/IP. IBM and Microsoft will be implementing mOSI over their protocols. Issue of Z39.50 being an OSI protocol. That is, it is capable of utilizing the presentation layer (RD). ******************************************************* 23. V4 AND BEYOND First step is to assess requirements for V4. Add items to list RD is keeping. At some point, do a survey on which are most needed. Probably not a level of effort equivalent to what was required for V3. MD: format for meeting: V3 status, implementation issues, and finally V4 topics. How long to retain compatibility with V2? V4 is open for discussion. Not clear that V4 would even be compatible with V3, never mind V2. This is an open issue. BW: question of how dynamic things can be from here on in? Like adding error messages after V3 is published. Keep provisional lists, which can be used, but are not yet in the standard. JZ: subtle difference between new attributes vs new diagnostics received by the client. ******************************************************* 24. BIB-1 MEETING BC reported that the BIB-1 group continues the revision process. Work the document on the BIB-1 list. Then revisit in a few weeks to determine whether a meeting is needed. Post to main ZIG list before next ZIG meeting. Interest in separate meeting vs one the day before the next zig. No, that doesn't work. May need to meet on Sunday. Around 12 folks interested in meeting before the next ZIG. RD may be able to find some space to meet, perhaps on Sunday before the ZIG. Thanks to hosts. And to the Europeans for putting up with us Americans. MD: IFOPS meeting here at 2pm. Tomorrow ISO TC46 meeting in Leiden. Sally is the chairperson. That group is more formal. Attendees would be observers, and would not have a vote. Informal reception at PICA in Leiden around 5pm tomorrow. Map on table: 35 minute train ride . Meeting starts at 9am tomorrow. Train leaves at 8:09 at latest from central station. 5-10 minutes walk from there. Meeting adjourned.