A grand "dumping ground" for semi-structured info, and perhaps......everything?

I propose the following features:

Both hierarchical and reference-based. Hierarchies are too embedded in users to outright kill. Too many people need them as a reference point. However, this doesn't preclude a reference engine(s) on top of it or in addition to it.

"Attachments" are treated as sub-folders, or sub-wiki pages. Attachments can be wiki pages, files, and/or attributes.

Name-spaces are specified "::". Thus, a given wiki my have a name of "east_office::sales".

A given wiki "node" has a set of attributes in "reserve", regardless of whether they are used/populated. See schema below.

Based on MultiParadigmDatabase, which is basically a giant map of maps (rows). "Tables" are specified by using an "entity" attribute in a dynamic/virtual kind of way.

A file doesn't have to have a wiki text entry and a wiki text entry doesn't have to have a file (except possibly for local/user-created constraints.)

Other entities (tables) can be created outside of the main wiki-related entities but still be involved in queries, including JOINS, using the stated MultiParadigmDatabase.

A ParagraphWiki could optionally be created by making the paragraphs be a sub-folder of the "document" node/object in conjunction with the "display_order" attribute. More on paragraph mode is given later.

The "[-]" mean that the item section is collaspable. It's similar to "tree viewers" that have a [+] and [-] icon to open or collapse branches. The order and default collapsed/not-collapsed status would be user and/or site configurable. "[*...*]" implies a button.

If the wiki item is in "paragraph mode", then the "reader" panel would display link markers to edit an individual paragraph. Rolling over the marker would also show the boundary of the target paragraph using a tint-block. The user could still do paragraph selection and editing using the "Sub-Items" panel, but that's not very convenient. Wiki titles will double as and display as paragraph (or section) titles if an item is part of a paragraphed topic. Note that using "paragraph mode" does not preclude multiple paragraphs per sub-section. "ParagraphWiki" may be a misnomer because of that. It's more like a sub-document, or divisible document.

Perhaps a ParagraphWiki should wait until version 2.0. It will add a lot of design complexity. Let people get used to a basic FlikiBase first before tossing in concepts such as ParagraphWiki. I'm mostly just "reserving conventions" for it so it can be added later with minimal changes. Maybe the whole concept of a ParagraphWiki can be made moot if it's easier to create virtual groupings. Needs more thinkification, as Bush might say.

The "standard" attributes would be tinted and placed at top to distinguish them from user/site-defined attributes (if allowed) in the "attributes" section of the above Wiki Item Explorer Screen.

Attributes combined with a DataDictionary of sorts and a data-entry screen/browser could provide basic internal form creation, kind of like LotusNotes. One could use the "attributes" section of the above Wiki Item Explorer Screen for a bare-bones form, but using a DataDictionary on top of it would give it polish. That for version 2.0 also?

Whether files would be embedded in the database used or stored elsewhere (such as a file system) and referenced in the wiki-base depends, and needs some pondering. It may depend on the performance capabilities of the wiki-base engine used. Maybe the choice could be a setup option.

SharePoint kind of tries to be a FlikiBase, but it's cumbersome and confusing, at least to the uninitiated. Its learning curve is not very gradual: you have to master and configure a lot before it's usable to "the masses". Granted, it has lots of features to lock down and control content, but in many ways that makes it anti-wiki. It's a BondageAndDiscipline version of a FlikiBase.

An individual Wiki database could be useful.If I were defining a database for this wiki, I wonder what I would do.

Entity: Wikipages
Attributes which comprise a page -
Id
PageName
Text
Attributes which can be derived for each page -
Categories
Contributors
Title - with great difficulty
Length of page
Child Pages