Bug Beta 2: Or is Docs Search just not complete?

I find Docs to be a lamentable name change, but I also find some of its workings to be unexpected.

1. No conversion of Logos 9 syntax

It does not offer to convert <Dt 6:4-7>

2. Unexpected results from bible search terms

a. A Bible term gives a result for the unlinked text in the tag area. Is this specific to Docs search or does it apply to other Search types? Note that I deliberately used "Deut" in the search term as it does not match "Dt" in the tag. So there has to be some parsing as Dt 6.5 is not found unless it is linked. But why does that give three results instead of 2? (I removed the space seen in the screenshot).

A search for "Lk 10:27" returns two results, and the full clipping is visible in the screenshot!

b. The result text for bible:"Deut 6:4-7" comes from the bottom of the Notes instead of the clipped text. That is unacceptable when the result for text:"Dt 6:4-7" quotes from the clipped text, which is far more relevant for results in the Tag area.

And please don't say that much/all of this happens in Logos 9 as users deserve to expect consistency and sense with the presentation of results.

Find more posts tagged with

Comments

Dave Hooton

Bumping this for a response

Ronny Woods (Faithlife)

https://community.logos.com/discussion/comment/1233513#Comment_1233513

Hi Dave--Thanks for the report. I don't have any good answers for you just yet, but wanted to let you know that we're looking into each of these:

1) On the surface it does seem like each search kind should be able to suggest the proper syntax from an attempt at `<Dt 6:4-7>`; I can't think of any reason why we wouldn't be able to do this for any search kind where the proper syntax would be relevant, but I need to check with some folks that are smarter than me on this topic.

2) The bible references in the clipping notes seem to be double-counted as hits. We'll create a bug case for this.

3) It isn't ideal that the search result preview when the hit is a tagged bible reference is simply the end of the clipping document, and this is especially weird when a hit in the tag on a text search does give back an expected preview.

More to come. I'll circle back here as I learn more.

Dave Hooton

https://community.logos.com/discussion/comment/1234082#Comment_1234082

More to come. I'll circle back here as I learn more.

Thank you.

Ronny Woods (Faithlife)

https://community.logos.com/discussion/comment/1234262#Comment_1234262

Hi Again Dave--Just a quick update here. I'll reference the numbers in my post above.

1) I haven't been able to dig into this further, but nobody has been able to tell me why we shouldn't expect the Docs search kind to provide the v1 to v2 bible search syntax suggestion. We've created a bug case to get this fixed.

2) In case you're interested in what was happening here, it appears we used to (many years ago) simply index the "plaintext" words in clippings notes (i.e. so the bible data type reference didn't get indexed as part of indexing the note). We had a separate process to go find any data type references in the note, and we index those separately at the end of the clipping document. At some point (looks like about 7 years ago) we started indexing the note's "rich text" (i.e. any data type references in the note began getting indexed as a data type reference), but we continued to also index those references separately at the end of the clipping document. TLDR: I believe that any references in the notes have been double-counted in the index for the last 7 years. We have a bug case to fix this.

3) Related to #2 above, the process to add data type references at the end of the clipping document also captures any tags that can be parsed as bible references, which is why it appears that a tag is "recognized" as a reference, but in reality the hit isn't on the tag, it's on this reference that's added at the end, which is why the preview shows the end of the clipping document. I think we can fix this by simply adding those references at a different point in the document. We also have a bug case to fix this one.

Can't commit to exactly when we'll get these done yet, but none of them seem overly complex, so hopefully they won't linger for too long.

Thanks again for the report, and for all the diligence digging into search!

-Ronny

Dave Hooton

https://community.logos.com/discussion/comment/1234354#Comment_1234354

Can't commit to exactly when we'll get these done yet, but none of them seem overly complex, so hopefully they won't linger for too long.

Thanks for the detailed explanation, Ronny.

Matt Mattox

https://community.logos.com/discussion/comment/1234449#Comment_1234449

Update --

Hi Dave,

This just pasted one of our rounds of QA. Our next update should be when this goes live to beta and/or production with the version number, of course.

Best,

Matt

Dave Hooton

https://community.logos.com/discussion/comment/1239945#Comment_1239945

thanks, Matt.

Dave Hooton

https://community.logos.com/discussion/comment/1239945#Comment_1239945

Update --

Hi Dave,

This just pasted one of our rounds of QA. Our next update should be when this goes live to beta and/or production with the version number, of course.

Best,

Matt

This is much improved in v23 Beta 3. My thanks to the team.