headers
Otis Gospodnetic | 1 Jun 2002 02:48
Picon
Favicon

Re: new product

Hello,

I'm afraid this doesn't meat the requirement of showing the Lucene logo
as descibed at http://jakarta.apache.org/lucene/docs/powered.html

Otis

--- ip m <ipm_1_1 <at> hotmail.com> wrote:
> Hi all,
> 
> A new product that uses Lucene is available
> at http://www.intellectronix.com/ipm/
> Among other things IPM provides powerful gui
> tools for creating and managing
> sophisticated Lucene indexes. Could you
> please include it in "Powered by Lucene"?
> 
> Thanks!
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp.
> 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:lucene-dev-unsubscribe <at> jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-dev-help <at> jakarta.apache.org>
(Continue reading)

Permalink | Reply | 0 comments |
headers
cmarschner | 1 Jun 2002 20:44
Picon
Favicon

cvs commit: jakarta-lucene-sandbox/contributions/webcrawler-LARM/libs - New directory

cmarschner    2002/06/01 11:44:49

  jakarta-lucene-sandbox/contributions/webcrawler-LARM/libs - New directory
Permalink | Reply | 0 comments |
headers
cmarschner | 1 Jun 2002 20:55
Picon
Favicon

cvs commit: jakarta-lucene-sandbox/contributions/webcrawler-LARM/src/hplb/xml/util HtmlObserver.java HtmlScanner.java NormalizeHtml.java RmMarkup.java TokTest.java UrlScanner.java

cmarschner    2002/06/01 11:55:16

  Modified:    contributions/webcrawler-LARM CHANGES.txt
               contributions/webcrawler-LARM/doc
                        webcrawler_tech_overview.doc
               contributions/webcrawler-LARM/src/de/lanlab/larm/fetcher
                        Fetcher.java FetcherMain.java FetcherTask.java
                        Filter.java MessageHandler.java
                        URLVisitedFilter.java
               contributions/webcrawler-LARM/src/de/lanlab/larm/parser
                        Tokenizer.java
               contributions/webcrawler-LARM/src/de/lanlab/larm/storage
                        DocumentStorage.java LogStorage.java
                        NullStorage.java SQLServerStorage.java
               contributions/webcrawler-LARM/src/de/lanlab/larm/util
                        WebDocument.java
  Added:       contributions/webcrawler-LARM TODO.txt build.xml
               contributions/webcrawler-LARM/libs placeholder
               contributions/webcrawler-LARM/src/de/lanlab/larm/parser
                        EntityManager.java SimpleCharArrayWriter.java
               contributions/webcrawler-LARM/src/de/lanlab/larm/storage
                        LinkLogStorage.java LinkStorage.java
                        StoragePipeline.java
  Removed:     contributions/webcrawler-LARM/src/hplb/misc ByteArray.java
               contributions/webcrawler-LARM/src/hplb/org/w3c/dom
                        Attribute.java AttributeList.java Comment.java
                        DOM.java Document.java DocumentContext.java
                        DocumentFragment.java Element.java Makefile
                        Node.java NodeIterator.java PI.java Text.java
                        TreeIterator.java
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Carlson | 2 Jun 2002 00:40

Bug? QueryParser may not correctly interpret RangeQuery text

I am trying to get date range searching use the range query (maybe a bad
choice vs. DateFilter, but I wanted to be able to use it from the query
string).

So I type in a string like
date:[0czi1ceuk-0d0ouet2k]

When I run this through the QueryParser it return only 1 term. That is the
query gets converted to:

date:[0czi1ceuk-0d0ouet2k-null]

This is because the StandardTokenizer sees <alphanum> <p> <has_digit> as a
single token.

Note: <p> can be .,-,_,, and a few other things.

What do people think the right way to handle this issue for the range
queries? My suggestion is to do a indexOf() for "-" and create the one or
two tokens. That is, don't use the analyzer to determine what the tokens are
here. Is there a problem with this?

--Peter
Permalink | Reply | 36 comments |
headers
Brian Goetz | 2 Jun 2002 00:43

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> What do people think the right way to handle this issue for the range
> queries? My suggestion is to do a indexOf() for "-" and create the one or
> two tokens. That is, don't use the analyzer to determine what the tokens are
> here. Is there a problem with this?

We can also use JavaCC's lexical modes to have different sets of rules
for different tokens.

The range stuff always felt to me like it was nailed onto the side of
the query parser.  How about we step back and define a formal syntax
for acceptable range queries, and then approach that as a parsing
problem, instead of hacking this hack further?
Permalink | Reply | 35 comments |
headers
Peter Carlson | 2 Jun 2002 00:48

Re: Bug? QueryParser may not correctly interpret RangeQuery text

That sounds great.

I really know nothing about JavaCC so I was trying to figure a way of not
using the StandardTokenizer to tokenize the code.

This is something I'd like to get working on so if you have any pointers I'd
spend the time to get the work done.

Thanks

--Peter

On 6/1/02 3:43 PM, "Brian Goetz" <brian <at> quiotix.com> wrote:

>> What do people think the right way to handle this issue for the range
>> queries? My suggestion is to do a indexOf() for "-" and create the one or
>> two tokens. That is, don't use the analyzer to determine what the tokens are
>> here. Is there a problem with this?
> 
> We can also use JavaCC's lexical modes to have different sets of rules
> for different tokens.
> 
> The range stuff always felt to me like it was nailed onto the side of
> the query parser.  How about we step back and define a formal syntax
> for acceptable range queries, and then approach that as a parsing
> problem, instead of hacking this hack further?
> 
> --
> To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe <at> jakarta.apache.org>
> For additional commands, e-mail: <mailto:lucene-dev-help <at> jakarta.apache.org>
(Continue reading)

Permalink | Reply | 34 comments |
headers
Brian Goetz | 2 Jun 2002 00:54

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> This is something I'd like to get working on so if you have any pointers I'd
> spend the time to get the work done.

The technical part is generally pretty easy, once we decide what we
actually want to do.  The problem is when we don't really know
what we want to accept.  

Lets start with coming up with a rough syntax definition of what
constitutes an allowable range.  Numbers?  Dates?  Date formats?
Permalink | Reply | 33 comments |
headers
Peter Carlson | 2 Jun 2002 01:11

Re: Bug? QueryParser may not correctly interpret RangeQuery text

Sounds good.

I think we should have a Date format or formats and then convert them use
the DateField to the Lucene date format.

Date formats to include might be
Mm/dd/yyyy where these are all <digit> (this is very US centric but could
easily be converted for other countries)

MMM dd, yyyy (where MMM is JAN, FEB, ...)

Yyyy/mm/dd (be able to know by 4 <digit> start)

Others????

Number would be interesting if we could define a NumberField in lucene. That
is potentially pad the number to a max length (say up to a 16 digits is
supported). That way if it's just a set of digits then we could convert it
using the NumberField.

If they don't match one of the defined formats, then I think we should just
leave them as is. If we tokenize it and it produces multiple tokens then how
would the RangeQuery work?

Thoughts?

--Peter

On 6/1/02 3:54 PM, "Brian Goetz" <brian <at> quiotix.com> wrote:
(Continue reading)

Permalink | Reply | 32 comments |
headers
Peter Carlson | 2 Jun 2002 01:16

Naming conventions for Release

Hi,

I am creating the final release for Lucene 1.2.

What should the next version be called? I think 1.3, but just checking.

The build will be called something like
Lucene-1.3-dev1

Thanks

--Peter
Permalink | Reply | 1 comment |
headers
Otis Gospodnetic | 2 Jun 2002 01:17
Picon
Favicon

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> Date formats to include might be
> Mm/dd/yyyy where these are all <digit> (this is very US centric but
> could
> easily be converted for other countries)
> 
> MMM dd, yyyy (where MMM is JAN, FEB, ...)
> 
> Yyyy/mm/dd (be able to know by 4 <digit> start)
> 
> Others????

dd.MM.YYYY.
YYYY-MM-dd

Otis

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
Permalink | Reply | 0 comments |

Gmane