Z39.50 Implementor
Agreement xx: Creating a Search from Scan Results The Requirement Scan returns results that consist of terms with complementary data,
representing rows from an ordered list. The results can be presented to an end user,
enabling him or her to browse forward and optionally backwards, then select a line for
further information or processing. When a line is selected, the system may format a search
request that may return one or more records associated with the term. Typical examples are
scans (browses) on AUTHOR, SUBJECT and TITLE. To construct a follow on search, the origin takes the USE attributes
that were used for the scan and takes data from the term field of the scan
as the search term or terms.
Database Models The technique described above may be employed to construct a search
for various database models. There are the following possible models:
The technique of doing a follow on search with the same Use
attributes from the scan request and the TERM from the scan response may not be
the most efficient for the first two cases above where there are database links that may
be employed. The problem with using Term for the follow search is that the
resulting search may not be precise enough. There are a number of reasons for this.
Firstly, the term may have been truncated and actually lacks significant words, important
for the precision. Secondly, the target may not support position attributes such as first
in field or the structure attribute phrase and therefore the search
is constructed in an imprecise way such that it can retrieve unexpected records even when
a single seemingly unique line has been extracted from a scan. Another case
is where the term is not unique. This can happen where it is necessary to
repeat the term because of differences in the display term.
Example: TERM
DUPUIS FRANCOISE TERM
DUPUIS FRANCOISE TERM
DUPUIS FRANCOISE What is required is a means of using database links where they
exist to assist in the precision of the follow on search. The
Proposal The proposal is to include this retrieval information in otherTermInfo
as an external carried in externallyDefinedInfo. The external would be
called DirectTermAccess and would comprise the following: Mandatory when database name is not present. Example: An authority scan, e.g. author or subject performed on an index of
an authority database (auth.file) produces a scan entry with a term occurrence of 1. There
are actually 3 bibliographic records associated with this authority record. In otherTermInfo
of the scan response, there is one entry containing the identifier of the authority record
(4544).
Z39500url server address and port blank, database name = bib.file AttributePlusTerm attributeSet 1.2.840.10003.3.1 (Bib1) attributeType 1 (Use attribute) attributeValue 12 (Local number) term 4544 (local number of the term) occurrenceCount 3 The target may define its own attribute values for internal numbers,
particularly if it needs to distinguish between local bibliographic and authority numbers.
As the target is able to supply these in the scan response, the origin does not need to
know them in advance. Therefore internally defined attributes do not pose a problem for
interoperability. The authority file may be located in a separate database from the
bibliographic file or it may be in the same database. For the purposes of retrieval, the
authority file should be regarded as a separate database even where it is not. The origin
needs to know the names of both databases. Where an authority file is linked to a bibliographic file as per
database models 2 and 3, it is possible to:
|