Talk:Discourse Modeling

Participants in the discussion

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

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.

Day 2

• structure [KM] (claim) defined categories for each of our data objects but not for axioms
• structure [KM] (claim) defined a schema and tried to define a form that will use a schema
• structure [KM] (claim) built a schema upon JC's DG diagram (note that this claim adds context to the claim above)
• structure [KM] (claim) forms not working well to create instances - this probably means that they are not well-specified
• {{ structure [KK] (question) should we use forms versus templates?
• structure [KM] (claim) created an example of each object and tried to link them on the object, but we're not at querying yet
• structure [KM] (claim) records in the db that are targetable
• structure [KM] (claim) there are improvements to be made on the wiki side
• structure [SJ] (question) SJ: which page were you working on for that?
• structure [KM] (claim) filling in materials under the group & trying to (screen share)
• (KM: do not assume intentionality)
• structure [KM] (claim) for a source - we'd add the source category to each participant page
• structure [KM] (claim) properties like "informs" remain to be defined
• structure [KH] (claim) KH: we'll have to make every claim a page - would be nice to have a smaller item than a page
• structure [KH] (claim) separate pages work ok for sources
• structure [SJ] (claim) inline is better - we can do this if we don't rely on semantic wiki to query
• structure [SJ] (claim) SJ: one thread could be updating the inline format & syntax - we'd want to do this for an interface anyway
  • structure [SJ] (claim) SJ: talk page is a linearization - compact way of viewing, but there are others
• SMW [SJ] (question) SJ: how good are the default SMW views?
• structure [SJ] (claim) SJ we haven't really tied any claims to evidence
• structure [KH] (claim) KH: at some point we want each of these things an entity we can refer to
• refer to things by their anchors - this is a wiki way of doing this
• structure [SJ] (claim) SJ: could have a template that includes an ID
  • identity [KH] (question) KH: is it up to authors to ensure IDs are unique?
    • identity [SJ] (claim) SJ: or plugin drawing from a db
  • structure [DA] (claim) DA: everything that is anchored is a child to whatever the parent page is - just need one organizing page - all the claims could be a child of the source
  • structure [KK] (question) do we want to make claims subordinate the source?
• structure [KK] (question) KK: how much about the structure of our discourse should we understand beforehand?
• structure [DA] (claim) DA: this is an argument for everything being its own page
• structure [KH] (claim) KH: then we're back to every title being an ID
  • structure [SJ] (claim) SJ: solving an infrastructure and a stat structure q at the same time --
  • visualize a bunch of nodes together on the same page - how we split up our convo yesterday
  • if we write a tool to autocomplete claims or sources - re-use - appearance on the page would not subordinate it to the page
  • here's a collection of nodes and links relevant to the subject of the page -- each could appear i nmultiple places
• structure [SJ] (claim) SJ: individual pages work
• structure [SJ] (claim) SJ: probably does make sense to asssign a little claim ID to things even if we're not displaying it in order to keep track of how this will map
• SJ: I'll add an additional Id field to make it clear how it will map to a wikibase
• SMW [KH] (claim) KH: I have the impression that what we are doing is not what SMW is built for
  • SMW [KHG] (claim) KH: my impression is that Mediawiki is for big things but not a tool meant to be used by 5 people playing with big ideas
• goal [KH] (question) KH: can we move onto our final goal in a reasonable amount of time?
• UX [DA] (claim) DA: using existing synthesis infrastructure makes sense but I'm curious about editing frictions
  • structure [DA] (question) DA: if we did this where every claim was its own page and they linked to each other - would we be able to parse meaningful relationships?
  • UX [DA] (claim) how would I know that this evidence supports or opposes this claim? (note that this is related to the Q above)
  • structure [DA] (question) do we need extra metadata fields? ( note that this is related to the preceding question)
  • structure [KM] (question) KM: can't we add properties to the claims & evidence that point to specific instances?
  • page for a claim with bullet points and headers
  • link to evidence
  • when we go to evidence we see things that link - do we see what that evidence supports or opposes or do we know that they are connected?
• structure [SJ] (question) SJ: what links would need to be enriched with this data?
• theory [KK] (evidence) KK(DG diagram)
• structure [DA] (question) DA: if I'm on a page and we list claims & evidence on the page for this meeting - it's unclear how much o this info is visible when we go to a specific claims or questions page
• everything is linked from the mtg page - have to be thoughtful about linking
• KK: (water & music discord)
• UX [DA] (question) DA: how do you get from anywhere to a Discourse Graph?
  • querying [DA] (question) KM: that is effectively what we're trying to accomplish with SPARQL query:
    • if we back up SMW database with RDF database - you can hit a SPARQL endpoint export as json and import via wolfram to execute queries - there is a relatively easy mechanism to access this data as RDf data, and you can execute sparql queries against it
• UX [KH] (question) KH: from the user's point of view, what are typical interactions?
  • UX [KH] (question) enter text, annotate text with dg tags, person who wants to run queries, aggregator who wants to synthesize DGs --
  • what are the ideal tools for each oth these users
  • UX [KH] (claim) if the wiki is not a useful user interface for any of these users - for ex, annotator, searcher, queryable -- we shouldn't use it
  • structure-UX [KH] (claim) if the wiki is inly a db, then it is not useful
  • structure-UX [KH] (claim) a wiki with no UI is not useful
  • UX [DA] (claim) DA: use case: collaboration
    • we write notes
    • he reads and has ideas
    • creates a new page with his note referencing our notes
    • being able to refer to things easily (does everything have its own page - seems to make sense)
  • key thing is when I mention something and I refer to something you mentioned - it would be cool if when you see your page, you can see "Deniz mentioned this claim" wherever it is mentioned
    • cite or hover tool showing the mention - "this link mentioned by this project etc"
    • this is the key interaction - the big win of a collaborative tool
    • people randomly talk about things - but when they mention the same thing we should be able to see that
    • in the wiki, we refer to things with direct links - everything is a direct link
    • everywhere there is a link - there is a hover that shows everything that links to X
    • rather than having to click on x we can see links on hover
    • social-utility [KK] (claim) KK: this would encode proof of use, proof of utility
• querying [DA] (question) DA: with sparql queries - can you browse the whole wiki tree and parse out what you want from that?
  • querying [KM] (claim) Km: yes - it's the right query language for this kind of data
• querying [DA] (question) DA: can you see the context for the link inside of the page? if I'm referring to a link, can I see the sentence that link is embedded in?
  • querying [KM] (claim) we'd need to annotate the wiki using the DG schema and then query against that schema -- the amazing thing about sparql is that anything thats connected, you can get there
• tool [KK] (claim) seems like we're rediscovering properties native to roam and trying to put them in the wiki
• structure [DA] (claim) DA:DA: the hover is sugar - we can get there by putting everything on a page: on the bottom of a claims page we have everything that mentions this claim and an extra field that describes, enriches the mention (support/oppose) context
• agora [KM] (claim) KM agora is partly a discovery algo for a graph
  • component of building an autocomplete for DGs is a mechanism to discover graphs and do the autocomplete so they algo can work off of
  • once there are DG to work from, agora algo seems like a useful tool to search the ecosystem
  • agora [DA] (question) how do you get data into an agora ?
  • agora [SJ] (claim) a mediawiki could be an agora
  • agora [KH] (question) we still have to encode each node as a page if we want to build on this agora model
• granularity [SJ] (question) SJ: question about the appropriate level of granularity?
• granularity [KH] (question) KH: also identity question - what is the smallest item you can point to?
  • structure [SJ] (claim) SJ: 2 separate ID Q:
    • let's add the concept of a page for a graph
    • something you can hold in your mind as an image
    • more than one claim
    • individual claims shouldn't be pages, but nodes or entities
    • if we want to do this in the wikiverse we can talk about them as entities
    • SMW will represent entities as pages but it doesn't scale
  • SMW [DA] (question) SMW will not support a large volume?
  • SMW [SJ] (evidence) SMW is designed for pages to have sizeable amt of text, well-formatted and structured
  • we're talking about entire constellations (also a claim)
• viz [SJ] (question) Q of what viz we need -
  • can still use MW as a viz - what happens when we hover over?
  • want to be able to see the links while looking at the claim in context
• tool [SJ] (claim) SJ: it does make sense to use a wiki for prototyping and experimenting - like where we want to carve distinctions
  • it's nice to be able to go back & forth in a collab text format
  • take snapshots and convert to a permanently structured DG
  • more lastingly machine readable version of the same discourse
  • wiki capture could feel more like a discourse if the discourse originated with people
  • iteratively annotate and structure
• {{d|id= tool |a=KH |type= question |text=KH: it's nice to have a familiar authoring tool like a wiki
• approach [KH] (claim) it would make sense to start with something like we did and have an external tool go over it and store it for later processing
  • wiki is a data entry tool
  • we still don't have relations
  • but this is not so much a problem privately, only when we merge
• goal [KK] (claim) KK: we're in a search for conventions: how do we write anywhere in a discourse graph?
• goal [KH] (claim) our goal is to create Markdown for Discourse Graphs - a set of syntax conventions portable everywhere - we can extract and port to appropriate DB to query and viz later