Re: [sword-devel] Strong's numbers: Numbers or strings

[Karl Kleinpaste]

No worries...

On 1/27/22 12:53 PM, Troy A. Griffitts wrote:
Yes, you are correct, we don't yet have an inverse solution, but we 
could add one by using the same strongsPad function during the lemma 
search or lemma index creation.


Yes, my deeper problem is that the search needs to match, style-wise, 
what is found throughout the OT of the Bible module at hand, using the 
dict key extracted from Xiphos' dict pane as source reference. It's a 
question of self-referential style matching using an unrelated external 
source.___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Strong's numbers: Numbers or strings

[Troy A. Griffitts]

Dear Karl,

I also just realized I answered the inversion of your question.

You are not attempting to go from Bible to Lexicon, but from Lexicon to Bible.

I am sorry for not taking more time to think about your example.

Yes, you are correct, we don't yet have an inverse solution, but we could add 
one by using the same strongsPad function during the lemma search or lemma 
index creation.

Let me have a bit more time to think through this.

Troy



On January 27, 2022 10:01:52 AM MST, "Troy A. Griffitts"  
wrote:
>Hi Karl,
>
>Yes, this history of how to record Strong's numbers has a long and 
>inglorious history.  The zero prefix was how the "Online Bible", from 
>which came most free online Bible resources back in the 1980s, recorded 
>Hebrew Strong's.  The Bible Foundation (the primary initial provider of 
>data for the Online Bible), trusted us with their data they provided to 
>the Online Bible for the open source community.  Most modules we 
>distributed from 1980-1990 were sourced from the Bible Foundation.
>
>I can't remember when we began using G and H prefixes to disambiguation 
>Strong's Hebrew numbers from Strong's Greek numbers-- it may have been 
>in the KJV2003 project.  We later adopted logic to allow Strong's 
>numbers to have suffixes like 1234b and OSIS allow '!' to split 
>suffixes, so we allowed 1234!c, but enough about history.
>
>Today, we have this odd bit of code in the engine to try to fix all of 
>this for the frontend developer, such that they shouldn't need to do 
>anything special, but simply use any 'G' or 'H' prefix to determine 
>which module you want to use for resolution, and pass the remainder to 
>the module:
>
>https://crosswire.org/svn/sword/trunk/src/modules/lexdict/swld.cpp
>
>scroll to the bottom, to the function strongsPad
>
>It should do exactly what is required for you and you shouldn't need to 
>do any special logic.
>
>Again, the frontend code probably should be something like:
>
>SWModule *lex = verseKey.getTestament() == 2 || 
>strongsKey.startsWith("G") ? strongGreek : strongsHebrew;
>
>if (strongsKey.startsWith("G") || strongsKey.startsWith("H")) strongsKey 
><< 1;  // shift the buffer left by one; i.e., drop the G or H
>
>lex.setKey(strongsKey);
>
>I know it's convoluted, but the history explains a bit of all the cases 
>we need to handle and we try to shield the frontend developer the best 
>we can:
>
>1
>
>G1
>
>G1!a
>
>01
>
>H1
>
>...
>
>
>
>On 1/27/22 06:27, Karl Kleinpaste wrote:
>> I have a Xiphos bug  
>> in which the facility to take a Strong's dict entry and search the 
>> Bible module for all its occurrences sometimes works and sometimes 
>> doesn't.
>>
>> The mechanism is straightforward: Take the key from the dict pane, 
>> note whether this is Heb or Grk, construct e.g. lemma:Hx, stuff 
>> that into the sidebar search, and execute the search. No sweat.
>>
>> The problem is with Heb refs. Because of the ancient habit that Heb 
>> Strong's refs are given a leading zero prefix (e.g. "07225") as a weak 
>> discriminant from Grk refs in the same number space, I actually handle 
>> this case explicitly. Strong's module keys are fixed, 5-digit strings, 
>> and the dict pane always shows this. When that key is taken to build 
>> the lemma search, I specifically include the last leading zero in the 
>> Heb case.
>>
>> This works in KJV and ESV where we find "In 
>> the beginning".
>> This fails in NASB and OSHB where we find "In 
>> the beginning".
>> Note H07225 vs H7225.
>>
>> The question revolves around what a Strong's ref ontologically is. 
>> Seriously, what is it?
>> Is it a number, written naturally with minimal required digits, stored 
>> for convenience in a character string?
>> Or is it a specific and fixed string of characters?
>>
>> In terms of module keys, it's a string of characters.
>> In terms of Bible markup, well... Opinion varies. As we see in this 
>> case, some Bibles encode as a natural number, occupying the normal 
>> (minimal) digits needed, but others take the fixed string approach so 
>> as to include a leading zero, but note that it's not a full, fixed, 
>> 5-digit string to match a dict key; it's just one leading zero, no 
>> matter how many natural digits follow. KJV encodes the 1st Heb ref as 
>> "01". Not "1" (natural number) and not "1" (module key); just "01".
>>
>> Result is that, by constructing zero-prefixed searches, such searches 
>> always fail in Bibles using natural/minimal digits because there's 
>> never a zero-prefixed match.
>>
>> This is different from Grk refs, which are stored in dict modules the 
>> same as Heb dict keys -- fixed 5-digit -- but are always marked up as 
>> natural numbers using minimal digits.
>>
>> As matters stand, I have no /a priori/ means by which to determine 
>> what to expect in a Bible's Heb Strong's markup. The dict pane's key 
>> from which to construct the search is fixed 5 digits. That is at first 
>> trimmed to 

Re: [sword-devel] Strong's numbers: Numbers or strings

[Troy A. Griffitts]

Hi Karl,

Yes, this history of how to record Strong's numbers has a long and 
inglorious history.  The zero prefix was how the "Online Bible", from 
which came most free online Bible resources back in the 1980s, recorded 
Hebrew Strong's.  The Bible Foundation (the primary initial provider of 
data for the Online Bible), trusted us with their data they provided to 
the Online Bible for the open source community.  Most modules we 
distributed from 1980-1990 were sourced from the Bible Foundation.


I can't remember when we began using G and H prefixes to disambiguation 
Strong's Hebrew numbers from Strong's Greek numbers-- it may have been 
in the KJV2003 project.  We later adopted logic to allow Strong's 
numbers to have suffixes like 1234b and OSIS allow '!' to split 
suffixes, so we allowed 1234!c, but enough about history.


Today, we have this odd bit of code in the engine to try to fix all of 
this for the frontend developer, such that they shouldn't need to do 
anything special, but simply use any 'G' or 'H' prefix to determine 
which module you want to use for resolution, and pass the remainder to 
the module:


https://crosswire.org/svn/sword/trunk/src/modules/lexdict/swld.cpp

scroll to the bottom, to the function strongsPad

It should do exactly what is required for you and you shouldn't need to 
do any special logic.


Again, the frontend code probably should be something like:

SWModule *lex = verseKey.getTestament() == 2 || 
strongsKey.startsWith("G") ? strongGreek : strongsHebrew;


if (strongsKey.startsWith("G") || strongsKey.startsWith("H")) strongsKey 
<< 1;  // shift the buffer left by one; i.e., drop the G or H


lex.setKey(strongsKey);

I know it's convoluted, but the history explains a bit of all the cases 
we need to handle and we try to shield the frontend developer the best 
we can:


1

G1

G1!a

01

H1

...



On 1/27/22 06:27, Karl Kleinpaste wrote:
I have a Xiphos bug  
in which the facility to take a Strong's dict entry and search the 
Bible module for all its occurrences sometimes works and sometimes 
doesn't.


The mechanism is straightforward: Take the key from the dict pane, 
note whether this is Heb or Grk, construct e.g. lemma:Hx, stuff 
that into the sidebar search, and execute the search. No sweat.


The problem is with Heb refs. Because of the ancient habit that Heb 
Strong's refs are given a leading zero prefix (e.g. "07225") as a weak 
discriminant from Grk refs in the same number space, I actually handle 
this case explicitly. Strong's module keys are fixed, 5-digit strings, 
and the dict pane always shows this. When that key is taken to build 
the lemma search, I specifically include the last leading zero in the 
Heb case.


This works in KJV and ESV where we find "In 
the beginning".
This fails in NASB and OSHB where we find "In 
the beginning".

Note H07225 vs H7225.

The question revolves around what a Strong's ref ontologically is. 
Seriously, what is it?
Is it a number, written naturally with minimal required digits, stored 
for convenience in a character string?

Or is it a specific and fixed string of characters?

In terms of module keys, it's a string of characters.
In terms of Bible markup, well... Opinion varies. As we see in this 
case, some Bibles encode as a natural number, occupying the normal 
(minimal) digits needed, but others take the fixed string approach so 
as to include a leading zero, but note that it's not a full, fixed, 
5-digit string to match a dict key; it's just one leading zero, no 
matter how many natural digits follow. KJV encodes the 1st Heb ref as 
"01". Not "1" (natural number) and not "1" (module key); just "01".


Result is that, by constructing zero-prefixed searches, such searches 
always fail in Bibles using natural/minimal digits because there's 
never a zero-prefixed match.


This is different from Grk refs, which are stored in dict modules the 
same as Heb dict keys -- fixed 5-digit -- but are always marked up as 
natural numbers using minimal digits.


As matters stand, I have no /a priori/ means by which to determine 
what to expect in a Bible's Heb Strong's markup. The dict pane's key 
from which to construct the search is fixed 5 digits. That is at first 
trimmed to natural, minimal digits...and then the trouble starts 
because I don't have anything like a module conf directive to tell me 
whether the module uses zero-prefixed Heb refs or not. I'm also not 
aware that we have any standard for such markup to which I can point 
to say, "NASB's markup is wrong because it lacks zero-prefixing on Heb 
refs."


Help.

___
sword-devel mailing list:sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page___
sword-devel mailing list: sword-devel@crosswire.org

Re: [sword-devel] Strong's numbers: Numbers or strings

[Fr Cyrille]

Le 27/01/2022 à 17:33, pierre amadio a écrit :

Fixing this for the OSHB module should be trivial.
Let me know if you want me to do it.
You mean directly on OSHB? This is a possibility. All module "just" add 
a zero in the good place...


On Thu, 27 Jan 2022 at 17:20, Fr Cyrille  wrote:



Le 27/01/2022 à 15:07, David Haslam a écrit :

What Karl has observed is a long-standing problem.

Might it be feasible to employ a suitable regular expression to match the 
Strong’s H number whether or not it has any leading zero[s]?

This would have to be done under the hood for this type of search, as it’s 
quite a different task than a user entered regex search.

But should such a workaround be better implemented in the SWORD API rather than 
as a kludge in a front-end?

And if so, how should JSword based front-ends also address the issue?


AndBible reads very well the Strong hebrew numbers.


David

Sent from ProtonMail for iOS


On Thu, Jan 27, 2022 at 13:27, Karl Kleinpaste  wrote:

I have a Xiphos bug in which the facility to take a Strong's dict entry and 
search the Bible module for all its occurrences sometimes works and sometimes 
doesn't.

The mechanism is straightforward: Take the key from the dict pane, note whether 
this is Heb or Grk, construct e.g. lemma:Hx, stuff that into the sidebar 
search, and execute the search. No sweat.

The problem is with Heb refs. Because of the ancient habit that Heb Strong's refs are 
given a leading zero prefix (e.g. "07225") as a weak discriminant from Grk refs 
in the same number space, I actually handle this case explicitly. Strong's module keys 
are fixed, 5-digit strings, and the dict pane always shows this. When that key is taken 
to build the lemma search, I specifically include the last leading zero in the Heb case.

This works in KJV and ESV where we find "In the 
beginning".
This fails in NASB and OSHB where we find "In the 
beginning".
Note H07225 vs H7225.

The question revolves around what a Strong's ref ontologically is. Seriously, 
what is it?
Is it a number, written naturally with minimal required digits, stored for 
convenience in a character string?
Or is it a specific and fixed string of characters?

In terms of module keys, it's a string of characters.
In terms of Bible markup, well... Opinion varies. As we see in this case, some Bibles encode as a natural number, 
occupying the normal (minimal) digits needed, but others take the fixed string approach so as to include a leading 
zero, but note that it's not a full, fixed, 5-digit string to match a dict key; it's just one leading zero, no matter 
how many natural digits follow. KJV encodes the 1st Heb ref as "01". Not "1" (natural number) and 
not "1" (module key); just "01".

Result is that, by constructing zero-prefixed searches, such searches always 
fail in Bibles using natural/minimal digits because there's never a 
zero-prefixed match.

This is different from Grk refs, which are stored in dict modules the same as 
Heb dict keys -- fixed 5-digit -- but are always marked up as natural numbers 
using minimal digits.

As matters stand, I have no a priori means by which to determine what to expect in a 
Bible's Heb Strong's markup. The dict pane's key from which to construct the search is 
fixed 5 digits. That is at first trimmed to natural, minimal digits...and then the 
trouble starts because I don't have anything like a module conf directive to tell me 
whether the module uses zero-prefixed Heb refs or not. I'm also not aware that we have 
any standard for such markup to which I can point to say, "NASB's markup is wrong 
because it lacks zero-prefixing on Heb refs."

Help.


___
sword-devel mailing list:sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page


___
sword-devel mailing list:sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list:sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Strong's numbers: Numbers or strings

[pierre amadio]

Fixing this for the OSHB module should be trivial.
Let me know if you want me to do it.

On Thu, 27 Jan 2022 at 17:20, Fr Cyrille  wrote:
>
>
>
> Le 27/01/2022 à 15:07, David Haslam a écrit :
>
> What Karl has observed is a long-standing problem.
>
> Might it be feasible to employ a suitable regular expression to match the 
> Strong’s H number whether or not it has any leading zero[s]?
>
> This would have to be done under the hood for this type of search, as it’s 
> quite a different task than a user entered regex search.
>
> But should such a workaround be better implemented in the SWORD API rather 
> than as a kludge in a front-end?
>
> And if so, how should JSword based front-ends also address the issue?
>
>
> AndBible reads very well the Strong hebrew numbers.
>
>
> David
>
> Sent from ProtonMail for iOS
>
>
> On Thu, Jan 27, 2022 at 13:27, Karl Kleinpaste  wrote:
>
> I have a Xiphos bug in which the facility to take a Strong's dict entry and 
> search the Bible module for all its occurrences sometimes works and sometimes 
> doesn't.
>
> The mechanism is straightforward: Take the key from the dict pane, note 
> whether this is Heb or Grk, construct e.g. lemma:Hx, stuff that into the 
> sidebar search, and execute the search. No sweat.
>
> The problem is with Heb refs. Because of the ancient habit that Heb Strong's 
> refs are given a leading zero prefix (e.g. "07225") as a weak discriminant 
> from Grk refs in the same number space, I actually handle this case 
> explicitly. Strong's module keys are fixed, 5-digit strings, and the dict 
> pane always shows this. When that key is taken to build the lemma search, I 
> specifically include the last leading zero in the Heb case.
>
> This works in KJV and ESV where we find "In the 
> beginning".
> This fails in NASB and OSHB where we find "In the 
> beginning".
> Note H07225 vs H7225.
>
> The question revolves around what a Strong's ref ontologically is. Seriously, 
> what is it?
> Is it a number, written naturally with minimal required digits, stored for 
> convenience in a character string?
> Or is it a specific and fixed string of characters?
>
> In terms of module keys, it's a string of characters.
> In terms of Bible markup, well... Opinion varies. As we see in this case, 
> some Bibles encode as a natural number, occupying the normal (minimal) digits 
> needed, but others take the fixed string approach so as to include a leading 
> zero, but note that it's not a full, fixed, 5-digit string to match a dict 
> key; it's just one leading zero, no matter how many natural digits follow. 
> KJV encodes the 1st Heb ref as "01". Not "1" (natural number) and not "1" 
> (module key); just "01".
>
> Result is that, by constructing zero-prefixed searches, such searches always 
> fail in Bibles using natural/minimal digits because there's never a 
> zero-prefixed match.
>
> This is different from Grk refs, which are stored in dict modules the same as 
> Heb dict keys -- fixed 5-digit -- but are always marked up as natural numbers 
> using minimal digits.
>
> As matters stand, I have no a priori means by which to determine what to 
> expect in a Bible's Heb Strong's markup. The dict pane's key from which to 
> construct the search is fixed 5 digits. That is at first trimmed to natural, 
> minimal digits...and then the trouble starts because I don't have anything 
> like a module conf directive to tell me whether the module uses zero-prefixed 
> Heb refs or not. I'm also not aware that we have any standard for such markup 
> to which I can point to say, "NASB's markup is wrong because it lacks 
> zero-prefixing on Heb refs."
>
> Help.
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
>
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Strong's numbers: Numbers or strings

[Fr Cyrille]

Le 27/01/2022 à 15:07, David Haslam a écrit :

What Karl has observed is a long-standing problem.

Might it be feasible to employ a suitable regular expression to match 
the Strong’s H number whether or not it has any leading zero[s]?


This would have to be done under the hood for this type of search, as 
it’s quite a different task than a user entered regex search.


But should such a workaround be better implemented in the SWORD API 
rather than as a kludge in a front-end?


And if so, how should JSword based front-ends also address the issue?


AndBible reads very well the Strong hebrew numbers.


David

Sent from ProtonMail for iOS


On Thu, Jan 27, 2022 at 13:27, Karl Kleinpaste  
wrote:
I have a Xiphos bug  
in which the facility to take a Strong's dict entry and search the 
Bible module for all its occurrences sometimes works and sometimes 
doesn't.


The mechanism is straightforward: Take the key from the dict pane, 
note whether this is Heb or Grk, construct e.g. lemma:Hx, stuff 
that into the sidebar search, and execute the search. No sweat.


The problem is with Heb refs. Because of the ancient habit that Heb 
Strong's refs are given a leading zero prefix (e.g. "07225") as a 
weak discriminant from Grk refs in the same number space, I actually 
handle this case explicitly. Strong's module keys are fixed, 5-digit 
strings, and the dict pane always shows this. When that key is taken 
to build the lemma search, I specifically include the last leading 
zero in the Heb case.


This works in KJV and ESV where we find "In 
the beginning".
This fails in NASB and OSHB where we find "In 
the beginning".

Note H07225 vs H7225.

The question revolves around what a Strong's ref ontologically is. 
Seriously, what is it?
Is it a number, written naturally with minimal required digits, 
stored for convenience in a character string?

Or is it a specific and fixed string of characters?

In terms of module keys, it's a string of characters.
In terms of Bible markup, well... Opinion varies. As we see in this 
case, some Bibles encode as a natural number, occupying the normal 
(minimal) digits needed, but others take the fixed string approach so 
as to include a leading zero, but note that it's not a full, fixed, 
5-digit string to match a dict key; it's just one leading zero, no 
matter how many natural digits follow. KJV encodes the 1st Heb ref as 
"01". Not "1" (natural number) and not "1" (module key); just "01".


Result is that, by constructing zero-prefixed searches, such searches 
always fail in Bibles using natural/minimal digits because there's 
never a zero-prefixed match.


This is different from Grk refs, which are stored in dict modules the 
same as Heb dict keys -- fixed 5-digit -- but are always marked up as 
natural numbers using minimal digits.


As matters stand, I have no /a priori/ means by which to determine 
what to expect in a Bible's Heb Strong's markup. The dict pane's key 
from which to construct the search is fixed 5 digits. That is at 
first trimmed to natural, minimal digits...and then the trouble 
starts because I don't have anything like a module conf directive to 
tell me whether the module uses zero-prefixed Heb refs or not. I'm 
also not aware that we have any standard for such markup to which I 
can point to say, "NASB's markup is wrong because it lacks 
zero-prefixing on Heb refs."


Help.


___
sword-devel mailing list:sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Strong's numbers: Numbers or strings

[John Dudeck]

Why not just add a normalization method to Sword? Ie. if the numeric reference starts with '0', pad it out to 5 digits?


John Dudeck


> 
> What Karl has observed is a long-standing problem.
> 
> Might it be feasible to employ a suitable regular _expression_ to match the Strong’s H number 
> whether or not it has any leading zero[s]?
> 
> This would have to be done under the hood for this type of search, as it’s quite a different task 
> than a user entered regex search.
> 
> But should such a workaround be better implemented in the SWORD API rather than as a kludge 
> in a front-end?
> 
> And if so, how should JSword based front-ends also address the issue?
> 
> David
> 
> Sent from ProtonMail for iOS
> 
> 
> On Thu, Jan 27, 2022 at 13:27, Karl Kleinpaste  wrote:
> I have a Xiphos bug in which the facility to take a Strong's dict entry and search the Bible module for 
> all its occurrences sometimes works and sometimes doesn't.
> 
> The mechanism is straightforward: Take the key from the dict pane, note whether this is Heb or Grk, 
> construct e.g. lemma:Hx, stuff that into the sidebar search, and execute the search. No sweat.
> 
> The problem is with Heb refs. Because of the ancient habit that Heb Strong's refs are given a leading 
> zero prefix (e.g. "07225") as a weak discriminant from Grk refs in the same number space, I actually 
> handle this case explicitly. Strong's module keys are fixed, 5-digit strings, and the dict pane always 
> shows this. When that key is taken to build the lemma search, I specifically include the last leading 
> zero in the Heb case.
> 
> This works in KJV and ESV where we find "In the beginning".
> This fails in NASB and OSHB where we find "In the beginning".
> Note H07225 vs H7225.
> 
> The question revolves around what a Strong's ref ontologically is. Seriously, what is it?
> Is it a number, written naturally with minimal required digits, stored for convenience in a character 
> string?
> Or is it a specific and fixed string of characters?
> 
> In terms of module keys, it's a string of characters.
> In terms of Bible markup, well... Opinion varies. As we see in this case, some Bibles encode as a 
> natural number, occupying the normal (minimal) digits needed, but others take the fixed string 
> approach so as to include a leading zero, but note that it's not a full, fixed, 5-digit string to match a 
> dict key; it's just one leading zero, no matter how many natural digits follow. KJV encodes the 1st Heb 
> ref as "01". Not "1" (natural number) and not "1" (module key); just "01".
> 
> Result is that, by constructing zero-prefixed searches, such searches always fail in Bibles using 
> natural/minimal digits because there's never a zero-prefixed match.
> 
> This is different from Grk refs, which are stored in dict modules the same as Heb dict keys -- fixed 
> 5-digit -- but are always marked up as natural numbers using minimal digits.
> 
> As matters stand, I have no a priori means by which to determine what to expect in a Bible's Heb 
> Strong's markup. The dict pane's key from which to construct the search is fixed 5 digits. That is at 
> first trimmed to natural, minimal digits...and then the trouble starts because I don't have anything like 
> a module conf directive to tell me whether the module uses zero-prefixed Heb refs or not. I'm also not 
> aware that we have any standard for such markup to which I can point to say, "NASB's markup is 
> wrong because it lacks zero-prefixing on Heb refs."
> 
> Help.


John Dudeck  Tel: +1-704-588-9891  Cell: +1-803-504-8065
john.dud...@sim.org    Charlotte, North Carolina
--
One of the greatest gifts you can give someone 
is thanking them for being part of your life.
  


___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

[sword-devel] Strong's numbers: Numbers or strings

[Karl Kleinpaste]

I have a Xiphos bug  in 
which the facility to take a Strong's dict entry and search the Bible 
module for all its occurrences sometimes works and sometimes doesn't.


The mechanism is straightforward: Take the key from the dict pane, note 
whether this is Heb or Grk, construct e.g. lemma:Hx, stuff that into 
the sidebar search, and execute the search. No sweat.


The problem is with Heb refs. Because of the ancient habit that Heb 
Strong's refs are given a leading zero prefix (e.g. "07225") as a weak 
discriminant from Grk refs in the same number space, I actually handle 
this case explicitly. Strong's module keys are fixed, 5-digit strings, 
and the dict pane always shows this. When that key is taken to build the 
lemma search, I specifically include the last leading zero in the Heb case.


This works in KJV and ESV where we find "In the 
beginning".
This fails in NASB and OSHB where we find "In 
the beginning".

Note H07225 vs H7225.

The question revolves around what a Strong's ref ontologically is. 
Seriously, what is it?
Is it a number, written naturally with minimal required digits, stored 
for convenience in a character string?

Or is it a specific and fixed string of characters?

In terms of module keys, it's a string of characters.
In terms of Bible markup, well... Opinion varies. As we see in this 
case, some Bibles encode as a natural number, occupying the normal 
(minimal) digits needed, but others take the fixed string approach so as 
to include a leading zero, but note that it's not a full, fixed, 5-digit 
string to match a dict key; it's just one leading zero, no matter how 
many natural digits follow. KJV encodes the 1st Heb ref as "01". Not "1" 
(natural number) and not "1" (module key); just "01".


Result is that, by constructing zero-prefixed searches, such searches 
always fail in Bibles using natural/minimal digits because there's never 
a zero-prefixed match.


This is different from Grk refs, which are stored in dict modules the 
same as Heb dict keys -- fixed 5-digit -- but are always marked up as 
natural numbers using minimal digits.


As matters stand, I have no /a priori/ means by which to determine what 
to expect in a Bible's Heb Strong's markup. The dict pane's key from 
which to construct the search is fixed 5 digits. That is at first 
trimmed to natural, minimal digits...and then the trouble starts because 
I don't have anything like a module conf directive to tell me whether 
the module uses zero-prefixed Heb refs or not. I'm also not aware that 
we have any standard for such markup to which I can point to say, 
"NASB's markup is wrong because it lacks zero-prefixing on Heb refs."


Help.___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page