I will check into the copyright issues with G-K numbers (thanks for the
cautionary reminder). I would think they would be free in granting
permission to use the numbers because it increases their usability and
visibility, but who knows.
The purist in me wants to use the lemma as the key, but that isn't
always realistic given the "market" for these sorts of things. And right
now there is only one module which uses the lemma as the key, and it's
in beta.
The other MAJOR problem is that the dictionary keys are always
capitalized, which makes it really awkward to use for Greek. Can I lobby
again for a change in that? How many Greek students are used to looking
up words in capitals? I was taught using lower case letters, and many of
the capitals are really fuzzy. When reading I can work them out based on
context sometimes because I have the rest of the word to clue me in.
Capitals also make accent marks look strange. Then there is the issue of
sort order again...
What I am hearing from Eeli and Jonathan is a move toward lemma as the
key for dictionaries but a recognition that multiple keys could be
useful. Is there is a way to encode TEI dictionaries to have multiple
key options using n, key, and sortKey? I mean, why not encode
dictionaries with each entry assigned a Strong's number (n?) and a
StrongLemma (sortKey?)?
We plan to make our source file include at least Strong's numbers and
lemma, so it will be easier in the future to switch between the two or
add more. We'll have G-K numbers if we can navigate the copyright issues.
Daniel
Jonathan Morgan wrote:
On Mon, Jan 19, 2009 at 9:40 PM, Eeli Kaikkonen
<eekai...@mail.student.oulu.fi> wrote:
Quoting Daniel Owens <dhow...@pmbx.net>:
I have a technical question, though. We will be using SIL's MDF markers
(similar to USFM) for the source file which can then be transformed
into TEI or other formats for various uses. I am thinking that each
entry should include Strong's number(s), the lexical form, and
Goodrick-Kohlenberger number(s). The G-K numbers seem to be a modern
replacement for Strong's.
My guess is that G-K must be forgotten because it's copyrighted. The list of
number/word connections is a creative work.
The whole idea of using Strong's or other numbers with computer software is
strange. We have discussed about this before, but I repeat that numbers are
needless because computers are able to do the searches and to show correct
entries in a dictionary without numbers. The problem in getting rid of them
is that people are so used to them that they think they give some extra
value to software/modules, and some people are used to reading the numbers
and can't live without them.
Numbers are of course good if you need to use external material, too
(printed books). Therefore they are useful and even necessary in
electronical resources. But you shouldn't use G-K without asking the
copyright holder.
Also, if you are using a module like our KJV it is using Strong's
Numbers internally (though you are welcome to then display the word
rather than the number, which BPBible does though I doubt it does it
perfectly).
Another problem that you will probably run into with the Greek is that
the different texts have a different vocabulary. The KJV and the NKJV
are based on the Textus Receptus, and as a result Strongs Numbers are
also based on the Textus Receptus vocabulary. If you look at the
introduction to a version of Thayer's Lexicon keyed to Strongs Numbers
but based on a different text you will find some words not present at
all, and others added with numbers like (1234a), meaning that it is a
word not in the Textus Receptus, but in whatever text is used as the
basis of Thayers. This might make it harder to use Strong's Numbers
or something similar as a universal keying standard (we really need
multiple keys for such dictionaries - maybe Strong's Numbers for
programmatic lookup (and people if they really insist), as well as
Greek and probably transliterated Greek like Strong's Dictionary has).
Jon
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page