<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Joe Walker wrote:
<blockquote cite="mid5dd474260504130020284213c5@mail.gmail.com"
type="cite"><br>
Some thoughts:<br>
Is the intention of RangeNotation that it should be strictly a
VerseRange, i.e. a set of contiguous verses in the Bible? If so we are
missing being able to restrict searches by doing: [ Dan, Rev ], which
we could do if it were a Passage.<br>
</blockquote>
I meant Passage. And I meant that JSword would do the interpretation of
the search. At least for a first implementation, the Passage would be
combined as indicated with the rest of the search when it was finished.<br>
<blockquote cite="mid5dd474260504130020284213c5@mail.gmail.com"
type="cite"><br>
I've been surprised before about the lack of i18n in Lucene. I notice
that google does allow word based connectors (as well as punctuation
ones) but only if they are in capitals. I looked because I was going to
say "do we need word based connectors". Not that we need it because
Google do though.<br>
I still tend towards thinking that word based connectors drag up more
problems than they solve though.<br>
- Does [ Gen to Mal ] now mean the same as [ Gen - Mal ]<br>
</blockquote>
The syntax that we would use would be JSwords Passage notation.<br>
<blockquote cite="mid5dd474260504130020284213c5@mail.gmail.com"
type="cite">- Which words to we allow for "Joseph - Mary": "Joseph
without Mary" or "Joseph but not Mary"<br>
- What then if someone wants to use without in a search.<br>
Do we have an option in Lucene to use only punctuation based connectors?<br>
</blockquote>
I hadn't explored this fully. Until now.<br>
Lucene distinguishes connectors by upper case (AND, OR, NOT)<br>
You can set the default connector for a search to either AND or to OR.
So that a multiword search "son of man" is "son AND of AND man" or its
"son OR of OR man". Lucene's default is OR. I don't see any reason to
change it. (Actually there is a good reason not to change it, see below)<br>
<br>
For every Boolean operator there is a symbolic equivalent: &&
|| and ! for AND, OR and NOT respectively.<br>
<br>
As far as I can tell, these (AND, OR, NOT) are the only non-symbolic
connectors.<br>
<br>
I have no problem with hiding the word based connectors (i.e. don't put
them in the help documentation!) and only using the symbolic connectors.<br>
<blockquote cite="mid5dd474260504130020284213c5@mail.gmail.com"
type="cite"><br>
Joe.<br>
<br>
<br>
<div><span class="gmail_quote">On Apr 11, 2005 11:53 PM, <b
class="gmail_sendername">DM Smith</b> <<a
href="mailto:dmsmith555@gmail.com">dmsmith555@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I
am thinking of the following for a new search syntax:<br>
SearchRequest -> LuceneSearch<br>
or
CompoundSearch<br>
or
RangeRequest LuceneSearch<br>
or
RangeRequest CompoundSearch<br>
<br>
LuceneSearch -> defined by lucene, not repeated here<br>
<br>
CompoundSearch -> LuceneSearch Blur LuceneSearch<br>
<br>
RangeRequest -> [ RangeNotation ] /* all these verses are ORed
with <br>
the rest */<br>
or
+[ RangeNotation ] /* the search is<br>
retricted to these verses */<br>
or -[
RangeNotation ] /* these verses are<br>
removed from the search results */<br>
<br>
RangeNotation -> anything that JSword can handle as a range<br>
<br>
Blur ->
~ /* Uses the blur size as given in options */<br>
or
~N /* Finds verses within N verses of each<br>
other */<br>
(Currently a ~ b finds b near a. I think this is counter intuitive.<br>
Should it be the other way?)<br>
<br>
Things to note:<br>
A search can have at most one RangeRequest. This actually will be a <br>
search modifier applied the results of the search.<br>
A search can have at most one Blur.<br>
Each part of the search request is expected to be separated by<br>
whitespace from the others.<br>
<br>
While the search syntax can be defined recursively, I think such <br>
complexity does not add a lot of value for Blur and RangeRestrictions.<br>
<br>
Without recursion in this syntax, a trivial parser can be written.<br>
<br>
One further thing, Lucene uses English connectors. Should we entertain <br>
the internationalization of these?</blockquote>
</div>
</blockquote>
<br>
<br>
</body>
</html>