======================================================================== Date: Thu, 1 Aug 1991 11:12:18 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Joe Zeeman Subject: ZIG Meeting Minutes Attached are the minutes of the last ZIG meeting, held in Washington on May 20-21. Sorry about the delay. />----------------------------------------------------------------<\ \ Joe Zeeman / / Software Kinetics Ltd \ | 65 Iber Road | \ Stittsville, Ontario voice: (613) 831-0888 / / Canada K2S 1E7 fax: (613) 831-1836 \ \>----------------------------------------------------------------0". Many in the group were uncomfortable with the idea of using a special kind of search to return a subset of a document. It was suggested instead that the ElementSetNames parameter should be used to specify the subdocument to be returned. Since this parameter was currently defined to be a Visible String, it would be impossible to define a structure for its use in version 2 of Z39.50, and WAIS would need to define string values externally to the standard (e.g "BYTES 0-2000"). The definition of a structured means for specifying segmentation of large records for presentation purposes could in the meantime form a work item for version 3. - 15 - Another issue raised was that of document type. Brewster's original proposal included an additional search attribute "document-type". In the course of a very lengthy discussion, it was determined that, although document type could legitimately be used as a search attribute (e.g. "restrict the search to only those documents of type 'WordPerfect'"), its use by WAIS was actually to specify a syntax for presentation of the document. It was therefore felt that the PreferredRecordSyntax parameter was more appropriate for this information. A WAIS search also required additional use attributes, notably an attribute for "items about" and an attribute for relevance feedback. The first attribute was determined to be different from "subject" in that the target is free to apply various tests of relevance and to substitute synomyms, etc. It was decided to call it "conceptual content". The second attribute identifies a document relevant to the search and asks for other items like it. It is therefore a document id in form, and a subject or contextual attribute in meaning. Another issue raised by WAIS was the need for extensible APDUs, to allow experimental data to be transferred between implementors. It was suggested that there already was an agreement to include the UserInformation field in every APDU. Upon examining minutes it was decided that the issue had been raised, but never resolved. It was now too late to include this in version 2 of the standard, but would be proposed for inclusion in version 3. One problem with this kind of extensibility was the danger that it would lead to multiple, mutually unintelligible dialects of the protocol. 24. EXPLAIN service Clifford Lynch presented the current status of work on the explain service. Three models have been proposed. Liv Holm has prepared a first draft of Explain using a separate protocol service; Cliff earlier proposed the use of a special database - WAIS currently uses such a database; Sun Microsystems has recently proposed handling explain by means of special element set names, which would return information relating to the database being searched, attribute sets, etc. - 16 - Each of these models has advantages and disadvantages. The separate service as currently defined does not scale very well, since each kind of explanation is predefined. The special database requires the specification of additional record syntaxes as well as a new search attribute set. It also presents the problem of requiring a target to keep multiple result sets, one for the actual search and one for the explain search. The use of element set names does not handle more global requests for information well, such as provision of a list of all databases. The consensus of the discussion was that the special database approach offered the most flexible way of implementing an explain service, though neither of the other models were precluded by using a database. There were also a number of problems in implementing a database. For instance, it would not be sufficient for a target simply to give a list of attributes supported for each database; what the origin requires to know is what combinations of attributes are supported for a database. Similarly, an explain service based on a database could not easily give an end user guidance or assistance in the form of context-sensitive help. This was, however, seen to be a different problem from Explain, and subject to separate investigation. This item led to a renewed discussion as to where the responsibility for "fuzzying" a search lay. The consensus was that this was a responsibility of the origin system. 25. Z39.50 implementation recognition of SR Object Identifiers Ray Denenberg described and explained the Object Identifier tree structure defined by the ASN.1 standard, and how both SR and Z39.50 would fit in. Most implementors indicated that they would ensure their implementations recognized both SR and Z39.50 object identifiers. 26. Local record syntaxes The related question of how and where to register local record syntaxes was also discussed, at some length. While the OId tree descending from Z39.50 - 17 - (ISO Member-body USA Z39.50 abstract-syntaxes) could easily be extended to allow locally-specified record syntaxes (... local

) there was some question as to how many of these local syntaxes would and should be defined, whether the Z39.50 tree was the most appropriate place to register them, and whether the existence of such local syntaxes would compromise interoperability. An additional problem was that of transfer syntaxes associated with these abstract syntaxes, where these should be registered, and how their use should be negotiated for any given document retrieval. After much discussion, it was decided to postpone any decision until more thought could be given to the matter, with discussion over the list, etc. 27. Comments on Draft 3 of Version 2 There was an inconsistency in the standard in the use of "null result set" and "empty result set". Ray would correct this. The wording of part of section 3.2.2.1.2 still suggested that a query using a result set as an argument would always be unsuccessful: "... prior to processing the query, the existing result set whose name is specified by the parameter Result-set-name will be deleted ..." Ray undertook to find a better wording. The meaning of Maximum-record-size was clarified: it specifies the maximum size of a data record. The message containing this maximum size record will be larger, and systems must make allowance for this. The definitions in Appendix F still required units. Clifford Lynch undertook to send a proposal to the list. 28. Comments on bib-1 attribute set Clifford Lynch raised a number of concerns. Among them were the structure types "year" and "date". The problem with year was that it did not allow for the transmission of BC dates, or dates using any other calendar. The specification of date used an ISO standard format. This , however, placed all the processing burden on the origin. It was desirable to - 18 - allow the transmission of an unnormalized date as well, which the target could process. In the course of discussion it became apparent that there was a requirement to specify the encoding standard(s) used in search terms. The only standard which was mentioned was the prohibition on the use of ASCII space in the year structure. Failure to specify the encoding standard would lead to interoperability problems if one system used ASCII encodings while another used EBCDIC. An additional use attribute for "body-of-text" was agreed upon. 29. APDU test suite In discussion of this item a distinction was made between a test suite, an "exerciser" and a reference implementation. A full test suite would be expensive and complex to develop, and it was generally agreed that what was immediately required was a set of APDUs which could be used to exercise implementations as they were developed and debugged. Jim Michael reported that the question of test suites was currently under study by the Standards Development Committee of NISO. The committee would not be meeting again until after the next ZIG meeting, so comments and requirements could be directed through this group. It was agreed that Michael Thwaites of UC-DLA would act as the focal point for exercise APDUs. 30. MARBI proposal for MARC record for systems Mark Hinnebusch raised this item by mentioning that MARBI has recently issued a discussion paper on a MARC format for describing information systems. The paper had been posted to the list. 31. Any other business Andy Bensky from Sun gave a very brief (the time being 3:00 PM) description of the implementation being planned by Sun. - 19 - 32. Next meeting The next meeting was fixed for 9-10 September at OCLC in Dublin, Ohio. The possibility of beginning the meeting on Sunday the 8th, and running for three days was suggested. - 20 - APPENDIX: KNOWBOTS The following is an excerpt from the Merit LinkLetter, vol. 4, no. 1 (March-April 1991): KNOWBOTS(TM) DELIVER THE GOODS Have you ever wished for a little robot to sit at your workstation and perform the tedious chore of finding and retrieving information from databases distributed around the world? Well, hold onto your keyboards, because the Corporation for Network Research Initiatives (CNRI) is working on a project which is the debut of exactly that kind of tool-one which will automate the searching of multiple disparate databases. CNRI has been working with the National Library of Medicine (NLM) and the National Science Foundation (NSF) on a utility for database searches in the Medline databases of the NLM. All the databases are now accessed via public networks but two of them, ELHILL and TOXNET, will soon be accessible over the Internet, perhaps as soon as June of this year. The work currently being done at CNRI targets the electronic databases at the National Library of Medicine's Lister Hill Center, known as the MEDLARS system. The prototype NLM Multiple Database Access Project was demonstrated recently at the American College of Radiology conference at the Lister Hill Center. The Multiple Database Access Project is part of a larger CNRI project called Digital Library Systems and applies the Knowbot technology of the DLS to the Multiple Database Access effort. Initial project goals nearly complete At the outset of the project, a number of goals were defined which included: 1) providing parallel access to NLM's multiple databases, 2) extending the NLM's form-based user interface for Mac's and PC's (Grateful-Med) to UNIX workstations, 3) supporting non-text information retrieval, and 4) supporting Internet access to the Medline databases. Three of the four are nearly complete. The fourth, supporting non- text information retrieval, is currently under investigation. - 21 - The heart of the project At the heart of the project is the "Knowbot(TM)," (KNOWledge roBOT) an active, intelligent program which acts on behalf of the user to carry out a search and retrieval task. A Knowbot exchanges messages with other Knowbots and moves from one system to another to carry out the user's wishes. When the Knowbot sets out on an assignment several processes occur: - The user interface, which is called the "user agent" contains functions such as query forms and login menus for the various databases available. The user formulates a query on the user agent and presses the "send" button. - The user agent places the query inside a Knowbot and encapsulates it with the appropriate "travel instructions" for traversing the Internet. - The Knowbot is then transmitted across the Internet to the "database server" where it is received and verified. The database server contains software which expedites access to the databases. - Next the database server runs a series of small programs to process the Knowbot: a) the Knowbot's generic syntax is translated into the appropriate syntax for the database being queried; b) the query is sent, which is equivalent to dialing- in to the appropriate database; c) when a response is received it is translated back into the generic syntax of the Knowbot, and the beginning and end of each record is marked. - A Knowbot transports the retrieved records back to the user agent where yet another small Knowbot reformats the response into a friendly syntax which is then displayed to the user. Figure 1 provides a graphic representation of this process. Additional Features An additional option to forms-based access is to open up a "transparent" window to ELHILL, TOXNET, and to a Johns Hopkins Welch Library database: On-line Mendelian Inheritance in Man (OMIM) and the Genome DataBase (GDB). This is, in effect, a telnet screen. - 22 - The window offers direct access to the interactive interfaces of the standard ELHILL, TOXNET, OMIM and GDB systems. (See Figure 1.) It is possible to have multiple Knowbot queries running while simultaneously doing manual interactive searches in this transparent window. In addition, since the user agent stores an encrypted form of the logins for each database, the user only needs to provide login information once for each database accessed. Flexible design The general design of the CNRI system is very flexible with the user agent and database server separable across the Internet. In the present experimental implementation, the user agent typically runs on a SUN 4/110 workstation at CNRI, the database server on a SUN 3/160 at the National Library of Medicine, the two NLM database systems on Telenet (but ELHILL is soon to be accessible on the Internet) and the OMIM and GDB systems via the Internet. Demonstrations using Network Computing Devices X- display stations as well as the SUN 4/110 workstations have been conducted for NLM and for NSF. Looking to the future - short term In the next few months Knowbots will be written to perform multiple searches from a single request. For example, the user will complete one Knowbot search form and the single Knowbot will locate and access multiple Medline databases until it finds the information requested. The current Knowbot-based system will be extended to support queries to databases other than ELHILL and TOXNET. The database server will be enhanced to support queries which are not database specific by making use of information about the contents of the various MEDLARS databases. For the long term Knowbots are general tools for implementing complex, distributed computations, processes and services. Researchers at CNRI and elsewhere are exploring applications of Knowbots as part of a more general examination of a national information infrastructure. - 23 - Looking further into the future, two of many possibilities are: - Resident Knowbot. A Knowbot is instructed to remain resident at a gateway and to query a given database at the time when new citations are posted. The Knowbot is programmed to search for topics of interest to the user; when appropriate citations are located a message is sent to the user listing the citations and their locations. - Image Processing. If a user's personal workstation does not have enough power to quickly process needed calculations, a Knowbot is written to launch the data to a supercomputer where the calculations are completed and returns the results to the user via the Knowbot. Additional CNRI Projects The Corporation for National Research Initiatives is involved in a number of networking research projects in areas of High Speed Digital Networking ("Gigabits"), Digital Library Systems, Inter- Organizational Messaging, and Internet Research. For more information about Knowbots or other CNRI projects, contact: Corp. for National Research Initiatives 1895 Preston White Drive Suite 100 Reston, VA 22091 703/620-8990 -Susan Calcari, Merit/NSFNET ======================================================================== Date: Thu, 1 Aug 1991 14:32:00 CDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: RANDALL@NUACC.BITNET Subject: Meeting Dates (Again) I hate to bring up the subject again, but cheap airfares expire on Sunday... What was the consensus on dates? Will enough people be there on Sunday (9/8) to begin? Is it possible to make the decision in the next 24 hours? Thanks Sara Randall NOTIS Systems, Inc randall@nuacc ======================================================================== Date: Thu, 1 Aug 1991 15:44:02 -0400 Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Eric J Bivona Subject: Re: meeting schedule I can make it for Sunday, if that's what's decided. -Eric Bivona Dartmouth College ======================================================================== Date: Thu, 1 Aug 1991 14:25:20 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Jay Field Subject: Re: meeting schedule REPLY TO 08/01/91 12:48 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": Re: meeting schedule Rich Fuchs and I can make for a Sunday meeting. Jay Field RLG To: Z3950IW@NERVM.BITNET ======================================================================== Date: Thu, 1 Aug 1991 19:57:06 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Final on meeting dates OK, I think there is sufficient interest in starting on Sunday and no outrage although there is some hesitation. Since we need to make a decision now to get the airfares, I will officially declare the next ZIG to begin on Sunday, September 8, at noon and to run until 3 PM on Tuesday, September 10. This should be the least reprehensible schedule as near as I can tell based on the responses I have seen. Ralph, I assume the offer of use of OCLC facilities on Sunday still holds? ======================================================================== Date: Thu, 1 Aug 1991 20:06:38 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Wengyik's paper Gee, Wengyik, now you can't be the "bad boy" anymore :-). Overall, I thought the paper was very well thought out and written. I particularly liked your raising the issue of delivery since I have been thinking about that myself. Locally, my system will take responsibility for moving the results wherever they are needed but that is certainly a specific inplementation solution and not as general as I would like. I'm a little confused by your distinction between attribute searching and index searching. The way I view an index is as an internal implementation of an attribute, nothing more. Systems with only index searching can be viewed as systems with attribute searching where only certain attrbibutes may be searched (i.e. those with an index built for them). In section 9.1, you talk about the many-to-one relationship between information bases and information providers but I would argue that the relationship is really many-to-several and that the directory needs to be able to reflect that relationship. Since it is heirarchical, I think that is easily accomplished. I recognize the validity of your concern about the size of systems that implement both X.500 and Z39.50 but I think it is important to indicate in your paper that that concern is really specific to the intelligent workstation and PC world when you speak of needing a new hardware generation. Finally, I would suggest that the ILL protocol (ISO 10160,10161) may answer some (although not all) of your concerns about delivery and it may be a good starting point for a delivery protocol even though it wasn't designed specifically for that purpose. It does, however, handle non-returnable items such as copies of articles. It may be that with time and work it could be massaged to the point where it would serve both ILL and non-ILL delivery needs. --> Joe, any comment? ======================================================================== Date: Mon, 5 Aug 1991 12:49:49 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: changes to bib-1 attributes My complements to Joe on the minutes. I would like to list agreed upon changes to the bib-1 attributes, according to my notes. These are not in complete accord with the minutes. If anyone who attended the meeting does not concur, let me know as soon as possible. Changes to Use attributes: - Add: body of text date/time added to database date/time last modified authority and format identifier concept-text concept-reference - Delete: NUC code combination of use system control number subject classification Changes to Structure attributes: - Change "date" to "normalized date" - Add: un-normalized date normalized name un-normalized name ======================================================================== Date: Mon, 5 Aug 1991 12:53:03 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "John A. Kunze" [ This message was sent by an automatic mailing program. ] I will not be answering my mail again until August 12. Please direct urgent questions to Susan Stone (sstone@violet) or Margaret Baker (margaret@garnet). ======================================================================== Date: Tue, 6 Aug 1991 18:54:41 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: length restrictions in PDUs I tried to raise this subject last year and no one seemed to want to discuss it much. On page 20 of Z39.50-1988, there were length limitations placed on fields of the PDUs. To be explicit, I quote... ""Identifier" refers to a character string of up to 64 characters... "Integer" refers to an unsigned integer whose value is between zero and 16,777,215." The current draft of version 2 has no such limitations. While it may be inappropriate to define those limits within the protocol (even though ASN.1 allows it) I believe that we must define them in the profile, otherwise interoperability will become impossible. For instance, if I decide that Implementation-ID can be no more than 64 characters and you send me one that is 80 characters, we don't talk. The whole point of our group is to guarantee that we talk. So let's talk about this! Terry is at a point in our implementation where he needs answers. I personally like limiting integers to 2**31-1 (16,777,215?). I can live with identifiers being no more than 64 characters, but I think it might be limiting for database names. I would rather propose 255 as the maximum number of characters in an identifier. I will go higher if someone wants to. The point is, WE MUST DECIDE. ======================================================================== Date: Tue, 6 Aug 1991 19:06:59 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: IBM OSI/CS Recursion Support In-Reply-To: Message of Tue, 06 Aug 91 17:21:25 EDT from I took care of it...delete away. ======================================================================== Date: Wed, 7 Aug 1991 07:47:07 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" Comments: Resent-From: "Mark Hinnebusch, FCLA" Comments: Originally-From: "Michael Thwaites" From: "Mark Hinnebusch, FCLA" > Mark - > > Is it time to visit Profiling again? I unfortunately missed the > first visit to the topic ;-). The point of profiling is to come to agreements on those issues about which the protocol is silent, those that are "outside" of the protocol, and to decide which options provided by a protocol will be chosen. In the ISO/OSI world , conformance to a standard does not guarantee inter- operability. That is why profiling is needed. > Seems to me there are a whole mess > of limitations an implementation is going to have. And some of > them depend on each other. For instance, our implementation will > not allow integers (or tags for that matter) greater than > 2,147,483,647. All the 'string' types (octet strings, visible > strings, bit strings, etc.) are limited to 32,767 bytes. But the > BER encoded APDU itself can't be anywhere near that long (more like > 3k - so I guess the actual limit is smaller than that.) That is the point that I am making. We all have limitations of one sort or another. The IBM ASN1 compiler makes that painfully obvious by insisting on length definitions in the ASN1 and by building static structures based on that length. Even if a field is variable length, it makes you define a maximum length and builds the structure of that length. It does this even for C which provides a very nice dynamic allocation scheme which you cannot use with the ASN1 compiler. > Does this discussion of lengths depend on your method of > implementation? The C and PL/I implementations probably have more > flexibility than ones in COBOL. I think that the size restrictions will be more dependent on the hardware platform than the language although there is no doubt that C and PL/I are more flexible. At least they allow dynamic allocation. (My apologies to COBOL if it does; I have always avoided learning it.) --mark > mjt ======================================================================== Date: Wed, 7 Aug 1991 12:49:48 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Joe Zeeman Subject: Re: changes to bib-1 attributes In-Reply-To: ; from "Ray Denenberg - LC" at Aug 5, 91 12:49 pm Ray's tabulation of changes to attributes corresponds with my manuscript notes of the meeting, with one exception: my notes have "concept-type" rather than "concept-text". As I recall, these two attributes were generated from the earlier "conceptual content" (a revisiting of an agenda item which didn't make it into the minutes - sorry). My recollection is that concept-reference was meant to be a numeric reference id for a concept to be matched, and concept-type (or term) was meant to be an expression of a concept. "Type" was preferred to "text" because the concept was not necessarily meant to be a string that was matched, but could generate a whole set of strings to be matched. Perhaps someone who feels more strongly about it than I do would like to argue for "text" vs "type". The deletions stem from the Atribute set explanatory annex (ZIG 91-009). They were briefly discussed before being accepted, but the discussion never got into my notes. -- />----------------------------------------------------------------<\ \ Joe Zeeman / / Software Kinetics Ltd \ | 65 Iber Road | \ Stittsville, Ontario voice: (613) 831-0888 / / Canada K2S 1E7 fax: (613) 831-1836 \ \>---------------------------------------------------------------- Sender: "Z39.50 Implementors Workshop" From: Michael Thwaites Subject: Where do we talk about limits? Mark - If the profiling is for stuff outside the protocal, shouldn't all these limits be in the profile? Or are you saying these limits are somehow different than the stuff regulated/disseminated in the profile? Michael ======================================================================== Date: Thu, 8 Aug 1991 08:18:53 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: Where do we talk about limits? In-Reply-To: Message of Wed, 7 Aug 1991 13:09:02 PST from No, I am saying that the limits should be in the profile. By "profile", I mean the common profile that we all agree to us, not individual system "profiles". ======================================================================== Date: Thu, 8 Aug 1991 08:34:38 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Francois Schiettecatte Subject: mailing list Could you put me on your mailing list my internet address is francois@welchlab.jhu.edu thanks ======================================================================== Date: Thu, 8 Aug 1991 06:25:49 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: limits and profiles Limits belong in the profile -- or more accurately, in the document we have been calling the "profile PICS proforma". The new term, though, is "Profile PICS Requirement List", PRL. Back in early 1990 we came up with some limits (the original draft, 3/90, specified some) but at the 7/90 meeting it was decided to remove most of them. That's the last time we discussed the profile so it's probably time to revisit it. There is a new draft of the SR PICS proforma (a PRL is obtained by annotating the PICS proforma). A revised Z39.50 PICS Proforma is being developed (based on the new SR draft PICS proforma) and a corresponding new PRL. I'll bring these to the meeting (SR PICS Proforma, Z39.50 PICS Proforma, and Z39.50 PRL). We should discuss limits in the context of these documents. If the documents themselves are deficient for our purposes, then we need to develop input for a U.S. position on the SR PICS Proforma draft. ======================================================================== Date: Thu, 8 Aug 1991 10:47:59 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: limits and profiles In-Reply-To: Message of Thu, 8 Aug 1991 06:25:49 PDT from I can defer discussion of limits to the meeting when we can discuss them in the context of the PICS Proforma as Ray suggests. ======================================================================== Date: Fri, 9 Aug 1991 08:11:00 EST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: AUTOMATION Subject: SUBSCRIBE Bob Carterette SUBSCRIBE Bob Carterette ======================================================================== Date: Mon, 12 Aug 1991 16:58:26 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Lennie Stovel Subject: Re: changes to bib-1 attributes REPLY TO 08/07/91 09:50 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": Re: changes to bib-1 attributes I agree with Joe and Ray about the changes to attributes as a result of the last meeting - mostly. Here are two questions: - I wrote down that we agreed to add a Use attribute for date last requested (along with date added and date modified). I'm not sure it survived the cut, however. - The discussion about normalized names referred only to personal names, didn't it? (Michael T?) So shouldn't the two new Structure attributes be normalized personal name and un-normalized personal name? One more point: I'm not too fond of "un-normalized". How about if the Structure attributes are date, normalized date, name, and normalized name? And another: if the date can be normalized or not, what about the time (in Use attributes date/time added and date/time modified)? Madeleine (Lennie) Stovel Bitnet: bl.mds@rlg.bitnet Research Libraries Group, Inc. Internet: bl.mds@rlg.stanford.edu 1200 Villa Street Phone: (415) 691-2259 Mountain View, CA 94041-1100 Fax: 415-964-0943 To: Z3950IW@NERVM.BITNET ======================================================================== Date: Mon, 12 Aug 1991 18:05:48 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Michael Thwaites In replay to Lennie's comments: >... The discussion about normalized names referred only to personal >names, didn't it? (Michael T?) ... That is the way I remember it. >One more point: I'm not too fond of "un-normalized". How about if >the Structure attributes are >date, >normalized date, >name, and >normalized name? I like the simpler names too. Michael T. ======================================================================== Date: Mon, 12 Aug 1991 17:11:22 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: dml@MOZART.ESL.COM Is there a way to catch up on what's going on here (archive, draft documents, etc.)? Thanks, --Denis Lynch, ESL Inc. ======================================================================== Date: Mon, 12 Aug 1991 19:20:56 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" Comments: Warning -- original Sender: tag was brewster@QUAKE.THINK.COM From: Brewster Kahle Subject: Z39.50 background In-Reply-To: dml%MOZART.ESL.COM@pucc.PRINCETON.EDU's message of Mon, 12 Aug 1991 17:11:22 PDT <9108130108.AA16579@Early-Bird.Think.COM> Date: Mon, 12 Aug 1991 17:11:22 PDT From: dml%MOZART.ESL.COM@pucc.PRINCETON.EDU Is there a way to catch up on what's going on here (archive, draft documents, etc.)? Thanks, --Denis Lynch, ESL Inc. There is an ftp site for z39.50 documents at /public/wais/z3950/*@think.com and there are wais servers (wais-docs and wais-discussion-archive) that some of the material is on. -brewster Brewster Kahle Thinking Machines Corporation Brewster@Think.com 1010 El Camino Real Project Leader Menlo Park, CA 94025 Wide Area Information Servers 415-329-9300x228 ======================================================================== Date: Tue, 13 Aug 1991 07:24:01 TZONE Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Andrew Gosling (0734) 318431" Subject: CLSI Sites Apologies to those of you on both lists. The University of Reading in the UK is in the first stages of planning a campus information server. The Library and Computer Services Centre both have hardware which may be suitable. Please is anyone running the CLSI Library Information System and a general campus information server out of the same Sequent box, and can spare a few minutes for a chat over email? Many thanks in anticipation, Andrew Gosling Deputy Director of Computer Services ======================================================================== Date: Sat, 17 Aug 1991 13:15:07 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" Comments: Warning -- original Sender: tag was brewster@QUAKE.THINK.COM From: Brewster Kahle Subject: length restrictions in PDUs In-Reply-To: "Mark Hinnebusch, FCLA"'s message of Tue, 6 Aug 1991 18:54:41 EDT <9108062317.AA18475@Early-Bird.Think.COM> Limiting integers to less than 16million in your implementation should be fine for now, but the standards should have no such limitation. Since you are likely to not work with large documents, you should not run into problems. We are using 32 bit numbers for all of our integers which will do for current document sizes. MegaByte images are now becoming standardly used on the WAIS system. I dont expect that it will remain that small for long. We are starting to get into the gigabit network group which can make video commonplace. -brewster Date: Tue, 6 Aug 1991 18:54:41 EDT From: "Mark Hinnebusch, FCLA" I tried to raise this subject last year and no one seemed to want to discuss it much. On page 20 of Z39.50-1988, there were length limitations placed on fields of the PDUs. To be explicit, I quote... ""Identifier" refers to a character string of up to 64 characters... "Integer" refers to an unsigned integer whose value is between zero and 16,777,215." The current draft of version 2 has no such limitations. While it may be inappropriate to define those limits within the protocol (even though ASN.1 allows it) I believe that we must define them in the profile, otherwise interoperability will become impossible. For instance, if I decide that Implementation-ID can be no more than 64 characters and you send me one that is 80 characters, we don't talk. The whole point of our group is to guarantee that we talk. So let's talk about this! Terry is at a point in our implementation where he needs answers. I personally like limiting integers to 2**31-1 (16,777,215?). I can live with identifiers being no more than 64 characters, but I think it might be limiting for database names. I would rather propose 255 as the maximum number of characters in an identifier. I will go higher if someone wants to. The point is, WE MUST DECIDE. ======================================================================== Date: Sat, 17 Aug 1991 16:37:00 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: wald@MHUXD.ATT.COM I will be gone till around August 26 - I will handle your mail at that time. If you need help before then contact my supervisor Dave Nowitz mhuxd!dan 908 582-4821 Bob Waldstein mhuxd!wald AT&T Bell Labs ======================================================================== Date: Mon, 19 Aug 1991 09:19:27 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: length restrictions in PDUs In-Reply-To: Message of Sat, 17 Aug 1991 13:15:07 PDT from Brewster, I really want to have the profile define something that Thinking Machines can not only live with but intends to use in the near and intermediate (next 3 years?) future. The unfortunate thing about profiles is either you are in or you are out. I personally would like to be able to aim my Z39.50 machine at your Z39.50 machine and have it work but not have it be a WAIS machine. If you "sort of" follow the protocol I don't have a chance of an ice cube... Actually, you may be surprised to find that some of your customers might want to aim at a library every once in a while. If you use a superset, you may prevent that. At any rate, let's define any necessary limits in the profile in such a way that ALL members of the ZIG can use them. I don't think that is impossible. ======================================================================== Date: Mon, 19 Aug 1991 13:53:46 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Lee C. Varian" Subject: Re: length restrictions in PDUs In-Reply-To: Message of Tue, 6 Aug 1991 18:54:41 EDT from On Tue, 6 Aug 1991 18:54:41 EDT you said (in part): >I tried to raise this subject last year and no one seemed to want to >discuss it much. On page 20 of Z39.50-1988, there were length >limitations placed on fields of the PDUs. To be explicit, I quote... > >""Identifier" refers to a character string of up to 64 characters... >"Integer" refers to an unsigned integer whose value is between zero >and 16,777,215." > >Terry is at a point in our implementation where he needs answers. I >personally like limiting integers to 2**31-1 (16,777,215?). Mark, Actually, 2**31-1 is 2,147,483,647 (not quite as small as 16 million) and 2**24-1 is 16,777,215. Lee Varian, Princeton University ======================================================================== Date: Mon, 19 Aug 1991 11:12:57 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" Comments: Warning -- original Sender: tag was brewster@QUAKE.THINK.COM From: Brewster Kahle Subject: length restrictions in PDUs In-Reply-To: "Mark Hinnebusch, FCLA"'s message of Mon, 19 Aug 1991 09:19:27 EDT <9108191330.AA01920@Early-Bird.Think.COM> Date: Mon, 19 Aug 1991 09:19:27 EDT From: "Mark Hinnebusch, FCLA" Brewster, Mark, I must have said something wrong. I am trying to interoperate as hard as I can. I am spending over $100k to push this standard. My point meant to be (I probably put it wrong) was that the protocol should allow for large documents. An implemenation of a server might only handle small documents if it only wants to serve small documents, but the protocol should not disallow large servers. I think we are actively agreeing. -brewster ======================================================================== Date: Mon, 19 Aug 1991 14:57:34 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: length restrictions in PDUs In-Reply-To: Message of Mon, 19 Aug 1991 11:12:57 PDT from I agree that we have to ba able to provide for the small server. I am more concerned with a small client not being able to handle a big server. However, I agree that we are agreeing. E-communication is **SO** much harder than face-communication. See you in Dublin ======================================================================== Date: Tue, 20 Aug 1991 17:39:34 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Franklin Davis Subject: Informations on ZIG, Z39.50 In-Reply-To: "Mark Hinnebusch, FCLA"'s message of Mon, 15 Jul 1991 10:03:52 EDT <9107151417.AA00481@Early-Bird.Think.COM> Date: Mon, 15 Jul 1991 10:03:52 EDT From: "Mark Hinnebusch, FCLA" Brewster, Should I infer from this that you have moved the stuff on the ftp server from the z3950 directory to the public\z3950 directory? Hi, Mark-- I don't know if this question was answered. In fact, the archives HAVE been moved, to /public/wais/z3950. When you login to think.com for anonymous ftp you are already in /public, so you need only change directory to wais/z3950. This should be publicized. --Franklin ======================================================================== Date: Mon, 26 Aug 1991 14:24:00 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: mhuxd!wald@ATT.ATT.COM Subject: SilverPlatter Am reading an article in Advanced Technology Libraries, vol 20, no 8, Aug 91 titled "SilverPlatter develops data exchange standard" on pg 8. Basically the gist is (quote - typos guaranteed): SilverPlatter Information has announced the development of a Data Exchange Standard for its databases. The company will complete the split of its search engine from its user interface by Summer 1992 and will specifyu in detail the way the two connect, making the data stored on SilverPlatter's databases available using any interface. Although SilverPlatter is developing this standard, it is also actively participating in the NISO Standards Committee and will concur with the formal standards specifications that may result from that committee. Anyone know if they plan to use Z39.50?? This is what i have been hoping for, but please, not another standard!! Now if i can get the network to work, the contracts legal, the interface fully working, the ... Robert K. Waldstein AT&T Bell Laboratories (in the Library Network) Room 3D-591 600 Mountain Avenue Murray Hill, New Jersey 07974 Email: wald@mhuxd.att.com Phone: (908) 582-6171 ======================================================================== Date: Mon, 26 Aug 1991 15:09:20 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: SilverPlatter In-Reply-To: Message of Mon, 26 Aug 1991 14:24:00 EDT from To the best of my knowledge, SilverPlatter is not using Z39.50. I think that they are probably refering to the CD-RX standard which is also being developed under NISO auspices. I don't know a lot about CD-RX but I **think** that it specifies commands for CD-ROM systems, more like the Common Command Language (Z39.58) than Z39.50. ======================================================================== Date: Mon, 26 Aug 1991 15:47:43 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Joe Zeeman Subject: Re: SilverPlatter In-Reply-To: ; from "Mark Hinnebusch, FCLA" at Aug 26, 91 3:09 pm Mark; Do you (and/or anyone else) know of any formal or informal liaison/coordination between the two standard groups (Z39.50 and CD-RX)? I'm sure that many of the implementors in this goup would be VERY interested in offering access/building targets for CD-ROMs. My recollection of Cliff's description of this is that it is at a lower level than Z39.50. This would suggest that it might be possible to build a generalized Z39.50 target which could interface to many/all CD-ROMs that implement this CD-RX protocol. -- />----------------------------------------------------------------<\ \ Joe Zeeman / / Software Kinetics Ltd \ | 65 Iber Road | \ Stittsville, Ontario voice: (613) 831-0888 / / Canada K2S 1E7 fax: (613) 831-1836 \ \>---------------------------------------------------------------- Sender: "Z39.50 Implementors Workshop" From: dml@MOZART.ESL.COM Where does a person find the definitions of the various search response RecordSyntaxes? Do any of the RecordSyntaxes defined in Appendix E support returning text in an SGML tagged form? Brewseter Kahle -- how are you planning to have WAIS return document bodies when you convert to Z39.50 V2? Thanks for the help on such simple stuff. --Denis Lynch, ESL Inc. ======================================================================== Date: Tue, 27 Aug 1991 08:48:19 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Lennie Stovel Subject: user defineable interfaces Some ideas from another list... To: Z3950IW@NERVM FORWARDED MESSAGE 08/21/91 15:37 FROM PACS-L@UHUPVM1.BITNET "Public-Access Computer Systems Forum": user defineable interfaces Received: by UCBCMSA (Mailer R2.04) id 5332; Wed, 21 Aug 91 15:36:03 PDT Date: Wed, 21 Aug 1991 17:33:23 CDT Reply-To: Public-Access Computer Systems Forum Sender: Public-Access Computer Systems Forum From: Lou Rosenfeld Subject: user defineable interfaces To: Karen Smith-Yoshimura , Lennie Stovel , Marilyn Roche , Steve Hunt , Stephen Lloyd Sorensen ----------------------------Original message---------------------------- I want to continue last week's discussion on user defineable interfaces. I have been especially interested in the ideas expressed by Sanjay Chadha, Jim Morgan, Jim Hobbs, and Thom Gillespie. I've tried to capture some of my ideas on this topic below, and hope they will spur further discussion. (My apologies for its verbosity.) --Lou Rosenfeld, University of Michigan, lou@csmil.umich.edu CUSTOMIZEABLE USER INTERFACES TO INFORMATION SYSTEMS (...OR USER DEFINEABLE? OR USER CONFIGUREABLE?...) Today, consumers of information products are confronted with almost as many interfaces and retrieval engines as there are products. This problem of interface overload makes research both confusing and inefficient. The information industry may be able to remedy this problem by adopting standards that enable the creation of a common interface to multiple products. The use of standard searching protocols that work with different products in a networked multi-platform environment would require users to learn only a single interface to satisfy their information needs. Once a standard interface/method of information access is in place, it may be possible to then create customized interfaces for each individual user. These custom user interfaces would be configureable along many dimensions: user's hardware configuration, user's preferred software interface (command-line vs. GUI), user's preferred search language, etc. Thus, instead of a single interface for each product, as is the situation today, the interface and retrieval tools could be configured to serve each individual user in the most effective way possible. REQUIREMENTS % client/server architecture Interface/retrieval clients and database servers allow the user's interface to be separated from the actual data. % a networked environment The network (Internet?) provides a single point of access to many distributed databases and allows them to be searched simultaneously. Thus, retrieval from many different databases can be presented together from a common interface. % user profile/configuration files accessible from the network The network allows the user to be physically anywhere and have access to his or her customized interface. % standard protocols for queries Users "speak different languages" in terms of linguistics, search languages, etc. The customizeable interface would have hooks which allow it to translate these different languages into a standard query protocol (Z39.50?). % standard protocols for data structures (?) Data may or may not need to exist in a standardized format (Z39.58?) for all this to work. % flexible configurations Some intelligence must be built into the customizeable interface that would enable it to "query the user's situation," i.e., allow it to know and configure itself to the user's present hardware, etc. CUSTOMIZEABLE FEATURES There seem to be two types of features which could be customized. One group could consist of the user's personal preferences, and would include preferred look and feel, types of search aids and query languages employed, etc. The other group is dependent on the user's situation (or predicament). This group would include features which must be flexible because the user can not, such as physical handicap, native language, or being stuck with a specific hardware configuration. CUSTOMIZEABLE FEATURES BASED ON USER TASTES % "look and feel" The user may prefer a WIMP interface (window, icon, menu, pointer) to a character-based look, or may prefer certain fonts, colors, etc. Much of this will depend on what the hardware configuration will allow. % search/query languages The user could search DIALOG with BRS commands if that's what he or she prefers, or could simply use natural language. % retrieval algorithms and document output schemes Content searching (WAIS), or concept tree searching (Verity TOPIC) could be employed instead of Boolean searching. This would allow a relevance-ranked retrieval of a database normally searched by hit-or-miss Boolean statements. Or the user may be more comfortable with more familiar Boolean and keyword retrieval. % preferred databases In the case of OPACS, the user may wish to have only the geographically closest ones searched. In the case of commercial online databases, the user may wish to have searches executed on the least expensive databases first. % current awareness Saving of searches and having them reexecuted at specified intervals is a logical extension of a saved user interface. CUSTOMIZEABLE FEATURES BASED ON THE USER'S SITUATION % hardware and operating systems The user may be confronted with many of these in a single day; the interface must be flexible to the environment in which it is working and respond to it. Actually, this means that there would really be multiple user interfaces dependent on the hardware in use. % language Another variable dependent upon the user and yet not changeable by the user. % portability The custom interface must be flexible enough to accommodate whatever hardware and operating system is available at the moment. In other words, a user might have different configurations depending on the environment he or she is operating in (e.g., the Mac with a mouse at home, the Sun workstation with in-the-box video at work). ======================================================================== Date: Wed, 28 Aug 1991 08:06:35 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: FINAL MEETING ANNOUNCEMENT Better late than never... This is the OFFICIAL call for attendance for the next Z3950 ZIG, to be held at OCLC, in Dublin, Ohio, USA, starting at noon on Sunday, September 8, 1991 and terminating at 3 pm on Tuesday, September 10. If you plan on attending, please respond to this list so that Ralph can get a seat count. Also, if you wish to take Ralph up on his gracious offer of a Sunday barbeque please so indicate. This is also the first call for agenda items. -mark ======================================================================== Date: Wed, 28 Aug 1991 08:21:03 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Tom Owens Subject: mit attendance MIT will be sending two people to the ZIG in Dublin. See you there. -- Tom Owens MIT Library Systems Office 617-253-1618 owens@athena.mit.edu ======================================================================== Date: Wed, 28 Aug 1991 08:22:07 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark Hinnebusch, FCLA" Subject: Re: FINAL MEETING ANNOUNCEMENT In-Reply-To: Message of Wed, 28 Aug 1991 08:06:35 EDT from I will be attending both the ZIG and the BAR-B-Q. Ralph, what does the well-dressed Dublin cowboy wear? --mark ======================================================================== Date: Wed, 28 Aug 1991 09:19:50 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ralph LeVan Subject: Re: FINAL MEETING ANNOUNCEMENT You know, I haven't seen anything cowboy like since I've moved here. Personally, shorts and a Hawaiian shirt will be the dress of the day on Sunday, both for the meeting and the barbeque. Ralph Ralph LeVan Internet: rrl@rsch.oclc.org Online Computer Library Center UUCP: ...!saqqara!sppy00!rrl 6565 Frantz Rd, Dublin OH 43017 Phone: (614) 764-6115 ======================================================================== Date: Wed, 28 Aug 1991 09:07:33 CDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: JIM MICHAEL-DATA RESEARCH Subject: RE: FINAL MEETING ANNOUNCEMENT Sean and I will be attending from Data Research. Jim ======================================================================== Date: Wed, 28 Aug 1991 09:08:39 CDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: JIM MICHAEL-DATA RESEARCH Subject: RE: FINAL MEETING ANNOUNCEMENT Include us in the barbeque too. Jim ======================================================================== Date: Wed, 28 Aug 1991 09:55:16 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Peter Ryall Subject: Re: FINAL MEETING ANNOUNCEMENT In-Reply-To: Mail from '"Mark Hinnebusch, FCLA" ' dated Wed, 28 Aug 1991 08:06:35 EDT I will be attending for Mead Data Central all 3 days, & would also like to participate in the barbecue - let us know if you want us to bring anything edible - otherwise I will just make a monetary contribution. As for the agenda, I would like to offer up the following items: 1. Persistent Result Sets: this item includes a rough proposal for the designation of the 'lifetime' of a set (either the lifetime is only the duration of the association, or it persists across associations), as well as implied 'aging' mechanisms necessary to ensure that sets do not remain alive indefinitely. The item would also include a proposal for set man- agement (e.g, add, replace, delete set records, create new sets independent of a search), & manipulation (e.g, sort, filter by criteria, partition by record type, combine multiple sets through union & intersection) functions invoked from the Origin. Finally, I propose that this item, or possibly a separate item, include a discussion of the possibility of standardizing a 'common' set of record elements which describe the demographics (or basic descriptive metadata) of the set itself, which is consistent across all types of target data bases (e.g, date/time of creation, original search query, target data base name/ID, title/description of information returned in each record, etc.) 2. Periodic Search Service: a rough proposal for a new set of parameters in the Search request which designate the duration (total lifetime) of a Periodic Search at the specified target, the periodicity (e.g, daily, weekly real-time continuous, etc.), the requested asynchronous delivery mechanism (e.g, E-Mail, FAX, etc.), & possibly a desired time for delivery of results. 3. Proposal for a new attribute set for use in searching company/financial or news-oriented target data bases: these new use attributes could also be included as extensions to the BIB-1 standard attribute set. I would expect a good deal of discussion on this topic, & would be interested to hear the views of other members on the definition of new, separate use attribute sets. I look forward to seeing everyone again & participating in some lively and constructive discussions.. ======================================================================== Date: Wed, 28 Aug 1991 11:06:00 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Eric G. Ferrin" Subject: Re: FINAL MEETING ANNOUNCEMENT Penn State will be sending two reps Sun thru Tues. ======================================================================== Date: Wed, 28 Aug 1991 09:42:25 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Lennie Stovel Subject: FINAL MEETING ANNOUNCEMENT REPLY TO 08/28/91 05:12 FROM Z3950IW@NERVM.BITNET "Z39.50 Implementors Workshop": FINAL MEETING ANNOUNCEMENT Four people from RLG will attend the ZIG meeting -- that's three definite and one probable. Ditto the BBQ -- will let you know about the probable. Madeleine (Lennie) Stovel Bitnet: bl.mds@rlg.bitnet Research Libraries Group, Inc. Internet: bl.mds@rlg.stanford.edu To: Z3950IW@NERVM.BITNET ======================================================================== Date: Wed, 28 Aug 1991 09:51:27 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" Comments: Warning -- original Sender: tag was morris@QUAKE.THINK.COM From: Harry Morris Subject: attendance Brewster and I will be there from Thinking Machines meetings and BBQ! ======================================================================== Date: Wed, 28 Aug 1991 09:14:04 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Janet Vratny-Watts Subject: Re: FINAL MEETING ANNOUNCEMENT In-Reply-To: Message from "Mark Hinnebusch, FCLA" of Aug 28, 91 at 8:06 am There will be 2 of us from Apple (I will attend Sun-Tues; I will be joined by Steve Wolfe on Mon-Tues). I will be attending the BBQ on Sunday as well. Thanks! Janet Vratny-Watts Apple Library ======================================================================== Date: Wed, 28 Aug 1991 09:56:25 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Clifford Lynch I believe that there will be 4 of us from the office of the president at uc. Clifford ======================================================================== Date: Wed, 28 Aug 1991 13:06:16 -0400 Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Eric J Bivona Subject: Re: FINAL MEETING ANNOUNCEMENT I'll be attending the meeting (Sunday thru Tuesday) and the BBQ. -Eric Bivona Dartmouth College ======================================================================== Date: Wed, 28 Aug 1991 10:47:20 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Margery Tibbetts David Loy will be attending the meeting representing DIALOG. ======================================================================== Date: Wed, 28 Aug 1991 11:03:22 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Larry Dixson and I will be there. BBQ too. ======================================================================== Date: Wed, 28 Aug 1991 11:24:23 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Jack_Greenfield@NEXT.COM Please count me in also, for both the BBQ and the meeting. Yes, I'm still alive, for those of you who were wondering... you wouldn't believe how much other non- related stuff I have had to work on since the last meeting. I've been following along with one eye on the net. We have finally started hacking, however, and by the time I come, there may be some results worth reporting. J. ======================================================================== Date: Wed, 28 Aug 1991 12:06:20 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "John A. Kunze" Subject: RE: FINAL MEETING ANNOUNCEMENT I'll be at the meeting and BBQ. ======================================================================== Date: Wed, 28 Aug 1991 12:50:00 -0700 Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark H. Needleman" Subject: attend Ralph Ill be there. The barbeque sounds like fun Mark Needleman ======================================================================== Date: Wed, 28 Aug 1991 12:53:58 -0700 Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: "Mark H. Needleman" Subject: dla Ralph Forgot to mention that Michael Thwaites Margery Tibbets and Clifford Lynch will also be there. I dont know their plans for the barbeque so I assume they will let you know mark ======================================================================== Date: Wed, 28 Aug 1991 16:46:56 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Tom True Subject: FINAL MEETING ANNOUNCEMENT REPLY TO 08/28/91 08:06 FROM FCLMTH@NERVM.BITNET "Mark Hinnebusch, FCLA": FINAL MEETING ANNOUNCEMENT I'll be there and would also like to be at the barbecue. Tom True Princeton University CIT - Advanced Applications TDTRUE@PUCC.PRINCETON.EDU (609) 258-6064 ======================================================================== Date: Wed, 28 Aug 1991 14:42:21 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: agenda items I wish to submit the following agenda items: 1. Z39.50 version 2, draft 4 (V2D4) -- distributed at meeting 2. Profile o SR PICS Proforma o Z39.50 PICS Proforma o ZIG PRL These three documents to be distributed at meeting. "PRL" replaces the old "profile PICS" and stands for "Profile PICS Requirements List". 3. Z39.50 Enhancements Will bring document to the meeting which will serve as Maintenance Agency mechanism for tracking enhancements. 4. Maintenance Agency registration of implementors ======================================================================== Date: Wed, 28 Aug 1991 18:55:09 -0400 Reply-To: yeongw@psi.com Sender: "Z39.50 Implementors Workshop" From: yeongw@SPARTACUS.PSI.COM Subject: Re: FINAL MEETING ANNOUNCEMENT In-Reply-To: Your message of Wed, 28 Aug 91 08:06:35 -0400. <9108281209.AA17095@psi.com> > Better late than never... > > This is the OFFICIAL call for attendance for the next Z3950 ZIG, > to be held at OCLC, in Dublin, Ohio, USA, starting at noon on Sunday, > September 8, 1991 and terminating at 3 pm on Tuesday, September 10. If > you plan on attending, please respond to this list so that Ralph can > get a seat count. Also, if you wish to take Ralph up on his gracious > offer of a Sunday barbeque please so indicate. > > This is also the first call for agenda items. > I will not be attending, sigh. Wengyik ======================================================================== Date: Thu, 29 Aug 1991 08:32:36 LCL Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" Comments: W: Invalid RFC822 field -- "From jh Thu Aug 29 08:". Rest of header flushed. Comments: E: "From:"/"Sender:" field is missing. From: Undetermined origin c/o Postmaster There will be 3 of us attending from Duke - Gail Corrado, Boris Vychodil and Juraj Horacek. Meetings & BBQ. ======================================================================== Date: Thu, 29 Aug 1991 08:39:51 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" Comments: Warning -- original Sender: tag was brewster@QUAKE.THINK.COM From: Brewster Kahle Subject: FINAL MEETING ANNOUNCEMENT In-Reply-To: "Mark Hinnebusch, FCLA"'s message of Wed, 28 Aug 1991 08:06:35 EDT <9108281212.AA11519@Early-Bird.Think.COM> Date: Wed, 28 Aug 1991 08:06:35 EDT From: "Mark Hinnebusch, FCLA" Better late than never... This is the OFFICIAL call for attendance for the next Z3950 ZIG, to be held at OCLC, in Dublin, Ohio, USA, starting at noon on Sunday, September 8, 1991 and terminating at 3 pm on Tuesday, September 10. If you plan on attending, please respond to this list so that Ralph can get a seat count. Also, if you wish to take Ralph up on his gracious offer of a Sunday barbeque please so indicate. This is also the first call for agenda items. -mark 3 from Thinking Machines: Harry Morris, Ottavia Bassetti, Brewster Kahle. -brewster ======================================================================== Date: Thu, 29 Aug 1991 10:23:30 PST Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Margery Tibbetts Aug. 29, 1991 Ralph, Michael Thwaites, David Loy and I will be attending the barbeque. Margery ======================================================================== Date: Thu, 29 Aug 1991 15:59:00 CDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: John Kolman <#L43JMK@LUCCPUA.BITNET> Subject: Re: FINAL MEETING ANNOUNCEMENT This is a confirmation and agenda topic for Sara Randall -- NOTIS Systems who will be attending both the meeting and barbecue. --------------------------------------------------- I would like to add the topics of "explain" and "browse" to the meeting agenda. There have been previous discussions on both of these topics. I understand that both topics are work items for ISO TC 46. However NOTIS needs to implement this functionality in the next 3-6 months. It is my impression that things are not moving that fast at the international level. I believe several other implementors have done their own extensions for either explain or browse since they also needed functionality immediately. NOTIS could take the same approach, but we would prefer to move toward something that has a chance of being interoperable. If anyone has more detailed information about the approach that ISO TC 46 is using for either topic, we could use that as a starting point. Otherwise I would like to use Wengyik's proposal for the explain extension that appeared on list 9/30/90. NOTIS has some ideas about browse that could be discussed. Sara Randall Systems Analyst NOTIS Systems ======================================================================== Date: Thu, 29 Aug 1991 17:20:12 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Terry Sullivan Subject: Re: FINAL MEETING ANNOUNCEMENT In-Reply-To: Message of Wed, 28 Aug 1991 08:22:07 EDT from Add one more from FLCA, Sunday thru Wensday. BBQ too. I look forward to meeting everyone. TPS ======================================================================== Date: Thu, 29 Aug 1991 17:32:29 EDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Joe Zeeman Subject: Re: FINAL MEETING ANNOUNCEMENT In-Reply-To: ; from "John Kolman" at Aug 29, 91 3:59 pm I shall be attending both meeting and barbecue, assuming that it is in fact possible to travel from Ottawa to Dublin. To further Sara's agenda item: a "draft addendum" specifying a browse service was distributed earlier this month to the working group of ISO TC 46. It strikes me that this might serve as a useful basis for discussion. I expect that both the US and Canadian members of the working group will be interested to know what real live implementors have to say about the proposal. -- />----------------------------------------------------------------<\ \ Joe Zeeman / / Software Kinetics Ltd \ | 65 Iber Road | \ Stittsville, Ontario voice: (613) 831-0888 / / Canada K2S 1E7 fax: (613) 831-1836 \ \>---------------------------------------------------------------- Sender: "Z39.50 Implementors Workshop" From: dml@MOZART.ESL.COM I will be attending both the meeting and the barbeque. Can somebody e-mail me directions to the meeting on Sunday? I'll be flying into Columbus and staying at the Dublin Marriot Courtyard. --Denis Lynch ESL Inc. ======================================================================== Date: Fri, 30 Aug 1991 10:35:16 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Another agenda item: "Relationship of ZIG to NIST OSI Workshop" ======================================================================== Date: Fri, 30 Aug 1991 13:41:58 PDT Reply-To: "Z39.50 Implementors Workshop" Sender: "Z39.50 Implementors Workshop" From: Ray Denenberg - LC Subject: browse In response to Sara Randall's concern about Browse, it has been distributed to TC46/SC4/WG4 as a CD ("committee draft" - the new form of the old DP - "draft proposal"). I'll bring a copy to the meeting for discussion.