![[Home]](/static/logo.png){kind=logo}
The Wiki is connected to a database. The data in the database is accessible to wikizens and from within the wiki; database queries are possible.
RdfForWiki is a major way to introduce DatabaseCapabilities to a wiki.
WikiVariables is another way, though somewhat weaker.
Some Wiki pages contain marked-up information for the database, either as part of the normal page text or associated with it. For example, Wikipedia has several types of pages (e.g., chemical elements, U.S. Presidents, countries) that contain tables with standard information about the subject. If Wikipedia had database capabilities, then the tables could be automatically generated, and they would be searchable. If the information fits in naturally with the page text (e.g. “Joe Random (1852--1978) was an American widget manufacturer”), then the relevant information could be marked in the text; otherwise, it could be placed at the beginning or end of the page (or SectionedPages could be used). When a page is saved, the marked data would be extracted and placed in the database, if any changes were made.
You’ll probably want a very flexible data model. Not rigid like a traditional SQL database. One that people can easily add to, like drawing new boxes on paper.
The Chandler project, by the OpenSourceApplicationsFoundation, has been doing a lot of work on such a data model. They call their model “associative,” rather than “hierarchical” or “relational.”
There may be useful reference databases available that could be referred to by Wiki pages. This is probably related to InterWiki, since if DatabaseCapabilities were common, Wikis could simply share databases.
I wonder if there are databases that implement cross-database SELECT statements..? I’ve never heard of such a thing, but database theory has been around for ages… I’d think someone would have implemented such a thing. – LionKimbro
Wiki made it easy to write pages. To make words italic with HTML, you have to put <i> and </i> around your text. In wiki, you just use //.
Can we make databases easy?
Say you had a “People” database with four columns:
You want people to be able to add entries into your database. So, you write something like this:
|||| Add a Person to the Database! || || Last Name: DATA.People.LastName || First Name: DATA.People.FirstName || || Email: DATA.People.Email || User Name: DATA.People.UserName || DATA.Button.Submit DATA.Report.Results
This gives you a 2x2 table, and makes four data-entry boxes. After the table, a “submit” button makes it so users can submit the data they’ve entered. When the data is submitted, “DATA.Report.Results” would be replaced with “Data submitted.”
If the table “People” didn’t exist, it would be created. Who cares about “type”? Everything’s a variable length string.
This has been solved in PWiki2 by the use of functions which PWiki2 has had all along. Probably very similar if not the same as MoinMoin’s macros.
DATA.People.LastName becomes dataInput(LastName);
DATA.Button.Submit becomes dataSubmit(Table);
DATA.Report.Results becomes dataQuery(Table);
with an additional dataCreate(Table); before these 3 lines. So that a database entry form becomes a minimum of 4 lines (more if there are more inputs).
Also if the table does not exist, it is automatically created. The table name has the format (internally) as Namespace_Page_Table where Table is the table being used. --JamesMills
Changes to the database are subject to peer review in RecentChanges. There probably needs to be a way to talk about the changes as well, so that people can deliberate over whether to keep the change or no.
You probably need some features to make it easy to roll back the database, in case you don’t like some change.
Be sure to give a timeout to database ops, so people can’t just crash down the database by selecting everything in it.
Perhaps every page represents a relations table.
The title of the page is the title of the relations table. If you draw a table in wiki (an HTML table), it represents the rows of the relations table. The very first row signifies the field names.
Maybe?
Looking at a page as a relation may be focusing too much attention on the presentation vs. the data model. A more useful abstraction is to realize that a wiki page itself can be viewed as a tuple (row), with its internal contents viewed as data or as foreign keys (links) to other pages. The “primary key” is, of course, the page title/identifier (issue: need for uniqueness over disambiguiation). A relation (table) is simply a set of pages with a common schema. This could be implemented by having each page link back to a page that defines its schema.
As far as presentation goes, it makes sense to allow users to edit pages in table format on a single screen, but that need should not drive the data model.
On this wiki, each of these feature ideas is essentially a database entry.
Each idea has:
Ideally, we’d like to be able to see the one-line summary in FeatureSummaries also in the category page. For example, this page belongs to CategoryObject. When we look at the CategoryObject page, we’d like to see a list of pages in CategoryObject (which we have) along with a one-line summary of each feature the page represents (which we don’t have.)
Implementations of WikiVariables and RdfForWiki and PageMetaData do not appear in this list. Check those pages for those specific types of DatabaseCapabilities!
| status | wiki engines |
|---|---|
| Implemented | [xWiki http://www.xwiki.org/xwiki/bin/view/Main/WhyIsXWikiDifferent] |
| Developing | PWiki2, OpenRecord (see also this) |
| Intend to Develop | - |
| Considering | - |
| Rejected | - |
No wiki has implemented all three of:
PWiki2 is presently leading the way in implementing DatabaseCapabilities.
In PWiki2, you can describe a table of data in simple language. It gives you a convenient submission form, to add data with. And then, with a simple macro, you can display the contents of the table. Go check it out! The page may change, but there are presently (2004-02-15) test examples on the page PWiki2:DatabaseCapabilitiesTest.
In PWiki2, you can also make SQL calls from the engine. PWiki2's RecentChanges page reads <sql>SELECT REPLACE("<a href
=\"<docroot>/?p=[name]\">[name]", "[name]", name) AS Page, FROM_UNIXTIME(timestamp, "%d-%m-%Y %T") AS Date, author AS Author FROM pages ORDER BY timestamp DESC;</sql>
Currently I have implemented
As for MoinMoin, there are [wiki:MoinMoin/WikiDb some notes on a MoinMoin WikiDb MoinMoin WikiDb.]
MoinMoin also says it will be implementing “Forms,” and has a page of [wiki:MoinMoin/FormSamples “Form Samples”] worth looking at. This seems like it could become part of a database system.
Different but related, see the WikiVariables implemented in MoinMoin 1.2.
People with little wiki experience are often appalled at wiki’s free-form nature, and suggest/insist that some collection of data *needs* a more structured way to enter and edit items.
However, adding “structure” makes it more difficult and complicated and time-consuming to enter and edit items (compared to free-form wiki). Especially when you just want to add a few tidbits of data you know, and the software insists that you fill out every field completely before it will accept any of it.
For example, the OneBigWikiSoftwareProject describes a big, complicated, database for storing and searching information about wiki. But we never implemented it. Instead, we ended up moving the “database” from the Wakka Wiki software to the Media Wiki software (now at http://WikiIndex.com/ ). It seems to be working fine with (as far as I can tell) absolutely no software customization.
“All of the advantages for computerized are about technical things. All the advantages for cards are about people. Projects are about people.” – Wiki:IndexCard
I think it might be good to use DatabaseCapabilities to implement part of a larger WikiForms feature. For example, at the PWiki, right now you can only enter text. What if you could also select from popup list, radiobutton, or checkbox. You could design any kind of form for adding items.
Also, you could choose from a range of possible form actions: store in database OR append to page, prepend to page, email to user, send to external program for processing, etc.
Possible applications could include: weblogs, comment forms, quizzes and surveys, etc.
I have every intention of doing this with PWiki2 and will start doing this tonight. Already PWiki2 has support for the textarea form element by the use of dataText(Name, Rows, Cols); --JamesMills
[20:28] <prologic> hmm [20:28] <prologic> I see many good things with DatabaseCapabilities :) [20:29] <prologic> so far I only have implemented basic form elements integrated along with mysql [20:29] <prologic> eg: text input, submit button, query the table [20:29] <prologic> each table create belongs to the NameSpace and Page, thus making each table unique [20:39] <prologic> but it seems now that DatabaseCapabilties shall be more usefull if other form elements were implemented such as: CheckBox, Radio, TextArea etc...
LionKimbro, I think you’re right. I see more and more use of a DatabaseCapabilities feature, and am seeking more and more ways to extend and enhance the current implementation I have built. With some of these other Form Elements implemented into the DatabaseCapabilities, opens up possibilities for such things as:
--JamesMillsBrianTempleton, LionKimbro, JamesMills