Talk:Discourse Modeling

Section 1 KK

Squad goals:

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

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

• 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

- KM: take contributions to this wiki as data to generate a discourse graph? - create schema, show others how to create the different node types - take db backend, ingest it, execute queries against it - viz may not be super-sophisticated, but a view or 2 framed on each node type would be worthwhile: eg how does a question related to claims, how are claims informed by different articles (evidence) - need to populate the wiki with the elements of a discourse graph --> create viz --> share code - SJ: would like to accomplish naming: coming up with names for each of those components, and names for things at differnt scales - discussion, family of hyptheses, family of experiments - 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? - what does it mean to have different graphs that share some pieces, or different graphs in or close to the same namespace - --> boil down to the naming of the pieces and how you place the connections - ho much context do you need to figure out how many connections there are? - KM: taking this as an opportunity to learn SPARQL - we need namespaces before we can qury anything - naming is critical! - KH: also relatively - Sj: we should name and make list of queries - queries nee their own names - KM: agora? - SJ: group of people interested in wiki linking and editable networks & knowledge federation - goals: - 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: 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 agaora ad-hov - elevate dgsd by making a section that tries to generate a dg or discourses that mention this node - dg is a shape you compile on the fly - could try to generate a dg x stteps away and show you different families that might be referencingthis - spirit of the agora is automatic discovery & openness to engagement - KH: impression is that it is a collection - how would I learn that someone rlsewants to do something to my node - diff between creating a new link with the same name as your node and creating a link to your specic node - KK: diff between agora and what we enision? - sj: no typology of links - graph visualization does not ignore non-typed connections - KH: existing descriptions of agora other than the site itself? - 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 capabiliies 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-referntial discourse about the state of discourse graphs - question: can a discourse be a bout a topic? are discourses about a certtain 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 differnt fields and circumstances - sj: meta: need to identify existing discourse maps, and existing graphs, that could be thought of as d.g.s - (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