Fliki Base

Based on ExtendingTheWikiParadigm, brainstorming features of a combo:

filing system
wiki (specifically, a ParagraphWiki)
database, or at least "attribute management"
Some basic CrudScreen-like ability

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.
Key-words and category references (to be described later)

Draft Dynamic Schemas based on MultiParadigmDatabase "rules":

Entity: wikiNode (not to be confused with a WikiNode) ---------------- ID (An Auto-ID is built into MultiParadigmDatabase, all records have them) wiki_title // wiki document or entry name; uniqueness not enforced, but warned. Required. text // wiki-text parent_node // ID of parent, if applicable file_ref // path or ID to file (depending on implementation) paragraphed // 1=paragraph-wiki-mode, 0=regular created_on // create time-stamp changed_on // modified time-stamp, same as create if new display_order // numeric keywords (any customer-defined attributes...)

Entity: wikiCategory -------------------- wiki_ref // node reference category_ref

[under constru

Sample User Interface Screens using GUI AsciiArt

 QUERY SCREEN:
 -------------------------------------------------
 .
 Search Words: [________________________][*Go*]
 . 
 Search: [X]Wiki-Title [X]Keywords [X]Category [X]Wiki-Text
 .       [X]File-name  [_]File-content (if indexed)
 .
 Query: (optional)
 [..............................] [*templates*]
 [.....query text box...........]
 [..............................] 
 [..............................] 
 .
 --------------------------------------------------end screen


 QUERY RESULTS SCREEN:
 -----------------------------------------------------------
 47 Matches Found
 .
 Wiki Title.......|Created.|Modified|File-Info|Key-words
 -----------------|--------|--------|---------|----------
 Why we love wikis|12/12/07|12/13/07|55Meg XLS|Wiki, Love, Reasons
 I spilled my Milk|01/18/08|01/03/09|.(none)..|Milk, Accidents
 Tables Rule......|11/01/10|11/01/10|8 Gig TXT|TOP, Tables, Good
 Etc...
 //  Click title for detail, per below. 
 //  Columns displayed are configurable.
 //  Rollovers may show more details.
 ----------------------------------------------------end screen


 WIKI ITEM EXPLORER SCREEN:
 -----------------------------------------------------------
 Title: Why we love wikis
 -----------------------------------------------------------
 [-] Content: . . . . . . [*full-screen*]
 Wiki content text goes here with a scroll-box and 
 a full-screen button. Before that, it would take up 
 about 2/5 of the screen by default.
 -----------------------------------------------------------
 [-] File Info: 
 .......File-Name: My_Dog_Wikituski_Pic.JPEG
 .......File-Size: 55.382 Meg
 .......Etc....
 .......[*Open File*]  // button
 -----------------------------------------------------------
 [-] Key-Words: Wiki, Love, Reasons
 -----------------------------------------------------------
 [-] Categories: Wiki, Proponents  // combine with above?
 -----------------------------------------------------------
 [-] Sub-Items:
 ....// (If items exist, same format as Query Results Screen above)
 -----------------------------------------------------------
 [-] Attributes:
 .
 Name..........|..Value
 --------------|------------------------------
 Created_On....| 12/12/2007    // standard attribute for wiki
 Modified......| 12/13/2007 
 My_Custom_Val.| Eat my socks!  // custom-defined attribute
 Etc...
 ----------------------------------------------------end screen

(Dots are to prevent TabMunging)

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.

--top

To consider:

Optional synopsis field
Required icon, perhaps for content "type", perhaps with an automatic default to simplify things

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

Yeah - it could be very useful