Till Kinstler wrote:
>> Where can I read about SOLR's browse support functions?
>
> In the source code, SCNR.
Ah, of course.
> Solr isn't about library data or any other special kind of data. It is a
> very flexible text/string indexing and retrieval system. You may index
> any string in very flexible ways, e.g. even so you can search it
> efficently as "left anchored text field".
Search is not browse.
> But there is no bullet on the feature list "left anchored text fields",
> because that is not a concept in Solr, the index concept of Solr is more
> flexible ...
I'm fully convinced it is extremely powerful, that was not my question.
Consider a browsable index like a phonebook. You can open it on any
page and flip back and forth, to browse through the entirety of all
names listed. That's a browsable index, no more, no less. I want access
to all names, titles, keywords in that way.
>
> You may sort any search result (and a browse list is a search result)
> many different ways. And if you have sorted your list, you may of course
> step up and down the list.
That's cool but that is NOT a browsable index. To browse a result set
set means you first have to _have_ a result set. It will contain
whatever matched your query - no more and no less. And that's the point.
The real, true browse list lets you see what is actually there - and
what's not there as well. So you can build result sets that include
things you didn't think of when you couldn't see what's actually there
but had to guess first.
IOW, using a search slot is always a _guess_. It will return whatever
the system will make of it. The more powerful it is - the more
intransparent it will be to the user. What can be more transparent than
a browsable index? Sure, it has other drawbacks, but who would say we
don't need the concept at all?
OTOH, if indeed a majority in this list agreed "A good catalog needs no
browsable lists" then that would be a nice result to hand down to OPAC
designers.
B.Eversberg
Received on Thu Mar 12 2009 - 06:02:48 EDT