42
edits
Talk:Discourse Modeling: Difference between revisions
Talk:Discourse Modeling (view source)
Revision as of 18:55, 23 November 2022
, 18:55, 23 November 2022→Day 2
m (→Day 2) |
|||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 5: | Line 5: | ||
* KK: [[Karola Kirsanow]] | * KK: [[Karola Kirsanow]] | ||
* KH: [[Konrad Hinsen]] | * KH: [[Konrad Hinsen]] | ||
* DA: [[Deniz Aydemir]] | |||
== Section 1 KK == | == Section 1 KK == | ||
=== Squad goals: === | === Squad goals: === | ||
==== Building Queries==== | ==== Building Queries==== | ||
| Line 33: | Line 34: | ||
|supports=}} | |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=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?| | *** {{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=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?| | *** {{d|id=fed-as-in-wiki |a=? |type=question |text=federation as in federated wiki?|extends=survey-first}} | ||
<!-- | <!-- | ||
| Line 49: | Line 50: | ||
* {{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=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 |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 | | ** {{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=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-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=}} | ||
| Line 148: | Line 149: | ||
*KH: [[proposal]] making tacit knowledge explicit!! | *KH: [[proposal]] making tacit knowledge explicit!! | ||
== Section 3 Kyle == | == Section 3 Kyle == | ||
* {{d|id= |a= |type= | * {{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= |type=question |text=do we start with a schema or refine as we go? |supports=}} | ||
** {{d|id= |a=SJ |type=claim |text=smw makes this hard for exactly this reason (deciding up front is friction). |supports=}} | ** {{d|id= |a=SJ |type=claim |text=smw makes this hard for exactly this reason (deciding up front is friction). |supports=start-w-schemas}} | ||
** {{d|id= |a= |type=claim |text=easier with free form mediawiki templates and wiki text |supports=}} | ** {{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=}} | *** {{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=}} | *** {{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? | | ** {{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=}} | *** {{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=}} | *** {{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=template-start |a=KK |type=question |text=should we start with creating a "source" template: source: url, publisher, date, author ? |supports=}} | ||
| Line 230: | Line 231: | ||
* - sj: a great next step would be intifying a discussion wewant to capture | * - sj: a great next step would be intifying a discussion wewant to capture | ||
--> | --> | ||
== 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 }} | |||