Hi Geert, Ok I think I follow. the magic is in the multi-valued field.
The only danger would be complexity if we allow users to multi select months/prices/fare classes. For example they can search for first prices in jan, april and november. I think what you describe is possible in this case just complicated. I'll see if i can hack some facets into the proto type tommorrow. Thanks for your help Lee C On 1 December 2010 17:57, Geert-Jan Brits <gbr...@gmail.com> wrote: > Ok longer answer than anticipated (and good conceptual practice ;-) > > Yeah I belief that would work if I understand correctly that: > > 'in Jan [9] > in feb [10] > in march [1]' > > has nothing to do with pricing, but only with availability? > > If so you could seperate it out as two seperate issues: > > 1. ) showing pricing (based on context) > 2. ) showing availabilities (based on context) > > For 1.) you get 39 pricefields ([jan,feb,..,dec,dc] * [standard,first,dc]) > note: 'dc' indicates 'don't care. > > depending on the context you query the correct pricefield to populate the > price facet-values. > for discussion lets call the fields: _p[fare][date]. > IN other words the price field for no preference at all would become: > _pdcdc > > > For 2.) define a multivalued field 'FaresPerDate 'which indicate > availability, which is used to display: > > A) > Standard fares [10] > First fares [3] > > B) > in Jan [9] > in feb [10] > in march [1] > > A) depends on your selection (or dont caring) about a month > B) vice versa depends on your selection (or dont caring) about a fare type > > given all possible date values: [jan,feb,..dec,dontcare] > given all possible fare values:[standard,first,dontcare] > > FaresPerDate consists of multiple values per document where each value > indicates the availability of a combination of 'fare' and 'date': > > (standardJan,firstJan,DCjan...,standardJan,firstDec,DCdec,standardDC,firstDC,DCDC) > Note that the nr of possible values = 39. > > Example: > 1. ) the user hasn't selected any preference: > > q=*:*&facet.field:FaresPerDate&facet.query=_pdcdc:[0 TO > 20]&facet.query=_pdcdc:[20 TO 40], etc. > > in the client you have to make sure to select the correct values of > 'FaresPerDate' for display: > in this case: > > Standard fares [10] --> FaresPerDate.standardDC > First fares [3] --> FaresPerDate.firstDC > > in Jan [9] -> FaresPerDate.DCJan > in feb [10] -> FaresPerDate.DCFeb > in march [1]-> FaresPerDate.DCMarch > > 2) the user has selected January > q=*:*&facet.field:FaresPerDate&fq=FaresPerDate:DCJan&facet.query=_pDCJan:[0 > TO 20]&facet.query=_pDCJan:[20 TO 40] > > Standard fares [10] --> FaresPerDate.standardJan > First fares [3] --> FaresPerDate.firstJan > > in Jan [9] -> FaresPerDate.DCJan > in feb [10] -> FaresPerDate.DCFeb > in march [1]-> FaresPerDate.DCMarch > > Hope that helps, > Geert-Jan > > > 2010/12/1 lee carroll <lee.a.carr...@googlemail.com> > > > Sorry Geert missed of the price value bit from the user interface so we'd > > display > > > > Facet price > > Standard fares [10] > > First fares [3] > > > > When traveling > > in Jan [9] > > in feb [10] > > in march [1] > > > > Fare Price > > 0 - 25 : [20] > > 25 - 50: [10] > > 50 - 100 [2] > > > > cheers lee c > > > > > > On 1 December 2010 17:00, lee carroll <lee.a.carr...@googlemail.com> > > wrote: > > > > > Geert > > > > > > The UI would be something like: > > > user selections > > > for the facet price > > > max price: £100 > > > fare class: any > > > > > > city attributes facet > > > cityattribute1 etc: xxx > > > > > > results displayed something like > > > > > > Facet price > > > Standard fares [10] > > > First fares [3] > > > in Jan [9] > > > in feb [10] > > > in march [1] > > > etc > > > is this compatible with your approach ? > > > > > > Erick the price is an interval scale ie a fare can be any value (not > > high, > > > low, medium etc) > > > > > > How sensible would the following approach be > > > index city docs with fields only related to the city unique key > > > in the same index also index fare docs which would be something like: > > > Fare: > > > cityID: xxx > > > Fareclass:standard > > > FareMonth: Jan > > > FarePrice: 100 > > > > > > the query would be something like: > > > q=FarePrice:[* TO 100] FareMonth:Jan fl=cityID > > > returning facets for FareClass and FareMonth. hold on this will not > facet > > > city docs correctly. sorry thasts not going to work..... > > > > > > > > > > > > > > > > > > > > > > > > > > > On 1 December 2010 16:25, Erick Erickson <erickerick...@gmail.com> > > wrote: > > > > > >> Hmmm, that's getting to be a pretty clunky query sure enough. Now > you're > > >> going to > > >> have to insure that HTTP request that long get through and stuff like > > >> that.... > > >> > > >> I'm reaching a bit here, but you can facet on a tokenized field. > > Although > > >> that's not > > >> often done there's no prohibition against it. > > >> > > >> So, what if you had just one field for each city that contained some > > >> abstract > > >> information about your fares etc. Something like > > >> janstdfareclass1 jancheapfareclass3 febstdfareclass6.... > > >> > > >> Now just facet on that field? Not #values# in that field, just the > field > > >> itself. You'd then have to make those into human-readable text, but > that > > >> would considerably simplify your query. Probably only works if your > user > > >> is > > >> selecting from pre-defined ranges, if they expect to put in arbitrary > > >> ranges > > >> this scheme probably wouldn't work... > > >> > > >> Best > > >> Erick > > >> > > >> On Wed, Dec 1, 2010 at 10:22 AM, lee carroll > > >> <lee.a.carr...@googlemail.com>wrote: > > >> > > >> > Hi Erick, > > >> > so if i understand you we could do something like: > > >> > > > >> > if Jan is selected in the user interface and we have 10 price ranges > > >> > > > >> > query would be 20 cluases in the query (10 * 2 fare clases) > > >> > > > >> > if first is selected in the user interface and we have 10 price > ranges > > >> > query would be 120 cluases (12 months * 10 price ranges) > > >> > > > >> > if first and jan selected with 10 price ranges > > >> > query would be 10 cluases > > >> > > > >> > if we required facets to be returned for all price combinations we'd > > >> need > > >> > to > > >> > supply > > >> > 240 cluases > > >> > > > >> > the user interface would also need to collate the individual fields > > into > > >> > meaningful aggragates for the user (ie numbers by month, numbers by > > fare > > >> > class) > > >> > > > >> > have I understood or missed the point (i usually have) > > >> > > > >> > > > >> > > > >> > > > >> > On 1 December 2010 15:00, Erick Erickson <erickerick...@gmail.com> > > >> wrote: > > >> > > > >> > > I'd think that facet.query would work for you, something like: > > >> > > &facet=true&facet.query=FareJanStandard:[price1 TO > > >> > > price2]&facet.query:fareJanStandard[price2 TO price3] > > >> > > You can string as many facet.query clauses as you want, across as > > many > > >> > > fields as you want, they're all > > >> > > independent and will get their own sections in the response. > > >> > > > > >> > > Best > > >> > > Erick > > >> > > > > >> > > On Wed, Dec 1, 2010 at 4:55 AM, lee carroll < > > >> > lee.a.carr...@googlemail.com > > >> > > >wrote: > > >> > > > > >> > > > Hi > > >> > > > > > >> > > > I've built a schema for a proof of concept and it is all working > > >> fairly > > >> > > > fine, niave maybe but fine. > > >> > > > However I think we might run into trouble in the future if we > ever > > >> use > > >> > > > facets. > > >> > > > > > >> > > > The data models train destination city routes from a origin > city: > > >> > > > Doc:City > > >> > > > Name: cityname [uniq key] > > >> > > > CityType: city type values [nine possible values so good for > > >> > faceting] > > >> > > > ... [other city attricbutes which relate directy to the doc > > >> unique > > >> > > key] > > >> > > > all have limited vocab so good for faceting > > >> > > > FareJanStandard:cheapest standard fare in january(float > value) > > >> > > > FareJanFirst:cheapest first class fare in january(float > value) > > >> > > > FareFebStandard:cheapest standard fare in feb(float value) > > >> > > > FareFebFirst:cheapest first fare in feb(float value) > > >> > > > ..... etc > > >> > > > > > >> > > > The question is how would i best facet fare price? The desire is > > to > > >> > > return > > >> > > > > > >> > > > number of citys with jan prices in a set of ranges > > >> > > > etc > > >> > > > number of citys with first prices in a set of ranges > > >> > > > etc > > >> > > > > > >> > > > install is 1.4.1 running in weblogic > > >> > > > > > >> > > > Any ideas ? > > >> > > > > > >> > > > > > >> > > > > > >> > > > Lee C > > >> > > > > > >> > > > > >> > > > >> > > > > > > > > >
