Lot’s of things I need to come back to from our recent activities here. But, I wanted to let MattisManzel know that http://eartwiki.org/cgi-bin/hive/WikiWoodstock/WikiNetWikiIdeas

WikiNetWikiIdeas” actually looks pretty good.

I wanted to ask Mattis about the idea of connecting non-oddmuse, and/or non “Hive” wikis into these rolls or RSS. What do you think about that, Mattis?

Absolutely. I’ve been trying on s-23-wiki: recent near changes and s23-wiki: wiki-net changes quite a while ago. We should make OneBigSoup, definitely. Two or more soups are simply not that much fun as one.

As far as I got it there are three prerequisites for wiki-engines to be fully wiki-net compatible.

  • Day-page-sets must be supported to get feeds that add new entries on top (just like the changes-feed does it).
  • The right “amount” of info must be included. Mediawiki’s current full changes for example are far too much and render it “unusable”.
  • Transclusion must be possible.

I’d be very interested in figuring out what other engine(s) come(s) closest to this. Maybe we can make a little table telling about wiki-net compatibility.

Mattis, thanks for laying that out.

From what I can tell so far, other engines come close to doing some, but not all of what you are talking about. I am almost starting to think that there might be somethign that could be part of software like WikiGateway, that could enable this from the outside. Kind of like how WikiPut? amd WikiCopy? are scripts that are able to do things with wiki content. We might be able to create code that can filter content, like recent changes from different wikis to make it more uniform. And, we might be able to filter content to some degree so that it is transcludable between engines. Then, we might be able to create a sort of psuedo WikiEngine that outputs DayPage? sets in a way that each engine can easily use. This might be possible for the most widely-used WikiEngines, anyway.

The interesting thing I’ve noticed is that most WikiEngines have a way to create and include “templates”. I’ve noticed this in MoinMoin, DokuWiki, MediaWiki, InstikiClone, SocialText and commercial WikiSpaces.

Also, we should try to anticipte the future of WikiSyntax. Will many wikis continue to use CamelCase (probably). How likely is it in the next 5 years that thee will be a sginificant migration to WikiCreole. Stuff like that.

All of these variables, part of the TechnoSocialGap, lead me to believe that evolving a tool like WikiGateway, that can serve as a content translator and mediator between wikis, might be the way to go for us.

I’ve done a lot of studying of design by way of BioMimicry? ove the past few years. Looking at how nature solves problems, and using/emulating the best Patterns that have emerged in nature. Nature has lots of useful and sustainable ways for diverse processes to mix together, and not just co-exist, but also become mutually benficial. Sometimes these SymbioticRelationship? patterns are facilitated by a third organism. This third organism may have started out barging in as a parasite bent on leeching off of the two original organisms. But, somehow over time it may have found symbiosis more effective.

A WikiGateway evolved the way I describe above could become like a “symbiotic beneficial parasite”, who’s activities generate PostiveExternalities?, if done right and carefully. These types of “symbiotic beneficial parasites” are the things that make mega flora and megafuana, adn the earth’s whole ecosystem possible. That is just a metaphor, but an auxilliary application like this might be the most natural pathway to “OneBigSoup” ecology. Instead of campaigning among all WikiEngine project and users to standardize among themselves, it might be possible to modify a technology that was made to mount and engage wiki content (Wikigateway) and then use it to process and out put content, in a way that is beneficial for both us and for group of people that the content comes from?



I’m not sure I understand your point that…

  • Day-page-sets must be supported to get feeds that add new entries on top (just like the changes-feed does it).

I’m probably just missing something, so I’ll make a few quick statements that should allow someone to correct me.

  • I think Date pages are indeed an essential part of a good wiki (in spite of the historical “WikiNow” arguments). Oddmuse supports these perfectly with its UTS approach that we all see as part of the Blog.
  • these Date pages can be displayed in the various Calendar forms … e.g.

… that we are all also familiar with.

  • Finally, the …action=collect… feature lets us specify the order in which the returned list is displayed. If these three things are supported by a particular WikiEngine (software implementation) it seems obvious that any communities using using that software can participate in your vision of wiki-net. Maybe I’m just restating what you are expressing, but I do not think it is “necessary” to define this functionality as a prerequisite capability for participation in the wiki-net, at least not to the same extent that I think TransClusion and COPY… are essential fundamental needs.

One additional point regarding your …“the right amount of content”…

  • I think this is something that needs to be resolved by the Authors and the Communities they represent, as opposed to being a programmed thing. After all, just look at the difficulties we’ve all seen both here and at MeatBall regarding “summary” comments! I doubt we will ever be able to create a universally acceptable, programmed ‘pattern’ for that.

Here here! (re: the date pages being an essential component)

Interesting discussion so far. It would be informative and educational for me to see people weigh in on what they think are the essential components for wikis, and for InterTwingling? content across wikis.

Of course, I agree that the DayPages? are great, and Mattis and others have done some very interesting things with them.

However, one thing that I’ve noticed in my adventures exploring different WikiEngines is that OddMuse is almost the only WikiEngine I can think of that has this feature. Maybe I’m wrong about that. Please correct me if you know of a WikiEngine that has DayPage? functions like those found in OddMuse. The only other WikiEngien? that I’ev sen that has DayPage? sets that are somewhat similar is DokuWiki (example: http://www.wikidesign.ch/playground/blog). This is still not exactly the same thing. DokuWiki also has a Calandar, too. The DokuWiki Calendar can colelct and list dates that you list with bullet points on pages. Example:


And, it has a similar function to action=collect

Beyond DokuWiki, I don’t know of any DayPage? based WikiEngine.

Also, the larger Meta-Issue that I see for the WikiNet is that it is impractical to try and get so many people to change their WikiEngine and WikiSyntax. It is my opinion that it is just not going to happen. I also believe that it is impractical to try and convince many people to radically change the way they currently use their wikis. Many wiki communities probably have a deeply ingrained set of social and cultural patterns, and they will be unlikely to change them at the behest of outsiders.

This leads me to think that a set of scripts could be created that can “interface” with different WikiEngine, that can put out content that is similar to WikiNetHiveChanges, but is not necassarily DayPage? based. Possibly it could instead be based upon the code that handles RecentChanges for each WikiEngine. The reason that I suggest that is that all WikiEngines universally have RecentChanges. And, most of them output a feed for their RecentChanges.

So, I can envision that WikiGateway might be a server-based application, and have “plugins”, that are bascially add-on scripts that work with each WikiEngine, that allow it to output WikiNetChanges in a way that can be used directly by the WikiEngine. People who host wikis could download and install this version of WikiGateway, and use it to do things like:

  • Combine RecentChanges from many different WikiEngines, and display them locally
  • Possibly “Compare” page indexes of different wikis, and match up page names, whether they be CamelCase or not, and then output a NearLink list between chosen wikis
  • Give different options for trimming content that is syndicated
  • Mount the Wiki like a file, as the original WikiGateway can do, but also creating new capabilities that allow you to easily TransClude? content between Wikis, so that the content is copied to the page (kind of like how “Copy:” Perl script works with OddMuse, but done via WikiGateway interface, (which could itself be an editing window).

The point here is to shift the focus from trying to do the impossible (get everyone to change) to the possible (build bridges between disperate technologies and processes). Eventually, the same tool could also interface with blog and ContentManagementSystem software. It could also let you look through content by Semantic context. And, it could use some open standards to output recombined content in formats like PDF, DocBook, etc, if you wanted to create publications from Wiki content.

I need to take a long look at WikiGateway to see if it can be the basis for this type fo thing.

  • It would be informative … to see people weigh in on what they think are the essential components for wikis, …
    • There are a few such lists, already out there, here, on MeatballWiki, on C2, … not sure where they are right now, but I might start with CategoryWiki… (If I recall right.)
    • When I said DayPages? are critical, I meant, “I think this is a really essential idea, and I think a lot of wiki would do well to support them.
      • …as in, “This is an excellent next-generation idea.”
      • yes, OddMuse is the only one that does it now. (And Docu, or something.)
  • wiki-net: The wiki-net is a concept for an efficient exchange of information about wikis among neighboring wikis wikilandia-wide and cross-wiki engine using syndication. [1]
    • I think the primary problem of the wikinet, is that it is a social organizing platform masquerading as a technical platform.
      • This is a manual, social process, not a technical one.
      • This requires some convictions of solidarity and cooperation with neighbors and so on; Generally not a default assumption between strangers, even strangers interested in related things.
        • These separations can be bridged, but that is just my point – this is a social effort, not a technical one.
        • There are ways of technically assisting the bridging process, (PoliticalSoftware,) but that software’s not wiki (which is SocialSoftware, exempting WikiPedia; WikiPediaIsNotTypical.)
        • I also believe that it is impractical to try and convince many people to radically change the way they currently use their wikis. Many wiki communities probably have a deeply ingrained set of social and cultural patterns, and they will be unlikely to change them at the behest of outsiders. (SamRose)
          • yes
  • re: WikiGateway possibilities

Just wanted to add that my current interest in Wikigateway and WikiNet is in part influenced by my friend’s ongoing PhD? work centered around StigmergicCollaboration?:

Check out this thread:


Basically, actual collaboration only happens among groups of under 25. Collaboration among groups over 25 people is a “stigmergic” collaboration.

  1. Collaboration is dependent upon communication, and communication is a network phenomenon.
  2. Collaboration is inherently composed of two primary components, without either of which collaboration cannot take place: social negotiation and creative output.
  3. Collaboration in small groups (roughly 2-25) relies upon social negotiation to evolve and guide its process and creative output.
  4. Collaboration in large groups (roughly 25-n) is enabled by stigmergy.”



1. Hwo’s Footnote experiment - impressive! HwoToDo 2007-08-01

Define external redirect: WikiEngien PostiveExternalities DayPage DayPages InterTwingling BioMimicry TransClude PhD WikiPut WikiCopy SymbioticRelationship StigmergicCollaboration

EditNearLinks: WikiEngine DokuWiki MeatBall OddMuse WikiPediaIsNotTypical InstikiClone WikiNet SocialText MeatballWiki ContentManagementSystem MoinMoin MediaWiki WikiSpaces CamelCase DocBook WikiEngines