Method:Exegetical Issues

• Grammar
• Semantics
  • Lexical Semantics
  • Phrase-Level Semantics
  • Verbal Semantics
  • Story Behind the Psalm
• Exegetical Issues
• Discourse
  • Participant Analysis
  • Macrosyntax
  • Speech Act Analysis
  • Emotional Analysis
• Poetics
  • Poetic Structure
  • Poetic Features
• Synthesis
  • Verse-by-Verse Notes
  • Translation and Performance Notes
• Close-but-Clear
• Videos
  • Overview
  • Top 3 Exegetical Issues
  • Top 3 Poetic Features
• Post to wiki
• Style Guide

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.
• 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.

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:

1. 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.
2. 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 summaries of each issue.

Here are two examples of exegetical issues summarised on the wiki:

• The Division of Ps. 11:5
• The Text, Grammar, and Meaning of Ps. 11:1b

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 capitalisation (also called headline case) when naming the page (e.g., "The Division of Ps. 11:5" and not "The division of Ps. 11:5).
• If it is necessary to use Hebrew text, use English transliteration.

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. Categorise 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.

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 highly probable).

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 categorise 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 coloured 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 coloured 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 coloured 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 which 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/summarise the conclusion which is to be presented in the following argument map and cite any modern translations that reflect the conclusion.

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 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. Occasionally, 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 highly probable. 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.

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 colours 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:

1. The Hebrew text of the line/verse in question, copied from OSHB.
2. Two or three modern translations of the text whose differences illustrate the issue.
3. 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. Finally, briefly explain the significance of your preferred interpretation.

8. Secondary Literature Bibliography

In the section titled "Secondary Literature," give bibliographic information for all of the sources that you cite in the page.

1. Input information for each of your sources in the Scriptura/CDBR Zotero Library.
2. Select all of the relevant sources in the library and click the "create bibliography" button (icon: books).
3. From the menu select "Chicago Manual of Style 17th edition (author-date)."
4. Copy the bibliography and paste it into the "Secondary" Literature" section of the wiki.
5. Remove URL's, add italics where necessary, and place a colon (:) before each source.

Your bibliography should resemble the one on this page.

9. Share your draft for Review

• Post a link to the wiki page to the forum. Title the post "Exegetical — Name of Issue", categorise 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.

Rubric

Dimension	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 Research Ancient translations Modern translations Secondary literature bibliography
Quality of argumentation	Each coloured 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. I.e., 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.
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 colours 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.

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
|||| *Research*
|[ ]||| Ancient translations
|[ ]||| Modern translations
|[ ]||| Secondary literature bibliography
|||| **Quality of argumentation**
|[ ]|[ ]|[ ]| Each coloured 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 colours 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.