Re: Strong's numbers: Numbers or strings

Fr Cyrille <[email protected]>
Newsgroups gmane.comp.literature.sword.devel
Message-ID <[email protected]>

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<[email protected]>  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<[email protected]>  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:Hxxxxx, 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 "<w savlm="strong:H07225">In the beginning</w>".
>> This fails in NASB and OSHB where we find "<w savlm="strong:H7225">In the beginning</w>".
>> 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 "00001" (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:[email protected]
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>>
>> _______________________________________________
>> sword-devel mailing list:[email protected]
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
> _______________________________________________
> sword-devel mailing list:[email protected]
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

_______________________________________________
sword-devel mailing list: [email protected]
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.