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

• 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

• 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 (--> 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