Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Justifications on Relations #302

Open
AdamSobieski opened this issue Dec 30, 2021 · 8 comments
Open

Justifications on Relations #302

AdamSobieski opened this issue Dec 30, 2021 · 8 comments

Comments

@AdamSobieski
Copy link

AdamSobieski commented Dec 30, 2021

I would like to ask about justifications of relations between parts of arguments (see also: the Toulmin model of argument).

One can envision, for diagrammatic arrows connecting nodes, that, from the midpoints of these arrows, perpendicular lines could emerge and connect to other argument nodes. Perhaps these nodes, representing the arguments for the arrows, could be initially collapsed and expandable. Also possible is that collapsed nodes, e.g., represented by circles, could be placed atop the midpoints of the arrows, and these could be clicked upon for expanded views.

Brainstorming, perhaps in argdown syntax one could put references in the middle of arrows, or relations, to express this.

+(ref)+>
-(ref)->
_(ref)_>

<+(ref)+
<-(ref)-
<_(ref)_

Perhaps these could also be sets or lists:

+(ref1; ref2; ref3)+>
-(ref1; ref2; ref3)->
_(ref1; ref2; ref3)_>

<+(ref1; ref2; ref3)+
<-(ref1; ref2; ref3)-
<_(ref1; ref2; ref3)_

Other syntactic possibilities include, but are not limited to, square brackets:

+[ref]+>
-[ref]->
_[ref]_>

<+[ref]+
<-[ref]-
<_[ref]_

+[ref1; ref2; ref3]+>
-[ref1; ref2; ref3]->
_[ref1; ref2; ref3]_>

<+[ref1; ref2; ref3]+
<-[ref1; ref2; ref3]-
<_[ref1; ref2; ref3]_

curly brackets:

+{ref}+>
-{ref}->
_{ref}_>

<+{ref}+
<-{ref}-
<_{ref}_

+{ref1; ref2; ref3}+>
-{ref1; ref2; ref3}->
_{ref1; ref2; ref3}_>

<+{ref1; ref2; ref3}+
<-{ref1; ref2; ref3}-
<_{ref1; ref2; ref3}_

and angled brackets:

+<ref>+>
-<ref>->
_<ref>_>

<+<ref>+
<-<ref>-
<_<ref>_

+<ref1; ref2; ref3>+>
-<ref1; ref2; ref3>->
_<ref1; ref2; ref3>_>

<+<ref1; ref2; ref3>+
<-<ref1; ref2; ref3>-
<_<ref1; ref2; ref3>_

Currently, arguments for steps of reasoning can be expressed:

(1) All humans are mortal.
(2) Socrates is a human.
--
Universal instantiation, Modus Ponens
{uses: [1,2], logic: ["deductive", "predicate logic"]}
--
(3) Socrates is mortal.

Perhaps, the inlined rule instantiations could be viewed as a justification of an arrow between steps 1 and 2 and step 3?

What do you think about relation arrows being capable of bearing justifications or arguments?

@maxsu
Copy link

maxsu commented Mar 20, 2022

@AdamSobieski I don't have a direct answer to your questions, since I'm new to argdown, but I wonder if these kinds of justifications could help me better understand fallacious, dishonest, motivated, or just uncertain reasoning (which we might lump together as "bullshit"). For instance, BS might fit into the Toulmin model as faulty warrants, backing, or rebuttals, or unjustified qualifiers. Are you aware of any graphical approaches that let us annotate argumentation graphs with these kinds of BS labels?

As for your specific use case, I am not yet sure of the parser layout of argdown, nor what it takes to make argdown extensions, but I will investigate. In the mean time, I am very curious about how you would like the resulting grapphs to look. Can you draw some examples, either in pen and paper, or a free-form diagramming software like draw.io? I'd love to see what you have in mind!

@AdamSobieski
Copy link
Author

@maxsu, thank you. I'm also new to argdown. The gist of the idea is that the arrows or connectors, e.g., those which carry us from antecedents to consequents, can often be justified.

As for graphical approaches, one could draw a small solid circle at the midpoint of any arrow and draw a line from it, effectively "reifying" the arrow or connector. I find interesting the idea of recursion in these regards: arrows from arrows can be viewed as being arrows... justifiable connectors connected to justifications via justifiable connectors.

In my opinion, visual, or diagrammatic, means of exploring these spaces would be useful for students (as hyperlinks are useful on Wikipedia, we can envision means of navigating a "Wikiarguments") and, if you find these topics to be interesting, you might also find interesting the work of Armin Fiedler:

  1. Fiedler, Armin. "User-adaptive proof explanation." (2001).
  2. Fiedler, Armin. "Dialog-driven adaptation of explanations of proofs." In International Joint Conference on Artificial Intelligence, vol. 17, no. 1, pp. 1295-1300. 2001.
  3. Fiedler, Armin. "P. rex: An interactive proof explainer." In International Joint Conference on Automated Reasoning, pp. 416-420. Springer, Berlin, 2001.

That is, only some parts of justifications (e.g., mathematical proofs) or explanations are instantaneously contextually relevant to a user.

@maxsu
Copy link

maxsu commented Mar 24, 2022

@AdamSobieski Would you be open to draw up (either on paper or digitally) some examples of the visual layout that you'd like to achieve? I think you have a better handle on what they should look like than I do, and hope you might sketch a substantial use case . For comparison and a laugh, please see my current example (drawn in excalidraw):

@AdamSobieski
Copy link
Author

@maxsu, thanks for the fun sketch.

To your question, I'm thinking about expandable trees in graphical user interfaces. In these user interface elements, boxes can have plusses in them, [+], to represent compressed tree nodes which can be expanded, and minuses in them, [-], to represent expanded tree nodes which can be de-expanded or compressed.

So, for arrow diagrams, I'm visualizing arrows with small circles at the midpoints of the arrows which could contain plus signs in them, , indicating that a user can click on the symbols for content about that arrow to expand into view. Perhaps those symbols could change into symbols when expanded, and users could click on those symbols to de-expand or compress the expanded content about that arrow.

So, not every arrow would have "meta" information about it available, but those which do could have a symbol at the midpoint, if not expanded, and a symbol at the midpoint, if expanded.

The lines of the arrows could pass through the circles like this:

——⊕——>

and this:

——⊖——>

regardless of how they are rotated on the diagram. That is, the minus or dash in the circle could be parallel to the arrow line, possibly being the arrow line itself, and the plus sign can be said to contain an additional line segment perpendicular to the arrow.

In theory, that could be more readable than an arrow pointing to the middle of another arrow and it comes with toggleability.

The size of the circles at some arrows' midpoints would be a UI/UX consideration, and needn't scale with arrow length. These toggleable circle-based symbols would be sized to be clicked, for mouse scenarios, and touched, for multi-touch scenarios.

What do you think?

@AdamSobieski
Copy link
Author

AdamSobieski commented Mar 25, 2022

Also, brainstorming, we could make use of other symbols, in a similar manner, upon arrows, to indicate that users could click on or touch to toggle open menus of "meta" options, e.g., menu options pertaining to "meta" information about those arrows, connectors, or relations. Via these menus, users could navigate to ‒ or otherwise explore ‒ justifications, explanations, provenance, and more, and make use of other modes of interaction pertaining to specific arrows.

If an arrow has a "meta" menu, we could also make use of the circle with a dot in it symbol:

——⊙——>

or, perhaps, utilize the information symbol:

——ⓘ——>

either of which could visually toggle to an empty circle while its menu is presented on-screen. Displayed menus could be visually connected to arrows' midpoints via connecting line segments.

——◯——>

See also: https://commons.wikimedia.org/wiki/Unicode_circle_shaped_symbols .

@maxsu
Copy link

maxsu commented Mar 28, 2022 via email

@AdamSobieski
Copy link
Author

AdamSobieski commented Apr 1, 2022

@maxsu, either first-order or nth-order recursion with respect to explanations, justifications, and provenance on arrows could be useful for end-users.

In addition to the UI/UX concepts indicated, placing visual decorators on certain arrows with which to toggle inline graph-based content, users could select arrows (in various ways) to view information and menus about them in side panels, in application menus, or in application ribbons. There would be, in all of these cases, a need for aesthetic means of distinguishing between those arrows without and those arrows with additional explanatory, justificatory, and provenance-related content.

Considering cognitive ergonomics, it could be that the approaches with visual decorators on arrows would be cumbersome, in particular for complex layouts, requiring extra visual scanning of arrows of interest, and that other means of more rapidly, visually distinguishing between those arrows without and those arrows with additional content would be better, more ergonomic and convenient, e.g., using different arrow colors or line widths.

Considering the history of hypertext and the Web, perhaps those arrows which do not link to more information could be text-colored, e.g., black, and those arrows which do link to more information could be visually highlighted, e.g., blue. Perhaps these visualization- and style-related matters for hyperlink arrows could be configurable by end-users.

I also like the idea of presenting independent sub-arguments as separate graphs, or “argument zooming”. It sounds like this approach could work with multi-document-view applications, e.g., applications with tabs. Tabs would be but one means of providing simple, clear, and efficient means of navigating between arguments and their sub-arguments.

@maxsu
Copy link

maxsu commented Apr 20, 2022

Hi Adam, I'm going to pull back from this issue until we have some well specced visual design docs - scope-limited visual representations of the changes we'd like to write. This lets us stabilize a concrete goal to move towards.

If you want support in using diagramming software like excalidraw or lucidchart I'd be happy to help with a screen-sharied training session. Consider it!

Till then, thanks for the thought provoking ideas!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants