Discourse Modeling

Discourse Modeling
Description	Implement Discourse Graph schema in Semantic MediaWiki. Query Discourse Graph contents through SMW sparql endpoint. Visualize and publish Discourse Graph contents.
Related Topics	Discourse Graphs, SPARQL
Projects	Federated knowledge synthesis, Making Discourse Graphs Indexable & Discoverable
Discord Channel	#discourse-modeling
Facilitator	Karola Kirsanow
Members	Kyle MacLaury, Sam Klein, Konrad Hinsen, Karola Kirsanow, Peter Murray-Rust

What are we discussing?

It could be really valuable to try to prototype a "computable" synthesis of the knowledge in this workshop here in the wiki. One test of the "computability" would be to make it visualizable.

Could have applications to the semantic climate setting that Peter Murray-Rust is working on.

the results graph - Matt Akamatsu's DG dialect for experimental science

Discourse Graphs

Discourse Graph (from Joel Chan)

We're focusing on implementing the Discourse Graph Datamodel in a wiki to see if we can make further progress on enabling and supporting synthesis, discovery, and dissemination by building upon models that have already demonstrated success.

From our chat yesterday: I'd like to propose adding Axioms and adding relationships to Sources. Is there a way to do this on the oasis-lab spec?

The discourse graph quadruplet

Now you're playing with templates

• {{ Source}} template : URL, publisher, publisher-url, date, author, title

Sj, 2022-11-12. Discourse modeling templates. Synthesis Infrastructures wiki.

• Claim :
• Axiom (?) :

Discourse Graph templates

Potential Actions

• Implement the Discourse Graph schema within the workshop's Semantic MediaWiki instance
  • Making Discourse Graphs Indexable & Discoverable is a sub-project relevant to this group
• Incorporate models/algorithms into Semantic MediaWiki
• Access discourse and knowledge representations in the SMW instance
• Compute with the returned data
  • potentially using models/algorithms from the wiki
• Visualize the results of the computation
• Publish the visualizations back to the SMW instance
• Assess suitability of Discourse Graphs for federation (Federated Knowledge Synthesis)

Modules

Technical aspects of the project

• Semantic MediaWiki
  • Front End
    • Embed CloudObjects from Wolfram Cloud
    • User chooses model and specifies input parameters
    • User applies model to input parameters
      • Call API that executes
  • rdf database
    • SPARQL endpoint
• Wolfram Cloud
  • Use SPARQLExecute to call the SPARQL endpoint
  • Apply Model to query results
  • Publish visualizations as CloudObjects
  • Publish API that executes model/algorithm

Workshop Goals

1. Implement the Discourse Graph schema within the workshop's Semantic MediaWiki instance
   1. create templates for nodes
   2. understand how to type relationships
   3. prototype naming conventions
2. Create a few example Discourse Graphs, drawing on content and conversations generated during the workshop
3. Make the Discourse Graphs contained on the wiki visualizable and queryable through the Semantic Mediawiki SPARQL endpoint, as described above
4. Document our process and create a guide to making wiki-supported Discourse Graphs

Progress as of Day 1

• We aligned on a workplan that largely harmonizes with the goals formulated before the workshop and integrates as many objectives from Making Discourse Graphs Indexable & Discoverable and Federated knowledge synthesis as feasible.
  • We want to bootstrap a simple entrypoint into Discourse Graph construction, complete with example graphs, from a more familiar wiki environment.
  • We hope to design a system that is compatible with later efforts at DG federation.
  • We discussed the approaches to naming and conflict resolution employed by an agora and everything2.
• We decided to focus first on the problems of naming and schemas; beginning with designing templates for nodes and a wiki-friendly implementation of relations.
  • We discussed the relative advantages and constraints of MW v SMW.
  • We aligned on the criticality of naming to enable effective querying
  • We decided that we should also develop names for frequent queries.
• We sketched a system for capturing and transforming conversations on this wiki into graphs, putting the "discourse" back into "Discourse Graphs"
  • We made a first pass at designing templates for sources, evidence, claims, and questions
  • We discussed for the page relations enabled by SMW could be used to create DG edges.
• We annotated this page's Discussion using simple DG syntax to experiment with transforming a "live" conversation into a DG

Progress as of Day 2

• We continued to build out the Discourse wiki on the talk page, including developing conventions for tagging parts of syntax and relations
• We discovered that what we are working towards is a set of (mostly syntactical) conventions for creating Discourse Graphs -- almost like a Markdown for Discourse Graphs
• We extended the SPARQL query system
• We discussed discourse graph discovery algorithms
• We discussed visualization options
• We realized that the ability to notice and capture disparate mentions of identical or similar topics would be a very desirable feature supporting collaboration

Observations & Open Problems

• We immediately realized that we had seen very few Discourse Graphs "in the wild": the model makes intuitive sense in single player and small-group mode in Roam & Obsidian, but how gracefully will it scale to massively multiplayer synthesis?
  • There are at least two possible models here: public-first writing in online mode (wiki, Roam) and local-first writing +push, probably via git. UX and conflict resolution will differ in these models.
• How to design with a federated future in mind?
  • What does it mean for distinct graphs to share nodes? to "live" in adjacent namespaces?
• The challenge of using a wiki like git: simultaneous editing seems more cumbersome
• If creating templates is a large part of the work, more powerful text editing & transformation capabilities (e.g. sed, pandoc) seem in order
• Need to create a consistent way of sharing and editing templates - how do template changes propagate in a future federated system?
• Will graph visualization scale in a useful manner? How will traversal work?
• The relationship between naming and clustering: how do we name groups of related hypotheses? A family of experiments?
• Questions regarding feasible & appropriate levels of automation
  

Relevant Projects and Ideas

• Agora
• everything2
• Cosma
• Obsidian
• Roam
• Logseq
• Zettlr
• Tana
• Kumu
• The Discourse Graph Starter pack
• Lepiter
• Massive Wiki

Example Discourse

Why do we expect increased concentrations of atmospheric carbon dioxide to change the climate?

Example Discourse Graphs

• Joel Chan's working notes
• CIViC (Clinical Interpretation of Variance in Cancer]

Tools

Download SMW rdf data

Import SMW .jsonld as RDFStore in Wolfram Language

Example SPARQL queries in Wolfram Language

Execute SPARQL query against RDFStore

Computation, Queries and Answers

What is the act of synthesis, and what does it have to do with discourse graphs?

Synthesis is the process by which one or more computational processes process the same set of information to generate a coherent understanding of (model of) the world. The set of information in this case is the discourse graph, which contains the information processed and shared in the act of attempting to answer a question, and information regarding the provenance of the information.

‘This is an epistemic process made perhaps most explicit by the scientific process, but it is generalizable in the sense that it can be used to describe two farmers sharing observations about the weather, or two parallel processes within a question answering system sharing results to synthesize a single answer.

I suppose that this shouldn’t be surprising since since the discourse graph starts with a question, but the process that the discourse graph supports has much in common with query execution following an API call, but perhaps query execution that attempts to answer a question whose answer requires synthesis. Perhaps a synthesis query? A query which returns multiple items of information (claims) that a computational process can synthesize to answer a question.

Discord

joelchan86#discourse graphs22-11-10 15:55:39

we think the problem now is user-friendly tools and workfows that can create discourse graph structures, and have seen some exciting progress across a bunch of new user-facing "personal wikis". but bridging from personal to communal is still a challenge, partially bc of tooling.

this is why i'm excited about the Discourse Modeling idea, which i sort of understand as a way to try to instantiate something like Discourse Graphs into a wiki (bc wikis have a lot more in-built affordances for collaboration, such as edit histories, talk pages, etc.), which may hopefully lead to a lower barrier to entry for collaborative discourse graphing.

a high hope is that we can develop a process that is easy enough to understand and implement that can then be applied to discourse graphing the IPCC or similarly large body of research on a focused, contentious, interdisciplinary topic.

other examples include: - effects of masks on community transmission (can't do decisive RCTs, need to synthesize) - effects of social media on political (dys)function: (existing crowdsourced lit review here, in traditional narrative form: https://docs.google.com/document/d/1vVAtMCQnz8WVxtSNQev_e1cGmY9rnY96ecYuAj6C548/edit#)