>>Does anyone have any ideas? A framework for match metadata?
Similar to the way tokenization was changed to allow tokenizers to to enrich a stream of tokens with arbitrary "attributes", Scorers could provide "MatchAttributes" to provide arbitrary metadata about the stream of matches they produce. Same model is used - callers decide in advance which attribute decorations they want to consume and Scorers modify a singleton object which can be cloned if multiple attributes need to be retained by the caller. Helps support highlighting, explain and enables communication of added information between query objects in the tree. LUCENE-1999 was an example of a horrible work-around where additional match information that was required was smuggled through by bit-twiddling the score - this is because score is the only bit of match context we currently pass in Lucene APIs. Cheers Mark ________________________________ From: Robert Muir <[email protected]> To: [email protected] Sent: Friday, 2 March 2012, 10:30 Subject: GSOC 2012? Hello, I was asked by a student if we are participating in GSOC this year. I hope the answer is yes? If we are planning to, I think it would be good if we came up with a list on the wiki of potential tasks. Does anyone have any ideas? One suggested idea I had (similar to LUCENE-2959 last year) would be to add a flexible query expansion framework. -- lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
