=Paper=
{{Paper
|id=Vol-464/paper-9
|storemode=property
|title=MoKi: the Modelling wiKi
|pdfUrl=https://ceur-ws.org/Vol-464/paper-01.pdf
|volume=Vol-464
|dblpUrl=https://dblp.org/rec/conf/semwiki/RospocherGPSL09
}}
==MoKi: the Modelling wiKi==
https://ceur-ws.org/Vol-464/paper-01.pdf
MoKi: the Modelling wiKi
Marco Rospocher1 , Chiara Ghidini1 , Viktoria Pammer2 , Luciano Serafini1 , and
Stefanie Lindstaedt3
1
FBK-irst, Via Sommarive 18, 38123 Trento Povo, Italy
2
Knowledge Management Institute, TU Graz. Inffeldgasse 21a, 8010 Graz, Austria
3
Know-Center, Inffeldgasse 21a, 8010 Graz, Austria.
Abstract. Enterprise modelling focuses on the construction of a struc-
tured description of relevant aspects of an enterprise, the so-called enter-
prise model. Within this contribution we describe a wiki-based tool for
enterprise modelling, called MoKi (Modelling wiKi). It specifically facili-
tates collaboration between actors with different expertise to develop an
enterprise model by using structural (formal) descriptions as well as more
informal and semi-formal descriptions of knowledge. It also supports the
integrated development of interrelated models covering different aspects
of an enterprise.
1 Introduction
An enterprise model is “a computational representation of the structure, activ-
ities, processes, information, resources, people, behavior, goals, and constraints
of a business, government, or other enterprise” [1]. Often, an enterprise model fo-
cuses in the description of two specific aspects of an enterprise: (i) its processes
and activities, and / or (ii) the business domain within which the enterprise
operates. Other aspects of an enterprise, like goals, human resources, organisa-
tional structure and roles, competencies, etc. may also be important assets to
be described in an enterprise model. This is due to the central role that enter-
prise models are playing in the development of a large number of applications,
including Internet and (Semantic) Web based applications.
Building an enterprise model requires a number of skills. These skills span
from knowing the different aspects that have to be described in the models
to having the ability of encoding such knowledge into formal statements, to
having the ability of integrating different aspects, such as structure, activities,
processes, information, resources, people, behaviour, goals, and constraints into
a uniform and coherent vision. Given the complexity of enterprise modelling,
it is unrealistic to assume that any one person possesses all the above skills,
and the contribution of multiple actors is necessary. For this reason enterprise
modelling is inherently a collaborative activity. Our research focuses mainly on
collaboration between actors with different skills. Naturally we also recognise
the relevancy of other aspects of collaboration such as resolution of conflicts of
opinion or interest (considered for example in Collaborative Protégé [2]), or more
fundamental requirements regarding access rights, simultaneous modification of
models, versioning etc., but we plan to consider them at a later stage of our
work.
To support actors with different skills, we envisage a system in which con-
tent can be represented at different degrees of formality. Domain experts need to
create, review and modify models at a rather informal/human intelligible level.
Knowledge engineers need to check the quality of the formal definitions and their
correspondence with the informal parts they intend to represent. In order not
to increase the overhead of human work, translation between different levels of
formality must be as automated as possible. To support a coherent development
and integration of the different components of the enterprise model, such a mod-
elling tool must support the modelling of all the relevant aspects of an enterprise
in a collaborative, cooperative and integrated manner. This is in order to exploit
the synergy of “having to think the same thing out only once”.
MoKi (Modelling WiKi) is developed in order to meet this vision:
1. It supports access to the enterprise model at different levels of formality
(informal, semi-formal, and formal);
2. It integrates modelling of several aspects of an enterprise; and
3. It ensures a coherent development of the formal part.
2 Conceptual framework
The key modelling aspects that MoKi aims to support are collaboration and
integration. This section goes into detail about how we understand these terms
and why they are relevant in the context of enterprise modelling.
2.1 Collaboration
Developing an enterprise model is inherently a collaborative activity, since a
variety of skills are required which are unlikely to be found in a single person, as
has already been argued above. In practice, different actors have very different
expertise in encoding content into formal languages, or may know only of specific
aspects of an enterprise. At this point it is necessary to understand that as a
direct consequence different contributors, as members of a modelling team, also
have different requirements on the modelling environment, especially with regard
to the presentation of the models’ content. The primary goal of our research with
respect to collaboration is to derive requirements on a modeling environment by
actors with different background knowledge and to develop appropriate ways to
access models accordingly.
To support collaboration between the modelling team, and to allow great
flexibility in the cooperative modelling activity, we therefore adopt a collabo-
rative modelling paradigm, illustrated in Figure 1. This paradigm is inspired
by recent Web 2.0 collaborative solutions, of which wikis are one example, and
was already proposed in [3, 4] as a way to support modelling activities. In this
paradigm all the actors asynchronously collaborate toward the creation of an
Fig. 1. Collaborative Modelling
integrated enterprise model by inserting knowledge (either formal or informal),
by transforming knowledge (from informal to formal) and by revising knowledge.
The domain experts enter the missing knowledge - using a form of informal lan-
guage - into the models or provide feedback on the formal models created. The
system semi-automatically translates part of the informal knowledge into a for-
mal specification and vice-versa. Asynchronously, the knowledge engineers can
refine the formal model by inserting new elements, by modifying existing knowl-
edge or by asking clarifications to the domain experts. The usage of a robust
collaborative technology, as the one provided by the wiki, allows the provision of
state of the art functionality like simultaneous access and online communication
via the platform.
Another important characteristic of our approach lies in the capability of the
system to maintain the alignment between the informal specification of the en-
terprise model and its formal version. This can provide an added extra value, as
the documentation contained in the informal part is often critical to fully under-
stand its formal version. Traditionally, the main goal of enterprise modelling is
the production of an integrated formal model in which the different aspects of an
enterprise are integrated in a unique model. This integrated formal model is an
artefact that nevertheless requires a strong connection with its informal part in
order to be fully exploited both by humans and machines. Thus, to support the
exploitation of an enterprise model also by humans we adopt a structure (also
referred as the meta-model ) which not only contains the formal meta-model of
the enterprise, but also the informal versions of this knowledge.
2.2 Integration
Relevant to our idea of modelling different aspects of one enterprise is that the
various models are interconnected, and thus constitute an integrated model.
In the current implementation of MoKi, we focus on an enterprise model describ-
ing the domain, the processes and the competencies of an enterprise; Figure 2
shows the current version of the integrated enterprise meta-model considered.
The choice of these aspects, which constitute typical parts of an enterprise model,
Fig. 2. The current version of the integrated enterprise meta-model considered in MoKi
was originally motivated by the EU-project APOSDLE4 in which MoKi was first
developed and used. Nonetheless, MoKi has also been used in different contexts
already (see Section 4). Also, more complex enterprise models can be consid-
ered, and we have designed our approach with the explicit intent to be open and
extendable to other aspects of an enterprise.
Below, we specify what we mean by domain, process and competency model,
and illustrate how we see integrated modelling using these spcific aspects.
The domain model provides the description of the business domain within which
the enterprise operates. It is a conceptualisation of the entities and the relations
between them, which are relevant to the activities of an enterprise. This de-
scription is provided in terms of concepts, relations and objects. Following the
growing popularity of Semantic Web technologies, we decided to base our rep-
resentation of a domain-specific model upon the OWL ontology language5 . This
approach allows one to express classes, properties, instances, and axioms among
them.
The process model provides a description of the patterns and procedures occur-
ring in a business domain of an organisation. The very core of a process model
is a control flow. In the e-learning application scenario described in [3] it was
enough to consider a task to be either atomic or composed of a bag of subtasks,
regardless of any execution control. In this case a simple hierarchical structure
representing the task/sub-task relation was sufficient and we adopted an OWL
ontology that encodes the part-of relation. In a different situation where tasks
were complex structures described in the BPMN6 language [5], a more complex
model was adopted, in which processes are described by means of the primitives
4
See www.aposdle.org.
5
www.w3.org/TR/owlfeatures/
6
Business Process Modelling Notation www.bpmn.org
defined in an OWL ontology that represents BPMN7 .
The competency model describes the attitudes and the capability of people em-
ployed in an organisation to fulfill their tasks and to reach their objectives
and goals. Elements of the competency model are competencies, which express
knowledge about domain concepts. Tasks are related to competencies, in that
a competency may be required to perform a task, and vice versa the (success-
ful) execution of a task indicates that person possesses a certain competency.
Such a competency model allows describing users in terms of knowledge about
concepts of the business domain and skills to perform the tasks of the process
model. Clearly, such a competency model serves as connection between domain
and process model. Practically, this connection is established by assigning tasks
to competencies (domain model element plus skill type) which are required for
performing the task. In the e-learning application scenario described in [3], the
competency model was built focusing on the support of individual learning in
the process of working tasks [6].
3 Enterprise modelling using MoKi
MoKi is based on Semantic MediaWiki (SMW) [7], extending it to offer partic-
ular support for enterprise modelling. Based on a predefined meta-model as the
one described above, MoKi adds to SMW the following groups of functionali-
ties: (i) import functionalities to load existing models from various formats, (iii)
modeling functionalities for model management and representation (iii) export
functionalities to translate models developed within MoKi into standard formats.
These functionalities are described in more details throughout this section.
The choice of developing MoKi on top of a semantic wiki was made for sev-
eral reasons. Wikis provide a state of the art robust collaborative tool, which
enabled us to focus on the aspect of collaboration between actors of different
skills and still getting an environment with more broad collaboration support.
Due to the growing popularity of wiki-based web sites (e.g. wikipedia), users are
quite familiar with wikis and the editing of wiki pages. Furthermore, the SMW
framework already provides many important functionalities such as access con-
trol and permissions, tracing of the activity, semantic search, and so on, without
the need to install specific client applications. Finally, only a web-browser is
required on the end user side to use the system. The second important reason
for choosing a semantic wiki was the fact that the wiki can provide a uniform
tool and interface for the (informal) specification of the different components of
an enterprise model (domain, processes, and competencies in our case). This is
in opposition to the usual procedure, where dedicated but often disconnected,
modelling tools are used to model each aspect. The usage of a uniform tool for
the integrated modelling of different aspects of an enterprise provides a great
opportunity to make modelling easier for domain experts. It is also a prerequi-
site for modelling different aspects of an enterprise in a truly integrated way, as
described above. As a final reason for implementing MoKi on top of a semantic
7
http://dkm.fbk.eu/index.php/BPMN Ontology
wiki, the natural language descriptions inserted in a semantic wiki can be struc-
tured according to predefined templates, with the help of semantic constructs
like properties. As a consequence, the informal descriptions in natural language
contain enough structure to be automatically translated in formal models, thus
allowing the reuse of informal descriptions for automatic ontology creation.
3.1 Describing knowledge in a MoKi page
MoKi integrates different views over portions of knowledge. The main idea behind
MoKi is to associate a wiki page8 to each (simple or complex) element of the
formal models so that this page contains an informal but structured description
of the element itself. The typical page contains9 :
– An informal description of the element in natural language (images or draw-
ings can be attached as well). The purpose of this part is to document the
model and clarify it to users not trained in the formal representation (e.g.,
reference to source documents, notes about modelling choices and open prob-
lems, etc.). Comments can be added by each user and are not translated to
the formal model;
– A structured part, where the element is described by means of triples of the
form (subject, relation, object), with the element itself playing the role of
the subject. The purpose of this part is to represent the connection between
elements of the same model (like class/sub-class relation between elements of
the domain model, or task/sub-task relation between elements of the process
model) as well as connections between elements of different models (like a
relation denoting required knowledge between elements of the process and
the domain model).
This natural language based, but also structured, description provides a nat-
ural bridge between formal and informal representation of knowledge. The user
fills a page via forms (see the Semantic Forms extension10 ), so he/she does not
need to know any particular syntax or language to participate in the creation of
the enterprise model. All the actors involved in the modelling activities can also
interact with each others and exchange further ideas and comments using the
discussion SMW’s built-it functionality. An example of a MoKi page describing
an element of the domain model is shown in Figure 3 while an example of a MoKi
page describing an element (task) of the process model is shown in Figure 4.
8
Wiki categories could have been used as well to represents the concepts of the domain
model. However, when we started developing the tool, the support for categories in
SMW was rather preliminary, so we decided to represent domain concepts using
standard pages.
9
Note that in this section we use the term “model element” to indicate a basic com-
ponent of the model. For instance, a concept or a relation of the domain model is a
model element, a task of the process model, a competency, and so on.
10
http://www.mediawiki.org/wiki/Extension:Semantic Forms
The important point to stress here is the usage of semantic forms to realise
appropriate templates to guide domain experts in providing their informal, but
structured descriptions. Templates are the key to customise MoKi for modelling
different kinds of model elements (e.g. domain concept, task, competency etc.)
with respect to which knowledge shall be specified about the kind of element.
3.2 MoKi functionalities
MoKi provides several groups of functionalities to support modelling, all of which
can be accessed via a wiki’s style menu. This section contains a description of
the functionalities currently available11 . Concerning future extensions, MoKi is
built in a modular way in order to facilitate the plugging-in of new or existing
state-of-the-art tools.
Import Functionalities. We provide three types of import functionalities:
– Import of available domain/task formal models. With this functionality the
user can set up MoKi with an already available domain or task model instead
of starting modelling from scratch. From the technical point of view, the
XML serialisation of the OWL formal model is parsed in order to obtain its
relevant elements, and a page is created for each one of them. All pages are
collected in a XML file, which then is given as input to the Import pages
functionality available in SMW.
– Input of structured lists of elements. With this functionality the user can
create new elements of the models by inserting lists of concepts (resp. tasks),
organized according to predefined semantic structures, e.g. a taxonomy or
a partonomy (resp. task/subtask decomposition structure). Figure 5 shows
the loading of a list of concepts organized according to a partonomy in the
domain model. Also this functionality takes advantage of the Import pages
functionality available in SMW.
– Text analysis functionalities. To support the utilization of available unstruc-
tured knowledge relevant for the modelling activity, MoKi includes an ex-
tension which allows to extract relevant terms from digital resources, and
to cluster such terms according to their relatedness. These functionalities
are provided by the KnowMiner, an advanced text analysis tool developed
by the Know-Center. The corresponding extension works in analogy to the
extensions realised for Protégé in earlier work [8].
Model Management Functionalities. This set of functionalities provides the
basic functionality each modelling tool necessarily provides: Creating, editing
and deleting model elements. Depending on the type of element, pre-defined
templates are loaded when it is created or edited. Such templates contain for
11
A demo version of MoKi can be tried out on-line at the MoKi web site: moki.fbk.eu. A
detailed description of the current version of MoKi is contained in the MoKi manual,
available at the same web site.
Fig. 3. An example of a MoKi page for a concept.
Fig. 4. An example of a MoKi page for a task
Fig. 5. Adding a list of concepts organised according to a part of hierarchy, via the
Load list of concepts functionality.
instance properties for specifying a taxonomy or partonomy, or a sequence in
the case of tasks.
Visualization Functionalities. These functionalities allow to produce differ-
ent types of graphical overviews of the models: they help the actors to deal with
the global picture on the models and not only with the single model elements. In
particular, the tool allows two kinds of overviews of the model, a tabular-based
one and a graphical-based one.
In the tabular-based view, the user sees a table listing all the elements of the
domain model or the process model, where for each element some relevant infor-
mation is shown, e.g. its description, the concepts of which it is a specialisation
(for domain elements), its subtasks (for tasks), and more. A short extract of a
list of element in a domain model is shown in Figure 6. This functionality is
based on the ask query mechanism available in SMW.
In the tree-based view, called IsA/PartOf Browser, a tree-like view shows
the hierarchy of the domain elements according to either the subclass or part
of relation. This tree-like view, which can be see in Figure 7, is dynamically
created from the content of the MoKi pages. The user has the possibility to
expand/collapse only parts of the tree, thus allowing him or her to efficiently
browse even large and complex models. Actually, this is not just a visualization,
since the user can easily rearrange via drag ’n’ drop the taxonomy and partonomy
of concepts in the domain model, and the changes performed within the browser
are propagated to the pages describing the elements involved. This functionality
is an adaptation of the DHTMLx-Tree library 12 , originally not meant for this
purpose.
12
http://www.dhtmlx.com/docs/products/dhtmlxTree/index.shtml
Fig. 6. Extract of a tabular-based view of the domain model.
Export Functionalities. These functionalities support the automatic export
of knowledge of the enterprise model into standard knowledge representation lan-
guages. At the moment, the formal representation of all parts of the enterprise
model is an OWL ontology. On-going work is devoted to the addition of other for-
mal languages especially for task/process specification. The process model and
the domain model can be exported separately. Technically speaking, the starting
point to the automatically created the OWL ontology from the informal domain
model is the built-in Semantic MediaWiki Export pages to RDF functionality.
Using this functionality, it is possible to generate a document in OWL/RDF
format containing information on the properties used in the pages describing
the model. However, since this functionality has been developed independently
with respect to the use of the Semantic MediaWiki that we propose, an auto-
mated postprocessing of this file is necessary in order to be able to generate
an OWL ontology consistent with the informal model designed. For example,
a page describing a domain concept is mapped by the Export pages to RDF
functionality to an instance of a top class smw:Thing, while in our approach it
should be mapped to an OWL class. Similarly, the “is a” relation is mapped
by the Export pages to RDF functionality to an object property named is a,
while in our approach this relation needs to be mapped to the RDFS subClassOf
Fig. 7. The taxonomy of the concepts in a domain model shown via the IsA browser.
Note the Save Tree button, which allows to save the class/subclass hierarchy after
changes made via drag ’n’ drop.
relation.
Reviewing MoKi against the claims made in the beginning of the paper, it:
1. Supports access to the enterprise model at different levels of formality (in-
formal, semi-formal and formal) in that it (i) accommodates highly informal
modelling based merely on hyperlink connected wiki pages as well as (ii)
semi-formal modelling where pages and links are raised to a semantic level,
and (ii) enables formal modelling by an easily accessible translation into
formal models via an export functionality.
2. Supports integrated modelling of domain, processes and competences within
an enterprise by providing one homogeneous interface for modelling all rel-
evant aspects of an enterprise, and enabling knowledge engineers to inter-
connect models describing these aspects in a quite natural way.
3. Ensures a coherent development of the formal part by providing an import
functionality which allows a re-translation of formal models into MoKi.
4 Use Cases and User Study
The MoKi has been successfully applied within the EU-project APOSDLE to
develop enterprise models in six different domains: Information and Consulting
on Industrial Property Rights, Electromagnetism Simulation, Innovation and
Knowledge Management, Requirements Engineering (the RESCUE methodol-
ogy), Statistical Data Analysis and Information Technology Infrastructure Li-
brary. Some of the experiences of an early usage of the system are described
in [3]. In addition, MoKi is used in applications that go beyond typical enter-
prise modelling: the representation of medical guidelines encoded in the ASBRU
language13 , and the collection of data for the Personal Health Record of the
Province of Trento, Italy14 . The work done in these projects, as well as the anal-
ysis of the usage of MoKi in APOSDLE constitutes an important step towards
the improvement of the tool and realisation of the full framework.
User study A qualitative evaluation based on the usage of the MoKi between
September 2008 and January 2009 by four application partners modeling five
different enterprise domains in the scope of the APOSDLE project was carried
out. The evaluation took the form of structured interviews with both open and
closed questions. Interview questions targeted not only MoKi but the whole mod-
eling process implemented in APOSDLE [10]. Modeling activities in APOSDLE
involved domain experts, on-site knowledge engineers as well as external knowl-
edge engineers. the interviews were carried out with the on-site and external
knowledge engineers but not directly with the domain experts.
All participants reported a positive experience of MoKi. In particular, the import
(easy integration of previously available knowledge) and export functionalities
(translation into formal models) were highly appreciated. Also, the homogenous
modeling environment for modeling different aspects (domain, task, preliminary
competency model) was found to facilitate the process. Furthermore, the par-
ticipants reported that MoKi did facilitate collaboration among the modelling
team.
5 Related Work
Solutions to the problem of modelling various aspects of an enterprise were
proposed in several works, both in terms of definition of the meta-model and in
terms of methodologies to support the creation of the model itself: a detailed
comparison between state of the art approaches and the one proposed in this
paper can be found in [4].
Many tools are available to support the creation of formal models in general.
Most of them, e.g. Protégé [11], were born as standalone desktop applications.
Despite the development of pug-ins that support collaborative features (e.g.,
Collaborative Protégé ) the tools remain barely usable by users with limited ex-
pertise of formal languages. The MoKi does not directly compare to such tools,
since it is not a modelling tool for a specific formalism but rather for specific
kinds of entities (concepts, tasks etc.). The support for concrete formalisms lies
in the implementation of different export functionalities. Additionally of course,
13
Part of the OncoCure project. See [9].
14
Part of the TreC project. See trec.fbk.eu
MoKi aims to collect information about these entities at different levels of for-
mality. Recently, wiki systems, and semantic wikis, have been applied to support
collaborative knowledge creation and sharing. We mention a few of them, and
assume for all that they offer “traditional” wiki functionality, i.e. web-based,
easy text edition and linking to web resources, integration of multimedia con-
tent and versioning.
There is already at least one proposal in which the modelling of processes is
done using the pure Semantic MediaWiki, see Dengler et al [12]. Semantic
MediaWiki+ (SMW+) [13] is a further extension on Semantic MediaWiki with a
focus on enhanced usability for semantic features. Especially, it supports besides
the annotation of whole pages also the annotation of parts of text and offers ad-
ditional funtionalities termed “knowledge gardening” functionalities. The latter
are maintenance scripts at the semantic level, with the aim to detect inconsistent
annotations, near-duplicate entries etc.
IkeWiki [14] and OntoWiki [15] are two more semantic wikis, both however
are completely independent from pre-existing wiki systems. Java-based IkiWiki
supports the semantic annotation of pages and links between pages with seman-
tic. Annotations are used for context-specific presentation of pages, advanced
querying, consistency verification or drawing conclusions. IkeWiki also directly
supports reasoning on its knowledge base. Continued development of IkeWiki
now takes place within the EU-project KIWI [16]. OntoWiki seems to focus
slightly more directly on the creation of a semantic knowledge base, and offers
widgets to edit/author not only single elements/pages but also whole statements
(subject, predicate, object).
AceWiki [17] was developed in the context of logic verbalisation, and is based on
research to verbalise formal logic statements, and inversely translate backwards
English statements into formal logic. AceWiki is based on Attempto Controlled
English - ACE, which allows users expressing their knowledge in near natural
language (i.e. natural language with some restrictions). Note that although such
content may look like natural language, in contrast to the informal fields in MoKi
for instance, it is actually formalised, i.e. follows some rules. In contrast to this,
the content of the informal parts in MoKi, e.g. the descriptions of the model
elements, is completely unrestricted.
myOntology [18] is geared towards the collaborative and community-driven de-
velopment and maintenance of lightweight ontologies. In particularit has been
applied within the context of E-Commerce.
What MoKi offers in addition are two main contributions:
– The support for the integrated specification of multiple aspects (in the use
cases described above, this meant domain, process and competencies).
– The bi-directional transformation between formal and informal models.
6 Conclusions
In this paper we have presented MoKi, a new tool for collaborative enterprise
modelling. The general framework and the tool we envisage constitute a gen-
uine contribution towards supporting a fruitful collaboration among people with
different skills and levels of expertise in the modelling activities. The current
implementation of MoKi, developed inside the APOSDLE EU-project already
provides key functionalities towards the modelling of an integrated enterprise
model in a collaborative manner, and constitutes a first version towards the
realisation of the full framework.
Future work focus on improving the tool and make it more general. Exam-
ples of future work include: a better support for domain and process modelling,
including better support to the modelling of all the elements of the formal mod-
els; the integration of the competency model in the MoKi15 ; better support to
define templates and to adapt to different meta-models; support for validation
of knowledge in the MoKi by means of the domain experts.
Acknowledgements We thank all the people involved in the modelling activities
of the APOSDLE project for their useful suggestions and feedback. This work
has been partially funded under grant 027023 in the IST work programme of the
European Community (APOSDLE IST-project). The Know-Center is funded
within the Austrian COMET Program - Competence Centers for Excellent Tech-
nologies - under the auspices of the Austrian Ministry of Transport, Innovation
and Technology, the Austrian Ministry of Economics and Labor and by the State
of Styria. COMET is managed by the Austrian Research Promotion Agency FFG
References
1. Fox, M.S., Grüninger, M.: Enterprise modeling. AI Magazine 19(3) (1998) 109–121
2. Tudorache, T., Noy, N.F., Musen, M.A.: Collaborative protege: Enabling
community-based authoring of ontologies. In: International Semantic Web Confer-
ence (Posters & Demos). (2008)
3. Christl, C., Ghidini, C., Guss, J., Pammer, V., Rospocher, M., Lindstaedt, S.,
Scheir, P., Serafini, L.: Deploying semantic web technologies for work integrated
learning in industry. a comparison: Sme vs. large sized company. In: Proceedings of
the 7th Int. Semantic Web Conference (ISWC 2008), In Use Track. Volume 5318.,
Springer (2008) 709–722
4. Rospocher, M., Ghidini, C., Serafini, L., Kump, B., Pammer, V., Lindstaedt, S.N.,
Faatz, A., Ley, T.: Collaborative enterprise integrated modelling. In Gangemi, A.,
Keizer, J., Presutti, V., Stoermer, H., eds.: SWAP. Volume 426 of CEUR Workshop
Proceedings., CEUR-WS.org (2008)
5. Di Francescomarino, C., Ghidini, C., Rospocher, M., Serafini, L., Tonella, P.: Rea-
soning on semantically annotated processes. In: Proceedings of the 6th Interna-
tional Conference on Service Oriented Computing (ICSOC’08), Sydney, Australia
(2008)
15
The creation of the competency model was initially envisaged and performed in
APOSDLE via the TAsk-Competency Tool (TACT) [10], developed by the Know
Center outside the MoKi. On-going work is focused on incorporating and extending
the functionalities of TACT in the MoKi to fully support the modelling of domain,
processes and competencies in an integrated manner.
6. Lindstaedt, S.N., Ley, T., Scheir, P., Ulbrich, A.: Applying Scruffy Methods to
Enable Work-integrated Learning. Upgrade (2008) in press
7. Krotzsch, M., Vrandecic, D., Volkel, M.: Wikipedia and the semantic web - the
missing links. In: Proc. of the 1st Int. Wikimedia Conference (Wikimania 2005)
8. Pammer, V., Scheir, P., Lindstaedt, S.: Two protégé plug-ins for supporting
document-based ontology engineering and ontological annotation at document-
level. In: 10th International Protégé Conference, Budapest, Hungary, July 15-18,
2007
9. Eccher, C., Ferro, A., Seyfang, A., Rospocher, M., Miksch, S.: Modeling clinical
protocols using semantic MediaWiki: the case of the Oncocure project. In: ECAI
workshop on Knowledge Management for Healthcare Processes (K4HelP). (2008)
10. APOSDLE Deliverable 1.6: Integrated modelling methodology version 2 (forth-
coming in April 2009)
11. Protégé: The protégé project (2000) http://protege.stanford.edu.
12. Dengler, F., Lamparter, S., Hefke, M., Abecker, A.: Collaborative process de-
velopment using semantic mediawiki. In: Proceedings of the 5th Conference of
Professional Knowledge Management. Solothurn, Switzerland, March 2009.
13. Semantic MediaWiki+: Business ready semantic collaboration (2008)
http://wiki.ontoprise.de/ontoprisewiki/index.php/Main Page.
14. Schaffert, S.: Ikewiki: A semantic wiki for collaborative knowledge management. In:
1st Int. Ws. on Semantic Technologies in Collaborative Applications (STICA’06)
15. Auer, S., Dietzold, S., Riechert, T.: Ontowiki - a tool for social, semantic collab-
oration. In: Proceedings of the 5th International Semantic Web Conference, Nov
5th-9th, Athens, GA, USA. Volume 4273., Springer (2006) 736–749
16. The KiWi Vision: Collaborative knowledge management, powered by the se-
mantic web. (2008) Deliverable 8.5 - http://wiki.kiwi-project.eu/multimedia/kiwi-
pub:KiWi D8.5 final.pdf.
17. Kuhn, T.: AceWiki: A Natural and Expressive Semantic Wiki. In: Proceedings of
Semantic Web User Interaction at CHI 2008: Exploring HCI Challenges. (2008)
18. myOntology: Open ontology environment for semantic web-based e-commerce.
(2008) http://www.myontology.org/.