SwikiSOTA StandardWikiFeatures

Description Scheme:

 * Name
 * Short description
 * Rationale (also for additional users
 * Scale, Possible Values, Explanation

BD: Maybe we should take some of the features mentioned under http://www.wikimatrix.org into account.

Copy and Go Section: Take this to describe your Wiki

 * User Features
 * Editing: Basic, Supported, WYSIWYG
 * Markup Syntax: Wikipedia style, JSP Wiki style, TikiWiki style, ...
 * Access Rights: None, User Group > Only Registered, Per page > Per Page with default
 * Attachments' allowed?: Yes, No
 * Versioning: No, Yes > Diff, Rollback, Permalink
 * Navigation Support: Backlinks, TOC, Categories, ...
 * Tagging of pages: Yes, No (Attention might not be relevant)
 * Plugins: No, Yes > ....
 * Further Features: Web-Dav access, Whiteboard, Portlets, Security / SSL, Offline editing with synchronization, ...
 * Developer Features (things relevant when you want to "tap" a wiki)
 * Backend: File based, Database, ...
 *  Versioning 4 Devs: None, File based, Database
 * XML-RPC Ready: None, Read only, full access
 * Extension Mechanisms: None, Plugin, Portlets:

User Features
Editing
 * Description: The interface used for editing Wiki content
 * Rationale: In particular user groups with a "low" computer literacy might have problems using the regular markup syntax
 * Rationale for Developers: With a WYSIWYG interface, integrating semantic markup might be more difficult
 * Scale
 * Basic: Content can be edited with markup only (like this Wiki)
 * Supported: Regular Markup is used, but some buttons support editing it by inserting Wiki Markup (like in TikiWiki)
 * WYSIWYG: No Markup is visible to the user via a WYSWIG interface

Markup Syntax
 * Description: The Markup style of the Wiki
 * Rationale: If a user group already uses a regular wiki, this characterization allows to determine how easy it is to switch to a semantic Wiki.
 * Scale ''In general, just mention the amrup you had in mind when creating this semantic wiki)
 * Wikipedia style: Headings are created using == ==, Links are marked by double squares
 * JSP Wiki style: Headings are created with ! (More ! --> Bigger Heading)
 * Tiki Wiki: ...

Access Rights
 * Description: Whether the Wiki allows to restrict access to pages or functions. It does NOT cover aspects of ontology editing, since this is no regular wiki feature
 * Rationale: For some reasons, the access to wiki content might be restricted (e.g. locking of content)
 * Scale
 * None: The Wiki (itself) does not offer access restructions (of cours, you could use features of the server (apache) to restrict access
 * User Group: User groups can be defined that have general access rights
 * Only Registered: Only registered users can edit content (common specialization of above value; One can configure MediWiki like this.
 * Per page: Access can be defined on a per page basis (like in TikiWiki)
 * Per Page with default: Default access rights are defined for user groups, but might be overwritten on a per page basis(again: like in TikiWiki)

Attachments
 * Description: Whether additional files can be added to a wiki page
 * Rationale: One might need this!
 * Scale: [Yes|No]

Versioning
 * Description: Whether changes to wiki pages are saved
 * Rationale: Needed for "safe" collaboration)
 * Scale: [Yes|No], if Yes, some of the following might apply
 * Diff: Show differences between two versions
 * Rollback: an older version can be made the current version
 * Permalink: A link can be created pointing to a specific version

Navigation Support
 * Description: Set of features that support navigation
 * Rationale: Straightforward, innit?
 * Scale (open for further values)
 * Backlinks: References to a page are listed on a page
 * TOC: Table of content; is there a feature to create a table of content
 * Categories: Pages can be assigned to a category (might be relevant to extract ontologie)

Tagging of pages ''Might only be relevant for a regular wiki, not for a semantic Wiki'

Plugins 
 * Description: Are extensions to wiki features (plugins) supported, and if, which ones?
 * Rationale: This supports users in using the wiki
 * Scale: [Yes|No], if yes
 * Example: http://www.jspwiki.org/Wiki.jsp?page=JSPWikiCorePlugins

Further Features (Might be merged with plugins, because to a user, only the functionality itself is relevant, and not how it is implemented)
 * Description: Further extensions, not implemented as wiki
 * Scale (open, more than one might apply)
 * Web-Dav access: User can store content via Web Dav
 * Whiteboard: User can draw simple pictures
 * Portlets: User can add or remove portlets (like in TikiWiki)
 * Security / SSL: Ist there an encrypted transmission between server and client (in most cases, this is no feature of the Wiki, but of the server where the Wiki is running)
 * Offline editing with synchronization: Can content be edited when not online and later put on the wiki (Flexwiki supports this somehow)

Developer Features (things relevant when you want to "tap" a wiki)
 Backend
 * Description: How is the Wiki content stored (pages and attachments, if available)
 * Rationale: Give a hint on how to use versioning information
 * Scale
 * File based: Pages and attachments are stored in files
 * Database: Same as above, but in databases

 Versioning 4 Devs (Subfeature of Backend?)
 * Description: How are versions stored
 * Rationale: Give a hint on how to use versioning information
 * Scale
 * None
 * File based: Versions are stored in files (e.g. by different filenames like _
 * Database: Versions are stored in databases

XML-RPC Ready
 * Description: Whether the Wiki support the Wiki XML-RPC interface
 * Rationale: [XML-RPC for Wikis] is a standarized interface to wiki content. The hope is that you only need to implement this interface once and use it with different wikis
 * Scale
 * None
 * Read Only
 * Full Access

Extension Mechanisms
 * Description
 * Rationale: The extension mechanism might support creator of semantic wiki to use
 * Scale (more than one might apply)
 * None
 * Plugin:
 * Portlets: