Exegetical Issues
- Grammar
- Semantics
- Exegetical Issues
- Discourse
- Poetics
- Synthesis
- Close-but-Clear
- Videos
- Post to wiki
Version: 1.0
Overseer: Ryan Sikes
Introduction
The "Top 3 Exegetical Issues" are issues that any interpreter of the psalm, whether they’re reading the text in Hebrew or looking at a number of translations, is likely to encounter. These issues usually involve textual criticism, grammar, lexical semantics, verbal semantics, and/or phrase-level semantics, though they sometimes involve higher-level layers as well.
Steps
1. Identify Top 3 Exegetical Issues
There will often be more than three exegetical issues in a psalm, and these should be worked out in the relevant layers. For the purpose of our "Top 3 Exegetical Issues", however, we limit ourselves to the three most important issues. To determine which three issues are most important, ask the following questions:
- Do modern translations show significant disagreement on this issue? The more widespread the disagreement, the more need there is to treat the issue.[1] It is often helpful to browse through the footnotes in modern Bible translations.
- Do we take a minority position on this issue? If our view is not well represented in modern translations, then it may require additional justification. We will need to show why more popular views are inadequate and why our view is preferable.
- To what extent does the issue affect the interpretation of the psalm as a whole? If our interpretation of a psalm as a whole hangs on our understanding of a particular word, phrase, or grammatical construction, then this issue is more likely to be included among the Top 3 Exegetical Issues. All exegetical issues should have at least some meaningful impact on interpretation.
See our list of past and current Exegetical Issues for examples.
2. Set up the Wiki Page
In addition to creating videos for "Top 3 Exegetical Issues," we will create wiki pages that contain the same basic information in different form. The purpose of having a static presentation of the same material is two-fold:
- The wiki page will be the basis on which the video is created. The person working out the exegetical issues and the person creating the videos will not always be the same person. The wiki summary, then, becomes the means by which the exegete communicates the relevant information to the video creator, who will base his/her video on the information in the wiki page.
- The wiki page will provide an additional way for users to access the material. Those who prefer a static presentation to a video presentation can view the wiki page. At the same time, those who have already watched a video can refer to the relevant wiki pages for a brief summary of each issue.
2.1. Create wiki page
Log in to the wiki and create one new page for each exegetical issue. To create a page, type the name of the page you wish to create into the "Search" bar. When given the option to "Create the page "X" on this wiki!" click the link ("X"). Copy and paste the following text onto the wiki page: [[Category:Argument maps]] [[Chapter::X]]:[[Verse::X]] and fill in the chapter/verse numbers. This text should remain at the very bottom of the wiki page.
- Use title capitalization (also called headline case) when naming the page (e.g., "The Division of Ps 11:5" and not "The division of Ps 11:5).
- Use English titles where possible. If it is necessary to use Hebrew text in the title, use Hebrew characters (not English transliteration). Include vowels, and do not include Masoretic accents.[2]
2.2. Outline wiki page
Copy and paste the following text onto the wiki page:
=Introduction=
=Argument Maps=
=Conclusion=
=Research=
==Translations==
===Ancient===
===Modern===
==Secondary Literature==
=References=
[[Category:Argument maps]]
[[Chapter::X]]:[[Verse::X]]
All exegetical issue pages should follow this basic outline. Within this outline, however, there is room for variation. For example, some issues will have multiple argument maps, in which case each argument map should receive its own sub-section within the section titled ("Argument Maps"). Depending on the nature and complexity of the issue, the "Research" section may also have additional sub-sections, and those sub-sections may in turn have their own sub-sections.
3. Orient to the Issue
3.1. Consult Translations
Now that the issue is identified and the wiki page is prepared, the first step in dealing with the issue is to consult translations. Go to the psalm translation page (e.g., Psalm 100 Translations) and consult every translation listed on that page, beginning with the modern versions.
3.1.1. Modern Translations
In the "Research">"Translations">"Modern" section of the wiki page, include the text of all of the modern translations you consulted. Include any translation footnotes as footnotes.[3] Categorize these translations based on how they deal with the issue. Use wiki headings (e.g., ====heading====) to visually distinguish the categories and sub-categories. Your modern translations section should look similar to this example. Do not use wiki headings to group the modern translations by language.
For most exegetical issues, these modern translations will determine how you approach the issue. For example, every view reflected in a modern translation needs to be dealt with in an argument map (whether or not you think that view is viable), and views that are not reflected in a single modern translation probably do not need to be discussed in the exegetical issue page (unless you consider one of these views as viable and worth exploring).[4]
3.1.2. Ancient Translations
In the "Research">"Translations">"Ancient" section of the wiki page, list all of the ancient versions. Use footnotes to indicate the source of each version (e.g., "Rahlfs 1931"). Include English translations where available. Your ancient translations section should look similar to this example. You do not need to categorize the ancient translations as you did the modern translations; the ancient translations can simply be listed one after the other.
4. Structure the Argument Maps Section
Based on your analysis of the differences among modern translations, create categories and sub-categories in the "Argument Maps" section. Each view should have its own argument map. See e.g., The Syntax and Subject(s) of Ps. 112:4. At this point in the process, you do not need to complete any argument maps. Only determine which argument maps you are going to include, determine how you are going to arrange them hierarchically within the structure of the page, and then begin to create one argument map for each view.
4.1. Introduction to Argument Maps
An argument map is a visual representation of the logical structure of an argument. As a tool, argument mapping forces us to be both rigorous and transparent in arriving at conclusions. Each exegetical issue should have at least two accompanying argument maps, though most exegetical issues will likely have more. Each argument map should have a single conclusion with reasons and evidence supporting (or refuting) that conclusion.
E.g.,
[Conclusion]: State conclusion here.
+ <Supporting argument 1>: Give reasoning here.
+ [Evidence 1]: Cite evidence here.
+ <Supporting argument 2>: Give additional reasoning here.
+ [Evidence 2]: Cite evidence here.
Argument maps may be small or large depending on the complexity of the issue. For example, the issue of text division and grammar in Ps. 11:5 has two argument maps. The first one presents an argument for one view, and it is rather large. The second one presents an argument for a different view, and it is smaller and simpler.
Some exegetical issues may require several argument maps. For example, the issue of the interpretation of Ps. 11:1b, which involves textual criticism, grammar, and semantics, has seven argument maps.
4.2. How to read an argument map
All of the elements in an argument map are explained in the argument map below.
===
model:
removeTagsFromText: true
shortcodes:
":C:": {unicode: "🄲"}
":G:": {unicode: "🄶"}
":A:": {unicode: "🄰"}
":I:": {unicode: "🄸"}
":L:": {unicode: "🄻"}
":D:": {unicode: "🄳"}
":M:": {unicode: "🄼"}
selection:
excludeDisconnected: false
dot:
graphVizSettings:
concentrate: true
ranksep: 0.2
nodesep: 0.2
===
[Conclusion]: The conclusion of the argument map is presented as a white box with a colored outline. If the conclusion is preferred (i.e., if the creator of the argument map agrees with the conclusion), then the outline is green (as here).
+ <Supporting argument>: Arguments are presented as colored boxes. If an argument supports the preferred conclusion, then it is green. If it supports a dispreferred conclusion, then it is orange. The green arrow connecting this argument to the conclusion shows that the argument supports the conclusion.
+ [Evidence for supporting argument]: Evidence is presented as a white box with a colored outline. This piece of evidence supports an argument which supports the conclusion.
<_ <Undercutting argument>: This is an undercutting argument. To undercut a claim is to say, "Yes, that may be true, but it does not support your argument because..." In other words, undercutting arguments do not refute the claim being made; instead, they undermine the claim of its supporting value. #dispreferred
- <Refuting argument>: This argument is connected to the conclusion with a red arrow because it refutes the conclusion. In other words, this argument says, "The conclusion is not true, because..." This argument is orange because it does not align with the preferred conclusion. #dispreferred
+ [Evidence for refuting argument]: This is evidence for the refuting argument. It has a green arrow because it supports the refuting argument. It has an orange outline because it is being used to support a view that is not preferred. #dispreferred
Citations of secondary literature within an argument map are usually accompanied by symbols that indicate the type of source being cited.
===
model:
removeTagsFromText: true
shortcodes:
":C:": {unicode: "🄲"}
":G:": {unicode: "🄶"}
":A:": {unicode: "🄰"}
":I:": {unicode: "🄸"}
":L:": {unicode: "🄻"}
":D:": {unicode: "🄳"}
":M:": {unicode: "🄼"}
selection:
excludeDisconnected: false
dot:
graphVizSettings:
concentrate: true
ranksep: 0.2
nodesep: 0.2
===
[Conclusion]: This is the conclusion.
+ <Supporting argument>: This is a supporting argument that another scholar has made (NAME DATE, PAGE :C:).
Key to Symbols:
- A = article
- C = commentary
- D = dictionary
- G = grammatical resource
- L = lexical resource
- M = monograph
4.3. How to create an argument map
- Copy and paste the following tags into the wiki page: <argdown> </argdown> Typing within these tags will allow you to create an argument map using argdown.
- To learn how to type in argdown, you can study the guide on the argdown website, or you can go to an existing argument map (e.g., Ps. 11:5) and toggle back and forth between the "Source" and the "Map" to see how the syntax translates into a visual presentation.
- The following is a template of an argument map to copy and paste onto your wiki page. (To copy this template, you will need to "Edit" the page and copy the text).
===
model:
removeTagsFromText: true
shortcodes:
":C:": {unicode: "🄲"}
":G:": {unicode: "🄶"}
":A:": {unicode: "🄰"}
":I:": {unicode: "🄸"}
":L:": {unicode: "🄻"}
":D:": {unicode: "🄳"}
":M:": {unicode: "🄼"}
selection:
excludeDisconnected: false
dot:
graphVizSettings:
concentrate: true
ranksep: 0.2
nodesep: 0.2
===
[Main point title]: Main point.
+ <Supporting argument title>: Type supporting argument here (Author Date, Page :C:).
+ <Supporting statement title>: Type supporting statement here (Author Date, Page :G:).
+ [Supporting evidence title]: List supporting evidence here.
<_ <Undercutting statement title>:Type undercutting statement here (Author Date, Page :C:).#dispreferred
- <Refuting statement title>:Type refuting statement here (Author Date, Page :C:; Author Date, Page :A:).#dispreferred
If an argument map is very wide (i.e., has many propositions at the same level), it may be necessary to adjust the presentation so that the flow of the argument is horizontal instead of vertical. This can be done by adding "rankdir: LR" to "graphVizSettings." E.g.,
===
model:
removeTagsFromText: true
shortcodes:
":C:": {unicode: "🄲"}
":G:": {unicode: "🄶"}
":A:": {unicode: "🄰"}
":I:": {unicode: "🄸"}
":L:": {unicode: "🄻"}
":D:": {unicode: "🄳"}
":M:": {unicode: "🄼"}
selection:
excludeDisconnected: false
dot:
graphVizSettings:
rankdir: LR
concentrate: true
ranksep: 0.2
nodesep: 0.2
===
[Main point title]: Main point.
+ <Supporting argument title>: Type supporting argument here (Author Date, Page :C:).
+ [Supporting evidence title]: List supporting evidence here.
<_ <Undercutting statement title>:Type undercutting statement here (Author Date, Page :C:).#dispreferred
- <Refuting statement title>:Type refuting statement here (Author Date, Page :C:; Author Date, Page :A:).#dispreferred
+ <Supporting argument title 2>: Type supporting argument here (Author Date, Page :C:).
+ <Supporting argument title 3>: Type supporting argument here (Author Date, Page :G:).
- <Refuting argument title>: Type refuting argument here (Author Date, Page :G:).
4.4. Prose introductions to argument maps
Each argument map on the page should be introduced with a brief introduction. Each introduction should state/summarize the conclusion which is to be presented in the following argument map, cite any modern translations that reflect the conclusion, and quote at least one modern translation to illustrate.
If the "Argument Maps" section is broken down into sub-sections with multiple argument maps in each sub-section, then write a brief introduction for each sub-section as well. See for example: [1]
5. Build Arguments
The next step in the process is to fill out each of the argument maps. To do this, we turn to secondary literature. Our goal is not just to do our own research and build these argument maps on our own. Instead, we want to represent the best of what scholars have said on the issue throughout the history of interpretation. Oftentimes, this will require us to do some original research, but, for the most part, you should be able to build good argument maps by representing the arguments of other scholars.
In addition to consulting any articles or monographs that are unique to your psalm, peruse the commentaries in the Scriptura/CDBR Zotero Library. Look through sources until you have found arguments for (and/or against) each of the views. You might also find arguments for views that are not represented in the translations. Disregard these views, unless you find one of them viable and worth exploring.[5] Over time, you will develop a familiarity with these commentaries and a good sense of which commentaries to consult for which issues. Until then, check as many as you can.
As you consult each secondary source you will slowly fill out your argument maps. When you find an argument in a particular source, be sure to cite the source: (Author Date, Pagenumber :type-of-source:). You may quote the source directly or, better, paraphrase the argument in your own words.
See the Common Mistakes section below for more detailed help with this part of the process.
6. Weigh Arguments
Once you have represented each argument in its strongest form, now you can decide which view is most convincing. Consider both the weight of evidence cited for each view and the strength of the argumentation (the way in which that evidence is used to support a conclusion). Remember that evidence is to be weighed, not counted, and views are to be evaluated based on the quality (not quantity) of the arguments supporting it.
As you weigh arguments, you might find that you have more questions that have not been answered—questions that need to be answered before you can decide on the issue. It might be necessary, in this case, either to look through more sources or to do some research of your own.
If you made your decision before you started building the argument maps, then you have gone about the process in the wrong way. The whole purpose of building an argument map for each view is so that you can properly assess each view and come to a conclusion.
When you determine which view you prefer, then indicate it as "(preferred)" in the sub-heading and change the argument map colors accordingly.
7. Write Introduction and Conclusion
Once you have completed the "Argument Maps" section of the page, you can write your introduction and conclusion.
7.1. Introduction
Write a brief introduction to the issue at the top of the page, within the section titled "Introduction." The introduction should include the following elements:
- The Hebrew text of the line/verse in question, copied from OSHB.
- Two or three modern translations of the text whose differences illustrate the issue.
- A brief explanation of the exegetical issues which underly the differences in the translations.
See e.g.,
- The Division of Ps. 11:5
- The Text, Grammar, and Meaning of Ps. 110:3
- The Subject(s) in Ps. 110:5-7
- The meaning of ערבות in Psalm 68:5
- The Syntax and Subject(s) in Ps. 112:4
7.2. Conclusion
In the conclusion section, begin by stating your conclusion to the problem. Next, briefly summarise the content of the above argument map(s) in support of your conclusion. Next, briefly explain the significance of your preferred interpretation. Finally, rate your level of condfidence in the conclusion on a scale of A-to-D, A being the highest and D being the lowest. Include your rating in parentheses next to the "Conclusion" title. E.g., =Conclusion (B)=
8. Secondary Literature Bibliography
In the section titled "Secondary Literature," give bibliographic information for all of the sources that you cite in the page.
- Input information for each of your sources in the Scriptura/CDBR Zotero Library.
- Select all of the relevant sources in the library and click the "create bibliography" button (icon: books).
- From the menu select "Chicago Manual of Style 17th edition (author-date)."
- Copy the bibliography and paste it into the "Secondary" Literature" section of the wiki.
- Remove URL's, add italics where necessary, and place a colon (:) before each source.
Your bibliography should resemble the one on this page.
- Post a link to the wiki page on the forum. Title the post "Exegetical — Name of Issue", categorize it as an exegetical issue, and tag it with the number of your psalm.
- When you update your ClickUp task for the Exegetical Issue, include a link to the forum page in the comments section of the task for the sake of your reviewers.
Help
Good Examples
Because the Creator Guidelines have evolved over time, not all of the exegetical issues on the Exegetical Issues page are equally up-to-date. Even some of the exegetical issues cited above, although exemplary in the area in which they are cited, might be out of date in other respects. For a good and completely up-to-date example of the Top 3 Exegetical Issues for a single psalm, see Psalm 37.
Common Mistakes
Most of the mistakes for this layer occur within the "Build Argument Maps" step. The common mistakes below apply to this step.
- Not presenting evidence for an argument. Insofar as it is available, evidence should be cited for each argument. For many arguments, especially ones that are more-or-less agreed upon, you will not need to cite all available evidence. Sometimes, it might suffice to cite a single example to illustrate the argument.
- Making the evidence less accessible. When citing evidence, use English text where possible. Only use Hebrew (or other language text) where it is necessary. For example, when quoting a biblical passage as evidence for a lexical argument, you might quote the passage in English and insert the relevant Hebrew word in parentheses. Sometimes, it might be necessary to cite the entire passage in Hebrew. Use your best judgment, remembering that the goal is to make the evidence as accessible as possible without sacrificing quality or depth.
- Combining the argument and the evidence within a single node in the argument map. Arguments and evidence should generally be separated into separate nodes on the argument map, with the evidence node supporting the argument node.
- Confusing arguments and evidence. Argument nodes make claims based on evidence, and those claims can be either true or false. Evidence nodes present the raw material on which the claim is based (e.g., a citation from a biblical passage). Evidence itself is not true or false and cannot be supported or refuted (though it can be undercut). Arguments, by contrast, can be supported or refuted.
- Argument nodes with incomplete sentences. All argument nodes must contain at least one complete sentence—a complete proposition that can be either true or false. Some argument nodes might contain two to three sentences.
- "So-and-so says 'X'" arguments. When citing the argument of a secondary source, do not say "So-and-so says, 'X.'" Instead, just say "X" and cite "so-and-so" in parentheses. When an argument says, "So-and-so says 'X,'" the main proposition being asserted is that someone has said X (a claim that is undeniably true and also irrelevant to the argumentation). We are not interested in who said what; we are interested in the context of what they said.
- Supporting relations that do not actually support. A supporting relation (i.e., a green arrow) always says: "Because X is true (or, based on X evidence) this claim to which I am pointing is more likely to be true." Check all of your supporting arrows to make sure this logical relation defines each of them. Sometimes, people creating argument maps will have a two-part argument (A + B = C), but they will have B supporting A, as follows:
[Conclusion]: C is true.
+ <A>: A is true.
+ <B>: B is true.
This argument map is not correct. The fact that "B is true" does not make it more likely that "A is true." Rather, the fact "A and B are both true" makes it more likely that "C is true." One proper way to represent this logic is as follows:
[Conclusion]: C is true.
+ <A>: A is true.
+ <B>: B is true.
The following argument map would also be accurate:
[Conclusion]: C is true.
+ <A+B>: A is true, and B is true.
Rubric
Dimension | Description |
---|---|
Completeness | The page includes every element required by the creator guidelines.
|
Quality of argumentation |
|
Depth of content |
|
Engagement with secondary literature |
|
Clarity of language |
|
Formatting/Style |
|
Submitting your draft
Copy the text below into your forum submission post, entitled Exegetical Issues - Psalm ###. After posting, change your post into a wiki post so the reviewers can check the boxes. To change your forum post into a wiki post, click on the three-dot menu at the end of the text.
Click on the wrench.
Select "make wiki."
[Exegetical Issues Layer Rubric](https://psalms.scriptura.org/w/Exegetical_Issues#Rubric) |Guardian Review|Overseer Review|Final Checks|Description| | --- | --- | --- | --- | |||| **Completeness** |[ ]||| The page includes every element required by the creator guidelines. |||| *Introduction* |[ ]||| Hebrew text |[ ]||| Modern translations to illustrate |[ ]||| Breakdown of the issue; list of views |||| *Argument maps* |[ ]||| One argument map for each view |[ ]||| Brief prose introduction to each argument map |[ ]||| Indication of preferred view |||| *Conclusion* |[ ]||| Statement of preferred view |[ ]||| Summary of argument(s) for and against preferred view |[ ]||| Summary of significance |[ ]||| Confidence rating (A-D) |||| *Research* |[ ]||| Ancient translations |[ ]||| Modern translations |[ ]||| Secondary literature bibliography |||| **Quality of argumentation** |[ ]|[ ]|[ ]| Each colored box in the argument map clearly expresses a complete proposition or a series of complete propositions which, together, form an argument. |[ ]|[ ]|[ ]| The relationships among propositions are accurately expressed; green, red, and purple arrows are properly used. |[ ]|[ ]|[ ]| Arguments for preferred conclusions are cogent. |[ ]|[ ]|[ ]| The arguments supporting the conclusion are well supported by evidence. |[ ]|[ ]|[ ]| The arguments supporting the conclusion actually support the conclusion. |||| **Depth of content** |[ ]|[ ]|[ ]| Evidence is provided for each view in the argument maps (insofar as evidence exists for a particular view). |[ ]|[ ]|[ ]| No relevant evidence has been omitted from the discussion. |||| **Engagement with secondary literature** |[ ]|[ ]|| Secondary sources are cited throughout the page, especially in the argument maps. |[ ]|[ ]|[ ]| The arguments of other scholars with whom we disagree are put forward in the strongest possible terms. |[ ]|[ ]|| No secondary source which is especially relevant to the discussion has been omitted. |||| **Clarity of language** |[ ]|[ ]|[ ]| Prose (introduction, conclusion, introductions to views) is clear and concise. |[ ]|[ ]|[ ]| Text within the argument maps is clear and concise. |[ ]|[ ]|[ ]| Titles to nodes in the argument maps are clear and concise and accurately summarise the content of the node. |[ ]|[ ]|[ ]| Language is not too technical so as to be inaccessible to [Sarah](https://psalms.scriptura.org/w/Personas). |||| **Formatting/Style** |[ ]||| Correct spelling and punctuation is used throughout. |[ ]||| Page is properly titled. |[ ]||| Page is properly structured. |[ ]||| Page is assigned to the “Argument maps” category. |[ ]||| Page is assigned the correct chapter and verse number. |[ ]||| Argument map colors are used properly. |[ ]||| Argument map symbols are used properly and thoroughly. |[ ]||| Every node in each argument map has a title. |[ ]||| Sources are cited properly and thoroughly. |[ ]||| Tags are removed from the argument map. |[ ]||| The argument map is arranged (up-down vs left-right) in the manner that makes it easiest to read.
Footnotes
- ↑ For some issues, there may be significant disagreement among commentators and relatively widespread agreement among translations. Because our audience is more likely to notice an issue in a modern translation than in a commentary, differences among translations should be given greater weight than differences among commentators.
- ↑ There might be some cases where you should not include vowels, e.g., where the exegetical focuses on how the consonantal text should be vocalized.
- ↑ For the English translations, you will need to go somewhere other than Biblehub to view the footnotes.
- ↑ Because the number one criterion for identifying exegetical issues is disagreement among modern translations, the exegetical issue is often reflected in modern translations. There may be some issues, however, that are not clearly reflected in translation. For example, the question of The Subject(s) in Ps. 110:5-7 is often not directly reflected in modern versions. For issues like these, modern versions will necessarily play a less decisive role in shaping your approach to the issue. In some rare cases, you might not need to list out any modern translations at all. Only list out the modern versions insofar as they are relevant to the issue.
- ↑ You might also mention some of these alternative views in footnotes in the prose sections accompanying the argument maps.