Several communities have engaged recently in assembling a Body of Knowledge (BOK) to organize the discipline knowledge for learning and sharing. BOK ideally represents the domain, contextualizes assets (e.g. literature), and exploits the Social Web potential to maintain and improve it. Semantic wikis are excellent tools to handle domain (ontological) representations, to relate items, and to enable collaboration. Unfortunately, creating a whole BOK (structure, content and relations) from scratch may fall prey to the “white page syndrome”1, given the size and complexity of the domain information. This article presents an approach to jump-start a BOK, by implementing it as a semantic wiki organized around a domain ontology. Domain representation (structure and content) are initialized by automatically creating wiki pages for each ontology concept and digital asset; the ontology itself is semi-automatically built using natural language processing (NLP) techniques. Contextualization is initialized by automatically linking concept- and asset-pages. The proposal's feasibility is shown with a prototype for a Software Architecture BOK, built from 1,000 articles indexed by a well-known scientific digital library and completed by volunteers. The proposed approach separates the issues of domain representation, resources contextualization, and social elaboration, allowing communities to try on alternate solutions for each issue.
In recent years, several professional and academic communities have undertaken to organize and systematize their knowledge with a “Body Of Knowledge” (BOK for short). BOK’s have been created most famously for project management 1 Colloquial name for writers’ mental block when starting a new piece from scratch (PMBOK 2 by the PMI 3) and for software engineering (SWEBOK 4 5), but also for IT architecture (ITABOK 6 by IASA 7 8 9 ), and other related disciplines.
Body-of-Knowledge (BOK) requirements typically include representing the domain, contextualizing resources (e.g. literature), and relying on Social Web members to maintain and improve it. Semantic wikis are excellent tools to handle domain (ontological) representations, to relate items, and to enable collaboration. Unfortunately, creating a whole BOK (structure, content and relations) from scratch may easily lead to the “white page syndrome”, given the size and complexity of the domain information.
This article presents an approach that differs from most current BOK’s in exploiting a formal discipline description to maintain the knowledge organization. It also presents several tools to automate the creation of a domain conceptualization (in concepts of a populated ontology), a semantic wiki to manage the domain representation and its assets, stylized wiki elements, and a timeline-based browser to explore the domain.
The reminder of the article is structured as follows: section 2 summarizes earlier related work; section 3 introduces the proposed approach for building a BOK; section 4 explains how the wiki structure, content and linking are initialized; section 5 describes the ConcepTion tools that implement the proposal; section 6 suggests some future work; 7 summarizes and concludes. 2
2.1
Several strands of work are directly related to this approach.
Semantic Wikis are designed to allow collaborative creation of content using a
fixed syntax and semantics to improve searching and querying. In traditional
wikis it is possible to find basic building blocks to create content (on most wikis
only a set of pages each one with a set of links). Semantic wikis provides an
expanded set of building blocks such as relations, entity types and RDF or OWL
annotations [
Pages/Library-of-PMI-Global-Standards.aspx 3 PMI - Project Management Institute: www.pmi.org/ 4 SWEBOK - Software Engineering Body of Knowledge: www.computer.org/portal/ web/swebok 5 ACM - Association for Computing Machinery: www.acm.org/ 6 ITABOK - IT Architect Body of Knowledge: www.iasahome.org/web/home/ skillset 7 IASA - International Association of Software Architects: www.iasahome.org/ 8 EABOK - Enterprise Architecture Body Of Knowledge: www.mitre.org/work/tech_ papers/tech_papers_04/04_0104/index.html 9 CBK - Common Body Of Knowledge: www.cissp.com/
Semantic Media Wiki [
The Kiwi wiki [
Angelo di Iorio et al. [
Jerome DL [
ScholOnto [
There is not a single, common structure for all BOK’s:
– The SWEBOK [
Clearly, there are alternative notions of what a BOK is and how it should be written. But some generalizations can be made: – A BOK is not just another textbook (an authoritative view by an individual or a committee); if so, it runs the risk of quickly becoming (or being born already) obsolete. – A BOK can be created from resource collections, but it is more than their sum; otherwise, an overall “big picture” does not emerge.
Although digital assets (e.g. papers, learning objects, Web sites...) are important, a BOK cannot be just a search engine for assets. 3
Building a body of knowledge (BOK) is expensive in human resources and time: it demands not only defining concepts and relations among them, but also requires a management system capable of support a whole community that will collaborate to create knowledge and enable inexperienced members of the community to understand the domain. To simplify and speed-up these requirements, we propose an ontology-based BOK which is semi-automatically populated from authoritative documents (such as articles). The BOK is enriched socially using the wiki, and is presented on a timeline to help better understand topics evolution in the community. 14 www.iasahome.org/web/home/skillset
There is a link between ontologies and BOK’s: an ontology is a knowledge representation in which concepts are organized in hierarchies and are related to each other through relations, and a BOK is also a knowledge organization in which a discipline is presented through definitions of concepts. (REFERENCIA A MAX VOLKEL). Both ontologies and BOK’s are knowledge organizations, their difference being for whom they are constructed: ontologies are intended to be machine-readable whereas BOK’s are intended to be used and understood by humans. It is not only a format difference that arises here (structured information v/s free text).
Our approach tries to balance the trade-off between representation accuracy
and usability of the organization [
From a very simplistic point of view, the more papers of a given domain a
researcher is able to read, the more understanding he will have of what is
happening with that domain. It should be possible to aid this process by automating
the analysis of publications, using basic Information Extraction [
The publication full body is not used for analysis since it would require a much more complex and expensive process for extracting information. Instead, we analyze publications’ metadata since simple, structured and also freely available on Internet from Web sites such as DBLP16, CiteSeer17 or ScienceDirect18. Mining digital assets metadata to extract Concepts The following excerpt is a typical Bibtex19entry provided by ScienceDirect20. @article{Kazman2005511, title = "From requirements negotiation to software architecture decisions", year = "2005", ... author = "Rick Kazman and Hoh Peter In and Hong-Mei Chen", keywords = "Requirements negotiation", "Architecture analysis",... abstract = "Architecture design and requirements..."}
Three main fields may contain information of the Software Architecture discipline: keywords, title and abstract. We use keywords as a primary data source, since it is the simplest information available (tags of no more than 3 words). The analysis is based on two properties of the keywords: – Keyword Frequency: If a keyword is present on several papers (that is, a keyword was used to tag several papers) that keyword represent an important Concept for the discipline that is being analyzed. – Co-occurrence: If a subset of keywords is present on several papers, all the keywords in the subset are likely to be related to each other.
We extended the analysis to the Abstract field, which contains a short text comprising the main ideas of the content of the document. This text was used as a search-base for the Keywords (processed with Named Entity Recognition 21).
This analysis yields a thesaurus with Concepts related to each other but with no hierarchy among them.
Creating a hierarchy of Concepts Given two Concepts related by co-occurrence analysis, we would like to know which Concept is broader and which one is narrower in the discipline, to add semantics to their relation. We proposed to identify and compare all digital assets associated to the Concepts. Table 1 shows two Concepts, each with an associated collection of digital assets. 19 Bibtex is a tool and file format to describe and process references - see www.bibtex.
org 20 ScienceDirect: www.sciencedirect.com 21 Named Entity Recognition is an Information Extraction technique used to identify entities on texts
Both Concepts co-occur on 4 different digital assets so we could say that they are related by co-occurrence. However, an 80% of the digital assets of the Concept #2 are contained on the set of concept #1, and only a 57% of the digital assets of concept #1 are in the concept #2 set (we call these percentages co-ocurrence factors). We can make the simple assumption that 80% of the literature of the concept Reusability is part of the literature of the concept Architecture Rationale and thus, Reusability represents something in the subdomain of Architecture Rationale. Since we cannot know what is this “something” that it represents we use a shallow relation stating only that Reusability is a narrower concept than Architecture Rationale (actually, Reusability of design rationale documents is a major goal of Architecture Rationale).
Applying this technique to every pair of co-occurrent concepts yields a hierarchy that emerges from the flat thesaurus built by mining the digital assets metadata. We can choose the minimal co-ocurrence factor to create the “narrower” relation between two concepts. We call this the co-ocurrence filter. Notice that a concept is not constrained to be narrower of only one concept (Reusability also is narrower than Non-functional requirement ).
backbone of the BOK. That means that it should be as complete as possible to cover all the main aspects of the discipline on research. Nevertheless, using only the keywords provided by the authors of papers yields some drawbacks: – Ambiguous Concepts: Authors often get too creative to tag their documents.
Ambiguity is a main problem of tagging as author s will tag using their own knowledge (different from shared knowledge) (architecture design, architectural design). – Too Generic Concepts: Some Concepts are too generic for the discipline and may not appear in the collection of Keywords since they do not represent a good tag for categorization. For instance, the word System is never used as a Keyword to tag a Software Architecture paper. – Too Specific Concepts: Many Keywords are too specific and do not add useful information that can be used on the BOK. For example, proper names, identificators, etc. These kind of Keywords add noise to the final ontology.
To overcome these issues, the initial dictionary of concepts to search on
abstracts is created over a thesaurus (we use a Software Architecture thesaurus
presented by Fraga et al.[
Too Specific Concepts need to be managed on a different way. We cannot just simply ignore all Keywords from papers’ metadata and use only those on the hand-made thesaurus because we would lose the capacity to discover information or new trends and topics. Specific concepts that cause noise are avoided by filtering them by the frequency they have. The idea is simple, the more specific a concept is, the less frequency it will have. Only concepts that appear in more than X papers will be used. We called X the frequency filter. 4
The configuration of a wiki for the identified metamodel implies creating two kinds of pages: those representing domain concepts, and those representing digital assets. Both kinds of pages make use of specialized Infoboxes, allowing a standardized visual representation of the (concept or asset) attributes. The relationship between assets and concepts is represented by inter-pages referencing. 4.1
The ontology is later used on a semantic wiki, where a single wiki page is created for each concept (a little program in java was used to do such labor). At this point is necessary to understand that the we are providing a jump-start approach for the SABOK, but of course, the definitions and contents of this knowledge representation remains in the hands of the Software Architecture Community. Of course, some information is provided on the semantic wiki for each concept: Broader Concepts, Narrower Concepts, Associated Digital Assets, and Topic Category. According to the properties of the concept, we have created specific types of topics.
The semantic wiki allows the community to create and maintain content collaborative, populating and enriching the SABOK; explaining such tools is out of the scope of this work. Searching concepts can be done either with the free-text searching tool provided by the wiki framework, or by browsing the thesaurus used to build the ontology. 4.2
Since each concept on the SABOK has several digital assets associated (the same used to build the ontology), it can be used as a digital asset search tool as well. The ontology behind the SABOK allow us to use inference on answering queries. We have identified two inference levels: basic, and based on concepts. Basic transitivity. Since the concepts are arranged on a hierarchy we can provide transitivity inference level for digital assets associated on a branch of concepts. For instance, all digital assets associated to Reusability will be answered to the query “digital assets for Architecture Rationale”.
As it can be seen, the SABOK besides from organizing the discipline knowledge, provides a searching capability of Digital Assets associated to each concept based on inference powered by its ontology.
The generated BOK can be browsed with a timeline-based tool, which shows the evolution of concepts and how they relate to each other. A timeline-based visualization tool can show which concepts concite attention currently. Crosscuting concepts can be visually identified because they have a constant participation in the timeline over the years. Users can access the community-created information of concepts and the wiki itself to edit and manage it.
The information that tool requires resides as year of publication in the digital assets information (see section 3.2). In the timeline, the concepts are presented with the dates of the first and (currently) last publication that use it.
The timeline can also be used to present Digital Assets evolution around a concept. This should be really useful for researchers looking for the last publications according certain subject, for example.
Finally, new Digital Assets can be added to the SABOK, such as lessons, presentations, posters, video, etc. 5
The proposed approach has been implemented in a system named ConcepTion 22, composed of three main tools: a Miner, a Hierarchizer, and a Visualizer.
The approach was validated with a case study for the Software Architecture domain. 5.1
Several efforts have been carried out to build a vocabulary for Software Architecture (SA). However, most of them are not intended to describe the entire Software Architecture discipline but systems and parts thereof (i.e. the discipline subject matter, not the discipline itself).
The SA community has recently focused on describing and recording
architecture knowledge (AK) that supports the architecting process (e.g. adopted and
discarded decisions, rationale, tradeoffs), and several metamodels and ontologies
has been proposed to systematize it (PAKME [
Unfortunately, only a couple of articles have proposed a broader
description of the entire software architecture discipline. Babu et al. [
Fraga et al. [
Although these two thesauri are good vocabularies to classify existing SA knowledge, there are several challenges that have not been already tackled in building a software architecture discipline vocabulary: – Both thesauri have been manually manipulated to better classify SA knowledge, so their hierarchies and relationships are usually very influenced by existing conceptual frameworks present in the discipline. This aspect certainly helps to create good thesauri for information search, but it usually hampers its ability to describe real connections among concepts. For example, they group “fault-tolerance”, “performance” and “usability” into a single category (“Quality Requirements” or “Non-Functional Requirements”), but in practice all three concepts are rarely present in the same article; indeed, most papers (and communities) focus on only one of them. Also, “fault-tolerance” is more frequently related to “validation” and “formal methods” than to any other quality requirement. – The starting corpus of these thesauri did not include published research or industry articles, either; they used back-of-the-book indices and/or SArelated Wikipedia pages. This corpus selection reduces the vocabulary scope to those topics already published in books, omitting new trending topics or novel techniques that might be being discussed in major refereed SA conferences or journals. For example, none of these thesauri mention “design rationale” or “software architecture rationale”, both dealt with in several recent mainstream articles. 5.2
The ontology was populated using 1,000 Bibtex files (including abstract) returned by ScienceDirect 24 for the “Software Architecture” search concept. Extracted metadata was stored in RDF 25. Table 2 shows some statistics generated by the Miner.
Over 10% of the articles do not have an abstract in their Bibtex file, so we can only rely on the keywords that the authors used to tag them. Interestingly, only 23 Wikipedia: www.wikipedia.org 24 ScienceDirect: www.sciencedirect.com 25 RDF: Resource Description Framework, the industry standard to store Semantic Information; see www.w3.org/RDF/. 47 tags account for more than the 50% of the matches produced by comparing searching dictionary concepts in abstracts. These are the most important and which we focused on. The Hierarchizer compares every pair of concepts and calculates a co-occurrence factor between them, (see section 3.2). We can lower the co-ocurrence filter to find more relations among concepts, but of course, the lower it is, the more false positives we will find. We have found empirically that a co-ocurrence filter of 80% is appropriate to discover new relations and maintain false positives on a low level.
The co-occurrence filter and frequency filter (see section 3.2) are the two parameters that can be used to adjust the quality of the hierarchy obtained, and thus, the ontology’s instances.
After creating the hierarchy, it can be visualizated with Graphviz26to draw the concepts and their relations, allowing Software Architecture experts to audit it and manually filter false-positives. Some samples of hierarchies can be found on Toeska’s Website27. The prototype SABOK was implemented using the semantic wiki platform Semantic Media Wiki 28 (SMW). A simple ad-hoc tool adds a wiki page for each concept in the hierarchy.
A timeline browser was also built with the MIT SIMILE Timeline29allowing to use HTML and JavaScript to use XML data, namely, a Knowledge Base with the ontology created.
Figure 1 shows a screenshot of the prototype SABOK. The evolution of the Concept Architecture is shown. Each line represents a narrower Concept displayed from the year of the first paper published with this Concept to the last paper. Figure 2 shows the wiki page for the Concept Reusability. Along with 26 www.graphviz.org/ 27 Toeska Research Group, Universidad T´ecnica Federico Santa Mar´ıa: www.toeska.cl 28 www.semantic-mediawiki.org 29 SIMILE Project: http://simile.mit.edu/timeline/ the information of broader concepts and narrower Concepts a Timeline of the publications using this Concept is provided. The Timeline is fully interactive and allow user to browse research papers. Figure 3 shows two infoboxes: Digital Asset and Concept. Digital Asset’s infobox displays useful information such as title, author and Concepts used on this paper. It also provides information of inferenced Concepts related to the paper. Concept’s infobox the upper and lower concepts in the hierarchy. It also displays inferred concepts and Digital Assets associated to the concept. 6
Along with adding more advanced NLP tools and adding more papers to the analysis to improve our hierarchy, we believe that there are two topics that could add a lot of value to the SABOK presented.
– Cluster Analysis: Through cluster analysis we can understand better which
are the areas the discipline is divided into. Also, it should be possible to
acknowledge some useful intersections of areas and define them as different
elements in the ontology to improve searching capability. We think that
using Formal Concept Analysis tools would allow us to find this clusters
of information by identifying classes of concepts as shown on PACTOLE
methodology [
Although we think the best validation for our SABOK should be made by the community, we are planning on making validation tests with Software Architects and Software Engineering students in the following months. 7
This article has presented a novel method to jump-start the creation of an ontology-based Body of Knowledge (BOK).
Using authorative documents from a community, we can mine and extract information about a discipline to hierarchize it and create an ontology. The ontology is used to organize the BOK and search Digital Assets (research publications in our example) using inference. The resulting BOK provides contextualization allowing document discovering and search inference.
The ConcepTion set of tools allows to extract, mine, hierarchize and display a BOK using a semantic wiki to manage information and a timeline tool to show evolution of topics in the discipline. The community is then asked to feed the BOK with definitions and their own Digital Assets. Future work will be focused on improving the quality of the resulting BOK and adding more features.