This paper introduces the Graphingwiki extension to MoinMoin Wiki. Graphingwiki enables the deepened analysis of the Wiki data by augmenting it with semantic data in a simple, practical and easy-to-use manner. Visualisation tools are used to clarify the resulting body of knowledge so that only the data essential for an usage scenario is displayed. Logic inference rules can be applied to the data to perform automated reasoning based on the data. Perceiving dependencies among network protocols presents an example use case of the framework. The use case was applied in practice in mapping effects of software vulnerabilities on critical infrastructures.
In recent years, Wikis and the semantic web have become the state of the art methods
for the management of information. Wikis have proven to be an effective means for the
collective gathering and editing of bodies of data ranging from encyclopaedia to bug
tracking and journals. Semantic web is envisioned as a universal medium for data
exchange and as a tool to manage the interconnection of information, enabling automated
analysis of data. [
Both of the technologies have strong selling points: Wikis enable collaborative,
open, evolutionary, and easy modification of data, and the semantic web employs
Resource Description Framework (RDF), a powerful yet relatively simple language for
representing information about World Wide Web (WWW) resources. RDF consists of
subject-predicate-object triples that are used to make statements about resources [
Combining the approaches and techniques of Wikis and semantic web has met little
success. The little support traditional Wikis offer for semantic data usually culminates
in page categories and different kinds of comment tags. Semantic web tools are often
single-user oriented and their operation frequently requires expert skills, which makes
knowledge engineering challenging for domain experts. [
Wikis have the strength that they focus on the structure of the data instead of its
presentation. Wiki users are accustomed to creating, linking and tagging content, which
represent the bare minimum requirements for taking advantage of semantics. Adding
semantic features to Wikis offers a smooth transition for exploiting different layers of
knowledge. [
This paper introduces Graphingwiki, a Wiki extension that aims to enable
knowledge engineering in Wikis by sidestepping the complexity of semantic technologies.
The bare minimum functionality for semantic capabilities in a Wiki includes the
implementation of a small but functional subset of RDF. This also follows the Wiki way of
doing the simplest thing that could possibly work [
The tags of represent a flat namespace and do not have a hierarchy of any kind. In a
way, this method of adding semantic data resembles folksonomies such as del.icio.us1.
Tagging is simple and unrestrained as it aims for easy diffusion in the user base.
Existing mechanisms, such as different kinds of linking, category pages and macros, are
utilised as much as possible. Users may freely select the tags they use, which thus
sacrifices consistency for practicality. This approach can prove more useful than forcing
any predefined tagging schema [
A Wiki functions as its own ontology, formed by all the tags in the Wiki’s pages
[
Interactive visualisation is proposed as a method for understanding the relations of information on the Wiki pages. Visualisations can be used to navigate the Wiki, and they include facilities for filtering out non-relevant data. This enables the quick derivation of a general view on any desired topic or entity.
Furthermore, Graphingwiki includes some logic reasoning capabilities for refining specific knowledge from the Wiki tags. Wiki pages can include rules that lead to new conclusions about specific tags, and the resulting data can be queried for sets of pages and tags that fulfil the premises of the query. This presents a fine-grained method for discovering relations amongst the wealth of data.
The paper presents the methods in the context of a practical use case, fathoming interdependencies in communication protocols. It is also argued that a similar knowledge management approach would also be effective for other domain-specific tasks where an
universal topical scope and some of the other stumbling blocks of semantic technologies
are not an issue [
The paper is structured as follows. In section 2, additions to traditional Wiki features are presented, which beget methods for gathering, visualising and reasoning on the data for the example case. Section 3 presents some results of an initial analysis of the use of Graphingwiki. Directions for future work are laid out in section 4. Finally, the work is summarised in section 5. 2
The main methods used in Graphingwiki include additions to the MoinMoin2 Wiki markup and plug-in tools that save the semantic data for later processing, visualise the semantic data and make logical reasoning based on it. 2.1
MoinMoin was selected as the starting point for semantic Wiki development based on the criteria that it is open source, implemented in the Python3 programming language, is mature and extendable, and uses a file database. Graphingwiki is implemented as a set of plugin actions to manipulate the page data, macros, and formatters to render the semantic data to the desired viewable or processable forms. The design strives to maximise backwards-compatibility and the use of existing MoinMoin features.
The semantic data in each Wiki page is stored into a file of its own, in a symmetrical manner with the page data storage in the MoinMoin Wiki. A general-purpose graph library was created for this purpose. Semantic data is interpreted with the help of existing and augmented Wiki markup, and serialised in the defined graph format. As the markup allows for incoming links links that are not shown on the wiki page itself, a global file database of page linkage was also implemented.
Graphingwiki uses the Python bindings of the Graphviz4 suite of layout tools to visualise the semantic relations of a Wiki page as graphs. The inference module is a simple unifier-based design in the style of many Prolog implementations. 2.2
The chosen markup additions resemble closely those utilised by the semantic Wikipedia
-project [
The goal of the markup additions is not to implement the whole of the RDF notation, but to present the user a simple and intuitive way to make statements about a Wiki page.
3 http://www.python.org 4 http://www.graphviz.org 5 http://theendmusic.org/programming/MetaDataPlugin Statements can only describe the containing Wiki page in relation to page tag values, Wiki pages and URI resources. Semantic data is marked up within page content and rendered in a meaningful manner when the page is viewed.
There are two kinds of statements users can make about a Wiki page: MetaData statements and augmented link statements. MetaData statements are used to realise semantic page tags. They are implemented with a macro and therefore follow the MoinMoin macro syntax of the form [[MacroName(arguments)]]. The arguments of the MetaData macro consist of tag-value pairs with an optional third argument that omits the macro from page rendering. For example, the statement [[MetaData(SpecialPower, x-ray vision)]] on a superhero Wiki page denotes that he or she has the extraordinary ability to conduct airport security checks without external hardware, among other things.
Respectively, augmented link statements are used to implement semantic link tags. They extend the MoinMoin named link syntax forms [:OtherPage:Wiki page] and [http://example.com URI resource] that create links with descriptive labels (see Figure 1). Augmented link syntax adds a link tag to this markup, resulting in links of the forms [:OtherPage:linktag: page] and [http://example.com linktag: URI resource].
The special keyword “From” in the end of the type string denotes that the link is an incoming link, i.e. the referenced page links to the current page instead of the current page linking to it. For example, the statements [:OtherPage:linktagFrom: page] and [http://example.com linktagFrom: URI resource] indicate that the current page is referenced by the Wiki page or the WWW page, respectively.
The statement [:DrX:Nemesis: DrX] on the superhero Wiki page tells that the nemesis of our hero is Dr. X, described in the same Wiki. Respectively, [http://example.com FanClub: http://example.com] states that the hero’s fan club has its web page at the URI http://example.com. Repeating the link in the descriptive string is not required, the examples do so for reasons of clarity only. Figure 2 illustrates the rendering of these statements.
The notation defaults to the namespace designated by the Wiki. To avoid collisions with regular Wiki pages, the pages describing the page tags and the link tags are prefixed with ’Property’. Thus, in the examples of the previous paragraphs, ’PropertySpecialPower’ and ’PropertyFanClub’ are pages in the same Wiki.
By editing the descriptions and semantic data on the Wiki pages describing the page
tags and the link tags, the community creates a contract on the formal meaning of a
domain - effectively an ontology. This lets the users freely edit the ontology in a very
Wiki-like fashion, which reduces the entry barrier and encourages vocabulary growth
and expressiveness. For example, users of the superhero Wiki can elaborate on the
concept of special powers (i.e. the content of the ’PropertySpecialPower’ page), adding
further information, declaring exceptions, and so forth. The availability of discussions
on the subject, along with relevant links and multimedia, will help in understanding the
concept. [
Graphingwiki is not planned to support any deeper semantic meaning to ontology
entries. RDF schema or datatypes are not supported, nor are pages checked for
consistency with any formalism. However, template pages can be used to create implicit
meta-ontologies similarly as in Wikitology [
The semantic markup supports namespaced statements. The list of valid namespaces is gathered from the Wiki’s InterWiki list. For example, the statement [[MetaData(Wardrobe:JumpSuit, Spandex)]] tells us that the hero in question wears a flashy spandex jump suit, and that the specifics on the style of dress can be found in the Wardrobe Wiki. Respectively, the statement [wiki:WikiTwo/PageTwo OtherWiki:SeeFrom: wiki:WikiTwo/PageTwo] represents the situation where the page ’PageTwo’ of the Wiki ’WikiTwo’ has a relation with the referencing page defined by the page ’PropertySee’ in the Wiki ’OtherWiki’. Naturally, by adding the line dc http://purl.org/dc/elements/1.1/ to the InterWiki list of the Wiki in question enables the user to employ Dublin Core6 definitions in the Wiki pages. Although InterWiki lists are currently not user-editable in MoinMoin, the InterWiki list provides a relatively clean and straightforward way to add new scope to Wiki editing. Graphingwiki uses the namespaces merely as URI prefixes to the resource names, the RDF data corresponding to the resource is not fetched. Still, the namespaced URIs offer some advantages, as users can use standardised seman
tic tags with well-defined meanings, some primitive inference rules involving different
namespaces can be used, and external RDF tools can utilise the full scope of the
external semantic data. The semantic data in the Wiki data can also be dumped from the
Wiki in N3 [
Visualisations are composed of the node of the current Wiki page, the links leading to the page and from the page, and the nodes depicting the linked pages. Alternatively, all pages belonging to a category of the current page can be used as the root nodes of the graph, instead of merely the current page node. Visualising a category shows a whole field at one glance, including the direct and indirect relations of all the members, along with their immediate surroundings.
Page tags can be used to colour the nodes of the graph, and pages can be filtered based on their tags. Respectively, augmented links are coloured with respect to their link tags, by which they can also be filtered. Filtering can greatly reduce the clutter in the visualisation, and helps in concentrating to desired aspects of the data. Graphs can also be ordered with respect to one of the page tags. The tag values are lexically sorted, determining the rank of the nodes corresponding to the pages. Colouring and ordering the nodes offers two dimensions by which to organise the semantic data.
As an example, Figure 3 depicts a visualisation made by Graphingwiki with data automatically extracted from the WiFiPedia7 wireless standard resource.
While visualisation makes semantics comprehensible, inference makes it operational.
Generally speaking, inference is used to extend the set of known facts with the help of
rules that concern them, and to find the facts, if any, that prove a stated goal. Inference
engines that take the first approach are called forward chaining, as they start from valid
data, while backwards chaining starts from the goal to be proved, and apply known facts
and rules to produce a proof. [
A backwards-chaining inference engine is used to answer queries on semantic data. The engine uses Horn clause logic, i.e. clauses that do not have more than one positive literal, also used by many logic programming approaches such as Prolog. Horn clauses have desirable properties in that their satisfiability is solvable in polynomial time with algorithms linear to formula size. As the semantic data can be expressed in the terms of RDF triples, which are basically simple relations, it is straightforward to map them as clauses.
The inference rules and queries are stored as Wiki pages for easy editing and reference. The rules are expressed in the N3 notation, as Graphingwiki markup extensions do not include any way to express them. The result of the query is a set of RDF triples, also in N3 format, that maintain the conditions presented by the query. For example, according to the old adage “the enemy of my enemy is my friend” an evil mastermind, Dr. X, might want to query the superhero Wiki for enemies of his enemies to find new
GB15629.11-2003 802.11j 802.11f 01 02 03 Graphingwiki has been used for the purpose of discerning and visualising interdependencies of protocols. Data is gathered from technical specifications and from experts of different protocol environments. The accumulated data is then visualised, bringing up different aspects from the data related to protocol dependency and security. The resulting views can additionally be used as a communication method between researchers and other actors. Inference is used as an method of gaining deeper insight to dependency chains and networks. Protocols can be thought of as languages shared by the information systems for communication. Most current information systems implement a large number of protocols, most of which it requires for normal functionality. In effect, the system can be communicated with by a number of means, and it parses diverse network data. This makes the system, as the other systems on the network, dependent on the implemented protocols in a multitude of ways. Assessing the dependency of protocols and the predominance of the protocols in the network is critical in the view of its robustness.
The issue is further complicated by the fact that protocols within a single protocol
family or even between protocol families often have connections. Thus, the impact area
of vulnerabilities in a shared component is greatly expanded due to protocol
dependency. This may lead to faults that can have a significant effect on an infrastructure.
[
While the process of adding given semistructured data cannot be effectively
automated for all cases, the extraction approach is a pragmatic one, making the best use
of the data available. Although the different data sources may adhere to any number
of conflicting explicit or implicit ontologies, a lightweight approach to ontology gives
the leverage to process the resulting primordial soup. This represents a bootstrapping
process for semantic Wikis, as the benefits of semantic data are illustrated only by the
availability of such data. These benefits far outweigh the costs of generating the
semantic data along with the data. Similar approaches to data extraction have been applied
successfully [
After the initial data gathering phase, the data is inserted into Graphingwiki. The details of this process are somewhat subject-dependent, but follow the same basic principles. Whenever new concepts are introduced in the data, new Wiki pages are created to describe them, and data concerning a protocol or other concept already in the Wiki is simply updated to that page.
As much of this data as possible is inserted to the pages in the forms of the attributes
of the concept and its relations to other concepts, as these forms of data are
machineprocessable. Page templates can be used to help formalise the extended markup [
In the collaboration phase, the experts are invited to join in to view and augment the results gathered in the Wiki from their interviews and additional sources. Experience has indicated that it may help in this phase if the data gathering phase has not been exceedingly careful in filtering contradictory or controversial arguments about the protocols. This is due to the fact that experts are often more keen to remove such flaws from existing data than to add complementary data to an empty page.
During these phases the data body is developed from a fairly generic and dry viewpoint towards exceedingly rich and specific use cases. Users immediately benefit from the practical domain experience included in the Wiki. 3.3
The ability to make logic deductions on the expert-supplied data can unearth results not
easily discovered by traditional means. As an example from the Wiki context, Decker
et al. uses reasoning to enable reuse of software engineering knowledge [
As an example case of inference on the domain of protocol dependency, the true
cause of a network error related to two hosts containing a plenitude of services can be
inferred from a data body on protocols and related implementations. Similarly, the gross
effect of a single vulnerability for a network can be assessed, optionally involving even
chains of vulnerabilities and exploits. Similar approaches have emerged in the context
of security research, particularly in network vulnerability assessment (e.g. [
Reasoning also has its limitations that have hindered its use in many cases. Main problem is the state space explosion resulting from massive knowledge bases. This can be countered by using monotonic logic and highly domain-specific data sets, although limits on query tree depth and traversal time can also be of help. All the statements made with Graphingwiki are essentially monotonic, as they only bring more data to the knowledge base without contradicting earlier statements. This is due to the inherent lack of meaning of the statements in the Wiki, as the different aspects and relations are only given meaning by humans interpreting them, or by the inference rules and queries.
While the statements are limited in their effect, there are no similar restrictions to
the inference rules queries. Thus, great care must be taken when generating them, as
they might bring contradiction or belief revision into the system. The heterogeneity of
the data gathered from various sources can present limitations to reasoning. As there
are no guarantees on given semantic data being present on all concerned pages, the
inference rules may not match all relevant data [
Semantic Wikis are a natural placeholder for various kinds of domain-specific data that are produced in normal course of work, enabling collaboration and groupwork. The gathering and visualisation of information was found straightforward with the methods explained in this paper. Visualising the relations of protocols has proved to be an effective method for realising the scope of a protocol in application and network contexts. The visualisations have been used in various stages of protocol-related vulnerability work.
It has been claimed that semantic tools also have applications in learning by
evaluating, manipulating, and presenting data in new ways [
OrgRoles/SalesRepresentative OrgRoles/FrontLineSupport OrgRoles/Purchaser OrgRoles/Assistant OrgRoles/Cof eeMaker
03 years
OrgRoles/CopyWriter OrgRoles/PublicRelationsOf icer
OrgRoles/ArtDirector OrgRoles/SalesManager OrgRoles/PreSalesEngineer
OrgRoles/Server-Developer OrgRoles/CustomerSupportEngineer
OrgRoles/Client-Developer OrgRoles/QA-Engineer OrgRoles/TechnicalWriter
OrgRoles/Trainer OrgRoles/TechnicalConsultant OrgRoles/SafetyOf icer
Figure 4 is a organisational chart of a company that has been created with Graphingwiki. The nodes of the graph represent the roles of different employees while edges report the reporting and management chains between the roles. The roles are ordered by their required experience and colored according to the departments they belong to. Similarly, Wiki pages containing data on employee responsibilities and fields of knowhow could enable efficient resource management and aid in problem resolution. Social network mapping techniques could be used on this data even further, for example to identify communities and communication bottlenecks.
Figure 5 represents a survey on the research on laser technologies and on the manufacturers of laser products. Data on different actors of the field was inserted to a Wiki, along with their relations. This view on the Wiki data depicts the Finnish laser product vendors by location, with links to the application areas of their products.
Graphingwiki could be enhanced in a variety of ways to increase its efficiency and expressiveness, and to make it more approachable for users. A full support for different levels of ontology formalisation would be an obvious benefit, along with mechanisms Spectroscopy DCA Epicrystals
Corelase
MedicalApplications Liekki
Communication LaserCooling
Modulight Toptica Application
Legend WeldingAndCutting
Surveying HeatTreatment
CoherentFinland
Cavitar HelsinkiRegion
International
Tampere
Turku
that check the page’s adherence to a specified ontology [
The creation of ontologies might be easier and more scalable if users could first use the augmented link syntax to denote all statements, shifting to use the MetaData-macro only when it has been ascertained that the values of the link tags do not have further structure and can be considered to be mere tag value data.
Some of the semantic data in a Wiki could also be automatically generated from
the knowledge of who created and modified the page, creation date, data on referring
page given by the browser, and so on [
The inference engine in the extension will yet require some work to be fully operational in a practical manner. A major part of this work includes creating the basic queries representing the common use cases of the inference engine. It also includes queries with additional functionality such as “find all of the links from the Wiki that point to non-existing pages”. Visualisating the results of the queries would increase their understandability in the case of complex queries.
Users could be greatly aided by the creation of semantic data macros specific to
their domains of knowledge. Further, the user interface could include tag word
suggestions to help converge the tagging scheme, similarly as in the del.icio.us service and
the Makna semantic Wiki. Another aid for the tagging scheme would be the use of
synonym-declaring relations. However, experiences from Wikipedia suggest that
problems regarding the selection of tags are not critical, and that the situation is further
ameliorated by the Wiki pages describing the tags [
The visualisation style and the GUI would benefit from user interaction studies and
research on other visualisation styles. Different dimensional views such as Zzstructures
and Polyarchies could be used to produce more data-compact views [
Many common use cases of Wikis, such as systems documentation and contracts, can encompass a smorgasbord of pages while placing great demands for the trustworthiness of the included data. As Wiki pages are by nature under constant revision and refinement, these use cases require facilities for specifying the page versions that constitute the de facto state of the entity. Visualisations that are bound to specific page revisions could be used to facilitate the version control of such entities while making their structure easier to apprehend.
Encapsulating the revision state in visualisations is a similar concept as the transition of software version control from the per file Revision Control System (RCS) into the set oriented Concurrent Versions System (CVS). Whereas in software development the module hierarchy facilitates easy revision tagging, in non-hierarchical Wikis the bound visualisations can provide for one click capture of a snapshot of a larger concept. Following the evolution of these visualisations could give insight into the development of the entity, and the processes involved. 5
This paper has shown how the MoinMoin Wiki can be extended to include some semantic capabilities. Graphingwiki uses the MoinMoin plugin mechanism along with its existing capabilities of linking and category pages to create a simple and lightweight semantic tagging scheme. The tagging scheme was further used to provide for the visualisation of semantic data and making reasoning upon it.
Graphingwiki has been used for knowledge engineering in the domain of network protocols. The visualisations have proven to be an effective aid in discovering dependencies between protocols, while the reasoning capabilities showed promise for uncovering complex relationships in the semantic data. The visualisations have been used in various stages of protocol-related vulnerability work.
Future research on Graphingwiki include analyses on the visualisation style and user interaction methods in the tool. This research could result in more compact and easily manageable views. Another future direction is the inclusion of more sopisticated semantic features, the lack of which currently limits the use of Graphingwiki with other semantic tools and data sources.
A great demand was noted for the management and visualisation of data from diverse domains. Usage of the tool was then attempted in a number of application areas. Initial experiences on the applicability of Graphinwiki for purposes outside its intended domain of application were very encouraging.
Therefore, a similar approach to handling, visualising, and inferring on data would probably be of much use in many other domains, including enterprise resource management and social network mapping. Organisational human resources related skill and social network mapping and documenting information systems from deployment level to strategy view with dimensions on security policy and system interdependencies are examples of envisioned use cases.