On 1/3/07, Walter Underwood <[EMAIL PROTECTED]> wrote:
On 1/3/07 9:33 PM, "Yonik Seeley" <[EMAIL PROTECTED]> wrote:
> On 1/3/07, Walter Underwood <[EMAIL PROTECTED]> wrote:
>> We tried several APIs and decided that the best was an array of
>> String with the odd elements containing the strings t
On 1/3/07 9:33 PM, "Yonik Seeley" <[EMAIL PROTECTED]> wrote:
> On 1/3/07, Walter Underwood <[EMAIL PROTECTED]> wrote:
>> We tried several APIs and decided that the best was an array of
>> String with the odd elements containing the strings that needed
>> highlighting.
>
> Good idea... the only th
On 1/3/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
That is _much_ better than the current system. It wouldn't be hard to
add start/end offsets to the fragments too, as Chris suggested so long
ago.
Or leave room for other info such as weights, or what term matched, etc.
Quite a few aspects of t
On 1/3/07, Walter Underwood <[EMAIL PROTECTED]> wrote:
We tried several APIs and decided that the best was an array of
String with the odd elements containing the strings that needed
highlighting.
Good idea... the only thing I could think of was an array of start/end
offsets into the string, wh
On 1/3/07, Walter Underwood <[EMAIL PROTECTED]> wrote:
I've implemented this before, once in Python and once in C, so I'd
be glad to take a look at it. I'm not sure I have time to do a lot
of implementation, but I'd sure be glad to help.
Cool. I'll post the current fragmenter as a JIRA issue
On 1/3/07 5:13 PM, "Mike Klaas" <[EMAIL PROTECTED]> wrote:
> Generally, we should strive for a high-quality out-of-the-box
> highlighting in Solr. That might involve making things like better
> fragmenters and a few other tricks(*) the default setup, and providing
> a "quick & dirty" setting for
: implementing Solr's highlighting. What I'd like to do is improve the
: end-user's experience with highlighting in Solr. If as a result a
: high-quality component for lucene Highlighter is fleshed out, that can
: always be contributed to Lucene later.
:
: Generally, we should strive for a high-
On 1/3/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: I've written an unpolished custom fragmenter for highlighting which is
: more expensive than the BasicFragmenter that ships with lucene, but
: generates more natural candidate fragments (it will tend to produce
: beginning/ends of sentences
: I've written an unpolished custom fragmenter for highlighting which is
: more expensive than the BasicFragmenter that ships with lucene, but
: generates more natural candidate fragments (it will tend to produce
: beginning/ends of sentences).
:
: Would there be interest in the community in relea
On Jan 3, 2007, at 6:36 PM, Mike Klaas wrote:
I've written an unpolished custom fragmenter for highlighting which is
more expensive than the BasicFragmenter that ships with lucene, but
generates more natural candidate fragments (it will tend to produce
beginning/ends of sentences).
Would there
I for one would be interested in such a fragmenter, as the default one
is lacking and doesnt produce acceptable results for most applications.
Michael
Mike Klaas wrote:
I've written an unpolished custom fragmenter for highlighting which is
more expensive than the BasicFragmenter that ships wit
I've written an unpolished custom fragmenter for highlighting which is
more expensive than the BasicFragmenter that ships with lucene, but
generates more natural candidate fragments (it will tend to produce
beginning/ends of sentences).
Would there be interest in the community in releasing it and
12 matches
Mail list logo
