Some of the comments below probably belong on a topic of a separate name, but I've got them fresh in my mind now, hence I want to get them out now, feel free to demolish, move and refactor.

There are several threads throughout TWIki.org on this topic at present, I'm moving my comments here since this is a much more appropriate context. Once I've done that I'll refactor them. (Or anyone else can of course, this is a wiki after all)

The initial set were moved from TWikiWhatWillYouBeWhenYouGrowUpDiscussion, and those were (IMO inappropriately) moved from TWikiWhatWillYouBeWhenYouGrowUp.

Assumption: TWiki is a Wiki. It may target corporate environments, but it's still essentialy a wiki...

• But as TWikiWhatWillYouBeWhenYouGrowUp posits, it's not - it's a CMS
  • Please wait until I have finished that article. You will see that is not going to be my position. -- ThomasWeigert - 10 Feb 2004

What's the difference?

• A wiki is 2 way - the OneWebMasterSyndrome benefits are a fringe benefit , a side effect. Imagine if you had to get approval from the local EmailMaster when you wanted to send an email or the local UseNetMaster when you wanted to either start a new thread, or post to an existing thread.
  • Out of a wiki's design naturally falls a system supporting dialogue between multiple writers

* A CMS is designed to support a 1 way monologue - from writer to reader.

A CMS is usually "set up" to be enforced to work in a certain way - "these topics are the only valid topics to display". This structure is the only appropriate structure.

For dialogue, discussion, collaboration, wiki cuts through all that crap. Good wikis provide tools that help people structure their discussions, to make it clearer what they're talking about, but they're unobstrusive, supportive, not prescriptive.

This has made me realise what it is that grates about elements of TWiki - especially TWiki.org.

Locking WebPreferences, WebForms, etc, constrains dialogue. Yes, it enforces ideas of security etc (forming MeatBall:HardSecurity), but essentially it constrains dialogue. This naturally leads to arguments about what can/can't be talked about, and how it can/can't be talked about. (This isn't a moan, just an observation, I think we can all agree there have been arguments over the past several months on these topics)

Sometimes constrained dialogue is useful - such as discussing bug reports. But if you're essentially discussing a new concept space, constraining the dialogue before it's had a chance to start is a bad thing. We've seen over the past few days the DeleteMe meme spread from other wikis into TWiki. But it's had to go back to the old WikiButton approach, rather than using the tools provided to help support writers & searchers.

Anyway, my simple point is this:

• Wiki - n-way dialogue
• CMS - 1 to many monologue (or small group to many monologue)
  • Thomas is spot on on noticing the whole culture shift towards CMS - especially on TWiki.org - the shifting of discussion points (such as on licensing pages etc) smacks of monologue, not dialogue - a side effect of the mindset the tools have on users.
    • What does Core.WebHome have to hide ? (Rhetorical, it's a place for conversations and brainstorming I presume. An exclusionist place at that)
    • What does twiki-core@sourceforgePLEASENOSPAM.net have to hide ? (Rhetorical, it's a place for conversations and brainstorming I presume. An exclusionist place at that)

All that said, I'm moving the comments here because I believe TWiki should remember it's a Wiki, not a CMS, and hence that prefaces all my viewpoints.

-- MS - 10 Feb 2004

---

Crawford,

I think there's (at least) two classes of metadata - stuff that's truly metadata (last edit time, topic format, version number, etc), and there's stuff people call metadata, but is really data. (Stuff inside forms, etc)

Stuff that is data should be possible to be entered by users inside a topic. Even if it's later transformed to something more complex. (As happens with old TWikiCategories transformed into WebForms)

You can currently do this using the following 2 idioms (excluding your FormQueryPlugin):

• Set Status = Proposed

%META:FIELD{name="Status" title="Status" value="Proposed"}%

One is free form data entry, the other is in WebForms. Semantically they're essentially identical. Indeed transformation from one to the other is a simple affair.

Furthermore, it doesn't take a great leap of imagination to automatically render Set approach above as follows:

• Set Status = Proposed [[ finalise ]]

To automate this transformation... (This then also fits in with John's using forms for settings )

Likewise there's nothing stopping other possible syntaxes. (I'm not advocating a new syntax here, the Set form would do fine - it's semantically equivalent.)

Logically there's also the next step of allowing a further separation & optimisation into a database for speed. The point I would argue for though is that this allows small steps of transformation. Users start off with wiki buttons and settings, these are simply transformed into structured data, and then that can be further optimised. The essential WikiNature is preserved, but allows a looser approach to move towards something more optimised where appropriate.

On a secondary note, the current storage format can be viewed as a serialised form of the topic & the information pertaining to it, and then the whole thing is version controlled. You could argue that each piece of associated data is actually a wiki document (perhaps constrained) that happens to be related to the primary topic. In which case the metadata itself should be version controlled, and then each revision of the original topic "has to" point at the specific revision of the "metadata" (structured data, properties, fields, whatever).

In that instance serialising the whole shebang (whether using that as the topic text or not) and then doing version control on that is IMO quite a good compromise of functionality to complexity.

This doesn't ignore the fact that the real metadata (author, etc) should be kept out of band. However users should have the ability to impose (and break down) structure in ways they see fit - and that by necessity means in the simplest case allowing in band "meta" data. (Though prefer structured, fields or properties)

-- MS - 09 Feb 2004

Please read AndrzejGoralczyk's post of 10 Feb in MetaDataStorage. I agree whole-heartedly. I'd also like to add that metadata, as currently implemented in twiki sucks. I don't really like the term UserHostile, as I think it trends farther from center than it's antonym UserFriendly, but in the case of twiki-metadata it might be appropriate.

First let me say that I agree with the goals: TopicClassification, grouping (RelatedTopics), SpecProgress, etc., etc. were all created to serve a need. However the implementation is the very antithesis of wiki nature. Once the structure is set it takes a lot of work to change it, and one must be an administrator and technically sophisticated to boot. The only advantage I see over WikiBadges/Buttons is that the code-word is moved out of the topic text -- meaning that people don't have to keep refactoring it to the bottom of the page as they add text.

Secondly I don't like the metadata because it's in the way all the time. Right now, while editing, there is this big coloured blob at the bottom of the edit box which I must navigate over to get to the next step, "Preview", and to the quick reference chart of commonly used TextFormattingRules. After I'm done editing it will be in the way again, at the bottom of the page. And while I'm trying to design my perfect skin it's in the way again in a whole different way.

Wiki, on the whole, is elegant and simple. Metadata by forms and tables, on the whole, is ugly and cumbersome. It's like living in your house before the sheetrock and paint goes up; it keeps the rain and snow out and the heat in but it ain't pretty.

I don't know what the solution is, but I do know I don't see it here.

ArthurClemens, you must have some thoughts on this, yes?

-- MattWilkie - 11 Feb 2004

As I argued in TWikiWhatWillYouBeWhenYouGrowUpDiscussion, twiki is really a combination of several applications, most prominently:

• a white board (wiki) application
• a form application
• a file storage (attachment) application

The topic text stores the data of the white board application, while TWikiMetaData primarily stores the data for the other applications. It would be most inappropriate, if the data storage for the white board application were were intermixed with the data storage of the other separate applications. Users of the white board applications do not want to be confused in their editing with data from other unrelated applications.

The shortcoming today of twiki as this (small) portfolio of applications is that while you can decide whether to use or not use other applications, you have no control of where on the screen they are rendered or how they are edited (e.g., attachments are always edited in a separate page, while form data is edited at the bottom of the edit page).

Note that nothing stops you as a user not to use, say the form application, or create the data that typically is contained in a form inline in your white board application. However, what you loose would be the well-structuredness guaranteed by the separate applications (but that would be the more wiki-like nature).

In short, if you want only the unstructured white board application, just use that one. If you want to compose your web pages from a white board and some structured applications, twiki offers that capability also. Obviously the other applications are not "wiki-like", but that is besides the point. They are not meant to be; the white board is the wiki.

Or phrased differently, there is nothing "wiki-ish" about trampling over other applications' data...

-- ThomasWeigert - 11 Feb 2004

Matt, Michael is touting one solution, when you get your head around it. Think of it this way.

A twiki page can be viewed as a table, which (today) has an entry for the text, an entry for the form, and a series of entries for attachments:

   text => "This is the text of my topic"
   form => ...
   attachment1 => ...
   attachment2 => ...

When you look at it this way, you can see that you can have multiple forms easily enough, if they are named uniquely. Come to that, you can have multiple _texts as well (a.k.a named include sections).

   text1 => "This is the"
   text2 => "text of my topic"
   MyForm => ...
   YourForm => ...
   My.pdf =>

Any of these fields should be able to be reordered within the topic, so MyForm can come at the start of the topic, if you want. And their expansion should be controllable. An unexpanded 'text' is a WikiWord. An unexpanded 'form' is a ... well, it's something we don't currently have. An unexpanded attachment is ... a link to an attachment, I guess. And an expanded attachment is ... the attachment in-line.

If you can control the expansion of the various elements, you have an incredibly powerful, user oriented representation. Imagine being able to either single-click on a wikiword to jump to that page (as now) but also double-click to see that page expanded in-line in the current topic!

Add the power of being able to parameterise all those fields from this topic and - wow! But I'm not going there just now.

-- CrawfordCurrie - 11 Feb 2004

Crawford, you are heading exactly the direction I have been arguing in related topics, I believe. My view is that the topic file on disk is just a holder for data of a number of separate applications that are aggregated in a single page. There could be multiple white boards (i.e., text), multiple form applications, etc., .... These applications can be nicely integrated. The thing remaining to do is separating the layout of the multiple applications from the applications themselves....

-- ThomasWeigert - 14 Feb 2004

Actually this direction is where MichaelSparks was heading with OWiki, as I understood it; I was just trying to express it a bit more clearly than Michael has. But the concept of classifying data has been around for a long time - it was discussed extensively when we were talking about OO TWiki (whatever happened to that anyway?).

Personally I think it's crucially important not to confuse how data are manipulated, with how they are stored. I don't actually care how/where data atoms are stored, as long as it's efficient. But I care a lot how I get to that data. Every time I have to write a piece of code that knows about topics being in files stored in directories called webs, I have to have therapy. It's just so ..... 1970s.

-- CrawfordCurrie - 15 Feb 2004

This topic is running into an issue that I'm currently struggling with.

I agree with the statement that much of what is currently called MetaData is in fact just data for a different applciation that runs alongside the wiki (the whiteboard application), but it would be nice to be able to have actual MetaData for the wiki content. For example, at my company we use TWiki's wiki (the whiteboard application) to document and discuss development tasks and issues. I'd like to be able to mark content in the wiki as being a requirement, assign it as a task to someone, associate the task with other tasks, mark it as completed, etc. I've looked at ActionTrackerPlugin and XpTrackerPlugin, but those treat the items being tracked as distinct from the content in the wiki, i.e, it's a different application within TWiki. If you have documentation and you want to mark something as a tracked issue, it needs to be copied from the wiki into the tracker. I'd like the content to exist OnceAndOnlyOnce.

As an aside, thinking about this I came up with a definition that works for me: TWiki is an application platform that includes a wiki.

-- ScottGargash - 17 Feb 2004