b-hebrew AT lists.ibiblio.org
Subject: Biblical Hebrew Forum
List archive
- From: "JAMES CHRISTIAN READ" <JCR128 AT student.anglia.ac.uk>
- To: b-hebrew AT lists.ibiblio.org
- Subject: [b-hebrew] Karl's lexicon
- Date: Fri, 24 Aug 2007 22:35:40 +0100
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
-
[b-hebrew] Karl's lexicon,
JAMES CHRISTIAN READ, 08/24/2007
- Re: [b-hebrew] Karl's lexicon, K Randolph, 08/24/2007
- <Possible follow-up(s)>
-
[b-hebrew] Karl's lexicon,
JAMES CHRISTIAN READ, 08/24/2007
- Re: [b-hebrew] Karl's lexicon, K Randolph, 08/25/2007
-
[b-hebrew] Karl's lexicon,
JAMES CHRISTIAN READ, 08/25/2007
- Re: [b-hebrew] Karl's lexicon, K Randolph, 08/25/2007
-
[b-hebrew] Karl's lexicon,
JAMES CHRISTIAN READ, 08/25/2007
- Re: [b-hebrew] Karl's lexicon, K Randolph, 08/25/2007
- [b-hebrew] Karl's lexicon, JAMES CHRISTIAN READ, 08/25/2007
-
[b-hebrew] Karl's lexicon,
JAMES CHRISTIAN READ, 08/25/2007
- Re: [b-hebrew] Karl's lexicon, K Randolph, 08/27/2007
-
[b-hebrew] Karl's lexicon,
JAMES CHRISTIAN READ, 08/28/2007
- Re: [b-hebrew] Karl's lexicon, K Randolph, 08/28/2007
Archive powered by MHonArc 2.6.24.