Indeed, selecting the best price for January OR April OR November and sorting on it isn't possible with this solution (if that's what you mean). However, any combination of selecting 1 month and/or 1 price-range and/or 1 fare-type IS possible.
2010/12/1 lee carroll <lee.a.carr...@googlemail.com> > 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 > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > > >
