Here I will attempt to classify the types of ways in which structure can be defined for a wiki (collection of documents).

A: Physical structure B: Tags C: Readable metadata D: Binary filters on content E: Extraction filters on content F: Content

Physical structure

Structure is reflected in the location of the documents in a directory-structure (namespaced structure)

Only a single structure is possible.

Changing the structure means moving the documents.

Pros: structure is immediately apparent to end users. Cons: changing the structure requires permanent redirects and/or updating all references.

> SB: I have never had success understanding wiki structure that had more > complex "structure" than flat with a name index. Part of what makes "wikis" > make sense to me as something distinct from a "collection of documents" is > that the structure is determined by the content (i.e., in the cross-linking), > not the other way around. But maybe I'm just talking about a different entity.

EJ: Clarification -- do you mean that you (proscriptively) don't believe in wikis with any kind of directory structure, like this wiki or Trac's wiki?

Tags

Structure is independent of the documents themselves and can be layered on top.

Any number of structures is possible -- each tag is a separate structure.

For N documents, each tag is a binary sequence of length N -- for each document the tag is either on or off.

SB: Are tags "metacontent" or "metadata"?

EJ: Can you define metacontent and metadata? I can't. I'll go out on a limb and say that they are metadata, because "metacontent is information gleaned from the content" and this is an annotation on the content, not anything derivable from the content.

OR I'll go out on a limb and say they're metacontent, because metadata is only readable. But that doesn't seem likely.

So my current answer is: metadata.

Compared to the "readable metadata" described below, tags (which are writeable metadata) have a lower information-density, because the only information they provide is semantic whereas readable metadata reflects deeper truths.

JH: My answer is tags are both fist-class content items andto metadata, at least in how I would want to implement them. Having them be both allows you to do things like tag tags (which I personally find useful with large complex interrelated information) and add other metadata to tags. So in the same sense that a comment is meta-content, tags are meta-content (that is, content that has a context) as well as metadata (that is, they are probably in general stored as data on an object and are otherwise viewable/editable/etc like other metadata), but the latter is an implementation detail and doesn't have to work this way (it just makes more things possible when it does).

To EJ: Why is metadata only readable? This document has a metadata "mimetype" which I can freely edit. Is that a bad way of looking at things?

Readable metadata

Things like "X most recently updated pages" or "pages created by author Q" or "pages which have been visited more than Z times."

There is no direct way to modify the balls.

Binary filters on content

"Pages that link to page Q" or "Pages with the word 'dog' in them" or follow this pattern.

Here the structure is a direct, binary filter against each page, so the structure can be modified by editing the content of a page.

Extraction filters on content

"Pages linked to from page Q" follows this pattern -- the structure is extracted and generated from content, in a non-binary way.

> SB: I'm not sure I understand the distinction between binary and extraction filters. > Maybe you mean something like "filters for intrinsic properties" vs. "filters for > extrinsic properties"?

Maybe I can express this better in programming terms. Here is the signature for a binary filter --

boolean binary_filter(document)

And here is the signature for an extraction filter --

list_of_uris extraction_filter(document)

In other words, with binary filters, the list of documents is generated by applying the filter to each document, and including each document that passes the filter. ("Does this page link to page Q? Yes/No") With extraction filters, the list of documents is generated by applying the filter to each document (or possibly just one document) and using the results as a list of documents. ("What documents does this page link to? DocA, DocB, and DocX.")

Content

Arguably a subset of "extraction filters": here the structure is itself content, directly editable by users, like an editable "table of contents" page.

SB: I challenge the idea that this is a "type of ways in which structure can be defined for a wiki". (Not because I think the idea is necessarily wrong, but because I think it needs to be challenged)