[b-hebrew] Karl's lexicon

JAMES CHRISTIAN READ JCR128 at student.anglia.ac.uk
Fri Aug 24 17:35:40 EDT 2007


Hi Karl,

KWR: True, but even so, it is a big improvement over looking up in a paper
edition, which had been my other option before.

JCR: Absolutely!

KWR: I considered that, and I still haven't ruled it out. But at the same
time I don't want to handhold the student for every form.

JCR: I can see your point about handholding but ... 
put yourself back in the shoes of your beginner who 
just wants to read a simple text and understand it. 
Each time the reader confronts a word he does not know 
he has to:

i) Recognise the root so he can look it up
ii) Look it up
iii) Use morphology plus the meaning/s in the lexicon 
to figure out the intended meaning

This is a very slow and tiresome process and as a 
result only very small sections of text are generally 
read by beginners.

However, imagine being able to read the unpointed 
Hebrew text online and being able to click on any 
word in the text that you don't understand and 
instantly be taken to its entry in a lexicon. The 
reading would be sped up somewhat.

KWR: After all,
there are already analytical lexica to serve that purpose.

JCR: Yeah! Before I got burgled I used to have an 
analytical lexicon which listed every form and directed 
you to the root. What a drag using that was! First you 
look up the form and then are told to look up the entry in another part of the book. Talk about user
unfriendly!

KWR: On the programming side, were I to make this just one large file
separated by commas, how would I deal with all the definitions that
have commas within the definitions (e.g. as part of complex
sentences)?

JCR: Yeah! In the case of your data it would probably 
make more sense to use a '|' as the separator. It 
doesn't really matter what you use as long as the 
separator is unique and has no other use in your lines 
of data.

KWR: Wouldn't MySQL split those up, even though they should
remain together?

JCR: No! Not necessarily. Your data, if properly 
delimited, could be fed into a line editor like sed 
and your entire entries could be encased in quotation 
marks, making them be treated as a string. Like I said, 
all this would be routine for me, had the data made 
use of a unique delimiter.

KWR: Shouldn't data bases use a different character,
not a common one like a comma, to mark field borders so such
confusions don't occur?

JCR: It's not a database issue. It's an issue of the 
programmer being able to use simple programmatic 
methods to form a script which enters your data into 
a database. As both your roots and your definitions 
make use of commas you have rendered the comma 
unusable as a delimiter.

KWR: One idea that I had was to include every form, programmed in such a
way that when one clicks on a word while reading Tanakh, that it calls
up the words that could generate that form. But that is beyond my
programming ability. I know what I would want, just don't know enough
programming to accomplish it.

JCR: It could be done. But the logic would be far 
simpler if you had entries for every form. If you had 
entries for every form no 'form to root' matching logic 
would be necessary and the logic of the application 
would be greatly simplified.

Otherwise, each root would need a table in the database 
populated with derived forms so that forms could be 
associated with roots and the user could be taken to 
the root entry and its definition.

KWR: While checking up a lexeme today, I found a bi-gram that you don't
list, depending on alternate spellings, it occurs 5–8 times in Tanakh:
(L )DWT   על אדות

JCR: Are you sure? Have you tried browsing through the 
concordance. Note that the concordance is not ordering 
as it should do (a MySQL bug) and sometimes you may 
find the bi-gram in a place you didn't expect it be 
in the concordancer. 

I have been in touch with MySQL and they suggest that 
I can fix the ordering behaviour with server side 
configuration variables. I haven't managed to fix the 
problem yet, haven't had that much time (busy with PhD. 
proposals in MT). Have another look and let me know if 
it definitely isn't there. I'll then look into why that 
could be.

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







































































































proposals in MT). Have another look and let me know if 
it definitely isn't there. I'll then look into why that 
could be.

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





More information about the b-hebrew mailing list