Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: NEAR in Search Engines

__/ [Noticedtrends] on Friday 14 October 2005 20:33 \__

> Good thing these posts are posting to 'search-engine forums.'  Why did
> GOOGLE Newsgroups repeat message #6 in message #8? The reply spaces can
> display in two or three different variations, and the responses may be
> posted (despite the preview option) at the wrong locations of
> discussion threads? Why are the processes of posting responses become
> less intuitive?

What bothered me more is that your lines are not being wrapped properly and
my newsreader does not cope with that in ideal ways. It fits to width which
has a distracting effect. Oddly enough, it's Google Groups I notice from
the headers...

Re: your question...

__/ [Noticedtrends] on Friday 14 October 2005 19:07 \__

>  Initial search queries in most search-engines recognize the wildcard
>  character "*" within two keywords in quotations -- very-much like the
>  Boolean NEAR; locating examples of keywords very close to each other.
>  Same applies for current month, wildcard chacrater, & year. Search-engine
>  results note "..." within text if keywords don't match month, any date,
>  year.
> Any considerations for applying NEAR search options in most
> search-engines?

I think it would not have much interest among the users. Judging by logs,
99.9% of queries will probably /not/ contain quotes, pluses, minuses and
the like.

Whether Google weigh these much (I remember the days of using AltaVista when
these were crucial skills), I do not know, but often the effect of these
symbols on SEPR's is futile to say the least. I am sorry to be
narrow-minded here because I only know Google well enough and I barely ever
use Yahoo. There is another big player... something that begin with an M,
but I was told it's cr**.

The improved quality of results due to query complexity is only in the mind
of the user. Plenty of room for improvements remains, but with googlebytes
of data already indexed, changing the method of indexing would involve a
complete data retension overhaul. It also might involve /risk/ as the
effects of re-indexing are not understood until vast amounts of data get
processed. Moreover, hand-tweaked search results go down the chute.


Roy S. Schestowitz      | while (sig==sig) sig=!sig;
http://Schestowitz.com  |    SuSE Linux    |     PGP-Key: 74572E8E
  3:55am  up 50 days 16:09,  3 users,  load average: 0.83, 0.81, 0.65
      http://iuron.com - next generation of search paradigms

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index