MeatballWiki

UseMentionProblem

  1. REDIRECT LinkingWithoutIndexing

The "use-mention distinction problem" isn't really the right term for this meme. LinkingWithoutIndexing seems better. However, I have left the original text of this page for possible future rewriting. -- ChrisPurcell

The OpenGuideToLondon was originally run using UseModWiki, and we had a category system just as described on ReverseIndexTree. However, we ran into a WikiPedia:Use-mention_distinction problem: we categorised pages by putting links to CategoryWhatever on them. However, then every time someone looked at the ReverseIndex for CategoryWhatever, they'd see every page that mentioned it in addition to the pages meant to be in it, because the ReverseIndex doesn't understand the use-mention distinction. This was, and is still for most wikis, obviously suboptimal.

The solution we came up with for OpenGuides was to develop a wiki database that contained a completely separate table of metadata about the pages, in addition to storing the usual contents of the pages. This way, we can classify any page as belonging to any category, and have a separate mechanism for finding those classifications, in addition to the usual system of reverse indices. See http://london.openguides.org/index.cgi?action=index;index_type=category;index_value=Coffee%20Shops for an example of this in action. In addition, categories can be nested; so we have a [Category Category] too. I'm currently thinking about ways for the user to navigate the hierarchy.

Because the OpenGuides system has a geographical purpose, we also have a parallel system for designating localities as well; a page might be in Category Pubs and Category Thai Food, for example, and also in Locale Fulham and Locale Hammersmith, so there are multiple ways to search for a page. These two systems are identical in everything but name; the separation is purely for human convenience. (At the moment.)

For UseModWiki I came up with a workaround to deal with the use-mention distinction: every category page, for example Category Mapping, has a parallel page - in this case Mapping - that does nothing but redirect to the category page itself. This way, the name Category Whatever will only be used on pages that actually are in that category, and I can use the redirect page to refer to when linking to the category; thus keeping the ReverseIndex listings clean. It's also easier on my fingers, as I can say <tt>The topic of [[mapping]] is related to this</tt> instead of <tt>The topic of [[Category Mapping|mapping]] is related to this</tt>.

-- EarleMartin

Another option is a specialised MetadataSyntax like PeriPeri:PeriPeri+FacetWiki:RdfForWikis. Also, ReverseIndexTree is possible right now on CocoaDev's engine. -- ChrisPurcell

A simpler way to preserve the use/mention distinction is to create IsaMonkey and CategoryMonkey, using the first to tag instances and the second for references. CategoryMonkey can then provide a link to IsaMonkey's backlinks. (IsaMonkey could further transclude CategoryMonkey's text to gratify curious folk who click on it, or it could redirect to CategoryMonkey.) Replace "Isa" as appropriate; for example, "In" is more appropriate for a locale. Redirection probably is better, as it is less "mysterious".

[Later] Er, I guess this is essentially what Earle was saying. But my point is that it is equivalent to adding metadata. Plus it feels more "wiki". ;-) -- anon.

I tried using SeeCategoryCategory to parallel Scott's suggestion, but this looks flawed, because the BackLinks here are from an unsophisticated search, so CategoryCategory (for example), still links. I thought the backlinks were fancier than that. Oops. --MartinHarper

We have a really neat solution to this on UnrealWiki. I don't know if it would work here, it could be a function of our patches. The page title click searches for "[[PageTitle]]", so all you need to do mention a category page is link as [[CategoryFoo|]]. The final | prevents it showing in a search. -- TarQuin

One thing we ought to do is distinguish between links to category pages that categorise the page (eg CategoryNavigation at the bottom of this page), and links to category pages that provide links (eg a link to CategoryCategory on StartingPoints or IndexingScheme). One way to do this would be via redirects: IE, we could write InCategoryNavigation to signify the first type, and SeeCategoryCategory to signify the second type. Add a couple links to Meatball:back=InCategoryNavigation and Meatball:back=SeeCategoryNavigation and all is well.

Isn't it ironic? The categorising started because people thought they can use the standard wiki mechanism to do an additional task. That was meant to be a simple extension. But eventually we discover the ineficiencies of the naive approach and make up more and more complicated schemas to be compatible with that mechanism. -- ZbigniewLukasiak

A little librarianship. This is really a problem with the LinkPattern strategy, not ReverseIndexing nor BackLinks per se, although it relates to how the LinkPattern is used to form a ReverseIndex on a wiki. I recommend restructuring this page's relationship to the PageDatabase to reflect this, but first it has to be renamed to something more manageable. In particular, this is not a problem specifically related to categories which are only one type of reverse index, therefore elide categories from the title, and the phrasing "use mention distinction" is unreadable and therefore unmemorable. (Ah, the rhetoric of link style.) I might call the solution a ReverseIndexReference. -- SunirShah

I'm unclear on how this is a problem with the LinkPattern. Wikipedia uses free links, and it still has this problem with its reverse indexes (eg WikiPedia:Wikipedia:NPOV_dispute). --MartinHarper

You have to think about links as being separated from the text. Just because I SmashWordsTogether that doesn't ordain that it will be a link. The script merely declares that it will. While normally this distinction is so minimal it might as well be meaningless, it does become painfully obvious when links appear in contexts they shouldn't, say when we talk about the fast food franchise, McDonald's. Thus, although I am writing about a given category by using its nym, I do not intend that it form a link. Actually, I'd rather it form only a weak ForwardLink without the corresponding BackLink, but I have no choice in the matter given the architecture of the wiki, which is hinged around the strategy of making links out of text patterns (not to mean the LinkPattern RegularExpression itself). Actually, FreeLinks can escape the problem partially since you can discuss Category Foo without making the link to [[Category Foo]]. -- SunirShah

Hmm, I think I see. The distinction I wish to draw is between a link meaning "is a member of this category" (use) and a link meaning "see this category for more info" (mention). The distinction you wish to draw is between PageDatabase (mention) and PageDatabase (use). But it seems to me that the possibility of turning links off with nowiki is sufficient to make this distinction, as you can discuss CategoryFoo without linking to CategoryFoo. So maybe I don't see.

On UseModWiki, this use of nowiki only breaks the forward link; the reverse link is still there, because backlinks are just searches. I consider that a bug, not a feature. --MartinHarper

It seems clear to me that using In-Category-X is the way to go, as it is more useful to readers than SeeCategoryCategory. Also, it's very awkward to refer to SeeCategoryCategory in normal speech: people just want to say "CategoryCategory" and be done with it. I'm still not quite clear on how the backlinker engine works, though. --MartinHarper

I don't understand. The categories should be marked with CategoryCategory. What's the purpose of renaming it? Was it so we can discuss 'SeeCategoryCategory' without making non-category pages categories? That just adds complexity where CategoryCategory is a special case whereas all the other categories are normal. i.e. there is no InCategoryInformationVisualization. It's simpler (less redundant) to just write CategoryInformationVisualization. Yes, no, am I missing something? Me confused. -- SunirShah

Well, I've decided that SeeCategoryCategory was junk, because it's just unnatural to use. So I'll revert that back to how it was in the name of simplicity, in good time.

The purpose of InCategoryCategory is the backlinks: MeatBall:back=InCategoryCategory contains only categories. Of course, switching over to SeeCategoryCategory is another solution, but it turns out to be less good.

CategoryCategory is in some respects a special case because there are lots of pages that link to it that aren't categories. In due course I might want to switch all categories over to this style, but I don't think that's necessary. --MartinHarper

A simple solution may be just to come up with a better name for the concept of CategoriesCategories that people link to, like CategoriesAndTopics. -- SunirShah

Most pages seem to link to CategoryCategory as a page, not as a topic, as far as I can tell. Let me vape SeeCategoryCategory and see what you think then. --MartinHarper

To make the special meaning of this link automatic I would spell it In:CategoryCategory. --ZbigniewLukasiak

http://meatballwiki.org/wiki/back=In:CategoryCategory doesn't seem to work, though? --MartinHarper

What I was aiming at was to develope a universal language for extra semantics in links. Since the colon (:) is allready used that way, I propose to extend it's usage to the new functionality. I did not mean that it is allready in the engine. -- ZbigniewLukasiak

(Aside) Perhaps "back" is doing a LinkPattern reduction on the parameter value. http:mb.pl?dosearch=1&search=In%3ACategoryCategory is a possible alternative; note that I used %3A to prevent the link from finding itself. -- anon.

NOTE: If the MeatballWiki site moves to a different wiki implementation (like UseModWiki 1.0), differences in searching and backlinks might require changes to any Meatball-specific category systems. (See below for sample code.) I am not planning any changes to the Meatball implementation at this time--that is SunirShah's decision to make. --CliffordAdams

What exactly is the problem with SeeCategoryXyzzy providing a forward link to CategoryXyzzy but not a backlink from CategoryXyzzy to the referring page? In understand it is not in the software, but that solution would not seem to muck up the backlink search, and require a minor complication for the display code, namely modifying GetPageOrEditLink to rewrite 'SeeCategoryXyzzy' as a link to CategoryXyzzy when prefixed by a 'DontBacklinkLinkPrefix. --DavidForrest

# somewhere in GetPageOrEditLink:
my $DontBacklinkLinkPrefix="See";
$id=~ s/^$DontBacklinkLinkPrefix($LinkPattern)/\1/;

Ack. That works in my UseMod, but the backlink search finds the CategoryXyzzy suffix on SeeCategoryXyzzy anyway. --DavidForrest

Current UseModWiki and Meatball implementations:

Here is the relevant backlinks code from the 1.0 release of UseModWiki:

  # At this time the backlinks are mostly a renamed search.
  # An initial attempt to match links only failed on subpages and free links.
  # Escape some possibly problematic characters:
  $string =~ s/([-'().,])/\\$1/g; 
  &PrintPageList(&SearchTitleAndBody($string));

The character escaping is needed because the search string is a Perl regular expression, and free links can contain characters which have a special meaning in that context. I vaguely remember trying to use the link database routines at one time, but I don't recall the specific reasons why I gave up on that approach. (One likely reason is that the link database code is much more CPU intensive than ordinary searches.)

The current (February 16, 2004) implementation of MeatballWiki is based on an older revision of UseModWiki. Its backlinks code is even simpler and it does not handle subpages or all valid free links correctly. (This is not a problem for Meatball because it does not use those features.) The "\b" sequences in the code below force the search to begin and end with a "word boundary" (like a space or punctuation). Here is the relevant line:

  &PrintPageList(&SearchTitleAndBody("\\b(?-i)$string\\b"));

As you can see, the backlinks implementation is practically the same as the ordinary search. This could change in the future, but I am unlikely to write or test alternate code in the near future. --CliffordAdams

Metadata categories and UseModWiki design:

In the original UseModWiki design I intended categories to be metadata--this was a major reason for the complexity of the current wiki DB code. (Categories would be stored in category sections, just as text is stored in text sections.) This would have several advantages, including:

  • Category edits could be shown separately (or hidden) on RecentChanges.
  • Category edits would not create a new revision of the page text. (They would not appear on diffs, they would not alter the last-changed date of the text, and they would not copy the (often large) page text.)
  • Category searches would search only the category metadata.
  • Category searches could be faster (one could reasonably create an index for categories -> pages).
  • Category names could be single words. This would be especially nice for sites that do not use the CamelCase LinkPattern.

Sites that try to closely follow the original WikiWiki "way" would see less benefit from separate metadata. Unfortunately, I never had time to write category-metadata code for UseModWiki, and I don't plan to do so in the near future. See PersonalCategories for more ideas I had about categories and wikis. --CliffordAdams

That explains a lot... any reasons why the database can't be in XML? -- Tarquin

Yes, there are lots of reasons. The main reason is that I don't think the current users would gain anything by using XML over the current nested-hash approach. Besides that, UseModWiki has very minimal requirements, and requiring a recent version of the XML libraries would exclude several users. (For example, the version of Perl on Futurequest.net (the current host of usemod.com) is almost 4 years old, and the XML libraries haven't been updated since then. I know several UseModWiki users who are using even older versions of Perl 5.) Sometimes I have coded workarounds for broken or extremely old Perl installations, but I don't want to worry about the database. (I have enough problems with truly ancient versions of CGI.pm.)

I think using an XML backend would be an interesting experiment for someone else to try. :-)

Finally, the database isn't the problem--categories are easy to add to the current DB. The biggest time factor is writing the user interface, especially if one wants to add options (like optionally hiding categories on RecentChanges). --CliffordAdams

I might try doing an XML database as part of UseMod:UseMOO, though I'll be keeping the current system for compatibility. -- TarQuin

Edit this page | History