September 1995 ZIG meeting minutes provided by Margery Tibbetts ____________________________________________________________ ZIG meeting Day one - 9/25/95 Implementor status reports: Denis Lynch - TRW: client & explain server now shipping Eric Ferrin - Penn State: working on V3 Eric Bivona - Dartmouth: v2 system with scan Brad McLean - SilverPlatter: v3 gateway to ERL tech, going into beta, with explain, next week Margery Tibbetts - UC DLA: adding access, resource control into v2, access to citation databases, client develop, evaluating OCLC ZWeb gateway Kevin Thomas - Ovid, Technologies: shipping client & server, v2 with scan, working on v3 Sean Donelan - DRA: a couple of v2 client & servers, v2+ server for Unix, PC windows client work David Loy - Knight-Ridder Info.: v2+v3 server for internal comm. opening up some to public Robert Gray - Gaylord: v2 server, WWW client, v3 underway Larry Dixon - LC: Web gateway to v2 server, and access to known Z39.50 databases -open to all. Ralph Orlick - LC: client, server v2, enhancing client, using Sitesearch, multilanguage databases, no v3 yet Mike Wheatley - British library : v3 target using NLC code, also GLP software using for European project conversion software ISO AR - public available summer 96. Ed Davison - SLS: v2 client, server. working to v3 by end of year, including explain Peter Ryall - Lexis/Nexis: several client/server implementation, mostly between their own clients, servers working on standard v3 implementation, Web gateway. Sara Randall - Ameritech: v2 clients/servers, v3 client in testing, looking for servers as testing parteners Craig Jackson - IAC: testing v2 server with scan, plan to do v3 later this year. Tom Jacobson - Innovative Interfaces: 30 clients v2; working on v3 John Kunze - NLM : v2 server with scan for Medline using MARC, SUTRS, interested in v3 compatibility production around October Dennis Van Dam - West Pub: investigating v3 Rich Fuchs - RLG: v2 server in prod with scan, sort Brent Washburn - Tabular Interactive: electronic publishing on the Web using Z39.50 Nasib Nassar - CNIDR: ISITE package to support v3 Paul Over - NIST: public domain client/server. Implementation papers completed. NIST to make avail. in Nov. hardcopy versions of the papers. Erik Lorenz Petersen - EWOS: Europeans moving away from profiles in favor of implementors agreements Mark Needleman - UC DLA: accessing 15 OCLC/RLG databases via Z39.50. Ralph LeVan - OCLC: v2+ server, Firstsearch, Sitesearch, just introduced HTTP server with Z39.50 capabilities going into prod. V3 plans tentative, waiting for market demand Bob Waldstein - ATT: v3 client & server, successfull interoperablility testing with Ameritech item order, clients spreading to desks Denise Troll - CMU/SIRSI: SIRSI clients, servers may be Sitesearch Kurt Kopp - U. of Missouri: testing TRW & OCLC products Bill Jordan - U. of Washington: WILLOW- not much new lately, more prod. database access OCLC, RLG, v3 warming up, via SilverPlatter Bill Cattey - MIT: Univ. of Washington, OCLC, Stanford work, working with WILLOW, prod. use of RLG databases, v. 3 development tied to SilverPlatter plans. Beta testing OCLC Webz client, like it. Stuart Soffer -Taliesian Software: Zest, NT Ute Rusnick - FIZ-K - implemented v3 client, server, GLP partner, starting interoperablity testing early Oct. Plan to develop Item Order client in 96 for GLP, interested in testbed for interoperability testing. Trig Ager - IBM: attended due to interest in Z39.50 for Digital Library project Les Wibberley - CAS: CAS has developed a Z39.50-1995 V3 client and server. The server is being used by USPTO for their Z39.50 project. The server is also being used to provide Z39.50 access to FIZ-K within GLP. STAS Attribute & Element Set now reflects contents of over 100 databases. Wayne Davidson - RLG: v2 server in prod, sort currently broken, almost fixed. v3 - 2 levels of plans: talk to v3 first, then business decision about what v3 services to support. Looking at Web access to databases, prototype later this year. Andy Oates - Geac: v2 client, v2 servers in prod. implementing v3 as needed Joe Zeeman - Software Kinetics/NLC: new integrated system - Amicus using Z39.50 live in June, refining now. New project to examine usefulness of using Z39.50 clients/servers in day to day operations. Commercial clients examined,evaluate impact on NLC , set requirements for Amicus to talk externally. Public access to NLC by fall 96 via Z39.50. Another z project for a virtual Canadian union catalog, linked together, using Z39.50. Makx Dekkers - PICA: v2 client used in prod. Accessing RLG, stopped access to OCLC due to Internet performance problems; looking at use of leased line alternative. V2 server not being used. Couple of projects: German library project: start testing API library. Will start testing around October. Will try geopac v3 against it in next couple months. Plan to implement Item Order early next year. Open library network - Netherlands - converting to Z39.50 basis, using the API library developed for GLP. Third: ONE project in Europe, using same API library, plus explain service. HTTP gateway operational for 3 months. Z39.50 component to be added. Cliff Lynch - UC DLA: starting to see serious production load on Z39.50 client & server increasing over time. Future plans: expect that in 1996 start dealing with v3 issues. In particular, core v3 stuff; some explain work; moving bit-mapped images via Z39.50 using lvl 2 segmentation. Developing graphical client - HTTP on one end, Z39.50 v3 on the other end. Mark Hinnebush - FCLA: v2 server access to 10 state university databases, staying out of client business, mainframe-based client. involved with IBM in Digital Library project. Going live tomorrow morning using Z39.50 to access citation databases, buried URL, with image retrieval. Bill Moen - Univ. of North Texas/CIMI: project manager for CIMI museum profile Bill Monhemius - Sea Change: released v2 client based on Cansearch, looking at v3 Bob Kline - Stream International/NLM: working with John on NLM project Library Corp. Pat Harris - NISO: campaign to educate folks. Manette Lazear - Mitre: developing end-user tools to allow mapping of metadata into attribute sets electronic library projects funded by European commission. Austria: doing Z39.50 target for museum appl. v2, working on explain on rdbms, lots of European folks involved, several working on explain Mike Douglas: Rensselaer Polytechnic Institue: v2 target; working on explain Defense Intelligence Agency: advocating use of Z39.50 in their arena and within the military. Interested in Z39.50 to HTTP and SQL relationships. George Blair: Excalibur: merged with Conquest. Their software finds patterns in digital data (fingerprints, mugshots, etc.). Standalone v2 WAIS server to Conquest server, with good ranking. Frontend server for NASA. Web client to WAIS, other Z39.50 databases. working on SQL. Hooks are in ISITE to access Conquest engine. Jeff Graubart-Cervone: Ameritech: Web gateway . v3 client in test mode, interoperability testing. Comp-1, Item Order, Explain with Silverplatter, working with GILS & U Mass on integrating v3 client with Netscape. 1. Register of Implementors Ray will circulate the register for markup 2. Walkthru of editorial changes No walkthrough this meeting! 3. Status of 1995 document Finalized in July. Current copy is final text. Not subject to change, except editorial changes which are part of the publication process (NISO), When publication processing is complete, Ray will summarize all text changes on the WEB page. Agreed in principle that Z39.50 & ISO equivalent will be identical standards. Pat Harris's (NISO) comments about the editorial process: editing for uniformity, edit details. No changes to the text of the standard without Ray's review. No changes to pagination if possible. Paper version will include an index. International progression of Z39.50 to ISO underway. Expect that all issues will be resolved, published as ISO fast-track standard in 1996. V3 will be published in late October. Will be accompanied by Bill Moen's paper on Z39.50. Introduction to users of the standard. NISO version of standard will continue to be available electronically via Ray's Z39.50 Maintenance Agency home page. 4. Z39.50 Maintenance Agency (ZMA) Web Page Discussion of the proposed sections of the Z39.50 Maintenance Agency Web site I - Changes to Z39.50-1995: List of the formal changes to the published standard. Page currently empty. No changes applied to July version yet. If there are changes which go thru a formal process, they will be reflected here. Additions to the attribute set, diagnostic set, etc may just be bundled into v4, instead of reflecting here. Ray wants to maintain bib-1 in current state, and highlight changes II - Extensions, agreements, and interpretations section: extensions: additional (provisional) diagnostics and attributes (maintained by the ZMA) Implementor agreements: ex. piggyback search present conformance, close, scan, etc. Interpretations: message size, etc. interpretations will be a formal interpretation of an ambiguity in the standard in an attempt to clarify the standard to improve interoperability. Documented here, as a result of discussion and consensus reached at a ZIG meeting Interpretation is more official than implementors agreement. Ray will document an issue raised, and the consensus he understands, and that would be validated at a ZIG meeting, and be reflected at this page. Q: Where will profiles be located? Profiles are a separate item on the MA home page. Profiles of Z39.50 for a specifc application. Q: is an implementor agreement just a global profile? They do span profiles. suggestion: move profile up in the Web page. III - V3 testbed section: wide open right now. add whatever makes sense. Q: is there a need for more general interoperability testing category? yes. change to a more generalize title. Several interoperablity projects, including European efforts. IV - Register of implementors: time consuming to publish on the Web. will continue to publish in hardcopy & pdf and postscript. Hotlinks to the company would be useful. Moen: Need for archival copies to document the state of the register at a given time. Retain date last verified? Yes. Frequency of updates adequate? Continue current approach (update 3-4 times per year). Need to add information as received (versus per ZIG meeting). Agreed: update information as received (dynamic update). HTML version will be updated on the fly. The other forms will be more static. V - Profiles: currently: WAIS, gils, z39 over tcpip, ATS May add category for profiles in progress. Q: section on SIG/LA? A: OK. Add link to SIG/LA page Link to the European EWOS profile page will be added. . VI - Objects and definitions: Move objects section up - right after the 1995 document (higher on the page). Renamed to Registered Objects. Problem: some of the things in there are not strictly objects. For example, the units systems are not identified by object OIDs. Nor are the body type definitions. Some things are somewhat hidden within objects, for example the character set negotiation topic. Should the charset negotiation be covered under implementors agreement? Two catgegory of OIDs to be included: public and private: VII - Articles & tutorials: initial set of implementor articles out there now. 11 papers published. will be a NIST publication, as well. Q: section for bibliography separate? these are not just ZIG papers, can be anything. Soliciting entries for the bibliography section: any subject related to Z39.50. Tutorials: put the latest ZIG tutorials online. Q: include the NIST brochure here, also? Provide a pointer to this NIST doc on the ZMA page 5. Target info Web page - Zeeman Difficult to find where the servers are right now, would like a mechanism for finding them. There is currently a directory on the Internic Z39.50 page which is fairly brief, and is not completely up to date. What is being proposed? Information to describe a server implementation, so that a client can test/run against it. Real work is collecting the data (whether for this or for explain). Part of the LC Z39.50 gateway was to provide a listing of the available servers, but the list certainly doesn't reflect all of them. Set of servers is very different from the set of implementors. Put together a structure for a Web page which provides a standard way of finding out what a server supports. This helps to capture the same type of information which will be used in explain. Goal is for human consumption. Explain is for electronic/machine consumption primarily. Concern re two mechanisms for the same function: this and explain. Desirable: 1. human/end-user form; and 2. something which is parsable for use in explain. NLC: wants this as information for a client to be configured to access a given server. possibly construct these files such that they could be converted to/from explain record. Lennie: willing to take their guidelines and convert to this format, if outcome is a useful RLG document, as an experiment. Concern that this may not be fully sufficient for the expressed purpose. Joe: related issue of finding out that there is some server somewhere that you can talk to. Requires some sort of registration service. Similar need for clients. Add a list of Z39.50 servers on Ray's ZMA page. Name of server, and a hyperlink to the server's html description page. List of available servers only will be included. Submitters will submit their entry Only submitted entries will be included. Q: is the ZMA the correct point for pointing to all the products & services using Z39.50? Is the purpose advertising, interoperablity testing, or configuration, etc. There needs to be some central site for finding sources of information via Z39.50. There needs to be an easy, human way to find this information. We need to encourage use of Z39.50. Conclusion: Mark, Ray, and Bob will work out a solution. Ray will put the solution into effect, and we can comment at next ZIG meeting. 6. V3 baseline requirements (handout) This was drafted in response to the last ZIG meeting. Does the ZIG endorse this requirements document as statement of V3 requirements? Yes. (sort of) Clarify that the client must accept diagnostics in either/both forms. Need to clarify the difference between accept and recognize in this document. Support: accept and recognize, and support the semantics as well. Accept: not declare a protocol error; Recognize but doesn't support - same as accept? Question re use of term "kernel"; Cliff preferred term Core over kernel. Add a date to the document, to reflect version. Very useful analysis for implementors. Dispells the misconception that V3 is an order of magnitude more complex than V2; this clarifies that it is actually a fairly minor step. This doc could be leveraged to defeat this misconception. 7. Piggyback error handling - Les Wibberley The client requests a (piggyback) search, which requests one or more search result records to be returned in the search response; The search was successful; BUT the server does not support piggybacked searches (cannot return records on the Search Response) Then the server should return: search-status = success result-count = number of answers in the resultset present-status = failure number-of-records-returned = 1 next-result-set-position = 1 records: non-surrogate-diagnostic = piggy-backed search/present not supported Denis: why do we need to do this? Cliff: there are several servers which don't support piggy-back searches Agreed to proposed solution. . New error diagnostic 1005 assigned. ____________________________________________________________ ZIG meeting Day 2 - 9/26/96 8. Recent profile developments deferred until later 9. Character set negotiation (handout) Most of this was agreed to at the last ZIG meeting in Amsterdam. New parts are: ISO2022 and ISO10646 ASN.1 definitions ISO2022 was based on an ECMA doc which we didn't have and weren't sure about its status. Most contributors to this topic are from Europe, and most not here. Bernd agreed that ECMA doc was not firm. Therefore perhaps base on our own ASN.1. Environment definition is new. Q: why environment needed if ASN.1 uses 8-bit encoding. A: the encoding could be non-BER for 7-bit environment. Q: what is definition of LanguageCode? ISO langauge codes or Z39.53? Z39.53 will be used, since it is a superset of the ISO language codes. Need for a bibliography for the referenced standards. Not only the ISO 2022 and ISO 10646 standards, but also the registers. All of this information is available from ANSI. There is an EWOS Web page on character sets, which Eric will post to the ZIG list, and ZMA may point to it. EXPLAIN does not export Language Code. Ray will fix this The datatype definition will be added to the charset ASN.1. CharacterSetandLanguageNegotiation will be replaced with the appropriate OID, and will be added to the definition. Q: Where does the negotiation record go in the InitRequest? This definition can not be used in V2, except for language negotiation. Make proposed character sets optional, to allow negotiation of language only. Add clarification that language negotiation affects message strings but not name fields. Q: Where is this negotiation record is carried userinfo field or otherinfo? propose use of otherinfo for flexibility. Problem: if client uses V3 otherinfo field talking to V2 server, that would cause a protocol error (V2 INIT doesn't include otherinfo). Proposed solution - if origin proposing V3, put it in otherinfo. If proposing V2, put it in userinfo. Recommend that V2 servers allow for possibility of otherinfo arriving on INIT, and not crash. proposed soultion agreed to 10. SICI attribute This was posted to the ZIG list as a proposal. Agreed. New BIB-1 use attribute - 1037 10.1 Report from BIB-1 attribute group The draft BIB-1 doc apporved with minor modifications. There was a general discussion about the future of attribute sets? one superset. or several smaller attribute sets. New BIB-1 attributes will not get added to the Z39.50 standard. But will get added to the BIB-1 attribute document, after approval by the ZIG. They will also get added to a list of BIB-1 on the WEB page ZIG general discussion about attribute sets. There is a concern about putting everything into attribute sets. verus more use of explain. Client software which knows the subject area and should understand the semantics of the attribute. Discussion of the issue of one big vs many specialized attribute sets. Biil C. - Do not create one great big attribute set. Allow each specialtygroup with necessary expertise create and maintain own attribute set. BIB-1 should go away, and be replaced by a common simple backbone attribute set. John K. - continue to use BIB-1, and move on. Mark H. - GLP attributes already in STAS, Makx has requested adding to BIB-1 also. Creates issue of ambiguity. Joe Z. - BIB-1 should be frozen. Ray D. - continue to add attributes to BIB-1, and start to develop new attribute set, which over time will supplant BIB-1. Also other non-bibliographic attribute sets. Need a model for an attribute set. Ray D. - suggestion: we need a fresh approach to building a new attribute set.The ZIG approach doesn't adequately address the problem. People don't have the time to spend on it, and are not committed to it. Attribute set needs to be developed by an officially constituted group: get right set of people involved, some of which are here; will give visibility to the result, such that it could even extend beyond Z39.50; focus on searching scope for Z39.50; but be able to make these objects available for other standards as well. This would be essentially a metadata effort, perhaps as a NISO subcommittee. This could be a recognized metadata set for searching. Cliff: L. - we have rich experience now with the effect of being vague. Need to be more specific in the future, and make sure the new group understands this hard lesson. Support notion that we start work on successor to BIB-1, done by bibliographic folks as a separate effort. We need to agree on basic principles: multiple attribute sets vs single attribute set? how about replication of attributes across attribute sets? relationship of this work to BIB-1? intentions for future of BIB-1? sizable installed site, need to continue to support and maintain, but avoid major structural enhancements, but use of BIB-1 declines over time. Other than explain attribute set, will there be a core ZIG attribute set for Z39.50? Makx D. - proposed that GLP attributes be added to BIB-1. Issue of duplicate attribute assignments. compromise: use same numbers already assigned to STAS. OK, but not to be used as a precedent. Other implementors also use other numbers in the BIB-1 attribute set. GILS also used the 2000- range. GILS also imports the entire BIB-1 attribute set, but has its own OID for its attribute set. This illustrates the need for general principles. We are trying to craft a hack solution without the solution. Even if same numbers, the semantics could diverge. Ute R. - GLP attributes were added to STAS because they couldn't be added to BIB-1. Now we are proposing adding them to BIB-1; is it proper to add some of these attributes to BIB-1 (eg, CAS registry number). Need to explicitly specify which attributes are to be added. Mark H. - establish subcommittee of the ZIG to come up with a short and long term solution to the issues. Bring it back to the ZIG for resolution. One group to come up with a short-term solution; another for the long-term solution. Clifford will chair a subcommittee to address the future of attribute sets (long term) Cliff L. - schedule a chunk of time at the next meeting to discuss this further. Short-term issues: work sooner. Architectural approach between now & next meeting. It will take a minimum of a year to fully structure the attribute concept/set. Need shorter term strategy. Recommend that shorter term attribute sets specify exactly which attributes are imported. Compromise: GLP attributes will be added to BIB-1. STAS will retain GLP attributes, and will cross-reference the BIB-1 attributes. 21. Browsing structured vocabularies (handout) (Kunze) Summary of handout: Ancillary to finding database records. Discover terms which will help you find them. Vocabularies may have no apparent order No requirement for scrolling. Collection of term nodes. Single node for set of synonyms. Can be connected to ancestor and/or child nodes. Bring rich enough term information back, to allow navigation. Marc authority format as a strawman for the record syntax. Can also use with SUTRS format. Synonyms are not central to this proposal. Two basic approaches which eliminated scan. The vocabulary search is ancillary to the database search, need to connect the vocabulary database to the main search database. Approach: construct the search as normal, but set a flag which causes server to create result set of term records, which you can present as normal. Need diagnostic to indicate no vocabulary available. Issue of database name on return, distinguish between returned vocabulary vs. the actual database records. Explained USMARC authority format. Significant project at NLM MetaThesaurus project for linking in. Why not GRS-1 record syntax? It would be a good fit. NLM currently supports MARC, so they tried to use MARC. Why not SCAN? Not possible to use due to multiple tress What about separate result sets? Can you OR them together? NO. Ray D. - whether to model as search vs browse: remember that browse was a broad topic, and that we allowed for additional browse facilities could be added. Would prefer to see a new browse service over setting a flag on the search (v4 facility). New service vs overload search. Model the thesaurus as a database? possibly with a standard for naming the database. Consensus that SCAN is not right for this function. Proposal to use explain to retrieve names of vocabulary databases? Brad M. - 1. there is a need to express ordering even within thesauri. Useful operation to browse up and down within a thesaurus. 2. support explode operation. Rather than have client traverse the tree, thesaurus provide list of children. Have server compute an explode, rather than client do. 3. Attempt to match an uncontrolled vocabulary to a controlled vocabulary at server. Be able to select preferred term. 4. Interest in linking across vocabularies. For example, in result set from thesaurus reference other databases or thesauri (see also). Bottom line: there are two ways to do this. Search/Present vs SCAN. Model of searching thesauri as separate databases requires no protocol changes. Support for specific record formats is not a problem. Not sure what other type of approval is necessary: need new search attributes for navigating thesauri? Some analysis about thesauri navigation? No standard changes, but some additional definition is needed. Perhaps an implementors agreement. Cliff L. - re SCAN: SCAN is essentially a search in the CAS implementation. John's approach has the advantage of selecting the record syntax and getting it back via segmentation. STAS attribute types for relationship can be used for scan and search, even in John's approach. Stu S. - inverse of thesaurus: use an ambiguous term to find a controlled term. 11. Explain implementation status Makx D. willing to take on role of coordinating Explain testbed, since Europe has money to support. Brad has just finished beta implementation of gateway, Has all records, except a few, like units. Just let Brad know if interested in interoperability testing. Bob has Explain up, only has retrieval record details. Will add more soon. Denis: has implemented explain (see paper Denis wrote - based on TRW's implementation). Pull data out of explain, and format at user interface. Server can support retrieval. TRW client uses explain extensively Have GUI tools to create the Explain records. Have built up an explain database about most of the servers they have accessed to make their client work. Availability to test against? Server is slow. Use private record syntax to wrap around the explain records - plan to fix this, and then will provide test access. RPI in process of implementing explain. Ameritech has a client which uses explain. Tested against AT&T and SilverPlatter servers so far. 12. EXPLAIN default database descriptions: how to specify? (D. Lynch) Use "default" ? Need to specify this special name in the explain database records. IR-Explain-default. agreed to as Explain database default name 13. Surrogate explain servers. (D. Lynch) Explain databases which are not resident on that host. This is the ability to be an explain server for multiple servers and their databases. Connect to this server, search the explain database, and look for those with the explainDatabases flag. Each of those explains another server/database, by pointing to the explain database of another server. This is an explain database of explain databases. Cliff: Think about an inverse to this. Add explain record which is some kind of a digital signature, for authentication. Ability for a company to delegate responsibility to another explain service (like Denis' explain server of explain server). Need to verify that this version of the explain database is an "official" version, approved by the database producer/licensor, versus a degraded explain database. Might be bound by a contract with the explain provider. If server doesn't support Explain, it could respond with a diagnostic, which includes a pointer to an available explain service for the server. May need mirrored explain databases. Agreed: The search term for retrieving this would be the URL or database name you got some other way.Will be included under the implementors agreements on the ZMA. 13. Scan Additional-Info - Waldstein. Develop external to express other scan information.. Discussion about how to determine whether the server will honor the requests, and what you actually get back? Bob will write up ASN.1 & English, and provide to Les and Ray for comments, then post to ZIG. 14. INIT-Response User Information record. (C.Jackson) The OCLC and CAS records are similar. OCLC is returning an external in the INIT Response. CAS included set of private option bits to negotiate. CAS handled diagnostic as an external. Could have the INIT diagnostics registered as part of the global diagnostic set; or as a separate diagnostic set? Separate message from the message of the day for user-specific information. Include an icon? Also include a version warning message (for expired client software). Warning versus user information. Perhaps categorize messages. Include ability to carry a sequence of diagnostics. Ray: can we list the diagnostics submitted? Allow for operation within both v2 and v3. Provide ability to determine which databases are down vs available? Resolution: Craig will draft up the proposal, and all should comment & submit diagnostics. Then post it to the list for discussion. ____________________________________________________________ ZIG meeting Day 3 - 9/27/95 Upcoming ZIG meetings: Next meeting: Feb 7-9, 1996 in Gainsville, Fla. (Wed, Thurs, Fri) Following meeting: Brussels, Belgium, October 2 - 4, 1996 (originally scheduled for Sept. 9-13) Q: do another ZIG tutorial in Brussels? tutorial on character sets by Europeans before ZIG in Brussels? Agreed: 1.5-day tutorial, including both ZIG and character set tutorial on Tuesday, Wed. morning. ZIG meeting Wed noon thru Friday. Moving toward 2 meetings per year. Mark offered to step aside as chair, noone accepted offer. Ray nominated Mark for another 6 years. 15 Extended Services Item Order (Joe) Profile 1 addresses use of Item Order with ILL protocol system on both ends. Extended services item order used to transfer ILL pdu between both sides via Z39.50. Profile 2 addresses use of Item Order without ILL protocol systems on either end. Uses ILL parameters without the ILL pdu, where the fields are no longer mandatory. Les W. - Wait action should be mandatory not optional under profile 1 &2 since ASN.1 in Extended services makes it mandatory. Q. - How does the server recognize which profile of an Item Order it is receiving? A. - The item request parameter in the ES request distinguishes the profiles.. Makx: would like to make it mandatory that the response info be written into the task package. Target reference returned in the response, can only be returned in the task package. If task package is returned, implies that the task is complete. Profile 2 allows for the task package to stick around, and be updated with a status which the client which can retrieve. But at some point, the task package may disappear, at the target's whim. Resolution: make necessary changes, discuss further over the list, then finalize. Another draft at next meeting, and try to approve at the next meeting. ASN.1 for ILL is available on NLC ftp server, including latest changes (V2). The whole ILL standard will be republished soon 16 Close (Bob) Bob's server is timing out after inactivity. In V2, just closing connection. In V3 willing to issue a Close, but not willing to wait for Close response. OK to Close, then disconnect. Not a conformance issue. Nice thing to do is issue a Close, wait a short time for a Close response, then close the connection. Ray will add an entry to the ZMA interpretation section on this. 17 Interoperablity testing & testbeds Cliff: For V3 interoperablity testing will be different than it was for V2, given number of features, and varying rates of implementation. Areas identified to date: V3 core, Explain, Scan, Item Order. Cliff agreed to coordinate V3 core issues, and others will coordinate other topics. Comments on V3 core: Immediate priority: identify what constitutes V3 core: what do you need to turn on the V3 bit. Ray's document on the Version 3 Baseline requirements specified this, and is very valuable, represents significant analysis. Proposed schedule: put out call for V3 core testbed operation, to start Nov/Dec 95 timeframe. There are already several V3 implementations, but limited interoperablity to date. Public V3 demos in Spring/early Summer 96, to allow vendors/implementors to announce V3 by the ALA. After core, test mixed attributes from multiple attribute sets. Call between now and mid-October for interested participants. Minimal meetings if any. Possibly monthly conference call if necessary. Hope for a core of 8-10, perhaps 10-15. Assure implementor and user and purchaser communities that V3 is broadly deployed by mid-late 1996, at least for minimal V3. Ray: how about a profile for this? Would it be useful? Cliff: not a profile per se, perhaps working agreements, based on participants. The call for participation will be written up in a form to help get more organizations to participate. This will be under the auspices of CNI (Coalition for Networked Information). PR element to this. Explain (Makx): Nothing has happened yet. Austria has agreed to develop an Explain testbed. Will support Explain on a RDBS. Would contain information about other servers and databases. Participants would submit information about their servers to add to their explain database. Makx will issue a call for participants. This is related to what Faye was proposing. Is there an idea about test scenarios for Explain? Denis' paper is a start. Concepts of levels of service, minimal vs full-blown. Form of Explain information from participants? In ASN.1 form, not in text form. Ralph was planning to post notes re an SGML form of the information. Then Ralph would provide a service to convert from SGML to the BER records, put on FTP server, and we can retrieve the results. Report on activity at the next meeting. Scan (Sara): Folks who agreed to participate in Scan testing (short list) OCLC, RLG, AT&T, NLM, (maybe CAS); several clients have been doing some testing. Expect demos in the same time frame, as well. Basically V2 based. Not based on V3 core. Item Order (Sara) - GLP will implement Item Order by 3Q96, and will be testing it. OCLC has implemented IO, no interoperablity testing yet. Implemented ILL PDU in IO via ES. GLP will use Profile 2. Ameritech & AT&T have interoperated with profile 2 essentially. Revisit at next meeting. 18 EXTERNALs negotiation: (Joe) This was raised on the list. Need to negotiate which externals would be used within the Z39.50 association. Origin sends list of OIDs it wants to use. Target responds with list it will accept. Bob wants to negotiate subfunctions of functions. Negotiating externals does not address this completely. Could negotiate details via CAS proposal for INIT structure option bits. Joe will craft some ASN.1 for this, post it to the list, and folks can comment, and add to it. Ray: is it useful to have a negotiation record which does just this, or make a more comprehensive record, which includes more. Consider a sequence of simple records. Sequence of externals. One record for negotiating a set of OIDs. If carried in Other Info, it supports sequence of EXTERNALs. Perhaps carry negotiation records in OtherInformation in INIT. Joe will draft a message and post it to the list for comment. 19. "Having with" operator (Joe) From SQL land. Ambiguity in mapping Z39.50 AND operator into SQL. Can be done in several ways, so Z39.50 client doesn't have same richness as an SQL client. For example, bib items related to name. Need to add an operator to Z39.50 to support this. For example, table of bib items, table of names, table that manages relation between name and bib items. SQL selection from name with relation to relation table. All items with a given relation: all items which have an author. Find names and roles, and AND them together. Express a query specifying a set of names and a set of roles, and insure that the answers satisfy that. Can do a union of the set of names and roles. But cannot express as a query. Would this be solvable via attributes? Not easily. This is one instance of the problem. Does it help to express an attribute on an operator? SQL operator would be "in"??. This is potentially a V4 issue. This could syntactically be expressed as proximity, but is messy. General issue of relationship between SQL queries and Z39.50 keeps coming up. Perhaps an SQL query type? Separate issue from this one. This is independent of SQL. The ZIG needs to address the SQL issue. Easy answer: SQL doesn't enhance interoperablity. European project plans to build an RPN to SQL converter. Easy one way, hard the other. BIB-1 Attribute Set Meeting 9/25/95 1. Discussion on current draft of BIB-1 attributes semantics document. Goal: reach final agreement on the BIB-1 draft. Q difference between 56 - code-institution and 1019 - record-source A: the definitions appear to be the same, but apparently want to get to a single subfield of the field. cataloging source, essentially. all USMARC fields specified are just suggestions. perhaps add prose for 1019 as a cataloging source for code-institution add record source or location. this would clarifies the difference between the 2 attribute types. Denis: clarity of text at front of doc. description of key attribute. wordlist not completely described Q. What about the deprecation of certain usages (like wordlist). Ray: there are a couple of deprecated attributes: concept-text and concept-reference. But not deprecate wordlist. Add some wording to the definition to clarify that its handling by different servers varies. (OR between words, or AND...). Also wordlist ADJACENT. section 2.6 change: there is a problem here. should say: incomplete subfield should be used to mean incomplete field. incomplete is a more general meaning than truncation. authortitlesubject is a different kind of animal. Need note about how to behave upon receiving this attribute. This was essentially introduced by CARL, to handle conformance. Host-item: this addresses more than one subfield of 773. 773 contains lots of subfields. change 1033 to be more specific. If other subfields of 773 are needed, then additional use attributes can be added. Q: is there some standard indicator of subfields within a user-input search term? A: no. There is a problem with this. if queries are that specific, you should probably be using a different attribute set, which contains specific attributes for such granular search fields. back to wordlist: add language to clarify. stopwords are outside the scope of this attribute set. Normalized date was changed. No longer the same as the ASN.1 structure. The generalized time was a problem. refers to ISO standard. normalized name is defined in the ats profile. 2. GLP attributes Makx: Can the GLP proposed attributes beaccepted into the BIB-1 attribute set? Problem: creates duplicate definitions in STAS vs BIB-1 attribute sets. Q: just leave them in STAS, or add them again to BIB-1? Need to resolve this issue. How to handle attributes administratively. There is a problem of coordination between multiple attribute sets, which we haven't worked out yet. There are no principles for doing this. No scope statement for BIB-1, or for managing it. Other attribute sets will need to move quickly. Current BIB-1 management scheme is very cumbersome (4-6 month turnaround minimum). Need broad discussion on this general topic. Need to be prepared for someone to define a new attribute set. Need to deal with the redundancy issue. Mark: do we really need to handle multiple attribute sets. Why not just allocate number spaces to various attribute sets, instead of distinct OIDs. What about new attribute types? The global attribute space gets out of control. Makx: proposed set of attributes for addition to BIB-1. Already in STAS. If BIB-1 uses same numbers as already assigned by STAS, no duplication? Need to examine candidate attributes relative to BIB-1? Joe: close BIB-1, and open a new attribute set? Cliff: BIB-1 represents early bibliographic roots of this standard, and has been considered poor. Now there is a group of folks who are experts in this area, who should be defining this (not protocol builders). BIB-1 needs to be handled by a group of appropriate experts, and taken off the table of all of ZIG. The BIB-1 group might need to control the BIB-1 attribute set? Problem: this is a big area, folks are not funded to do this. Bob W.: have BIB-1, STAS, GILS attributes all ORed to same thing, same table. Outside of that, explain takes over, to support dynamically define attributes. If table becomes too big, it's a big problem. Denis: value of BIB-1 is commonality. Adding everything to it is not commonality. Adding everything to one attribute set doesn't gain anything. No reason not to have lots of registered attribute sets, for various information domains. BIB-1 now has problems with what it covers. Have one small well-understood set, like BIB-1, and others which can be discovered, or separately documented. BIB-1 is already too big. In version 2, need one large enumeration of attributes. Perhaps need a brand new attribute set. John's generic attribute set was a good attempt. Related to the metadata efforts. Need to break out of this group, and work with another outside group to create a solution which might be usable within other protocols, as well. The other attribute set will be submitted to the ZIG. A new bibliographic attribute set. This will be discussed with the ZIG. ____________________________________________________________ OIW SIG/LA meeting 9/26/95 Background: Profiles so far: GILS, WAIS, ATS, Z39.50 over TCP/IP. SIG/LA will not approve anything not approved by the ZIG. Agenda: 1. GILS indexing rules. 2. Ray's status report Profiling activities: Profiles for Digital Libraries (Ray). Announced at the Amsterdam meeting the intent to convene a group to discuss a digital library profile. LC has narrowed down the topic somewhat and is proceeding. There are a variety of activities underway under the topic of digital libraries. LC wants to make its collections available via Z39.50, as well as other protocols. We spent 4 years developing V3, and a good portion (80%) addresses requirements posed by digital library applications. Therefore Z39.50 is a good protocol for addressing retrieval of digitized objects, etc. If we don't think about how Z39.50 would be used, it probably would not end up being used, and its functionality would be replicated in other protocols like WWW. Need to profile the parts of the standard which are applicable to digital libraries. LC got support for the idea of driving a Z39.50 profile for digital libraries. Cliff and Ray put together an initial group, which met last Wed. & drafted a strawman profile. At same time, lots of activity in the museum community for solving similar aspects for their community. There are some general models which might apply, but don't cover all aspects. Address base class of DL aspects. Additional profiles could be developed by specific focus groups (eg, museum folks) to build on this base profile. Some concern that all those interested are included in the process. Not try to do in the full ZIG context yet. Do in small body first, and then bring to the ZIG. If there are others with a strong interest in this area, see Ray. Emphasis is Z39.50 access to DL. CIMI (Bill Moen): Consortium for interchange of museum information (CIMI) laid out a document about use of standards for accessing information. CIMI wants to identify standards framework and do demo project to show how 2 standards will be used: SGML and Z39.50. First part last year, using SGML. Second is CHIO access, which will use Z39.50 to provide access to SGML databases and to other museum info: digital objects, thesaurus, collections, records, etc. Bill is project manager for profile development for accessing museum info. Will run for 2 years. Profile in next 6 months. Team includes some from Z39.50 community and some from museum community. Draft profile in spring 96. Implementations starting next spring over next 12-18 months. At end, revisit profile and revise based on experience, then publish final profile. Proof of concept orientation, not necessarily scale to production. Small working group of experts, may not have all perspectives represented. Those strongly interested can contact Bill to participate. Also looking for input from ZIG over the duration. Geospatial profile (Doug Nebert.): USFG required that all Federal Agencies need to document their Geospatial data via their standard. over 300 fields defined. Prototype of this using Freewais/sf. Working with CNIDR to put together GEO profile under ISITE this fall. Extension of GILS profile in a specific domain. The NSF-funded DL projects. Each of the projects is focusing on specific aspects. Stanford, Berkeley, CMU, U of Ill, ... Cliff: interoperability here is viewed as a research topic, rather than real practical issues. Z39.50 is not viewed as a research project by these folks, but these projects have committed to using it, in the interest of providing data to the community. Their knowledge representation issues are very minimally related to our attribute set issues. All of these profiles will be reviewed by the ZIG before going to SIGLA. There are also two other profiles: Item Order ILL profiles. Europe ( Eric): there is a list of European topics, as well. There is a G7 project related to this. Another European project on picture recognition, etc EWOS is the home for European projects working on Z39.50 implementations. Will create profile or baseline implementation to insure interoperability. They will create a technical guide for Z39.50 implementors, serve as implementors agreements. GILS issue (Lisa Weber from NARA). Issue: need guidance on: field which has been indexed and searchable via use attributes. Can locally defined subfields be searched by the same use attribute? Creator field contains set of subelements showing hierarchy of the govt. agency. It depends on how the server defines the index. Why can't the locally defined fields be added to the profile? Creating AACR2 for government agencies. NARA guidance not related to AARC2. Is the profile inadequate, and can it be fixed? Fundamental issue of accommodating hierarchical attribute structure. Perhaps: using complex attribute structure to express a hierarchy of attributes. This is also a requirement for the Geospatial attribute set. This should be addressed by the attribute set subgroup (Cliff et al). How to address this for NARA? Do the NARA guidelines also include strict indexing rules? Is this part of the problem? Reflect the subelements within the profile. Also need to define USE attributes necessary to search the subfields. Local to the hierarchy of the organization. Should make an explicit statement about the relationship of the USE attribute to the retrievable element