Synthesis Infrastructures - User contributions [en]

Talk:Discourse Modeling

2022-11-13T18:06:42Z

Sj: experiments

== Participants in the discussion ==

* SJ: [https://synthesis-infrastructures.wiki/User:Sj Samuel Klein]
* KM: [[Kyle MacLaury]]
* KK: [[Karola Kirsanow]]
* KH: [[Konrad Hinsen]]

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* {{d|id=1 |a=KM |type=question |text=can we build the queries needed to interact with the Discourse Graph data model?}}
** {{d|id=2 |a= |type=claim |text=this entails making DGs part of the wiki and shareable |supports=1}}
** {{d|id=3 |a= |type=claim |text=relevant tools include wolfram/mathematica & wiki functions |supports=1}}
*** {{d|id=4 |a=KM |type=claim |text=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}}
** {{d|id=5 |a=SJ |type=claim |text=it is also desirable to create a namespace of functions that any contributor to functions can edit |supports=1}}
*** {{d|id=6 |a=SJ |type=claim |text=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}}
*** {{d|id=7 |a=SJ |type=claim |text=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}}
*** {{d|id=8 |a=KH |type=evidence |text=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 ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|extends=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=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}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|extends=survey-first}}



==== Conflict Resolution ====
* {{d|id=page-forking |a=? |type=question |text=problem with wiki is that there is only one version of each page - what if you disagree? |supports=}}
** {{d|id=fed-wiki |a=? |type=question |text=in wiki each page has a single version ==> federated wiki is the solution |supports=page-forking}}
** {{d|id=fed-wiki-git |a=? |type=claim |text=pages in a federated wiki are more like working in branches as in git |extends=fed-wiki}}
*** {{d|id=fed-wiki-merging |a=? |type=claim |text=''branches'' and ''merges'' are important ideas in the federated wiki concept space |supports=fed-wiki-git}}
* {{d|id=author-dgs |a=KH |type=claim |text=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 |supports=}}
** {{d|id=author-label-loss |a=KH |type=question |text=will the "author" label on scientific papers disappear as collaborations grow? |supports=author-dgs }}
* {{d|id=better-graph-viz |a=? |type=question |text=can we enable effective and usable graph visualizations? |supports=}}
* {{d|id=do-properties-scale |a=SJ |type=question |text=do DG graph properties scale to communally edited collaborative graphs? |supports=}}



==== Version control v Narratives ====
* {{d|id=meet-in-middle |a=? |type=question |text=how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives? |supports=}}
** {{d|id= |a=KK |type=evidence |text=[https://everything2.com/ everything2] |supports=meet-in-middle}}
** {{d|id= |a=KK |type=evidence |text=[https://anagora.org/agora agora] |supports=meet-in-middle}}
* {{d|id=what-dg-types |a=SJ |type=question |text=what types of graph are we talking about? |supports=}}
** {{d|id=lacking-meta-dgs |a=SJ |type=claim |text=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}}
*** {{d|id=composite-dg |a=SJ |type=question |text=what does composite graph of discourse addressing the same issues look like? |extends=lacking-meta-dgs}}
** {{d|id= |a=SJ |type=claim |text=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 ==
* {{d|id=start-w-schemas |a= |type=question |text=What if we start with naming & schemas first |supports=}}
* {{d|id= |a= |type=question |text=do we start with a schema or refine as we go? |supports=}}
** {{d|id= |a=SJ |type=claim |text=smw makes this hard for exactly this reason (deciding up front is friction). |supports=start-w-schemas}}
** {{d|id=simple-mw |a= |type=claim |text=easier with free form mediawiki templates and wiki text |supports=start-w-schemas}}
*** {{d|id= |a= |type=claim |text=templates allow tiny Lua templates, w/ any number of fields and presentation. |supports=simple-mw}}
*** {{d|id= |a=SJ |type=claim |text=this can be edited flexibly, so schema changes don't break things or make them illegible. |supports=simple-mw}}

** {{d|id= |a=KK |type=question |text=is there a problem extending from mw to smw later? |extends=simple-mw}}
*** {{d|id= |a= |type=claim |text=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}}
*** {{d|id= |a= |type=claim |text=depends on what authoring + visualization tools we want, and the modelling tradeoffs we want |supports=simple-mw}}

* {{d|id=template-start |a=KK |type=question |text=should we start with creating a "source" template: source: url, publisher, date, author ? |supports=}}
* {{d|id=edge-complexity |a=KK |type=question |text=will defining edges/relationships turn out to be more complicated than creating templates for nodes? |supports=}}
* {{d|id=when-done |a=KK |type=question |text=how do we know when we are done? |supports=}}

** {{d|id=internal-consistency |a=SJ |type=claim |text=we need to create an internally consistent way of sharing templates |supports=template-start}}
*** {{d|id= |a=KH |type=claim |text=challenge: templates are universally available, which means that anyone can break our template|supports=internal-consistency}}

* {{d|id= |a=KM |type=question |text=should we decompose Questions into further properties (like a Q has a subject and object) or leave it nat language?|supports=}}
** {{d|id= |a=KH |type=claim |text=we should stick to natural language | source=self |supports=}}

* {{d|id=wiki-granularity |a=KH |type=question |text=if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page? |supports=}}
** {{d|id=wiki-all-pages |a=KM |type=claim |text=it seems everything is a page. |extends=wiki-granularity }}
*** {{d|id=wiki-sections |a=SJ |type=claim |text=sections of a page are not a page. |opposes=wiki-all-pages }}
** {{d|id=wiki-node-pages |a=SJ |type=claim |text=everything we want to be a node should be a page. |extends=wiki-granularity }}
** {{d|id=wiki-subgraph-pages |a=SJ |type=claim |text=wiki transclusion also allows any subgraph to have a page, transcluding other nodes. |extends=wiki-granularity }}
*** {{d|id=wiki-pages-busy |a=SJ |type=claim |text= then each page needs a title - lots of work. and makes the history view busy, a UX question affecting exploration. |opposes=wiki-node-pages }}
** {{d|id=wiki-pages-manageable |a=SJ |type=claim |text=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''
*** {{d|id=start-with-transclusion|a=KH |type=claim |text=first attempt: everything is a page, we rely on transclusion to group things |supports=wiki-pages-manageable}}
** {{d|id= |a=KH |type=question |text=can we have the entire Q as a page title? |extends=wiki-pages-busy }}

* {{d|id= |a=KK |type=claim |text=there are many to many relationships between sources & evidence |supports=}}
* {{d|id= |a= |type=claim |text=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|supports=}}
* {{d|id=starting-dgs |a=SJ |type=claim |text=let's identify a discussion we want to capture, and figure out how to name it. |supports=}}

Template:D

2022-11-13T18:06:31Z

Sj:

<noinclude>A simple discourse node template.
</noinclude>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} {{#if:
{{{supports|}}}| supports: [[{{FULLPAGENAME}}#{{{supports}}}|{{{supports}}}]]| }} {{#if:
{{{opposes|}}}| opposes: [[{{FULLPAGENAME}}#{{{opposes}}}|{{{opposes}}}]]| }} {{#if:
{{{extends|}}}| extends: [[{{FULLPAGENAME}}#{{{extends}}}|{{{extends}}}]]| }}

Talk:Discourse Modeling

2022-11-13T18:06:13Z

Sj: extends

Talk:Discourse Modeling

2022-11-13T18:04:43Z

Sj: opposes

== Participants in the discussion ==

* SJ: [https://synthesis-infrastructures.wiki/User:Sj Samuel Klein]
* KM: [[Kyle MacLaury]]
* KK: [[Karola Kirsanow]]
* KH: [[Konrad Hinsen]]

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* {{d|id=1 |a=KM |type=question |text=can we build the queries needed to interact with the Discourse Graph data model?}}
** {{d|id=2 |a= |type=claim |text=this entails making DGs part of the wiki and shareable |supports=1}}
** {{d|id=3 |a= |type=claim |text=relevant tools include wolfram/mathematica & wiki functions |supports=1}}
*** {{d|id=4 |a=KM |type=claim |text=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}}
** {{d|id=5 |a=SJ |type=claim |text=it is also desirable to create a namespace of functions that any contributor to functions can edit |supports=1}}
*** {{d|id=6 |a=SJ |type=claim |text=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}}
*** {{d|id=7 |a=SJ |type=claim |text=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}}
*** {{d|id=8 |a=KH |type=evidence |text=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 ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|clarify=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=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}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|clarify=survey-first}}



==== Conflict Resolution ====
* {{d|id=page-forking |a=? |type=question |text=problem with wiki is that there is only one version of each page - what if you disagree? |supports=}}
** {{d|id=fed-wiki |a=? |type=question |text=in wiki each page has a single version ==> federated wiki is the solution |supports=page-forking}}
** {{d|id=fed-wiki-git |a=? |type=claim |text=pages in a federated wiki are more like working in branches as in git |clarifies=fed-wiki}}
*** {{d|id=fed-wiki-merging |a=? |type=claim |text=''branches'' and ''merges'' are important ideas in the federated wiki concept space |supports=fed-wiki-git}}
* {{d|id=author-dgs |a=KH |type=claim |text=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 |supports=}}
** {{d|id=author-label-loss |a=KH |type=question |text=will the "author" label on scientific papers disappear as collaborations grow? |supports=author-dgs }}
* {{d|id=better-graph-viz |a=? |type=question |text=can we enable effective and usable graph visualizations? |supports=}}
* {{d|id=do-properties-scale |a=SJ |type=question |text=do DG graph properties scale to communally edited collaborative graphs? |supports=}}



==== Version control v Narratives ====
* {{d|id=meet-in-middle |a=? |type=question |text=how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives? |supports=}}
** {{d|id= |a=KK |type=evidence |text=[https://everything2.com/ everything2] |supports=meet-in-middle}}
** {{d|id= |a=KK |type=evidence |text=[https://anagora.org/agora agora] |supports=meet-in-middle}}
* {{d|id=what-dg-types |a=SJ |type=question |text=what types of graph are we talking about? |supports=}}
** {{d|id=lacking-meta-dgs |a=SJ |type=claim |text=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}}
*** {{d|id=composite-dg |a=SJ |type=question |text=what does composite graph of discourse addressing the same issues look like? |extends=lacking-meta-dgs}}
** {{d|id= |a=SJ |type=claim |text=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 ==
* {{d|id=start-w-schemas |a= |type=question |text=What if we start with naming & schemas first |supports=}}
* {{d|id= |a= |type=question |text=do we start with a schema or refine as we go? |supports=}}
** {{d|id= |a=SJ |type=claim |text=smw makes this hard for exactly this reason (deciding up front is friction). |supports=start-w-schemas}}
** {{d|id=simple-mw |a= |type=claim |text=easier with free form mediawiki templates and wiki text |supports=start-w-schemas}}
*** {{d|id= |a= |type=claim |text=templates allow tiny Lua templates, w/ any number of fields and presentation. |supports=simple-mw}}
*** {{d|id= |a=SJ |type=claim |text=this can be edited flexibly, so schema changes don't break things or make them illegible. |supports=simple-mw}}

** {{d|id= |a=KK |type=question |text=is there a problem extending from mw to smw later? |extends=simple-mw}}
*** {{d|id= |a= |type=claim |text=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}}
*** {{d|id= |a= |type=claim |text=depends on what authoring + visualization tools we want, and the modelling tradeoffs we want |supports=simple-mw}}

* {{d|id=template-start |a=KK |type=question |text=should we start with creating a "source" template: source: url, publisher, date, author ? |supports=}}
* {{d|id=edge-complexity |a=KK |type=question |text=will defining edges/relationships turn out to be more complicated than creating templates for nodes? |supports=}}
* {{d|id=when-done |a=KK |type=question |text=how do we know when we are done? |supports=}}

** {{d|id=internal-consistency |a=SJ |type=claim |text=we need to create an internally consistent way of sharing templates |supports=template-start}}
*** {{d|id= |a=KH |type=claim |text=challenge: templates are universally available, which means that anyone can break our template|supports=internal-consistency}}

* {{d|id= |a=KM |type=question |text=should we decompose Questions into further properties (like a Q has a subject and object) or leave it nat language?|supports=}}
** {{d|id= |a=KH |type=claim |text=we should stick to natural language | source=self |supports=}}

* {{d|id=wiki-granularity |a=KH |type=question |text=if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page? |supports=}}
** {{d|id=wiki-all-pages |a=KM |type=claim |text=it seems everything is a page. |extends=wiki-granularity }}
*** {{d|id=wiki-sections |a=SJ |type=claim |text=sections of a page are not a page. |opposes=wiki-all-pages }}
** {{d|id=wiki-node-pages |a=SJ |type=claim |text=everything we want to be a node should be a page. |extends=wiki-granularity }}
** {{d|id=wiki-subgraph-pages |a=SJ |type=claim |text=wiki transclusion also allows any subgraph to have a page, transcluding other nodes. |extends=wiki-granularity }}
*** {{d|id=wiki-pages-busy |a=SJ |type=claim |text= then each page needs a title - lots of work. and makes the history view busy, a UX question affecting exploration. |opposes=wiki-node-pages }}
** {{d|id=wiki-pages-manageable |a=SJ |type=claim |text=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''
*** {{d|id=start-with-transclusion|a=KH |type=claim |text=first attempt: everything is a page, we rely on transclusion to group things |supports=wiki-pages-manageable}}
** {{d|id= |a=KH |type=question |text=can we have the entire Q as a page title? |extends=wiki-pages-busy }}

* {{d|id= |a=KK |type=claim |text=there are many to many relationships between sources & evidence |supports=}}
* {{d|id= |a= |type=claim |text=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|supports=}}
* {{d|id=starting-dgs |a=SJ |type=claim |text=let's identify a discussion we want to capture, and figure out how to name it. |supports=}}

Template:D

2022-11-13T18:04:30Z

Sj:

Talk:Discourse Modeling

2022-11-13T18:01:09Z

Sj: /* Section 3 Kyle */

== Participants in the discussion ==

* SJ: [https://synthesis-infrastructures.wiki/User:Sj Samuel Klein]
* KM: [[Kyle MacLaury]]
* KK: [[Karola Kirsanow]]
* KH: [[Konrad Hinsen]]

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* {{d|id=1 |a=KM |type=question |text=can we build the queries needed to interact with the Discourse Graph data model?}}
** {{d|id=2 |a= |type=claim |text=this entails making DGs part of the wiki and shareable |supports=1}}
** {{d|id=3 |a= |type=claim |text=relevant tools include wolfram/mathematica & wiki functions |supports=1}}
*** {{d|id=4 |a=KM |type=claim |text=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}}
** {{d|id=5 |a=SJ |type=claim |text=it is also desirable to create a namespace of functions that any contributor to functions can edit |supports=1}}
*** {{d|id=6 |a=SJ |type=claim |text=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}}
*** {{d|id=7 |a=SJ |type=claim |text=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}}
*** {{d|id=8 |a=KH |type=evidence |text=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 ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|clarify=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=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}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|clarify=survey-first}}



==== Conflict Resolution ====
* {{d|id=page-forking |a=? |type=question |text=problem with wiki is that there is only one version of each page - what if you disagree? |supports=}}
** {{d|id=fed-wiki |a=? |type=question |text=in wiki each page has a single version ==> federated wiki is the solution |supports=page-forking}}
** {{d|id=fed-wiki-git |a=? |type=claim |text=pages in a federated wiki are more like working in branches as in git |clarifies=fed-wiki}}
*** {{d|id=fed-wiki-merging |a=? |type=claim |text=''branches'' and ''merges'' are important ideas in the federated wiki concept space |supports=fed-wiki-git}}
* {{d|id=author-dgs |a=KH |type=claim |text=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 |supports=}}
** {{d|id=author-label-loss |a=KH |type=question |text=will the "author" label on scientific papers disappear as collaborations grow? |supports=author-dgs }}
* {{d|id=better-graph-viz |a=? |type=question |text=can we enable effective and usable graph visualizations? |supports=}}
* {{d|id=do-properties-scale |a=SJ |type=question |text=do DG graph properties scale to communally edited collaborative graphs? |supports=}}



==== Version control v Narratives ====
* {{d|id=meet-in-middle |a=? |type=question |text=how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives? |supports=}}
** {{d|id= |a=KK |type=evidence |text=[https://everything2.com/ everything2] |supports=meet-in-middle}}
** {{d|id= |a=KK |type=evidence |text=[https://anagora.org/agora agora] |supports=meet-in-middle}}
* {{d|id=what-dg-types |a=SJ |type=question |text=what types of graph are we talking about? |supports=}}
** {{d|id=lacking-meta-dgs |a=SJ |type=claim |text=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}}
*** {{d|id=composite-dg |a=SJ |type=question |text=what does composite graph of discourse addressing the same issues look like? |extends=lacking-meta-dgs}}
** {{d|id= |a=SJ |type=claim |text=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 ==
* {{d|id=start-w-schemas |a= |type=question |text=What if we start with naming & schemas first |supports=}}
* {{d|id= |a= |type=question |text=do we start with a schema or refine as we go? |supports=}}
** {{d|id= |a=SJ |type=claim |text=smw makes this hard for exactly this reason (deciding up front is friction). |supports=start-w-schemas}}
** {{d|id=simple-mw |a= |type=claim |text=easier with free form mediawiki templates and wiki text |supports=start-w-schemas}}
*** {{d|id= |a= |type=claim |text=templates allow tiny Lua templates, w/ any number of fields and presentation. |supports=simple-mw}}
*** {{d|id= |a=SJ |type=claim |text=this can be edited flexibly, so schema changes don't break things or make them illegible. |supports=simple-mw}}

** {{d|id= |a=KK |type=question |text=is there a problem extending from mw to smw later? |extends=simple-mw}}
*** {{d|id= |a= |type=claim |text=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}}
*** {{d|id= |a= |type=claim |text=depends on what authoring + visualization tools we want, and the modelling tradeoffs we want |supports=simple-mw}}

* {{d|id=template-start |a=KK |type=question |text=should we start with creating a "source" template: source: url, publisher, date, author ? |supports=}}
* {{d|id=edge-complexity |a=KK |type=question |text=will defining edges/relationships turn out to be more complicated than creating templates for nodes? |supports=}}
* {{d|id=when-done |a=KK |type=question |text=how do we know when we are done? |supports=}}

** {{d|id=internal-consistency |a=SJ |type=claim |text=we need to create an internally consistent way of sharing templates |supports=template-start}}
*** {{d|id= |a=KH |type=claim |text=challenge: templates are universally available, which means that anyone can break our template|supports=internal-consistency}}

* {{d|id= |a=KM |type=question |text=should we decompose Questions into further properties (like a Q has a subject and object) or leave it nat language?|supports=}}
** {{d|id= |a=KH |type=claim |text=we should stick to natural language | source=self |supports=}}

* {{d|id=wiki-granularity |a=KH |type=question |text=if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page? |supports=}}
** {{d|id=wiki-all-pages |a=KM |type=claim |text=it seems everything is a page. |extends=wiki-granularity }}
*** {{d|id=wiki-sections |a=SJ |type=claim |text=sections of a page are not a page. |opposes=wiki-all-pages }}
** {{d|id=wiki-node-pages |a=SJ |type=claim |text=everything we want to be a node should be a page. |extends=wiki-granularity }}
** {{d|id=wiki-subgraph-pages |a=SJ |type=claim |text=wiki transclusion also allows any subgraph to have a page, transcluding other nodes. |extends=wiki-granularity }}
*** {{d|id=wiki-pages-busy |a=SJ |type=claim |text= then each page needs a title - lots of work. and makes the history view busy, a UX question affecting exploration. |opposes=wiki-node-pages }}
** {{d|id=wiki-pages-manageable |a=SJ |type=claim |text=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''
*** {{d|id=start-with-transclusion|a=KH |type=claim |text=first attempt: everything is a page, we rely on transclusion to group things |supports=wiki-pages-manageable}}
** {{d|id= |a=KH |type=question |text=can we have the entire Q as a page title? |extends=wiki-pages-busy }}

* {{d|id= |a=KK |type=claim |text=there are many to many relationships between sources & evidence |supports=}}
* {{d|id= |a= |type=claim |text=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|supports=}}
* {{d|id=starting-dgs |a=SJ |type=claim |text=let's identify a discussion we want to capture, and figure out how to name it. |supports=}}

Talk:Discourse Modeling

2022-11-13T17:58:04Z

Sj: /* Section 3 Kyle */

== Participants in the discussion ==

* SJ: [https://synthesis-infrastructures.wiki/User:Sj Samuel Klein]
* KM: [[Kyle MacLaury]]
* KK: [[Karola Kirsanow]]
* KH: [[Konrad Hinsen]]

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* {{d|id=1 |a=KM |type=question |text=can we build the queries needed to interact with the Discourse Graph data model?}}
** {{d|id=2 |a= |type=claim |text=this entails making DGs part of the wiki and shareable |supports=1}}
** {{d|id=3 |a= |type=claim |text=relevant tools include wolfram/mathematica & wiki functions |supports=1}}
*** {{d|id=4 |a=KM |type=claim |text=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}}
** {{d|id=5 |a=SJ |type=claim |text=it is also desirable to create a namespace of functions that any contributor to functions can edit |supports=1}}
*** {{d|id=6 |a=SJ |type=claim |text=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}}
*** {{d|id=7 |a=SJ |type=claim |text=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}}
*** {{d|id=8 |a=KH |type=evidence |text=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 ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|clarify=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=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}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|clarify=survey-first}}



==== Conflict Resolution ====
* {{d|id=page-forking |a=? |type=question |text=problem with wiki is that there is only one version of each page - what if you disagree? |supports=}}
** {{d|id=fed-wiki |a=? |type=question |text=in wiki each page has a single version ==> federated wiki is the solution |supports=page-forking}}
** {{d|id=fed-wiki-git |a=? |type=claim |text=pages in a federated wiki are more like working in branches as in git |clarifies=fed-wiki}}
*** {{d|id=fed-wiki-merging |a=? |type=claim |text=''branches'' and ''merges'' are important ideas in the federated wiki concept space |supports=fed-wiki-git}}
* {{d|id=author-dgs |a=KH |type=claim |text=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 |supports=}}
** {{d|id=author-label-loss |a=KH |type=question |text=will the "author" label on scientific papers disappear as collaborations grow? |supports=author-dgs }}
* {{d|id=better-graph-viz |a=? |type=question |text=can we enable effective and usable graph visualizations? |supports=}}
* {{d|id=do-properties-scale |a=SJ |type=question |text=do DG graph properties scale to communally edited collaborative graphs? |supports=}}



==== Version control v Narratives ====
* {{d|id=meet-in-middle |a=? |type=question |text=how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives? |supports=}}
** {{d|id= |a=KK |type=evidence |text=[https://everything2.com/ everything2] |supports=meet-in-middle}}
** {{d|id= |a=KK |type=evidence |text=[https://anagora.org/agora agora] |supports=meet-in-middle}}
* {{d|id=what-dg-types |a=SJ |type=question |text=what types of graph are we talking about? |supports=}}
** {{d|id=lacking-meta-dgs |a=SJ |type=claim |text=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}}
*** {{d|id=composite-dg |a=SJ |type=question |text=what does composite graph of discourse addressing the same issues look like? |extends=lacking-meta-dgs}}
** {{d|id= |a=SJ |type=claim |text=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 ==
* {{d|id= |a= |type=claim |text=What if we start with naming & schemas first |supports=}}
* {{d|id= |a= |type=question |text=do we start with a schema or refine as we go? |supports=}}
** {{d|id= |a=SJ |type=claim |text=smw makes this hard for exactly this reason (deciding up front is friction). |supports=}}
** {{d|id= |a= |type=claim |text=easier with free form mediawiki templates and wiki text |supports=}}
*** {{d|id= |a= |type=claim |text=templates allow tiny Lua templates, w/ any number of fields and presentation. |supports=}}
*** {{d|id= |a=SJ |type=claim |text=this can be edited flexibly, so schema changes don't break things or make them illegible. |supports=}}

** {{d|id= |a=KK |type=question |text=is there a problem extending from mw to smw later? |supports=}}
*** {{d|id= |a= |type=claim |text=no, can start with a dozen schemas by hand, then decide if to move to a MW extension (smw or other) or wikidata |supports=}}
*** {{d|id= |a= |type=claim |text=depends on what authoring + visualization tools we want, and the modelling tradeoffs we want |supports=}}

* {{d|id=template-start |a=KK |type=question |text=should we start with creating a "source" template: source: url, publisher, date, author ? |supports=}}
* {{d|id=edge-complexity |a=KK |type=question |text=will defining edges/relationships turn out to be more complicated than creating templates for nodes? |supports=}}
* {{d|id=when-done |a=KK |type=question |text=how do we know when we are done? |supports=}}

** {{d|id=internal-consistency |a=SJ |type=claim |text=we need to create an internally consistent way of sharing templates |supports=template-start}}
*** {{d|id= |a=KH |type=claim |text=challenge: templates are universally available, which means that anyone can break our template|supports=internal-consistency}}

* {{d|id= |a=KM |type=question |text=should we decompose Questions into further properties (like a Q has a subject and object) or leave it nat language?|supports=}}
** {{d|id= |a=KH |type=claim |text=we should stick to natural language | source=self |supports=}}

* {{d|id=wiki-granularity |a=KH |type=question |text=if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page? |supports=}}
** {{d|id=wiki-all-pages |a=KM |type=claim |text=it seems everything is a page. |extends=wiki-granularity }}
*** {{d|id=wiki-sections |a=SJ |type=claim |text=sections of a page are not a page. |opposes=wiki-all-pages }}
** {{d|id=wiki-node-pages |a=SJ |type=claim |text=everything we want to be a node should be a page. |extends=wiki-granularity }}
** {{d|id=wiki-subgraph-pages |a=SJ |type=claim |text=wiki transclusion also allows any subgraph to have a page, transcluding other nodes. |extends=wiki-granularity }}
*** {{d|id=wiki-pages-busy |a=SJ |type=claim |text= then each page needs a title - lots of work. and makes the history view busy, a UX question affecting exploration. |opposes=wiki-node-pages }}
** {{d|id=wiki-pages-manageable |a=SJ |type=claim |text=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''
*** {{d|id=start-with-transclusion|a=KH |type=claim |text=first attempt: everything is a page, we rely on transclusion to group things |supports=wiki-pages-manageable}}
** {{d|id= |a=KH |type=question |text=can we have the entire Q as a page title? |extends=wiki-pages-busy }}

* {{d|id= |a=KK |type=claim |text=there are many to many relationships between sources & evidence |supports=}}
* {{d|id= |a= |type=claim |text=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|supports=}}
* {{d|id=starting-dgs |a=SJ |type=claim |text=let's identify a discussion we want to capture, and figure out how to name it. |supports=}}

Talk:Discourse Modeling

2022-11-13T17:28:21Z

Sj:

== Participants in the discussion ==

* SJ: [https://synthesis-infrastructures.wiki/User:Sj Samuel Klein]
* KM: [[Kyle MacLaury]]
* KK: [[Karola Kirsanow]]
* KH: [[Konrad Hinsen]]

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* {{d|id=1 |a=KM |type=question |text=can we build the queries needed to interact with the Discourse Graph data model?}}
** {{d|id=2 |a= |type=claim |text=this entails making DGs part of the wiki and shareable |supports=1}}
** {{d|id=3 |a= |type=claim |text=relevant tools include wolfram/mathematica & wiki functions |supports=1}}
*** {{d|id=4 |a=KM |type=claim |text=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}}
** {{d|id=5 |a=SJ |type=claim |text=it is also desirable to create a namespace of functions that any contributor to functions can edit |supports=1}}
*** {{d|id=6 |a=SJ |type=claim |text=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}}
*** {{d|id=7 |a=SJ |type=claim |text=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}}
*** {{d|id=8 |a=KH |type=evidence |text=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 ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|clarify=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=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}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|clarify=survey-first}}



==== Conflict Resolution ====
* {{d|id=page-forking |a=? |type=question |text=problem with wiki is that there is only one version of each page - what if you disagree? |supports=}}
** {{d|id=fed-wiki |a=? |type=question |text=in wiki each page has a single version ==> federated wiki is the solution |supports=page-forking}}
** {{d|id=fed-wiki-git |a=? |type=claim |text=pages in a federated wiki are more like working in branches as in git |clarifies=fed-wiki}}
*** {{d|id=fed-wiki-merging |a=? |type=claim |text=''branches'' and ''merges'' are important ideas in the federated wiki concept space |supports=fed-wiki-git}}
* {{d|id=author-dgs |a=KH |type=claim |text=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 |supports=}}
** {{d|id=author-label-loss |a=KH |type=question |text=will the "author" label on scientific papers disappear as collaborations grow? |supports=author-dgs }}
* {{d|id=better-graph-viz |a=? |type=question |text=can we enable effective and usable graph visualizations? |supports=}}
* {{d|id=do-properties-scale |a=SJ |type=question |text=do DG graph properties scale to communally edited collaborative graphs? |supports=}}



==== Version control v Narratives ====
* {{d|id=meet-in-middle |a=? |type=question |text=how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives? |supports=}}
** {{d|id= |a=KK |type=evidence |text=[https://everything2.com/ everything2] |supports=meet-in-middle}}
** {{d|id= |a=KK |type=evidence |text=[https://anagora.org/agora agora] |supports=meet-in-middle}}
* {{d|id=what-dg-types |a=SJ |type=question |text=what types of graph are we talking about? |supports=}}
** {{d|id=lacking-meta-dgs |a=SJ |type=claim |text=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}}
*** {{d|id=composite-dg |a=SJ |type=question |text=what does composite graph of discourse addressing the same issues look like? |extends=lacking-meta-dgs}}
** {{d|id= |a=SJ |type=claim |text=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 ==
* {{d|id= |a= |type=claim |text=What if we start with naming & schemas first |supports=}}
* {{d|id= |a= |type=question |text=do we start with a schema or refine as we go? |supports=}}
** {{d|id= |a=SJ |type=claim |text=smw makes this hard for exactly this reason (deciding up front is friction). |supports=}}
** {{d|id= |a= |type=claim |text=easier with free form mediawiki templates and wiki text |supports=}}
*** {{d|id= |a= |type=claim |text=templates allow tiny Lua templates, w/ any number of fields and presentation. |supports=}}
*** {{d|id= |a=SJ |type=claim |text=this can be edited flexibly, so schema changes don't break things or make them illegible. |supports=}}

** {{d|id= |a=KK |type=question |text=is there a problem extending from mw to smw later? |supports=}}
*** {{d|id= |a= |type=claim |text=no, can start with a dozen schemas by hand, then decide if to move to a MW extension (smw or other) or wikidata |supports=}}
*** {{d|id= |a= |type=claim |text=depends on what authoring + visualization tools we want, and the modelling tradeoffs we want |supports=}}

* {{d|id=template-start |a=KK |type=question |text=should we start with creating a "source" template: source: url, publisher, date, author ? |supports=}}
* {{d|id=edge-complexity |a=KK |type=question |text=will defining edges/relationships turn out to be more complicated than creating templates for nodes? |supports=}}
* {{d|id=when-done |a=KK |type=question |text=how do we know when we are done? |supports=}}



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

Talk:Discourse Modeling

2022-11-13T17:07:44Z

Sj: /* Version control v Narratives */

== Participants in the discussion ==

* SJ: [https://synthesis-infrastructures.wiki/User:Sj Samuel Klein]
* KM: [[Kyle MacLaury]]
* KK: [[Karola Kirsanow]]
* KH: [[Konrad Hinsen]]

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* {{d|id=1 |a=KM |type=question |text=can we build the queries needed to interact with the Discourse Graph data model?}}
** {{d|id=2 |a= |type=claim |text=this entails making DGs part of the wiki and shareable |supports=1}}
** {{d|id=3 |a= |type=claim |text=relevant tools include wolfram/mathematica & wiki functions |supports=1}}
*** {{d|id=4 |a=KM |type=claim |text=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}}
** {{d|id=5 |a=SJ |type=claim |text=it is also desirable to create a namespace of functions that any contributor to functions can edit |supports=1}}
*** {{d|id=6 |a=SJ |type=claim |text=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}}
*** {{d|id=7 |a=SJ |type=claim |text=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}}
*** {{d|id=8 |a=KH |type=evidence |text=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 ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|clarify=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=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}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|clarify=survey-first}}



==== Conflict Resolution ====
* {{d|id=page-forking |a=? |type=question |text=problem with wiki is that there is only one version of each page - what if you disagree? |supports=}}
** {{d|id=fed-wiki |a=? |type=question |text=in wiki each page has a single version ==> federated wiki is the solution |supports=page-forking}}
** {{d|id=fed-wiki-git |a=? |type=claim |text=pages in a federated wiki are more like working in branches as in git |clarifies=fed-wiki}}
*** {{d|id=fed-wiki-merging |a=? |type=claim |text=''branches'' and ''merges'' are important ideas in the federated wiki concept space |supports=fed-wiki-git}}
* {{d|id=author-dgs |a=KH |type=claim |text=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 |supports=}}
** {{d|id=author-label-loss |a=KH |type=question |text=will the "author" label on scientific papers disappear as collaborations grow? |supports=author-dgs }}
* {{d|id=better-graph-viz |a=? |type=question |text=can we enable effective and usable graph visualizations? |supports=}}
* {{d|id=do-properties-scale |a=SJ |type=question |text=do DG graph properties scale to communally edited collaborative graphs? |supports=}}



==== Version control v Narratives ====
* {{d|id=meet-in-middle |a=? |type=question |text=how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives? |supports=}}
** {{d|id= |a=KK |type=evidence |text=[https://everything2.com/ everything2] |supports=meet-in-middle}}
** {{d|id= |a=KK |type=evidence |text=[https://anagora.org/agora agora] |supports=meet-in-middle}}
* {{d|id=what-dg-types |a=SJ |type=question |text=what types of graph are we talking about? |supports=}}
** {{d|id=lacking-meta-dgs |a=SJ |type=claim |text=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}}
*** {{d|id=composite-dg |a=SJ |type=question |text=what does composite graph of discourse addressing the same issues look like? |extends=lacking-meta-dgs}}
** {{d|id= |a=SJ |type=claim |text=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 ==
*
* - 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
*

Talk:Discourse Modeling

2022-11-13T17:07:14Z

Sj: /* Squad goals: */

== Participants in the discussion ==

* SJ: [https://synthesis-infrastructures.wiki/User:Sj Samuel Klein]
* KM: [[Kyle MacLaury]]
* KK: [[Karola Kirsanow]]
* KH: [[Konrad Hinsen]]

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* {{d|id=1 |a=KM |type=question |text=can we build the queries needed to interact with the Discourse Graph data model?}}
** {{d|id=2 |a= |type=claim |text=this entails making DGs part of the wiki and shareable |supports=1}}
** {{d|id=3 |a= |type=claim |text=relevant tools include wolfram/mathematica & wiki functions |supports=1}}
*** {{d|id=4 |a=KM |type=claim |text=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}}
** {{d|id=5 |a=SJ |type=claim |text=it is also desirable to create a namespace of functions that any contributor to functions can edit |supports=1}}
*** {{d|id=6 |a=SJ |type=claim |text=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}}
*** {{d|id=7 |a=SJ |type=claim |text=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}}
*** {{d|id=8 |a=KH |type=evidence |text=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 ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|clarify=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=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}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|clarify=survey-first}}



==== Conflict Resolution ====
* {{d|id=page-forking |a=? |type=question |text=problem with wiki is that there is only one version of each page - what if you disagree? |supports=}}
** {{d|id=fed-wiki |a=? |type=question |text=in wiki each page has a single version ==> federated wiki is the solution |supports=page-forking}}
** {{d|id=fed-wiki-git |a=? |type=claim |text=pages in a federated wiki are more like working in branches as in git |clarifies=fed-wiki}}
*** {{d|id=fed-wiki-merging |a=? |type=claim |text=''branches'' and ''merges'' are important ideas in the federated wiki concept space |supports=fed-wiki-git}}
* {{d|id=author-dgs |a=KH |type=claim |text=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 |supports=}}
** {{d|id=author-label-loss |a=KH |type=question |text=will the "author" label on scientific papers disappear as collaborations grow? |supports=author-dgs }}
* {{d|id=better-graph-viz |a=? |type=question |text=can we enable effective and usable graph visualizations? |supports=}}
* {{d|id=do-properties-scale |a=SJ |type=question |text=do DG graph properties scale to communally edited collaborative graphs? |supports=}}



==== Version control v Narratives ====
* {{d|id=meet-in-middle |a=? |type=question |text=how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives? |supports=}}
** {{d|id= |a=KK |type=evidence |text=[https://everything2.com/ everything2] |supports=meet-in-middle}}
** {{d|id= |a=KK |type=evidence |text=[https://anagora.org/agora agora] |supports=meet-in-middle}}
* {{d|id=what-dg-types |a=SJ |type=question |text=what types of graph are we talking about? |supports=}}
** {{d|id=lacking-meta-dgs |a=SJ |type=claim |text=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}}
*** {{d|id= |a=SJ |type=question |text=what does composite graph of discourse addressing the same issues look like? |extends=lacking-meta-dgs}}
** {{d|id= |a=SJ |type=claim |text=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 ==
*
* - 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
*

Talk:Discourse Modeling

2022-11-13T17:02:41Z

Sj:

== Participants in the discussion ==

* SJ: [https://synthesis-infrastructures.wiki/User:Sj Samuel Klein]
* KM: [[Kyle MacLaury]]
* KK: [[Karola Kirsanow]]
* KH: [[Konrad Hinsen]]

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* {{d|id=1 |a=KM |type=question |text=can we build the queries needed to interact with the Discourse Graph data model?}}
** {{d|id=2 |a= |type=claim |text=this entails making DGs part of the wiki and shareable |supports=1}}
** {{d|id=3 |a= |type=claim |text=relevant tools include wolfram/mathematica & wiki functions |supports=1}}
*** {{d|id=4 |a=KM |type=claim |text=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}}
** {{d|id=5 |a=SJ |type=claim |text=it is also desirable to create a namespace of functions that any contributor to functions can edit |supports=1}}
*** {{d|id=6 |a=SJ |type=claim |text=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}}
*** {{d|id=7 |a=SJ |type=claim |text=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}}
*** {{d|id=8 |a=KH |type=evidence |text=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 ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|clarify=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=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}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|clarify=survey-first}}



==== Conflict Resolution ====
* {{d|id=page-forking |a=? |type=question |text=problem with wiki is that there is only one version of each page - what if you disagree? |supports=}}
** {{d|id=fed-wiki |a=? |type=question |text=in wiki each page has a single version ==> federated wiki is the solution |supports=page-forking}}
** {{d|id=fed-wiki-git |a=? |type=claim |text=pages in a federated wiki are more like working in branches as in git |clarifies=fed-wiki}}
*** {{d|id=fed-wiki-merging |a=? |type=claim |text=''branches'' and ''merges'' are important ideas in the federated wiki concept space |supports=fed-wiki-git}}
* {{d|id=author-dgs |a=KH |type=claim |text=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 |supports=}}
** {{d|id=author-label-loss |a=KH |type=question |text=will the "author" label on scientific papers disappear as collaborations grow? |supports=author-dgs }}
* {{d|id=better-graph-viz |a=? |type=question |text=can we enable effective and usable graph visualizations? |supports=}}
* {{d|id=do-properties-scale |a=SJ |type=question |text=do DG graph properties scale to communally edited collaborative graphs? |supports=}}



==== 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]] [https://everything2.com/ everything2]
**KK:[[evidence]] [https://anagora.org/agora 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
*

Template:D

2022-11-13T17:01:51Z

Sj:

Talk:Discourse Modeling

2022-11-13T17:01:03Z

Sj: /* Conflict Resolution */

== Participants in the discussion ==

* SJ: [https://synthesis-infrastructures.wiki/User:Sj Samuel Klein]
* KM: [[Kyle MacLaury]]
* KK: [[Karola Kirsanow]]
* KH: [[Konrad Hinsen]]

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* {{d|id=1 |a=KM |type=question |text=can we build the queries needed to interact with the Discourse Graph data model?}}
** {{d|id=2 |a= |type=claim |text=this entails making DGs part of the wiki and shareable |supports=1}}
** {{d|id=3 |a= |type=claim |text=relevant tools include wolfram/mathematica & wiki functions |supports=1}}
*** {{d|id=4 |a=KM |type=claim |text=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}}
** {{d|id=5 |a=SJ |type=claim |text=it is also desirable to create a namespace of functions that any contributor to functions can edit |supports=1}}
*** {{d|id=6 |a=SJ |type=claim |text=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}}
*** {{d|id=7 |a=SJ |type=claim |text=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}}
*** {{d|id=8 |a=KH |type=evidence |text=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 ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|clarify=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=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}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|clarify=survey-first}}



==== Conflict Resolution ====
* {{d|id=page-forking |a=? |type=question |text=problem with wiki is that there is only one version of each page - what if you disagree? |supports=}}
** {{d|id=fed-wiki |a=? |type=question |text=in wiki each page has a single version ==> federated wiki is the solution |supports=page-forking}}
** {{d|id=fed-wiki-git |a=? |type=claim |text=pages in a federated wiki are more like working in branches as in git |clarifies=fed-wiki}}
*** {{d|id=fed-wiki-merging |a=? |type=claim |text=''branches'' and ''merges'' are important ideas in the federated wiki concept space |supports=fed-wiki-git}}
* {{d|id=author-dgs |a=KH |type=claim |text=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 |supports=}}
** {{d|id=author-label-loss |a=KH |type=question |text=will the "author" label on scientific papers disappear as collaborations grow? |supports=author-dgs }}
* {{d|id=better-graph-viz |a=? |type=question |text=can we enable effective and usable graph visualizations? |supports=}}
* {{d|id=do-properties-scale |a=SJ |type=question |text=do DG graph properties scale to communally edited collaborative graphs? |supports=}}

 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]] [https://everything2.com/ everything2]
**KK:[[evidence]] [https://anagora.org/agora 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
*

Template:D

2022-11-13T17:00:37Z

Sj:

<noinclude>A simple discourse node template.
</noinclude>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} {{#if:{{{supports|}}}| supports: [[{{FULLPAGENAME}}#{{{supports}}}| {{{supports}}}]]| }}

Template:D

2022-11-13T17:00:09Z

Sj:

<noinclude>A simple discourse node template.
</noinclude>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} {{#if:{{{supports|}}}| supports: [[{{FULLPAGENAME}}#{{{supports}}}| {{{supports}}}]]| }}

Talk:Discourse Modeling

2022-11-13T16:59:12Z

Sj:

== Participants in the discussion ==

* SJ: [https://synthesis-infrastructures.wiki/User:Sj Samuel Klein]
* KM: [[Kyle MacLaury]]
* KK: [[Karola Kirsanow]]
* KH: [[Konrad Hinsen]]

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* {{d|id=1 |a=KM |type=question |text=can we build the queries needed to interact with the Discourse Graph data model?}}
** {{d|id=2 |a= |type=claim |text=this entails making DGs part of the wiki and shareable |supports=1}}
** {{d|id=3 |a= |type=claim |text=relevant tools include wolfram/mathematica & wiki functions |supports=1}}
*** {{d|id=4 |a=KM |type=claim |text=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}}
** {{d|id=5 |a=SJ |type=claim |text=it is also desirable to create a namespace of functions that any contributor to functions can edit |supports=1}}
*** {{d|id=6 |a=SJ |type=claim |text=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}}
*** {{d|id=7 |a=SJ |type=claim |text=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}}
*** {{d|id=8 |a=KH |type=evidence |text=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 ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|clarify=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=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}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|clarify=survey-first}}



==== Conflict Resolution ====
* {{d|id=page-forking |a=? |type=question |text=problem with wiki is that there is only one version of each page - what if you disagree? |supports=}}
** {{d|id=fed-wiki |a=? |type=question |text=in wiki each page has a single version --> federated wiki is the solution |supports=page-forking}}
** {{d|id=fed-wiki-git |a=? |type=claim |text=pages in a federated wiki are more like working in branches as in git |clarifies=fed-wiki}}
*** {{d|id=fed-wiki-merging |a=? |type=claim |text=''branches'' and ''merges'' are important ideas in the federated wiki concept space |supports=fed-wiki-git}}
* {{d|id=author-dgs |a=KH |type=claim |text=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 |supports=}}
** {{d|id=author-label-loss |a=KH |type=question |text=will the "author" label on scientific papers disappear as collaborations grow? |supports=author-dgs }}
* {{d|id=better-graph-viz |a=? |type=question |text=can we enable effective and usable graph visualizations? |supports=}}
* {{d|id=do-properties-scale |a=SJ |type=question |text=do DG graph properties scale to communally edited collaborative graphs? |supports=}}

 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]] [https://everything2.com/ everything2]
**KK:[[evidence]] [https://anagora.org/agora 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
*

Template:D

2022-11-13T16:58:50Z

Sj:

<noinclude>A simple discourse node template.
</noinclude>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} {{#if:{{{supports|}}}| supports: [[{{FULLPAGENAME}}#{{{supports}}}| {{{supports}}}]]| }}

Template talk:D

2022-11-13T16:57:39Z

Sj:

update.

Template:D

2022-11-13T16:57:26Z

Sj:

<noinclude>A simple discourse node template.
</noinclude>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} {{#if:{{{supports|}}}| supports: [[{{FULLPAGENAME}}#{{{supports}}}| {{{supports}}}]]| }}

Talk:Discourse Modeling

2022-11-13T16:50:24Z

Sj: /* Squad goals: */ tests

== Participants in the discussion ==

* SJ: [https://synthesis-infrastructures.wiki/User:Sj Samuel Klein]
* KM: [[Kyle MacLaury]]
* KK: [[Karola Kirsanow]]
* KH: [[Konrad Hinsen]]

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* {{d|id=1 |a=KM |type=question |text=can we build the queries needed to interact with the Discourse Graph data model?}}
** {{d|id=2 |a= |type=claim |text=this entails making DGs part of the wiki and shareable |supports=1}}
** {{d|id=3 |a= |type=claim |text=relevant tools include wolfram/mathematica & wiki functions |supports=1}}
*** {{d|id=4 |a=KM |type=claim |text=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}}
** {{d|id=5 |a=SJ |type=claim |text=it is also desirable to create a namespace of functions that any contributor to functions can edit |supports=1}}
*** {{d|id=6 |a=SJ |type=claim |text=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}}
*** {{d|id=7 |a=SJ |type=claim |text=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}}
*** {{d|id=8 |a=KH |type=evidence |text=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 ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|clarify=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=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}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|clarify=survey-first}}



==== Conflict Resolution ====
* {{d|id=page-forking |a=? |type=question |text=problem with wiki is that there is only one version of each page - what if you disagree? |supports=}}
** {{d|id=fed-wiki |a=? |type=question |text=in wiki each page has a single version --> federated wiki is the solution |supports=page-forking}}
** {{d|id=fed-wiki-git |a=? |type=claim |text=pages in a federated wiki are more like working in branches as in git |clarifies=fed-wiki}}
*** {{d|id=fed-wiki-merging |a=? |type=claim |text=''branches'' and ''merges'' are important ideas in the federated wiki concept space |supports=fed-wiki-git}}
* {{d|id=author-dgs |a=KH |type=claim |text=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 |supports=}}
** {{d|id=author-label-loss |a=KH |type=question |text=will the "author" label on scientific papers disappear as collaborations grow? |supports=author-dgs }}
* {{d|id=better-graph-viz |a=? |type=question |text=can we enable effective and usable graph visualizations? |supports=}}
* {{d|id=do-properties-scale |a=SJ |type=question |text=do DG graph properties scale to communally edited collaborative graphs? |supports=}}

 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]] [https://everything2.com/ everything2]
**KK:[[evidence]] [https://anagora.org/agora 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
*

Talk:Discourse Modeling

2022-11-13T16:36:05Z

Sj: /* Squad goals: */ +clarify

Template:D

2022-11-13T16:16:51Z

Sj:

<noinclude>A simple discourse node template.
</noinclude>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} {{#if:{{{supports|}}}| supports: [[{{FULLPAGENAME}}#{{{supports}}}| {{{supports}}}]]| }}

Question

2022-11-13T16:13:11Z

Sj: Created page with "_"

Template:D

2022-11-13T16:12:12Z

Sj:

<noinclude>A simple discourse node template.
</noinclude>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} supports: [[{{FULLPAGENAME}}#{{{supports|}}}|{{{supports|}}}]]

Template talk:D

2022-11-13T16:11:01Z

Sj:

!! thanks.

Template:D

2022-11-13T16:10:41Z

Sj:

<noinclude>A simple discourse node template.
</noinclude>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} supports: [[{{PAGENAME}}#{{{supports|}}}|{{{supports|}}}]]

Template:D

2022-11-13T16:07:13Z

Sj:

<noinclude>A simple discourse node template.
</noinclude>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} supports: [#{{{supports|}}} {{{supports|}}}]

Template:D

2022-11-13T15:56:26Z

Sj:

<noinclude>A simple discourse node template.
</noinclude><a href="#{{{id}}}" />{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} supports: <a href="#{{{supports|}}}" style="color:green">{{{supports|}}}</a>

Template:D

2022-11-13T15:54:44Z

Sj:

<noinclude>A simple discourse node template.
</noinclude><a href="{{{id}}}" />{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} supports: <a href="{{{supports|}}}" style="color:green">{{{supports|}}}</a>

Template:D

2022-11-13T15:54:01Z

Sj: link

<noinclude>A simple discourse node template.
</noinclude><a href="{{{id}}}"/>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} supports: <a href="{{{supports|}}}" style="color:green">{{{supports|}}}</a>

Template talk:D

2022-11-13T15:44:06Z

Sj: Created page with "!!"

Template:D

2022-11-13T15:44:01Z

Sj:

<noinclude>A simple discourse node template.
</noinclude>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} {{{supports|}}}

Template:D

2022-11-13T15:43:26Z

Sj:

<noinclude>Simple discourse node template.
</noinclude>{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} {{{supports|}}}

Template:D

2022-11-13T15:42:09Z

Sj:

<noinclude>Simple discourse node template.</noinclude>

{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} {{{supports|}}}

Template:D

2022-11-13T15:41:48Z

Sj: Created page with "{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} {{{supports|}}}"

{{{id|?}}} [{{{a|?}}}] ''({{{type|node}}})'' {{{text}}} {{{supports|}}}

Talk:Discourse Modeling

2022-11-13T15:28:28Z

Sj: try with {{d}}

Discourse Modeling

2022-11-13T14:54:20Z

Sj: /* Discourse Graphs */

{{Group
|Decription=Implement Discourse Graph schema in Semantic MediaWiki. Query Discourse Graph contents through SMW sparql endpoint. Visualize and publish Discourse Graph contents.
|Topics=Discourse Graphs, SPARQL
|Projects=Federated knowledge synthesis, Making Discourse Graphs Indexable & Discoverable
|Discord Channel Name=#discourse-modeling
|Discord Channel URL=https://discord.com/channels/1029514961782849607/1038988750677606432
|Facilitator=Karola Kirsanow
|Members=Karola Kirsanow, Konrad Hinsen, Kyle MacLaury, Peter Murray-Rust
|Description=Implement Discourse Graph schema in Semantic MediaWiki. Query Discourse Graph contents through SMW sparql endpoint. Visualize and publish Discourse Graph contents.
}}
== What are we discussing? ==

It could be really valuable to try to prototype a "computable" synthesis of the knowledge in this workshop here in the wiki. One test of the "computability" would be to make it visualizable.

Could have applications to the semantic climate setting that [[Peter Murray-Rust]] is working on.

[[File:Results graph.png|thumb|the results graph - Matt Akamatsu's DG dialect for experimental science]]

== Discourse Graphs ==
[[File:Discourse Graph.png|thumb|Discourse Graph (from Joel Chan)]]
We're focusing on implementing [https://oasis-lab.gitbook.io/roamresearch-discourse-graph-extension/ the Discourse Graph Datamodel] in a wiki to see if we can make further progress on enabling and supporting synthesis, discovery, and dissemination by building upon models that have already demonstrated success.<blockquote>From our chat yesterday: I'd like to propose adding <code>Axiom</code>s and adding relationships to <code>Source</code>s. Is there a way to do this on the oasis-lab spec?</blockquote>[[File:The discourse graph quadruplet.png|thumb|The discourse graph quadruplet]]

== Now you're playing with templates ==
* <tt>{{</tt><tt> [[:template:source|Source]]}} </tt> template : URL, publisher, publisher-url, date, author, title

{{source
| url = https://synthesis-infrastructures.wiki/Discourse_Modeling
| publisher = Synthesis Infrastructures wiki
| publisher-url = https://synthesis-infrastructures.wiki/index.php?title=Discourse_Modeling
| date = 2022-11-12
| author = Sj
| title = Discourse modeling templates}}

* Claim :
* Axiom (?) :

[[:Category:Discourse graph templates|Discourse Graph templates]]

== Potential Actions ==
* Implement the Discourse Graph schema within the workshop's Semantic MediaWiki instance
** [[Making Discourse Graphs Indexable & Discoverable]] is a sub-project relevant to this group
* [[Incorporate models/algorithms into Semantic MediaWiki]]
* [[Access discourse and knowledge representations in the SMW instance]]
* Compute with the returned data
** potentially using models/algorithms from the wiki
* Visualize the results of the computation
* Publish the visualizations back to the SMW instance
* Assess suitability of Discourse Graphs for federation ([[Federated knowledge synthesis|Federated Knowledge Synthesis]])

=== Modules ===
Technical aspects of the project
* [[Semantic MediaWiki]]
** Front End
*** Embed CloudObjects from Wolfram Cloud
*** User chooses model and specifies input parameters
*** User applies model to input parameters
**** Call API that executes
** rdf database
*** [[SPARQL]] endpoint
* Wolfram Cloud
** Use [https://reference.wolfram.com/language/GraphStore/ref/SPARQLExecute.html SPARQLExecute] to call the SPARQL endpoint
** Apply Model to query results
** Publish visualizations as CloudObjects
** Publish API that executes model/algorithm

== Workshop Goals ==

# Implement the Discourse Graph schema within the workshop's Semantic MediaWiki instance
## create templates for nodes
## understand how to type relationships
## prototype naming conventions
# Create a few example Discourse Graphs, drawing on content and conversations generated during the workshop
# Make the Discourse Graphs contained on the wiki visualizable and queryable through the Semantic Mediawiki SPARQL endpoint, as described above
# Document our process and create a guide to making wiki-supported Discourse Graphs

== Progress as of Day 1 ==

* We aligned on a workplan that largely harmonizes with the goals formulated before the workshop and integrates as many objectives from [[Making Discourse Graphs Indexable & Discoverable]] and [[Federated knowledge synthesis]] as feasible.
** We want to bootstrap a simple entrypoint into Discourse Graph construction, complete with example graphs, from a more familiar wiki environment.
** We hope to design a system that is compatible with later efforts at DG federation.
** We discussed the approaches to naming and conflict resolution employed by [https://anagora.org/agora an agora] and [https://everything2.com/?node=patriotism everything2].
* We decided to focus first on the problems of ''naming'' and ''schemas''; beginning with designing templates for '''nodes''' and a wiki-friendly implementation of '''relations'''.
** We discussed the relative advantages and constraints of MW v SMW.
** We aligned on the criticality of naming to enable effective querying
** We decided that we should also develop names for frequent queries.
* We sketched a system for capturing and transforming conversations on this wiki into graphs, putting the "discourse" back into "Discourse Graphs"
** We made a first pass at designing templates for '''sources''', '''evidence''', '''claims''', and '''questions'''
** We discussed for the page relations enabled by SMW could be used to create DG edges.
* We annotated this page's [[Talk:Discourse Modeling|Discussion]] using simple DG syntax to experiment with transforming a "live" conversation into a DG

== Progress as of Day 2 ==

== Observations & Open Problems ==

* We immediately realized that we had seen very few Discourse Graphs "in the wild": the model makes intuitive sense in single player and small-group mode in Roam & Obsidian, but how gracefully will it scale to massively multiplayer synthesis?
** There are at least two possible models here: public-first writing in online mode (wiki, Roam) and local-first writing +push, probably via git. UX and conflict resolution will differ in these models.
* How to design with a federated future in mind?
** What does it mean for distinct graphs to share nodes? to "live" in adjacent namespaces?
* The challenge of using a wiki like git: simultaneous editing seems more cumbersome
* If creating templates is a large part of the work, more powerful text editing & transformation capabilities (e.g. sed, pandoc) seem in order
* Need to create a consistent way of sharing and editing templates - how do template changes propagate in a future federated system?
* Will graph visualization scale in a useful manner? How will traversal work?
* The relationship between naming and clustering: how do we name groups of related hypotheses? A family of experiments?
* Questions regarding feasible & appropriate levels of automation 

== Relevant Projects and Ideas ==

* [https://anagora.org/agora Agora]
* [https://everything2.com/ everything2]
* [https://cosma.graphlab.fr/en/ Cosma]
* Obsidian
* Roam
* Logseq
* [https://zettlr.com/ Zettlr]
* [https://tana.inc/ Tana]
* Kumu
* [https://discoursegraph.com The Discourse Graph Starter pack]
* [https://gtoolkit.com/components/lepiter/ Lepiter]

==Example Discourse==
[[Why do we expect increased concentrations of atmospheric carbon dioxide to change the climate?]]

==Example Discourse Graphs==
* [https://publish.obsidian.md/joelchan-notes/README Joel Chan's working notes]
* [https://civicdb.org/assertions/home CIViC] (Clinical Interpretation of Variance in Cancer]

==Tools==

[[Download SMW rdf data]]

[[Import SMW .jsonld as RDFStore in Wolfram Language]]

[[Example SPARQL queries in Wolfram Language]]

[[Execute SPARQL query against RDFStore]]
== Discord ==

{{Message
|Author=joelchan86
|Avatar=https://cdn.discordapp.com/avatars/322545403876868096/6dd171845a7a4e30603d98ae510c77b8.png?size=1024
|Date Sent=22-11-10 15:55:39
|Channel=discourse graphs
|Text=we think the problem now is user-friendly tools and workfows that can create discourse graph structures, and have seen some exciting progress across a bunch of new user-facing "personal wikis". but bridging from personal to communal is still a challenge, partially bc of tooling.

this is why i'm excited about the [[Discourse Modeling]] idea, which i sort of understand as a way to try to instantiate something like [[Discourse Graphs]] into a wiki (bc wikis have a lot more in-built affordances for collaboration, such as edit histories, talk pages, etc.), which may hopefully lead to a lower barrier to entry for collaborative discourse graphing.

a high hope is that we can develop a process that is easy enough to understand and implement that can then be applied to discourse graphing the IPCC or similarly large body of research on a focused, contentious, interdisciplinary topic.

other examples include:
- effects of masks on community transmission (can't do decisive RCTs, need to synthesize)
- effects of social media on political (dys)function: (existing crowdsourced lit review here, in traditional narrative form: https://docs.google.com/document/d/1vVAtMCQnz8WVxtSNQev_e1cGmY9rnY96ecYuAj6C548/edit#)
|Link=https://discord.com/channels/1029514961782849607/1040214388554084372/1040293673851691059
}}

Discourse Modeling

2022-11-12T16:54:20Z