User:Dan

Collecting and analyzing evidence impact related to a predicate X

We will want some way to guide new users through expressing "why" they believe X to be true or false, so that their explanation is a) easily understood and analyzable, and b) ratable. As part of this process, the user may want to link to evidence supporting their vote. As a side note, a thorough user may desire to add both evidence supporting and rejecting X.

When adding evidence, it is important to construct one or more impact arguments that explains why the evidence is relevant to X. User's will vote for/against such impact arguments. Sub-arguments can also be created on an impact predicate to argue for/against the impact predicate's truth.

At first thought, there's several ways impact arguments can be structured: 1. Impact argument that evidence argues for predicate. 2. Impact argument that evidence argues against predicate. 3. Impact argument that evidence doesn't impact predicate.

In the case of for/against, the evidence could have varying "amounts" of impact, how can that be quanitified? Impacts with a quantitative impact are a bit troublesome, because then we're not voting on a simple true/false predicate (or if we are, we're voting on a large number of similar ones with different quantities, which doesn't seem practical).

Users can directly rate the believability of each piece of related evidence. If the rating for the evidence is low, the importance of the impact arguments clearly won't matter much.

Directly rating the believability of documentary evidence will often be difficult, as documents may not clearly express the predicates, and they will generally contain many predicates, some true, some false.

One way to resolve this would be to add a link to the document, but extract out the key predicates required to support or oppose an argument and rate those predicates individually. In this case, the document is just a "source" from which actual evidence and impact predicates are being constructed. This will likely involve creating a higher order predicate like `If A and B and not C, then predicate X is true.` which would also need to be rated (here user's would be rating the validity of this higher order predicate argument itself, not A, B, or C.

Note in this case that several such higher order predicates could be created from the same document, with each creator arguing for a differing interpretation of the source document's meaning in relationship to X.

In addition to providing evidence, users should be able to describe how they obtained knowledge about a predicate's truth or the evidence for it. For example:

1. 'I' read 'predicateX' asserted from a source I trust: link_to_source_material or unknown 2. 'I' heard 'predicateX' asserted from a source I trust: name_of_source or unknown 3. 'I' personally experienced 'predicateX': when/context 4. 'I' personally deduced 'predicateX': when/how 5. 'I' believe 'predicateX' is true/false because of the arguments presented here: source(s).

Note that 5 is a way someone could vaguely explain why they believe something is true if they don't want to create their own detailed argument for their position, or they feel their reasoning should be clear the sources they point to. Ideally they would point to a a clearly laid out predicate argument, rather than documents, so the system should guide them through existing predicate arguments that seem likely to match their reasoning that they may want to pick from. This in turn would also likely result in them rating the argument they select as their reasoning.

The user could make similar predicate assertions for the evidence predicates.

Note that above are also predicates that could be rated by others. Only `I` can assert the statement, but others can rate the believability of the person's statement.

Notes from laadan (inspiration for recording how knowledge was obtained)

The evidence particle[3] – this occurs at the end of statements and indicates the trustworthiness of the statement.

• Known to speaker because perceived by speaker, externally or internally
• Known to speaker because self-evident
• Perceived by speaker in a dream
• Assumed true by speaker because speaker trusts source
• Assumed false by speaker because speaker distrusts source; if evil intent by the source is also assumed, the form is
• Imagined or invented by speaker, hypothetical
• Used to indicate that the speaker states a total lack of knowledge as to the validity of the matter

Types of statements

These distinctions seem like they will be useful in a decision-making system.

• Declarations
• Questions
• Commands
• Requests
• Promises
• Warnings

Ideas for Debate software prototype

Meta-data for all types of predicates

Text objects: adding non-predicate text to a debate

Text objects are any text that isn't expressible as a simple predicate. Examples of a text object would be an essay, a resume, etc. Text objects cannot be directly rated, but predicates can be attached to a text object to rate it in various ways (e.g. "This essay is written very clearly."). It would be useful to be able to "anchor" a predicate to particular locations in a text object (a word or phrase, for example).

Blobs: adding binary objects to a debate

Blobs are binary objects like pictures, spreadsheets, word processor documents, etc. Blobs can be to associate images or any non-purely textual material to a predicate. Similar to text objects, blobs can be linked to a predicate, and predicates can be linked to a blob.

It would also be useful to be able to "anchor" a predicate to particular locations in a blob, but such anchors will require knowledge of the "type" of the blob so that some appropriate coordinate system can be used.

Documents (files): text objects and blobs

In practice, we can probably classify both "text objects" and "blobs" as a single type of thing: a document file, and then have special handling for anchoring of each document type which the software "knows" about. As a minimal set of supported document types, we should support plain text objects as known types that we can anchor to interior portions of. Anchors should be hierarchical, enabling anchoring to a portion of an image inside a word document, for example.

Tags: adding tags to predicates

• One or more domain topic tags can be assigned to a predicate. Whenever a tag is assigned to a predicate, this generates a first-class predicate that is vote-able to determine the accuracy of the tag. E.g. if predicate X is tagged with the “biology” tag, then a predicate is auto-generated that states: “predicate X is related to biology”). Tags themselves are not actual predicates, however, they are more like a grouping mechanism for a set of predicates. Tag names should probably be at most two words long.
• We probably want some threshold number of votes on the tags before they get used by filters and voting algorithms in a community system. But we also need to be sure that these tags are "seen" so they can be voted on.
• Topics themselves will need rating, so there’s probably another predicate associated with each tag like “I find X a useful tag for filtering”.

Linking predicates (and objects)

• How should we categorize links? Here's some of the "types" of links I think I've described in this writeup: 1) links between rewordings of a predicate, 2) links between an argument and the pro/con sub-arguments, 3) links between a policy and debates related to the policy, 4) Arguments and the tags (tag predicates) that apply to them, 5) links between predicates and objects.
• I think basically all the links we establish between predicates in this system should be bidirectional, but assuming we’re using a database for the links I guess we have that already. But even though they should be bidirectionally travelable, the links often do have a "direction" of a sort, often being one where there is an initial predicate that "inspires" the other predicate. For example, a reworded predicate inspired by another predicate, a debate sparked by a policy proposal, an image added to support an argument versus a predicate added to rate the image, etc.

Data editing

For the most part, we probably want to maintain an immutable history of edits to the database, so rather than editing data we may want to use a copy-on-write style of editing.

Data model for policy votes

• In a community rating system, members vote on a “community-binding” predicate to undertake or not undertake a specific policy. A policy describes a set of actions to be performed. These actions can be either very high-level and vague, or very concrete actions.
• One or more debates will likely be created to discuss issues of competing policies being voted on by the community. We need a mechanism for linking policy predicates to debate predicates.

Data model for debates

• Each debate argument is a predicate. And similarly, any predicate can be debated.
• Sub-arguments can be linked to a parent argument in some manner that allows both an understanding of and a calculatable impact of the sub-argument on the parent argument. WHAT FORM?
• No predicate is ever edited, but new predicates can be reworded with a reworded link to old ones. A rewording link isn’t strictly necessary, but these may allow for a better understanding of how a debate has evolved over time.
• If a predicate is reworded, what mechanism(s) could be used to attach old sub-arguments to the new predicate (some may no longer even apply and certainly their impacts could change as a result, but likely most will still apply)? It will also be useful to know which rewording is currently most popular among users, this can be done by analyzing a recent history of different types of activity associated with each debate.

Example debate

Debate predicate: It is better to have 3 people make decisions for a group than have just one of the three make the decisions.

Arg1: It can take longer for 3 people to agree on a decision than one person.

Arg2: The sum total knowledge available between 3 people is larger.

Arg3: Two people may “collude” to vote for each other’s personal needs, and it is less obvious than if one person is voting just for their own personal needs.

Arg4: More time and effort is consumed if three people have to spend time thinking about and voting on a decision. This is especially wasteful if the decision making is simple and obvious.

Blob: Someone attached a powerpoint slide with graphs about experiments performed solving math problems with varying numbers of solvers.

Arg1 and Arg4 lead to reformulations to clarify that issue is about non-trivial decisions and that voting will be used rather than 100% consensus required.

Reworded debate topic: It is better to have 3 people vote on making non-trivial decisions for a group rather than just have one of the three people making the decision.

This also leads to a reworded arg4 (simple and obvious part gets dropped since debate is about non-obvious decisions now): More time and effort is consumed if three people have to spend time thinking about and voting on a decision.

Arg1 could arguably be considered a pro or con argument, since it could be argued than taking longer to decide a decision leads to better outcomes (yet another debate, now on the “impact” of the argument). So how should we model the “impact” mathematically?

Maybe it is some positive/negative scale (where positive impact values add to the computed rating for the parent predicate and negative impact values subtract from it)? Note that this could result in a case where a sub-predicate is considered to have little impact, even though two “sides” think it has a lot of impact, just in opposite directions. But this seems like a reasonable outcome.

Filtering mechanisms for predicates

Note: these filtering ideas apply both to filtering policy predicates and debate predicates.

Filtering should be done by some rating formula that results in a ranked ordering of the predicates to view, with the highest ranked at the most visible position. If predicates are paginated in this ranking, then there probably is no need for an absolute filtering out of any predicate, but we could also include some kind of hard limit (e.g. user may only want to see 10 pages of predicates or user may not want to see any predicates below some threshold rating).

A user could have multiple rating formulas that they may want to choose from, depending on what they are interested in seeing at a given time. For example, if a user wants to simply rate predicates in one of their domains of interest, they might select a rating formula that ranks high that type of predicate. Or if they want to debate a topic in near real-time, they could select a rating formula that ranks actively debated predicates.

• Users can filter based on domain tags they either want to see or don’t want to see based on voting on the accuracy of the tag.
• Users can vote directly on the importance of people seeing a predicate (not a good-bad value judgment, just voting it is an important topic that people should see).
• In cases where other people make their filters available, people can filter based on filters used by one or more other users to avoid having to create detailed filters of their own.
• Users can filter based on “linked” predicates (for example, to find or exclude all re-worded forms of a debate predicate). In such case, we might want some way to figure out which of the re-wordings is the best (which might not be the most active since it may be a new re-wording, so probably need some more thought on how this should be done).
• Individuals can filter based one or more rating systems (e.g. a specific CRS or the user’s personal SRC). There are also a number of options for how to select and combine values from multiple rating systems over the set of all predicates to determine a ranking.
• Since it is probably desirable that filters are extremely personalized, perhaps it is better to use a filter rating algorithm where the user's personal voting if specified has more dominance than the ratings of others. For example, if the user has directly rated a topic, that rating would be the one used for the topic, instead of the aggregated rating (unrated ones would still use the calculated rating, so "suggested topics" would still be findable from the user's network).
• A filter rating could be specific to a specific tagging, or even to a particular debate or policy. For example, debates on politics could be filtered to ignore arguments about dead politicians. This perhaps could be done via a combination of a tag plus a key word search.

Implementation issues

Ratings can be very dynamic. If predicates are stored in an SQL database, for example, does a user’s software just periodically update the predicates with ratings from their rating system, then generate a filtering query? Or are the raw predicates fetched from the database, then ratings fetched to use for ranking?

If the latter, seems like there would need to be filtering on which predicates get stored in the database originally. So at any given time, the database would only contain predicates that met some minimal rating formula threshold at the time it was last reported to the user’s node.

But this brings up the question of how predicates arrive at the user’s node, a question which also depends on the topology of the network.

How do predicates get added to a user’s database?

For fully connected nodes (e.g. initial community systems will fall into this category), each node will need to make a decision about every predicate that gets created (in an extreme case this could just be blocking predicates from peers that are particularly bad at generating predicates). In a subjective rating system, a node would have the option to not pass on predicates to other peers if they don’t consider them interesting/desirable, resulting in an automatic form of filtering.

There’s also the issue of whether to push or pull predicates, or some combination of both.

Both of these options allow for filtering at the network level: a push could explicitly ask for predicates with a given tag threshold on the peer it is querying or it could register with the peer that it only wants to receive pushes for predicates above the tag threshold.

Solution for now

For now, I suppose we should assume a relatively small but fully connected model, where ratings changes are constantly pushed by peers (similar to Lem’s prototype) and we update the ratings in the database.

If we use a copy-on-write methodology to allow for analysis of historical changes, then we would timestamp all the changes to a rating as reported by each peer I suppose.

In a community rating system, each peer would just directly report its own ratings “vote” change to one or more central databases that would then generate aggregated ratings.

Prototype UI

For now, I propose we should keep the prototype UI as simple as possible so we can quickly create and deploy something we can test in the real world and primarily use paginated lists displayed on each page.

I’m assuming a web browser-based UI (e.g. written in Typescript).

Here’s a list of UI areas I can think of (not all would need to be created in the prototype):

• A page to define different types of predicate rating filters. I think we should skip this page in the prototype and just have some “default” rating filters, for example one for filtering debate topics based on a direct rating of the topic’s importance, one for filtering sub arguments within a debate based on their impact, etc. because there’s a lot of different options on how we can filter and it shouldn’t be a big issue when dealing with a small number of reasonable people participating in the prototype testing. Even when we open it to some public testing, probably a simple muting mechanism for spammers is the primary need at the beginning, along with basic filtering based on tags. Filtering will become more important the more active the userbase becomes.
• A page (FILTERED DEBATE LIST) where we could see debates/policies ranked and paginated based on a dropdown at the top of the page where the user can select from available rating filters. From this page, user can select any debate/policy to navigate to.
• A page for viewing a single specific debate predicate containing (DEBATE PAGE):
• the wording of the predicate
• if reworded forms of the debate exist, links to reworded forms of the debate predicate (paginated and ranked by a rewording filter).
• immediate sub arguments (paginated and ranked by an argument filter such as rated “impact”). Sub arguments are also links to a debate on the sub argument itself, allowing for navigation down the argument tree.
• links to other debates that this is a sub-argument of, allowing navigating to any debate depending on this argument.
• A set of navigation path links at the top of the page so that user can navigate back to any point in the path that led him to the current predicate. This would need some kind of squeezing if it gets too long and we would need some way to assign “short names” for links too. This is probably too much work for now and maybe we can just rely on browser navigation for this.

Every displayed predicate should have the following info:

• the wording of the predicate
• the user’s own rating (starts as “Vote” or maybe just “?”, clickable to assign a rating)
• A direct rating of the predicates from a ratings system chosen by the user. This could be clickable to change which rating system is used based on available ratings systems/algorithms.
• a computed rating based on its sub arguments (using whatever algorithm the user selected for computing this rating). This could be clickable to change the rating algorithm.
• a button to reword the predicate. This would open a new predicate page with the wording of the old predicate as a starting point.
• a button to add a sub-argument
• Optional: we could show the “filter rating” computed by whatever filter is allowing the predicate to be displayed (this wouldn’t apply when someone directly clicks on a predicate, just when it is in a list of predicates and was determined by such a filter).

Implementation Issues:

• How should we limit the size of predicates for reasonable viewing? Maybe just a simple character limit (e.g. 160 characters and allow for a maximum of 80 characters per line and 2 lines)? Another option would be some kind of “squeezing” of predicate text when it is over a specific length (this would discourage creating long predicates without being an absolute prohibition). Both methods could be employed in tandem, with some “maximum allowed length” and a lower “squeeze length”, with the max length a database setting and the squeeze length just a UI setting.
• Need to avoid cycles when computing a rating based on sub-arguments

Other potential features

• search for predicates matching keywords
• search for sub-argument predicates matching keywords

Page Mockups

For the initial prototype, I propose we start with just a few pages: debate list, debate page, user list, and a user page.

We need to render the following types of objects: predicates, tags, documents, and users.

To simplify rendering, we will have standard widgets for objects that can appear on different pages, but the widgets will have options for different renderings depending on the context to indicate which actions are currently possible on the object. For example, on virtually any page, you can vote on a predicate. But you can't add sub arguments to a predicate unless you are on that predicate's "debate" page.

UI Element Notes:

[] indicates a button. Buttons will typically open a dialog for input or a dropdown list to select from.

Each predicate can have a list of tags associated with it. This list is shown on the predicate's page (e.g. the Debate page). Each tag is shown with a percentage relevancy (which user's can click to vote on).

[Add Arg] Opens dialog to add a sub-argument to a predicate. This can be a new predicate or an existing one (so the dialog needs both search and creation functions).

[Add Tag] Opens dialog to add related tags to the predicate.

[Creator: Dan] Click on this button to go to the activity page for the creator of the predicate.

[Arguer: Dan] Click on this button to go to the activity page of the person who linked this argument to the predicate.

[Vote Truth: NULL] This button would initially be displayed as [Vote Truth: NULL]. Once a user clicks on it and votes (just open a dialog that accepts percentage values with two decimal places for now, between 0.01 and 99.99), it would display also display user's current voted value instead of NULL (or some similar text to indicate no vote has been cast). For example, [Vote Truth: 99.99%]. Also, need a way for a user to remove their vote, for now maybe remove their vote if they delete everything in the edit box.

[Vote Impact: NULL] This button would basically work the same as the [Vote Truth] button.

[FilterDropDown] is a dropdown list showing default predicate ratings (probably one for “all tags” and then one for each tag, order alphabetically for now). There’s an implication here that predicate rating filters have “names”. Right now I use this control for essentially every "list" in the UI.

[Page Size: 20] This sets the page size of the associated list. Different lists will have different "default" sizes. User clicks this button to change the page size of the list, maybe allow values between 1-200?

PAGINATION BAR: a standard bar at the bottom of a list to allow navigation through pages in the list. Almost every list will have a pagination bar.

For now, the CRS/SRS ratings are just displayed as rating type and percentage (and the prototype would probably just show a community rating since that's probably all we'll have for the first prototype). Eventually these could be dropdown lists so that users could select which ratings they would like to see.

DEBATE LIST page (very simple page)

Debates [FilterDropDown] [PAGE SIZE: defaults to 20 per page]:

1. Dogs are better than cats. CRS (20 votes): 99% SRS: 75% [Creator] [Reword] [Vote Truth]
2. Ice cream is healthy. CRS (20 votes): 99% SRS: 75% [Creator] [Reword] [Vote Truth]
3. Table tennis is the best sport. CRS (20 votes): 99% SRS: 75% [Creator] [Reword] [Vote Truth]
4. …

PAGINATION BAR

DEBATE page (4 sections: debate predicate, rewordings, sub arguments, super arguments)

Rewordings [FilterDropDown] [PAGE SIZE: defaults to max of 3 per page]:

1. It is better to have 3 people vote on making non-trivial decisions for a group rather than just have one of the three people making the decision. CRS (20 votes): 99% SRS: 75% [Creator] [Reword] [Vote Truth] [Add Arg]

PAGINATION BAR

Arguments ranked by total impact (impact * rated truth) [FilterDropDown] [PAGE SIZE: defaults to 10 per page]:

1. The sum total knowledge available between 3 people is large than just one of them. CRS (20 votes): 99% SRS: 75% [Creator: Dan] [Arguer: Dan] [Reword] [Vote Truth] [Vote Impact] [Add Arg]
2. More time and effort is consumed if three people have to spend time thinking about and voting on a decision. This is especially wasteful if the decision making is simple and obvious. CRS (20 votes): 99% SRS: 75% [Creator: Dan] [Arguer: Dan] [Reword] [Vote Truth] [Vote Impact] [Add Arg]
3. It can take longer for 3 people to agree on a decision than one person. CRS (20 votes): 99% SRS: 75% [Creator: Dan] [Arguer: Dan] [Vote Truth] [Vote Impact] [Add Arg]
4. Two people may “collude” to vote for each other’s personal needs, and it is less obvious than if one person is voting just for their own personal needs. CRS (20 votes): 99% SRS: 75% [Creator: Dan] [Arguer: Dan] [Reword] [Vote Truth] [Vote Impact] [Add Arg]

PAGINATION BAR

Attached Files [FilterDropDown] [PAGE SIZE: defaults to 5 per page]

1. [Solve times and correctness of math solutions with multiple solvers]

Debates depending on this argument [FilterDropDown] [PAGE SIZE: defaults to 5 per page]:

1. The President of the US has too much power. CRS (20 votes): 99% SRS: 75% [Creator: Dan] [Arguer: Dan] [Reword] [Vote Truth] [Vote Impact] [Add Arg]
2. Dan should be replaced by Donna, Eric, and Pete as manager of SynaptiCAD. CRS (20 votes): 99% SRS: 75% [Creator: Dan] [Arguer: Dan] [Reword] [Vote Truth] [Vote Impact] [Add Arg]

PAGINATION BAR

USER page (one for each user)

Recent Activity [PAGE SIZE: defaults to 20 per page]:

Debate Filter: [DropDownFilter] Action Filter: [Rewords][Arguments][Impact Votes][Truth Votes] Tag Filter: [DropDownToSelectATag]

1. <Timestamp> Voted 99% on TagA for "It is better to have 3 people make decisions for a group than have just one of the three make the decisions.
2. <Timestamp> Voted 99% on truth of "It is better to have 3 people make decisions for a group than have just one of the three make the decisions."
3. <Timestamp> Created rewording of X to: "It is better to have 3 people vote on making non-trivial decisions for a group rather than just have one of the three people making the decision."
4. <Timestamp> Voted 99% on impact of "The sum total knowledge available between 3 people is larger." on "It is better to have 3 people make decisions for a group than have just one of the three make the decisions."

PAGINATION BAR

PROXIED VOTING POWER

Note: In a community rating system, we can also display someone's accumulated proxied voting weight on tags). Ordered by "All Tags" followed by the highest proxied weight on each tag.

[All Tags: +10%] [TagB: +200%] [TagA: +50%]

USER LIST page (filterable list of all users)

Users (debate filtered) [PAGE SIZE: defaults to 40 per page]: [DropDownFilter]

1. [Alice] last active ...
2. [Bob] last active ...
3. [Carol] last active ...

PAGINATION BAR

//Users can also include "bots" that auto-generate some actions.
//For example, a "pdf bot" could be added to the system to parse previously-unparseable pdf docs into sub documents.
//Or a bot could be be used to automatically assign tags to a predicate or document.
users 
id : integer not null
creation_time : timestamp not null
username : char[20] not null
firstname : text
lastname/surname : text
url : text
email : text
email_alert_frequency : time_interval

//Almost all data in the database is created via user and bot actions. The actions view tracks how the data evolves over time.
actions (for now just make a view of the associated tables) 
creation_time : timestamp
creator_id : integer not null
type : [created_tag, created_predicate, created_document, created_predicate_tag_link, created predicate_document_link, created_document_predicate_link, created_argument_link, voted_on_predicate, delegate_weight, follow_predicate, follow_user, voting_result]
details_id : integer not null that references the specific "type" table (is there some better way to do this?)

//The predicates table stores "raw" predicates, debates, and policies (debates with a decision_time)
predicates
id : integer not null
creation_time : timestamp not null
creator_id : integer not null
decision_time : timestamp
body : char[256] not null
aggregated_rating details (computed from ratings table and selected rating algorithm each time their is a vote)
  aggregated_rating   : money not null
  number_of_ratings   : integer not null
  weight_of_ratings   : integer not null
  evalution_time      : timestamp not null
  
//Tracks historical rating/voting results for a predicate so that they don't need to be recomputed
voting_results
id : integer not null
creation_time : timestamp not null
creator_id : integer not null               //this user will be a bot
predicate_id        : integer not null
aggregated_rating   : money not null
number_of_ratings   : integer not null
weight_of_ratings   : integer not null

//Tags primarily exist to represent information domains.
//Tags can be attached to a predicate to categorize it based on applicable domains.
tags
id : integer not null
creation_time :timestamp not null
creator_id: integer not null
name: char[40] not null
useful_predicate_id: integer not null

//Documents are used to attach evidence and related information to predicates
documents
id : integer not null
creation_time :timestamp not null
creator_id : integer not null
displayname : char[256]
document_type_id : integer not null
text_id : integer
body : binary data (unique)
text : (text search indexes on this field)

If a document is parseable, sub documents get created automatically when the document is added, and parent/child links are also created, including multi-level hierarchies within a document. Document links can be used as part of an anchor path for a link.

//document-to-document links will normally be created by bots
document_links 
id : integer not null
creation_time :timestamp not null
creator_id : integer not null
parent_id : integer not null
child_id : integer not null

//users create these to categorize a predicate into information domains
predicate_tag_links
id : integer not null
creation_time : timestamp not null
creator_id : integer not null
predicate_id : integer not null
tag_id : integer not null
relvancy_predicate_id : integer not null

//for attaching relevant documents to a predicate
predicate_document_links
id : integer not null
creation_time : timestamp not null
creator_id : integer not null
predicate_id : integer not null
document_id : integer not null
relevancy_predicate_id : integer not null

//I considered merging the table below with predicate_document_links and just adding a direction field, but it seems like the columns could vary more with time:

//for attaching descriptive predicates to a document
document_predicate_links
id : integer not null
creation_time : timestamp not null
creator_id : integer not null
predicate_id : integer not null
document_id : integer not null
relevancy_predicate_id : integer not null

argument_links
id : integer not null
creation_time : timestamp not null
creator_id : integer not null
debate_id : integer not null
argument_id : integer not null
impact_predicate_id : integer not null

//Created whenever a user rates a predicate
ratings
id : integer not null
creation_time : timestamp not null
creator_id : integer not null
predicate_id : integer not null
rating : money

A user can create follows to have a "favorites" list of predicates and users that is easily accessible from the user's "follows" page:

* Debates I'm following (predicate list)
* Users I'm following (user list)

Follows can optionally include an "expiration_time" after which the follow is effectively canceled. The last created follow of an object is always the "dominant" expiration_time for the follow, so an existing follow can also be canceled at any time by adding a new follow of the object where the expiration_time is set to the past.

A user can either directly create follows or use a bot to dynamically manages his follows (e.g a bot
could observe that a user spent 10 minutes reading various arguments related to a debate and add a follow time
with an expiration time based on how involved the user seemed to be).

The user's follows are also used to generate "alerts" when activity occurs related to the followed objects.
Activity alerts fill an "alerts" list with clickable links to activities attached to the followed predicate or user activity.

Follows can optionally be configured to send an out-of-band alert msg with activity info (e.g. an email or text message).

followed_predicates
id
creation_time : timestamp not null
creator_id : integer not null
predicate_id
alert_type : enum
expiration_time : timestamp //follow is ignored after this time

followed_users
id
creation_time : timestamp not null
creator_id : integer not null
user_id
alert_type : enum
expiration_time : timestamp //follow is ignored after this time


delegations
id : integer not null
creation_time : timestamp not null
creator_id : integer not null
receiver_id : integer not null
tag_id : integer
weight : integer (weight can be negative, in which case it is a counter vote)


Voting algorithm:
Inputs: 
* a list of all tags on the predicate over the delegation threshold
* a list of all the user votes on the predicate
* adjust each voter's weight by the delegations made to them. In the case where a user has delegated based on multiple tags meeting
the delegation threshold (80% and at least N voters where N defaults to 3) and two or more of those delegation receivers have voted
on the predicate, his proxied weight would be proportionately shared between them). If a user votes on a predicate, all his proxied power
is canceled for that predicate.


Objects related to votes:
policies
work proposal
ideas
labor requests
resource requests

What do ratings filters look like with the above data model?
* we want to filter based on tags
* we want to filter based on key word searches (available for predicates and text objects)
* we want to filter based on links
* we want to filter based on creator
* we want to filter on activity by specific creator
* we want to filter on activity by a certain number of users within a specified period of time.



Filter outputs:
* predicates
* documents
* tags
* users
* actions
* action types

Linked filter outputs:
* tags linked to a debate (categories)
* rewordings linked to a debate (rewordings)
* predicates linked to a debate (arguments)
* documents linked to a debate (evidence)
* predicates linked to a document (meta-data)


default argument filters:

For now, we can allow users to create direct queries and "name" them. Filters are classified according to their output (e.g. predicate filter, tag filter, document filter, argument filter).

filters
id
creation_time : timestamp not null
creator_id : integer not null
type : [predicates, documents
name
query

Filtering based on viewing history:

It would also be useful for a user to be able to track information they've already seen in the past (their viewing history), allowing them, for instance, to create a filter that only shows new documents or arguments linked to a debate. 

But even in many community ratings systems, it seems possible most users will not want their viewing information shared with others. Even in communities where such information is desired to be shared for some kind of reward, viewing history could easily be obscured if the user employs a bot that "pretends" to be the user.

So probably rather than directly storing viewing history in the central database, the user's UI should maintain
a local database related to that user's viewing history. For example, it could track previously viewed debates and the associated arguments that were displayed in the various filters used at that time. In this algorithm, the UI would request longer lists than it needed, then do a 2nd phase filtering of the data displayed in the UI based on the local "previously viewed" data (or possibly just "greying" previously viewed data). 

The "greying" approach is similar to that used by web browsers, and since the plan is that most objects viewed will in fact be web links, we can get an ability like this "for free" without writing any code if we are satisfied with greying, where the greying only takes place if the user then clicks in to the link. But note this is different from the originally described version of this filtering, where the user only has to view the link
versus click on the link in order for the filter to count it as "read".

# Template predicates

* Useful for grouping related predicates.
* At its most basic level, these templates serve as an encoding mechanism for "families" of predicates.
* Mostly designed to allow for voting on multiple alternative predicates (e.g. weighted voting).
* Template parameters are strictly positional.
* Argument typing is required because argument type arguments to the template are ids to objects in various tables.
* To form a "predicate instantiation", we connect a template and the template arguments (using a row in predicate_instantiations table).
* Note: there's no effective encoding compression because we cache the rendered string in the predicates table.


//Examples of predicate templates
I vote for {user}. //here the argument is required to be a user object
Argument {predicate} is relevant to Debate {predicate}.

predicate_templates
id, creation_time, creator, body 
1, now, 7, "User {user} is awesome"

predicate_instantiations
predicate_template_id, argument_tuple, predicate_id (unique)
1, [42], 7

To get a set of predicates for a weighted vote on alternatives, create a predicate_template (e.g. id=42),
then query for all predicates where predicate_template_id = 42. This query would be used both for voting
and for the vote evaluation.

I vote for option1.
I vote for option2.
I vote for option3.