mstalker Posted November 19, 2016 Share Posted November 19, 2016 (edited) The Kohlenberger/Mounce Hebrew dictionary sometimes pulls up the wrong definitions. Here are some examples: Genesis 1:11 - עַל - Accordance defines this as "upon, over above." KM defines this as "Most High." Genesis 1:22 - וַיְבָרֶךְ - Accordance defines this as "to bless." KM defines this as "to kneel down" or "to make kneel." Genesis 1:22 - וּרְבוּ - Accordance: "to be many, great." KM: "Greater Sidon" Genesis 1:26 and 1:28 - בִדְגַת - Accordance "fish" (noun). KM: "to increase, multiply." This also happens here: Genesis 2:3 - וַיְקַדֵּשׁ Genesis 2:5 - שִׂיחַ Genesis 2:7 - בְּאַפָּיו and חַיָּה Genesis 2:9 and 2:17 - טוֹב Genesis 2:18 - עֵזֶר - KM mentions "help," but seems to mention it as a cross reference. The main definition seems to be "Ezer." Genesis 23:12 - וַיִּשְׁתַּ֙חוּ֙ I'm using Accordance version 2.4.3 for iOS. Edited November 19, 2016 by mstalker Link to comment Share on other sites More sharing options...
Solly Posted November 19, 2016 Share Posted November 19, 2016 I see what you mean, though I find that the NIV11-GKE and NIV11-GK texts give the expected behavior. All other tagged texts that I have give results as you described, though the KM entry expected is usually adjacent to the one opened by the triple click. Very interesting. My experiments were done with Accordance Ver. 12.0.1. Shalom, Joseph Link to comment Share on other sites More sharing options...
Chris Rockwell Posted November 28, 2016 Share Posted November 28, 2016 The Kohlenberger/Mounce Hebrew dictionary sometimes pulls up the wrong definitions. Here are some examples: Genesis 1:11 - עַל - Accordance defines this as "upon, over above." KM defines this as "Most High." Genesis 1:22 - וַיְבָרֶךְ - Accordance defines this as "to bless." KM defines this as "to kneel down" or "to make kneel." Genesis 1:22 - וּרְבוּ - Accordance: "to be many, great." KM: "Greater Sidon" Genesis 1:26 and 1:28 - בִדְגַת - Accordance "fish" (noun). KM: "to increase, multiply." This also happens here: Genesis 2:3 - וַיְקַדֵּשׁ Genesis 2:5 - שִׂיחַ Genesis 2:7 - בְּאַפָּיו and חַיָּה Genesis 2:9 and 2:17 - טוֹב Genesis 2:18 - עֵזֶר - KM mentions "help," but seems to mention it as a cross reference. The main definition seems to be "Ezer." Genesis 23:12 - וַיִּשְׁתַּ֙חוּ֙ I'm using Accordance version 2.4.3 for iOS. Hey, You could try Amplifying using the ID and you'll see several definitions or consider using a different Hebrew lexicon (like HALOT, BDB Complete, or DCH). This is not a bug though, the words you're applying have a lot of different definitions and the Hebrew tool you're using doesn't include verse references for an accurate amplify. Hope this helps. Chris Link to comment Share on other sites More sharing options...
Mark Allison Posted November 29, 2016 Share Posted November 29, 2016 The Kohlenberger/Mounce Hebrew dictionary sometimes pulls up the wrong definitions. Here are some examples: Genesis 1:11 - עַל - Accordance defines this as "upon, over above." KM defines this as "Most High." Genesis 1:22 - וַיְבָרֶךְ - Accordance defines this as "to bless." KM defines this as "to kneel down" or "to make kneel." Genesis 1:22 - וּרְבוּ - Accordance: "to be many, great." KM: "Greater Sidon" Genesis 1:26 and 1:28 - בִדְגַת - Accordance "fish" (noun). KM: "to increase, multiply." This also happens here: Genesis 2:3 - וַיְקַדֵּשׁ Genesis 2:5 - שִׂיחַ Genesis 2:7 - בְּאַפָּיו and חַיָּה Genesis 2:9 and 2:17 - טוֹב Genesis 2:18 - עֵזֶר - KM mentions "help," but seems to mention it as a cross reference. The main definition seems to be "Ezer." Genesis 23:12 - וַיִּשְׁתַּ֙חוּ֙ I'm using Accordance version 2.4.3 for iOS. I'd like to track down these issues. Could you let me know what base text you were using when you amplified to KM Hebrew? Thanks! Link to comment Share on other sites More sharing options...
mstalker Posted December 10, 2016 Author Share Posted December 10, 2016 Could you let me know what base text you were using when you amplified to KM Hebrew? I think I was using the HMT-W4. Link to comment Share on other sites More sharing options...
mstalker Posted December 10, 2016 Author Share Posted December 10, 2016 This is not a bug though, the words you're applying have a lot of different definitions and the Hebrew tool you're using doesn't include verse references for an accurate amplify. Thanks for your reply, Chris! From a software developer's perspective, I think I agree that it's not a bug, and that the app is functioning as designed. I'm assuming that the intended behavior is to find the first matching word in the KM lexicon, and display it. From the user's perspective, though, the app does not do what is expected. When I see a definition for a word, my assumption is that it's a correct definition. If I told my daughter to wind up the clock, and she asked me what "wind" means, it would be incorrect to tell her that it means, "movement of air that you can feel." Without a context, that's a correct definition of "wind." However, in context, it's a wrong definition. If the KM doesn't have the capability of giving the developer (or user) a correct definition every time, I'd suggest doing one of the following: display all definitions, and allow the user to scroll through them refrain from displaying any definitions, show the user a message detailing why, and provide instructions for amplifying to display all possible definitions. I suppose I'd say that it's a UX bug, rather than an algorithmic one. What are your thoughts? Link to comment Share on other sites More sharing options...
Chris Rockwell Posted December 12, 2016 Share Posted December 12, 2016 Thanks for your reply, Chris! From a software developer's perspective, I think I agree that it's not a bug, and that the app is functioning as designed. I'm assuming that the intended behavior is to find the first matching word in the KM lexicon, and display it. From the user's perspective, though, the app does not do what is expected. When I see a definition for a word, my assumption is that it's a correct definition. If I told my daughter to wind up the clock, and she asked me what "wind" means, it would be incorrect to tell her that it means, "movement of air that you can feel." Without a context, that's a correct definition of "wind." However, in context, it's a wrong definition. If the KM doesn't have the capability of giving the developer (or user) a correct definition every time, I'd suggest doing one of the following: display all definitions, and allow the user to scroll through them refrain from displaying any definitions, show the user a message detailing why, and provide instructions for amplifying to display all possible definitions. I suppose I'd say that it's a UX bug, rather than an algorithmic one. What are your thoughts? I don't believe that's the best course of action since we wouldn't know the context and if the definition is correct or not. Otherwise, we'd just find a way to display the correct definition instead. It's just a limitation of that particular Tool if you don't amplify. Maybe we'll find a solution in the future to handle these cases but for now, amplifying does the trick. I appreciate the suggestion. Thanks, Chris Link to comment Share on other sites More sharing options...
Solly Posted December 12, 2016 Share Posted December 12, 2016 From my little experiments, it appears that the triple click takes one to the first instance of the key value in the KM tool. Texts tagged with GK numbers work in getting one to the correct sense because of the greater granularity of the GK system. Texts tagged with Strong's get one to the "top" of the appropriate area of the KM tool, but one must then check for the appropriate entry among the equal Strong's number entries. This gives another good reason to have the NIV tagged texts handy. Are any other texts tagged with the GK numbers? Link to comment Share on other sites More sharing options...
Fabian Posted December 12, 2016 Share Posted December 12, 2016 From my little experiments, it appears that the triple click takes one to the first instance of the key value in the KM tool. Texts tagged with GK numbers work in getting one to the correct sense because of the greater granularity of the GK system. Texts tagged with Strong's get one to the "top" of the appropriate area of the KM tool, but one must then check for the appropriate entry among the equal Strong's number entries. This gives another good reason to have the NIV tagged texts handy. Are any other texts tagged with the GK numbers? Mounce NT Link to comment Share on other sites More sharing options...
Rick Bennett Posted December 12, 2016 Share Posted December 12, 2016 Thanks for your reply, Chris! From a software developer's perspective, I think I agree that it's not a bug, and that the app is functioning as designed. I'm assuming that the intended behavior is to find the first matching word in the KM lexicon, and display it. From the user's perspective, though, the app does not do what is expected. When I see a definition for a word, my assumption is that it's a correct definition. If I told my daughter to wind up the clock, and she asked me what "wind" means, it would be incorrect to tell her that it means, "movement of air that you can feel." Without a context, that's a correct definition of "wind." However, in context, it's a wrong definition. If the KM doesn't have the capability of giving the developer (or user) a correct definition every time, I'd suggest doing one of the following: display all definitions, and allow the user to scroll through them refrain from displaying any definitions, show the user a message detailing why, and provide instructions for amplifying to display all possible definitions. I suppose I'd say that it's a UX bug, rather than an algorithmic one. What are your thoughts? This has been brought up before, and to-date there hasn't been a good solution proposed or implemented. On the desktop app we have the ability to amplify with context, which helps in more exhaustive lexicons, but still doesn't help with KM Hebrew, nor is that a feature on iOS. If a more precise solution were implemented, I imagine it would use the homograph numbers in the Hebrew text tagging, and use that to amplify. However, not all dictionaries reference the homograph number in the same fashion (and some not at all, like KM Hebrew). So, it's a more complex issue than it appears at first, but one which I think we could improve upon in the future. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now