[b-hebrew] Karl's lexicon

JAMES CHRISTIAN READ JCR128 at student.anglia.ac.uk
Sat Aug 25 10:43:22 EDT 2007


Hi Karl,

KWR: I can understand where there are alternate spellings, I would have to
have an entry for each of the alternate spellings. But what about
where a spelling can come from two or more sources? For example, Y$B
would have to pull up three entries, Y$B, $BH and $WB because Y$B is
found as a derivative from all three roots. It's the context that
tells which root is the one to use. Moreover, it could be a 3rd p. s.
qal imp. or a participle or a ... depending on which root and part of
speech it has in the sentence. There are many such examples. How would
your database deal with those?

JCR: I think that this is an excellent example of where the value of having definitions for n-grams and not 
just single words comes in. By using n-grams and not 
just what we conventionally have decided to treat as a 
single word (real speech shows no pauses in the 
sequence of sound waves for natural n-grams) you have 
the opportunity to use context as a guide in your 
unique entries.

If you don't want to go down this path the only solution would be to have multiple entries for the 
word so that it can be associated with multiple roots. 
The first query would return all the roots. The second 
query would return the three roots with their entries.

For maximum user friendliness the user would have the 
option to select the single word (with its possible 
multiple entries) or the natural n-gram in which it 
sits (with a potentially much less ambiguous entry).

Again, I cannot stress strongly enough that if you 
were to have definitions for each and every single 
word the logic of such an application would be greatly 
simplified. In the scenario of words that have multiple 
possible derivations the word could have as its entry 
whatever you feel like. You could put a comma separated 
list of possible meanings and derivations all in the 
one field. What this means in plain English is that 
everything could be held in the one table with no need 
for multiple queries or multiple tables, i.e. faster, 
cleaner and more user friendly.

James Christian Read - BSc Computer Science 
http://www.lamie.org/hebrew       -  thesis1: concept driven machine translation using the Aleppo codex 
http://www.lamie.org/lad-sim.doc  -  thesis2: language acquisition simulation
http://www.lamie.org/ngelta




































































































More information about the b-hebrew mailing list