The WAIS, World-Wide Web, Prospero systems for network information retrieval (NIR) were presented (the Gopher protocol was presented in plenary the following day). The x500 directory was presented in the light of NIR needs, as were two proposals to use the directory to refer to documents. A discussion followed as to how to allow these systems to inter-operate, and on requirements for name spaces. A working group was proposed to define the format for a generalized printable format for a name or address in any of these systems.
Many databases exist, but there is no scalable way of finding them (TMC currently keeps a master index). Use of x500 was discussed.
The WAIS protocol is an extended subset of Z3950. The differences were discussed: WAIS allows relevance feedback ("Give me a document like this one") , and specifies how a query should be formulated. WAIS and Z39.50 have the same presentation layer.
The W3 clients use several protocols for accessing documents (FTP, NNTP, WAIS, Gopher, and W3's own "HTTP") although this is hidden from the user. The HTTP protocol is a simple stateless search/retrieve protocol running over TCP. As originally conceived but not yet implemented, it included authentication and data format negotiation.Tim discussed the differences between WWW, WAIS, Archie, Gopher and Prospero systems.
The need for a Universal Document Identifier (UDI) for describing the address or, given a directory, name, for a document whatever is access protocol was discussed, as outlined in OSI-DS-XX. Each application uses a "handle" for a file which can be prefixed by the particular protocol name to generate a universal address.
Most systems (WAIS excepted) are extensible, entertaining document addresses which refer to other systems. WAIS indexes currently can only refer to documents in the same database, let alone with other retrieval methods. There is a need for WAIS to be more flexible. John Curran said he would bring this to the attention of the WAIS community.
Addresses would not in the long term be suitable for references to documents, so it was hoped that some sort of directory service, operating within the UDI framework, would be incorporated.
More information: telnet info.cern.ch. Client and server code is available by anonymous FTP from info.cern.ch.
Mailing lists: www-talk@info.cern.ch, www-interest@info.cern.ch
Discussion document: OSI-DS-29
A Listing Service may be used to group like information items together for example to provide a Yellow Pages Service.
Such a service could for example provide for members of a special interest group, or could group documents on a particular subject.Services such as Archie could be considered to be Listing Services. One imagines an information Universe in which Information Brokers provide different subject based (say) views via their listing service. One would then need to locate the various listing services (using a mechanism such as a directory?)
Cliff stated that he expected to be able to use X.500 to translate between the document ID and how to get the document.
With Prospero the user has his own view of the global information base (or has a view built for him). Cliff thought there should be multiple name spaces - but the difficulty would be that these would need representing near the top of the directory tree. With multiple user chosen views - this would be difficult to manage. Also two users might refer to an object by different handles which would be relative to their individual name spaces - difficult when passing references (say in a mail message) from one person to the other.
The concept of "Closure": Each object has a related name space. All references within the object are resolved using the context of the name space. Name spaces themselves have global network addresses, but the user doesn't see that.
More information: info-prospero@isi.edu
Gateways provide access between systems not sharing transport protocols.
Also considered Access Control. ACL is part of description. The Server exploits multiple protocols for Search and retrieve.
There is a problem with dealing with different types of document (applications for jobs, product specs, memos, contracts, faxes, etc. ) It is difficult to normalize the attributes of a general document.
In discussion, Steve Kille suggested should be a WG on details of UDIs and a separate one for USDN. A comment was that the W3 data model encompasses those of the other systems. John Curran insisted on a better term than "UDI", suggesting "Document Access Token".
Peter Deutch's need for a USDN is to be able to determine the equivalence of two USDN. Chris Weider agreed to co-author a document on the issues. Jill Foster suggested a pilotproject to put UDI's in the directory for a set of documents and to have the gopher, Prospero, archie, and Prospero people try to utilise these.[These minutes have been largely built from Jill Foster's report and Karen Sollins' notes for which I am most grateful, though errors in the above are probably mine. Tim BL]