Agreed.  I assume that the term in the middle is the "best matching" and
does not have to be interpreted as the one requested. I also expect that
in some cases there is only a "best matching" and "next best matching"
terms but not a "previous". For example coordinates closest to the
requested coordinates or relevance ranked terms.
Or do I miss the clue?

Theo


>>> [log in to unmask] 03/09 5:46  >>>
In the past, I've not had a problem generating a 'Your term would be
here'
entry in a scan user interface because the terms would invariably be
ordered in an intuitive fashion and I could check (previous < term and
current > term) or (current == term)

Given the recent discussion of stemmed or otherwise modified terms,
this
is no longer the case.  I cannot check that the term returned == the
term
requested. Nor can I rely on the ordering to be alphanumeric.

My suggestion is an extraTermData extension marking the term as being
the
requested one in a form suitable for searching, even if it's not
identical to the request.
Also two extraTermData fields, one marking the term immediately before
where the requested term would be and one marking the term immediately
after.

Thoughts?

Rob

--
      ,'/:.          Dr Robert Sanderson ([log in to unmask])
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Nebmedes:  http://nebmedes.o-r-g.org:8000/
____/:::::::::::::.
I L L U M I N A T I