There is an idea, similar to WikiFeatures:BuiltinCategories, of taking cluster assignment for a page out of the page's contents.

Right now, to say that a page belongs to the "ExperimentalTechnology" cluster, you write the word "ExperimentalTechnology" at the top of the page. If we implemented this idea, though, there would be a separate field, similar to the existing "Summary" field, that would tell what cluster the page belonged to.

This page includes arguments for and against the idea.





We need to turn this page into BuiltinClusters?, actually, since they are different ideas. ChrisPurcell noted that RdfForWikis works perfectly fine on the page, thus the issue I want to talk about is distinct.

In fact, I think this idea is moot. Whether the cluster is specified at the top of the page, or a property of the page outside the page contents, it is still MetaData. We're just talking about whether we want BuiltinClusters?, or clusters in the page itself. -- LionKimbro


I've renamed this ExtrinsicClustering, as c.f. the current system where the cluster is intrinsic to the Wiki text. I'm removing these points:

  • We don't have WikiFeatures:BuiltinCategories, even though it may be a good idea.
    • What's that mean? It means: Let's not.
    • (reworker's note: I don't fully understand the argument; I'm tempted to say it is an argument for consistency. But I suspect we are intentionally leaving this vague, because our feelings are mixed, in which case we are putting the idea on hold. Which is, I think, okay.)
    • ChrisPurcell notes that in PeriPeri's RdfForWikis, all MetaData is merely part of the page.


I presently think clustering is way too complicated to actually use. ExtrinsicClustering would help a lot.


Yeah, I agree that there should be an explicit field, right now clustering is sort of a "hidden feature"; there is no affordance/hint that it exists; you have to read the documention or hear about it.

I guess that there should be some sort of unified system for associated meta-data with a page, though. If there are lots of MetaData fields (category, cluster, etc), a config option could tell the WikiEngine which fields should be explicitly represented as fields in the edit box and which should just be left in the text.

I guess the ones which significantly affect the operation of the wiki, like Cluster, should be represented explicitly.


There's no affordance for CategoriesAndTopics, either.

Issue: If you throw these options at a new user, they'll be overwhelmed. "I want to make a new page. But what are these categories? And clusters? And <insert a million other features that have been made extrinsic>? Oh, bother this, I'm going to post somewhere simple."

If people start using clustering, newcomers will learn by example, as they do for categories.


It's been I don't know how long since we've had clustering, and it doesn't seem to be working.

I have another argument.

The PageCluster is more like a comment summary (and thus deserving of an extrinsic block) than it is like page metadata.

That is, it is more about the immediate post to RecentChanges than anything else.

It just happens we think we'll post it into the same part of RecentChanges that we did last time, about 60%-70% of the time. So, we carry it over.

(When the cluster is in a text box, I would expect it is automatically filled with the previous cluster value.)


The cluster can be like a comment summary, certainly. If that's the case, making the cluster ExtrinsicMetaData makes perfect sense.

I see it as creating super-pages: several pages expounding the PatternLanguage of a single...Topic. (A connection Sunir has pointed out before.) This is the only way clustering has really been used here (ExperimentalTechnology, CliquesAndCommunities), and this usage demands IntrinsicMetaData.

What we really want is the ability to cluster revisions as well as pages: RevisionCluster.


I disagree.

While I have sympathy for the idea of topics (as in TopicsAndCategories?,) I disagree that we PageCluster by topic.

I think PageCluster is about RecentChanges.

For instance, just recently, I was factoring large pages into smaller pages. You (rightly, I think) thought, "This should all be clustered, so we don't have to see all of this..."

Those should all have been clustered as "LionsFactoringWork?."


I wanted those pages clustered forever, so I disagree. I was keeping the parts of the single essay together, not clustering the changes used to make them.


hm. well, i view clustering as applied to topics as well, and it didn't occur to me to apply it to revisions. i do want more granularity for revisions, but i don't particularly want to see them clustered because, like Chris, i view clustering as more permanent. gotta think some more about that...


Well, let's have both then. Some sort of permanent clustering mechanism (ahem.. categories), as well as a temporary "change cluster" field in the edit box.


That's my suggestion (RevisionCluster). Lion?

Define external redirect: LionsFactoringWork TopicsAndCategories BuiltinClusters

EditNearLinks: KeepItSimpleStupid CategoriesAndTopics PeriPeri RdfForWikis WikiEngine