SwikiSOTA StandardWikiFeatures
From semanticweb.org
Contents |
[edit] 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.
[edit] 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:
- Backend: File based, Database, ...
[edit] 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
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)
[edit] 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 <filename>_<VersionNumber>
- 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:
