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? extends: survey-first
  - 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? extends: survey-first

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 extends: fed-wiki
  - 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

start-w-schemas [] (question) What if we start with naming & schemas first
[] (question) do we start with a schema or refine as we go?
- [SJ] (claim) smw makes this hard for exactly this reason (deciding up front is friction). supports: start-w-schemas
- simple-mw [] (claim) easier with free form mediawiki templates and wiki text supports: start-w-schemas
  - [] (claim) templates allow tiny Lua templates, w/ any number of fields and presentation. supports: simple-mw
  - [SJ] (claim) this can be edited flexibly, so schema changes don't break things or make them illegible. supports: simple-mw

- [KK] (question) is there a problem extending from mw to smw later? extends: simple-mw
  - [] (claim) no, can start with a dozen schemas by hand, then decide if to move to a MW extension (smw or other) or wikidata supports: simple-mw
  - [] (claim) depends on what authoring + visualization tools we want, and the modelling tradeoffs we want supports: simple-mw

template-start [KK] (question) should we start with creating a "source" template: source: url, publisher, date, author ?
edge-complexity [KK] (question) will defining edges/relationships turn out to be more complicated than creating templates for nodes?
when-done [KK] (question) how do we know when we are done?

- internal-consistency [SJ] (claim) we need to create an internally consistent way of sharing templates supports: template-start
  - [KH] (claim) challenge: templates are universally available, which means that anyone can break our template supports: internal-consistency

[KM] (question) should we decompose Questions into further properties (like a Q has a subject and object) or leave it nat language?
- [KH] (claim) we should stick to natural language

wiki-granularity [KH] (question) if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page?
- wiki-all-pages [KM] (claim) it seems everything is a page. extends: wiki-granularity
  - wiki-sections [SJ] (claim) sections of a page are not a page. opposes: wiki-all-pages
- wiki-node-pages [SJ] (claim) everything we want to be a node should be a page. extends: wiki-granularity
- wiki-subgraph-pages [SJ] (claim) wiki transclusion also allows any subgraph to have a page, transcluding other nodes. extends: wiki-granularity
  - wiki-pages-busy [SJ] (claim) then each page needs a title - lots of work. and makes the history view busy, a UX question affecting exploration. opposes: wiki-node-pages
- wiki-pages-manageable [SJ] (claim) True, this is a Q of interfaces. Wiki recent changes scales well, we don't need to worry about that yet. we can use wikibase to scale ux issues and hide certain types of history (eg source edits). But we can do it this way for a demo. opposes: wiki-pages-busy

NB: this last is really 'oppose in part, support in part'. speaking to wanting a vocabulary of connection types

- - start-with-transclusion [KH] (claim) first attempt: everything is a page, we rely on transclusion to group things supports: wiki-pages-manageable
- [KH] (question) can we have the entire Q as a page title? extends: wiki-pages-busy

[KK] (claim) there are many to many relationships between sources & evidence
[] (claim) 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
starting-dgs [SJ] (claim) let's identify a discussion we want to capture, and figure out how to name it.