Wiki Technology needed: THE SPREADSHEET WIKI

THE SPREADSHEET WIKI

Goal Based Mass Collaboration Accounting & Data Processing
(with near real time computation of results)

Abstract
The spreadsheet wiki is needed so as to allow complex data gathering tasks [that are prone to accuracy, consistency and traceability problems] like public accounting, enterprise bookkeeping, etc ... that by their nature "require relatively low computational overhead" (ie: ~1.2 seconds on web server, max) to be continuously updated (and audited) by hundreds of participants.

Ideally it is designed for spreadsheets that are 90% data, 10% computation -- but ideally it works best for 99.5% data, 0.5% computation. Computation means formulas -- and data means numerical data [as per the spreadsheet idiom].

The wiki user interface to the spreadsheet computation engine is paramount. Behind the wiki user interface there must be a 3D spreadsheet computational engine.

This is not a regurgitation of technologically defunct collaborative 2D and 3D spreadsheet designs of the 20th century, as these 2D and 3D spreadsheets did not really allow for Wiki stlye interactivity as they were designed for corporate workgroups. The 20th century corporate workgroup "collaborative spreadsheet" is technologically defunct in 21st century -- these spreadsheets were always more trouble than they were worth.

Why will wiki spreadsheets succeed where workgroup spreadsheets have failed completely?

Not enough people, corporate workgroups with less than 10 people can generate spreadsheets with unlimited design, logic and "garbage in, garbage out" data input errors.
Corporate workgroup spreadsheets had inferior auditing tools from the time of their inception. Wikis have very good auditing tools, for a technology that is open source.
Lower complexity: The goals and objectives of the spreadsheet administrator are more likely to be met if the administrative owner of the spreadsheet is constantly overseeing the spreadsheets emergence.

How does it work? How should it work?

By using a highly paired down wiki user interface technology a highly controlled user interface

Barriers that will have to be overcome with intellectual leaps in programming

This is a column oriented spreadsheet user interface. T row/column agnostic design that you see with normal standalone spreadsheets will not work well on the web. Columns also render (and display) better than long rows on computer display devices (monitors, printers, etc).
For some lesser versions of the technology, 2D spreadsheets may be acceptable. This however is a 3D technology by default, but 2D wiki spreadsheets are acceptable training tools to prepare people for 3D wiki environments.no matter how you do it on the web side, you will need a spreadsheet computational kernel that has XML filter interfaces
Many 3D spreadsheet file formats may not be able to handle every cell having several kb of comments, so this technology might create a new file format.
The spreadsheet wikis need this kind of comment space "at the cell level" in order to be considered a wiki.
the Wiki must continuously translate the wiki spreadsheet contents into industry standard XLS, ODF, etc ... file formats
Stand alone spreadsheets quickly evolve in to complex data and formula co-dependent data structures that can break very easily. Stand alone spreadsheet audit tools like "display cell dependencies" may need to be reworked for web users.
If a spreadsheet goes beyond 10% of the cells having computations, the user interface should indicate a design error condition.
unlike text Wikis, users should only work at the level of the cell (modify formula or formatting, change data, edit text)
2D spreadsheets can be wikified easier than 3D spreadsheets, but the fundamental Spreadsheet Wiki data structures should be designed around 3D spreadsheets
"FILTERS" will be needed to interface between the Wiki user interface, the spreadsheet kernel and

Mechanical implementation details

Modification privileges

Administrators: Spreadsheets: (Create (a typical user may want to create up to 10 spreadsheets), Add ancillary 3D sheet, Delete ancillary 3D sheet, Reset single 3D index sheet, Rename, change 3D index order); Rows & Columns: (Add, Delete, Reset, Change formatting, ...); Cells: see Privileged Editors
Privileged Editors: Rows & Columns: (Change formatting, spelling, reset); Cells: (update formula, data or text; reset);
Editors: Cells: (add data or text to cells, spell check, alert Privileged Editors of cell equation errors)
Guests or Anonymous Editors: (add comments to talk page)
It is very easy to vandalize a spreadsheet, so very tight superuser and editor controls are needed -- like CAPTCHA

Spreadsheet wiki property

Talk page: 256 kb at least, but 512 kb
Media storage space, to allow referring documents to be stored -- potentially 10 Gb by default but server configuration dependent; per sheet and per user storage allotments must be decided at the implementation level

Spreadsheet property (single sheet in a 3D page structure)

Talk page: 256 kb at least (rotating buffer)

Cell properties

Formulas: 32 kb talk page (rotating buffer; regardless of weather the cell is named or not)
Text: 16 kb talk page (rotating buffer; regardless of weather the cell is named or not)
Numeric Data: 4 kb talk page (rotating buffer; regardless of weather the cell is named or not)
Empty cells: no talk page (naming forbidden)

Never ending problems

the never ending problem of 'circular references' in spreadsheets must be dealt with
only the most basic spreadsheet functions should be permitted (math operators [+, -, div, mul, >, <, =]; sum(), average(), std(), log(), log2(), ... compound interest) but no trigonometric, date, time or other fragile or breakable functions
named cells (with at least 1kb of documentation per cell) may be mandatory for the collaboration system to work at all -- named groups of cells may be needed too
hidden cells should be forbidden, it is an unnecessary feature here
Standalone "wizard" tools that spreadsheets have (like formula and data copying, cell dependency graphing) will be lost at the wiki interface level. Some can be recovered by allowing users to modify the spreadsheet on their stand alone 3D spreadsheet programs like Open Office. Ways can be found to bring these tools back at the web interface level, but it will take time.
Editing individual cell contents in a wiki format vs standalone spreadsheet format will be very counterintuitive at first.
The web user interface must totally decouple the cells presentation from its contents, otherwise there will be confusion. This will take some intellectual effort to find the best way to get this done.

You can't just dump a web based spreadsheet program and use it

spreadsheet programs are for single users, not groups
no matter how you slice it, the stand alone spreadsheet in it current form is not ready for (much less compatible with) wiki technology
wiki controls like excluding users from certain nations, IP addresses, etc ... non existent in single user spreadsheets
staleness of data, and long term maintenance of data in a collaborative environment will have to be dealt with just as with normal spreadsheets

Known spreadsheet deficiencies that Wiki systems may be able to partly or totally fix

Spreadsheets have significant reliability problems. Research studies estimate that roughly 94% of spreadsheets deployed in the field contain errors, and 5.2% of cells in unaudited spreadsheets contain errors.
The practical expressiveness of spreadsheets is limited. Several factors contribute to this limitation. Implementing a complex model requires implementing detailed layouts, cell-at-a-time.
Authors have difficulty remembering the meanings of hundreds or thousands of cell addresses that appear in formulas.
Collaboration in authoring spreadsheet formulas is difficult because such collaboration must occur at the level of cells and cell addresses.
Although some spreadsheets have good collaboration features, authoring at the level of cells and cell formulas remains a significant obstacle to collaboration in authoring spreadsheet models.
Productivity of spreadsheet modelers is reduced by the cell-level focus of spreadsheets. Even conceptually simple changes in spreadsheets (such as changing starting or ending time or time grain, adding new members or a level of hierarchy to a dimension, or changing one conceptual formula that is represented as hundreds of cell formulas) often require large numbers of manual cell-level operations (such as inserting or deleting cells/rows/columns, editing and copying formulas, re-laying out worksheets).
Each manual correction increases the risk of introducing further mistakes in design, logic or formatting over the entire body of the spreadsheet.

How do you interact with the wiki at the cell level?
This will take some time to consider. This is being worked on.

Possible applications for THE SPREADSHEET WIKI

Using open sources to find the US, Australian, NZ, Canadian national debt -- based on the total debt per person averaged out over all known debt sources (this has never been attempted)
Spreadsheet wikis could replace the now defunct BOND RATINGS COMPANIES, as public wikis that allow for companies and governmental entities to constantly have their income and debts tracked by the public will get the lower ratings they deserve

Computations like "Total National US Debt" need to be wikified in order for the any solution to ever to be known

Column 1	Column 2	Column 3

Known Data		Notes & Sources
Total US Population	304,123,123	Via US Census Clock, now 305 millions
Total US Working Population	244,819,114
Total US Tax Paying Population	200,751,673

Removal Working Population from % pop	19.50%	Accurate real world numbers needed
Removal non-Tax Paying Pop from % Working Pop	18.00%	Accurate real world numbers needed
Governmental Interest Rate Average	4.55%	Accurate real world numbers needed
Commercial Interest Rate Average	8.50%	Accurate real world numbers needed
Consumer Interest Rate Average, housing	7.50%	Accurate real world numbers needed
Consumer Interest Rate Average, non housing	15.55%	Accurate real world numbers needed

Federal Govt Debt	$53,000,100,100,100	Dollars
State Govt Debt	$5,000,100,100,010	Total Dollars – known guesstimate
Local Govt Debt (county, city, water districts, etc)	$2,501,000,100,011	Dollars – known guesstimate
Consumer Housing Debt	$30,000,100,100,100	Dollars – known guesstimate
Consumer Credit Card Debt, Car Loan Debt etc...	$20,000,100,100,101	Dollars – known guesstimate
Commercial Sector Debt	$10,000,000,100,011	Dollars – known guesstimate

Interest Incurred Debt (commercial, 5 years)	$4,250,000,042,505	Constant dollars (2008)
Interest Incurred Debt (consumer, 7 years)	$37,520,161,511,513	Constant dollars (2008)
Interest Incurred Debt (governmental, 20 years)	$55,056,092,273,110	Constant dollars (2008)

Debt Total	$217,327,654,427,460	Dollars for total debt from all sources

Implied outcomes
Debt per person	$714,604.18	What is owed per person
Debt per working person	$887,707.05	What is owed per working person
Debt per tax paying person	$1,082,569.58	What is owed per working tax paying person

User interface notes:
Users would only be allowed to input: Text into Column 1, Numeric Data & Formulas into Column 2, and Text into Column 3.

Model notes for spreadsheet above and in question

A taxable person is a person that has paid at least 1 USD more in taxes (from their own microsegment of GDP or GNP that they produce) than they have consumed in government services in their lifetime (and technically is a moving average number that changes as the economy does). However, due to the depth of consumption of government services the above numbers relating to taxable persons in this spreadsheet model are probably overestimates (by an unknown order of magnitude). Taxable people are generally tied to corporate entities (even if the corporate entities are minor), so corporate taxes and personal taxes do at least have the possibility of nominally meeting in the spreadsheet model. Corporations in some situations are notorious for consuming more government services than the taxable GNP or GDP that they produce. In the US model, corporations can never technically die -- except via select forms of bankruptcy or insolvency.

Under the Internal Revenue Code, the income of a U.S. citizen is taxable without regard to the citizen's place of residence, and, significantly, without regard to where the income is earned or produced. Hence, a US citizen can eliminate his tax liability only by both moving abroad and renouncing citizenship.

The process of renunciation requires the US citizen to appear at a foreign US embassy or consulate, prove that another citizenship has already been obtained (so that the renunciation will not make one a stateless person), and sign various documents which basically state that you are of good mental health, acting without force or duress, and realize that the renunciation is irrevocable. The State Department then reviews the documentation and may decide to permanently bar the person from entering the US - even for visits. This decision is based upon whether or not State decides that the person renouncing is or is not doing so for tax reasons alone. For the purposes of the IRS, the effective date of the renunciation becomes the final day that US income taxes are due - assuming that all US assets are liquidated and have left US jurisdiction.

An immigrant who has been granted permanent resident status in the U.S. is generally treated as a citizen for tax purposes. An immigrant not legally admitted for permanent residence (such as a guest worker) becomes liable for U.S. taxes if he spends more than 122 days in the year in the United States.

The US tax law, at the state and federal level -- broadly speaking -- only tolerates Americans taking money outside the US. As long as money taken outside the US is never brought back into the US there is no violation of the law. It is broadly understood that Americans can use corporations or trusts to cover moving money outside the US, providing that said corporations or trusts are not based in nations that would raise suspicion.

Broadly speaking, the US taxation rules encourage people to move their assets offshore -- and to retire offshore. This creates a permanent outflow of United States dollars into other currency zones.

Tax avoidance is the legal utilization of the tax regime to one's own advantage, in order to reduce the amount of tax that is payable by means that are within the law. By contrast tax evasion is the general term for efforts to not pay taxes by illegal means. The term tax mitigation is a synonym for tax avoidance. Its original use was by tax advisers as an alternative to the pejorative term tax avoidance. Latterly the term has also been used in the tax regulations of some jurisdictions to distinguish tax avoidance foreseen by the legislators from tax avoidance which exploits loopholes in the law.

Some of those attempting not to pay tax believe that they have discovered interpretations of the law that show that they are not subject to being taxed: these individuals and groups are sometimes called tax protesters. An unsuccessful tax protester has been attempting openly to evade tax, while a successful one avoids tax. Tax resistance is the declared refusal to pay a tax for conscientious reasons (because the resister does not want to support the government or some of its activities). Tax resistors typically do not take the position that the tax laws are themselves illegal or do not apply to them (as tax protesters do) and they are more concerned with not paying for particular government policies that they oppose.

Intellectual property notice
As the originator of this intellectual property, I require different things than those that actually do the computer coding to implement this technology. I am too poor to patent this technology, nor it is clear to me that patenting it is a good idea. The spreadsheet wiki is essentially a "middleware" technology, not a new technology.

My views on user fees

Non Profits, home businesses, small local governments (under 500 employees): no user fees required. Most users in these categories will probably be using the technology via 3rd party ISPs, but even if not they should not be charged.
Corporations: 1000 {{EUR / Year} / corporation} if traded on the share market and if consistently used by company business processes otherwise 100 EUR for medium and small businesses. Companies and state and provincial governments using 3rd party websites offering wiki spreadsheets are exempt.
National governments: Same rule as corporations, but 50,000 {EUR / year} at the national level.
State & Provincial governments: 1000 {{EUR / Year} / state or province}
ISPs, that is to say "content providers" offering spreadsheet wikis (but getting money from ads or user fees): 0.5% of the net profit from the spreadsheet wiki operation. Other means of support are accepted.
The programmers that take the wiki technology and effectively combine it with 3D spreadsheet technology: You can make as much money as you want from your own intellectual property, but a one off donation to me of 10000 EUR would be acceptable.
Those creating wiki spreadsheet middleware technology via "open source means" are not subject to this same requirement. However, a donation of 1000 EUR would be acceptable in this case.
I am willing to consult in an ex-officio capacity with any IT developer, ISP etc...