Talk:Discourse Modeling

Participants in the discussion

Section 1 KK

Squad goals:

Building Queries

1 [KM] (question) can we build the queries needed to interact with the Discourse Graph data model?
- 2 [] (claim) this entails making DGs part of the wiki and shareable supports: 1
- 3 [] (claim) relevant tools include wolfram/mathematica & wiki functions supports: 1
  - 4 [KM] (claim) it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions supports: 3
- 5 [SJ] (claim) it is also desirable to create a namespace of functions that any contributor to functions can edit supports: 1
  - 6 [SJ] (claim) one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions supports: 5
  - 7 [SJ] (claim) in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph supports: 5
  - 8 [KH] (evidence) wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like supports: 5

Federated Knowledge Synthesis

systems [KH] (question) can we develop systems and process for federated knowledge synthesis?
- survey-first [?] (claim) the first steps involved would be getting people together & doing a survey of prior work (eg anagora) supports: systems
  - how-to-extend [?] (question) how can we build on this and extend it?
  - long-term coord [?] (claim) this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years supports: survey-first
  - fed-as-in-wiki [?] (question) federation as in federated wiki?

Conflict Resolution

page-forking [?] (question) problem with wiki is that there is only one version of each page - what if you disagree?
- fed-wiki [?] (question) in wiki each page has a single version ==> federated wiki is the solution supports: page-forking
- fed-wiki-git [?] (claim) pages in a federated wiki are more like working in branches as in git
  - fed-wiki-merging [?] (claim) branches and merges are important ideas in the federated wiki concept space supports: fed-wiki-git
author-dgs [KH] (claim) we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader ==> author transition
- author-label-loss [KH] (question) will the "author" label on scientific papers disappear as collaborations grow? supports: author-dgs
better-graph-viz [?] (question) can we enable effective and usable graph visualizations?
do-properties-scale [SJ] (question) do DG graph properties scale to communally edited collaborative graphs?

Version control v Narratives

meet-in-middle [?] (question) how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
- [KK] (evidence) everything2 supports: meet-in-middle
- [KK] (evidence) agora supports: meet-in-middle
what-dg-types [SJ] (question) what types of graph are we talking about?
- lacking-meta-dgs [SJ] (claim) I haven't seen dgs about discourse: chains of reasoning, mapping out arguments - these can be linear if there is a dialog supports: what-dg-types
  - composite-dg [SJ] (question) what does composite graph of discourse addressing the same issues look like? extends: lacking-meta-dgs
- [SJ] (claim) personal or group notetaking: connections are not discourse connections - they include refrences, clarifiers, and links of definitions supports: what-dg-types

Section 2 Konrad

A Discourse Graph for our own Wiki

KM: question can we take contributions to this wiki as data to generate a discourse graph?
- claim this means creating a schema, show others how to create the different node types
- claim this means take db backend, ingest it, execute queries against it
- claim viz may not be super-sophisticated, but a view or 2 framed on each node type would be worthwhile: eg how does a question relate to claims, how are claims informed by different articles (evidence)
claim need to populate the wiki with the elements of a discourse graph --> create viz --> share code
SJ: question can we accomplish naming: coming up with names for each of those components, and names for things at different scales - discussion, family of hypotheses, family of experiments
- claim this will allow us to say that if you have identified x ideas, hypotheses, etc - how many discourses do you need to describe? how many graphs are needed to illustrate those discourses - when are people working on the same graph?
- question what does it mean to have different graphs that share some pieces, or different graphs in or close to the same namespace
- claim these issues --> boil down to the naming of the pieces and how you place the connections - how much context do you need to figure out how many connections there are?
KM: taking this as an opportunity to learn SPARQL (--> claim this is a good opportunity to learn SPARQL)
KM: claim we need namespaces before we can query anything - naming is critical!
SJ: claim we should name and make list of queries - queries need their own names

Agora

KM: question what is agora?
SJ: claim agora is a group of people interested in wiki linking and editable networks & knowledge federation
- claim agora's goals include:
  - make linking always do something sensible - best effort connection between links
  - agora is a url pattern that will try to resolve it
  - redirect strings to appropriate resources
  - each reader gets a filter - only see certain nodes & connection based on sort preferences
- KM: claim sounds like auto-complete for knowledge graphs
- claim each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
- proposal elevate DGs by making a section that tries to generate a DG or discourses that mention this node
claim DG is a shape you compile on the fly - could try to generate a DG x steps away and show you different families that might be referencing this
- claim spirit of the agora is automatic discovery & openness to engagement
- KH: question impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
  - SJ: claim diff between creating a new link with the same name as your node and creating a link to your specific node
KK: question diff between agora and what we envision?
- SJ: claim no typology of links
- claim graph visualization does not ignore non-typed connections
KH: question existing descriptions of agora other than the site itself?

Getting started on our own Discourse Graph

KK: question what actions will we need to take to get where we want to go?
- question how do we turn parts of this wiki into the components of a DG?
- KM: proposal we have folks write and annotate in the wiki and use the annotation capabilities of SMW to call out what the node types are
- claim getting the data into the wiki is literally people interacting and annotating
- claim but first we need to figure out naming and schema
- template objects, other objects, tools that can be used to define the schema
- KH: proposal prefer many short examples
- SJ: proposal like the idea of a self-referential discourse about the state of DGs

What exactly makes a graph a Discourse Graph?

question: can a discourse be about a topic? are discourses about a certain over-arching hypothesis where you make claims and discover evidence?
- KH: question what do you do when your discourse does not fit a DG?
  - examples from physics with no well-posed question
- discussion of results graphs and requests for experiments
- proposal need to figure out how DGs work in these different fields and circumstances
- SJ: meta:proposal need to identify existing discourse maps, and existing graphs, that could be thought of as DGs (proofs, discourse diagrams, text summarization graphs, argument maps, decision maps + flowcharts, ...)
SJ: proposal need to capture axioms / assumptions
KH: proposal making tacit knowledge explicit!!

Section 3 Kyle

- decision: start with naming & schemas first
- do we start with a schema or refine as we go?
- sj: smw makes this hard for exactly this reason
- easier with free form wiki templates and wiki text
- tiny Lua templates (don't need to write Lua)
- define any number of fields
- define how they are presented
- this is just mediawiki w/o the semantic extension
- make a mediawiki entry for every thing that has a shape
- edit that v flexibly, schema changes won't break things, won't cascade illegibility
- at scale: smw wiki extension enables multiple dynamic table updates as data changes
- KK: question: problem extending to smw later?
- no
- not as long as template is compatible with smw
- we can do this by hand - dozen schemas
- we can then decide whether we want to do smw or use wikidata & their respective modelling tradeoffs
- start with creating a "source" template: source: url, publisher, date, author ?
- kk: question will defining edges/relationships turn out to be more complicated than creating templates for nodes?
- KK: how do we know when we are done?
- SJ: need to create an internally consistent way of sharing templates
- kH: templates are universally available, which means that anyone can break our template
- KM: should we decompose the Q into further properties (like a Q has a subject and object) or leave it nat language
- KH: we should stick to nat language
- KH: if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page?
- KM: seems like everything is a page?
- sj: sections of a page are not a page
- sj: everything we want to be a node should be a page
- sj: wiki supports transclusion
- kh: then each pp needs a title - lots of work
- sj: this is a q iof interfaces - we can do it this way for a demo
- KH: makes the history list a bit busy - this is a ux question affecting exploration
- KK: many to many relationships between sources & evidence
- source property could be a url and we could create an entity for the source that scrapes data and populates fields
- if you expect something will be used more than once you probably want it to have the full data
- sj: claim: this level of precision is important to dgs
- sj: claim wiki recent changes scale well
- sj: we can use wikibase to scale ux issues and hide certain types of history (eg source edits)
- KH: first attempt: everything is a page, we rely on transclusion to group things
- KH: can we have the entire Q as a page title?
- sj: this gets to my interest, naming
- sj: a great next step would be intifying a discussion wewant to capture