Managing IT Knowledge with XWiki

Main issues:

• Collaborative content creation in object-oriented manner
• Evolutionary approach to defining semantics; local changes to documents, generalizations and easy refactorings to reflect our growing knowledge about the structure of the data
• Design of wikified, reusable content templates and form elements; software as commodity
• How to reflect this knowledge itself (i.e. this article and related things) as structured, OO-content.

Introduction

Alternative Titles for the Article:

1. Evolving Wikis for Everyone/Dummies
2. Gradual Introduction of Wiki Technologies and Social Processes
3. Wikies and Multi-Facetted Knowledge Classification

Our inspiration has been O'Reilly series books called "… cookbooks" (e.g. Java Extreme Programming Cookbook). All these are collections of recipes, which share certain attributes. Each recipe ideally should relate to one or more pieces of software; for each software item the applicable version numbers are indicated. Also operating systems, platforms and standards may be noted in the technical characteristics of a recipe. There usually is a brief description of the problem, and then there is a solution. Some recipes may be dependent on others - they form a directed (and, hopefully, acyclic) graph. Then there are links pointing to other recipes or, generally, resources in the Internet, which can make valuable reading once this recipe has been completed. We try to view such recipes as data objects of our main interest, and look at the ways to organize them on this platform, namely, XWiki.

Data model

Figure: UML Class diagram for Software Recipes in XWiki

Issues

• Can we reuse one template (which is good for document display) in another template? Any way to reset current $doc? If template is used as standalone, then "doc" has the correct value, if it is used in an iteration over a list of objects, the "doc" should always change.
• How (not) to reuse the given fields in the XWiki model - e.g. is "XWikiDocument.title" used to store bookmark titles, or is it more convenient to create additional attribute for an object?
• When to create a document, and when an object is enough? Should object die with the document? Similar question: Aggregating objects versus creating a link between documents? I.e. when the children should be destroyed by a cascade?
• Any means to validate XWiki links, if these are used as values in another object?
• How to represent hierachical structures in XWiki (each document represents a simple hierarchy)
• When should we have child documents inheriting properties from their parent documents? (Implementation by adding new edges to the model.)
• How to deal with ontology inference (e.g. inprelistof's inverse is subproperty of seealsolist)
• How to use XWiki multilanguage support; how it interferes with objects
• Can text fields have history (and diff comparisons)
• Ontology included in the object versus universal Meta object with property/value pair
• How to use tags? Can tags be documents and people or just simple strings?
• Defining portal layout with XWiki objects (i.e. RDFish data structure)
• Using Wiki-editable templates to build composite views (including paged results and lists of values)
• XWiki means of simple workflow implementation
• Map of data structures to RDF-like graphs

Requirements for the Music Project

These are the remarks regarding Songs project on this Wiki?:

• Need to execute command-line scripts (e.g. LilyPond and LilyBook processing; SVN checking) on Ante server. Avoid code-injection. End-users may call servlets included as IFRAMEs (XWiki plugins??), which upon refreshing display the result, when it is obtained.
• It is good to store file resources on SVN, but one should use Ante (the XWiki server) instead of Google. (1) It may increase availability; (2) one can use the same LDAP user rights for both XWiki editing and for SVN; (3) can avoid unnecessary checkout, which is usually done with Google.
• There are meta-info fields, which populate select-boxes. Current approach (hardcoding them to Velocity forms) is not extensible and does not facilitate readable Velocity code. Consider a special "classifier" object class, where a superadmin may create instances, and regular users get those sorted object lists quickly during Velocity script runtime (the values should be cached, instead of running HQL query every time).
• Meta information fields may be displayed in a full list (empty value means that the property is not set). This avoids cluttered Velocity code.

Items requiring special processing

Texts about IT and other technologies usually contain various sorts of items that should be both visible/embedded in the text and also independently referable from outside and they can make up various indices and cross-reference tables. Here we list the items:

1. References to special terminology.
2. References to people, geography locations, etc. If these are not appearing in a systematic manner, we can handle them in the simplest possible manner - show original spelling of unusual names besides the text in Latvian. Thus they can be found with a full text search. If any sort of index is needed, they can be handled in a similar manner as terminology items.
3. Attachments.
4. Images. Unless we want a fast draft solution, we want to avoid placing images as attachments to the documents.
5. Tables and code samples.
6. Mathematical formulae
7. Quoted Web links.
8. Other bibliography references
9. Some texts may also contain references to more complex objects, e.g. live demos and web-based tools (online validators, games, useful applets, etc.). Since these inside XWiki pages, but they typically have URL addresses, we can simply refer to them as a special kind of Web links.

Tutorial Related Recipes

• Reusable Variables
• Multilingual Class Sheets

List of approaches

In analogy with Web 2.0 (Tim O'Reilly list) and AJAX programming - we can list our approach to collaborative training material development.

• Flat user hierarchy (instead of managing various levels of user rights, all users, except superadmin are created equal - security is handled by frequent back-ups and/or versioning).