[Home]PermanentAnchorDiscussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
This is the discussion that led to PermanentAnchors.

Dedicated blogging software often feature a "permanent URL for this entry". For wikis, this translates into an anchor that can be moved around -- from the front page to any of the archive pages, for example.

Raw text: 

    '''2003-04-15''' -- saw the evening sun shine on the moss growing
    on the roof of the neighbouring office building.  The air was full
    of orange reflections.  [#moss_and_sunshine]

This should look as follows:

2003-04-15 -- saw the evening sun shine on the moss growing on the roof of the neighbouring office building. The air was full of orange reflections. [Permanent URL for this entry]

And when a user visits the following URL, the wiki should redirect the user to correct page. The simplest brute-force approach is to just search the page database for the occurence of the anchor and redirect to the first matching page.

The matching page should also have an invisible anchor tag at the beginning of the paragraph where the blog anchor is positioned, so that the redirection will automatically proceed to the the right anchor.

Better looks could be achieved using CSS.

The important part about this is the recognition that when a wiki is used to keep blog-style text blobs, then it should be easy refer to single text blobs (single blog entries) using an URL that does not change, so that other people can refer to it. This is particularly important when you consider that on a wiki, old entries can be moved to other pages, or reworked into new passages. The old URLs should not have to change just because of this. This is also why plain HTML anchors don't fit the bill, because the text blobs don't necessarily stay on the same page.

Well, a blog entry is just one blob of text, which is one page of text on a wiki. If you want to refactor blog entries together, you write a new blog entry. If you want to refactor wiki content together, you wiki. Blogs aren't wikis aren't blogs. If you want to talk about PermanentAnchors, that's another potentially interesting thing.

You are saying they are different, but I contest this assertion. Both wikis and blogs are a technology and a tradition. But nothing prevents you from using a wiki engine and keeping blog-tyle on your front page, for example. In fact, I suspect that homepages with easy to edit pages will automatically drift into blog-style, so supporting blog-style using a wiki engine is important to me.

Considered the following alternatives:

Online Diary Style -- Every blog entry is just a paragraph on a page, with no special provisions. This makes it difficult for other people to link to particular entries. Since these links are very important to bloggers, however, this is suboptimal.

Little pages -- Every blog entry is a little page of its own. Using some naming convention, a front page shows the appropriate blog entries. The naming convention might be implemented using SubPages. As it stands, there is a TransClusion patch for UseMod which allows you to assemble a front page using arbitrary other pages. But this involves more work for the author. Furthermore, reworking several entries and combining them into other pages will involve editing dozens of pages and adding #REDIRECT entries for many of the pages.

Permanent URLs -- This uses a naming convention to find an anchor no matter on which page it is, and it adds a way to put these anchors on pages such that other people can easily see where to link to.

Well, culturally they are different, but that's irrelevant as you point out. The point is that structurally they are different. Blogs require a different data structure than wikis provide. However, wikis already provide a lot of structure that you can leverage. Let's enumerate the requirements:

(Not to imply that the titles have to be CamelCase.)

The issue you have is with refactoring. Well, if you mean macro-refactoring, where only the position of the text blob changes, pages work again. Just change the order or structure of the InternalTransclusions. If you mean reworking, then that is the antithesis of blogging, which prefers (more or less) a consistent history. A consistent corpus is the antithesis of wikiing.

However, there is an alternative: WayBackMode. A permanent URL for an entry becomes

http://meatballwiki.org/wiki/action=browse&id=MossAndSunshine&revision=14

and even if MossAndSunshine is eventually reworked into oblivion (i.e. emptied), the older version still exists.

Now, if later you want to add to MossAndSunshine, that becomes different. In blogland, you would perhaps annotate your previous entry. e.g.

MossAndSunshineTwo

I had previously talked about MossAndSunshine. I forgot to mention I hate moss.

Or you might just modify MossAndSunshine and repost it whole. e.g.

MossAndSunshine

2003-04-17 -- saw the evening sun shine on the moss growing on the roof of the neighbouring office building. The air was full of orange reflections. I hate moss, but today it made me smile.

Another option, modified from ArchivingNews, is to create a core wiki document reworked out of blog posts. e.g.

MossAndSunshine/2003/04/15

I saw the evening sun shine on the moss growing on the roof of the neighbouring office building. The air was full of orange reflections.

MossAndSunshine/2003/04/17

I hate moss, but it made me smile that day.

Leads to a growing body of a prose lyric...

MossAndSunshine

saw the evening sun shine on the moss growing on the roof of the neighbouring office building. The air was full of orange reflections. I hate moss, but today it made me smile.

Then your permanent URLs become MossAndSunshine/2003/04/15 and MossAndSunshine/2003/04/17.

You could further simplify this scheme by eliminating the need for InternalTransclusions. Follow BillSeitz's model of having RecentChanges include the text of the wiki pages, except in this case only include those (new) pages that have a datestamp. e.g.

RecentChanges

I hate moss, but it made me smile that day.

I saw the evening sun shine on the moss growing on the roof of the neighbouring office building. The air was full of orange reflections.

That would provide front page access to recent entries. If you're so inclined, you could also print all the datestamped entries at the end of each root page, although that might be ugly.

In Wiki:JspWiki, all blog entries are separate pages, which are then aggregated together to a single page dynamically using a specialized plugin. This allows multiple wikis on the same server. It also nicely translates into PermaLinks?. The drawback is that since pages have to be named in a special way, it makes the page titles a bit obscure. See http://www.jspwiki.org/Wiki.jsp?page=WebLog and http://www.ecyrd.com/ButtUgly/ for my blog --JanneJalkanen

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: