Feedback on new Morph search
Thanks for allowing us to mix and match morph databases. Very helpful.
I ran a few test searches yesterday with mixed results. My main confusion had to do with the fact that when I press Tab to close the search drop down, the search string is not expanded to the full version, even when it should be. This leads to searches not working properly when you then continue adding searches from other databases.
From what I can tell, the only way to make the search string expand to the full version is to press Enter, but this actually runs the search. It would be nice if Tab would expand the search string when necessary without running the search.
Comments
-
I was confused by the description of this feature in the release notes. I thought the release notes were saying I could just choose @V and it would search for verbs in all morphologies (I didn't understand how this would work in more complex cases, but nonetheless, I thought that was what was being said).
I now understand that if I wanted to do that, I would need to construct the search myself in every morphology. That could be very time consuming. It might be helpful to have an "All morphologies" option in the dropdown, and constrain that to just the basic parts of speech that are in common across all morphologies.
It would also be helpful to have some options for multiple morphologies for Hebrew/Aramaic too, so that we could search the whole of the OT without having to construct our search twice. I think the SESB Hebrew/Aramaic morphologies are identical, for example.
Fr Devin Roza said:From what I can tell, the only way to make the search string expand to the full version is to press Enter, but this actually runs the search. It would be nice if Tab would expand the search string when necessary without running the search.
I agree with this.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
What we have here is a halfway point between where we were, specifying one morph at the query level, and where we want to be, easily specifying a morph at the term level. Along the way, there will certainly be workflow kinks to work out. I'll have someone look into expanding the syntax at points prior to committing the search. Thanks!
0 -
Fr Devin Roza said:
Thanks for allowing us to mix and match morph databases.
Am I missing something...???, am I doing something wrong, or is there a bug? Adding a second search term doesn't seem to affect my results at all (see screenshots). I expected search terms to be combined via Boolean logic, just like other searches. I tested with the two searches below, which I expected to have VASTLY different results. I tried inserting "OR" between the terms and still made no difference, but when I inserted "AND" I got 0 results as I expected.
0 -
Reuben Helmuth said:
see screenshots
Please paste the queries (as text) into your post. That will make it easier for us to try to replicate your results.
0 -
Reuben Helmuth said:
I tried inserting "OR" between the terms and still made no difference,
<WIVUMorphHeb ~ VbP2MS??> OR <LogosMorphHeb ~ VbP2MS??> works, as does your term
<WIVUMorphHeb ~ VbP2MS??> OR <LogosMorphHeb ~ VaP1?????>
Dave
===Windows 11 & Android 13
0 -
Thanks Dave, I hadn't put spaces on either side of the OR. Playing around with it, it seems like "<x>, <y>" produces "OR" results, "<x> <y>" produces "AND" results (0), but "<x><y>" produces only "<x>" results. What's more, "<x><y>" is the format automatically inserted when typing @ to input an additional argument. It seems to me that it should somehow alert the user that "<x><y>" is not a valid format. If this were treated as an "AND" argument, thereby producing zero hits, the user would at least know that something is wrong.
0 -
Reuben Helmuth said:
What's more, "<x><y>" is the format automatically inserted when typing @ to input an additional argument.
To clarify, that happens only if the first argument is converted from @Morph to <Explicit Morph> format! In another scenario a user will only get @Morph.
Reuben Helmuth said:It seems to me that it should somehow alert the user that "<x><y>" is not a valid format.
To be precise, the engine should convert an input like <LogosMorphHeb ~ Va?1?????>@N to a valid format because an input like @V??1@ is clearly seen as incorrect (but not flagged invalid), forcing one to insert a space -->
Dave
===Windows 11 & Android 13
0 -
Fr Devin Roza said:
From what I can tell, the only way to make the search string expand to the full version is to press Enter, but this actually runs the search. It would be nice if Tab would expand the search string when necessary without running the search.
Fixed in 6.10 Beta 4.
Updated Morph Search to auto complete when dismissing the selection pop up by pressing; Space Bar, Esc, Tab or clicking outside of the selection box.
0
