Re: Searching for entity attributes

> On 5/14/24 5:20 PM, David "Judah's Shadow" Blue wrote:
>>>
>>> I'm sure I could add some logic to check the given module and adapt the
>>> token to fit, but that doesn't help the other issue I've found. When
>>> searching for, say, G11 in a module that isn't 0 padded, all occurrences
>>> of G11 are found, but so are all occurrences of G110, G1105, etc.
>>> Assuming that normalization of padding on the entity attributes adds
>>> padding to them so it's in the form of G0XXXX, that should cut down on
>>> the false matches significantly.
>>>
>>> In node-sword-interface I added some logic for this, so that the user does
>>> not have to consider that.
>>>
>>>
>>> https://github.com/ezra-bible-app/node-sword-interface/blob/794c349bece231
>>> e2aa58bdacb7fe4aaffe774bcf/src/sword_backend/module_search.cpp#L146>
>>>              // If the Strong's key is OT we need to insert a zero in front
>>>
>>> of the key
>>>
>>>              // This is necessary because the Sword modules with Strong's
>>>
>>> have a zero in front of the Hebrew Strong's numbers
>>>
>>>              if (searchTerm[0] == 'H' &&
>>>
>>> this->_textProcessor.moduleHasStrongsZeroPrefixes(module)) {
>>>
>>>                  // Cut out the number from the Strong's key (starting at
>>>
>>> index 1 until end of string)
>>>
>>>                  string strongsKey = searchTerm.substr(1,
>>>
>>> searchTerm.size());
>>>
>>>                  // Overwrite the searchTerm with an inserted 0
>>>                  searchTerm = "H0" + strongsKey;
>>>              
>>>              }
> I just checked in diatheke and it looks like this will fail for the NASB, for
> instance, because the NASB doesn't have leading 0s in either Testament.
>
> And the bigger issue in my interface, when you retrieve a Strong's number from
> the lexicon by searching for a term (i.e. Alpha), it passes through the
> strongsPadding logic and gets leading 0's added. Until strongsPadding is added
> to the entity attribute search in the SWORD engine, I may fall back to
> stripping 0's out of the users input if the first search comes up empty. But
> that still won't solve the issue of searching for G matching G11, and so on.
> For that, I feel, the solution is to do use the strongsPadding logic on the
> entity attributes since that seems to add leading 0's.

I don't think I have either of those issues in node-sword-interface.

The module-based logic has the purpose that you prevent adding the 
padding if the module does not have it - that's what the helper function 
moduleHasStrongsZeroPrefixes 
<https://github.com/ezra-bible-app/node-sword-interface/blob/794c349bece231e2aa58bdacb7fe4aaffe774bcf/src/sword_backend/text_processor.cpp#L610>() 
is for.

Regarding the issue with G1 also matching G11, etc. I have the following 
snippet of code below the section I posted above:

             // from swmodule.h api docs:
             // for use with entryAttrib search type to match whole 
entry to value, e.g., G1234 and not G12345
             flags |= SWModule::SEARCHFLAG_MATCHWHOLEENTRY;

             searchTerm = "Word//Lemma./" + searchTerm;

Best regards,
Tobias

_______________________________________________
sword-devel mailing list: [email protected]
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page