Date:         Tue, 12 Oct 2004 11:30:50 +0200
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Theo van Veen <[log in to unmask]>
Subject:      Expansions (was Requesting summary counts)
Comments: To: [log in to unmask]
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline

>>>> [log in to unmask] 11-10-04 17:36:31 >>>
>On Mon, 11 Oct 2004, Theo van Veen wrote:
>>>>>> [log in to unmask] 8-10-04 21:13:03 >>>
>
>>> That if the client isn't expecting it, it could blow up the poor
>>> unsuspecting client. Especially in thin (terminally stupid)
clients.
>
>> I thought that the nice thing of extraResponseData was that it was
the
>> right place to put "unexpected data" without blowing up the client.
>
>It is.  It lets us do it at all, as opposed to putting it directly
into
>the response which would never get past a SOAP toolkit.
>
>> Given the discussion on expanding searches with the aid of  thesauri
I
>> would be in favour of a protocol extension that indicates for a
search
>> result that the search returned a thesuarus term that can be
expanded
>> and  extraResponseData seemed to me the right place for it.
>
>Sure. I'm in favour of it too, and extra*Data is the right place for
it.
>Something similar would also be useful in scan.
>
>> Although I agree with the general idea of not returning unrequested
>> information ...
>
>Good :)
>
>> ... I think that this is a case were it could be appropriate to
>> do so.
>
>Why?  What makes this more special than, for example, returning a
unique
>identifier for a record in extraRecordData?
>Or an authentication token in extraResponseData?
>
>> The alternative is that a user always has to request query
expansions
>> without knowing whether there are thesaurus terms resulting from
his
>> search.
>
>And that's exactly the way it should be.  If the server supports
>fb.broader or fb.equivalent, it'll say so in the ZeeRex record.  It
should
>also then say which thesauri it supports.
>
>So then you need to ask the server to tell you that there were hits
in
>the thesaurus. Nothing wrong with that.
>
No there is nothing wrong with that when a user chooses to do so, but
in many cases a user is not aware of all  the possibilities without
making the user interface extremely complicated. An extra field in
extraRequestData indicating that the result is also a thesaurus term
would allow the client to offer expansions in a controlled way and not
just letting the user try arbitrarily.

Parallel to the other thread on expansions we are developing and
testing several user intefaces in which we do query expansion based on
thesauri (and other databases providing all different kinds of
relations). There are different scenarios: the user may request
expansion, the client may request the extension or the server may
present information that expansion is possible. And in some cases the
thesaurus is integrated in the target database.
Our approach will probably be that the client performs hidden searches
in thesauri and name authority databases. Based on the search results we
will offer the user the possibility for expanding or changing his query.
Especially when the thesaurus is integrated in the target database and
each thesaurus record is a record like any other record,  a field
indicating that there is such a record would be much more convenient
than teling the user or client via explain that he can always _try_ an
expansion for a certain thesaurus.

The real issue is actually providing such an extraResponseData field
and _not_ whether it is offered unsollicited because we can always
request it by extraRequestData.

Theo