Synthesis Infrastructures - User contributions [en]

Discourse Modeling

2022-11-28T20:28:21Z

Karola: /* Progress as of Day 2 */

{{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, Sam Klein
|Description=Implement Discourse Graph schema in Semantic MediaWiki. Query Discourse Graph contents through SMW sparql endpoint. Visualize and publish Discourse Graph contents.
}}
== What are we discussing? ==

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

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

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

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

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

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

* Claim :
* Axiom (?) :

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

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

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

== Workshop Goals ==

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

== Progress as of Day 1 ==

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

== Progress as of Day 2 ==

* We continued to build out the Discourse wiki on the talk page, including developing conventions for tagging parts of syntax and relations
* We discovered that what we are working towards is a set of (mostly syntactical) conventions for creating Discourse Graphs -- almost like a Markdown for Discourse Graphs
* We extended the SPARQL query system
* We discussed discourse graph discovery algorithms
* We discussed visualization options
* We realized that the ability to notice and capture disparate mentions of identical or similar topics would be a very desirable feature supporting collaboration

== Observations & Open Problems ==

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

== Relevant Projects and Ideas ==

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

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

==Computation, Queries and Answers==

What is the act of synthesis, and what does it have to do with discourse graphs?

Synthesis is the process by which one or more computational processes process the same set of information to generate a coherent understanding of (model of) the world. The set of information in this case is the discourse graph, which contains the information processed and shared in the act of attempting to answer a question, and information regarding the provenance of the information.

‘This is an epistemic process made perhaps most explicit by the scientific process, but it is generalizable in the sense that it can be used to describe two farmers sharing observations about the weather, or two parallel processes within a question answering system sharing results to synthesize a single answer.

I suppose that this shouldn’t be surprising since since the discourse graph starts with a question, but the process that the discourse graph supports has much in common with query execution following an API call, but perhaps query execution that attempts to answer a question whose answer requires synthesis. Perhaps a synthesis query? A query which returns multiple items of information (claims) that a computational process can synthesize to answer a question.

== 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-23T18:55:12Z

Karola: /* Day 2 */

== Participants in the discussion ==

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

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



==== Federated Knowledge Synthesis ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|extends=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years|supports=survey-first}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|extends=survey-first}}



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



==== Version control v Narratives ====
* {{d|id=meet-in-middle |a=? |type=question |text=how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives? |supports=}}
** {{d|id= |a=KK |type=evidence |text=[https://everything2.com/ everything2] |supports=meet-in-middle}}
** {{d|id= |a=KK |type=evidence |text=[https://anagora.org/agora agora] |supports=meet-in-middle}}
* {{d|id=what-dg-types |a=SJ |type=question |text=what types of graph are we talking about? |supports=}}
** {{d|id=lacking-meta-dgs |a=SJ |type=claim |text=I haven't seen dgs about discourse: chains of reasoning, mapping out arguments - these can be linear if there is a dialog |supports=what-dg-types}}
*** {{d|id=composite-dg |a=SJ |type=question |text=what does composite graph of discourse addressing the same issues look like? |extends=lacking-meta-dgs}}
** {{d|id= |a=SJ |type=claim |text=personal or group notetaking: connections are not discourse connections - they include refrences, clarifiers, and links of definitions |supports=what-dg-types}}



== Section 2 Konrad ==

=== A [[Discourse Graph]] for our own Wiki ===

*KM: [[question]] can we take contributions to this wiki as data to generate a discourse graph?
**[[claim]] this means creating a schema, show others how to create the different node types
**[[claim]] this means take db backend, ingest it, execute queries against it
**[[claim]] viz may not be super-sophisticated, but a view or 2 framed on each node type would be worthwhile: eg how does a question relate to claims, how are claims informed by different articles (evidence)
*[[claim]] need to populate the wiki with the elements of a discourse graph --> create viz --> share code
*SJ: [[question]] can we accomplish naming: coming up with names for each of those components, and names for things at different scales - discussion, family of hypotheses, family of experiments
**[[claim]] this will allow us to say that if you have identified x ideas, hypotheses, etc - how many discourses do you need to describe? how many graphs are needed to illustrate those discourses - when are people working on the same graph?
**[[question]] what does it mean to have different graphs that share some pieces, or different graphs in or close to the same namespace
**[[claim]] these issues --> boil down to the naming of the pieces and how you place the connections - how much context do you need to figure out how many connections there are?
*KM: taking this as an opportunity to learn SPARQL ('''-->''' [[claim]] this is a good opportunity to learn SPARQL)
*KM: [[claim]] we need namespaces before we can query anything - naming is critical!
*SJ: [[claim]] we should name and make list of queries - queries need their own names

=== [[Agora]] ===

*KM: [[question]] what is agora?
*SJ: [[claim]] agora is a group of people interested in wiki linking and editable networks & knowledge federation
** [[claim]] agora's goals include:
*** make linking always do something sensible - best effort connection between links
*** agora is a url pattern that will try to resolve it
*** redirect strings to appropriate resources
*** each reader gets a filter - only see certain nodes & connection based on sort preferences
**KM: [[claim]] sounds like auto-complete for knowledge graphs
** [[claim]] each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
** [[proposal]] elevate DGs by making a section that tries to generate a DG or discourses that mention this node
*[[claim]] DG is a shape you compile on the fly - could try to generate a DG x steps away and show you different families that might be referencing this
** [[claim]] spirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
*KK: [[question]] diff between agora and what we envision?
**SJ: [[claim]] no typology of links
** [[claim]] graph visualization does not ignore non-typed connections
*KH: [[question]] existing descriptions of agora other than the site itself?

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

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

=== What exactly makes a graph a [[Discourse Graph]]? ===

*[[question]]: can a discourse be about a topic? are discourses about a certain over-arching hypothesis where you make claims and discover evidence?
**KH: [[question]] what do you do when your discourse does not fit a DG?
***examples from physics with no well-posed question
**discussion of results graphs and requests for experiments
**[[proposal]] need to figure out how DGs work in these different fields and circumstances
**SJ: meta:[[proposal]] need to identify existing discourse maps, and existing graphs, that could be thought of as DGs (proofs, discourse diagrams, text summarization graphs, argument maps, decision maps + flowcharts, ...)
*SJ: [[proposal]] need to capture axioms / assumptions
*KH: [[proposal]] making tacit knowledge explicit!!

== Section 3 Kyle ==
* {{d|id=start-w-schemas |a= |type=question |text=What if we start with naming & schemas first |supports=}}
* {{d|id= |a= |type=question |text=do we start with a schema or refine as we go? |supports=}}
** {{d|id= |a=SJ |type=claim |text=smw makes this hard for exactly this reason (deciding up front is friction). |supports=start-w-schemas}}
** {{d|id=simple-mw |a= |type=claim |text=easier with free form mediawiki templates and wiki text |supports=start-w-schemas}}
*** {{d|id= |a= |type=claim |text=templates allow tiny Lua templates, w/ any number of fields and presentation. |supports=simple-mw}}
*** {{d|id= |a=SJ |type=claim |text=this can be edited flexibly, so schema changes don't break things or make them illegible. |supports=simple-mw}}

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

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

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

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

* {{d|id=wiki-granularity |a=KH |type=question |text=if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page? |supports=}}
** {{d|id=wiki-all-pages |a=KM |type=claim |text=it seems everything is a page. |extends=wiki-granularity }}
*** {{d|id=wiki-sections |a=SJ |type=claim |text=sections of a page are not a page. |opposes=wiki-all-pages }}
** {{d|id=wiki-node-pages |a=SJ |type=claim |text=everything we want to be a node should be a page. |extends=wiki-granularity }}
** {{d|id=wiki-subgraph-pages |a=SJ |type=claim |text=wiki transclusion also allows any subgraph to have a page, transcluding other nodes. |extends=wiki-granularity }}
*** {{d|id=wiki-pages-busy |a=SJ |type=claim |text= then each page needs a title - lots of work. and makes the history view busy, a UX question affecting exploration. |opposes=wiki-node-pages }}
** {{d|id=wiki-pages-manageable |a=SJ |type=claim |text=True, this is a Q of interfaces. Wiki recent changes scales well, we don't need to worry about that yet. we can use wikibase to scale ux issues and hide certain types of history (eg source edits). But we can do it this way for a demo. |opposes=wiki-pages-busy }}
:: '''NB''': ''this last is really 'oppose in part, support in part'. speaking to wanting a vocabulary of connection types''
*** {{d|id=start-with-transclusion|a=KH |type=claim |text=first attempt: everything is a page, we rely on transclusion to group things |supports=wiki-pages-manageable}}
** {{d|id= |a=KH |type=question |text=can we have the entire Q as a page title? |extends=wiki-pages-busy }}

* {{d|id= |a=KK |type=claim |text=there are many to many relationships between sources & evidence |supports=}}
* {{d|id= |a= |type=claim |text=source property could be a url and we could create an entity for the source that scrapes data and populates fields. If you expect something will be used more than once you probably want it to have the full data|supports=}}
* {{d|id=starting-dgs |a=SJ |type=claim |text=let's identify a discussion we want to capture, and figure out how to name it. |supports=}}



== Day 2 ==

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

Talk:Discourse Modeling

2022-11-23T18:50:08Z

Karola: add /* Day 2 */ discussion with DG annotations

== Participants in the discussion ==

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

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



==== Federated Knowledge Synthesis ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|extends=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years|supports=survey-first}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|extends=survey-first}}



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



==== Version control v Narratives ====
* {{d|id=meet-in-middle |a=? |type=question |text=how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives? |supports=}}
** {{d|id= |a=KK |type=evidence |text=[https://everything2.com/ everything2] |supports=meet-in-middle}}
** {{d|id= |a=KK |type=evidence |text=[https://anagora.org/agora agora] |supports=meet-in-middle}}
* {{d|id=what-dg-types |a=SJ |type=question |text=what types of graph are we talking about? |supports=}}
** {{d|id=lacking-meta-dgs |a=SJ |type=claim |text=I haven't seen dgs about discourse: chains of reasoning, mapping out arguments - these can be linear if there is a dialog |supports=what-dg-types}}
*** {{d|id=composite-dg |a=SJ |type=question |text=what does composite graph of discourse addressing the same issues look like? |extends=lacking-meta-dgs}}
** {{d|id= |a=SJ |type=claim |text=personal or group notetaking: connections are not discourse connections - they include refrences, clarifiers, and links of definitions |supports=what-dg-types}}



== Section 2 Konrad ==

=== A [[Discourse Graph]] for our own Wiki ===

*KM: [[question]] can we take contributions to this wiki as data to generate a discourse graph?
**[[claim]] this means creating a schema, show others how to create the different node types
**[[claim]] this means take db backend, ingest it, execute queries against it
**[[claim]] viz may not be super-sophisticated, but a view or 2 framed on each node type would be worthwhile: eg how does a question relate to claims, how are claims informed by different articles (evidence)
*[[claim]] need to populate the wiki with the elements of a discourse graph --> create viz --> share code
*SJ: [[question]] can we accomplish naming: coming up with names for each of those components, and names for things at different scales - discussion, family of hypotheses, family of experiments
**[[claim]] this will allow us to say that if you have identified x ideas, hypotheses, etc - how many discourses do you need to describe? how many graphs are needed to illustrate those discourses - when are people working on the same graph?
**[[question]] what does it mean to have different graphs that share some pieces, or different graphs in or close to the same namespace
**[[claim]] these issues --> boil down to the naming of the pieces and how you place the connections - how much context do you need to figure out how many connections there are?
*KM: taking this as an opportunity to learn SPARQL ('''-->''' [[claim]] this is a good opportunity to learn SPARQL)
*KM: [[claim]] we need namespaces before we can query anything - naming is critical!
*SJ: [[claim]] we should name and make list of queries - queries need their own names

=== [[Agora]] ===

*KM: [[question]] what is agora?
*SJ: [[claim]] agora is a group of people interested in wiki linking and editable networks & knowledge federation
** [[claim]] agora's goals include:
*** make linking always do something sensible - best effort connection between links
*** agora is a url pattern that will try to resolve it
*** redirect strings to appropriate resources
*** each reader gets a filter - only see certain nodes & connection based on sort preferences
**KM: [[claim]] sounds like auto-complete for knowledge graphs
** [[claim]] each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
** [[proposal]] elevate DGs by making a section that tries to generate a DG or discourses that mention this node
*[[claim]] DG is a shape you compile on the fly - could try to generate a DG x steps away and show you different families that might be referencing this
** [[claim]] spirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
*KK: [[question]] diff between agora and what we envision?
**SJ: [[claim]] no typology of links
** [[claim]] graph visualization does not ignore non-typed connections
*KH: [[question]] existing descriptions of agora other than the site itself?

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

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

=== What exactly makes a graph a [[Discourse Graph]]? ===

*[[question]]: can a discourse be about a topic? are discourses about a certain over-arching hypothesis where you make claims and discover evidence?
**KH: [[question]] what do you do when your discourse does not fit a DG?
***examples from physics with no well-posed question
**discussion of results graphs and requests for experiments
**[[proposal]] need to figure out how DGs work in these different fields and circumstances
**SJ: meta:[[proposal]] need to identify existing discourse maps, and existing graphs, that could be thought of as DGs (proofs, discourse diagrams, text summarization graphs, argument maps, decision maps + flowcharts, ...)
*SJ: [[proposal]] need to capture axioms / assumptions
*KH: [[proposal]] making tacit knowledge explicit!!

== Section 3 Kyle ==
* {{d|id=start-w-schemas |a= |type=question |text=What if we start with naming & schemas first |supports=}}
* {{d|id= |a= |type=question |text=do we start with a schema or refine as we go? |supports=}}
** {{d|id= |a=SJ |type=claim |text=smw makes this hard for exactly this reason (deciding up front is friction). |supports=start-w-schemas}}
** {{d|id=simple-mw |a= |type=claim |text=easier with free form mediawiki templates and wiki text |supports=start-w-schemas}}
*** {{d|id= |a= |type=claim |text=templates allow tiny Lua templates, w/ any number of fields and presentation. |supports=simple-mw}}
*** {{d|id= |a=SJ |type=claim |text=this can be edited flexibly, so schema changes don't break things or make them illegible. |supports=simple-mw}}

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

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

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

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

* {{d|id=wiki-granularity |a=KH |type=question |text=if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page? |supports=}}
** {{d|id=wiki-all-pages |a=KM |type=claim |text=it seems everything is a page. |extends=wiki-granularity }}
*** {{d|id=wiki-sections |a=SJ |type=claim |text=sections of a page are not a page. |opposes=wiki-all-pages }}
** {{d|id=wiki-node-pages |a=SJ |type=claim |text=everything we want to be a node should be a page. |extends=wiki-granularity }}
** {{d|id=wiki-subgraph-pages |a=SJ |type=claim |text=wiki transclusion also allows any subgraph to have a page, transcluding other nodes. |extends=wiki-granularity }}
*** {{d|id=wiki-pages-busy |a=SJ |type=claim |text= then each page needs a title - lots of work. and makes the history view busy, a UX question affecting exploration. |opposes=wiki-node-pages }}
** {{d|id=wiki-pages-manageable |a=SJ |type=claim |text=True, this is a Q of interfaces. Wiki recent changes scales well, we don't need to worry about that yet. we can use wikibase to scale ux issues and hide certain types of history (eg source edits). But we can do it this way for a demo. |opposes=wiki-pages-busy }}
:: '''NB''': ''this last is really 'oppose in part, support in part'. speaking to wanting a vocabulary of connection types''
*** {{d|id=start-with-transclusion|a=KH |type=claim |text=first attempt: everything is a page, we rely on transclusion to group things |supports=wiki-pages-manageable}}
** {{d|id= |a=KH |type=question |text=can we have the entire Q as a page title? |extends=wiki-pages-busy }}

* {{d|id= |a=KK |type=claim |text=there are many to many relationships between sources & evidence |supports=}}
* {{d|id= |a= |type=claim |text=source property could be a url and we could create an entity for the source that scrapes data and populates fields. If you expect something will be used more than once you probably want it to have the full data|supports=}}
* {{d|id=starting-dgs |a=SJ |type=claim |text=let's identify a discussion we want to capture, and figure out how to name it. |supports=}}



== Day 2 ==

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

Talk:Discourse Modeling

2022-11-23T18:44:52Z

Karola:

== Participants in the discussion ==

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

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



==== Federated Knowledge Synthesis ====
* {{d|id=systems |a=KH |type=question |text=can we develop systems and process for federated knowledge synthesis?
|supports=}}
** {{d|id=survey-first |a=? |type=claim |text=the first steps involved would be getting people together & doing a survey of prior work (eg anagora)|supports=systems}}
*** {{d|id=how-to-extend |a=? |type=question |text=how can we build on this and extend it?|extends=survey-first}}
*** {{d|id=long-term coord |a=? |type=claim |text=this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years|supports=survey-first}}
*** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|extends=survey-first}}



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



==== Version control v Narratives ====
* {{d|id=meet-in-middle |a=? |type=question |text=how can you start w/ something highly formalized like version control and meet in the middle at something suitable for narratives? |supports=}}
** {{d|id= |a=KK |type=evidence |text=[https://everything2.com/ everything2] |supports=meet-in-middle}}
** {{d|id= |a=KK |type=evidence |text=[https://anagora.org/agora agora] |supports=meet-in-middle}}
* {{d|id=what-dg-types |a=SJ |type=question |text=what types of graph are we talking about? |supports=}}
** {{d|id=lacking-meta-dgs |a=SJ |type=claim |text=I haven't seen dgs about discourse: chains of reasoning, mapping out arguments - these can be linear if there is a dialog |supports=what-dg-types}}
*** {{d|id=composite-dg |a=SJ |type=question |text=what does composite graph of discourse addressing the same issues look like? |extends=lacking-meta-dgs}}
** {{d|id= |a=SJ |type=claim |text=personal or group notetaking: connections are not discourse connections - they include refrences, clarifiers, and links of definitions |supports=what-dg-types}}



== Section 2 Konrad ==

=== A [[Discourse Graph]] for our own Wiki ===

*KM: [[question]] can we take contributions to this wiki as data to generate a discourse graph?
**[[claim]] this means creating a schema, show others how to create the different node types
**[[claim]] this means take db backend, ingest it, execute queries against it
**[[claim]] viz may not be super-sophisticated, but a view or 2 framed on each node type would be worthwhile: eg how does a question relate to claims, how are claims informed by different articles (evidence)
*[[claim]] need to populate the wiki with the elements of a discourse graph --> create viz --> share code
*SJ: [[question]] can we accomplish naming: coming up with names for each of those components, and names for things at different scales - discussion, family of hypotheses, family of experiments
**[[claim]] this will allow us to say that if you have identified x ideas, hypotheses, etc - how many discourses do you need to describe? how many graphs are needed to illustrate those discourses - when are people working on the same graph?
**[[question]] what does it mean to have different graphs that share some pieces, or different graphs in or close to the same namespace
**[[claim]] these issues --> boil down to the naming of the pieces and how you place the connections - how much context do you need to figure out how many connections there are?
*KM: taking this as an opportunity to learn SPARQL ('''-->''' [[claim]] this is a good opportunity to learn SPARQL)
*KM: [[claim]] we need namespaces before we can query anything - naming is critical!
*SJ: [[claim]] we should name and make list of queries - queries need their own names

=== [[Agora]] ===

*KM: [[question]] what is agora?
*SJ: [[claim]] agora is a group of people interested in wiki linking and editable networks & knowledge federation
** [[claim]] agora's goals include:
*** make linking always do something sensible - best effort connection between links
*** agora is a url pattern that will try to resolve it
*** redirect strings to appropriate resources
*** each reader gets a filter - only see certain nodes & connection based on sort preferences
**KM: [[claim]] sounds like auto-complete for knowledge graphs
** [[claim]] each agora has a few default sections - ex will try to generate related out nodes, related agoras you know with the same title or fuzzy match, any text it finds in your own agora ad-hoc
** [[proposal]] elevate DGs by making a section that tries to generate a DG or discourses that mention this node
*[[claim]] DG is a shape you compile on the fly - could try to generate a DG x steps away and show you different families that might be referencing this
** [[claim]] spirit of the agora is automatic discovery & openness to engagement
**KH: [[question]] impression of agora is that it is a collection - how would I learn that someone else wants to do something to my node?
*** SJ: [[claim]] diff between creating a new link with the same name as your node and creating a link to your specific node
*KK: [[question]] diff between agora and what we envision?
**SJ: [[claim]] no typology of links
** [[claim]] graph visualization does not ignore non-typed connections
*KH: [[question]] existing descriptions of agora other than the site itself?

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

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

=== What exactly makes a graph a [[Discourse Graph]]? ===

*[[question]]: can a discourse be about a topic? are discourses about a certain over-arching hypothesis where you make claims and discover evidence?
**KH: [[question]] what do you do when your discourse does not fit a DG?
***examples from physics with no well-posed question
**discussion of results graphs and requests for experiments
**[[proposal]] need to figure out how DGs work in these different fields and circumstances
**SJ: meta:[[proposal]] need to identify existing discourse maps, and existing graphs, that could be thought of as DGs (proofs, discourse diagrams, text summarization graphs, argument maps, decision maps + flowcharts, ...)
*SJ: [[proposal]] need to capture axioms / assumptions
*KH: [[proposal]] making tacit knowledge explicit!!

== Section 3 Kyle ==
* {{d|id=start-w-schemas |a= |type=question |text=What if we start with naming & schemas first |supports=}}
* {{d|id= |a= |type=question |text=do we start with a schema or refine as we go? |supports=}}
** {{d|id= |a=SJ |type=claim |text=smw makes this hard for exactly this reason (deciding up front is friction). |supports=start-w-schemas}}
** {{d|id=simple-mw |a= |type=claim |text=easier with free form mediawiki templates and wiki text |supports=start-w-schemas}}
*** {{d|id= |a= |type=claim |text=templates allow tiny Lua templates, w/ any number of fields and presentation. |supports=simple-mw}}
*** {{d|id= |a=SJ |type=claim |text=this can be edited flexibly, so schema changes don't break things or make them illegible. |supports=simple-mw}}

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

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

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

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

* {{d|id=wiki-granularity |a=KH |type=question |text=if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page? |supports=}}
** {{d|id=wiki-all-pages |a=KM |type=claim |text=it seems everything is a page. |extends=wiki-granularity }}
*** {{d|id=wiki-sections |a=SJ |type=claim |text=sections of a page are not a page. |opposes=wiki-all-pages }}
** {{d|id=wiki-node-pages |a=SJ |type=claim |text=everything we want to be a node should be a page. |extends=wiki-granularity }}
** {{d|id=wiki-subgraph-pages |a=SJ |type=claim |text=wiki transclusion also allows any subgraph to have a page, transcluding other nodes. |extends=wiki-granularity }}
*** {{d|id=wiki-pages-busy |a=SJ |type=claim |text= then each page needs a title - lots of work. and makes the history view busy, a UX question affecting exploration. |opposes=wiki-node-pages }}
** {{d|id=wiki-pages-manageable |a=SJ |type=claim |text=True, this is a Q of interfaces. Wiki recent changes scales well, we don't need to worry about that yet. we can use wikibase to scale ux issues and hide certain types of history (eg source edits). But we can do it this way for a demo. |opposes=wiki-pages-busy }}
:: '''NB''': ''this last is really 'oppose in part, support in part'. speaking to wanting a vocabulary of connection types''
*** {{d|id=start-with-transclusion|a=KH |type=claim |text=first attempt: everything is a page, we rely on transclusion to group things |supports=wiki-pages-manageable}}
** {{d|id= |a=KH |type=question |text=can we have the entire Q as a page title? |extends=wiki-pages-busy }}

* {{d|id= |a=KK |type=claim |text=there are many to many relationships between sources & evidence |supports=}}
* {{d|id= |a= |type=claim |text=source property could be a url and we could create an entity for the source that scrapes data and populates fields. If you expect something will be used more than once you probably want it to have the full data|supports=}}
* {{d|id=starting-dgs |a=SJ |type=claim |text=let's identify a discussion we want to capture, and figure out how to name it. |supports=}}



== Day 2 ==

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

Discourse Modeling

2022-11-13T17:27:17Z

Karola: /* 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.<blockquote>From our chat yesterday: I'd like to propose adding <code>Axiom</code>s and adding relationships to <code>Source</code>s. Is there a way to do this on the oasis-lab spec?</blockquote>[[File:The discourse graph quadruplet.png|thumb|The discourse graph quadruplet]]

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

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

* Claim :
* Axiom (?) :

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

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

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

== Workshop Goals ==

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

== Progress as of Day 1 ==

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

== Progress as of Day 2 ==

== Observations & Open Problems ==

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

== Relevant Projects and Ideas ==

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

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

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

==Tools==

[[Download SMW rdf data]]

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

[[Example SPARQL queries in Wolfram Language]]

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

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

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

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

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

Discourse Modeling

2022-11-13T14:27:30Z

Karola: /* Observations & Open Problems */

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

== 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]
* Tana
* Kumu
* [https://discoursegraph.com The Discourse Graph Starter pack]

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

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

==Tools==

[[Download SMW rdf data]]

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

[[Example SPARQL queries in Wolfram Language]]

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

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

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

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

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

Discourse Modeling

2022-11-13T14:23:54Z

Karola: /* Progress as of Day 1 */

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

== 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]
* Tana
* Kumu
* [https://discoursegraph.com The Discourse Graph Starter pack]

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

== Discord ==

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

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

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

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

Discourse Modeling

2022-11-13T14:11:23Z

Karola: added figures

{{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/ Discourse Graphs] 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.

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

== 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]
* Tana
* Kumu
* [https://discoursegraph.com The Discourse Graph Starter pack]

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

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

File:Results graph.png

2022-11-13T14:07:30Z

Karola:

schematic of Matt Akamatsu's DG dialect for experimental science

File:The discourse graph quadruplet.png

2022-11-13T14:05:46Z

Karola:

illustration of the component nodes of a DG & their relations

File:Discourse Graph.png

2022-11-13T14:04:16Z

Karola:

Joel Chan's example Discourse Graph diagram

Discourse Modeling

2022-11-13T13:57:16Z

Karola: /* Now you're playing with templates */

{{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.

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

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

== 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]
* Tana
* Kumu
* [https://discoursegraph.com The Discourse Graph Starter pack]

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

== Discord ==

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

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

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

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

Discourse Modeling

2022-11-13T13:49:15Z

Karola: relevant projects & 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.

== 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 (?) :

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

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

== 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]
* Tana
* Kumu
* [https://discoursegraph.com The Discourse Graph Starter pack]

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

== Discord ==

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

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

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

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

Discourse Modeling

2022-11-13T13:44:19Z

Karola: /* Observations & Open Problems */

Discourse Modeling

2022-11-13T13:41:32Z

Karola: /* Observations & Open Problems */

Discourse Modeling

2022-11-13T13:28:30Z

Karola: Day 1 progress

Discourse Modeling

2022-11-13T11:03:36Z

Karola: /* Workshop Goals */

Discourse Modeling

2022-11-13T11:02:13Z

Karola: added workshop goals

Talk:Discourse Modeling

2022-11-12T22:38:06Z

Karola: /* Section 2 Konrad */

== 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 agaora ad-hov
* - 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
*

Talk:Discourse Modeling

2022-11-12T22:26:42Z

Karola: /* Squad goals: */

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

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

Talk:Discourse Modeling

2022-11-12T22:24:53Z

Karola: /* Section 3 Kyle */

== Section 1 KK ==
=== Squad goals: ===
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

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

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

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

Talk:Discourse Modeling

2022-11-12T22:24:41Z

Karola: /* Section 2 Konrad */

== Section 1 KK ==
=== Squad goals: ===
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

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

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

== Section 3 Kyle ==

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

Talk:Discourse Modeling

2022-11-12T22:24:19Z

Karola: /* Squad goals: */

== Section 1 KK ==
=== Squad goals: ===
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
**[[claim]] this entails making DGs part of the wiki and shareable
**[[claim]] relevant tools include wolfram/mathematica & wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

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

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

- sj: need to capture axioms / assumptions
- kh: making tacit knowledge explicit!!

== Section 3 Kyle ==

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

Talk:Discourse Modeling

2022-11-12T22:22:58Z

Karola: /* Section 1 KK */

== Section 1 KK ==
=== Squad goals: ===
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
** part of the wiki and shareable
*** relevant tools:
***wolfram/mathematica
***wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]] this (federation) project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

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

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

- sj: need to capture axioms / assumptions
- kh: making tacit knowledge explicit!!

== Section 3 Kyle ==

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

Talk:Discourse Modeling

2022-11-12T22:21:45Z

Karola: /* Section 1 KK */

== Section 1 KK ==
=== Squad goals: ===
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
** part of the wiki and shareable
*** relevant tools:
***wolfram/mathematica
***wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]]this project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

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

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

- sj: need to capture axioms / assumptions
- kh: making tacit knowledge explicit!!

== Section 3 Kyle ==

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

Talk:Discourse Modeling

2022-11-12T22:08:34Z

Karola: /* Section 1 KK */

== Section 1 KK ==
=== Squad goals: ===
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
** part of the wiki and shareable
*** relevant tools:
***wolfram/mathematica
***wiki functions
***[[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
**SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
***SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
***SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
***KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
** [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
***[[question]] how can we build on this and extend it?
***[[claim]]this project is more of a long-term coordination, determining who is interested in doing what over the next few years
***[[question]]federation as in federated wiki?
*** [[claim]] this is more of a a meta-project, don't expect an artefact

*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
* - [[claim]] in wiki each page has a single version --> federated wiki is the solution
* - [[claim]] pages in a federated wiki are more like working in branches as in git
* - [[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* - (federation model)
* - (conflict resolution)
* - [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start o ut by creating DGs to which readers will respond
* - [[question]] how can you start w something highly formalized like version control and meet in the middle at something suitable for narratives?
* - [[evidence]] everything2
* - [[evidence]] agora
* - [[question]] can we enable effective and usable graph visualizations?
* - [[question]] do DG graph properties scale to communally edited collaborative graphs?
* - reader --> author transition
* - [[question]] KH: will the "author" label on scientific papers disappear as collaborations grow?
* - SJ: what types of graph are we talking about?
* - I haven't seen dgs about discourse: chains of reasoning, mapping out arguments - these can be linear if there is a dialog
* - composite graph of discourse addressing the same issues
* - personal or group notetaking: connections are not discourse connections
* - reference
* - clarifiers
* - links of definitions

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

- sj: need to capture axioms / assumptions
- kh: making tacit knowledge explicit!!

== Section 3 Kyle ==

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

Talk:Discourse Modeling

2022-11-12T21:41:09Z

Karola: further dg annotations

== Section 1 KK ==
=== Squad goals: ===
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
* part of the wiki and shareable
* relevant tools:
* wolfram/mathematica
* wiki functions
* [[claim]] it is possible and useful to integrate wolfram with semantic media wiki: looks possible to take the wolfram toolset & integrate it with the toolset of this wiki to accomplish the same things as wiki functions
* SJ: [[claim]] it is also desirable to create a namespace of functions that any contributor to functions can edit
* SJ: [[claim]] one desirable property is the ability to fork functions to create others derivative functions without disturbing the operation of the original functions -- this exists for wikifunctions
* SJ: [[claim]] in the ideal case, as we see for wikifunctions, DG functions could be v local - just defined by whoever is using that graph
* KH: [[evidence]] wikifunctions were intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in - a catalogue of functions written in any language you'd like
* KH: [[question]] can we develop systems and process for federated knowledge synthesis?
* [[claim]] the first steps involved would be getting people together & doing a survey of prior work (eg anagora)
* - how can we build on this and go on
* - more of a coordination of who is interested in doing what over the next few years
* - federation as in federated wiki
* [[claim]] this is more of a a meta-project, don't expect an artefact

* - [[question]] problem with wiki is that there is only one version of each page - what if you disagree?
* - [[claim]] in wiki each page has a single version --> federated wiki is the solution
* - [[claim]] pages in a federated wiki are more like working in branches as in git
* - [[claim]] *branches* and *merges* are important ideas in the federated wiki concept space
* - (federation model)
* - (conflict resolution)
* - [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start o ut by creating DGs to which readers will respond
* - [[question]] how can you start w something highly formalized like version control and meet in the middle at something suitable for narratives?
* - [[evidence]] everything2
* - [[evidence]] agora
* - [[question]] can we enable effective and usable graph visualizations?
* - [[question]] do DG graph properties scale to communally edited collaborative graphs?
* - reader --> author transition
* - [[question]] KH: will the "author" label on scientific papers disappear as collaborations grow?
* - SJ: what types of graph are we talking about?
* - I haven't seen dgs about discourse: chains of reasoning, mapping out arguments - these can be linear if there is a dialog
* - composite graph of discourse addressing the same issues
* - personal or group notetaking: connections are not discourse connections
* - reference
* - clarifiers
* - links of definitions

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

- sj: need to capture axioms / assumptions
- kh: making tacit knowledge explicit!!

== Section 3 Kyle ==

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

Talk:Discourse Modeling

2022-11-12T17:08:16Z

Karola: /* Section 1 KK */

== Section 1 KK ==
* - Kyle's goals:
* KM: build the queries needed to interact with the Discourse Graph data model
* - part of the wiki and shareable
* - tools:
* - wolfram/mathematica
* - wiki functions
* - 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
* - namespace of functions that any contributor to functions can edit
* - can fork functions to create others derivative functions without disturbing the operation of the original functions
* - functions could be v local - just defined by whoever is using that graph
* - KH: wikifunctions intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in
* - catalogue of functions written in any language you'd like
* - KH: federated knowledge synthesis - more a meta-project, don't expect an artefact
* - get people together
* - do a survey of prior work (eg anagora)
* - how can we build on this and go on
* - more of a coordination of who is interested in doing what over the next few years
* - federation as in federated wiki
* - [[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
* - (federation model)
* - (conflict resolution)
* - [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start o ut by creating DGs to which readers will respond
* - [[question]] how can you start w something highly formalized like version control and meet in the middle at something suitable for narratives?
* - [[evidence]] everything2
* - [[evidence]] agora
* - [[question]] can we enable effective and usable graph visualizations?
* - [[question]] do DG graph properties scale to communally edited collaborative graphs?
* - reader --> author transition
* - [[question]] KH: will the "author" label on scientific papers disappear as collaborations grow?
* - SJ: what types of graph are we talking about?
* - I haven't seen dgs about discourse: chains of reasoning, mapping out arguments - these can be linear if there is a dialog
* - composite graph of discourse addressing the same issues
* - personal or group notetaking: connections are not discourse connections
* - reference
* - clarifiers
* - links of definitions

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

- sj: need to capture axioms / assumptions
- kh: making tacit knowledge explicit!!

== Section 3 Kyle ==

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

Talk:Discourse Modeling

2022-11-12T17:07:54Z

Karola: add bulk discussion

== Section 1 KK ==
- Kyle's goals:
KM: build the queries needed to interact with the Discourse Graph data model
- part of the wiki and shareable
- tools:
- wolfram/mathematica
- wiki functions
- 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
- namespace of functions that any contributor to functions can edit
- can fork functions to create others derivative functions without disturbing the operation of the original functions
- functions could be v local - just defined by whoever is using that graph
- KH: wikifunctions intended to be a way to add code (abstract wikipedia) write page without knowing which language it would be displayed in
- catalogue of functions written in any language you'd like
- KH: federated knowledge synthesis - more a meta-project, don't expect an artefact
- get people together
- do a survey of prior work (eg anagora)
- how can we build on this and go on
- more of a coordination of who is interested in doing what over the next few years
- federation as in federated wiki
- [[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
- (federation model)
- (conflict resolution)
- [[claim]] we talk about DGs as if they are done by the *reader* of a paper, but at some point, *authors* will start o ut by creating DGs to which readers will respond
- [[question]] how can you start w something highly formalized like version control and meet in the middle at something suitable for narratives?
- [[evidence]] everything2
- [[evidence]] agora
- [[question]] can we enable effective and usable graph visualizations?
- [[question]] do DG graph properties scale to communally edited collaborative graphs?
- reader --> author transition
- [[question]] KH: will the "author" label on scientific papers disappear as collaborations grow?
- SJ: what types of graph are we talking about?
- I haven't seen dgs about discourse: chains of reasoning, mapping out arguments - these can be linear if there is a dialog
- composite graph of discourse addressing the same issues
- personal or group notetaking: connections are not discourse connections
- reference
- clarifiers
- links of definitions

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

- sj: need to capture axioms / assumptions
- kh: making tacit knowledge explicit!!

== Section 3 Kyle ==

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

Making Discourse Graphs Indexable & Discoverable

2022-11-12T12:21:39Z

Karola:

{{Project
|Decription=Define a schema for a Discourse Graph and create instructions for how to generate a graph. Integrate Discourse Graphs with wiki conventions and spaces.
|Topics=Discourse Graphs, wiki
||Discord Channel Name=
|Discord Channel URL=
|Contributors=[[Karola Kirsanow]]
|Members=
|Description=Define a schema for a Discourse Graph and create instructions for how to generate a graph. Integrate Discourse Graphs with wiki conventions and spaces.
}}

[[Part of::Discourse Modeling]]
*Contributors
**[[Karola Kirsanow]]
=== Idea ===
We want to create a clear path for folks to publish discourse graphs that can be published and referenced by others: we want to make shared [[Discourse Graphs]] indexable and discoverable

==== Data Shapes ====
We want to specify and promulgate a set of schema or data shapes -- like a [https://rawgit.com/shexSpec/shex.js/wikidata/doc/micro-tutorial.html ShEx schema]-- for Discourse Graphs, so that existing graphs can be recognized in the wild, and so that existing data can be more easily organized into a d/graph.

''rationale:'' if we can automate shape creation, we can create discourse graphs at scale, and support the conversion of datasets to d/graphs at scale.

==== Namespaces ====
We want to map out a a strategy for creating discourse graph namespaces: a ''namespace practice'' that includes

* a unique mapping of an identifying string to an instance of an item
* a way of capturing & indicating timestamped snapshots of the referent

We believe this implies developing community of practice about ''namespace resolution'': resolving the situation where graphs overlap and conflict, but there is broad agreement that they address the same topic. This could be as simple as appending further descriptors when there is a potential name collision, wikipedia style. This project might involve creating or discovering a ''clustering rule'': a way of determining/declaring the family of related d/graphs a for any focal d/graph. Ideally, we'd also like to align on a practice for attaching metadata to a d\graph.

=== Implementation ===
We think a good start to this process will be to

* define a templateable unit for a discourse graph
* write instructions for how to generate a stub
* and set up a wiki for d/graphs to start working on the namespace and discovery issue

[[Category:Project]]

Discourse Modeling

2022-11-12T12:13:39Z

Karola:

Discourse Modeling

2022-11-12T12:13:01Z

Karola: add project category

<nowiki>[[Category:Project]]</nowiki>{{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=Arthur Perret, Karola Kirsanow, Kyle MacLaury, Peter Murray-Rust, Konrad Hinsen
|Description=Implement Discourse Graph schema in Semantic MediaWiki. Query Discourse Graph contents through SMW sparql endpoint. Visualize and publish Discourse Graph contents.
}}
== What ==

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 thesemantic climate setting that [[Peter Murray-Rust]] is working on

== Potential Actions ==
* Implement the Discourse Graph schema within the workshop's Semantic MediaWiki instance
** This may be duplicated by [[Making Discourse Graphs Indexable & Discoverable]]
* [[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

=== Modules ===
There are other
* [[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

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

Making Discourse Graphs Indexable & Discoverable

2022-11-12T12:03:09Z

Karola:

[[Part of::Discourse Modeling]]
*Contributors
**[[Karola Kirsanow]]
=== Idea ===
We want to create a clear path for folks to publish discourse graphs that can be published and referenced by others: we want to make shared [[Discourse Graphs]] indexable and discoverable

==== Data Shapes ====
We want to specify and promulgate a set of schema or data shapes -- like a [https://rawgit.com/shexSpec/shex.js/wikidata/doc/micro-tutorial.html ShEx schema]-- for Discourse Graphs, so that existing graphs can be recognized in the wild, and so that existing data can be more easily organized into a d/graph.

''rationale:'' if we can automate shape creation, we can create discourse graphs at scale, and support the conversion of datasets to d/graphs at scale.

==== Namespaces ====
We want to map out a a strategy for creating discourse graph namespaces: a ''namespace practice'' that includes

* a unique mapping of an identifying string to an instance of an item
* a way of capturing & indicating timestamped snapshots of the referent

We believe this implies developing community of practice about ''namespace resolution'': resolving the situation where graphs overlap and conflict, but there is broad agreement that they address the same topic. This could be as simple as appending further descriptors when there is a potential name collision, wikipedia style. This project might involve creating or discovering a ''clustering rule'': a way of determining/declaring the family of related d/graphs a for any focal d/graph. Ideally, we'd also like to align on a practice for attaching metadata to a d\graph.

=== Implementation ===
We think a good start to this process will be to

* define a templateable unit for a discourse graph
* write instructions for how to generate a stub
* and set up a wiki for d/graphs to start working on the namespace and discovery issue

[[Category:Project]]

Making Discourse Graphs Indexable & Discoverable

2022-11-12T12:02:18Z

Karola:

[[Part of::Discourse Modeling]]
*Contributors
**Karola Kirsanow
=== Idea ===
We want to create a clear path for folks to publish discourse graphs that can be published and referenced by others: we want to make shared [[Discourse Graphs]] indexable and discoverable

==== Data Shapes ====
We want to specify and promulgate a set of schema or data shapes -- like a [https://rawgit.com/shexSpec/shex.js/wikidata/doc/micro-tutorial.html ShEx schema]-- for Discourse Graphs, so that existing graphs can be recognized in the wild, and so that existing data can be more easily organized into a d/graph.

''rationale:'' if we can automate shape creation, we can create discourse graphs at scale, and support the conversion of datasets to d/graphs at scale.

==== Namespaces ====
We want to map out a a strategy for creating discourse graph namespaces: a ''namespace practice'' that includes

* a unique mapping of an identifying string to an instance of an item
* a way of capturing & indicating timestamped snapshots of the referent

We believe this implies developing community of practice about ''namespace resolution'': resolving the situation where graphs overlap and conflict, but there is broad agreement that they address the same topic. This could be as simple as appending further descriptors when there is a potential name collision, wikipedia style. This project might involve creating or discovering a ''clustering rule'': a way of determining/declaring the family of related d/graphs a for any focal d/graph. Ideally, we'd also like to align on a practice for attaching metadata to a d\graph.

=== Implementation ===
We think a good start to this process will be to

* define a templateable unit for a discourse graph
* write instructions for how to generate a stub
* and set up a wiki for d/graphs to start working on the namespace and discovery issue

[[Category:Project]]

Making Discourse Graphs Indexable & Discoverable

2022-11-12T12:01:45Z

Karola: add contributor

[[Part of::Discourse Modeling]]
*Contributors
**<nowiki>[[Has Contributor: Karola Kirsanow]]</nowiki>
=== Idea ===
We want to create a clear path for folks to publish discourse graphs that can be published and referenced by others: we want to make shared [[Discourse Graphs]] indexable and discoverable

==== Data Shapes ====
We want to specify and promulgate a set of schema or data shapes -- like a [https://rawgit.com/shexSpec/shex.js/wikidata/doc/micro-tutorial.html ShEx schema]-- for Discourse Graphs, so that existing graphs can be recognized in the wild, and so that existing data can be more easily organized into a d/graph.

''rationale:'' if we can automate shape creation, we can create discourse graphs at scale, and support the conversion of datasets to d/graphs at scale.

==== Namespaces ====
We want to map out a a strategy for creating discourse graph namespaces: a ''namespace practice'' that includes

* a unique mapping of an identifying string to an instance of an item
* a way of capturing & indicating timestamped snapshots of the referent

We believe this implies developing community of practice about ''namespace resolution'': resolving the situation where graphs overlap and conflict, but there is broad agreement that they address the same topic. This could be as simple as appending further descriptors when there is a potential name collision, wikipedia style. This project might involve creating or discovering a ''clustering rule'': a way of determining/declaring the family of related d/graphs a for any focal d/graph. Ideally, we'd also like to align on a practice for attaching metadata to a d\graph.

=== Implementation ===
We think a good start to this process will be to

* define a templateable unit for a discourse graph
* write instructions for how to generate a stub
* and set up a wiki for d/graphs to start working on the namespace and discovery issue

[[Category:Project]]

Making Discourse Graphs Indexable & Discoverable

2022-11-09T14:53:38Z

Karola: added dgraph discovery idea

=== Idea ===
We want to create a clear path for folks to publish discourse graphs that can be published and referenced by others: we want to make shared [[Discourse Graphs]] indexable and discoverable

==== Data Shapes ====
We want to specify and promulgate a set of schema or data shapes -- like a [https://rawgit.com/shexSpec/shex.js/wikidata/doc/micro-tutorial.html ShEx schema]-- for Discourse Graphs, so that existing graphs can be recognized in the wild, and so that existing data can be more easily organized into a d/graph.

''rationale:'' if we can automate shape creation, we can create discourse graphs at scale, and support the conversion of datasets to d/graphs at scale.

==== Namespaces ====
We want to map out a a strategy for creating discourse graph namespaces: a ''namespace practice'' that includes

* a unique mapping of an identifying string to an instance of an item
* a way of capturing & indicating timestamped snapshots of the referent

We believe this implies developing community of practice about ''namespace resolution'': resolving the situation where graphs overlap and conflict, but there is broad agreement that they address the same topic. This could be as simple as appending further descriptors when there is a potential name collision, wikipedia style. This project might involve creating or discovering a ''clustering rule'': a way of determining/declaring the family of related d/graphs a for any focal d/graph. Ideally, we'd also like to align on a practice for attaching metadata to a d\graph.

=== Implementation ===
We think a good start to this process will be to

* define a templateable unit for a discourse graph
* write instructions for how to generate a stub
* and set up a wiki for d/graphs to start working on the namespace and discovery issue

Project Ideas

2022-11-09T14:45:25Z

Karola: /* 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]] =

Project Ideas

2022-11-09T14:43:59Z

Karola: added a project idea about indexing dgs

Karola Kirsanow

2022-11-04T09:22:35Z

Karola:

{{Participant
|Timezone=CET (GMT+01:00/GMT+02:00)
|Homepage=http://www.wutbot.com/ , https://research.protocol.ai/authors/karola-kirsanow/
|Affiliation=Protocol.ai
|Interests=Credit Assignment, Synthesis, Scholcomm, Protocols, Incentive Systems, Decentralization, Knowledge Network
|Github=KarolaKirsanow
}}
{{Workshop Submission
|Interest=I'm a Research Program Manager at Protocol Labs, an open-source R&D lab building technologies for internet decentralization. I'm broadly interested in developing tools and incentive systems to support decentralized research workflows: collaboration across institutional boundaries, collaborations including unaffiliated researchers or singleton contributors, self-organizing and self-sustaining communities of knowledge and practice, and related issues.
|Frame=Practitioner, Tool-builder
|Materials=My team has been working with discourse graphs and research roadmaps as a method of exploring the knowledge frontier and constructing research initiatives, and we've described some of our approaches in [this talk](https://www.youtube.com/watch?v=P0KUt2yrUkw&t=5s).
}}
In addition to solving technological problems surrounding modes of communication, synthesis, and dissemination, I'm interested in exploring the construction of incentive systems supporting the open exchange of information about the current position of the knowledge frontier.

I'm also interested in questions surrounding the transfer of tacit knowledge, particularly in the laboratory sciences. Here I'm influenced by the work of [Collins and Polanyi](https://orca.cardiff.ac.uk/id/eprint/71069/1/wrkgpaper1.pdf).

Karola Kirsanow

2022-11-04T09:21:17Z

Karola: add interests

{{Participant
|Timezone=CET (GMT+01:00/GMT+02:00)
|Homepage=http://www.wutbot.com/ , https://research.protocol.ai/authors/karola-kirsanow/
|Affiliation=Protocol.ai
|Interests=Credit Assignment, Synthesis, Scholcomm, Protocols, Incentive Systems, Decentralization, Knowledge Network
|Github=KarolaKirsanow
}}
{{Workshop Submission
|Interest=I'm a Research Program Manager at Protocol Labs, an open-source R&D lab building technologies for internet decentralization. I'm broadly interested in developing tools and incentive systems to support decentralized research workflows: collaboration across institutional boundaries, collaborations including unaffiliated researchers or singleton contributors, self-organizing and self-sustaining communities of knowledge and practice, and related issues.

In addition to solving technological problems surrounding modes of communication, synthesis, and dissemination, I'm interested in exploring the construction of incentive systems supporting the open exchange of information about the current position of the knowledge frontier.

I'm also interested in questions surrounding the transfer of tacit knowledge, particularly in the laboratory sciences. Here I'm influenced by the work of [Collins and Polanyi](https://orca.cardiff.ac.uk/id/eprint/71069/1/wrkgpaper1.pdf).
|Frame=Practitioner, Tool-builder
|Materials=My team has been working with discourse graphs and research roadmaps as a method of exploring the knowledge frontier and constructing research initiatives, and we've described some of our approaches in [this talk](https://www.youtube.com/watch?v=P0KUt2yrUkw&t=5s).
}}

Template:Workshop Submission

2022-11-04T09:19:46Z

Karola: /* What's your interest in this workshop? */

<noinclude>
{{#template_params:Interest (label=What's your interest in this workshop?;property=Interest)|Frame (label=With what "frame" do you approach the workshop? (or identity)?;property=Has Frame)|Materials (label=What materials can you contribute to the workshop for consideration?;property=Materials)|Organizer Topics (label=Organizer-estimated Topics;list;property=Interested In)}}
</noinclude><includeonly>
== Workshop Submission ==
===What's your interest in this workshop?===
I'm a Research Program Manager at Protocol Labs, an open-source R&D lab building technologies for internet decentralization. I'm broadly interested in developing tools and incentive systems to support decentralized research workflows: collaboration across institutional boundaries, collaborations including unaffiliated researchers or singleton contributors, self-organizing and self-sustaining communities of knowledge and practice, and related issues.

===With what "frame" do you approach the workshop? (or identity)?===
[[Has Frame::{{{Frame|}}}]]

===What materials can you contribute to the workshop for consideration?===
{{{Materials|}}}

===Organizer-estimated Topics===
{{#arraymap:{{{Organizer Topics|}}}|,|x|[[Interested In::x]]}}

</includeonly>

Karola Kirsanow

2022-11-03T11:35:57Z

Karola: Created page with "{{Participant |Timezone=CET (GMT+01:00/GMT+02:00) |Homepage=http://www.wutbot.com/ , https://research.protocol.ai/authors/karola-kirsanow/ |Affiliation=Protocol.ai |Interests=Credit Assignment, Synthesis, Scholcomm, Protocols, Incentive Systems, Decentralization, Knowledge Network |Github=KarolaKirsanow }} {{Workshop Submission}}"