By now it’s pretty obvious that the same, or similar, idea has been reinvented many times in different CS fields and contexts with everyone coming up with their own terms. I wrote the above post from a lumper’s point of view (see http://en.wikipedia.org/wiki/Lumpers_and_splitters ), because I think that having dozens of terms for the “same” paradigm (in a broad sense) doesn’t exactly help finding relevant research and previous work.

Eetu’s suggestion of “view-based query constraining and visualization” may be general enough to cover all cases, but for the purpose of finding relevant information it doesn’t help much to coin a new term that nobody uses (currently zero hits for the phrase on Google). But if you want to avoid unwanted connotations like faceted classification, that may be a good approach.

BTW, Giovanni M. Sacco rejects “faceted search” in his recent papers for the same reason as Eetu, but he advocates “dynamic taxonomies” which seems to exclude maps, timelines etc. And the mSpace people got around the problem by calling their interface a mSpace.

I personally still think that the reference to faceted classification is not a bad thing to have, and that richer knowledge models, spatiotemporal data etc. can be incorporated as extensions of the facet model without having to invent new names. A splitter obviously wouldn’t agree…

The reasons for this are:
First, I like view-based better than faceted because I want to see the paradigm as large as possible, and I think the connotation to faceted classification is a constraint here. Sure, the interfaces o0f MuseumFinland, Flamenco etc. are strictly hierarchical facet, but is a map view of the items still a facet? what about a timeline? What about a semantic autocompletion box that matches concepts all over the different domains?

Second, I’ve expanded from search, browsing or the even more abstract navigation to what is actually done, i.e. query constraining and visualization. This is to underline the two basic functionalities inherent in the paradigm and to enable the analysis of these two as related to each other. So, in HIBROWSE, there were only views that did both, but in most current systems, there is a view visualization of the results meant only as a visualization – but it uses the same constructs and facets still, and could be used to constrain the search if we only wanted it to be so. I think there is fruitful dialogue to be had in how much particular views are focused on visualization vis-a-vis selection, and what is a good mix.

(and yes, this view of the paradigm comes much closer to the OLAP concept of Drilldown presented in the comment before – however, that too is a word not revealing its contents.)

Finally, to Jakob, I’m not aware of any live datasets online consisting of millions of items. However, internally we’ve stress-tested the MuseumFinland engine with the content of dmoz.org, and found that we could scale that engine up to two million items and 450 000 categories. Our new engine, based on creating efficient custom indexes in traditional relational databases should scale even better.

http://www.seco.tkk.fi/u/oisuomin/rdfroom-8bit-uri.patch

UI design worth taking a look at, considering semantic web too…