• GenericMetaDataStoreForTopics for categories
• Issues with categories; a great function, but can only have one category system per Web and have to edit template to effect changes
• MultiLevelWikiWebs
• Easier navigation - NavigationByTopicContext, ZWiki:FrontPage

I've been a bit slow to catch on to parenting and intra-Web navigation but have now come up with the following idea.

• Add parenting support as suggested by Peter in GenericMetaDataStoreForTopics and NavigationByTopicContext. So there is a new meta tag that links to the parent (i.e. the topic from which the link was originally created).
• Bring together categories and parenting. At present a topic is given a category by the user selecting UseCategory (then selecting from multi-dimensional items e.g. TopicClassification, OperatingSystem) when editing, this results in special HTML markup. How about having the parent being the category definition. The category definition would define the possible categories.

Thoughts in the form of an example:

WebHome >> TopicClassification >> NavigationByTopicContext TopicType >> FeatureBrainstorming

• Category for NavigationByTopicContext is TopicClassification, which defines possible categories
• FeatureBrainstorming is not the parent of NavigationByTopicContext, but is, say, a god-parent
• How do we know NavigationByTopicContext has a cetegory
  • It could be a META tag in NavigationByTopicContext
  • It could be a META tag in TopicClassification
  • It could be that a special link exists between TopicClassification and TopicType
  • Some combination of the above
• How do we change category?
  • From an interface point of view this could be very similar to the current category system, see examples below, but within the parenting mechanism.
• New facilities this could help enable
  • Multiple category systems with a Web - no need to create a new Web just for this
  • Definition of categories is done via Web interface
• Extras
  • Special topics like WebChanges, WebIndex, WebNotify WebSearch could also be used with a category
  • The category defines a subset of a Web which these then act on
  • This is just as applicable to parenting, which itself defines a sub-set of a Web
• Why not allow multiple parents?
  • In this instance a topic only has one parent, but multiple god-parents (please someone think of a better name)
  • I think this is simpler and allows a basic one line context (chain of parents). Similarly, OO languages now tend away from multiple implementation inheritance to one parent, but the ability to have multiple interfaces. Same simplicity arguments apply here - e.g. if there is only one parent, this relationship could be used for namespaces and security as well as grouping.
• Why don't we make NavigationByTopicContext's parent FeatureBrainstorming?
  • This was my initial idea.
  • Re-parent to change category
  • Reasons I dropped it:
    • Expecting to re-parent seems wrong, re-parenting should be rare
    • Relationship between namespaces and NavigationByTopicContext - I feel that parents could in the future define namespaces (part of any topic is a Web, it's children are within that Web). But, generally we don't want the namespace of a topic to change once created (external references broken and just generally confusing) Present situation can be seen to model this with a topic able to link directly (in namespace terms) to everything below level 1 in it's tree.

Bug topic edit example

Bug topic view example

Does this make sense? Additional ideas? Might be a good time for this, with categories soon to move to GenericMetaDataStoreForTopics.

-- JohnTalintyre - 12 Jun 2001