Synthesis Infrastructures

Talk:Discourse Modeling: Difference between revisions

Talk:Discourse Modeling (view source)

Revision as of 18:55, 23 November 2022

22,451 bytes added ,  18:55, 23 November 2022
m
→‎Day 2
 
(32 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Section 1 KK ==
== 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: ===
=== 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}} 
<!--
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
* KM: [[question]] can we build the queries needed to interact with the Discourse Graph data model?
** part of the wiki and shareable
**[[claim]] this entails making DGs part of the wiki and shareable
*** relevant tools:
**[[claim]] relevant tools include  wolfram/mathematica & wiki functions
***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
***[[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]] it is also desirable to create a namespace of functions that any contributor to functions can edit
Line 11: Line 28:
***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
***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: [[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?  
-->
 
==== 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}}
 
<!--
* [[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)
** [[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?
***[[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
***[[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?
***[[question]] federation as in federated wiki?
*** [[claim]] this is more of a  a meta-project, don't expect an artefact
*** [[claim]] this is more of a meta-project, don't expect an artefact
-->


==== 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=}}
<!--
*[[question]] problem with wiki is that there is only one version of each page - what if you disagree?
*[[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]] 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]] 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
***[[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: [[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?
**KH: [[question]] will the "author" label on scientific papers disappear as collaborations grow?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] can we enable effective and usable graph visualizations?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?
*[[question]] do DG graph properties scale to communally edited collaborative graphs?
-->


==== 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}}
<!--
*[[question]] how can you start w/ something highly formalized like version control and meet in the middle at something suitable for 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://everything2.com/ everything2]
Line 34: Line 85:
**SJ: [[question]] what does composite graph  of discourse addressing the same issues look like?
**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
**SJ:  [[claim]] personal or group notetaking: connections are not discourse connections - they include refrences, clarifiers, and links of definitions
* {{d|id= |a=  |type=claim |text= |supports=}}
-->


== Section 2 Konrad ==
== 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
=== A [[Discourse Graph]] for our own Wiki ===
- kh: making tacit knowledge explicit!!
 
*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=}}
 
<!--
* {{d|id= |a=  |type=claim |text=|supports=}}
* {{d|id= |a=  |type=claim |text=|supports=}}
* - 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
-->


== Section 3 Kyle ==
== Day 2  ==


- decision: start with naming & schemas first
* {{d|id=structure |a=KM |type=claim |text= defined categories for each of our data objects but not for axioms}}
- do we start with a schema or refine as we go?
*  {{d|id=structure |a=KM |type=claim |text=defined a schema and tried to define a form that will use a schema}}
- sj: smw makes this hard for exactly this reason
* {{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)
- easier with free form wiki templates and wiki text
*  {{d|id=structure |a=KM |type=claim |text=forms not working well to create instances - this probably means that they are not well-specified}}
- tiny Lua templates (don't need to write Lua)
*{{ {{d|id=structure |a=KK |type=question |text= should we use forms versus templates?}}
- define any number of fields
*  {{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 }}
- define how they are presented
*  {{d|id=structure |a=KM |type=claim |text= records in the db that are targetable }}
- this is just mediawiki w/o the semantic extension
*  {{d|id=structure |a=KM |type=claim |text=there are improvements to be made on the wiki side}}
- make a mediawiki entry for every thing that has a shape
*  {{d|id=structure |a=SJ |type=question |text=SJ: which page were you working on for that?}}
- edit that v flexibly, schema changes won't break things, won't cascade illegibility
*  {{d|id=structure |a=KM |type=claim |text= filling in materials under the group & trying to  (screen share) }}
- at scale: smw wiki extension enables multiple dynamic table updates as data changes
* (KM: do not assume intentionality)
- KK: question: problem extending to smw later?
* {{d|id=structure |a=KM |type=claim |text= for a source - we'd add the source category to each participant page}}
- no
* {{d|id=structure |a=KM |type=claim |text= properties like "informs" remain to be defined }}
- not as long as template is compatible with smw
* {{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 }}
- we can do this by hand - dozen schemas
* {{d|id=structure |a=KH |type=claim |text= separate pages work ok for sources }}
- we can then decide whether we want to do smw or use wikidata & their respective modelling tradeoffs
* {{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}}
- start with creating a "source" template: source: url, publisher, date, author ?
*  {{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}}
- kk: [[question]]  will defining edges/relationships turn out to be more complicated than creating templates for nodes?
** {{d|id=structure |a=SJ  |type=claim |text=SJ: talk page is a linearization - compact way of viewing, but there are others}}
- KK: how do we know when we are done?
*{{d|id=SMW |a=SJ  |type=question |text=SJ: how good are the default SMW views?}}
- SJ: need to create an internally consistent way of sharing templates
* {{d|id=structure |a=SJ  |type=claim |text=SJ we haven't really tied any claims to evidence}}
- kH: templates are universally available, which means that anyone can break our template
* {{d|id=structure |a=KH  |type=claim |text= KH: at some point we want each of these things an entity we can refer to
- KM: should we decompose the Q into further properties (like a Q has a subject and object) or leave it nat language
* refer to things by their anchors - this is a wiki way of doing this}}
- KH: we should stick to nat language
* {{d|id=structure |a=SJ  |type=claim |text=SJ: could have a template that includes an ID}}
- KH: if you represent a dg in a wiki, what is a page? what's the granularity? every source is a page?
** {{d|id=identity |a=KH  |type=question |text=KH: is it up to authors to ensure IDs are unique?}}
- KM: seems like everything is a page?
*** {{d|id=identity |a=SJ  |type=claim |text=SJ: or plugin drawing from a db}}
- sj: sections of a page are not a page
** {{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 }}
- sj: everything we want to be a node should be a page
** {{d|id=structure |a=KK  |type=question |text=do we want to make claims subordinate the source?}}
- sj: wiki supports transclusion
* {{d|id=structure |a=KK  |type=question |text=KK: how much about the structure of our discourse should we understand beforehand?}}
- kh: then each pp needs a title - lots of work
* {{d|id=structure |a=DA  |type=claim |text=DA: this is an argument for everything being its own page}}
- sj: this is a q iof interfaces - we can do it this way for a demo
*{{d|id=structure |a=KH |type=claim |text=KH: then we're back to every title being an ID}}
- KH: makes the history list a bit busy - this is a ux question affecting exploration
** {{d|id=structure |a=SJ  |type=claim |text=SJ: solving an infrastructure and a stat structure q at the same time --
- KK: many to many relationships between sources & evidence
** visualize a bunch of nodes together on the same page - how we split up our convo yesterday
- source property could be a url and we could create an entity for the source that scrapes data and populates fields
**if we write a tool to autocomplete claims or sources - re-use - appearance on the page would not subordinate it to the page
- if you expect something will be used more than once you probably want it to have the full data
** here's a collection of nodes and links relevant to the subject of the page -- each could appear i nmultiple places}}
- sj: claim: this level of precision is important to dgs
* {{d|id=structure |a=SJ  |type=claim |text=SJ: individual pages work}}
- sj: claim wiki recent changes scale well
* {{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: we can use wikibase to scale ux issues and hide certain types of history (eg source edits)
* SJ: I'll add an additional Id field to make it clear how it will map to a wikibase }}
- KH: first attempt: everything is a page, we rely on transclusion to group things
* {{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}}
- KH: can we have the entire Q as a page title?
** {{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}}
- sj: this gets to my interest, naming
* {{d|id=goal |a=KH  |type=question |text=KH: can we move onto our final goal in a reasonable amount of time?}}
- sj: a great next step would be intifying a discussion wewant to capture
* {{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 }}
Karola
42

edits

Retrieved from "https://synthesis.jon-e.net/Special:MobileDiff/1244...1500"