Synthesis Infrastructures - User contributions [en]

Discourse Modeling

2022-11-13T14:48:36Z

Khinsen: /* Relevant Projects and Ideas */

{{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.
[[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<br />

== 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
}}

Talk:Discourse Modeling

2022-11-13T10:33:47Z

Khinsen: /* Getting started on our own Discourse Graph */ more tags

== 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====
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
==== Federated Knowledge Synthesis ====

* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

==== Conflict Resolution ====
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
**[[claim]] in wiki each page has a single version --> federated wiki is the solution
**[[claim]] pages in a federated wiki are more like working in branches as in git
***[[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* KH: [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader --> author transition
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?

==== Version control v Narratives ====

*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
**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-13T10:33:06Z

Khinsen: /* Agora */ a few more tags

== 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====
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
==== Federated Knowledge Synthesis ====

* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

==== Conflict Resolution ====
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
**[[claim]] in wiki each page has a single version --> federated wiki is the solution
**[[claim]] pages in a federated wiki are more like working in branches as in git
***[[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* KH: [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader --> author transition
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?

==== Version control v Narratives ====

*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
**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: prefer many short examples
**SJ: 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-13T10:31:10Z

Khinsen: /* A Discourse Graph for our own Wiki */ rewriting a sentence into a claim - is this permissible in creating a DG?

== 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====
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
==== Federated Knowledge Synthesis ====

* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

==== Conflict Resolution ====
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
**[[claim]] in wiki each page has a single version --> federated wiki is the solution
**[[claim]] pages in a federated wiki are more like working in branches as in git
***[[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* KH: [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader --> author transition
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?

==== Version control v Narratives ====

*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
**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
**each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
**elevate DGs by making a section that tries to generate a DG or discourses that mention this node
*[[claim]] DG is a shape you compile on the fly - could try to generate a DG x steps away and show you different families that might be referencing this
** [[claim]] spirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
*KK: [[question]] diff between agora and what we envision?
**SJ: [[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: prefer many short examples
**SJ: 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-13T10:28:31Z

Khinsen: /* What exactly makes a graph a Discourse Graph? */ add tags

== 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====
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
==== Federated Knowledge Synthesis ====

* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

==== Conflict Resolution ====
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
**[[claim]] in wiki each page has a single version --> federated wiki is the solution
**[[claim]] pages in a federated wiki are more like working in branches as in git
***[[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* KH: [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader --> author transition
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?

==== Version control v Narratives ====

*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
**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
*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
**each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
**elevate DGs by making a section that tries to generate a DG or discourses that mention this node
*[[claim]] DG is a shape you compile on the fly - could try to generate a DG x steps away and show you different families that might be referencing this
** [[claim]] spirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
*KK: [[question]] diff between agora and what we envision?
**SJ: [[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: prefer many short examples
**SJ: 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-13T10:24:28Z

Khinsen: /* Getting started on our own Discourse Graph */

== 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====
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
==== Federated Knowledge Synthesis ====

* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

==== Conflict Resolution ====
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
**[[claim]] in wiki each page has a single version --> federated wiki is the solution
**[[claim]] pages in a federated wiki are more like working in branches as in git
***[[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* KH: [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader --> author transition
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?

==== Version control v Narratives ====

*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
**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
*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
**each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
**elevate DGs by making a section that tries to generate a DG or discourses that mention this node
*[[claim]] DG is a shape you compile on the fly - could try to generate a DG x steps away and show you different families that might be referencing this
** [[claim]] spirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
*KK: [[question]] diff between agora and what we envision?
**SJ: [[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: prefer many short examples
**SJ: 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: what do you do when your discourse does not fit a DG?
***examples from physics with no well-posed question
**discussion of results graphs and requests for experiments
**need to figure out how DGs work in these different fields and circumstances
**SJ: meta: need to identify existing discourse maps, and existing graphs, that could be thought of as DGs (proofs, discourse diagrams, text summarization graphs, argument maps, decision maps + flowcharts, ...)
*
**SJ: need to capture axioms / assumptions
**KH: making tacit knowledge explicit!!
*

== Section 3 Kyle ==
*
* - decision: start with naming & schemas first
* - do we start with a schema or refine as we go?
* - sj: smw makes this hard for exactly this reason
* - easier with free form wiki templates and wiki text
* - tiny Lua templates (don't need to write Lua)
* - define any number of fields
* - define how they are presented
* - this is just mediawiki w/o the semantic extension
* - make a mediawiki entry for every thing that has a shape
* - edit that v flexibly, schema changes won't break things, won't cascade illegibility
* - at scale: smw wiki extension enables multiple dynamic table updates as data changes
* - KK: question: problem extending to smw later?
* - no
* - not as long as template is compatible with smw
* - we can do this by hand - dozen schemas
* - we can then decide whether we want to do smw or use wikidata & their respective modelling tradeoffs
* - start with creating a "source" template: source: url, publisher, date, author ?
* - kk: [[question]] will defining edges/relationships turn out to be more complicated than creating templates for nodes?
* - KK: how do we know when we are done?
* - SJ: need to create an internally consistent way of sharing templates
* - kH: templates are universally available, which means that anyone can break our template
* - KM: should we decompose the Q into further properties (like a Q has a subject and object) or leave it nat language
* - KH: we should stick to nat language
* - KH: if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page?
* - KM: seems like everything is a page?
* - sj: sections of a page are not a page
* - sj: everything we want to be a node should be a page
* - sj: wiki supports transclusion
* - kh: then each pp needs a title - lots of work
* - sj: this is a q iof interfaces - we can do it this way for a demo
* - KH: makes the history list a bit busy - this is a ux question affecting exploration
* - KK: many to many relationships between sources & evidence
* - source property could be a url and we could create an entity for the source that scrapes data and populates fields
* - if you expect something will be used more than once you probably want it to have the full data
* - sj: claim: this level of precision is important to dgs
* - sj: claim wiki recent changes scale well
* - sj: we can use wikibase to scale ux issues and hide certain types of history (eg source edits)
* - KH: first attempt: everything is a page, we rely on transclusion to group things
* - KH: can we have the entire Q as a page title?
* - sj: this gets to my interest, naming
* - sj: a great next step would be intifying a discussion wewant to capture
*

Talk:Discourse Modeling

2022-11-13T10:21:42Z

Khinsen: /* Agora */ More fixes, a few more tags

== 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====
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
==== Federated Knowledge Synthesis ====

* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

==== Conflict Resolution ====
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
**[[claim]] in wiki each page has a single version --> federated wiki is the solution
**[[claim]] pages in a federated wiki are more like working in branches as in git
***[[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* KH: [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader --> author transition
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?

==== Version control v Narratives ====

*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
**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
*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
**each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
**elevate DGs by making a section that tries to generate a DG or discourses that mention this node
*[[claim]] DG is a shape you compile on the fly - could try to generate a DG x steps away and show you different families that might be referencing this
** [[claim]] spirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
*KK: [[question]] diff between agora and what we envision?
**SJ: [[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:what actions will we need to take to get where we want to go?
**how do we turn parts of this wiki into the components of a DG?
**KM: we have folks write and annotate in the wiki and use the annotation capabilities of SMW to call out what the node types are
**getting the data into the wiki is literally people interacting and annotating
**but first we need to figure out naming and schema
**template objects, other objects, tools that can be used to define the schema
**KH: prefer many short examples
**SJ: like the idea of a self-referential discourse about the state of DGs

=== 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: what do you do when your discourse does not fit a DG?
***examples from physics with no well-posed question
**discussion of results graphs and requests for experiments
**need to figure out how DGs work in these different fields and circumstances
**SJ: meta: need to identify existing discourse maps, and existing graphs, that could be thought of as DGs (proofs, discourse diagrams, text summarization graphs, argument maps, decision maps + flowcharts, ...)
*
**SJ: need to capture axioms / assumptions
**KH: making tacit knowledge explicit!!
*

== Section 3 Kyle ==
*
* - decision: start with naming & schemas first
* - do we start with a schema or refine as we go?
* - sj: smw makes this hard for exactly this reason
* - easier with free form wiki templates and wiki text
* - tiny Lua templates (don't need to write Lua)
* - define any number of fields
* - define how they are presented
* - this is just mediawiki w/o the semantic extension
* - make a mediawiki entry for every thing that has a shape
* - edit that v flexibly, schema changes won't break things, won't cascade illegibility
* - at scale: smw wiki extension enables multiple dynamic table updates as data changes
* - KK: question: problem extending to smw later?
* - no
* - not as long as template is compatible with smw
* - we can do this by hand - dozen schemas
* - we can then decide whether we want to do smw or use wikidata & their respective modelling tradeoffs
* - start with creating a "source" template: source: url, publisher, date, author ?
* - kk: [[question]] will defining edges/relationships turn out to be more complicated than creating templates for nodes?
* - KK: how do we know when we are done?
* - SJ: need to create an internally consistent way of sharing templates
* - kH: templates are universally available, which means that anyone can break our template
* - KM: should we decompose the Q into further properties (like a Q has a subject and object) or leave it nat language
* - KH: we should stick to nat language
* - KH: if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page?
* - KM: seems like everything is a page?
* - sj: sections of a page are not a page
* - sj: everything we want to be a node should be a page
* - sj: wiki supports transclusion
* - kh: then each pp needs a title - lots of work
* - sj: this is a q iof interfaces - we can do it this way for a demo
* - KH: makes the history list a bit busy - this is a ux question affecting exploration
* - KK: many to many relationships between sources & evidence
* - source property could be a url and we could create an entity for the source that scrapes data and populates fields
* - if you expect something will be used more than once you probably want it to have the full data
* - sj: claim: this level of precision is important to dgs
* - sj: claim wiki recent changes scale well
* - sj: we can use wikibase to scale ux issues and hide certain types of history (eg source edits)
* - KH: first attempt: everything is a page, we rely on transclusion to group things
* - KH: can we have the entire Q as a page title?
* - sj: this gets to my interest, naming
* - sj: a great next step would be intifying a discussion wewant to capture
*

Talk:Discourse Modeling

2022-11-13T10:19:04Z

Khinsen: Fix typo

== 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====
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
==== Federated Knowledge Synthesis ====

* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

==== Conflict Resolution ====
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
**[[claim]] in wiki each page has a single version --> federated wiki is the solution
**[[claim]] pages in a federated wiki are more like working in branches as in git
***[[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* KH: [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader --> author transition
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?

==== Version control v Narratives ====

*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
**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
*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
**each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
**elevate DGs by making a section that tries to generate a DG or discourses that mention this node
*[[claim]] DG is a shape you compile on the fly - could try to generate a DG x steps away and show you different families that might be referencing this
** [[claim]] spirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
***KK: [[question]] diff between agora and what we envision?
**sj: no typology of links
**graph visualization does not ignore non-typed connections
**KH: existing descriptions of agora other than the site itself?

=== Getting started on our own [[Discourse Graph]] ===

**KK:what actions will we need to take to get where we want to go?
**how do we turn parts of this wiki into the components of a DG?
**KM: we have folks write and annotate in the wiki and use the annotation capabilities of SMW to call out what the node types are
**getting the data into the wiki is literally people interacting and annotating
**but first we need to figure out naming and schema
**template objects, other objects, tools that can be used to define the schema
**KH: prefer many short examples
**SJ: like the idea of a self-referential discourse about the state of DGs

=== 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: what do you do when your discourse does not fit a DG?
***examples from physics with no well-posed question
**discussion of results graphs and requests for experiments
**need to figure out how DGs work in these different fields and circumstances
**SJ: meta: need to identify existing discourse maps, and existing graphs, that could be thought of as DGs (proofs, discourse diagrams, text summarization graphs, argument maps, decision maps + flowcharts, ...)
*
**SJ: need to capture axioms / assumptions
**KH: making tacit knowledge explicit!!
*

== Section 3 Kyle ==
*
* - decision: start with naming & schemas first
* - do we start with a schema or refine as we go?
* - sj: smw makes this hard for exactly this reason
* - easier with free form wiki templates and wiki text
* - tiny Lua templates (don't need to write Lua)
* - define any number of fields
* - define how they are presented
* - this is just mediawiki w/o the semantic extension
* - make a mediawiki entry for every thing that has a shape
* - edit that v flexibly, schema changes won't break things, won't cascade illegibility
* - at scale: smw wiki extension enables multiple dynamic table updates as data changes
* - KK: question: problem extending to smw later?
* - no
* - not as long as template is compatible with smw
* - we can do this by hand - dozen schemas
* - we can then decide whether we want to do smw or use wikidata & their respective modelling tradeoffs
* - start with creating a "source" template: source: url, publisher, date, author ?
* - kk: [[question]] will defining edges/relationships turn out to be more complicated than creating templates for nodes?
* - KK: how do we know when we are done?
* - SJ: need to create an internally consistent way of sharing templates
* - kH: templates are universally available, which means that anyone can break our template
* - KM: should we decompose the Q into further properties (like a Q has a subject and object) or leave it nat language
* - KH: we should stick to nat language
* - KH: if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page?
* - KM: seems like everything is a page?
* - sj: sections of a page are not a page
* - sj: everything we want to be a node should be a page
* - sj: wiki supports transclusion
* - kh: then each pp needs a title - lots of work
* - sj: this is a q iof interfaces - we can do it this way for a demo
* - KH: makes the history list a bit busy - this is a ux question affecting exploration
* - KK: many to many relationships between sources & evidence
* - source property could be a url and we could create an entity for the source that scrapes data and populates fields
* - if you expect something will be used more than once you probably want it to have the full data
* - sj: claim: this level of precision is important to dgs
* - sj: claim wiki recent changes scale well
* - sj: we can use wikibase to scale ux issues and hide certain types of history (eg source edits)
* - KH: first attempt: everything is a page, we rely on transclusion to group things
* - KH: can we have the entire Q as a page title?
* - sj: this gets to my interest, naming
* - sj: a great next step would be intifying a discussion wewant to capture
*

Talk:Discourse Modeling

2022-11-13T10:04:09Z

Khinsen: Participant list

== 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====
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
==== Federated Knowledge Synthesis ====

* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

==== Conflict Resolution ====
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
**[[claim]] in wiki each page has a single version --> federated wiki is the solution
**[[claim]] pages in a federated wiki are more like working in branches as in git
***[[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* KH: [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader --> author transition
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?

==== Version control v Narratives ====

*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
**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
*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
**each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
**elevate DGs by making a section that tries to generate a DG or discourses that mention this node
*[[claim]] DG is a shape you compile on the fly - could try to generate a DG x steps away and show you different families that might be referencing this
** [[claim] spirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
***KK: [[question]] diff between agora and what we envision?
**sj: no typology of links
**graph visualization does not ignore non-typed connections
**KH: existing descriptions of agora other than the site itself?

=== Getting started on our own [[Discourse Graph]] ===

**KK:what actions will we need to take to get where we want to go?
**how do we turn parts of this wiki into the components of a DG?
**KM: we have folks write and annotate in the wiki and use the annotation capabilities of SMW to call out what the node types are
**getting the data into the wiki is literally people interacting and annotating
**but first we need to figure out naming and schema
**template objects, other objects, tools that can be used to define the schema
**KH: prefer many short examples
**SJ: like the idea of a self-referential discourse about the state of DGs

=== 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: what do you do when your discourse does not fit a DG?
***examples from physics with no well-posed question
**discussion of results graphs and requests for experiments
**need to figure out how DGs work in these different fields and circumstances
**SJ: meta: need to identify existing discourse maps, and existing graphs, that could be thought of as DGs (proofs, discourse diagrams, text summarization graphs, argument maps, decision maps + flowcharts, ...)
*
**SJ: need to capture axioms / assumptions
**KH: making tacit knowledge explicit!!
*

== Section 3 Kyle ==
*
* - decision: start with naming & schemas first
* - do we start with a schema or refine as we go?
* - sj: smw makes this hard for exactly this reason
* - easier with free form wiki templates and wiki text
* - tiny Lua templates (don't need to write Lua)
* - define any number of fields
* - define how they are presented
* - this is just mediawiki w/o the semantic extension
* - make a mediawiki entry for every thing that has a shape
* - edit that v flexibly, schema changes won't break things, won't cascade illegibility
* - at scale: smw wiki extension enables multiple dynamic table updates as data changes
* - KK: question: problem extending to smw later?
* - no
* - not as long as template is compatible with smw
* - we can do this by hand - dozen schemas
* - we can then decide whether we want to do smw or use wikidata & their respective modelling tradeoffs
* - start with creating a "source" template: source: url, publisher, date, author ?
* - kk: [[question]] will defining edges/relationships turn out to be more complicated than creating templates for nodes?
* - KK: how do we know when we are done?
* - SJ: need to create an internally consistent way of sharing templates
* - kH: templates are universally available, which means that anyone can break our template
* - KM: should we decompose the Q into further properties (like a Q has a subject and object) or leave it nat language
* - KH: we should stick to nat language
* - KH: if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page?
* - KM: seems like everything is a page?
* - sj: sections of a page are not a page
* - sj: everything we want to be a node should be a page
* - sj: wiki supports transclusion
* - kh: then each pp needs a title - lots of work
* - sj: this is a q iof interfaces - we can do it this way for a demo
* - KH: makes the history list a bit busy - this is a ux question affecting exploration
* - KK: many to many relationships between sources & evidence
* - source property could be a url and we could create an entity for the source that scrapes data and populates fields
* - if you expect something will be used more than once you probably want it to have the full data
* - sj: claim: this level of precision is important to dgs
* - sj: claim wiki recent changes scale well
* - sj: we can use wikibase to scale ux issues and hide certain types of history (eg source edits)
* - KH: first attempt: everything is a page, we rely on transclusion to group things
* - KH: can we have the entire Q as a page title?
* - sj: this gets to my interest, naming
* - sj: a great next step would be intifying a discussion wewant to capture
*

Talk:Discourse Modeling

2022-11-13T09:57:51Z

Khinsen: Fix typos, standardize abbreviations

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
==== Federated Knowledge Synthesis ====

* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

==== Conflict Resolution ====
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
**[[claim]] in wiki each page has a single version --> federated wiki is the solution
**[[claim]] pages in a federated wiki are more like working in branches as in git
***[[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* KH: [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader --> author transition
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?

==== Version control v Narratives ====

*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
**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
*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
**each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
**elevate DGs by making a section that tries to generate a DG or discourses that mention this node
*[[claim]] DG is a shape you compile on the fly - could try to generate a DG x steps away and show you different families that might be referencing this
** [[claim] spirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
***KK: [[question]] diff between agora and what we envision?
**sj: no typology of links
**graph visualization does not ignore non-typed connections
**KH: existing descriptions of agora other than the site itself?

=== Getting started on our own [[Discourse Graph]] ===

**KK:what actions will we need to take to get where we want to go?
**how do we turn parts of this wiki into the components of a DG?
**KM: we have folks write and annotate in the wiki and use the annotation capabilities of SMW to call out what the node types are
**getting the data into the wiki is literally people interacting and annotating
**but first we need to figure out naming and schema
**template objects, other objects, tools that can be used to define the schema
**KH: prefer many short examples
**SJ: like the idea of a self-referential discourse about the state of DGs

=== 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: what do you do when your discourse does not fit a DG?
***examples from physics with no well-posed question
**discussion of results graphs and requests for experiments
**need to figure out how DGs work in these different fields and circumstances
**SJ: meta: need to identify existing discourse maps, and existing graphs, that could be thought of as DGs (proofs, discourse diagrams, text summarization graphs, argument maps, decision maps + flowcharts, ...)
*
**SJ: need to capture axioms / assumptions
**KH: making tacit knowledge explicit!!
*

== Section 3 Kyle ==
*
* - decision: start with naming & schemas first
* - do we start with a schema or refine as we go?
* - sj: smw makes this hard for exactly this reason
* - easier with free form wiki templates and wiki text
* - tiny Lua templates (don't need to write Lua)
* - define any number of fields
* - define how they are presented
* - this is just mediawiki w/o the semantic extension
* - make a mediawiki entry for every thing that has a shape
* - edit that v flexibly, schema changes won't break things, won't cascade illegibility
* - at scale: smw wiki extension enables multiple dynamic table updates as data changes
* - KK: question: problem extending to smw later?
* - no
* - not as long as template is compatible with smw
* - we can do this by hand - dozen schemas
* - we can then decide whether we want to do smw or use wikidata & their respective modelling tradeoffs
* - start with creating a "source" template: source: url, publisher, date, author ?
* - kk: [[question]] will defining edges/relationships turn out to be more complicated than creating templates for nodes?
* - KK: how do we know when we are done?
* - SJ: need to create an internally consistent way of sharing templates
* - kH: templates are universally available, which means that anyone can break our template
* - KM: should we decompose the Q into further properties (like a Q has a subject and object) or leave it nat language
* - KH: we should stick to nat language
* - KH: if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page?
* - KM: seems like everything is a page?
* - sj: sections of a page are not a page
* - sj: everything we want to be a node should be a page
* - sj: wiki supports transclusion
* - kh: then each pp needs a title - lots of work
* - sj: this is a q iof interfaces - we can do it this way for a demo
* - KH: makes the history list a bit busy - this is a ux question affecting exploration
* - KK: many to many relationships between sources & evidence
* - source property could be a url and we could create an entity for the source that scrapes data and populates fields
* - if you expect something will be used more than once you probably want it to have the full data
* - sj: claim: this level of precision is important to dgs
* - sj: claim wiki recent changes scale well
* - sj: we can use wikibase to scale ux issues and hide certain types of history (eg source edits)
* - KH: first attempt: everything is a page, we rely on transclusion to group things
* - KH: can we have the entire Q as a page title?
* - sj: this gets to my interest, naming
* - sj: a great next step would be intifying a discussion wewant to capture
*

Talk:Discourse Modeling

2022-11-13T09:48:18Z

Khinsen: Subsections

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
==== Federated Knowledge Synthesis ====

* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

==== Conflict Resolution ====
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
**[[claim]] in wiki each page has a single version --> federated wiki is the solution
**[[claim]] pages in a federated wiki are more like working in branches as in git
***[[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* KH: [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader --> author transition
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?

==== Version control v Narratives ====

*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
**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 related to claims, how are claims informed by different articles (evidence)
*[[claim]] need to populate the wiki with the elements of a discourse graph --> create viz --> share code
*SJ: [[question]] can we accomplish naming: coming up with names for each of those components, and names for things at different scales - discussion, family of hypotheses, family of experiments
**[[claim]] this will allow us to say that if you have identified x ideas, hypotheses, etc - how many discourses do you need to describe? how many graphs are needed to illustrate those discourses - when are people working on the same graph?
**[[question]] what does it mean to have different graphs that share some pieces, or different graphs in or close to the same namespace
**[[claim]] these issues --> boil down to the naming of the pieces and how you place the connections - how much context do you need to figure out how many connections there are?
*KM: taking this as an opportunity to learn SPARQL
*KM: [[claim]] we need namespaces before we can query anything - naming is critical!
*SJ: [[claim]] we should name and make list of queries - queries nee 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
**each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
**elevate DGs by making a section that tries to generate a dg or discourses that mention this node
*[[claim]] dg is a shape you compile on the fly - could try to generate a dg x steps away and show you different families that might be referencing this
** [[claim]s pirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
***KK: [[question]] diff between agora and what we envision?
**sj: no typology of links
**graph visualization does not ignore non-typed connections
**KH: existing descriptions of agora other than the site itself?

=== Getting started on our own [[Discourse Graph]] ===
**KK:what actions will we need to take to get where we want to go?
**how do we turn parts of this wiki into the components of a dg?
**KM: we have folks write and annotate in the wiki and use the annotation capabiliies of SMW to call out what the node types are
**getting the data into the wiki is literally people interacting and annotating
**but first we need to figure out naming and schema
**template objects, other objects, tools that can be used to define the schema
**KH: prefer many short examples
**SJ: like the idea of a self-referntial discourse about the state of discourse graphs

=== What exactly makes a graph a [[Discourse Graph]]? ===
**question: can a discourse be a bout a topic? are discourses about a certtain over-arching hypothesis where you make claims and discover evidence?
**KH: what do you do when your discourse does not fit a Dg?
**examples from physics with no well-posed question)
**discussion of results graphs and requests for experiments)
**need to figure out how DGs work in these differnt fields and circumstances
**sj: meta: need to identify existing discourse maps, and existing graphs, that could be thought of as d.g.s
**proofs, discourse diagrams, text summarization graphs, argument maps, decision maps + flowcharts, ...)
*
**sj: need to capture axioms / assumptions
**kh: making tacit knowledge explicit!!
*

== Section 3 Kyle ==
*
* - decision: start with naming & schemas first
* - do we start with a schema or refine as we go?
* - sj: smw makes this hard for exactly this reason
* - easier with free form wiki templates and wiki text
* - tiny Lua templates (don't need to write Lua)
* - define any number of fields
* - define how they are presented
* - this is just mediawiki w/o the semantic extension
* - make a mediawiki entry for every thing that has a shape
* - edit that v flexibly, schema changes won't break things, won't cascade illegibility
* - at scale: smw wiki extension enables multiple dynamic table updates as data changes
* - KK: question: problem extending to smw later?
* - no
* - not as long as template is compatible with smw
* - we can do this by hand - dozen schemas
* - we can then decide whether we want to do smw or use wikidata & their respective modelling tradeoffs
* - start with creating a "source" template: source: url, publisher, date, author ?
* - kk: [[question]] will defining edges/relationships turn out to be more complicated than creating templates for nodes?
* - KK: how do we know when we are done?
* - SJ: need to create an internally consistent way of sharing templates
* - kH: templates are universally available, which means that anyone can break our template
* - KM: should we decompose the Q into further properties (like a Q has a subject and object) or leave it nat language
* - KH: we should stick to nat language
* - KH: if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page?
* - KM: seems like everything is a page?
* - sj: sections of a page are not a page
* - sj: everything we want to be a node should be a page
* - sj: wiki supports transclusion
* - kh: then each pp needs a title - lots of work
* - sj: this is a q iof interfaces - we can do it this way for a demo
* - KH: makes the history list a bit busy - this is a ux question affecting exploration
* - KK: many to many relationships between sources & evidence
* - source property could be a url and we could create an entity for the source that scrapes data and populates fields
* - if you expect something will be used more than once you probably want it to have the full data
* - sj: claim: this level of precision is important to dgs
* - sj: claim wiki recent changes scale well
* - sj: we can use wikibase to scale ux issues and hide certain types of history (eg source edits)
* - KH: first attempt: everything is a page, we rely on transclusion to group things
* - KH: can we have the entire Q as a page title?
* - sj: this gets to my interest, naming
* - sj: a great next step would be intifying a discussion wewant to capture
*

Agora

2022-11-13T09:41:15Z

Khinsen: New page

https://anagora.org/agora?q=Agora

Talk:Discourse Modeling

2022-11-13T09:16:58Z

Khinsen: First cleanup pass on formatting

== Section 1 KK ==
=== Squad goals: ===
==== Building Queries====
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
==== Federated Knowledge Synthesis ====

* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

==== Conflict Resolution ====
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
**[[claim]] in wiki each page has a single version --> federated wiki is the solution
**[[claim]] pages in a federated wiki are more like working in branches as in git
***[[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* KH: [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start out by creating DGs to which readers will respond. We should consider the reader --> author transition
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?

==== Version control v Narratives ====

*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives?
**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 ==
*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 related to claims, how are claims informed by different articles (evidence)
*[[claim]] need to populate the wiki with the elements of a discourse graph --> create viz --> share code
*SJ: [[question]] can we accomplish naming: coming up with names for each of those components, and names for things at different scales - discussion, family of hypotheses, family of experiments
**[[claim]] this will allow us to say that if you have identified x ideas, hypotheses, etc - how many discourses do you need to describe? how many graphs are needed to illustrate those discourses - when are people working on the same graph?
**[[question]] what does it mean to have different graphs that share some pieces, or different graphs in or close to the same namespace
**[[claim]] these issues --> boil down to the naming of the pieces and how you place the connections - how much context do you need to figure out how many connections there are?
*KM: taking this as an opportunity to learn SPARQL
*KM: [[claim]] we need namespaces before we can query anything - naming is critical!
*SJ: [[claim]] we should name and make list of queries - queries nee their own names
*KM: [[question]] what is agora?
*SJ: [[claim]] agora is a group of people interested in wiki linking and editable networks & knowledge federation
**[[claim]] agora's goals include:
***make linking always do something sensible - best effort connection between links
***agora is a url pattern that will try to resolve it
***redirect strings to appropriate resources
***each reader gets a filter - only see certain nodes & connection based on sort preferences
**KM: [[claim]] sounds like auto-complete for knowledge graphs
**each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
**elevate DGs by making a section that tries to generate a dg or discourses that mention this node
*[[claim]] dg is a shape you compile on the fly - could try to generate a dg x steps away and show you different families that might be referencing this
** [[claim]s pirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
***KK: [[question]] diff between agora and what we envision?
**sj: no typology of links
**graph visualization does not ignore non-typed connections
**KH: existing descriptions of agora other than the site itself?
**KK:what actions will we need to take to get where we want to go?
**how do we turn parts of this wiki into the components of a dg?
**KM: we have folks write and annotate in the wiki and use the annotation capabiliies of SMW to call out what the node types are
**getting the data into the wiki is literally people interacting and annotating
**but first we need to figure out naming and schema
**template objects, other objects, tools that can be used to define the schema
**KH: prefer many short examples
**SJ: like the idea of a self-referntial discourse about the state of discourse graphs
**question: can a discourse be a bout a topic? are discourses about a certtain over-arching hypothesis where you make claims and discover evidence?
**KH: what do you do when your discourse does not fit a Dg?
**examples from physics with no well-posed question)
**discussion of results graphs and requests for experiments)
**need to figure out how DGs work in these differnt fields and circumstances
**sj: meta: need to identify existing discourse maps, and existing graphs, that could be thought of as d.g.s
**proofs, discourse diagrams, text summarization graphs, argument maps, decision maps + flowcharts, ...)
*
**sj: need to capture axioms / assumptions
**kh: making tacit knowledge explicit!!
*

== Section 3 Kyle ==
*
* - decision: start with naming & schemas first
* - do we start with a schema or refine as we go?
* - sj: smw makes this hard for exactly this reason
* - easier with free form wiki templates and wiki text
* - tiny Lua templates (don't need to write Lua)
* - define any number of fields
* - define how they are presented
* - this is just mediawiki w/o the semantic extension
* - make a mediawiki entry for every thing that has a shape
* - edit that v flexibly, schema changes won't break things, won't cascade illegibility
* - at scale: smw wiki extension enables multiple dynamic table updates as data changes
* - KK: question: problem extending to smw later?
* - no
* - not as long as template is compatible with smw
* - we can do this by hand - dozen schemas
* - we can then decide whether we want to do smw or use wikidata & their respective modelling tradeoffs
* - start with creating a "source" template: source: url, publisher, date, author ?
* - kk: [[question]] will defining edges/relationships turn out to be more complicated than creating templates for nodes?
* - KK: how do we know when we are done?
* - SJ: need to create an internally consistent way of sharing templates
* - kH: templates are universally available, which means that anyone can break our template
* - KM: should we decompose the Q into further properties (like a Q has a subject and object) or leave it nat language
* - KH: we should stick to nat language
* - KH: if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page?
* - KM: seems like everything is a page?
* - sj: sections of a page are not a page
* - sj: everything we want to be a node should be a page
* - sj: wiki supports transclusion
* - kh: then each pp needs a title - lots of work
* - sj: this is a q iof interfaces - we can do it this way for a demo
* - KH: makes the history list a bit busy - this is a ux question affecting exploration
* - KK: many to many relationships between sources & evidence
* - source property could be a url and we could create an entity for the source that scrapes data and populates fields
* - if you expect something will be used more than once you probably want it to have the full data
* - sj: claim: this level of precision is important to dgs
* - sj: claim wiki recent changes scale well
* - sj: we can use wikibase to scale ux issues and hide certain types of history (eg source edits)
* - KH: first attempt: everything is a page, we rely on transclusion to group things
* - KH: can we have the entire Q as a page title?
* - sj: this gets to my interest, naming
* - sj: a great next step would be intifying a discussion wewant to capture
*

Discourse Modeling

2022-11-13T08:25:57Z

Khinsen: Add two example discourse graphs

Everything2

2022-11-12T15:45:17Z

Khinsen: Created page with "https://everything2.com/"

https://everything2.com/

Federated knowledge synthesis

2022-11-12T15:44:33Z

Khinsen:

* Part of: [[Part of::Discourse Modeling]]
* Contributors
** [[Has Contributor::Konrad Hinsen]]

Knowledge production starts with the work of individuals and teams. Such contributions are then refined and synthesized in topical communities, disciplines, and other higher-level organizational structures. A big challenge at each move to a higher organizational level is the divergent jargon and terminology of the lower-level entities that wish to join forces. Sometimes there is one dominant entity that ends up imposing its choices. This is arguably not the best way to proceed, and not even an option in more egalitarian settings. Common vocabulary (including semantics in formal systems) can only emerge by consensus, a process that is poorly supported by digital knowledge management tools.

One idea for supporting collaboration in spite of divergence, and ultimately consensus formation, is ''federation''. The general idea is to establish "informational meeting points" where each entity exposes its vocabulary in a structured fashion, making divergent definitions explicit and easy to find and compare. Participants can then switch to someone else's definition if they consider it more appropriate, making a step towards consensus (which however may never be complete).

The goals of this project (perhaps better called a meta-project) are:

* Identify existing technology (tools, data models and formats, protocols, ...) that look promising to support a federated mode of knowledge synthesis. Examples: [[Fedwiki]], [[anagora]], [[everything2]]

* Support projects that improve and extend existing technology. Such support includes providing feedback on each other's work, testing each other's tools, etc. In short: apply the federation idea to develop better infrastructure for federated knowledge synthesis, in a multi-disciplinary setting.

* Think about the social structures that are desirable for consensus formation, and ensure that the technological infrastructure supports them (never forget [[Conway's law]]!)

[[Category:Project]]

Discourse Modeling

2022-11-12T09:16:23Z

Khinsen: Add myself

Interfaces

2022-11-12T08:51:13Z

Khinsen: Add myself

{{Group
|Decription=How do we support richer forms of synthesis-oriented interaction with the existing bodies of research that transcend publications as the unit?
|Topics=Documents, HCI
|Discord Channel Name=#interfaces
|Discord Channel URL=https://discord.com/channels/1029514961782849607/1040386439575240704
|Facilitator=Jodi Schneider
|Members=Elianna DeSota, Jay Patel, Jodi Schneider, Jordan Wick, Joseph Chee Chang, Pao Siangliulue, Pooja Upadhyay, Konrad Hinsen
}}
[[Category:Group]]

== What ==

How do we support richer forms of synthesis-oriented interaction with the existing bodies of research that transcend publications as the unit?

Related to:
* [[Related To::HCI]]

Interdisciplinary Models

2022-11-12T08:50:08Z

Khinsen: Add myself

{{Group
|Decription=How do we define minimal information models tuned for synthesis that can interoperate across various disciplines?
|Topics=Interoperability
|Discord Channel Name=#interdisciplinary-models
|Discord Channel URL=https://discord.com/channels/1029514961782849607/1040385502026682408
|Facilitator=Wayne Lutters
|Members=James Howison, Paul Itoi, Peter Murray-Rust, Wayne Lutters, Konrad Hinsen
}}
== What ==

How do we define minimal information models tuned for synthesis that can interoperate across various disciplines?

Concrete problem expressed by [[Peter-Murray Rust]] here: https://discord.com/channels/1029514961782849607/1040214388554084372/1040299259930611833: "The idea of Hypothesis testing is common in some disciplines, unknown in others. For example chemical synthesis or materials science is "can we make X?" and many sciences are exploratory - what can we see with a new telescope, plants in Antarctica, etc. You have to design your project but I suspect Hypothesis doesn't come into it."

And to a certain extent, the issue of representing/discussing the discourse of computational research (e.g., model parameters), discussed by [[Konrad Hinsen]] here: https://discord.com/channels/1029514961782849607/1038988750677606432/1039576903838859326

This connects also with [[Peter-Murray Rust]]'s work on [[Semantic Climate]] (semantifying the IPCC report).

* see discussion here: https://discord.com/channels/1029514961782849607/1040057721044598788/1040060670907002973
* and here: https://discord.com/channels/1029514961782849607/1033091746139230238/1040226423346040853

And also connects to emerging discussions around interoperability and Surfacing/managing/resolving disagreements in ontologies/terms/federation

Computable Graphs

2022-11-12T08:47:41Z

Khinsen: Add myself

{{Group
|Decription=How to ground knowledge graphs (that can be used for prediction or computational simulation experiments and models) in the discourse and quantitative evidence in scientific literature?
|Topics=Knowledge Graphs
|Projects=Synthesis center for cell biology, Translate Logseq Knowledge Graph to Systems Biology Network Diagrams
|Discord Channel Name=#computable-graphs
|Discord Channel URL=https://discord.com/channels/1029514961782849607/1038983137222467604
|Members=Aakanksha Naik, Akila Wijerathna-Yapa, Deniz Aydemir, Eran Egmon, Joel Chan, Matthew Akamatsu, Michael Gartner, Konrad Hinsen
}}
Facilitator/Point of Contact: [[Has Facilitator::Joel Chan]]

== What ==

How to ground knowledge graphs (that can be used for prediction or computational simulation experiments and models) in the discourse of evidence in scientific literature? How to transition from unstructured literature to knowledge graphs and keep things updated with appropriate provenance for (un)certainty?

== Discussion entry points ==

* [[Matthew Akamatsu]] https://discord.com/channels/1029514961782849607/1033091746139230238/1040212464631029822

== Resources ==

* [[Simularium]] - https://simularium.allencell.org/
* [[Vivarium Collective]] - https://vivarium-collective.github.io/

== Next Steps ==

* don't know if a joint project makes sense, but perhaps coordinated first prototypes of a bridge?

could use:

* someone with programming skills to implement a POC translation between a discourse graph and one of the specific modeling languages/ontologies

Conway's law

2022-11-11T08:28:50Z

Khinsen: Created page with "From the [https://en.wikipedia.org/wiki/Conway%27s_law Wikipedia page on Conway's law]: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. — Melvin E. Conway A specialization to tools yields a famous quote attributed to Marshall McLuhan: First we shape our tools, and then our tools shape us."

From the [https://en.wikipedia.org/wiki/Conway%27s_law Wikipedia page on Conway's law]:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin E. Conway

A specialization to tools yields a famous quote attributed to Marshall McLuhan:

First we shape our tools, and then our tools shape us.

Federated knowledge synthesis

2022-11-11T08:24:07Z

Khinsen: First draft of a project proposition for the workshop

Knowledge production starts with the work of individuals and teams. Such contributions are then refined and synthesized in topical communities, disciplines, and other higher-level organizational structures. A big challenge at each move to a higher organizational level is the divergent jargon and terminology of the lower-level entities that wish to join forces. Sometimes there is one dominant entity that ends up imposing its choices. This is arguably not the best way to proceed, and not even an option in more egalitarian settings. Common vocabulary (including semantics in formal systems) can only emerge by consensus, a process that is poorly supported by digital knowledge management tools.

One idea for supporting collaboration in spite of divergence, and ultimately consensus formation, is ''federation''. The general idea is to establish "informational meeting points" where each entity exposes its vocabulary in a structured fashion, making divergent definitions explicit and easy to find and compare. Participants can then switch to someone else's definition if they consider it more appropriate, making a step towards consensus (which however may never be complete).

The goals of this project (perhaps better called a meta-project) are:

* Identify existing technology (tools, data models and formats, protocols, ...) that look promising to support a federated mode of knowledge synthesis. Examples: [[Fedwiki]], [[anagora]]

* Support projects that improve and extend existing technology. Such support includes providing feedback on each other's work, testing each other's tools, etc. In short: apply the federation idea to develop better infrastructure for federated knowledge synthesis, in a multi-disciplinary setting.

* Think about the social structures that are desirable for consensus formation, and ensure that the technological infrastructure supports them (never forget [[Conway's law]]!)

Project Ideas

2022-11-11T08:04:12Z

Khinsen: /* Linked Data Publishing On Activitypub */

== [[Translate Logseq Knowledge Graph to Systems Biology Network Diagrams]] ==
lead: [[Akila Wijerathna-Yapa]]

= [[Linked Data Publishing On Activitypub]] =

{{Message
|Author=sneakers-the-rat
|Avatar=https://cdn.discordapp.com/avatars/305044217393053697/2970b22bd769d0cd0ee1de79be500e85.png?size=1024
|Date Sent=22-11-03 22:51:30
|Channel=In terms of overlap with my own
|Text=[[Project Ideas#Linked Data Publishing On Activitypub]]

ooh I'm very interested in this. so are you thinking a [[Twitter#Bridge]] -> [[ActivityPub#Bridge]] where one could use markup within the twitter post to declare [[Linked Data#Markup Syntax]] and then post to AP? I have thought about this kind of thing before, like using a bot command syntax to declare prefixes by doing something like
```
@ bot prefix
foaf: https:// (ontology URL)
```
or
```
@ bot alias
term: foaf.LongerNameForTerm
```
so that one could do maybe a semantic wikilink like `[ [term::value] ]` either within the tweet or as a reply to it (so the tweet itself doesn't become cluttered/it can become organized post -hoc?).

I've also thought about a bridge (I called [[Threadodo]] ) that implements that kind of command syntax to be able to directly archive threads to [[Zenodo]] along with structured information about the author, but this seems more interesting.

I can help try and clear some of the groundwork out of the way to make it easier for you and other interested participants to experiment. I have asked around fedi a bunch for a very minimal AP server implementation, and I could try and find one (or we could try and prototype one) if you want to experiment with that :), and I can also document and show you a tweepy-based bot that has an extensible command/parsing system too
|Link=https://discord.com/channels/1029514961782849607/1037786518800039978/1037861609885925467
}}

= [[Making Discourse Graphs Indexable & Discoverable]] =

= [[Federated knowledge synthesis]] =

{{Message
|Author=Konrad Hinsen
|Avatar=https://cdn.discordapp.com/avatars/499904513038090240/343ae17c322fa09b3260f95e58bc4f29.png?size=1024
|Date Sent=22-11-11 05:45:14
|Channel=Thanks sneakers the rat2880 Your site is
|Text=I'll try to turn this thread into [[Project Ideas#Federated knowledge synthesis]]: identify protocols, data models, tools, practices, etc. that can support the process of synthesizing and formalizing scientific knowledge, then build on these ingredients. One dimension is going from narratives via discourse graphs to knowledge graphs. Another dimension is going from conceptual ideas to formal systems.
|Link=https://discord.com/channels/1029514961782849607/1040360259413348432/1040502446943899668
}}

Project Ideas

2022-11-11T08:03:45Z

Khinsen: /* Making Discourse Graphs Indexable & Discoverable */

== [[Translate Logseq Knowledge Graph to Systems Biology Network Diagrams]] ==
lead: [[Akila Wijerathna-Yapa]]

== [[Linked Data Publishing On Activitypub]] ==

{{Message
|Author=sneakers-the-rat
|Avatar=https://cdn.discordapp.com/avatars/305044217393053697/2970b22bd769d0cd0ee1de79be500e85.png?size=1024
|Date Sent=22-11-03 22:51:30
|Channel=In terms of overlap with my own
|Text=[[Project Ideas#Linked Data Publishing On Activitypub]]

ooh I'm very interested in this. so are you thinking a [[Twitter#Bridge]] -> [[ActivityPub#Bridge]] where one could use markup within the twitter post to declare [[Linked Data#Markup Syntax]] and then post to AP? I have thought about this kind of thing before, like using a bot command syntax to declare prefixes by doing something like
```
@ bot prefix
foaf: https:// (ontology URL)
```
or
```
@ bot alias
term: foaf.LongerNameForTerm
```
so that one could do maybe a semantic wikilink like `[ [term::value] ]` either within the tweet or as a reply to it (so the tweet itself doesn't become cluttered/it can become organized post -hoc?).

I've also thought about a bridge (I called [[Threadodo]] ) that implements that kind of command syntax to be able to directly archive threads to [[Zenodo]] along with structured information about the author, but this seems more interesting.

I can help try and clear some of the groundwork out of the way to make it easier for you and other interested participants to experiment. I have asked around fedi a bunch for a very minimal AP server implementation, and I could try and find one (or we could try and prototype one) if you want to experiment with that :), and I can also document and show you a tweepy-based bot that has an extensible command/parsing system too
|Link=https://discord.com/channels/1029514961782849607/1037786518800039978/1037861609885925467
}}

= [[Making Discourse Graphs Indexable & Discoverable]] =

= [[Federated knowledge synthesis]] =

{{Message
|Author=Konrad Hinsen
|Avatar=https://cdn.discordapp.com/avatars/499904513038090240/343ae17c322fa09b3260f95e58bc4f29.png?size=1024
|Date Sent=22-11-11 05:45:14
|Channel=Thanks sneakers the rat2880 Your site is
|Text=I'll try to turn this thread into [[Project Ideas#Federated knowledge synthesis]]: identify protocols, data models, tools, practices, etc. that can support the process of synthesizing and formalizing scientific knowledge, then build on these ingredients. One dimension is going from narratives via discourse graphs to knowledge graphs. Another dimension is going from conceptual ideas to formal systems.
|Link=https://discord.com/channels/1029514961782849607/1040360259413348432/1040502446943899668
}}

Project Ideas

2022-11-11T05:48:04Z

Khinsen: /* Federated knowledge synthesis */

== [[Translate Logseq Knowledge Graph to Systems Biology Network Diagrams]] ==
lead: [[Akila Wijerathna-Yapa]]

== [[Linked Data Publishing On Activitypub]] ==

{{Message
|Author=sneakers-the-rat
|Avatar=https://cdn.discordapp.com/avatars/305044217393053697/2970b22bd769d0cd0ee1de79be500e85.png?size=1024
|Date Sent=22-11-03 22:51:30
|Channel=In terms of overlap with my own
|Text=[[Project Ideas#Linked Data Publishing On Activitypub]]

ooh I'm very interested in this. so are you thinking a [[Twitter#Bridge]] -> [[ActivityPub#Bridge]] where one could use markup within the twitter post to declare [[Linked Data#Markup Syntax]] and then post to AP? I have thought about this kind of thing before, like using a bot command syntax to declare prefixes by doing something like
```
@ bot prefix
foaf: https:// (ontology URL)
```
or
```
@ bot alias
term: foaf.LongerNameForTerm
```
so that one could do maybe a semantic wikilink like `[ [term::value] ]` either within the tweet or as a reply to it (so the tweet itself doesn't become cluttered/it can become organized post -hoc?).

I've also thought about a bridge (I called [[Threadodo]] ) that implements that kind of command syntax to be able to directly archive threads to [[Zenodo]] along with structured information about the author, but this seems more interesting.

I can help try and clear some of the groundwork out of the way to make it easier for you and other interested participants to experiment. I have asked around fedi a bunch for a very minimal AP server implementation, and I could try and find one (or we could try and prototype one) if you want to experiment with that :), and I can also document and show you a tweepy-based bot that has an extensible command/parsing system too
|Link=https://discord.com/channels/1029514961782849607/1037786518800039978/1037861609885925467
}}

= [[Making Discourse Graphs Indexable & Discoverable]] =

== [[Federated knowledge synthesis]] ==

{{Message
|Author=Konrad Hinsen
|Avatar=https://cdn.discordapp.com/avatars/499904513038090240/343ae17c322fa09b3260f95e58bc4f29.png?size=1024
|Date Sent=22-11-11 05:45:14
|Channel=Thanks sneakers the rat2880 Your site is
|Text=I'll try to turn this thread into [[Project Ideas#Federated knowledge synthesis]]: identify protocols, data models, tools, practices, etc. that can support the process of synthesizing and formalizing scientific knowledge, then build on these ingredients. One dimension is going from narratives via discourse graphs to knowledge graphs. Another dimension is going from conceptual ideas to formal systems.
|Link=https://discord.com/channels/1029514961782849607/1040360259413348432/1040502446943899668
}}

Digital Scientific Notations

2022-11-11T05:35:59Z

Khinsen: Another link fix

A scientific notation is a convention for encoding scientific information using symbols. The best known example is mathematical notation. The goal of a scientific notation is to represent scientific knowledge in a way that humans can easily comprehend and manipulate. While in principle a mathematical equation could be replaced by an equivalent statement in plain language, the more concise equation is faster to read (assuming a trained reader) and allows manipulation by formal rules (such as "add the same term to both sides").

A '''digital''' scientific notation is a scientific notation that can be processed by both humans and computers. A machine readable notation is necessarily a [https://en.wikipedia.org/wiki/Formal_language formal language] and thus has a well-defined unambiguous syntax in addition to some useful level of well-defined semantics.

There are many formal languages designed for representing scientific information. An example is the [https://en.wikipedia.org/wiki/SBML Systems Biology Markup Language (SBML)]. Most of them do not qualify as digital scientific notations, because they are designed to be used by software but not for communication between humans.

There are also formal languages that are designed to be read and written by humans, in addition to computers. Programming languages are the most prominent examples. In scientific computing, programming languages are routinely used to represent scientific knowledge as program code. In particular, computational notebooks embed code written in high-level programming languages such as Python or R into a narrative, much like mathematical notation is used in traditional scientific publications. However, programming languages fill the role of scientific notations rather poorly, in particular because they cannot express anything other than executable algorithms.

Digital scientific notations are '''not''' computational tools, but parts of the communication interfaces between scientists and their computational tools. In particular, they permit scientists to discuss computational models and methods in a way that ensures conformity between the human narratives and the computations.

Further reading: [https://arxiv.org/abs/1605.02960 Scientific Notations for the Digital Era] (on arXiv)

== Discord ==

{{Message
|Author=Konrad Hinsen
|Avatar=https://cdn.discordapp.com/avatars/499904513038090240/343ae17c322fa09b3260f95e58bc4f29.png?size=1024
|Date Sent=22-11-11 05:26:42
|Channel=WikiFunctions
|Text=That said, the more abstract idea of defining a data model plus execution semantics that any programming language can plug into looks very promising. That aspect of WikiLambda was in fact one of my inspirations for developing [[Digital Scientific Notations]].
|Link=https://discord.com/channels/1029514961782849607/1040456437022859324/1040497782882062336
}}

Digital Scientific Notations

2022-11-11T05:35:08Z

Khinsen: Fix link syntax

A scientific notation is a convention for encoding scientific information using symbols. The best known example is mathematical notation. The goal of a scientific notation is to represent scientific knowledge in a way that humans can easily comprehend and manipulate. While in principle a mathematical equation could be replaced by an equivalent statement in plain language, the more concise equation is faster to read (assuming a trained reader) and allows manipulation by formal rules (such as "add the same term to both sides").

A '''digital''' scientific notation is a scientific notation that can be processed by both humans and computers. A machine readable notation is necessarily a [https://en.wikipedia.org/wiki/Formal_language formal language] and thus has a well-defined unambiguous syntax in addition to some useful level of well-defined semantics.

There are many formal languages designed for representing scientific information. An example is the [Systems Biology Markup Language (https://en.wikipedia.org/wiki/SBML SBML)]. Most of them do not qualify as digital scientific notations, because they are designed to be used by software but not for communication between humans.

There are also formal languages that are designed to be read and written by humans, in addition to computers. Programming languages are the most prominent examples. In scientific computing, programming languages are routinely used to represent scientific knowledge as program code. In particular, computational notebooks embed code written in high-level programming languages such as Python or R into a narrative, much like mathematical notation is used in traditional scientific publications. However, programming languages fill the role of scientific notations rather poorly, in particular because they cannot express anything other than executable algorithms.

Digital scientific notations are '''not''' computational tools, but parts of the communication interfaces between scientists and their computational tools. In particular, they permit scientists to discuss computational models and methods in a way that ensures conformity between the human narratives and the computations.

Further reading: [https://arxiv.org/abs/1605.02960 Scientific Notations for the Digital Era] (on arXiv)

== Discord ==

{{Message
|Author=Konrad Hinsen
|Avatar=https://cdn.discordapp.com/avatars/499904513038090240/343ae17c322fa09b3260f95e58bc4f29.png?size=1024
|Date Sent=22-11-11 05:26:42
|Channel=WikiFunctions
|Text=That said, the more abstract idea of defining a data model plus execution semantics that any programming language can plug into looks very promising. That aspect of WikiLambda was in fact one of my inspirations for developing [[Digital Scientific Notations]].
|Link=https://discord.com/channels/1029514961782849607/1040456437022859324/1040497782882062336
}}

Digital Scientific Notations

2022-11-11T05:30:46Z

Khinsen:

A scientific notation is a convention for encoding scientific information using symbols. The best known example is mathematical notation. The goal of a scientific notation is to represent scientific knowledge in a way that humans can easily comprehend and manipulate. While in principle a mathematical equation could be replaced by an equivalent statement in plain language, the more concise equation is faster to read (assuming a trained reader) and allows manipulation by formal rules (such as "add the same term to both sides").

A '''digital''' scientific notation is a scientific notation that can be processed by both humans and computers. A machine readable notation is necessarily a [formal language](https://en.wikipedia.org/wiki/Formal_language) and thus has a well-defined unambiguous syntax in addition to some useful level of well-defined semantics.

There are many formal languages designed for representing scientific information. An example is the [Systems Biology Markup Language (SBML)](https://en.wikipedia.org/wiki/SBML). Most of them do not qualify as digital scientific notations, because they are designed to be used by software but not for communication between humans.

There are also formal languages that are designed to be read and written by humans, in addition to computers. Programming languages are the most prominent examples. In scientific computing, programming languages are routinely used to represent scientific knowledge as program code. In particular, computational notebooks embed code written in high-level programming languages such as Python or R into a narrative, much like mathematical notation is used in traditional scientific publications. However, programming languages fill the role of scientific notations rather poorly, in particular because they cannot express anything other than executable algorithms.

Digital scientific notations are '''not''' computational tools, but parts of the communication interfaces between scientists and their computational tools. In particular, they permit scientists to discuss computational models and methods in a way that ensures conformity between the human narratives and the computations.

Further reading: [https://arxiv.org/abs/1605.02960 Scientific Notations for the Digital Era] (on arXiv)

== Discord ==

{{Message
|Author=Konrad Hinsen
|Avatar=https://cdn.discordapp.com/avatars/499904513038090240/343ae17c322fa09b3260f95e58bc4f29.png?size=1024
|Date Sent=22-11-11 05:26:42
|Channel=WikiFunctions
|Text=That said, the more abstract idea of defining a data model plus execution semantics that any programming language can plug into looks very promising. That aspect of WikiLambda was in fact one of my inspirations for developing [[Digital Scientific Notations]].
|Link=https://discord.com/channels/1029514961782849607/1040456437022859324/1040497782882062336
}}

Konrad Hinsen

2022-11-05T09:44:32Z

Khinsen:

{{Participant
|Timezone=CET (GMT+01:00/GMT+02:00)
|Homepage=http://khinsen.net/, https://science-in-the-digital-era.khinsen.net/
|Affiliation=CNRS
|Projects=Leibniz
|Table Assignment=Table 1
|ORCID=0000-0003-0330-9428
|Twitter=khinsen
|Fediverse=https://scholar.social/@khinsen
|Github=khinsen
}}
{{Workshop Submission
|Interest=Ever since I started doing computational biophysics research 25 years ago, I have been unhappy with the state of the art in dealing with complex computational models. Then and still now, they are represented in two unconnected forms: a narrative providing the scientific background and a summary, and an optimized (and hence unreadable) piece of simulation software the embeds the model. The narrative is usually subject to peer review, but review has to remain superficial in the absence of the complete model. The software source code usually undergoes no independent evaluation because that's far too much effort to ask from a reviewer. For the potential user of the model, there is a version they can run but not understand, and a summary that they can understand but not compare to what they are running. Given the increasing importance of computational models in many fields of science, that's a problem. Scientific models ought to take center stage in scientific debate, but this is currently not possible.

My first attempt to improve the situation was the move to high-level programming languages. In 1995, I co-founded the "Numerical Python" project, which became the nucleus of the Scientific Python ecosystem. While Python code was indeed more readable and better modifiable than the previously common Fortran or C codes, this didn't change the fundamental situation of two unconnected representations. Also, Python code is still too alien for human readers to make independent evaluation of scientific software a reality.

Another obstacle to doing computational science is that computational models are, in general, specifications rather than algorithms. A runnable implementation is thus needlessly specific, making it difficult to use computational tools (formal methods, code generators, future AI-based tools) to reason about the model. My current second attempt at improving the situation is therefore (1) a specification language and (2) embedded into a human-readable narrative, much like traditional mathematical notation. The second major iteration of this project, which I named "Leibniz" in honor of Gottfried Wilhelm Leibniz, just reached the point where I could make a public demo.

Although my current prototype is a single-user environment, the long-term objective is a collaborative computational medium for scientific models. My main inspiration for this aspect is the consensus-enabling structure of Federated Wiki, but I really hope to learn more about this problem space from other participants of the workshop.
|Frame=Practitioner, Tool-builder
|Materials="Computational science: shifting the focus from tools to models" https://f1000research.com/articles/3-101/v2
An in-detail explanation of the problem, with an outline of a solution, written in 2014 before I actually started working on my prototypes.

"The structure and interpretation of scientific models" http://blog.khinsen.net/posts/2020/12/10/the-structure-and-interpretation-of-scientific-models/
A blog post explaining why computational models are, in general, specifications rather than algorithms.

"Verifiability in computer-aided research: the role of digital scientific notations at the human-computer interface" https://peerj.com/articles/cs-158/
A report on the first iteration of Leibniz, written in 2018.

"Liberating computational science from software complexity" https://www.youtube.com/watch?v=YbznItQpALo&t=2104s
A recorded talk at RacketCon 2020, with a motivating introduction and a demo of the first iteration.

"Using Glamorous Toolkit for Scientific Notation" https://www.youtube.com/watch?v=f10NpsMmbis
A first demo of the second iteration, in discussion with Tudor Girba, the chief architect of the platform I chose to build on.

And, of course, the code: https://github.com/khinsen/leibniz-pharo
|Organizer Topics=Research Data, Reproducibility, Federation, Gradual Enrichment, Documents, Wikis, Knowledge Graphs, Transdisciplinarity, Scientific Publishing
}}

Konrad Hinsen

2022-11-05T09:40:02Z

Khinsen:

Konrad Hinsen

2022-11-02T09:59:33Z

Khinsen:

Konrad Hinsen

2022-11-02T07:53:28Z

Khinsen: Add ORCID and social network handles

{{Participant
|Timezone=CET (GMT+01:00/GMT+02:00)
|Affiliation=CNRS
|Projects=Leibniz
|Table Assignment=Table 1
|ORCID=0000-0003-0330-9428
|Twitter=khinsen
|Fediverse=https://scholar.social/@khinsen
|Github=khinsen
}}
{{Workshop Submission
|Interest=Ever since I started doing computational biophysics research 25 years ago, I have been unhappy with the state of the art in dealing with complex computational models. Then and still now, they are represented in two unconnected forms: a narrative providing the scientific background and a summary, and an optimized (and hence unreadable) piece of simulation software the embeds the model. The narrative is usually subject to peer review, but review has to remain superficial in the absence of the complete model. The software source code usually undergoes no independent evaluation because that's far too much effort to ask from a reviewer. For the potential user of the model, there is a version they can run but not understand, and a summary that they can understand but not compare to what they are running. Given the increasing importance of computational models in many fields of science, that's a problem. Scientific models ought to take center stage in scientific debate, but this is currently not possible.

My first attempt to improve the situation was the move to high-level programming languages. In 1995, I co-founded the "Numerical Python" project, which became the nucleus of the Scientific Python ecosystem. While Python code was indeed more readable and better modifiable than the previously common Fortran or C codes, this didn't change the fundamental situation of two unconnected representations. Also, Python code is still too alien for human readers to make independent evaluation of scientific software a reality.

Another obstacle to doing computational science is that computational models are, in general, specifications rather than algorithms. A runnable implementation is thus needlessly specific, making it difficult to use computational tools (formal methods, code generators, future AI-based tools) to reason about the model. My current second attempt at improving the situation is therefore (1) a specification language and (2) embedded into a human-readable narrative, much like traditional mathematical notation. The second major iteration of this project, which I named "Leibniz" in honor of Gottfried Wilhelm Leibniz, just reached the point where I could make a public demo.

Although my current prototype is a single-user environment, the long-term objective is a collaborative computational medium for scientific models. My main inspiration for this aspect is the consensus-enabling structure of Federated Wiki, but I really hope to learn more about this problem space from other participants of the workshop.
|Materials="Computational science: shifting the focus from tools to models" https://f1000research.com/articles/3-101/v2
An in-detail explanation of the problem, with an outline of a solution, written in 2014 before I actually started working on my prototypes.

"The structure and interpretation of scientific models" http://blog.khinsen.net/posts/2020/12/10/the-structure-and-interpretation-of-scientific-models/
A blog post explaining why computational models are, in general, specifications rather than algorithms.

"Verifiability in computer-aided research: the role of digital scientific notations at the human-computer interface" https://peerj.com/articles/cs-158/
A report on the first iteration of Leibniz, written in 2018.

"Liberating computational science from software complexity" https://www.youtube.com/watch?v=YbznItQpALo&t=2104s
A recorded talk at RacketCon 2020, with a motivating introduction and a demo of the first iteration.

"Using Glamorous Toolkit for Scientific Notation" https://www.youtube.com/watch?v=f10NpsMmbis
A first demo of the second iteration, in discussion with Tudor Girba, the chief architect of the platform I chose to build on.

And, of course, the code: https://github.com/khinsen/leibniz-pharo
|Organizer Topics=Research Data, Reproducibility, Federation
}}

Reproducibility

2022-10-29T09:14:09Z

Khinsen: Created page with "Reproducibility is one of the cornerstones of the scientific method. If I say "here's what I have done and that's what I found", then someone else should be able to retrace my steps and arrive at the same outcome. Without reproducibility, it is very difficult to verify someone else's work, or to build on it in subsequent work. Over the last 10 to 20 years, many scientific disciplines have experienced a [https://en.wikipedia.org/wiki/Replication_crisis reproducibility cr..."

Reproducibility is one of the cornerstones of the scientific method. If I say "here's what I have done and that's what I found", then someone else should be able to retrace my steps and arrive at the same outcome. Without reproducibility, it is very difficult to verify someone else's work, or to build on it in subsequent work.

Over the last 10 to 20 years, many scientific disciplines have experienced a [https://en.wikipedia.org/wiki/Replication_crisis reproducibility crisis], consisting of the discovery that results that everybody expected to be reproducible are in fact not. Most of these cases fall into one (or both) of two categories.

1. Statistical reproducibility is about re-doing an experiment, using a different sample (people, bacteria, electrons, ...), applying the same inference techniques, and finding close enough results. Statistical irreproducibility points to insufficient sample sizes, mistakes in applying statistical inference, inappropriate use of statistics, or various forms of fraud (data manipulation, p-hacking, ...).

2. Computational reproducibility is about re-running a computation and getting identical results. Computational irreproducibility is due to an incomplete record of what was actually computed. That can be due to bad bookkeeping (e.g. no version control for source code), or due to the complexity of today's software stacks, which make it very difficult to know all the software that contributed to a computation, and even more difficult to reconstruct that stack identically.

Leibniz

2022-10-29T09:03:59Z

Khinsen: Leibniz is an experimental digital scientific notation for computational physics and chemistry (and maybe more)

Leibniz is a research project aiming at developing a digital scientific notation for computational physics and chemistry. Such a notation should be suitable as well for other domains using predominantly mathematical models, but my focus is on the domains that I know best.

The basic idea of a digital scientific notation is to upgrade traditional math notation to the digital era, i.e. making it suitable for computational models, without losing its tight integration into human-friendly narratives.

CNRS

2022-10-29T08:50:09Z

Khinsen: Created page with "The [https://www.cnrs.fr/ Centre National de la Recherche Scientifique] is the largest public research organization in France. It runs research laboratories all over the country, often in cooperation with a nearby university."

The [https://www.cnrs.fr/ Centre National de la Recherche Scientifique] is the largest public research organization in France. It runs research laboratories all over the country, often in cooperation with a nearby university.