Talk:Discourse Modeling
From Synthesis Infrastructures
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?
- 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: 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
- 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?
- 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
- 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
