Jump to content

Automatic Strongs/GK Conversion


Brett K.

Recommended Posts

That gets me all the time. Apparently it is a feature in "other" software. I was talking to one of the authors of the NIV Concordance and he said his software does the conversion.

Link to comment
Share on other sites

It is feasible, but would require programming. It has not been requested before, so we would be interested to know what the purpose and benefits might be.

Link to comment
Share on other sites

When someone looks up a key number in a tool, that tool may use one or both of Strongs and GK. If you select another tool that does not use the numbering system of the previous tool, Accordance can't find the word. If I look up a key number and I'm not paying any attention to whether it is Strongs or GK, when I get to the tool and it doesn't work, I have to go through a process of, "What does the tool want? What did I look up? Which number do I need?"

I brought this up because it happens to me on a pretty regular basis. It would be cool if Accordance could make up for my stupidity.  :)  If it knew it was a key number that doesn't work, it could try the other key number system. Or it could offer to perform the search with the other system.

For example, if I enter a Strongs number in a GK tool, it displays a message asking if I would like to try the GK equivalent.

Maybe it's just me. Maybe other people don't have the problem. It's just one that I encounter often.

  • Like 2
Link to comment
Share on other sites

Well, I would say that Strong's system is clearly obsolete and people should just stop using it, making the world a better place for everyone.

As far as I know the GK system seems to be tied to the NIV only, and to my knowledge hasn't spread to any other versions.

 

Unless there was some kind of intermediate layer inside Accordance, which could automatically interpret texts on-the-fly and give either the Strong's number or the GK number (and would have to be clever enough to recognise where the Strong's number is wrong), and then pass that along to whatever other resource/dictionary/lexicon we were using.

Link to comment
Share on other sites

The data certainly exists - K/M dictionary lists both for example. It would be a matter of coding up the translation you speak of and handling cases where they don't match.

The problem with throwing away Strong's is as always with data, updating the files that use it with something better. If translation software existed for the key then a first pass of auto-updating the keys could be done. But it would need manual review for the additional cases where G/K supercedes or adds to Strong's in a manner which goes beyond simple number substitution.

 

It's essentially a bunch of rework and it could be done but ... all the usual questions arise.

 

Thx

D

Link to comment
Share on other sites

What catches me out when searching and cutting and pasting numbers, is that some tools use g and h prefixes while other tools dont have a prefix and just use the number (obviously the publishers dont care about other reference documents when dealing with hard copy but in an electronic environment...)

 

But its just fabulous being able to search multiple resources quickly and its only a couple of clicks to add or remove the letter as required. (Need to start using the full fat version more, just too easy to pick up ipad.)

 

;o)

Edited by ukfraser
  • Like 1
Link to comment
Share on other sites

When someone looks up a key number in a tool, that tool may use one or both of Strongs and GK. If you select another tool that does not use the numbering system of the previous tool, Accordance can't find the word. If I look up a key number and I'm not paying any attention to whether it is Strongs or GK, when I get to the tool and it doesn't work, I have to go through a process of, "What does the tool want? What did I look up? Which number do I need?"

 

I brought this up because it happens to me on a pretty regular basis. It would be cool if Accordance could make up for my stupidity.  :)  If it knew it was a key number that doesn't work, it could try the other key number system. Or it could offer to perform the search with the other system.

 

For example, if I enter a Strongs number in a GK tool, it displays a message asking if I would like to try the GK equivalent.

 

Maybe it's just me. Maybe other people don't have the problem. It's just one that I encounter often.

 

Your exact workflow isn't quite clear, but for example if you were to use opt-Ampify (or Win equiv) you can amplify by the lemma/lexeme associated with the Key Number, which is basically equivalent to automatically converting between the two key number systems.

 

In addition, in 'Amplify Preferences' you can 'Override Key Number Dictionaries' and choose another Greek/Hebrew lexicon of choice, and Accordance will automatically amplify by lemma/lexeme when you triple-click. After doing this you can then switch between tools and it will automatically use the lemma instead of the Key Number in any lexicon / dictionary (including Key Number dictionaries).

  • Like 1
Link to comment
Share on other sites

Your exact workflow isn't quite clear, but for example if you were to use opt-Ampify (or Win equiv) you can amplify by the lemma/lexeme associated with the Key Number, which is basically equivalent to automatically converting between the two key number systems.

 

In addition, in 'Amplify Preferences' you can 'Override Key Number Dictionaries' and choose another Greek/Hebrew lexicon of choice, and Accordance will automatically amplify by lemma/lexeme when you triple-click. After doing this you can then switch between tools and it will automatically use the lemma instead of the Key Number in any lexicon / dictionary (including Key Number dictionaries).

I did not know about this option. I will take a look.

 

Are there any disadvantages in using the lemma instead of the key number? If not, should that be the default option?

 

Thanks

Link to comment
Share on other sites

When the key number has to be entered manually (or copy and pasted) is another place the problem can occur. If I'm using a tool which used a key number but till not amplify with that key number, I have to manually enter it. Then when I switch to another tool that uses the other numbering system, it can't find the word.

Thanks

Edited by Brett K.
Link to comment
Share on other sites

When the key number has to be entered manually (or copy and pasted) is another place the problem can occur. If I'm using a tool which used a key number but till not amplify with that key number, I have to manually enter it. Then when I switch to another tool that uses the other numbering system, it can't find the word.

 

Thanks

 

Can you give me an example of this scenario? I can't readily think of one where you would need to enter manually a key number.

Link to comment
Share on other sites

I did not know about this option. I will take a look.

 

Are there any disadvantages in using the lemma instead of the key number? If not, should that be the default option?

 

Thanks

 

The only disadvantage I can think of is that in Hebrew specifically there are often words with multiple homographs (bra for example), and the key number will give the correct one without having to filter through results. However, there are only a few tools where this is affected (KM Hebrew for example). In the standard lexicons when you amplify with context it will almost always give you the correct homograph based on the context where the word is used.

Link to comment
Share on other sites

Can you give me an example of this scenario? I can't readily think of one where you would need to enter manually a key number.

 

I'm not saying this is the optimum workflow, but this is a workflow that will trigger the problem.

 

1. Open Exhaustive Analysis GNT

 

2. Double click on a key number. With my setup, it opens the ZPEB.

 

3. Switch to Thayer. It can't find the GK number since it only accept Strong's.

Link to comment
Share on other sites

It is feasible, but would require programming. It has not been requested before, so we would be interested to know what the purpose and benefits might be.

In this thread, I was trying to figure out how to search for translations from a given original word coded with Strong's. I had the NIV with G/K numbers also in my workspace (below). I just assumed the G/K numbers were cross-coded to the Strong's ones wherever they could be. Not so. The workspace would not tie/link properly until I removed the one text that used the G/K numbers and left only ones with Strong's numbers. So that means I cannot do this search quickly for the NIV since I have to figure out what G/K number matches the Strong's number and then do a separate search.

 

Therefore, I agree that linking these together would be a great improvement.

 

Thanks,

Eric

EC Search for Key# (EN).accord.zip

 

 

STRANGE THING: the Accordance forum won't let me upload an *.accord file (workspace), but if I zip it, it's OK.

Link to comment
Share on other sites

This just occurred in my normal workflow. I was not even working on this problem. It just happened while I was studying a verse.

1. I double-clicked on the word "but" in Gal 5.6 ESV.
 

2. It opened the entry using the Strong's key number in the Mounce Greek Dictionary.

3. I switched the NIDNTT and it couldn't find anything with that key number.

That's the kind of stuff that happens all the time. It would be nice if when I switched to NIDNTT Accordance knew to look for the GK number rather than the Strong's number.

Edited by Brett K.
  • Like 1
Link to comment
Share on other sites

Rick's question had to do with workflows involving manually typing a key number.  We are aware that the two schemes do run into each other at times.

Link to comment
Share on other sites

Sorry, I was just trying to demonstrate where I run into the problem. Like I said, I may be the only one who experiences this on a somewhat regular basis. No biggy just for me. I'll live. :)

Thanks

Edited by Brett K.
Link to comment
Share on other sites

This just occurred in my normal workflow. I was not even working on this problem. It just happened while I was studying a verse.

 

1. I double-clicked on the word "but" in Gal 5.6 ESV.

 

2. It opened the entry using the Strong's key number in the Mounce Greek Dictionary.

 

3. I switched the NIDNTT and it couldn't find anything with that key number.

 

That's the kind of stuff that happens all the time. It would be nice if when I switched to NIDNTT Accordance knew to look for the GK number rather than the Strong's number.

 

This is the scenario I had in mind most when suggesting to amplify by lemma. If you plan on utilizing any lexicon in addition to Mounce or KM, I strongly suggest amplifying by lemma to avoid using key numbers. The lemma is the bridge between the key number systems, and we provide that for you in Instant Details, opt-amplify, or copy as > lexical form.

 

The only other minor suggestion here is that if you want more in depth discussion on prepositions, conjunctions, etc. to use a lexicon like BDAG. NIDNTT will not have any significant discussion on these types of words (hence the fact that it has to search the Greek content field to find any hits). 

Link to comment
Share on other sites

Joel/ rick

My workflow is im reading the good shepherd by kenneth bailey as a hard copy.

 

In psalm 23, bailey has an interesting interpretation on verse 3. I opened up accordance on my ipad and used interlinear and found נַפְשִׁי in verse 3 and wanted to explore it in hebrew but then also see how soul is also handled in greek so used bdb, niv hebrew dictionary, mounce expository, km hebrew, nidntte, etc and ended up copying and pasting both strong and gk numbers as well as the actual hebrew word in my various resources. Thats when i was coming across using both h and non h numbers as well as working out which tool required strong or gk numbers.

 

Great to be able to search but it was interesting that brett raised this topic a couple of days after i was having an interesting time using search in ios ( and relearning about all the ways you can search in resources).

 

As brett says, no biggy, but interesting a couple of us found this at the same time from different directions.

 

No way i would want to be without accordance, especially on ios and all the mega tagging and fantastic search.

 

;o)

Edited by ukfraser
Link to comment
Share on other sites

Joel/ rick

My workflow is im reading the good shepherd by kenneth bailey as a hard copy.

 

In psalm 23, bailey has an interesting interpretation on verse 3. I opened up accordance on my ipad and used interlinear and found נַפְשִׁי in verse 3 and wanted to explore it in hebrew but then also see how it is also handled in greek so used bdb, niv hebrew dictionary, mounce expository, km hebrew, nidntte, etc and ended up copying and pasting both strong and gk numbers as well as the actual hebrew word in my various resources. Thats when i was coming across using both h and non h numbers as well as working out which tool required strong or gk numbers.

 

Great to be able to search but it was interesting that brett raised this topic a couple of days after i was having an interesting time using search in ios ( and relearning about all the ways you can search in resources).

 

As brett says, no biggy, but interesting a couple of us found this at the same time from different directions.

 

No way, i would want to be without accordance, especially on ios and all the mega tagging and fantastic search.

 

;o)

 

In this case the Mobile app has some catching up to do. My recommendation is to amplify by key number from your text of choice. To study it deeper, touch and hold on the lexical form in Mounce or KM, and then select amplify. This will open up your default Greek / Hebrew lexicon. From there cycle through different lexicons by showing the search entry (unhide menu bar, touch magnifying glass icon), touch the module name from below the search entry and select a different module from the list, then touch search on the keyboard. Continue to cycle through lexicons in this manner. 

 

Again, as I mentioned to Brett, I recommend getting away from the key number when doing any kind of research, even if the resource has a Key Number / Strong's Number field; use the lemma / lexical form provided.

 

Hope this helps…

  • Like 1
Link to comment
Share on other sites

In this thread, I was trying to figure out how to search for translations from a given original word coded with Strong's. I had the NIV with G/K numbers also in my workspace (below). I just assumed the G/K numbers were cross-coded to the Strong's ones wherever they could be. Not so. The workspace would not tie/link properly until I removed the one text that used the G/K numbers and left only ones with Strong's numbers. So that means I cannot do this search quickly for the NIV since I have to figure out what G/K number matches the Strong's number and then do a separate search.

 

Therefore, I agree that linking these together would be a great improvement.

 

Thanks,

Eric

attachicon.gifEC Search for Key# (EN).accord.zip

 

 

STRANGE THING: the Accordance forum won't let me upload an *.accord file (workspace), but if I zip it, it's OK.

 

I think there are more ways to approach this question rather than relying strictly on the key number. I'm out of time today to offer any further suggestions, but will try to do so in that thread later.

  • Like 1
Link to comment
Share on other sites

What catches me out when searching and cutting and pasting numbers, is that some tools use g and h prefixes while other tools dont have a prefix and just use the number (obviously the publishers dont care about other reference documents when dealing with hard copy but in an electronic environment...)

 

But its just fabulous being able to search multiple resources quickly and its only a couple of clicks to add or remove the letter as required. (Need to start using the full fat version more, just too easy to pick up ipad.)

 

;o)

Looking good Fraser. Now you just need an eink device with real pages and leather binding to be invented and you are set.

 

Any chance of a screen shot of the display preferences you have for NIDNTTE?

Link to comment
Share on other sites

Thanks rick, the problem is that while i can use different hebrew tools for hebrew. But as soon as i wanted to explore in mounce expository, it is an english tool so not available and then when i wanted to explore soul in greek, from english tools i cant go into greek tools, hence a lot of copying and pasting.

 

one day...

 

But until then, its great having what we have and interlinear is just sooooooo good.

 

Nidntte is default though i switch between 16 and 18 point.

 

;o)

Edited by ukfraser
Link to comment
Share on other sites

I looked up a transliteration in the NIDOTTE (Hebel). I decided to look it up in the ESV using its key number. I copied the key number out of the NIDOTTE and pasted it into an ESV search window like this:
 

[Range Eccl] [Key H2039]

 

It couldn't find it. The NIDOTTE used GK and the ESV wants Strong's. That's an area where I have a "manual" entry issue. My initial suggestion was that on failure it automatically convert the GK number to Strong's and either try the search again or ask if I wanted to do a search with the Strong's number.

Just today I've ran into the key number problem twice in my normal course of study. In any given Accordance session lasting an hour or more, I usually run into it in some form about 3-5 times.

As I said before, maybe it's just me and I have a goofy way of doing things. If so, just ignore it and pray for me. :-)

Thanks

Edited by Brett K.
  • Like 1
Link to comment
Share on other sites

Or you could use the niv with enhanced Gk when using gk based tools. (Sometimes the niv more formal than the so called formal translations!)

 

;o)

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...