GoogleInterWiki

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Today I (SunirShah) found myself annoyed that punching in Google:BookShelved:JhumpaLahiri into Google did not result in the page I wanted. However, I did notice that Google:BookShelved did find the right script. This got me thinking:

Suppose each wiki--or similar environments with NameAsLink? semantics--put as a MetaTag on its FrontPage, or even every page, the simple command:

 <meta name="namemap" content="url=http://example.com/cgi-bin/wiki.pl?">

or optionally to be more specific

 <meta name="namemap" content="context=MeatBall; url="http://example.com/cgi-bin/wiki.pl?">

Then when Google encountered the syntax, "Prefix:Name", it might first search for Prefix to see if the first link was a page with that MetaTag. If so, it would auto-redirect to http://example.com/cgi-bin/wiki.pl?Name.

Note that this does not actually require Google, per se, although it would be more efficient. We could write a third-party script to do this for any InterWiki mark up. Suppose you encounter InterWiki syntax that was not already included in your InterMap? Then you could use this GoogleInterWiki scheme to try to autodetect what it should be. You can then cache the target URL in your InterMap for the future.

Also, if you discover that your InterMap has entries that have moved and therefore have resulted in broken links, then you can automatically try to rediscover where the target URL is through Google using this scheme.

The only caveat is that enough wikis have to start using this system to make it worthwhile. Of course, it's also possible to try to do this without the MetaTag. Simply search for the Prefix, take the first URL, follow it, follow its redirects, and then try and replacing the query part of the URL (which may be empty) with Name to see if that resolves in a different page. This has a lot of points of failure though that would be best served with the MetaTag. After all, later on we could ask Google to only search sites that have that particular MetaTag to make the search more accurate. One day Google:MeatBall may return a cooking site, for instance.

The need for the context modifier is for cases like Google:Wiki that return the wrong wiki. It doesn't help the third party script, but it would help Google.

CategoryWikiTechnology CategoryUnimplementedWikiTechnology

This page is not named particularly well. WikiMetaTag?? SemanticNameServer?--as it is really a better domain name server based on the SocialSemanticSpace? that is PageRank? Well, you knw what to do. -- SunirShah

Roughly beat you to it; see my comment below from MetaWikiDiscussion. -- anon.

Bravo! Thanks for reminding me. That really makes me feel that I need to open control of MetaWiki in some way, now that we have meatballsociety.org to host it. I recognize that your suggestion below doesn't match directly with what I wrote above, but they are convergent rather than divergent, I think. -- SunirShah

A simple alternative would be to establish a convention of emitting wiki page titles in the form WikiName:PageName. Meatball is already pretty close. When I do Google:Meatball+Wiki:+InterWiki I get what I expect. Even Google:MeatballWiki:InterWiki seems to work, though I can't discern whether that works as a rule or just because lots of other wikis link to the page with that link text. Actually, it must be a fluke, because Google:BookshelvedWiki:TheVisitorsBook doesn't work.

This solves your problem of doing quick interwiki lookups. It doesn't solve my problem of doing metawiki-style searches for all wikis that use a particular page name. -- anon.

From MetaWikiDiscussion...

As more personal wikis are added to this list, MetaWiki might grow unwieldy for Sunir to maintain. Maybe we need to invent the following to "flag" wiki pages:

 <meta name='wiki-page' content='ThisPageName'>
 <meta name='wiki-name' content='MyIntermapPrefix'>

Then we might be able to use search engines to search for wiki pages. Perhaps we could persuade Google to provide a way to restrict searches by meta tag types and values -- at least for the Google API. After that we can invent

 <link name='wiki-text' href='url-to-get-raw-wiki-text-for-this-page'>
 <link name='wiki-index' href='url-for-raw-allpages-list'>

Then, on to a standard for text/wiki, and we can create a WikiBrowser to GET/PUT raw wiki text. -- anon. (half serious)

It's already beyond my ability to maintain. The metaparse.pl script already half supports inhaling wikis by type. While I initially thought that manual additions to the database were reasonable, I figure that's just opening it up to being spammed, so it would be preferable to use a page here to manage that, like the InterMapTxt. I think it's perfectly reasonable to demand every wiki engine provide an alphabetical plaintext listing of its page titles and PermanentAnchors before adding it to MetaWiki. -- SunirShah

so, it sounds like you want an addition to be specified by (a) it's InterMapTxt (or, if it's not in there already, then a name/url-pattern to add to it), and (b) the name of the WikiEngine running it, which implies a URL and output pattern that you can handle. Is that a fair statement?

of the bunch I requested adding, they all happen to be variants of UseModWiki, so the same URL works for them

my own wikilog is a ZwikiClone, but your MetaWiki Dec8 deletion implied some problem with the output of the "standard" url for it. And I'm not sure whether you were using the /listpages URL that Simon mentioned somewhere, or the /SearchPage??expr=&noheaders=1 (which is a poor general choice because it's unindexed). If you give some direction, I'll go back to Simon and come to agreement on a specific URL and output format to spread to the ZWiki community. --BillSeitz

On my newly discovered google toolbar is the option to look at google's cache of a page. I presume (?) is that uncached pages will never turn up in searches which may be the problem with your top search. I thought google didn't look at meta tags but my curiousity on the subject (today anyway) exceeds my knowledge --AndrewCates

This has been in [the Local Names specification] for a long time, now..!

The example in the spec is:

 <link rel="meta" type="text/plain" title="localnamespace" href="http://ln.taoriver.net/localnames.txt" />

[Greg Schueller] first recommended it in his blog entry, ["LocalNames and a Useful Semantic Web,"] in December of 2004.

I'm really interested in promoting this project, I think this is really valuable.

Because people don't express interest, I often times think, "Gee, maybe I should stop working on this project; Nobody seems to think it is interesting."

But every time I ask myself, "Is this really a bad idea," my heart and reason tell me: "No! You just have to keep carrying this ball!" -- LionKimbro