lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Runo <mr...@zappos.com>
Subject Re: Faceted Hierarchal Navigation
Date Mon, 16 Jul 2007 21:54:25 GMT
Thank you for this. I will be giving this a try, as I think it would  
work well for us.

In the index, we'll store them as  
Footwear>Outdoor>Mens>Fancy>Hiking>Boots>Waterproof, and upon getting  
it out as a facet, we'll convert that into a <ul><li>footwear</li>..  
list for display. Then we'll drill down using facet prefixes,  
stripping the prefix from all the returned facets.

+--------------------------------------------------------+
  | Matthew Runo
  | Zappos Development
  | mruno@zappos.com
  | 702-943-7833
+--------------------------------------------------------+


On Jul 16, 2007, at 1:58 PM, Binkley, Peter wrote:

> Here's one approach that should work: You could treat departments the
> way the sample app treats manufacturers, with a manu field (tokenized)
> and a manu_exact field (nontokenized). You would then do your initial
> search (mens+footwear) on the dept field, and facet on the dept_exact
> field, with facet.sort=false. This will give you an alphabetical  
> list of
> relevant departments, which your application can group in whatever way
> you need (show top-level departments with sub-departments in
> javascript-activated dropdowns, whatever).
>
> If a user clicks on a department or subdepartment to narrow their
> search, you do a filter query on the dept_exact field, and use a  
> prefix
> query to limit the facets in the result page if you want (e.g.
> fq=dept_exact:Footwear>Mens*&facet.prefix=Footwear>Mens).
>
> If you've got too many potential dept_exact values, I suppose you  
> could
> bite off the top couple of levels into a dept_top_exact field and  
> facet
> on that until the user drills down far enough that you need to go to
> dept_exact. The dept field would contain the full department  
> string, so
> they'd still find the dept_top_exact values that pertain to mens'
> footwear even if the "Mens > Footwear" elements were deep in the
> department hierarchy.
>
> And of course populating these multiple fields can be handled
> automatically in the schema using copyField elements.
>
> Peter
>
> Peter Binkley
> Digital Initiatives Technology Librarian
> Information Technology Services
> 4-30 Cameron Library
> University of Alberta Libraries
> Edmonton, Alberta
> Canada T6G 2J8
> Phone: (780) 492-3743
> Fax: (780) 492-9243
> e-mail: peter.binkley@ualberta.ca
>
> ~ The code is willing, but the data is weak. ~
>
>
> -----Original Message-----
> From: Matthew Runo [mailto:mruno@zappos.com]
> Sent: Monday, July 16, 2007 1:26 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Faceted Hierarchal Navigation
>
> We were thinking of using SOLR simply because we'll end up navigating
> around the products via facets at some level - so why not just use it
> from the beginning.
>
> For example, if we build the category landing pages from our DB, when
> the user clicks on a link, they'll get dumped into SOLR to view the
> products.. why not get the list of available categories to generate  
> the
> landing page as well? Either way, we have to store the departments in
> the index, right?
>
> Am I trying to make SOLR do something it's not designed to do? Please
> tell me if I am =p
>
> +--------------------------------------------------------+
>   | Matthew Runo
>   | Zappos Development
>   | mruno@zappos.com
>   | 702-943-7833
> +--------------------------------------------------------+
>
>
> On Jul 16, 2007, at 12:13 PM, Corey Tisdale wrote:
>
>> So you want your category display to be controlled by SOLR? Why not
>> keep the hierarchical structure of categories in a RDBMS, then keep
>> the product index in SOLR?
>>
>> Corey
>>
>> On Jul 16, 2007, at 1:56 PM, Matthew Runo wrote:
>>
>>> Hello!
>>>
>>> I was very surprised to find that this wasn't in the email archive
>>> for this list.... I'm wondering about the best way to provide
>>> hierarchal navigation using facets. For example, lets assume that I
>>> have products with department trees like:
>>>
>>> Footwear > Mens > Hiking > Waterproof  (could be arbitrarily deep
>>> though..)
>>>
>>> Now, I need to make a "Mens Footwear" landing page. So ok, I'll  
>>> facet
>
>>> on "department", for a search of "mens+footwear" present in
>>> "department".
>>>
>>> Oops.. now I'm showing lots and lots and lots of departments,  
>>> because
>
>>> I don't know which ones are "higher level" than others.
>>> Since each department has many departments under it, a full list
>>> would be so long that people wouldn't use it. Information overload.
>>>
>>> Ok, so I'll break up the "department" field, and put it into
>>> "top_level_department" and "mid_level_department" and the rest of  
>>> the
>
>>> items just in "department". The landing page will facet
>>> "top_level_department", and upon rendering the page I'll query SOLR
>>> to get all the "mid_level_department" facets for that
>>> top_level_department. Then, if the user clicks on one of these,  
>>> we'll
>
>>> facet on "department" to get the rest of them (and the
>>> products) with the other two levels as filter queries.
>>>
>>> That would work (right?), but it seems horribly wasteful to run all
>>> those extra queries to get the sub-department facets. Surely  
>>> there is
>
>>> a better way here.. just waiting to be brought to light.
>>>
>>> How have you implemented hierarchal navigation via SOLR?
>>>
>>> +--------------------------------------------------------+
>>>  | Matthew Runo
>>>  | Zappos Development
>>>  | mruno@zappos.com
>>>  | 702-943-7833
>>> +--------------------------------------------------------+
>>>
>>>
>>
>


Mime
View raw message