Traditional Wiki Limitations
Traditional wikis are Content Management Systems (CMSs). The most notable example is WikiMedia, made famous by Wikipedia. Theses traditional CMSs only allow us to author and publish static raw content, with very limited formatting that goes beyond the most basic of HTML features.
As a result, these static traditional wikis make it very difficult to do things like create reusable formatting templates or to include metadata and data that facilitate things like aggregated querying, semantic meaning, and semantic linking between topics. The lack of these types of features make traditional wikis very difficult to use with other advanced technology concepts like Data Visualizations, Natural Language Processing & Search (NLP/NLS) and Machine Learning.
What’s worse is that links between pages have no semantic structure or meaning and there can be no links to or from objects that represent data records or instances of data types or classes. As a result, the usefulness of such tools is rapidly fading, especially in light of the Big Data revolution that’s been occurring.
The advent of Semantic Wikis
This lack of semantic tagging, structuring or inter-linking in traditional wikis means that they cannot easily be used like interactive systems that can be queried for meaningful data that meets certain point-in-time criteria. For example, it is difficult to use a traditional wiki like a Product Inventory System that has Product data records. We can try to mimic such features in traditional wikis by manually creating individual Product pages, Product data indexes, Product Catalogs and all the links between them but it simply is not easy and it does not scale well, considering how much manual labor is required to do so.
To address these limitations and requirements, the industry has started moving toward Semantic Wikis. Unlike traditional Wikis, Semantic Wikis allow content authors to create and embed both metadata and data into the content of their pages in a manner that helps better classify and isolate pages. For example, if you have descriptive product pages, you can use semantic wikis to embed attributes/fields like “Product Name”, “Product Category”, and “Primary Product Market”. Once such metadata and data is embedded, the Semantic Wiki can be queried to look for such metadata and data value to isolate pages. For example, we can ask for all Product pages where the “Product Category = B2B”, and this would return only those pages whose metadata and values meet such criteria. This is virtually impossible with traditional content-only wikis.
Pros of Semantic Wikis
- Semantic Wikis allow you to embed metadata and data into web pages. This allows doing things like classifying pages. For example, if your enterprise has a policy that your wiki must contain a descriptive project page for every Product, you can tag each Product page with metadata that helps distinguish Product pages from Service pages or Project pages.
- Semantic Wikis allow you to add descriptive context (e.g. Predicates) to relationships so that you know how one thing is bound to another. For example: “Person Jane Doe is a Subject Matter Expert for Product XYZ“.
- Semantic Wikis will look, feel and act a little more like relational databases. This means you can more meaningfully query the wiki, based on metadata, and data to find pages in the wiki. For example: Find all Product pages where the Product Category is equal to “B2B”.
Cons of (manually generated) Semantic Wikis
- Embedding metadata and data into each content page must still be performed manually, one page at a time. This means a tremendous amount of manual labor, a tremendous amount of wasted time, and (even worse) a tremendous amount of human error (i.e. poor quality). If you have a thousand Product pages, you’ll have to manually go into to each individual page and manually update data like Product Category for each one. There is simply no ability to create, work with, update, or restructure many content pages, all at once.
- Semantic Wikis are more technical than traditional wikis. This means you will have a difficult time teaching non-technical human resources the syntax for creating, formatting, and publishing articles that require them to embed metadata and data. It gets even more difficult if you want to teach them to create and embed things like semantic relationships. If your non-technical staff is already not writing enough articles for your knowledge repositories and content sites, adding more complexity will, more than likely, yield less content and materials for your sites.
- Just like you will have to teach people a whole new syntax for creating and publishing information into your Semantic Wiki, you will also have to teach them a new syntax and language for performing Queries and Semantic Searches for the purposes of getting data and information out of the wiki. Good luck trying to teach non-technical John Doe in Finance or Jane Smith in HR how to do this.
- You will still have to manually create, maintain and publish changes to all your Semantic Relationships. In just a small semantic data network or semantic data graph this could easily be hundreds of thousands of relationships. Imagine how much time and effort it will require of you to address this.
- You will still have very high levels of inconsistency across similar content pages. If you have many content authors, that exist and work in different areas of your enterprise, getting them to consistently create, enter and embed the same metadata and data is very difficult, to say the least.
- Your staff will still have to write queries to extract metadata, data, and semantic data. This means custom coding.
- Data analytics is not available as part of the integrated solution and, therefore, you still cannot easily embed interactive reports, charts and graphs, dashboards, and data visualizations.
- You will still have to pay for, install, maintain, integrate and support many other tools to get useful and usable interactive charts & graphs, reports, dashboards, and visualizations. This means your semantic wiki will be expensive, time consuming, and will always lead to much higher levels of technical complexity in your enterprise.
The evolution of Automated Semantic Wikis (Auto-Wikis)
In short, most semantic wikis present two very significant new problems.
- they require even more manual labor, and
- they include far more complex technology that most of your staff will simply not be able to take advantage of.
Auto-Wikis allow a single slightly technical person to heavily outperform very large armies of humans who can only perform manual labor in traditional wikis or semantic wikis. They work by ingesting data and using that data to automatically generate or synthesize massive quantities of content pages that are rich with features, formatting, metadata, data, semantic links, and advanced data visualizations. For example, what would take an army of people many years to create using traditional wikis and semantic wikis can often be performed in hours or days with Auto-Wikis.
Disclosure: All examples of automatically generated wikis (i.e. Auto-Wikis), contained within this publication, point to online examples of the IF4IT NOUNZ Auto-Wiki, which is a product that is developed and sold by the IF4IT. It is easy to use this wiki for examples because it’s already populated with example dummy data.
Semantic wikis are certainly more powerful than traditional wikis and have significant advantages if you can properly implement them. However, most semantic wikis still require massive amounts of manual labor and, worse, require the users to be far more technical than traditional wikis. This means higher levels of complexity and costs for you and your enterprise.
For this reason, Auto-Wikis are evolving. They are Automated Semantic Wikis that work like software compilers and allow one person (or a small group of people) with some moderate technical skills to significantly outperform massive armies of content generators who only can work manually. Auto-Wikis automatically generate (i.e. synthesize) massive quantities of richly formatted, highly organized, highly interlinked, and feature rich content pages that would otherwise require heavy investments of time and funds in custom software development.