THL Toolbox > Workflow Issues > Sakai Collaborative Worksite Technology > WIKI Publishing
Contributor(s): THL Staff.
We are using WIKIs as offered within the Sakai environment to build collaborative content. This is especially true for documentation, which generally needs constant updating to be useful and relevant, and content organized in complex hierarchies - such as the Encyclopedias - which requires multiple people to work on the hierarchy as well as its description and content. WIKIs allow for easy online editors by the generators of content themselves, as well as easy generation and revision of hierarchical organization schemes holding the content. In the future, with the implementation of a better WIKI system like TWIKI allowing for WYSIWYG editing and structured functionalitiy, this will become even more true.
For documentation, given the need for constant updates, the relatively informal nature of such documents, and their generally collaborative content, we plan for WIKIs to be the permanent home for such materials. However, scholarly ontologies or topic maps organizing information into complex hierarchies are best suited to publication in XML because of the need for multilingual interfaces, annotations, global updates of structure, metadata, and more. Thus our current plan is to use WIKIs to build the hierarchies and initial content, but then eventually publish in XML-GDMS. We thus need to look into an efficient way to convert a set of WIKI documents into GDMS. Even after publication, however, we will continue to want to use the WIKIs to help create supplemental content, so that we need a model which combines formal GDMS publications with ongoing content creation in WIKIs.
At present, it is simple to "publish" a WIKI so that it has a publicly viewable mode of access through a URL. However, quite a bit remains to be done to make this view user friendly.
Worksite WIKIs can be shown via URL to the public. You have to click on INFO for that WIKI, and then set the permission settings so that the public can "view" the pages. Then hit SAVE. Then go further down that INFO page in the feeds section where it says "Public View". Click on that, and it will open up a second window with the public view of the WIKI. Copy the URL from the browser address line and you have it. This public URL can also be used whether or not you have activated public view, but only by people within a worksite after logging in.
Please note it has settings for the public being able to "update" the page, but these do not work. That will only work if you want to have a link to your add a link to your publicly editable wiki page (that you provide to them) to their wiki that they can view and edit your wiki page from within their own worksite wiki. It doesn't make the "Public View" URL editable. But this seems irrelevant since within worksites its better to use the other protocol (see above) to just incorporate the other worksite's WIKI into the second worksite.
Wiki pages can be incorporated into a THL-style page using the
- a <title> element with the name of the page that will appear at the top of the browser's window.
- a <script> element linking to THDL Scripts
- a <link> element linking to the THL styles
The head is followed by a <body> which itself contains:
- a <script> element loading the banner scripts (/scripts/banner.js)
- the breadcrumbs for the page which are contained in two nested divs <div id="sub_banner"> which contains <div id="breadcrumbs">. (This is the usual formatting for breadcrumbs in THL.)
- and finally, the main div with its class set to "text-heavy" (<div id="main" class="text-heavy">).
Within this main div, one includes a single