ZIG meeting Agenda items
 
 There are a couple of items which we at Software Kinetics would
 like to see on the agenda for this week's meeting.  They are:
 (1) the state of play on defining a browse service in
 SR/Z39.50; (2) the possibility of defining multiple functional
 profiles to support different levels of service offered by a
 target - we have identified a use for a restricted "Known-Item
 Lookup" profile which would support simpler queries and a
 smaller attribute set than a more general "Information
 Retrieval" profile.
 
 Brief explanations/justifications of the two items are
 enclosed.
 
 
 
 A number of the projects we are involved in require the
 provision of SR gateways to one or more "integrated library
 systems", such as Dynix, Inlex, Geac, etc.  All these systems
 provide public access catalogues which are based on the notion
 of index browsing:  the user examines a set of search terms
 until one is found which seems to be appropriate; at this
 pointed to by the search term.  This two-step process, while it
 has considerably less power than the explicit input of a query,
 is very easy to use, and forms the basis of many menu-driven
 catalogue.
 
 In order to make this kind of facility available remotely, it
 will be necessary to provide a browse service in SR, and, since
 we are being asked to build this kind of interface now, it is
 important that the standardization process begin as soon as
 possible.
 
 Looking over our notes of the last meeting, it would appear
 that there was some discussion of supporting index browsing
 then, and it appears that OCLC are interested in a browse
 service as well.  But there has been no discussion since.
 
 Known-Item Lookup Profile
 
 The vast majority of use of the databases of the major
 bibliographic utilities is for the retrieval of records whose
 existence is already known to the user.  This kind of searching
 has identifiable characteristics:
 
 -- the search is for a single item already known to the
    searcher
 
 -- the searcher has sufficient information to identify the item
    uniquely (e.g. unique number, author+title+date+edition)
 
 -- a standard, application specific set of bibliographic data
    elements is required as the result of the search
 
 -- much of the decision-making involved in identifying a
    successful search is routine and lends itself to machine
    processing
 
 At the same time, a number of bibliographic systems exist which
 support just this kind of searching:  they do not offer
 maintain the current result set, only offer a fixed or static
 display format.
 
 The fact that this type of search is well matched with the
 capabilities of many potential targets, together with the fact
 that this type of search probably comprises the bulk of
 searches carried out within libraries (for interlibrary loans,
 for catalogue records, for acquisition records, etc.) suggests
 that it would be efficient to define a standard subset of the
 protocol services specifically for this use.  This would allow
 both users and providers of catalogue lookup services to create
 more efficient implementations.  This distinction between the
 catalogue lookup service and the full service would be made by
 choice of profile, and would be indicated by the existence of
 different application contexts.