Talk:Discourse Modeling

Participants in the discussion

• SJ: Samuel Klein
• KM: Kyle MacLaury
• KK: Karola Kirsanow
• KH: Konrad Hinsen

Section 1 KK

Squad goals:

Building Queries

• KM: question can we build the queries needed to interact with the Discourse Graph data model?
  • claim this entails making DGs part of the wiki and shareable
  • claim relevant tools include wolfram/mathematica & wiki functions
    • 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
  • SJ: claim it is also desirable to create a namespace of functions that any contributor to functions can edit
    • 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
    • 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
    • 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

Federated Knowledge Synthesis

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

Conflict Resolution

• question problem with wiki is that there is only one version of each page - what if you disagree?
  • claim in wiki each page has a single version --> federated wiki is the solution
  • claim pages in a federated wiki are more like working in branches as in git
    • claim *branches* and *merges* are important ideas in the federated wiki concept space
• 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
  • KH: question will the "author" label on scientific papers disappear as collaborations grow?
• question can we enable effective and usable graph visualizations?
• question do DG graph properties scale to communally edited collaborative graphs?

Version control v Narratives

• 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
  • KK:evidence agora
• SJ: question what types of graph are we talking about?
  • SJ:claim I haven't seen dgs about discourse: chains of reasoning, mapping out arguments - these can be linear if there is a dialog
  • SJ: question what does composite graph of discourse addressing the same issues look like?
  • SJ: claim personal or group notetaking: connections are not discourse connections - they include refrences, clarifiers, and links of definitions

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
• 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
  • 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
  • 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: no typology of links
  • graph visualization does not ignore non-typed connections
  • KH: existing descriptions of agora other than the site itself?

Getting started on our own Discourse Graph

• • KK:what actions will we need to take to get where we want to go?
  • how do we turn parts of this wiki into the components of a DG?
  • KM: we have folks write and annotate in the wiki and use the annotation capabilities of SMW to call out what the node types are
  • getting the data into the wiki is literally people interacting and annotating
  • but first we need to figure out naming and schema
  • template objects, other objects, tools that can be used to define the schema
  • KH: prefer many short examples
  • SJ: 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: 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
  • need to figure out how DGs work in these different fields and circumstances
  • SJ: meta: 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: need to capture axioms / assumptions
  • KH: 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