Architecture of a Collaborative Business Intelligence Environment
based on an Ontology Repository and Distributed Data Services
Valério Aymoré Martins, João Paulo C. Lustosa da Costa and Rafael Timóteo de Sousa Júnior
Department of Electrical Engineering, University of Brasília – UnB, Brasília, Brazil
Keywords: Collaborative Business Intelligence, Centralized Ontology, Data Services.
Abstract: Business Intelligence (BI) refers to a set of methodologies, methods, tools and software that are used in
order to provide system solutions to support information analysis. The specifications and development of
these system solutions are still limited to specific domain tables. Furthermore, in conventional BI solutions,
it is necessary to promote massive data loads provided by other organizations in local repositories. Such
massive loads can make the information not available on-time or cause errors due to misinterpreting
received data. In this paper, we propose a systemic architecture that seeks solutions to these limitations. The
architecture is based on a centralized ontology repository and uses distributed data services to provide data
to generic analytical queries.
1 INTRODUCTION
While Business Intelligence environments in general
are focused on semantic models about specific
information domains and/or organizations, the
Semantic Web seeks to organize public knowledge
in a single semantic model that goes beyond these
domain and organization boundaries.
In this context, the concept of BI 2.0 has
emerged (Nelson, 2010) and brings a new
perspective for its use on the Internet. The BI 2.0
combines the traditional BI together with features
offered by Web 2.0 and supported by new Web
technologies (Galatis and Tsekeridou, 2011).
This perspective is observed in Böhringer et al.
(2010), which describes that, in the future, BI will
support the use of: Collaboration to provide
information (BI Crowdsourcing); Ontologies as a
knowledge representation technique (Ontology-
based BI); shared resources from decentralized BI
systems (BI decentralization); and BI provided in
cloud computing environments (Cloud BI).
To address these challenges, based on the
concepts introduced by Berthold et al. (2010), we
propose to establish a collaborative model composed
of two integrated layers to handle BI environments.
In Berthold at al., (2010), these layers are named
Infospace (information space) and Dataspace (data
space).
Inspired in this two layer model, in this paper we
propose a Business Intelligence (BI) architecture
that follows the paradigm of Dataspace and
Infospace so as to improve the structure of
conventional BI applications.
By employing Ontologies in our proposed
architecture, a crowdsourcing ontology-based
environment for Infospace can be created. At the
same time, the use of Data Services can provide a
decentralized Dataspace that can be supported by
Cloud environments. With such environment,
several partners and/or organizations can build
information communities with minimum efforts.
To support the development of our proposed
architecture, we describe the main features that can
be selected and adapted from existing solutions in
order to build an integrated environment. Then, we
discuss our contribution, presenting the architectural
model, its components and the related application
integration process.
Finally, we discuss the application of our
proposed ontology repository to integrate different
BI systems. For instance, we can integrate the BI
system of the Federal Patrimony Department
(Fernandes et al., 2012) to BI systems of other
departments and ministries in Brazil.
The remaining of this paper is organized as
follow: in Section 2, we present an overview of BI
concepts. In Section 3, it is shown the state of the art
in the domains of business intelligence, ontologies
99
Aymoré Martins V., C. Lustosa da Costa J. and de Sousa Júnior R..
Architecture of a Collaborative Business Intelligence Environment based on an Ontology Repository and Distributed Data Services.
DOI: 10.5220/0004107000990106
In Proceedings of the International Conference on Knowledge Management and Information Sharing (KMIS-2012), pages 99-106
ISBN: 978-989-8565-31-0
Copyright
c
2012 SCITEPRESS (Science and Technology Publications, Lda.)
and data services. In Section 4, we propose our
architecture and its application. In Section 5 the
conclusions are drawn.
2 BASIC CONCEPTS ON
BUSINESS INTELLIGENCE
2.1 Structure of Traditional BI
Environments
Existing BI solutions offer features that deliver
results in different presentation styles and
summarizations according to the user requirements.
We highlight one of these features: the On-Line
Analytical Processing (OLAP).
According to Chaudhuri and Dayal (1997),
OLAP is a generic and convenient mechanism that
allows data navigation through a multidimensional
structure which performs information research and
controls the way that information is presented.
To understand the use of OLAP, it is necessary
to analyze the role of various elements existing
within client-server architectures of a conventional
BI environment. According to Davenport et al.,
(2007) and BI solution providers such as IBM
(2004) and Microsoft (2006), there are five basic
levels recognized in these architectures. These five
levels are listed in Table 1.
Table 1: Layers of a conventional BI environment
(Davenport et al., 2007); (IBM, 2004); (Microsoft, 2006).
# Davenport Microsoft/IBM Primary Functions
1
Data
Management
Data Sources
Management of data
sources
2 Transformation
Data Integration
Extraction, clean and
load (ETL).
3 Repository
Data Storage
Storage of data and
metadata
4 Application
Data Analysis
Treatment of analytical
data
5 Presentation
Data Presentation
Data manipulation and
presentation
The first three layers in Table 1, related to the
first three columns in Figure 1, Data Management,
Transformation and Repository, are used in the
construction cycle of conventional BI architectures.
For instance, data from Data Management are used
in a process called extraction, transformation and
load (ETL) defined in Transformation.
The ETL loads the generated data and
information into data models within the Repository
layer. These data models are distinguished structures
known as multidimensional models, implemented as
physical or logical tables that hold both the
aggregation of concepts and the metrics that link
information and data.
Figure 1: Conventional BI environment (Chaudhuri et al.,
2011).
The fourth and fifth layers presented in Table 1,
Application and Presentation, respectively the
fourth and fifth columns of Figure 1, are executed
during the usage cycle of conventional BI solutions.
Regarding the fourth and fifth columns in
Figure 1, our particular interest is in the OLAP
server in the role of middle-tier and the ad hoc query
client that is the application front-end. Both are
circled in Figure 1. These components cooperate via
request and response protocols. In the usage cycle,
the OLAP server directly accesses pre-defined
multidimensional models, and the Repository layer
reads data in order to build ad hoc information.
2.2 Multidimensional Models
The multidimensional modeling represents the main
technique to meet the needs required in conventional
BI environments.
Informational concepts are generally categorized
using structured trees within multidimensional
models. These trees organize the concepts from their
genus, down to their species, a representation of a
knowledge called taxonomy (Guarino, 1996).
However, the taxonomy of concepts is an
oversimplified representation with known
limitations regarding the need to organize different
levels of granularities from various information
domains.
Regarding the process of representing
informational concepts and how they relate to each
other, modern literature explores another knowledge
management model, known as ontology (Guarino,
1996); (Guarino and Giaretta, 1995); (Noy and
KMIS2012-InternationalConferenceonKnowledgeManagementandInformationSharing
100
Musen, 2002); (Noy, 2010).
2.3 Ontologies and Ontological
Representation
Ontology refers to the idea of set-of-concept-
definitions, which is more general than taxonomy
(Gruber, 2009). In such a set, the concepts are
represented by classes, their attributes and their
instances, linked by relations. According to Gruber
(2009), they must be developed for the purpose of
sharing knowledge between people and/or
computational agents.
In
this sense, ontologies can have a variety of formats
(Jasper and Uschold, 1999) and have more components,
allowing richer representations than the traditional
taxonomy.
Moreover, the use of ontologies to represent concepts
from different partners or organizations, if defined in
conformance to a referential architecture, allows
these concepts to be merged and expressed as a
single semantic model, known as upper-level
ontology, or just upper ontology.
2.4 Alignment and Merging Ontologies
According to Noy (2002, 2010), when two
ontologies are developed based in a set of predefined
rules, their automatic or semi-automatic alignment
and fusion become possible, being implemented
using resources of an existing system solution.
This process is accomplished with two activities:
first, one must identify and align these ontologies
based on their basic common components. Then, a
merge process is executed to carry out a new upper
ontology (Gruber, 2009); (Jasper and Uschold,
1999). Figure 2, from Abels at al., (2005), illustrates
the alignment and fusion process. Figure 2(a) shows
the identification and alignment of relations between
two ontologies while Figure 2(b) sketches their
merging and the resulting upper-level ontology.
Figure 2: (a) Identifying and aligning the relationship and
(b) merging between two ontologies (Abels, 2005).
The resulting model can be used in successive
alignment and merge processes. This means that
these processes may be continuously repeated by
adding other ontological models and resulting in
new upper ontologies.
However, during the generation of upper
ontologies, inconsistencies can occur if the processes
are done automatically. This can happen even when
the ontologies have the same set of basic elements in
their specifications (Noy and Musen, 2000).
3 STATE OF THE ART
In this section, we summarize the state of the art in
the domains of ontological and data services
environments, as well as BI solutions.
3.1
Ontological
Environment
Given the merging process described above, and
regarding the tools to build the ontological
environment, we must consider two distinct needs:
the construction of ontologies and the upper-level
ontology generation.
For the ontological environment, the alignment
processes and fusion are necessary in order to
centralize the ontologies of the various partners.
Such ontologies centralization environment ensures
that similar concepts, such as same classes with
overlapping instances or classified with different
terms or with different levels of granularity, can be
aligned even by inference of a human administrator.
Therefore, the merging process materializes an
unique upper ontology and their correlated
taxonomy in a multidimensional model, and so, it is
possible to use an OLAP service with this unique
model, in which the unrelated dimensions are
treated.
For the construction of ontologies, there are well
known tools, which key aspects are the ability to
capture external ontologies and the edition of
ontologies with standard representation languages.
For the generation and record of an upper-level
ontology there are ontology maintenance tools based
on a centralized repository with options for aligning
and merging (Noy and Musen, 2002).
As shown in Noy and Musen, 2002, and Abels et
al., 2005, there are several studies about evaluation
of tools for building, aligning and merging
ontologies. Based on these studies, we point out
advanced solutions such as COMA++, PROMPT
and Glue. In particular, COMA++ provides
advanced configuration of integration approaches
ArchitectureofaCollaborativeBusinessIntelligenceEnvironmentbasedonanOntologyRepositoryandDistributedData
Services
101
and evaluation of similarities as well as the ability to
implement new approaches.
3.2 Data Services Environment
The increasing use of distributed service-based data
environments (Bennett et al., 2000) and the growth
of the bandwidth in data transmission over the
Internet (Kempf et al., 2010) favored the use of a
data access mode based on decentralized and
distributed data sources. However, since the
integration is made between different partners with a
priori unknown infrastructure environments, the use
of interoperable standards and models are required.
Related to the techniques of Service-Oriented
Architecture (SOA), there is an emerging standard
technology to provide data on demand called Data as
Services (DaaS), or just Data Services. These
techniques use the extensible markup language –
XML, as the basic exchange pattern (Hui et al.,
2009).
Chaudhuri et al. (2011) states that the processes
based on data services, which initially consisted of a
simple storage of keys and values, have been
enhanced to support the functionality of a single
relational database in the form of a hosted service or
a data provided service. This is the operation mode
of Microsoft SQL Azure and Cloud Data Services in
Amazon EC2.
Moreover, some organizations have developed
protocols and services for managing and
dynamically querying tabular data. This is provided
by Google with GData, Microsoft with OData and
Yahoo with DataRSS (Kansa and Bissell, 2010).
Thus, these XML based standards are emerging
associated with cloud computing initiatives.
However, since the XML traffic is yet extremely
inefficient for any model, we suggest the
incorporation of data cache mechanisms in BI
environment for data services.
3.3 BI Solutions
In existing BI architectures, the main components
responsible for the operations and support to
answering queries accessing multidimensional data
structures are the OLAP server and the analytical
interface, as represented in Table 1, within the
Application and Presentation layers, respectively.
Regarding the operationalization of our proposed
architecture, the corresponding requirements can be
fulfilled by adapting some existing open source
platforms, including Pentaho BI, Spago BI and Palo
BI (Liu and Lou, 2010).
We emphasize the use of solutions based on
principles of Virtual Cubes, which allow an easy
adaptation to higher models with unrelated
dimensions.
Moreover, changes in the organization concepts
of each BI system should be updated to the other BI
systems. Finally, errors in a certain BI system can be
propagated to the others reducing the reliability of
the integrated system in Figure 3.
In Figure 3, we exemplify traditional solution for
integrating four BI systems of different
organizations. Each BI system should allow
exchanging information beyond its domain.
4 PROPOSED ARCHITECTURE
In our proposed architecture, we consider the
ontological and the data services environments as
solutions to establish the Infospace and Dataspace,
respectively. In practice, these environments are
integrated using common components of BI
platforms.
4.1 General Structure of the Proposed
Architecture
In Figure 4, we identify and place the components
along with the general structure of our proposed
architecture.
Figure 3: Example of traditional integration of four BI
systems.
According to Figure 4, we distinguish three
environments: User environment, Collaborative BI
environment and Organizational environment.
KMIS2012-InternationalConferenceonKnowledgeManagementandInformationSharing
102
Figure 4: General structure of the proposed architecture.
The User environment, represented by the
front-end web application, is used to make
information queries. This environment is associated
with the Presentation layer in Table 1.
The Collaborative BI environment is the core
service provider in our proposed solution. This
environment is associated with the Application layer
in Table 1.
The Organizational Environment is
represented by ontological development tools and
Data Services that are provided by each of the
partners and thus are located within the partners
environments. This way, differently from the
conventional BI architecture, which directly
accesses the local Repository, in our proposal data
and information are remotely accessed by means of
Data Services.
It is worth to note that the Data Management and
Transformation layers in Table 1 are not included in
the scope of this work, since they are placed within
the partner or organization boundary. Thus, each
partner or organization is responsible for its own
data quality management and interpretation.
Also in Figure 4, each layer may have one or
more components. For instance, the User
environment has only one component which is the
analytical interface platform existing in BI
platforms. In our architecture, this component needs
to be adapted to read the ontological model placed in
the centralized repository.
In the Collaborative BI environment, there are
two components: the centralized ontology repository
and the OLAP Server.
The centralized ontology repository, integrated
with a correlated ontology development tool,
provides and integrates concepts using resources for
the alignment and merging of various ontologies.
This repository must support the management of
semi-automated ontology merge processes.
The OLAP server solution accesses the remote
data services as data sources. This server needs to
interact with the contents placed in the ontology
repository to generate multidimensional models at
runtime.
In the Organizational environment we have the
other two components: the ontology development
tool and the data services platform.
The ontology development tool creates and
updates the conceptual model of the information
created by the partners. This tool is based on
techniques and standards that enable successive
ontology alignment and merge steps, in order to
compose the upper-level ontology.
The data services platform enables the
collaborative BI environment to access the partner
organization environments in compliance to
specified standards of SOA Data as a Service.
In order to show the feasibility of our proposed
architecture, we show its constituents in Figure 4
and describe them hereafter.
4.2 Layers and Cycles of the Proposed
Architecture
Similarly to a conventional BI environment, we also
divide our proposed architecture into layers.
However, we consider only four layers, which are
named: Interface layer, OLAP layer, Ontology layer
and Data Service layer.
The Interface layer uses the upper ontology
recorded in the centralized ontology repository to
ensure the formation of a consistent model. The
centralized ontology repository stores the
relationships between classes, instance and metrics,
as well between metrics and their sources. The major
concern found in this layer is to keep control given
the constraints imposed by these relationships.
The OLAP layer receives the request and
constructs the response in multidimensional cubes.
There are no major concerns about the integrity
between the hierarchies and the selected metrics
because these are ensured previously by the
Interface layer. Thus, differently from reading a pre-
defined multidimensional model, this layer allows
the dynamic construction of a sufficient and
necessary multidimensional model from the
centralized ontology repository.
The Ontology layer is materialized both within
the limits of organizations playing a client role as
well as within the Collaborative BI Environment
acting as a server. This way our proposed
architecture provides elements that can be combined
within different approaches for the integration of
heterogeneous ontologies.
User Environment
Collaborative BI Environment
Organizational Environment
Analytical Interface
Centralized
Ontology Repository
Ontology
Development Tool
OLAP Server
Data Services
Platform
ArchitectureofaCollaborativeBusinessIntelligenceEnvironmentbasedonanOntologyRepositoryandDistributedData
Services
103
The Data Service layer is used to publish and
provide data as a service. Therefore, the goal of this
layer consists of decoupling the partner’s concepts
from the sources of data. It is worth to note that this
layer applies two SOA design patterns, namely the
Service Loose Coupling and Service Abstraction.
Now regarding the development of applications
based on the proposed architecture the process,
similarly to that of a conventional BI environment,
must be performed in two cycles, named
Construction and Usage cycle as represented in the
second and third columns in Figure 5.
The Construction cycle involves tools for
building and integrating conceptual models within
the centralized ontology repository and providing
the related access to data services published by each
partner using its Data Service Platform.
In the Usage cycle, on behalf of the BI user the
analytical interface interacts with the OLAP server.
The OLAP server requests data as service from the
necessary partners and then generates and delivers
the multidimensional response back to the analytical
interface.
In Subsection 4.3, we present a description of the
basic process and elements involved in each of these
cycles.
4.3 Processes and Elements Involved in
the Construction Cycle
Figure 5: Environments, cycles, layers, and processes of
the proposed Collaborative BI architecture.
Using the ontology development tool, a new
partner performs an ontology construction resulting
in the conceptual model of information (a). This
process can perform an initial capture of an existing
ontology from the centralized ontology repository,
and then use it as basis for the client solution (b).
Also using the ontology development tool
linked to the centralized ontology repository, the
partner performs the ontology publishing, i.e.
executes a handshake process until the model is
accepted (c). After that, an underlying application
generates the proposals of Data Services (d).
Next, this new partner performs a Data Service
publishing, i.e., turns these data services available in
its service inventory (e).
At the end of this publishing task, an additional
underlying application can be used to evaluate the
queries to the Data Service in order to ensure the
overall model performance.
4.4 Processes and Elements Involved in
the Usage Cycle
By using the analytical interface platform, the
end-user performs the information selection
process, i.e., the user selects and filters concepts and
metrics, as well as he adjusts the output of columns
and rows to fulfill the business requirements (f). The
use of this interface is controlled by the upper-level
ontology structure loaded from the centralized
ontology repository (g).
These user selections are sent to the OLAP
server as data requirements. The OLAP server reads
the multidimensional structure from the upper-level
ontology at the centralized ontology repository as
needed (h).
Then, the OLAP server prepares and directs the
necessary data requests to data provisioning
services provided by the data service platforms of
the involved partners (i). When all data are returned,
the OLAP server executes the multidimensional
cube generation (j) and routes the result to the
analytical interface platform (k).
4.5 Applications of the Proposed
Architecture
With our proposed architecture, strategic
information networks can link concepts and data
from various partners. This integration can be better
reached if the data service layer of each involved
partner is conformant to a BI architecture. Moreover,
the fitting and use of systemic elements already
existing simplifies the construction of the intended
environment.
By applying semantics in conjunction with
business intelligence assessments, we can relate to
KMIS2012-InternationalConferenceonKnowledgeManagementandInformationSharing
104
various subjects such as in the areas of public policy,
security, economy, education. (Ludwig, 2005)
In Figure 6, we present our proposed centralized
ontology repository, which adjusts its ontology
according to taxonomy of the four BIs that are
integrated. Moreover, in case of inconsistency of a
certain BI system, the centralized ontology
repository may ignore it and consider only the
remaining BI systems.
Additional tasks may be performed by the
administrator in order to create pre-defined
indicators for general use inside the centralized
ontology repository. These tasks fulfill the
requirements proposed by Berthold et al. (2010).
Although our architecture can be easily built,
some questions related to performance are identified.
In this sense, we point out some future
improvements to solve these questions: the use of
optimized mechanisms of SOA transport, the
implementation of cache schemas in OLAP servers
and data services, the setting of restrictions on the
amount of data that can be generated, the
implementation of compression techniques to
transfer data from the Data Service layer to the
OLAP layer.
Another crucial aspect is the capacity to fully
automate tasks in the aligning and merging
processes. The commitment to fully implement the
automation in a sole step seems to be unreasonable,
since this process requires information exchanges
regarding similarities, an activity that still imposes
human intervention. Therefore, it is required a
mediator to check if a minimum consistency level
has been reached, otherwise an automated solution
may affect existing models of the participants.
Figure 6: Example of the proposed centralized ontology
repository for integrating four BI systems.
However, this effort can be minimized if the
selected elements for the ontology layer are able to
use a rich combination of different approaches for
ontology integration, such as measuring the
similarity between texts, extraction of text
keywords, execution of language-based analytical
methods, identification of relationships between
words, evaluation of similarity between types of data
with assessments in domains and value ranges,
general structural and taxonomic analysis,
integration of data with analysis of key properties,
and graphical mapping.
5 CONCLUSIONS
In this paper we propose a collaborative BI
environment architecture in which the composition
and treatment of analytical queries are based on the
interoperation of a centralized repository of concepts
and decentralized data services.
Our approach departs from a conventional BI
environment in several respects, but mainly its two
founding principles. First, our proposal is based
upon the integration of heterogeneous semantic
concepts so as to compose upper ontologies. In
addition, source data retrieval is accomplished
according to fundamental SOA practices, such as
low coupling and abstraction.
This way, our architecture constitutes an
improved alternative to the conventional BI
structure, offering a distributed solution that is able
to integrate heterogeneous information concepts.
Finally, as a future work, we propose to integrate
BI systems of the Brazilian government based on the
Centralized Ontology Repository in Figure 6.
REFERENCES
Abels, S., Haak, L., Hahn, A., (2005). Identification of
Common Methods Used for Ontology Integration
Tasks. University of Oldenburg - Business Information
Systems- Oldenburg, Germany.
Bennett, K., Layzell, P., Budgen, D., Brereton, P.,
Macaulay, L., Munro, M., (2000). Service-based
software: the future for flexible software. Asia-Pacific
Software Engineering Conference, vol. 0, p. 214.
Berthold, H., Rösch, P., Zöller, S., Wortmann, F.,
Carenini, A., Campbell, S., Bisson, P., Strohmaier, F.,
(2010). An Architecture for Ad hoc and Collaborative
Business Intelligence. ACM International Conference
Proceeding Series, ACM.
Böhringer, M., Gluchowski, P., Kurze, V., Schieder, C.,
(2010). A Business Intelligence Perspective on the
Future Internet. Americas Conference on Information
Systems, AMCIS 2010 Proceedings, Paper 267.
Chaudhuri, S., Dayal, U., (1997) An overview of data
warehousing and OLAP technology, ACM SIGMOD
Record, vol.26, no.1, pp.65-74, March 1997, doi:
10.1145/248603.248616.
Chaudhuri, S., Dayal, U., Narasayya, V., (2011) An
overview of business intelligence technology.
ArchitectureofaCollaborativeBusinessIntelligenceEnvironmentbasedonanOntologyRepositoryandDistributedData
Services
105
Common, ACM 54, August 2011, 88-98.
DOI=10.1145/1978542.1978562.
Davenport, T. H., Harris, J. G., (2007) Competing on
Analytics: The New Science of Winning. Harvard
Business School Press, 2007, pp 240.
Fernandes, A. A., Amaro, L. C., da Costa, J. P. C. L.,
Martins, V. A., Serrano, A. M. R., de Sousa Jr., R. T.,
(2012) Construction of Ontologies by using Concept
Maps: a Study Case of Business Intelligence for the
Federal Property Department. International
Conference on Business Intelligence and Financial
Engineering (BIFE'12), Lanzhou & Tunhuang, China.
Galatis, G., Tsekeridou, S., (2011) Business Intelligence
On 2.0 Era: A Framework Described With Emphasis
On Opinion Mining, Thesis submitted for Master Of
Science. Management of Business, Innovation &
Technology (MBIT), Athens, Unpublished.
Gruber, T., (2009) What is an Ontology?. Encyclopedia of
Database Systems, Ling Liu and M. Tamer Özsu
(Eds.), Springer-Verlag, 2009.
Guarino, N. (1996) Understanding, building and using
ontologies. In: Proceedings of Knowledge Acquisition
for knowledge-based systems workshop. Knowledge
Acquisition Workshop - KAW'96, Banff, Alberta,
Canada.
Guarino, N., Giaretta, P., (1995) Ontologies and
Knowledge Bases: Towards a Terminological
Clarification. In N. Mars (ed.) Towards Very Large
Knowledge Bases: Knowledge Building and
Knowledge Sharing 1995. IOS Press, Amsterdam: 25-
32.
Hui, M., Jiang, D., Li, G., Zhou, Y., (2009) Supporting
database applications as a service. In: ICDE '09:
Proceedings of the 2009 IEEE International
Conference on Data Engineering, pages 832-843.
IEEE Computer Society.
IBM, (2004) Introduction to BI Architecture Framework
and Methods. IBM Group. DB2 Data Management
Software. IBM Corporation.
Jasper, R., Uschold, M., (1999). A framework for
understanding and classifying ontology applications.
IJCAI-99, Ontology Workshop, Stockholm, S. 1. : s. n.
Kansa, E. C., Bissell, A., (2010). Web Syndication
Approaches For Sharing Primary Data in Small
Science Domains. School of Information, Data
Science Journal, Volume 9, 8 July 2010.
Kempf, J., Nikander, P., Green, H., (2010). Innovation and
the Next Generation Internet. INFOCOM IEEE
Conference on Computer Communications Workshop,
March 2010, pp.1-6, 15-19, doi:
10.1109/INFCOMW.2010.5466657.
Liu, X., Lou, X., (2010). A Data Warehouse Solution For
E-Government. International Journal of Research and
Reviews in Applied Sciences - IJRRAS, vol.4, issue 1.
July 2010.
Ludwig, L., (2005). Business Intelligence und das
Semantic Web: ein Traumpaar. Retrieved June 04,
2009 from http://www.competence-site.de/business-
intelligencehr/Business-Intelligence-und-das-Semantic
-Web-39683.
Microsoft, (2006). Business Intelligence Guidelines
Conceptual Framework. Microsoft Corporation
.
Nelson, G. S., (2010). Business Intelligence 2.0: Are we
there yet?, SAS Global Forum Business
Intelligence/Analytics, Paper 040-2010.
Noy, N., Musen, M. A., (2000). Algorithm and Tool for
Automated Ontology Merging and Alignment. From:
AAAI-00 Proceedings. AAAI (www.aaai.org).
Noy, N., Musen, M. A., (2002). Evaluating Ontology-
Mapping Tools: Requirements and Experience.
Workshop on Evaluation of Ontology Tools at
EKAW'02 (EON2002). 2002.
Noy, N., (2010). Ontology Mapping and Alignment. Fifth
International Workshop on Ontology Matching
collocated with the 9th International Semantic Web
Conference ISWC-2010, Shangai, China.
KMIS2012-InternationalConferenceonKnowledgeManagementandInformationSharing
106
