BrowseSystem

OK, this is all pretty speculative, and I'm still thinking about it so any comments would be very welcome. A while back I asked about the browse system for DSpace and it was suggested that if I specify one then we would be one step closer to the goal. So, here is an attempt to specify one. I've split the page into two halves, one for the overall ethos behind the browse/search features and one for the technical stuff that might need to go on underneath for it to work.

Browse and Search Overview

The way I see it, it would be a good idea if the browse and the search facilities in DSpace are really different angles to the same system. At the end of both a search and a browse request you have a record set which must be displayed to the user; this record set should be displayed through the same interface and posess a full range of record set manipulation tools such as sort (with appropriate sub-sort and sub-sub-sort and so on), paging (with customisable records-per-page facilities).

In addition to this, sub searching inside the current record set is also a desireable bit of functionality, and this is where I would say that we can merge the browse and search into identical systems, because you would use a multiple layered filtering system to generate your final record set that is displayed to the user.

For example, I want to browse the authors starting with F section of my archive. This is equivalent to filtering by F* (in common parlance) the whole data set and presenting the results in alphabetical order. I could achieve precisely the same results by searching for F* in the field contributor.author and requesting that the results be returned in asceding alphabetical order. So, there's no reason that this couldn't work exactly this way - that browse by F simply requests a filter on F* returned in alphabetical order. This means that we can now layer filters on top of eachother and have the resulting record set returned to the user.

I might, for example, only want authors starting with F who wrote articles whose title started with either W or P. Then I would have two filters: 1) F* on authors 2) W* OR P* on title. It is a separate matter over which order it is that these items are listed in. Using this system it would be possible to provide users with a way of creating multiple filters and trying out various combinations of them to see if they can find the items that they are interested in.

In terms of sorting, this is something that can be applied after the record set has been generated, and it should be possible to sub-sort and so forth by passing a number of sorting order requests in order of precedence to the record set manager. For example, we might wish to sort our authors filtered by F in ascending alphabetical order but our titles for those authors in descending alphabetical, so a result might look like this:

Filbert The paper wot I wrote
Filbert Because because because because
Flibble Zoological observations
Flibble Xylophone mechanics
Flibble Another paper

In terms of how these sorts of requests might be managed by the user, it is feasable to have a filter panel which would contain common metadata fields that can be searched from pull down lists, search boxes for proper search strings, and some common browse requests like authors starting with F and so forth. Then there could be sort boxes attached to the result sets (say at the top of each column) that allow you to choose the sort precedence of each column, and there could be somewhere other info such as a customisable records-per-page box. No doubt preparing the interface for this will be non-trivial and some time would need to be spent seeing what was good and what was confusing.

Browse and Search Technical Discussion

In progress...