<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Well, theoretically, yes. The logical
syntax allows such, but after it didn't work when I tried, the
Lucene FAQ says:<br>
<br>
Leading wildcards (e.g. <em>*ook</em>) are <strong>not</strong>
supported by the QueryParser by default. As of Lucene 2.1, they
can be enabled by calling <tt class="backtick">QueryParser.setAllowLeadingWildcard( true )</tt>.
Note that this can be an expensive operation: it requires scanning
the list of tokens in the index in its entirety to look for those
that match the pattern. <br>
<br>
So, it might take some flags to be flipped and an eval of the
performance.<br>
<br>
Troy<br>
<br>
<br>
On 07/12/2012 07:12 PM, Daniel Owens wrote:<br>
</div>
<blockquote cite="mid:4FFF0580.50400@gmail.com" type="cite">Troy,
<br>
<br>
I am excited about this kind of search capability. This is great
work.
<br>
<br>
I have a question. Will this solution also cover searching for a
morph value for any lemma? It might look like:
<br>
<br>
morph:*@mor1
<br>
<br>
instead of
<br>
<br>
morph:lem1@mor1
<br>
<br>
In other words, if I want to find all the masculine, singular
nouns, regardless of lemma.
<br>
<br>
Daniel
<br>
<br>
On 07/12/2012 10:01 AM, Troy A. Griffitts wrote:
<br>
<blockquote type="cite">Hey Chris,
<br>
<br>
A relational database will not contribute more to a solution
than what we have available in lucene. What I failed to get
across in my last email, due to too much caffeine, was that a
verse's declension data by itself is useless without being
attached to the lemma which each morph code in the declension
data modifies.
<br>
<br>
We have 2 things for each word:
<br>
<br>
root@declension
<br>
<br>
we refer to these as:
<br>
<br>
lemma@morph
<br>
<br>
root, stem, lemma, in this discussion are all synonyms.
<br>
<br>
<br>
Currently in our lucene index we have a field called 'lemma', so
for a verse with 5 words, this field might look something like
this:
<br>
<br>
lem1 lem2 lem3 lem4
<br>
<br>
and we can do searches for all verses with lem3
<br>
<br>
lemma:lem3
<br>
<br>
great, but this ignores the declension data; e.g., was lem3 a
1st person or 2nd person noun? Ignoring declension is usually
desired when doing word studies, and why we have the 'lemma'
lucene index in the first place. You don't want to have to
search for all forms of a word to do a word study.
<br>
<br>
... but sometimes you only care about 1 form of a word when
doing a study, so how do we incorporate the declension
information?
<br>
<br>
It would be useless to create a 'morph' field with contents for
the same verse as:
<br>
<br>
mor1 mor2 mor3 mor4
<br>
<br>
In this scenario, you could construct a clucene search using
both fields like this:
<br>
<br>
lemma:lem2 morph:mor2
<br>
<br>
but this would not return what you desire. This would return
all verses which have a lem2 in the lemma field and a mor2 in
the morph field, but not necessarily together.
<br>
<br>
So... the proposed solution...
<br>
++++++++++++++++++++++++++
<br>
<br>
We have created a new field called 'morph' which will probably
replace the lemma field and has data as:
<br>
<br>
lem1@mor1 lem2@mor2 lem3@mor3 lem4@mor4
<br>
<br>
This allows a lucene search to be create like this:
<br>
<br>
morph:lem2@mor2
<br>
<br>
or to get the functionality of the current 'lemma' field-- which
ignores declension, the equiv search using the 'morph' field
would be:
<br>
<br>
morph:lem2@*
<br>
<br>
this allows all kinds of queries, like: give me all verses which
have lem1 and lem2 within 4 words of each other and lem2 must
have the declension mor2
<br>
<br>
morph:"lem1@* lem2@mor2"~4
<br>
<br>
Hope this make things clearer if there were any clouds :)
<br>
<br>
Troy
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 07/12/2012 02:17 PM, Chris Burrell wrote:
<br>
<blockquote type="cite">Thanks Troy. That helps put the task in
perspective... An alternative would possibly be to store both
strong and morphology indexes in a relational database. Then
have a table mapping all the data together. I guess the
mapping table would be based on one version of the Bible only.
<br>
<br>
Cheers
<br>
Chris
<br>
<br>
<br>
On 11 July 2012 01:09, Troy A. Griffitts
<<a class="moz-txt-link-abbreviated" href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:scribe@crosswire.org"><mailto:scribe@crosswire.org></a>> wrote:
<br>
<br>
Chris,
<br>
<br>
We're toyed around with the best way to add lemma+morph
searching
<br>
in SWORD but haven't finalized anything yet.
<br>
<br>
Indexing Morphology codes won't helps. This would give
you 2
<br>
fields which need to be used together.
<br>
<br>
For example, if you wish to find λογος only in the
nominative
<br>
within 3 words of any present, active, indicative, 2
persons
<br>
singular or plural verb, you could not satisfy your
search.
<br>
<br>
Believe it or not, end users of tools like Bibleworks seem
quite
<br>
happy to learn odd syntax like:
<br>
<br>
<br>
"λογος@* *@PAI2?"~3
<br>
<br>
<br>
Of course GUI tools to help build that syntax for them is
also
<br>
desired.
<br>
<br>
This it the direction we're heading, but would require
lemma
<br>
encoding changed from strongs to lexical form.
<br>
<br>
Presently we could nearly obtain this by building an index
as
<br>
(from the start of John 1.1):
<br>
<br>
G1722@PREP G746@N-DSF G2258@V-IXI-3S
<br>
<br>
But this would require users to know strongs numbers
rather than
<br>
lexical form, which would almost certainly need a GUI to
help
<br>
them build the search syntax.
<br>
<br>
Hope this helps,
<br>
<br>
Troy
<br>
<br>
<br>
<br>
<br>
<br>
On 07/10/2012 11:41 PM, Chris Burrell wrote:
<br>
<blockquote type="cite"> Hello
<br>
<br>
Does anyone know/tried some kind of stem search with
JSword? Is
<br>
it implemented? Or would we need to do a bit more work
there?
<br>
<br>
Chris
<br>
<br>
<br>
<br>
_______________________________________________
<br>
jsword-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:jsword-devel@crosswire.org"><mailto:jsword-devel@crosswire.org></a>
<br>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</a>
<br>
</blockquote>
<br>
<br>
<br>
<br>
<br>
_______________________________________________
<br>
jsword-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</a>
<br>
</blockquote>
<br>
<br>
<br>
<br>
_______________________________________________
<br>
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
<br>
Instructions to unsubscribe/change your settings at above page
<br>
</blockquote>
<br>
<br>
<br>
_______________________________________________
<br>
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
<br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote>
<br>
<br>
</body>
</html>