Integrating Wikipedia With a Local Intranet Wiki 121
An anonymous reader writes "I work for a large company taking a preliminary look at developing an honest-to-goodness wiki. We have tried to launch a company-wide wiki before, but with little success. The technical domains of each part of the company are different, thus each article needs a good deal of background to be useful. Of course, due the proprietary nature of our work we cannot share our articles outside of the intranet. What we would like to do is leverage existing wikis by augmenting our internal wiki with an external wiki. When a user accesses Wikipedia from inside our intranet, they receive the wikipedia content, plus the local domain specific information. For example, links to company-specific wiki pages would be available in Wikipedia pages. Has anyone else tried to do something like this? I know it sounds like a logistical nightmare; are there any thoughts on how to make this successful?"
bad idea (Score:5, Interesting)
Re:Solution (Score:5, Interesting)
Dumps go stale, Wikipedia is updated all the time. I'd suggest something a bit more dynamic.
I did something similar (conceptually) as a dynamic help system for our web-based application, and had content in a wiki based on the URL of the page where the help message was to apply. In my case, clicking the "help" button on a page would make a proxy call to a private wiki to get the help menu content. If none was found, an email was sent to support desk and the end-user was given a web-chat prompt to tech support (with the URL prepended so that tech support could jump in, answer the questions, and write the help menu in one fell swoop)
In your case, start with your local wiki. Presumably you have some stuff in there already. Rename the articles as necessary to match URLs from Wikipedia.
Then, build a simple proxy server that rewrites wikipedia content to include a header of your local content. Probably 100 lines (or so) of glue code, and anywhere from a few man-hours to a few man-days coding.
The rest is all training.
interwiki (Score:5, Interesting)
Don't (Score:5, Interesting)
Legitimate use for this hack (Score:2, Interesting)
Am I the only one which cannot see any legitimate uses for this hack.
Why lure your users into thinking the content is on wikipedia if it is on your network?
Can't your users use wikipedia _and_ your wiki.
Sincerely I think that the goal for this hack is luring users to think they're reading/editing wikipedia for someone's profit.
What? (Score:3, Interesting)
Why? Can't you just link to wikipedia pages where appropriate? OK, my company has an internal server we link through to sanitize referrer info so our internal wiki titles don't get all over teh interwebs. But if the wiki users can't figure out "hey, this article is too specific - maybe wikipedia has more general information that would help me," you've got bigger problems than your wiki management.
part of an Intelligent Book (Score:4, Interesting)
A very small part of My PhD [cam.ac.uk] looked at this (but with "collaborative textbooks" rather than wikis) -- see Chapter 4. Adding a very simple metadata-based navigation layer over the top of the wiki is pretty easy, clean (doesn't confuse users), and seems to do the trick. The wiki itself shows in an embedded frame. Of course, I had to go further and let students do difficult number theory proofs backed by machine reasoning systems within the book, but you won't have to solve that problem!
I'm (gradually) putting this fairly simple but useful part of the software into an online resource at www.theintelligentbook.com [theintelligentbook.com], though it's in my spare time and the system is down at the moment. I'll put my contact details back up there shortly in case the question-asker wants to discuss it technically.
Re:Don't (Score:3, Interesting)
I agree (would mod up but gave up modding way back). However this is an interesting and probably reoccurring problem: extending the wealth of public net wisdom with precision data from local context (organisational or task-centric rather than geolocational).
A proxy adding local content into pages loaded from outside as suggested in Re:Solution by mcrbids [slashdot.org] would solve some of the problems you mention:
* The wikipedia content will always be out of date
* it's fetched from real sources in real time
* Changes made to wikipedia content don't get fed back into wikipedia
* this changes to risk of unintentionally publishing private information - how hilarious!
* Trying to load the wikipeida DB locally is a headache due to its shear size
* not done; could instead cover the whole of outside web with one solution.
This problem remains:
* Creates confusion as to what is and is not company information
I guess you'd be best off injecting a (user-hidable) "widget" layer that would contain all the local information needed, thus providing clear separation of local and global content. Least breakage of existing layout that way, I hope.
I assume here that we restrict our proxy to embed HTML (possibly including Javascript) into well parsing HTML pages only, so as to avoid breaking things as much as possible - inevitable to happen sometimes anyway.
Updating the contents of another window based on browsed content would require either
* a single sign-on solution to target references to correct user's desktop (seen in updaters of multiple applications views in medical solutions for instance) or
* a browser-specific local hack to study each page url and content and to fetch related information from local database based on those.
OT, adding such meshing into Google Wave would probably prove an interesting challenge :) Think of doing it Right (tm), with private additions to documents and discussions getting saved and tracked on local servers while public parts would be passed on to public servers.
There's lots of value in a compound wiki (Score:4, Interesting)
Ignore the nay sayers. Of course there is a lot of value in aggregating content and creating a compound page that blends your internal content with other sources.
From a usuability and authority-of-source perspective, however, I think it would be best to list each source in a separate section on the page, starting with your internal content at the top. You can get to the other content either by embedding links into your internal content, or by collecting the links in a separate section.
Wikipedia itself uses the embedded technique. When composing or editing an article, the author can embed markup for external references. On display, this markup is turned into a footnote link at the point of embedding, and a footnote at the bottom of the page. I don't see why you couldn't do something similar. In this case, however, you would be embedding references to Wikipedia articles.
I don't see why you couldn't do something similar. In your internal wiki templates, have a custom markup for embedding wikipedia queries related to the article. On display, turn this markup queries either into embedded links to footnotes, resolve the queries and deposit them at the bottom of the page, or toss them into iframes and let the user sort it out.
The other technique is to have a custom form in your internal wiki template where you collect the cross-references. On display, turn these queries into links or resolve them into content.
In any event, why limit yourself to Wikipedia? Include cross-references to patent search engines and other domain-specific sources.
A big word of caution, of course, is owed to the legal angle. Make sure you follow the law whenever reusing anyone else's content, even if it's just a link. Have your legal department sign off on your reuse policy. Don't distract them with technical aspects of what you want to do. They're lawyers; they only care about the law. Ask them a specific legal question, such as, "what is our legal exposure if we republish (links to or actual content from) Wikipedia on our internal wiki?".
Re:URLs (Score:3, Interesting)
Said in a crude way; but to the OP: This guy is right. The most brain-dead simple way to make this work is to just set up your own wiki, and pepper it liberally with links to relevant Wikipedia pages. As someone below points out, there's even a feature in MediaWiki to make this linking easier (look up "InterWiki" in the MediaWiki help).
You may even be able to set up #REDIRECTS using InterWiki links so that people can still see the page names you want in your search and category listing, and then be taken straight to Wikipedia. If you want to get fancy, you can create a Template that opens the Wikipedia page in an IFRAME or does some DHTML to embed the content, so that the surrounding trim (edit link and search box) is for your wiki. The key here is to make sure people understand which content is your own wiki and which is Wikipedia -- whenever they edit or add a page, it goes into your wiki; treat Wikipedia as read-only. (If someone wants to make a genuine contribution to Wikipedia, they can go do that the normal way.)
I think that's the tightest integration you can get -- easy access to Wikipedia info, plus your own wiki for company-specific stuff. On the other hand this right here sounds like a recipe for disaster:
When a user accesses Wikipedia from inside our intranet, they receive the wikipedia content, plus the local domain specific information. For example, links to company-specific wiki pages would be available in Wikipedia pages.
That's not a logistical nightmare; that's a major development effort, just for a freakin' wiki. Requirements like this are why so many software projects fail. Abandon the pie-in-the-sky vision and go with something simple to start.
Like URLs.