30px No slides known
- Review no.
- Title of the submission
- Type of submission (workshop, tutorial, panel, presentation)
Tutorial or Presentation
- Author of the submission
Dr. Vadim Zaytsev
- E-mail address or username (if username, please confirm email address in Special:Preferences)
Spider or firstname.lastname@example.org
- Country of origin
- Affiliation, if any (organization, company etc.)
National Research Institute for Mathematics and Computer Science, Amsterdam, The Netherlands
- Personal homepage or blog
- Abstract (please use no less than 300 words to describe your proposal)
Migrating a wiki site from one place to another is not an uncommon activity, and not a pleasant one either. To provide motivation for those unfamiliar with the subject, as well as to establish a common ground for those who have participated in a wiki move or have witnessed one, a range of scenarios will be presented where various types of migration will be named, such as forking, merging, engine upgrading, farm deterioration, domain specificity introduction. The core part of the tutorial/presentation will mostly address the issues of community migration, content migration and ontology migration.
Community migration. Unless someone wants to move a (part of) wiki and start over on its basis, there needs to be certain awareness built among both active and dormant wiki participants. In the case of forking, each member of the community needs to decide whether to stay or move and properly and needs to be truthfully informed before the ultimate decision point. The community will also appreciate if the user base of names and passwords can be migrated in an automated way so that nobody needs to make a new account. When this is unavoidable, one should at least try to prevent confusion introduced by possible name clashes between edit history and new account names. Search engines, sister projects, portals, etc should also be keep informed in an appropriate way. All of this should be done in a way that poses the least problems for the end users.
Content migration. In a migration project from one MediaWiki site to another one, content migration is simply a question of choosing the right time to make a wiki snapshot, exporting all revisions of all articles, importing them all into the new place, making sure that it raises no licensing ambiguities and enjoying the result. However, if a considerable number of articles were written in another wiki engine dialect (say, when going from WikiDot to MediaWiki), there is a need for more elaborate translation. It will be shown how to automate this process by using established technology from grammarware research domain, including techniques like data scraping, skeleton grammars, refactoring, code analysis, semi-automated manipulation and meta-programming. Automation will show considerable boost and reduction of migration effort in large wikis.
Ontology migration. Blindly converting available content, directing the right people to its new location and hoping to get a perfectly working wiki site is an unreasonable dream. Some additional concerns will be highlighted and explained, such as developing mappings between paradigms and ontologies used to organise and annotate the wiki content (e.g., tagging vs. categorising). As a more sophisticated example, one can think of the way media files like images are treated: in MediaWiki, they are basically separate entities with their own edit history and discussion pages; in PBWorks, media files have revision history but no description; in Wikidot, they are file attachments of specific pages (that can still be references from other pages); in TiddlyWiki, files are fully separated and only links to them are stored as wiki data; etc. Another example can be a question of writing style: some pages migrated to a domain specific wiki will need to be marked for future rewriting.
At the end of the tutorial, the participants will be expected to acquire increased familiarity of the list of issues they should look forward to confront while engaging in a wiki migration process. They will also be made aware of existing approaches and tools for automation of most tedious activities of that process.
- Track (People and Community/Knowledge and Collaboration/Infrastructure)
I prefer to touch on all three topics anyway, so any track would be fine, but in order of preference:
- Knowledge and Collaboration
- People and Community
- Will you attend Wikimania if your submission is not accepted?
Yes, I received a partial scholarship to do so.
- Slides or further information (optional)
- The sample wiki concrete syntax grammar used during the talk: SourceForge (CC-BY)
- Slides for the talk: PDF (CC-BY)
- Rascal meta-programming language: http://www.rascal-mpl.org (Eclipse public license)
If you are interested in attending this session, please sign with your username below. This will help reviewers to decide which sessions are of high interest. Sign with four tildes. (~~~~).
- Yaron Koren 00:34, 18 April 2011 (UTC)
- Millosh 14:23, 20 April 2011 (UTC)
- Vibhijain 13:47, 4 May 2011 (UTC)
- Jewbask 14:32, 20 May 2011 (UTC)
- Geraki 06:04, 15 June 2011 (UTC)
- Roy Emanuel 08:12, 26 July 2011 (UTC)